最初接触 AI 编码是在 GitHub Copilot 发布的时候。那时的使用方式非常自由——写一行注释或一个简短的描述，然后让 AI 自动完成后续的代码片段。在早期，这种方式的确提高了效率，特别是在一些小型函数或简单逻辑的开发中。但这种生成方式往往缺乏系统性和整体思考，每次生成的代码片段不连贯、不统一，甚至存在明显的错误。最终，我不得不一次次地进行人工修正，这种反复“人机协作”的过程，充满了随机性和不确定性。

当后来 Agent 模式兴起之后，AI 编码的任务规模开始升级为模块甚至整页开发。这时自然流派的弱点便暴露无遗：AI 总是专注于眼前的具体需求，而缺乏对全局架构、设计模式和已有代码规范的考虑。长此以往，代码的风格差异明显、重复造轮子的问题层出不穷，这种碎片化积累最终形成了一种难以偿还的“AI 债务”。

正是在这种反复踩坑的过程中，我逐渐意识到：我们必须给 AI 提供足够完整的上下文。

上下文流派的核心：用 PRD 引导 AI

什么是“上下文流派”？简单来说，就是明确告知 AI 它需要知道的一切，而不是让它猜测或即兴发挥。

AI 并非万能神谕，它更像一位技术能力高超但记忆有限的助理。你为它提供的信息越完整，它的输出就越符合预期，质量也就越高。具体而言，在开始一项开发任务时，我不再使用随意的自然语言，而是尽可能结构化地提供：

清晰的任务需求描述，类似产品需求文档（PRD）；
完整的项目目录结构，以及涉及的文件路径；
已有的组件和设计规范，并指出可供参考的已有页面或模块；
明确的系统提示词（system prompt），确保统一的代码风格、命名规则和开发规范。

除此之外，我还建立了更清晰的 AI 协作流程：

明确需求分析；
提出多个解决方案；
AI 自我评估，推荐最佳方案；
人类审核并最终选择；
编码实现并进行单元测试；
自动生成文档和任务记录。

这种方式让 AI 编程变得有迹可循，每个步骤都可控且透明。由此，AI 的输出代码更加稳定、一致、易于维护。

上下文流派的价值权衡

不可否认，准备充足的上下文是一件耗时的事情，尤其对不熟悉项目细节或整体架构的程序员而言，更是如此。但长远来看，这种一次性的投入能显著节省未来的时间成本，因为它避免了后续大量的修复和重构工作。

相比之下，自然流派虽然前期简单易用，但生成的代码碎片化严重，风格和逻辑常常相互冲突，未来修复或重构的成本会远高于最初的上下文准备。简单来说，提供上下文不是追求短期的“快”，而是追求长期的“稳”，是实现可持续协作的重要手段。

多人协作时，上下文流派的价值更为突出。团队中如果每个人都有自己定义的需求标准，每个人提供的上下文又各不相同，AI 必然会产生混乱的输出结果。这时，我们需要统一的提示词标准、统一的上下文结构，以及明确的协作规范，使每个团队成员站在同一条起跑线上，以避免协作中的混乱与低效。

自然流派依旧有它的空间

尽管上下文流派有着明显的优势，但这并不意味着自然流派毫无用处。我自己在一些特定的场景中仍然喜欢使用自然流派：

独立的小型任务；
单个组件的快速迭代；
个人探索或原型快速开发。

在这些场景中，我通常会直接告诉 AI：“这是个简单任务，不需要考虑系统指令，请快速推进。” 这种方式的好处是快速、灵活，甚至更富有创造性。

真正有经验的程序员，并不会简单地站队哪一个流派，而是能在不同情景下自由切换。自然流派适用于轻量、快速的任务；上下文流派则适用于长期的协作与大型系统开发。明确任务性质，灵活运用方法，才是真正高效的 AI 协作方式。

未来：写代码的是 AI，创造上下文的是你

回到文章的标题：“Context is all you need”。这句话所表达的，不只是一个简单的结论，而是一种对于未来工作的思考方式。

在未来的开发中，程序员的主要职责可能不再是手写每一行代码，而是组织上下文、明确任务、设置规范，以及管理 AI 的输出结果。这是一种崭新的技能，它要求程序员具备良好的结构化思维、精准的表达能力以及整体的架构能力。

当我们与 AI 协作时，代码可能由 AI 来实现，但创造上下文和掌控全局的角色，永远属于程序员本身。我们正在见证并亲历着这种转变——在这场由生成式 AI 掀起的协作革命中，“Context”终将成为真正的核心。