Agentic Coding 的陷阱与出路

1.1 引子：一句话与一千行代码之间

2026年5月，Hacker News上出现了一篇标题近乎挑衅的文章：《Agentic Coding Is a Trap》。作者Lars Faye没有使用任何委婉的表达——开篇第一段，他直接点明了当下被热炒的行业叙事：

“AI does the coding, and the human in the loop is the orchestrator”

“AI做编码，而人类在环中扮演编排者的角色 ¹”

这句话（Faye称之为”sentiment”而非事实）听起来优雅、时髦，完美契合了”人类升级到更高价值活动”的进化叙事。但Faye的追问同样直接：你真的相信这是正在发生的事情吗？

他紧接着描绘了一幅更接近现实的图景：整个工作流简化成了一个”拉老虎机”的过程——定义需求、生成计划，然后一遍又一遍地拉动随机性机器，迭代、再迭代，直到”完成”。这个描绘的刻薄之处在于：它把Agentic coding最被宣传的”精密编排”（orchestration）降格为一种心理安慰——实际上发生的是，编排者与被生成的代码之间的距离在每一次迭代中持续拉大，而迭代本身成了一种目的，仿佛只要继续拉下去，总会出点什么好东西。

这简直对vibe coding(氛围编程)的当头棒喝。当”orchestration”变成了隐形的距离制造机，当”迭代”变成了拉老虎机的隐喻，问题的本质已经浮现：氛围编程默认了一个错误的前提——人类可以仅凭”意图”来有效控制一个概率系统，而不需要深入理解它的输出。

本文将深入拆解Faye原文的论证逻辑，追踪每一个关键论断的隐含前提，并与srs.pub”反vibe编程”的思想进行深度融合，最终提出一个以知识为核心 ²的第三条路。

3.1 一个被混淆的概念

Faye原文的第三部分”Not Just Another Abstraction”中，有一个论断看似简单，实则是全文最重要的概念切割：

“Whether or not these tools are really an abstraction layer in the first place is not a settled matter; a higher level of ambiguity is not a higher level of abstraction.”

