文章目录开篇一、提升最明显的不是打字速度二、过去三周真正省下了什么时间1. 少走需求误解的弯路2. 少做无目标的代码修改3. 少把时间花在重复劳动上三、效率提升必须同时看质量四、这三种做法我仍然不会交给 AI 决定1. 业务规则的最终确认2. 高风险修改是否上线3. “看起来正确”的代码是否可信五、我现在固定保留的一个最小闭环六、下一阶段应该继续提升什么总结✍创作者全栈弄潮儿²⁰²⁶ 个人主页全栈弄潮儿²⁰²⁶ 专栏地址AI 编程进阶实战开篇过去三周我们已经讨论了不少 AI 编程方法如何拆解模糊需求。如何让 AI 先写方案再写代码。如何阅读陌生项目和定位故障。如何生成单测、审查代码和编写技术文档。但“学会了很多方法”不等于开发效率真的提升了。真正值得复盘的问题是我到底在哪些环节变快了这些速度有没有带来新的风险一、提升最明显的不是打字速度很多人使用 AI 后第一感受是代码写得更快了。但更重要的变化通常发生在编码之前和编码之后环节过去的做法现在的做法需求分析看一句话就开始写先补齐边界和验收标准方案设计边写边改结构先让 AI 列方案和风险编码实现反复描述同一个问题按小任务逐步生成故障排查看到报错就试修复先整理事实再验证假设代码审查只看能不能运行检查边界、权限和副作用文档整理发布前临时补文档让 AI 根据已确认事实生成效率提升的核心不是让 AI 替我写完所有代码而是减少了反复试错和重复沟通。二、过去三周真正省下了什么时间1. 少走需求误解的弯路以前遇到模糊需求往往先做一个“看起来能用”的版本等评审或联调时才发现权限范围没有定义。异常流程没有考虑。返回结果不符合调用方预期。数据量增加后方案无法运行。现在会先让 AI 提出澄清问题并把需求转换成任务清单。这一步可能多花几分钟却能减少后面的大量返工。2. 少做无目标的代码修改“帮我优化一下”通常会带来大范围重写。现在我会先要求 AI 说明这个建议解决了什么真实问题 它会改变哪些行为 如何验证修改确实有效没有问题、没有证据、没有验证方式的建议不会直接采纳。3. 少把时间花在重复劳动上下面这些工作很适合交给 AI根据规则生成测试场景。根据代码提取接口参数。根据日志整理排查假设。根据提交内容生成文档初稿。根据改动范围列出审查清单。它们不一定复杂却很消耗注意力。交给 AI 后我可以把时间集中到判断和验证上。三、效率提升必须同时看质量如果只是代码产出速度变快但缺陷和返工也变多这不叫真正的提效。我会从下面四个指标观察效果指标复盘问题交付速度从需求确认到可测试版本用了多久返工次数是否因为理解错误反复修改缺陷数量测试和上线后暴露了多少问题理解成本接手代码和文档是否更容易尤其要关注“返工次数”。如果 AI 让第一次输出变快却让后续修改变多就说明工作流还没有建立好。四、这三种做法我仍然不会交给 AI 决定1. 业务规则的最终确认AI 可以列出优惠券、权限、库存等边界但它不知道当前项目真正采用哪条业务规则。规则必须由产品、业务负责人或开发者根据项目事实确认。2. 高风险修改是否上线涉及权限、金额、数据迁移、并发和线上配置的修改AI 可以提供分析但不能替代评审和验证。3. “看起来正确”的代码是否可信代码能运行只能说明它通过了某些路径。还要检查功能是否符合需求 异常是否可控 数据是否安全 测试是否覆盖关键边界AI 的输出可以作为候选方案不能直接作为最终结论。五、我现在固定保留的一个最小闭环面对大多数开发任务我会按下面的顺序操作1. 说明背景和约束。 2. 让 AI 先提问题或列方案。 3. 把任务拆成可以独立验证的小步骤。 4. 每完成一步就运行测试或检查结果。 5. 最后让 AI 做一次风险审查和文档整理。这套流程不依赖某个特定工具也不要求每次都写很长的 Prompt。关键是不要跳过“先理解”和“再验证”这两个阶段。六、下一阶段应该继续提升什么过去三周解决的是“如何把 AI 用起来”。下一阶段需要进一步解决三个问题如何让 AI 更准确地理解真实代码库。如何在完整项目中控制修改范围。如何让 AI 参与从开发到交付的完整闭环。也就是说重点会从单个问题的 Prompt逐步转向可持续的项目协作方式。总结过去三周的最大收获可以概括为三句话先理解再生成。 先验证再采纳。 先控制风险再追求速度。AI 主要帮助我减少重复劳动和无效试错。真正的效率提升必须同时体现在速度、质量和返工次数上。需求判断、风险决策和最终验收仍然需要开发者负责。如果只记住一个结论那就是AI 编程的效率不是生成了多少代码而是更快交付了多少正确、可靠、可维护的代码。下一篇文章我们将进入小项目实战《用 AI 从零搭一个 API 服务项目实战开篇》✍坚持原创求关注点赞收藏