为什么同一个模型，有的人生成的是生产级代码，有的人生成的却是一堆需要重写的代码？

经过这段时间的实践，我发现答案并不在 Prompt，而在于 Context（上下文）。

AI 并不是一个凭空创造代码的程序员，它更像一位刚加入团队的新工程师。

如果你只告诉它：

实现这个功能。

它只能根据自己的理解去猜。

如果你把需求、设计原则、团队规范、历史决策都告诉它，它写出来的代码质量就会完全不同。

我现在基本采用下面这套流程。

Requirement Review
        ↓
RFC
        ↓
Architecture Design
        ↓
Project Rules
        ↓
AI Coding
        ↓
ADR
        ↓
Knowledge Base

第一步：Requirement Review

这是我认为整个流程里最重要的一步。

很多 Bug，并不是代码写错，而是需求理解错。

所以，我会先让 AI Review Requirement，而不是直接开始 Coding。

例如：

• 需求是否完整？
• 有没有歧义？
• 有没有遗漏的边界条件？
• 有没有非功能需求（性能、安全、扩展性）？

很多问题在这里就已经暴露出来了。

第二步：RFC

以前我总觉得 RFC 是为了写文档。

后来发现，它真正的作用是帮助做决策。

在 RFC 里，我不会直接问 AI：

怎么做？

而是让 AI 和我一起讨论：

• 有哪些方案？
• 每个方案的优缺点？
• 哪些约束最重要？
• 为什么最终选择这个方案？

最后得到的是一个经过讨论后的设计方向，而不是 AI 给出的第一个答案。

第三步：Architecture Design

RFC 决定方向。

Design 决定实现结构。

这里会确定：

• Service Boundary
• API
• Module
• Data Flow
• Error Handling
• Monitoring

到这一步，系统结构已经基本确定。

AI 不需要再猜。

第四步：Project Rules

这是最近让我收获最大的部分。

我开始把团队里的很多隐性经验，逐渐整理成 AI 可以理解的规则。

例如：

• 命名规范
• 文件组织方式
• Cache 使用原则
• Storage 选择原则
• Logging 规范
• Error Handling 风格
• Testing 要求

这些不是语言知识，而是团队长期积累下来的工程经验。

以前，这些经验都存在工程师脑子里。

现在，它们变成了 AI 的长期上下文。

第五步：AI Coding

到这一步，我发现 AI 写代码变得非常轻松。

因为：

需求已经明确。

设计已经确定。

规则已经存在。

AI 真正负责的，只剩下实现。

它不再负责设计，而是负责执行。

生成出来的代码，和团队风格几乎一致。

后续修改也明显减少。

第六步：ADR

现实中，实现过程经常会偏离最初设计。

例如：

实现过程中发现某个方案复杂度太高。

或者性能达不到要求。

这时候，我不会默默修改代码。

而是补充一份 ADR（Architecture Decision Record）。

记录：

• 为什么偏离原设计？
• 为什么采用新的方案？
• 这个决定带来了哪些影响？

这样，下次 AI 再遇到类似问题，就能理解当初为什么这么改。

我真正积累的不是 Prompt

很多人现在还在收集 Prompt。

但我越来越觉得，Prompt 的价值其实越来越低。

真正有价值的是：

• Requirement Review
• RFC
• Architecture Design
• Project Rules
• ADR

这些共同组成了 AI 的长期记忆。

以后，每完成一个项目，这套知识都会不断增长。

下一次开发类似功能时，AI 不再从零开始，而是能够参考过去所有的设计决策和经验。

我的一个新认识

过去，我认为：

AI Coding = Prompt Engineering。

现在，我更愿意称它为：

Context Engineering。

AI 的能力没有变。

真正变化的是，我给它提供的上下文越来越完整。

从需求，到设计，到团队规范，再到架构决策，整个软件开发过程都变成了 AI 可以理解和复用的知识。

我也越来越相信，未来真正拉开差距的，不是谁会写 Prompt，而是谁拥有更完整、更高质量的工程知识体系。

AI 不会替代架构师。

但一个拥有完整知识体系的架构师，会把 AI 的能力放大很多倍。