《周复盘：过去三周，我的开发效率真正提升在哪》

开篇

过去三周，我们已经讨论了不少 AI 编程方法：

如何拆解模糊需求。
如何让 AI 先写方案，再写代码。
如何阅读陌生项目和定位故障。
如何生成单测、审查代码和编写技术文档。

但"学会了很多方法"，不等于开发效率真的提升了。

真正值得复盘的问题是：

我到底在哪些环节变快了？这些速度有没有带来新的风险？

一、提升最明显的不是打字速度

很多人使用 AI 后，第一感受是代码写得更快了。

但更重要的变化，通常发生在编码之前和编码之后：

环节	过去的做法	现在的做法
需求分析	看一句话就开始写	先补齐边界和验收标准
方案设计	边写边改结构	先让 AI 列方案和风险
编码实现	反复描述同一个问题	按小任务逐步生成
故障排查	看到报错就试修复	先整理事实，再验证假设
代码审查	只看能不能运行	检查边界、权限和副作用
文档整理	发布前临时补文档	让 AI 根据已确认事实生成

效率提升的核心，不是让 AI 替我写完所有代码，而是减少了反复试错和重复沟通。

二、过去三周真正省下了什么时间

1. 少走需求误解的弯路

以前遇到模糊需求，往往先做一个"看起来能用"的版本，等评审或联调时才发现：

权限范围没有定义。
异常流程没有考虑。
返回结果不符合调用方预期。
数据量增加后方案无法运行。

现在会先让 AI 提出澄清问题，并把需求转换成任务清单。

这一步可能多花几分钟，却能减少后面的大量返工。

2. 少做无目标的代码修改

"帮我优化一下"通常会带来大范围重写。

现在我会先要求 AI 说明：

text 复制代码

这个建议解决了什么真实问题？
它会改变哪些行为？
如何验证修改确实有效？

没有问题、没有证据、没有验证方式的建议，不会直接采纳。

3. 少把时间花在重复劳动上

下面这些工作很适合交给 AI：

根据规则生成测试场景。
根据代码提取接口参数。
根据日志整理排查假设。
根据提交内容生成文档初稿。
根据改动范围列出审查清单。

它们不一定复杂，却很消耗注意力。交给 AI 后，我可以把时间集中到判断和验证上。

三、效率提升必须同时看质量

如果只是代码产出速度变快，但缺陷和返工也变多，这不叫真正的提效。

我会从下面四个指标观察效果：

指标	复盘问题
交付速度	从需求确认到可测试版本用了多久？
返工次数	是否因为理解错误反复修改？
缺陷数量	测试和上线后暴露了多少问题？
理解成本	接手代码和文档是否更容易？

尤其要关注"返工次数"。

如果 AI 让第一次输出变快，却让后续修改变多，就说明工作流还没有建立好。

四、这三种做法，我仍然不会交给 AI 决定

1. 业务规则的最终确认

AI 可以列出优惠券、权限、库存等边界，但它不知道当前项目真正采用哪条业务规则。

规则必须由产品、业务负责人或开发者根据项目事实确认。

2. 高风险修改是否上线

涉及权限、金额、数据迁移、并发和线上配置的修改，AI 可以提供分析，但不能替代评审和验证。

3. "看起来正确"的代码是否可信

代码能运行，只能说明它通过了某些路径。

还要检查：

text 复制代码

功能是否符合需求？
异常是否可控？
数据是否安全？
测试是否覆盖关键边界？

AI 的输出可以作为候选方案，不能直接作为最终结论。

五、我现在固定保留的一个最小闭环

面对大多数开发任务，我会按下面的顺序操作：

text 复制代码

1. 说明背景和约束。
2. 让 AI 先提问题或列方案。
3. 把任务拆成可以独立验证的小步骤。
4. 每完成一步就运行测试或检查结果。
5. 最后让 AI 做一次风险审查和文档整理。

这套流程不依赖某个特定工具，也不要求每次都写很长的 Prompt。

关键是不要跳过"先理解"和"再验证"这两个阶段。

六、下一阶段应该继续提升什么

过去三周解决的是"如何把 AI 用起来"。

下一阶段需要进一步解决三个问题：

如何让 AI 更准确地理解真实代码库。
如何在完整项目中控制修改范围。
如何让 AI 参与从开发到交付的完整闭环。

也就是说，重点会从单个问题的 Prompt，逐步转向可持续的项目协作方式。

总结

过去三周的最大收获，可以概括为三句话：

text 复制代码

先理解，再生成。
先验证，再采纳。
先控制风险，再追求速度。

AI 主要帮助我减少重复劳动和无效试错。
真正的效率提升，必须同时体现在速度、质量和返工次数上。
需求判断、风险决策和最终验收，仍然需要开发者负责。

如果只记住一个结论，那就是：

AI 编程的效率，不是生成了多少代码，而是更快交付了多少正确、可靠、可维护的代码。

下一篇文章，我们将进入小项目实战：

《用 AI 从零搭一个 API 服务：项目实战开篇》

✍坚持原创，求关注，点赞，收藏