语境工程：如何将 AI 编程助手转化为真正的生产力利器 (2026最新)

type

Post

status

Published

date

Dec 8, 2025

slug

ai-conversion-2026-5cacvo

summary

📌 来自：faafospecialist.substack.com (Substack) | 💡 AI 编程效率低？那是你还没避开 40% 的“智力禁区”。本文深入探讨了 **Context Engineering（语境工程）的核心理念，指出 AI 编程助手在处理复杂项目时效率低下的根源在于上下文管理不善。通过引入 RPI（研究-计划-执行）工作流和“40% 禁区”理论，作者分享了如何通过控制 Context Window**（上下文窗口）的质量和大小，利用 **Sub-agents**（子智能体）精准获取信息，从而避免 AI 产生“代码垃圾”，实现生产级别的代码交付。 | 🔑 关键词：Substack、faafospecialist.substack.com、FA&FO | 🤖 由Gemini 3 Flash (Google API)分析生成

当 AI 还只是个“垃圾生成器”时

我看了 HumanLayer 的 CEO Dex Horthy 在 2025 年 AI 工程师峰会上的视频，他发表了一场关于 AI 编程助手现状的震撼演讲。他没有讨论潜力或美好的未来，而是直面了一个苦涩的真相：

大多数时候当你用 AI 写代码时，你实际上创造了大量的重复劳动和 Code Churn（代码频繁变动），而且它在处理复杂任务或 Brownfield Codebases（旧有代码库）时表现并不好。

来自 Eigor 对 10 万名开发者的研究显示了一个现实：你交付的代码更多了，但其中大部分只是在重做你上周交付的那些垃圾内容。如果你在一个简单的 Greenfield Project（新项目，如 NextJS 仪表盘）上工作，AI 表现会很棒。但如果你跳进一个有 10 年历史的 Java 代码库？祝你好运。

语境工程：AI 开发的灵魂

为什么上下文如此重要？

LLMs（大语言模型）本质上是 Stateless Functions（无状态函数）。输出的质量完全取决于输入的质量。每当 Claude Code 或任何编程助手选择下一步时，都有数百个正确的步骤和数百个错误的步骤。唯一影响输出的是到那一刻为止的对话内容。

语境工程的核心在于针对准确性、完整性、规模和 Trajectory（轨迹）来优化上下文窗口。轨迹部分特别有趣——如果你因为 AI 做错了而不断责骂它，模型会学习到这种模式：“好吧，我做错了，人类吼我，我再做错，人类再吼我”。在这个对话中，概率最高的下一个 Token（令牌）就是……继续做错，等着被吼！

记住，AI/LLM 是一个统计概率算法。

“智力禁区”：40% 禁区

这是 Dex 提出的核心概念：当你使用超过 40% 的上下文窗口时，性能会开始急剧下降。

以 Claude Code 约 16.8 万个 Token 为例，40% 左右就是一个阈值，超过这个点你会看到明显的收益递减。“你使用的上下文窗口越多，结果就越差”。如果你在编程助手中加载了太多的 MCPs（模型上下文协议服务器），你其实一直是在“智力禁区”内工作，永远得不到好的结果。

为什么是 40%？研究表明 Transformer 模型有一个特性：随着上下文窗口变大，模型的 Recall（召回）和 Reasoning（推理）能力会逐渐下降。这不是 bug，而是基础架构的特性。更大的上下文窗口并不意味着不需要自律地管理上下文，相反，如果没有妥善的 Curation（筛选），它更容易导致输出质量下降。

研究-计划-执行：反“垃圾”工作流

HumanLayer 开发了一个名为 RPI（Research-Plan-Implement）的工作流。这也是我每天使用 ClaudeCode/ClaudeKit 的确切流程，也是让 ClaudeKit 的效果区别于其他 AI 编程工具的核心支柱。这不仅仅是一组提示词或死板的流程，而是一种围绕上下文管理来设计整个开发过程的哲学。

第一阶段：Research（研究）—— 压缩代码库中的重要信息

研究阶段专注于客观地理解系统如何运作，找到正确的文件并保持客观性。目标不是写代码，而是创建一个包含确切必要信息的 Markdown 文件：文件名、行号、数据流。

为什么不让 AI 自己去探索（在没有引导的情况下）？因为如果你让 AI 自由探索大型代码库，它会：

阅读一堆无关文件