这句话非常有意思。抽象层(abstraction layer）在计算机科学中有明确的含义：它是一种有意识的、经过设计的简化，它隐藏了底层复杂度，同时保留了必要的可预测性。SQL是数据库操作的抽象，它让你不需要理解磁盘I/O调度就能查询数据，但它不会让你对磁盘的工作方式一无所知。Java是C的抽象，它让你不需要手动管理内存，但它仍然要求你理解什么是对象、什么是引用。

模糊性（ambiguity）则完全是另一回事。模糊性是当你不确定发生了什么时的状态。你不知道代码为什么这样运行，不知道某个修改会影响到哪里，不知道这个bug的根源是什么——这是模糊性，不是抽象。

AI编程的问题恰恰在于：它带来的”升级”是模糊性的增加，而非抽象层次的提升。你从”精确知道每行代码在做什么”跳到了”大致知道系统应该做什么，但不确定它实际在做什么”——这不是从汇编跳到Java的升级，这是从”看地图导航”跳到了”凭感觉导航”。距离目的地可能差不多，但你失去的是对路线的确切理解。

3.2 历史对比的逻辑缺陷

Faye随后讨论了常见的反驳：“程序员一直在’向上迁移’，从汇编到FORTRAN、从C到Java，每次都有类似的担忧，最终都被证明是过度忧虑。”他承认这种担忧是真实的（FORTRAN时代确实有人担心编译器引入太多”magic”），但他提出了关键的区分：那些担忧是推测性的、理论性的，而今天的影响已经在短短几年内显著显现。

这个论证的逻辑链条值得解剖：

1. 前提A：过去的担忧后来被证明是过度的
2. 前提B：那些担忧是推测性的（speculative and theoretical）
3. 结论C：今天的担忧可能也是过度的？

Faye的反驳是：今日不同，因为今日的证据已经是实证的而非推测的。 这个反驳有力，但不是无懈可击的。它的隐含假设是”实证证据比推测担忧更可靠”——这个假设通常成立，但前提是实证证据的时间窗口足够长。Faye会说：仅仅几年内的显著影响已经是证据，Simon Willison的亲身报告和Anthropic的研究都是证据。这个论点的强度取决于你对”短期实证vs长期趋势”的判断。

3.3 初级研发人员的双重剥夺

Faye提出了一个容易被忽视的论点，关于Junior developers的处境：

“Junior developers are faced with an even steeper climb, as we truncate their ability to work with code and replace it with reviewing generated code. Reviewing code is important, but it’s only 50% of the learning process, at best.”

这个”50%“的数字值得注意。Faye没有说100%是工作代码、0%是review——他说review充其量是50%的学习过程。这个数字暗示：理解代码和写代码是相互依存的，缺了任何一半，另一半的价值都会大打折扣。

其逻辑是：review之所以有价值，部分原因是它建立在你自己写过类似代码的经验基础上的。你知道”这里为什么选择这个实现”可能有一个更好的替代方案，因为你曾经写过类似的实现并发现了痛点。当你跳过直接写代码的阶段直接进入review，你获得的理解是二手的——你知道”代码应该是这样的”，但你不知道”为什么不是那样的”。

这是一个深刻的教学法洞察：技能的习得需要主动参与，而不仅仅是观察 ³和判断。 就像你看游泳教学视频不能替代下水，review AI生成的代码不能替代你亲手写代码时遇到的困惑、错误和顿悟。

3.4 高级研发人员也未能幸免

Faye引用了Simon Willison（近30年经验）的亲身观察来证明这个问题不是新手专属的：

“not having a firm mental model of what the applications can do and how they work, which means each additional feature becomes harder to reason about”

这里的关键词是”firm mental model”——坚实的心理模型。Willison不是在说”AI生成的代码太多我看不过来”，他是在说”我对自己构建的系统失去了清晰的心理图景”。这两者的区别很关键：

• “看不过来” 是一个容量问题，可以通过更多时间或更好的工具解决
• “心理模型不再坚实” 是一个理解深度问题，它意味着你对系统如何运作的直觉已经模糊了

当一个资深开发者的心理模型不再坚实，每添加一个功能都变得更难推理——不是因为功能本身更复杂，而是因为你用来推理它的工具（你的理解、你的直觉、你对系统的整体把握）已经钝化了。这比”效率降低”更危险，因为这是一个恶性循环：你越依赖AI，你对自己系统的理解越模糊，理解越模糊你越需要依赖AI。

4.1 研究的直接发现

Faye援引的Anthropic研究揭示了两个关键数据点，而它们的含义需要被分别拆解：

发现一（直接发现）：使用AI编码助手的开发者，在代码理解测试中得分比纯手动编码者低17%。

发现二（分层发现）：在同一研究中，AI用于概念探究（conceptual inquiry）的开发者得分65%以上，而AI用于直接代码生成委托（code generation delegation）的开发者得分低于40%。

Faye原文的重点落在了发现一上——他用这个数据支撑”监督悖论”的核心论点。但真正具有实践指导意义的是发现二，因为它揭示的不只是”AI有害”，而是”不同的使用模式产生截然不同的结果”。

65/40的差距说明了什么？它说明在相同的工具、相同的任务、相同的初始技能水平下，使用模式是决定性变量。高分区的人做了什么？他们的行为特征是：追问”为什么这样设计”而非接受代码本身；要求AI在生成代码的同时提供逻辑说明；核心代码自己手写，AI仅用于概念疑问和参考方案。

这不是”用不用AI”的问题，而是”怎么用AI”的问题。这个区分对Faye的论点有一个微妙的挑战——我们稍后会看到。

4.2 监督悖论的完整展开

Faye引用了Anthropic研究的原话作为”悖论”的核心表述：

“One reason that the atrophy of coding skills is concerning is the ‘paradox of supervision’… effectively using Claude requires supervision, and supervising Claude requires the very coding skills that may atrophy from AI overuse.”

这个悖论的逻辑结构可以还原为：

1. 前提：要有效使用Claude进行编码，需要对代码有足够的理解（监督能力）
2. 前提：监督能力需要通过亲自编写和调试代码来培养
3. 前提：AI编码工具的使用正在削弱亲自编写和调试代码的机会
4. 结论：AI编码工具正在削弱有效使用AI编码工具所需的能力

这是一个自我毁灭性循环的精确定义。它不是”用AI会导致一些问题”的温和警告，而是”AI的有效使用与其广泛使用之间存在结构性冲突”的严厉诊断。

4.3 Sandor Nyako的观点

Faye引用了LinkedIn工程总监Sandor Nyako的话，这段引用值得完整分析：

“‘To grow skills, people need to go through hardship. They need to develop the muscle to think through problems,’ he said. ‘How would someone question if AI is accurate if they don’t have critical thinking?’”

Nyako的要求值得玩味：他让团队不要用AI完成”需要批判性思维或问题解决”的任务。 相对于简单的支持与反对来说， Nyako用了另一种方式: 划定了一个使用边界, 让AI只干他适合干的部分。

这个边界的隐含逻辑是：某些类型的工作是技能培养的必经之路，省略这些工作就是省略技能的养成。 这与”反vibe编程”的核心主张高度一致——srs.pub的作者会说：AI可以辅助生成文档和代码，但产品主导者必须先对产品知识有完整理解，这个理解和成长的过程不能被委托给AI的。Nyako会说：某些任务必须由人来做，因为这些任务是培养判断力的载体。

Faye在引用Nyako之后还提到：关于什么是”过度使用”（overuse）已经存在证据——数据显示这些技能可以在短短几个月内萎缩和消散。这为他的担忧提供了一个时间尺度的参照：不需要几年，几个月就够。

5.1 优先级列表的反转

Faye在原文第五部分提出了一个被大多数AI布道者忽视的论点。他先描述了一个（AI出现之前的）优秀开发者的优先级 ⁴列表：

1. Understanding of the code and its relation to the codebase（对代码及其与代码库关系的理解）
2. If the code is aligned with the documented and efficient standards（代码是否与文档化的和高效的标准对齐）
3. As few lines of code as needed to accomplish the goal（用尽可能少的代码行数完成目标，同时保持可读性）
4. Turnaround time（周转时间）

然后他指出：

“Agentic coding, and LLMs in general, completely invert this list.”

这个”反转”是关键。原来的优先级是：理解 > 对齐 > 简洁 > 速度。Agentic coding带来的优先级是：速度 > 代码量 > （其余一切）。

为什么这是危险的？因为速度是一个自然的下游指标，而不是一个独立目标。一个真正理解问题、写出对齐标准且简洁代码的开发者，速度是自然的结果。但当速度被提升为直接追求的目标时，它可以通过增加代码量（而非提高质量）来实现——LLM恰恰擅长这件事：快速生成大量代码。

Faye随后的分析直击要害：

“Their capabilities and usage tend to focus on speed by increasing the amount of code that can be generated in a specified time frame. Speed is a natural byproduct of high aptitude. When it’s forced, it always leads to lower accuracy.”

这句话的逻辑是：速度是aptitude（能力、悟性）的副产品，而不是独立追求的目标。当速度被强制化——当你在组织层面以”每天生成多少行代码”或”每个sprint完成多少功能”来衡量生产力——你实际上在激励错误的行为：用更多代码来伪装速度，而不是用更好的理解来达成速度。

5.2 LLM为什么倾向于增加代码量

Faye的分析没有止步于”激励结构有问题”，他还指出了LLM本身的系统性偏向：

“The integration of these tools doesn’t tend to focus much on deeper understanding or conciseness.”

这个观察有实证基础。LLM作为语言模型，其训练目标是最可能出现在上下文中的下一个token。这个目标天然倾向于冗长、详细、全面——因为”详细的解释”在训练数据中比”简洁的解释”出现频率更高。而且，LLM没有内在的”简洁性偏好”，因为简洁性不是一个可以在统计上预测的特征。

这就产生了一个系统性偏向：当你让LLM生成代码时，它倾向于生成比你需要的更多、更冗长的代码。 这不是bug，这是训练目标的自然结果。它可以生成简洁的代码——但简洁需要额外的prompt指示，而默认行为是增加代码量。

6.1 一个Agent创建者的反叛

Faye在第六部分”Coding === Planning”中引用了一段来自Dax的访谈。Dax是OpenCode（一个开源编码agent）的创建者——这是一个coding agent的创造者，说coding agent不是编程的未来。这个身份的反差值得注意：最了解agent能做什么的人，对agent能替代什么持最谨慎的态度。

Dax的原话被Faye完整引用：

“When working on something new or something challenging, me typing out code is the process by which I figure out what we should even be doing. I have a really tough time just sitting there, writing out a giant spec on exactly how the feature should work. I like writing out types. I like writing out how some of the functions might play together. I like playing with folder structure to see what the different concepts should be. And this is all stuff that I think most people—most programmers—have always done. I don’t really see a good reason why I would stop that personally, because it’s how I figure out what to do.”

这段话的价值在于它揭示了coding和planning不是分离的活动，而是同一思维过程的不同表达。Dax说他写代码是”figure out what we should even be doing”的方式——写代码是思考的一部分，而不是思考之后的行为。

这与Faye自己在多处表达的论点形成呼应。Faye说：

“Some of us plan, and think, better with code.”

这句话的关键是”some of us”——不是所有人用代码思考，但程序员群体中相当比例的人是这样工作的。当Spec Driven Development（规范驱动开发）试图把”写规范”变成纯粹的文字活动，而把”写代码”完全委托给AI时，它实际上是在强迫一部分人用他们不擅长的方式工作——用文字精确描述他们本来通过写代码来发现的东西。

6.2 你说的不是你想要的，而LLM填入的是它猜测的

Faye紧接着提出了一个深刻的认识论观察：

“What you say is often not what you mean, and LLMs fill in ambiguity with assumptions (or hallucinations)”

这个论断的认识论含义是：自然语言从根本上不适合精确表达技术意图。 当你说”实现用户登录功能”，这句话在不同的上下文中可以意味着截然不同的东西：是用邮箱还是用户名还是手机号登录？密码有复杂度要求吗？需要支持OAuth吗？登录失败有锁定策略吗？

如果这个模糊性被人类工程师处理，他会追问。但LLM不会追问——它会假设。它会用最常见的实现模式来填充你的模糊意图，而最常见的模式不一定是适合你的模式。

Faye随后说的这句话是全文最锋利的论断之一：

“You cannot replace a deterministic system with a probabilistic one and expect zero ambiguity.”

这句话的分量需要被充分理解。它不是在说”LLM不可靠”，而是在说LLM和编译器本质上是不同的系统，你不能期待用LLM来做编译器的工作而得到编译器的确定性保证。编译器要求你的输入（代码）是精确的、符合语法规范的，它的输出是确定性的、可预测的。LLM对你的输入（自然语言）没有任何硬性要求，它会产生一个输出，但这个输出是概率性的——同样的输入可能产生不同的输出，即使产生相同的输出，它也是基于统计推断而非逻辑推理。

把一个概率系统嵌入到一个需要确定性的工程流程中，必然带来模糊性的增加。这是一个结构性的、无法通过改进模型来根本解决的问题——除非模型不再是概率模型，而那将是完全不同类型的技术。

7.1 技能锁定的维度

Faye在讨论Vendor Lock-In时，提到了Claude宕机期间整个团队陷入停滞的现象。但这篇文章中关于vendor lock-in的讨论，远不止”工具不能用怎么办”这么简单。

他提出了一个更深的担忧：

“It’s not unreasonable to play this pattern forward, where we could be creating an industry where you need to pay for token consumption to accomplish something that used to be the product of your own critical thinking and problem-solving abilities.”

注意这里的措辞：“critical thinking and problem-solving abilities”（批判性思考和解决问题的能力）。这不是在说”你的工具链需要订阅”，而是在说你的能力正在被替换成一项需要付费的服务。

这与传统的vendor lock-in有本质区别。传统的vendor lock-in是：你的业务依赖某个供应商 ⁵的数据格式或API，迁移成本很高。但技能层面的lock-in更危险——当你的团队已经失去了不依赖AI就能完成任务的能力，你实际上是在把自己的竞争力外包给了一个需要持续付费的系统。

Faye接着指出：

“The financial, and intellectual, rug-pull could come at any moment, and local LLMs are nowhere near ready to scale to absorb that level of usage.”

“Financial and intellectual rug-pull”——财务和智力的双重抽身。这句话的含义是：AI公司今天的价格是补贴性质的（“heavily subsidized”），但未来会涨价；更重要的是，你今天以为属于自己的”AI技能”实际上是依赖于云端模型的，当本地模型无法替代云端模型时，你既无法控制成本，又无法保持技能。

7.2 47%的调试技能下降

Faye引用了另一项Anthropic研究的数据：

“Anthropic study showed a precipitous 47% drop-off in debugging skills”

47%——这个数字的量级值得注意。不是17%，不是20%，而是接近一半的调试技能流失。

调试（debugging）是Faye在多处强调的核心技能。他指出，在Anthropic的研究中，调试能力是AI辅助组与纯手动编码组差距最大的模块。而这项研究显示，整个调试技能库在”激进整合AI”的工作场所中，下降了47%。

这个数字的含义不仅是”效率降低了一点”，而是”你排查问题的能力正在大幅丧失”。调试能力本质上是系统性思维的应用——你要在不知道确切原因的情况下，根据症状重建因果链条。当这种能力萎缩，你对系统的理解会越来越依赖外部的确定性来源（文档、测试、AI解释），而无法独立进行推理。

7.3 “当你说’完全agentic workflow’，模型提供商基本上拥有你”

Faye引用了Primeagen的这句话来总结vendor lock-in的最终状态：

“When you use these fully agentic workflows, the model providers essentially own you.”

“Own”在这里有双关含义：字面上是”拥有”（你被他们控制），隐喻上是”属于”（你成为他们的用户而非合作伙伴）。这个双关精准捕捉了完全拥抱agentic coding的组织将面临的处境：你不仅是他们的客户，你是在用自己的技能萎缩来喂养他们的商业模式。

8.1 一个被低估的结尾

Faye原文的最后部分”My Approach: Demote AI’s role”往往被读者当作文章的”温和收尾”而略过，但这部分实际上包含了非常具体的实践建议，远比标题暗示的更细致。

他先做了一个重要的澄清：

“I’m certainly not advocating for typing code out manually… This is why we even have Emmet, autocomplete, and snippets in the first place. Even COBOL was designed to encapsulate more instructions with less writing by using ‘English-like’ words such as MOVE and WRITE.”

这不是在反对使用工具，而是在重新定义工具的角色。从COBOL到Emmet到LLM，所有的代码生成工具都是为了让人类更高效地产出代码。Faye反对的不是更高效的代码生成，他反对的是把代码生成变成认知的替代而非认知的增强。

8.2 五步具体实践

Faye随后列出了自己的具体工作流，精确到可操作：

第一步：用LLM辅助生成规范和计划，但自己主导实现

“I use LLMs to help generate specs and plans, while I facilitate the implementation. This is an inversion of the ‘orchestration’ workflow; I am still manually coding anywhere from 20% to 100%, depending on the task.”

注意”20% to 100%“这个范围——Faye没有说”永远自己写核心代码”，而是说根据任务调整。他保留了灵活性，但始终处于”主导”位置，AI是辅助。

第二步：经常自己写伪代码

“I very often am writing pseudo-code when I do engage with the models, closing the distance between the request and the generated code.”

“Closing the distance”——弥合请求与生成代码之间的距离。这是伪代码的核心价值：它把你的意图翻译成更接近代码的形式语言，减少LLM填充假设的空间。

第三步：用AI做临时委托、交互式文档和研究工具

“I use the models as delegation utilities for ad-hoc code generation and interactive documentation, as well as research tools so that I can constantly ask questions, iterate, refactor, and gain clarity around my approaches.”

这里的关键是”interactive”——交互式文档意味着你在对话中不断澄清，而不是一次性给出模糊指令。

第四步：永远不超过一所能review的量

“I never generate more than I can review in a sitting. If it’s too much to review, I slow down and split the task up, manually refactoring where needed to ensure a comprehensive understanding of the end result.”

这个规则触及了Agentic coding最核心的悖论：生成速度受限于审查速度。 如果你让AI生成了你无法在一小时内审查完的代码，你实际上已经放弃了审查——而放弃了审查，你就放弃了理解。

第五步：从不委托从未做过的事

“I never ask an LLM or agent to implement something that I’ve never done before or couldn’t do on my own, except perhaps purely for educational or tutorial purposes (and often discarded afterwards).”

这条规则的重要性在于它直接回应了”监督悖论”：如果你对某个领域完全陌生，你就无法有效监督AI在该领域的输出。 这不是保守主义，这是能力边界的诚实认知。

8.3 像企业号电脑一样用AI，别像Data一样

Faye用《星际迷航》的比喻来总结他的处方。这个比喻的精确含义值得拆解：

• Data是《星际迷航：下一代》中的仿生人角色，他拥有完全自主的智能，可以独立执行复杂任务，但他的”人性”始终是一个被探索的主题——他努力理解人类情感，却始终与人类不同
• 企业号电脑（Ship’s Computer）是星舰上的辅助系统，它可以提供信息、执行计算、在授权范围内操作设备，但它永远在船长的指挥下运作

Faye的意思是：把AI当作信息工具和执行工具，而不是自主行动者。 企业号电脑可以运行扫描、计算轨道、显示传感器数据，但它不能代替船长做战略决策。AI可以生成代码、解释概念、提供建议，但它不能代替开发者做架构判断。

这个比喻的隐含假设是：架构判断是一种需要持续锻炼的能力，不是可以委托给AI的”高级活动”。 如果你把架构判断也委托给AI，你就不再是船长，而是乘客。

10.1 两种处方的局限

到目前为止，我们追踪了Faye的核心论点和他自己的处方。现在我们需要审视这个处方与mpt.solutions的”外化监督”方案之间的关系，并指出它们的共同盲点。

Faye处方的优势在于它的个人实践性——五个具体的规则可以直接执行。但它的局限也很明显：它依赖于个体的自律和判断，而没有提供系统性的支撑结构。 当一个团队中的每个人都”决定”按Faye的方式使用AI时，实际上没有任何机制保证他们这样做。Faye的处方更像是个人最佳实践的清单，而非组织层面的解决方案。

mpt.solutions的”外化监督”方案——测试、类型系统、lint、hooks、代码审查——则提供了系统性的支撑结构。它的核心主张是：把监督从脑子里搬到不会萎缩的地方。 这个主张与Faye的担忧形成了完美的互补——Faye说”脑子里的能力会萎缩”，mpt.solutions说”那就搬到artifact里”。

但mpt.solutions的方案有一个隐含的假设：监督的标准已经存在于脑子里，只需要外化。 如果脑子里根本没有清晰的标准——如果团队不确定”好的代码”到底长什么样——那么外化的测试和lint只能防止”变得更错”，而无法保证”走在正确的方向上”。

10.2 “反vibe编程”的洞察

srs.pub”反vibe编程”的思想恰恰指向了这个盲点。它的核心主张是：

“氛围编程是不切实际的空想，不能靠’一句话让AI给你干好活’。”

这不是在说”AI没用”，而是在说”AI的有效使用有前提”。反vibe编程的框架包含三个要素：

第一，成长：产品主导者必须随着产品发展不断接收新知识，否则产品停留在模糊阶段。

第二，知识：AI编程的首要任务不是编程，而是先构建完整的产品知识。这里的”知识”不是API文档或技术规格，而是对产品愿景、用户需求、业务逻辑、架构约束的完整理解。

第三，AI：只有在前两步完成后，才是让AI辅助生成文档和代码。

反vibe编程最核心的论断是：

“构建产品，我们将失去知识和产品。构建知识，我们将得到知识和产品，还有成长。”

这个论断揭示了Agentic coding陷阱的真正本质。当你跳过知识构建直接委托实现，你同时失去了两样东西：对产品的真正理解，以及高质量的产品本身。 因为没有知识锚定的委托，本质上是在让AI用假设填充模糊地带，而假设会累积成幻觉。

10.3 知识 ≠ 代码审查 ≠ 测试覆盖

这里需要做一个精确的概念区分，因为这是整个论证的核心：

• 代码审查是验证性活动——它检查”这段代码对吗？”
• 测试覆盖是验证性活动——它验证”这个功能按预期工作吗？”
• 知识构建是指导性活动——它回答”这个系统应该做什么、为什么这样做、什么情况下不这样做？”

mpt.solutions的方案是强大的验证性artifact——测试fail了告诉你代码有问题，lint warning了告诉你格式不规范，类型检查failed了告诉你数据结构不对。但它们无法告诉你”系统应该做什么”。如果你的产品知识本身就是错的（你对用户需求的理解有偏差、你对架构选择的判断有误），验证性artifact只能在错误的方向上验证错误的实现。

产品知识文档（WORKFLOW.md、需求规格、设计文档）恰恰是把监督从脑子里搬出来的最有效的artifact——但它是”指导性”的，而非”验证性”的。 它不仅告诉你什么错了，它告诉AI什么是对的。它的价值在于：在代码生成之前，它就为AI提供了清晰的上下文，减少了LLM需要填充的假设空间。

10.4 认知债务的真正根源

回到Faye提出的”认知债务”概念。以知识为核心的视角提供了一种更精确的诊断：

认知债务的本质不是”代码看不过来”，而是”知识没有在人与AI之间建立共同的锚点”。

当你向AI描述一个需求，你使用的是你的语言、你脑海中的画面、你理解的业务逻辑。AI听到的却是它训练数据中与此相关的代码模式、最常见的实现方式、最可能”看起来正确”的解决方案。这两个理解之间的差距，就是Faye所说的”错位鸿沟”的本质。

产品知识文档的作用是：在”你的理解”和”AI的推测”之间建立一个共同的参照系。 当AI的输出与产品知识文档一致时，你知道它在正确的轨道上；当它偏离时，你可以立即识别并纠正。这个”锚点”是认知债务的解药——不是因为你看了更多代码，而是因为你和AI在说同一种语言。

10.5 与mpt.solutions的呼应与超越

mpt.solutions的核心主张——把监督从脑子里搬到artifact里——在这个框架下获得了新的意义。测试、lint、类型系统都是验证性artifact，它们的共同特征是：当系统行为偏离预期时，它们会告诉你。

但”验证性artifact”的前提是”预期”本身是正确的。如果产品知识文档（指导性artifact）本身就是错的，验证性artifact只能在错误的方向上验证错误的实现。因此：

正确的优先级是：先构建指导性知识（产品文档），再建立验证性规则（测试/lint/类型），最后委托AI执行。

这个优先级与Anthropic研究中高分区使用模式（65%+得分）的特征完全一致：追问”为什么这样设计”是在澄清指导性知识；要求详细注释和逻辑说明是在建立验证性规则；核心代码自己手写是在确保自己始终保持对知识的控制。

11.1 第一步：构建产品知识（AI辅助生成，人工逐字审核）

产品知识的内容应包括：

• 愿景文档：产品解决什么问题、为什么这个问题重要、成功的标准是什么
• 用户故事 ⁶与场景：谁在什么情况下使用这个功能，他们期望得到什么
• 架构决策记录（ADR）：为什么选择这种架构、有什么备选方案、被否决的方案为什么不行
• 设计规范：命名约定、模块边界、错误处理原则、可观测性要求

关键原则：AI可以辅助生成这些文档的初稿，但每一句话都必须经过人工审核。审核不是检查语法，而是重新确认”这个理解准确吗？这个决策有道理吗？“这个过程本身就是知识构建——它迫使产品主导者将模糊的直觉转化为清晰的表述，而表述的过程就是理解深化的过程。

11.2 第二步：外化监督机制（测试、类型、lint、hooks）

在知识层建立之后，将知识转化为具体的验证规则：

• 测试：根据知识文档中定义的契约编写测试，不是追求覆盖率数字，而是确保核心逻辑的正确性被持续验证
• 类型系统：将业务约束编码为类型系统规则，让编译器成为第一道守门员
• Lint与hooks：将知识文档中的设计原则转化为lint规则，例如命名规范、错误处理模式、安全要求
• CI/CD门禁：将以上所有规则集成到持续集成流程中，确保任何代码变更都经过验证

这一步骤与mpt.solutions的方案高度一致，但关键区别在于：这些规则的来源是第一步构建的产品知识，而不是开发者的个人偏好或临时决定。

11.3 第三步：有限委托AI编码（在有知识和监督的框架内）

现在，可以开始让AI参与编码了——但必须是有边界的委托：

• 委托边界：根据知识文档中定义的系统边界，确定哪些部分可以委托给AI、哪些必须由人亲自处理。一般原则是：核心业务逻辑、高风险操作（支付、安全）、架构决策相关的代码，应该保留在人工编写或至少人工审核的范围内
• Prompt工程：向AI提供的prompt必须包含知识文档中的关键约束——不只是”做什么”，更要”为什么这样做”和”什么情况下不这样做”
• 逐次验证：AI生成的每段代码，都应在运行测试和lint之前进行人工review——不是逐行检查语法，而是确认”这段代码的逻辑符合知识文档的描述吗”

11.4 第四步：持续迭代（每次修正先回到知识层）

当bug出现或需求变更 ⁷时，不要直接让AI修改代码然后通过测试就算完事：

• 回到知识层：先问”知识文档需要更新吗？“——如果bug的根源是知识文档的遗漏或错误，这就是补充的机会
• 更新知识：修改知识文档，确保新的理解被准确记录
• 更新验证：相应地更新测试、lint、类型规则
• 最后改代码：带着更新后的知识和验证规则，再让AI修改代码

这个顺序——知识 → 验证 → 代码——与直觉相反但极其重要。它确保每次迭代都是在深化理解而非仅仅修复症状。

11.5 一个验收测试

mpt.solutions提出了一个检验系统是否健康的好问题，可以直接拿来作为这个框架的验收标准 ⁸：

离开三周。Agent在这三周里仅靠repo、tests、lint、hooks、mistake log和review process工作。回来后，这个代码库是你能defend的状态吗？

如果答案是”不能”，说明知识层或验证层还有缺口。如果答案是”能”，说明知识、验证和代码三层已经形成了有效的闭环。