过去半年，我最大的感受不是 AI 越来越聪明了。
而是我发现，以前很多开发习惯，其实并不适合 AI 时代。
刚开始使用 AI Coding 时，我的期待很简单。
希望它帮我写代码。
帮我修 Bug。
帮我解释报错。
甚至希望它能够直接完成一个模块。
后来发现，它确实能做到很多事情。
但真正影响开发效率的，从来不是”代码生成速度”，而是整个工程流程。
这篇文章分享一下，我这半年逐步调整出来的一套 AI Coding 工作方式，希望能给正在使用 AI 的开发者一些启发。
⸻
最开始，我把 AI 当成了”高级搜索”
刚开始接触 AI 时，我的使用方式和很多开发者一样。
遇到异常。
复制报错。
粘贴到 AI。
等待答案。
或者：
“帮我写一个 Spring Boot 登录接口。”
“帮我写一个 React 表格组件。”
这种方式当然有效。
但随着项目越来越复杂，我发现问题开始出现。
同一个需求。
不同时间生成的代码风格不同。
上下文越来越长。
模型开始遗忘前面的约束。
改一个地方，又影响另外一个地方。
最后，大量时间花在：
重新解释需求。
重新整理上下文。
重新修改代码。
真正浪费时间的，并不是写代码，而是不断恢复上下文。
⸻
后来，我开始把需求拆成多个阶段
以前，一个 Prompt 解决所有问题。
现在，一个需求，我通常拆成五个阶段。
第一阶段：需求澄清
不是直接写代码。
而是先问：
有哪些业务规则？
有哪些边界条件？
有哪些异常流程？
先把需求真正理解清楚。
⸻
第二阶段：架构设计
让 AI 输出：
模块拆分。
目录结构。
数据流。
接口关系。
这一阶段，不生成业务代码。
只讨论设计。
⸻
第三阶段：核心实现
开始生成：
Service。
Controller。
Repository。
DTO。
这一阶段，每次只完成一个模块。
避免一次生成大量代码。
⸻
第四阶段：Code Review
代码完成以后，我一定会重新开一个新的对话。
让 AI 扮演 Reviewer。
重点检查：
异常处理。
空指针。
事务边界。
性能问题。
安全风险。
很多隐藏问题，就是在这里发现的。
⸻
第五阶段：文档整理
最后，再统一生成：
README。
接口文档。
部署说明。
变更日志。
整个流程下来，AI 参与了每一个环节。
但没有任何一步完全依赖 AI。
⸻
Prompt 不应该越来越长
去年大家都在讨论：
超级 Prompt。
万能 Prompt。
后来我发现。
Prompt 越长。
上下文越复杂。
模型越容易忽略重点。
现在，我更喜欢：
每一个 Prompt，只解决一个问题。
例如：
只讨论数据库。
只讨论缓存。
只讨论异常处理。
Prompt 越简单。
输出越稳定。
⸻
建立自己的 AI Checklist
以前开发结束，我主要检查：
功能有没有完成。
接口有没有问题。
后来增加了一份 AI Checklist。
例如：
✅ 有没有遗漏异常处理？
✅ 是否存在重复代码？
✅ SQL 是否可以优化？
✅ 是否存在 N+1 查询？
✅ 日志是否足够？
✅ 参数是否合法？
每次开发结束，都按照 Checklist 检查一次。
长期下来，比单纯相信 AI 更可靠。
⸻
不要让 AI 替你做架构决策
这一点，我踩过不少坑。
以前喜欢问：
“帮我设计整个系统。”
后来发现。
模型可以提供很多参考。
但真正涉及：
业务复杂度。
团队能力。
维护成本。
部署方式。
这些问题，没有标准答案。
AI 可以提供思路。
不能替代架构师。
现在，我更喜欢：
先自己给出方案。
再让 AI：
提出反对意见。
分析风险。
补充遗漏。
效果反而更好。
⸻
AI Coding 最重要的能力，其实不是生成代码
很多开发者认为：
AI Coding 最大价值就是写代码。
我现在越来越觉得：
真正重要的是：
帮助开发者持续思考。
例如：
有没有更简单的实现？
有没有更好的命名？
有没有遗漏边界？
有没有潜在风险？
这些问题，往往比生成几十行代码更有价值。
⸻
我的几个实践原则
半年下来，我给自己定了几个原则。
第一，不一次生成整个模块。
第二，不让 AI 做最终决策。
第三，复杂任务一定拆分。
第四，每个阶段都重新验证。
第五，把优秀 Prompt 沉淀成模板，而不是聊天记录。
这些原则看起来简单。
但真正坚持下来以后，开发效率和代码质量都有了明显改善。
⸻
写在最后
AI Coding 正在改变软件开发。
它减少了大量重复劳动。
也让很多开发工作变得更加高效。
但真正值得升级的，并不是某一个模型。
而是开发者自己的工程思维。
当 AI 成为团队的一部分以后，我们需要优化的，不只是 Prompt，而是整个开发流程。
最近，我也会把自己在 AI Coding、工作流设计、Prompt 迭代以及开发效率优化方面的一些实践，持续整理到公众号 【AI效率引擎】。
更多时候，它只是一本持续更新的工程笔记。
记录那些真正能够在项目里长期复用的方法，而不是追逐每一次模型更新。
未来，模型一定会越来越强。
而真正能够拉开开发者差距的，依然是工程能力、系统思维，以及持续优化工作流的能力。