用冗长的工具输出填满上下文

浪费 Token 去理解不需要的代码

从一开始就进入“智力禁区”

相反，你可以启动多个 Sub-agents（子智能体）来获取代码库的片段，然后构建一个研究文档，它就是代码库中重要部分的精确快照。

第二阶段：Plan（计划）—— 压缩“意图”

计划阶段概述了确切的步骤，包括文件名、行号、代码片段和清晰的测试步骤。这就是“意图的压缩”——你将你的意图压缩成一个干净的产物。

通过计划达成认知对齐

代码审查不仅是为了找 bug，主要是为了保持 Mental Alignment（认知对齐）——确保团队中的每个人都理解代码库为何改变以及如何改变。

问题是：当 AI 每周交付 2000-3000 行代码时，你没法读完所有代码。但你可以读计划。例如，当把整个 Claude 对话记录附加到 PRs（拉取请求）时，我们可以帮助审查者看到确切的步骤、提示词和测试结果——这能带审查者经历一段单纯的 GitHub PR 无法提供的旅程。

第三阶段：Implement（执行）—— 在清爽的上下文中执行

执行阶段是助手根据研究和计划实际编写代码的阶段。目标是保持上下文窗口的效率（Dex 建议在 40% 以下）并在关键检查点进行人工审查。

关键实践：

持续 Compact（精简）并更新上下文窗口。

标记已完成的任务，专注于剩余任务（在 CK 中如果使用 `/code` 命令会自动处理这部分）。

审查计划而不是阅读原始的代码变更。

你们中的许多人在使用 CC/CK 时都会犯这个错误：把所有任务都委托给 AI 替你思考，然后让它自由发挥，最后 AI 把你带到了火星……求求了，请审查计划！

子智能体：关乎上下文控制，而非“角色扮演”

Dex 警告的一个常见反模式：子智能体不是为了“角色人格化”。人们经常创建“前端子智能体”、“后端子智能体”、“QA 子智能体”、“数据科学家子智能体”——请停止这样做。

子智能体是为了控制上下文，而不是为了模拟人类角色。老实说，我最初也犯过这个错误。

“子智能体是出去收集有用信息的军队！”

使用子智能体的正确方式：

假设你想了解一个大型代码库中某个功能的工作原理。与其让主智能体阅读几十个文件、浪费 Token，不如：

派生一个拥有清爽上下文窗口的 Sub-agent。

子智能体进行探索、阅读文件、理解代码库。

子智能体返回一条极其简洁的消息： “你需要的文件是 `src/auth/oauth.ts` 第 142-256 行”。

主智能体只需要阅读那 1 个文件，然后直接开始工作。

如果你正确使用子智能体，你可以获得很好的响应并极其高效地管理上下文。秘密就在这里：这就是 ClaudeKit 中的 Scout（侦察）子智能体的工作原理。

有意图的精简：核心工作流

有意识地定期压缩意味着围绕“上下文管理”设计整个工作流，将其保持在 40-60% 的最佳范围。

起初的天真方式：

问 AI -> 错了 -> 修正 AI -> 又错了 -> 修正…… -> 上下文用尽或放弃。

稍微聪明一点的方式：

问 AI -> 偏离轨道 -> 带着引导在清爽的上下文中重新开始：“做这个，但不要用 ABC 方法，因为行不通”。

终极大师级（RPI）：

研究（子智能体） -> 人工审查 -> 计划 -> 人工审查 -> 执行（清爽上下文） -> 测试 -> 压缩 -> 下一阶段。

看起来很眼熟对吧？没错，这就是 ClaudeKit 的工作流！

被扭曲的“规范驱动开发”

在 Dex 的演讲中，我发现最有趣的一点是他宣布 Spec-driven Development（规范驱动开发）已经死了——不是这个想法死了，而是这个词。

规范驱动开发：当一个术语由某个人/团体发明并有了很好的定义，但随后它以多种方式在社区传播，最终扭曲了原始定义。

现在“规范驱动开发”意味着什么？

有些人： “写更好的提示词”。

另一些人： “写 PRD（产品需求文档）”。

有些人： “使用可验证的反馈循环”。

Sean Wang： “把代码当成汇编，专注于 Markdown”。

其他人： “编程时使用很多 Markdown 文件”。

还有些人： “开源库的文档”。

