AI 编程“降智”实录：来自 Claude 工程师的 5 个“反直觉”真相
为什么你的 AI 编程助手总是吐出“垃圾代码”？
只要是写代码的，大概都经历过这种精神分裂时刻：在一个全新的 “绿地”项目（Greenfield） 里，AI 像个绝世天才，代码写得飞起；但一旦把它扔进一个满是历史遗留问题的 “棕地”代码库（Brownfield），它就瞬间降智，开始疯狂输出需要你花几小时去修补的“垃圾代码”。
这是一个行业通病。一项针对 10 万名开发者的调查揭示了残酷真相：AI 虽然提高了产出速度，但也导致了大量的代码重构。我们陷入了一个怪圈：这周节省的时间，全用来清理上周 AI 留下的烂摊子了。
别急着怪模型不够聪明。问题的核心在于我们还在用那套混乱的“提示-纠正”老办法。是时候升级你的操作系统了，我们需要一种更专业、更具纪律性的方法论——“上下文工程”（Context Engineering）。
这不仅仅是理论，这是一套经过实战验证的系统。本文将分享Claude 工程师五个颠覆认知的见解，帮你把 AI 从一个“烂代码制造机”调教成真正靠谱的工程伙伴。
1. 你的 AI 有个“降智区”，而你正把头往里钻
先打破一个最大的误区：给 AI 的信息并非越多越好。恰恰相反。
每个大型语言模型（LLM）都有个 “上下文窗口”（Context Window），也就是它的短期记忆。但这个记忆空间有个致命的性能拐点——我们可以称之为 “愚蠢区”（The Dumb Zone）。研究表明，一旦上下文的使用率超过某个阈值（比如 40%），模型的智商就会呈断崖式下跌。
“你塞进去的上下文越多，吐出来的结果就越烂。” —— Jeff Huntley
这听起来很反直觉，因为人类习惯了“多多益善”。但对 LLM 来说，过载的信息就是噪音，会直接干扰它的推理回路，最终吐出低质量的代码。
所以，第一条军规就是学会 “有意压缩”（Intentional Compaction）：主动精简上下文，把 AI 牢牢按在它最高效的 “智能区”（Smart Zone） 里干活。
2. 别再“纠正”你的 AI 了——你这是在教它怎么摆烂
理解了“愚蠢区”，你就该明白为什么“反复纠正”是最蠢的交互方式。当你对 AI 说“你错了，改一下”时，你不仅是在修一个 Bug，更是在污染整个对话的 “轨迹”（Trajectory）。
LLM 是通过对话模式来学习的。如果你的交互模式是“犯错 -> 挨骂 -> 再犯错 -> 再挨骂”，AI 的内心独白大概是这样的：
“懂了。这个对话的剧本就是：我犯错，然后人类纠正我。为了符合这个剧本，我最好再犯个错，这样人类就能继续扮演他的纠正者角色了。”
别笑，这是真的。这揭示了一个深刻的真相：你不是在给指令，你是在双向塑造它的行为。
与其在一个已经跑偏、且塞满了错误信息的对话里浪费时间（这时候 AI 多半已经掉进“愚蠢区”了），不如直接掀桌子：果断放弃当前对话，开一个新的、干净的上下文窗口，从头开始。如果用 Claude 模型比较多的同学应该能理解，如果你看到了“you are absolutely right”的时候，你可能就到了应该掀桌子的时候了。
3. 子智能体不是你的“队友”，它们是“上下文清洁工”
怎么既处理复杂任务，又避免“愚蠢区”？答案是子智能体（Sub-agents）。
很多人把子智能体拟人化，觉得它们是“前端专家”或“测试员”。大错特错。它们的真实身份其实更卑微也更强大：它们是控制上下文的过滤器。
想象一下，你要让 AI 理解一个巨型代码库。直接把所有文件扔给主智能体？那是自杀。正确的做法是：派一个小弟（子智能体）去读那堆文档，在一个独立的上下文里完成繁重的搜索和分析。
完事后，它回报错时，不要给主智能体看几千行的原始代码，而是一句高度压缩的结论：“去看 service.py 第 87 行。”
这样，主智能体的脑子（上下文窗口）始终是清爽、专注的。子智能体不是来陪你聊天的，它们是来帮你倒垃圾的。
4. “规范驱动开发”已死，拥抱 RPI 才是未来
“规范驱动开发”（Spec-Driven Development） 这个词已经被玩坏了。正如 Martin Fowler 警告的，这归咎于 “语义扩散”（Semantic Diffusion） 一个好词一旦被炒作，每个人对它的理解就天差地别，最后它就变得一文不值。
忘掉那些虚头巴脑的概念吧。我们需要的是一套能把“避开愚蠢区”、“保持轨迹干净”、“压缩上下文”这些原则落地的实操工作流：研究-计划-实施（Research-Plan-Implement, RPI）。
RPI 把编程任务拆解为三步，每一步的核心都是 “压缩”：
- 研究（Research）：压缩“理解”。让子智能体去钻代码库，只提炼出最关键的信息摘要。
- 计划（Plan）：压缩“意图”。基于研究摘要，制定一份包含具体文件名、代码片段和测试步骤的作战地图。
- 实施（Implement）：压缩“执行”。在前两步铺垫好的极度清晰、无噪音的上下文中，AI 只需要做一个无情的执行机器，想出错都难。
RPI 不是什么新造的时髦词，它是“上下文工程”这门手艺的具体实践。
5. AI 时代最重要的技能：知道什么“不能”外包
这就是“上下文工程”的灵魂：永远不要外包你的思考（Do not outsource the thinking）。
“AI 无法代替你思考。它只能放大你已经完成的思考，或者放大你思维上的漏洞。”
你的角色变了。你不再是那个吭哧吭哧写每一行代码的码农，你是架构师和审查官。你的核心价值转移到了杠杆率最高的环节：严格审查“研究”和“计划”的产出。
为什么？因为一行错误的代码只是个 Bug；但一个错误的研究摘要，或者一个跑偏的计划，能衍生出成百上千行建立在错误根基上的废代码。
人类的职责，是在 AI 开足马力狂奔之前，先把方向盘握稳了。
真正的挑战在代码之外
未来，写代码的 AI 就像自来水一样廉价。真正的护城河不是你有更强的模型，而是你的团队有没有一套像“上下文工程”这样严谨的纪律。
现在很多团队里正在发生一场文化的断裂：资深工程师嫌弃 AI 写得烂，初级工程师依赖 AI 偷懒，结果制造了更多烂摊子让资深工程师去擦屁股。
“上下文工程”就是缝合这道裂痕的线。它提供了一套规矩，让 AI 的暴力美学能被安全地引导。
作为技术管理者，你面临的问题不是“用不用 AI”，而是 “怎么管好这群 AI”。
是任由混乱蔓延，还是建立纪律，让 AI 真正放大团队的智慧？选择权在你。
