配套视频：https://www.bilibili.com/video/BV1bFvbBUEz1/
引言：AI编码的真实困境
"12位专家称，这可能是AI工程师6月最佳分享之一。"当Dex Horthy在AI工程师大会上分享他的研究时，揭示了一个令人不安的事实：根据对10万名开发者的调研，大多数人在使用AI进行软件开发时，大部分时间都在重复修改代码，且对复杂项目效果不佳。
这个现象你一定不陌生：用Cursor或Claude Code构建一个新的Vercel面板？效果很好。但接手一个十年老的代码库？可能就不那么灵了。图表清晰地显示：虽然你发布更多，但大部分只是在重做之前发布的粗糙代码。
Dex坦白说："第一次用Cloud Code时，我并不满意。"但从那时起，他的团队找到了方法，性能提升了两三倍，吞吐量大增。这迫使他们不得不改变整个软件开发的协作方式。三人团队，耗时八周，过程极其艰难，但现在他们解决了，再也不会回头。
这就是本文要探讨的核心：如何通过上下文工程，让AI在遗留代码库中高效工作，解决复杂问题，彻底杜绝冗余。
一、理解上下文工程的本质
为什么上下文如此重要？
首先要明白一个基本事实：大模型并非纯函数。它们具有非确定性，但无状态。这意味着什么？唯一提升效果的方法就是输入更优的Tokens。
更好的输入产生更好的输出——这听起来简单，但影响深远。在编码代理的每个循环步骤中，模型只会选择一个正确的下一步，而错误的选择可能有数百种。唯一影响接下来内容的，是截至目前对话中的信息。
因此，我们需要优化上下文窗口的四个维度：
准确性（Accuracy）：信息必须正确
完整性（Completeness）：不能缺少关键信息
大小（Size）：控制在合理范围内
轨迹（Trajectory）：避免错误的对话历史
关于轨迹，有个有趣的现象：很多人让智能体做件事，它却做错了。你纠正它，冲它吼，然后它又做错了，你再吼它。接着大模型看到了这一切对话：好吧，我错了，人类冲我吼了。于是下一个最可能的反向操作是——我最好别做错事，免得人类再冲我吼。
这就是最糟的结果：信息错误 + 信息缺失 + 过多干扰。
"愚钝区"：上下文窗口的临界点
Jeff Huntley对编码智能体做了大量研究，发现了一个关键规律：你用的上下文窗口越长，结果就越差。
这引出了一个非常学术的概念——"愚钝区"（Dumb Zone）。以Claude Code为例，你大约有16.8万个token的上下文窗口，部分预留给输出和压缩。研究发现，在40%左右时开始出现回报递减。
想象一下：如果编码代理中MCP过多，你一直在低效区做功，永远得不到好结果。什么占用了你的上下文空间？查找文件、理解代码流程、编辑文件、测试构建输出。如果某个MCP不断输出JSON和一堆UUID塞满上下文窗口，那就天理难容了。
40%是一个不错的参考标准，但具体取决于任务的复杂程度。关键是要意识到这个临界点的存在，并围绕它设计你的工作流。
二、压缩的艺术：巧妙绕过低效区
从最简单的方法说起
最简单的方法是什么？提出需求，让编码代理先做事，再指出错误。不断纠正、追问、追问、再追问，直到你耗尽线索、放弃或崩溃。
稍微聪明一点的做法是：偏离了就开启新对话窗口。走错路了，重新开始，同样的提示和任务，但这次我们走这条路，别去那边。
但你怎么知道何时该重来？当你看到"I apologize for the confusion..."这句话时，可能就是时候重新开始了。这正是你告诉Claude它搞砸了时的典型回应。
有意识的压缩
我们可以更聪明些，采取有意识地压缩：判断你是否在正轨上，利用现有上下文窗口，让代理压缩成一个可审阅、可标记的Markdown文件。之后新代理启动后立即投入工作，无需再经历那些搜索、基于代码的理解及处理过程。
那我们该压缩什么？具体到关键的文件和行号，我们正在解决的问题。这是一次非常有效的压缩，将上下文浓缩为最精华的部分。
子代理：控制上下文的利器
很多人对子代理有误解。如果你有前端子代理、后端子代理、测试子代理、数据科学家子代理——请停止！
子代理不是用来拟人化角色的，它们用于控制上下文。
正确的使用方式是：在大型代码库中查找某个功能的实现原理时，可以引导编码代理启动一个子代理。子代理会分出一个新的上下文窗口，负责所有读取和搜索工作，查找和阅读整个文件，理解代码库，然后只需向父级返回一条极简短的消息："文件已找到，父代理可直接读取。"
这样使用起来非常强大。父代理的上下文窗口保持清洁，所有繁重的搜索工作都在子代理的独立上下文中完成。
频繁主动压缩工作流
比子代理更有效的是一种我称之为"频繁主动压缩"的工作流。关键是你要持续保持上下文窗口紧凑。
你正在构建整个工作流，围绕上下文管理。这不是一次性的操作，而是贯穿整个开发过程的持续行为。我们的目标是努力保持在高效区，全程如此。
三、研究-规划-实施：三阶段方法论
这套方法分为三个阶段：研究（Research）、规划（Planning）、实施（Implementation）。每个阶段都有明确的目标和输出。
研究阶段：理解系统的真相
还记得电影《记忆碎片》吗？这是关于上下文工程最好的电影。男子醒来，失忆了，他得靠读身上的纹身来回忆，弄清他是谁、在做什么。
若不培训员工，他们就会自行臆测。 这就是为什么研究阶段如此重要。
研究的核心是：
理解系统运作方式
查找正确文件
保持客观
你可以把引导流程放到每个仓库里——一堆上下文，这是仓库，这是运作方式，一种压缩版的代码库智能体预先能看到的所有上下文。
但这会遇到挑战：代码库变大时，这会变得过长。你可以将它逐层分解，每个仓库根目录放个文件，每一层都可以放一个文件，每层都有相应的附加信息。
我们不记录文件本身，因为它们是真实来源。但当你的智能体运行时，你会引入根上下文，然后引入子上下文。智能区仍有充足空间，因为你只获取所需信息。
按需压缩：避免文档过时的陷阱
这里有个关键问题：这些文档会过时。每次发布新功能时，需要缓存并验证，并重建大部分内部文档。
但我想问个问题：在实际代码、函数名、注释和文档之间，有谁想猜猜哪个包含的谎言最多？
答案是：你的代码库任一部分中存在的谎言数量，文档最多。
因此，与其将更新文档作为流程的一部分（你很可能不会坚持），我们更倾向于按需压缩上下文。
若我正在开发与SCM服务商及Jira、Linear相关的功能，我会说："嘿，我们要在这块代码区域深入研究一下。"斜杠指令或提示可直接调用你的技能，启动多个子代理，对代码库进行垂直切片分析，并生成研究报告。
这只是基于代码本身对真实情况的快照。 我们正在压缩代码中关键部分的真实信息，而不是依赖可能过时的文档。
规划阶段：压缩意图的杠杆
规划是对意图的压缩。 计划则是明确具体步骤。
根据研究、PRD或缺陷报告等材料制定计划，创建计划文件。我们再次压缩，但这次压缩的是你的意图和执行路径。
规划时，你要：
列出具体步骤
包含文件名和代码行片段
表述要清晰明确
说明每次更改后如何测试
这是一个很好的规划提示输出示例：包含实际代码片段，任何人读这个方案都能轻易看出如何执行。最笨的模型也不会搞砸。
可靠性与可读性的平衡
这里有个有趣的权衡：随着计划越来越详细，可靠性越长，但可读性越低。你需要找到适合你的团队和代码库的平衡点。
我们的目标是杠杆。因此要追求高置信度——模型真能做对事。如果我无法读懂这个计划，也不知实际会怎样，那就失去了杠杆效应。
因此，我们逐步迭代优化，我们的计划包含实际代码片段，明确什么将改变。你的目标是杠杆，要压缩意图，并确保执行可靠。
实施阶段：执行的艺术
实施阶段相对直接：执行计划，保持简洁的规划提示。
这是过程中最不刺激的部分，但必不可少。当你有了清晰的计划，实施就变成了机械化的过程。
四、心智对齐：团队协作的新范式
代码审查已死，方案审查永生
我想暂停一下，谈谈心智对齐（Mental Alignment）。有人知道代码审查的真正目的是什么吗？
心理对齐，就是确保一切协调一致。但最重要的是如何让所有人保持同步——团队同步代码库的变更及其原因。
问题是：我能看懂每周千行Go代码吗？抱歉，我看不过来，太难了。我能做，但我不想。随着团队扩大，所有代码都会被审查，但最终我作为技术负责人，我能读懂方案。
我能读懂方案，并保持同步，及时发现问题。我能及早发现一些问题，并持续掌握系统的演变情况。
增强线程：让审阅者看到思考过程
Mitchell发了篇很棒的帖子，关于他如何在提交的请求中放置"增强线程"（Amplifier Threads），方便你查看。不只是在GitHub上看到一大片绿色代码，而是具体步骤和提示：
"嘿，我最后运行了构建，通过了"
"这是我采取的步骤"
"这是我们手动测试的方法"
这能让审阅者逐步理解变更过程，这是GitHub的PR无法做到的。
随着你不断交付更多代码，代码量增加两到三倍，你要想办法让团队保持高效，保持同步。
一行糟糕的计划 = 一百行糟糕的代码
如果你只记住一点，要明白：一行糟糕的代码就是糟糕的代码，计划中的一行也是如此。
计划中的一行可能包含一百行糟糕的代码。一条错误的研究路线，如同对系统运作方式和事物位置的误解，整个系统都会瘫痪。你会让模型跑偏，走向错误的方向。
因此，当我们对内或与用户合作时，我们不断尝试将人力和精力转移到这一流程中最具杠杆效应的环节——研究和规划阶段。
五、实战案例：成功与失败的教训
成功案例一：30万行Rust代码库
Dex和他的播客搭档Vibe（Boundary ML公司的CEO）进行了一次挑战："我来一次性修复你那30万行Rust代码库的问题。"
整个过程耗时一个半小时。他们做了大量调研，制定了计划，有研究和无研究的情况下都做了规划，并对比了所有结果。
周二早上他们上节目时，CTO已经看到了PR，还挺满意，说："嗯，这看起来不错，下次发布就解决了。"
确认无误：能在遗留代码中运行，且无冗余。
成功案例二：BAML项目的7小时奇迹
但Dex想试试能否解决更复杂的问题。周六，他们坐下来，一连讨论了七小时。
他们向BAML提交了3.5万行代码，其中一个PR大约一周后被合并。不过，部分代码是生成的——你更新下行为，所有黄金文件都更新了。
Vibe估计这相当于一到两周零七小时的工作量。
太棒了，我们能解决复杂问题！
失败案例：Parquet Java的教训
但这有极限。Dex和兄弟Blake坐下来，试图移除Parquet Java中的Hadoop依赖。如果你知道parquet java是什么，对不起，不管你经历了什么让你走到今天这一步。
进展不顺。
他们做了方案，做了研究成果，后来彻底推翻重来。他们重新回到白板前梳理了一遍。学会之后，他们不得不重新回到白板前，发现所有问题后，便回头思考：这究竟该如何整合。
这引出一个有趣的观点：不要外包思考。AI无法替代思考，只能放大你已有的思考或缺乏的思考。
六、规范驱动开发的迷思
人们问Dex，这是由需求驱动的开发吗？
问题在于："规范驱动开发"（Spec-driven Development）定义不明确。 这是来自ThoughtWorks的概念，但现在已经陷入了语义扩散。
很多人直接说"规格"，他们指的是：
更详细的提示
撰写产品需求文档
利用可验证的反馈循环
把代码当作汇编来处理
一堆Markdown文件
Martin Fowler在2006年提到过语义扩散：我们提出了一个定义清晰的好术语，然后大家就兴奋起来，每个人都赋予它一百种含义。对100个不同的人意味着100种不同含义，便失去了意义。
永远不会有所谓的"智能体之年"，因为语义扩散。
我们曾认为代理是人，智能体是微服务，是聊天机器人，是工作流。回到起点，智能体不过是循环调用工具。
因此，Dex不用"规范驱动开发"这个词。如果真想用个时髦词，可称之为**"驾驭工程"（Steering Engineering）**。这也是情境工程的一部分，是你集成接入点的方式，如何定制你的代码库。
七、四个真正有效的战术步骤
抛开那些过度炒作的概念，让我们谈谈四个当下真正有效的战术性和实践性步骤：
1. 做调研，弄清系统运作方式
使用研究提示，生成基于代码本身的真实快照。这些全部开源，你可以自己去下载并试试。
2. 制定计划，压缩意图
根据研究结果制定详细计划，包含文件名、代码片段、具体步骤。找到可靠性与可读性的平衡点。
3. 审查和迭代
回顾研究和计划，若可行，我们就能理清思路并对齐。别外包思考——这并非魔法，没有完美的提示。
我们围绕你——建造者，与代理反复沟通来构建整个流程。边看方案边修改，若需同行评审，可随时转发他人。
4. 执行并保持同步
实施计划，使用增强线程让团队保持同步。展示你采取的步骤，展示你手动测试的方法。
八、如何开始：根据复杂度调整方法
不必每次都执行完整的研究计划，需求有多有少：
简单任务（改按钮颜色）→ 直接告诉代理
小功能（简单计划）→ 无需复杂流程
中等规模（多仓库功能）→ 应先研究再制定计划
复杂问题（多系统交互）→ 需要更多上下文工程压缩
你能解决的问题越难，上限就越高，而你愿意做的上下文工程压缩也应越多。
很多人问：如何知道该用多少上下文设计？答案是：这需要大量练习。
你会反复出错，必须不断试错。有时过大，有时过小，选一个继续练。不要在不同工具间过度追求极致——选一个工具，多练习几次。
九、未来：文化变革的必要性
Dex认为编码代理这类东西实际上会变得普及化，人们会学会并不断提升这方面的能力。
难的是如何调整团队，以及你的开发流程如何适应这个世界——其中99%的代码由AI生成。
若搞不定这点，你就麻烦了。因为正出现一种裂痕：
资深工程师不采用AI：因为它并不能显著提升他们的速度
初级和中级工程师大量使用：因为它弥补了技能差距
结果：制造出不少烂活，高级工程师每周都在收拾Cursor前一周留下的烂摊子
这并非AI之过，这也不是中级工程师的错。因为文化变革确实很难，必须自上而下才能见效。
所以，如果你是公司的技术负责人，选一个工具，多练习几次。率先示范如何正确使用AI编码工具，建立团队的最佳实践。
结论：上下文工程是一门艺术
让我们回到核心：
上下文工程的本质：不是寻找完美提示，而是建立一套系统化的压缩和管理方法
三阶段方法：研究-规划-实施，每个阶段都有明确目标
关键原则：不要外包思考，保持在智能区，持续压缩上下文
团队协作：从代码审查转向方案审查，保持心智对齐
文化变革：自上而下推动，适应99%代码由AI生成的未来
没有完美的提示，没有万能解法。 关键在于压缩与上下文设计，保持在智能区域。
这是驾驭工程，是情境工程，是你如何定制代码库、如何与AI协作的艺术。
Dex和他的团队正在打造智能编程助手HumanLayer，助力各种规模团队快速实现99%代码由AI生成的旅程。但无论你使用什么工具，这些原则都适用。
最后的建议：选一个工具，持续练习，不断试错，找到适合你团队的平衡点。记住，AI无法替代思考，只能放大你已有的思考。
上下文工程不是终点，而是一个持续学习和优化的过程。现在就开始吧。
#AI编程 #VibeCoding #上下文工程 #ClaudeCode #独立开发者 #AI创业 #一人公司 #程序员 #软件工程师 #软件工程