天哪……没错，这就像“传声筒”游戏——一个人听另一个人说，有人读了别人写的东西，然后加上了自己的“解释”，最后完全跑偏了。这就像“语境污染”导致 AI 产生幻觉。

结果呢？这个术语变得毫无用处。与其争论“规范驱动开发”意味着什么，不如专注于真正有效的东西：Research（研究）、Planning（计划）和 Intentional Compaction（有意图的精简）。

核心教训

**不要让 AI 代替你思考**……拜托，我们有大脑，AI 没有。训练你的大脑去思考得更好，变得越来越通透。AI 无法取代思考，它只能放大你已有的思考——或者建议你尚未想到的思考。

**“坏的代码行” vs “坏的计划行”**：一行坏代码就是一行坏代码。但一行坏的计划可能导致 100 行坏代码。一次坏的研究——误解了系统的工作原理——会导致整个事情崩塌。这就是为什么“人工审查”在 AI 开发过程中始终是关键步骤。我们必须专注于影响最高的部分：研究和计划，而不是原始代码。

**上下文是稀缺资源**：我们需要像操作系统对待 **RAM**（内存）和 **CPU** 一样理解和对待上下文：它们是有限的资源，需要平衡、压缩、优化和智能分配。高效的智能体系统并不是要把尽可能多的代码塞进上下文，而是要仔细筛选、优先考虑相关性并持续压缩。

**旧有项目需要不同的方法**：在 Greenfield 项目（新应用，白手起家）中，AI 能提高 30-40% 的生产力。但在 Brownfield 代码库（遗留系统、复杂系统）中，情况完全不同。RPI 工作流是专门为旧有项目设计的——在这些项目中，你不能只是“问问 AI 就能搞定”。

**工具是人人可得的，但工作流不是**：编程助手将变得商品化并被广泛发布（如 ClaudeKit）。每个人都能接触到它们，并会学习如何更好地使用它们。难点在于，在一个 99% 的代码由 AI 交付的世界里，团队和流程如何运作。

这就是我的观点：Context Engineering（语境工程）是最高准则。

如果你最近一直在读我的博客，你会知道我对当前 AI 模型的看法：它们已经撞墙了！不要指望模型会变得聪明很多，每个新版本的发布可能只提升不到 1%，肉眼几乎无法分辨。

然而，这并不意味着模型不好——利用今天的模型，我们已经可以实现生产质量的代码——只要你知道如何管理上下文。

语境工程可以定义如下：

“构建动态系统，以正确的格式提供正确的信息和工具，以便 LLMs 能够合理地完成任务。”

总结一下：

**正确的信息**：研究得当，不多也不少。

**正确的工具**：使用子智能体进行探索和收集必要信息，而不污染上下文。

**正确的格式**：带有代码片段的计划，而不仅仅是抽象的描述。

**正确的时间**：必要时进行精简，不要触碰“智力禁区”。

甚至 Anthropic 的工程团队也说过：语境工程不只是往提示词里塞更多东西——它是对信息进行结构化、压缩和筛选的刻意练习。

而这取决于你，没有任何 AI 模型能“替你思考——替你完成”！

所以，我对那些在 AI 编程工具中挣扎的开发者的建议是：不要等待模型变得更“聪明”——现在就开始学习语境工程。

顺便说一句，最近 Gemini 生成的插图相当不错！

📌 关键收获

对 Grace 的启示

**营销素材的“语境压缩”**：在利用 AI 撰写独立站落地页或广告文案时，不要一次性塞入几十页的产品资料（进入智力禁区）。应先让 AI 提取核心卖点（Research），确认文案大纲（Plan），最后再在清爽的上下文中生成正文（Implement）。

**建立 SOP 知识库作为“外部上下文”**： AI 效率的高低取决于你喂给它的信息质量。为你的独立站运营建立结构化的 Markdown 文档，包含品牌语调、受众画像和过往成功案例，这比写长达 1000 字的 Prompt 更有效。

**警惕“伪自动化”**：不要期待 AI 能完全自主完成选品或增长策略。在“计划”阶段必须由你亲自 Review。一个错误的增长逻辑（坏的计划行）会导致后续执行中浪费大量的广告预算（100 行坏代码）。

语境工程不只是往提示词里塞东西，它是对信息进行结构化、压缩和筛选的刻意练习。

👉

想了解更多细节？ 查看原文 →