“氛围编码”的宿醉
灵感袭来。你有个点子，而且确切知道该怎么做。你启动了最喜欢的 AI 编码智能体 (AI coding agent)，输入那些提示词，然后把工作交给它。嘿，看它跑得多快。
它完成了。或者说，是你完成了。App 能用了。这就是 10 倍速工程师的真实感受。你是个天才，是 AI 革命中的叛逆者。
但周一到了。你想加个功能或者改改它的工作方式，却发现你根本看不懂。你没法维护它，最后不得不把大部分甚至全部代码扔掉。
“氛围编码” (Vibe coding) 是一种低规格、零规划的 AI 加速开发方法，虽然感觉上效率很高，但结果往往是脆弱、不可维护的“演示级废品” (demo wear)。所谓的“宿醉”，就是当你试图用这种方式构建可维护、可理解的软件时所产生的绝望感。
简介
不过别担心，有药可救，这就是我们要讨论的使用 AI 编码智能体进行构建的框架。
如果你将编程视为日常的学习体验；如果你希望像对待自己编写的其他软件一样，理解并掌控使用 AI 编码智能体编写的软件；如果你想做编码智能体的老板而不是它们困惑的实习生；如果现在的智能体工作让你感觉自己只是个“提示词操作员” (prompt jockey) 而不再是 AI 工程师；如果你厌倦了扔掉代码、浪费时间和 Token，或者你想用编码智能体构建真正能干活的生产级应用，那么你会喜欢这个演讲。
另一方面，这不适合你，Jen。这不适合你，Jen。如果编程对你来说只是一份工作而不是一门你需要精进的手艺；如果你满足于让 AI 为你做这件事而不需要理解原理；或者如果“氛围编码”已经能满足你的需求，那这也不适合你。这些声明不是评判，只是我们今天走的路非常不同。
我是 Corey。我经营着一家 AI 原生控股公司，我们积极在技术、投资和教育垂直领域收购和建立业务。自 2022 年以来，我一直狂热地构建 AI 编码智能体。我热爱并热衷于所有技术事物。
我是个超级咖啡迷。实际上，如果在走廊遇到我，可以问问我最近痴迷烘焙的 Misty Valley 埃塞俄比亚耶加雪菲咖啡。我也是个匹克球 (pickleball) 狂热者。明天我甚至还要参加一场比赛。
框架 - 概览
让我们概览一下这个框架。该框架由三大支柱组成：原则 (Principles)，这是支撑一切的哲学；流程 (Process)，这是使用 AI 实际构建软件的工作流；以及工具 (Tools)，它们是流程的加速器或推动者，同时也反映了我们的原则。
你可能会问，用这个框架能构建什么？答案是任何东西。该框架适用于所有类型的软件，目前现实世界中已有几个使用此方法构建的案例：律师事务所的专业诉讼支持应用、烹饪用的实时设备监控包、动态内容重构的数字出版系统等等。
重点在于，这些不是玩具。这些是每天都在处理实际工作的真实软件应用。关键是，它们是由应用此框架的 AI 工程师进行演进和维护的。
原则
让我们开始进入原则部分。原则大致分为三类：适用性广泛的总体原则、偏向流程规划阶段的原则，以及偏向流程实施阶段的原则。总共 10 条。让我们逐一讨论。
我们的第一条总体原则是：AI 工程是加速学习。这源于什么问题？将 AI 编码智能体仅仅视为提高代码产出的生产力工具；使用 AI 生成软件却不从过程中学习。结果六个月后，作为工程师毫无进步，甚至在调试、修改、架构决策等方面对 AI 产生了依赖。这与 AI 增强 (AI augmentation) 背道而驰，这是 AI 依赖。
这里的核心理念是，框架不仅是为了构建得更快，更是为了在构建过程中学习。框架中的每一步都创造了特定的学习机会，这样你不仅是在发布软件，也是在构建你自己。软件有价值，但你成长为更优秀的工程师价值呈指数级增长。这就是为什么我们说：始终保持学习 (Always be learning)。
下一条总体原则是：你是架构师，智能体是实施者。将 AI 智能体视为架构思维的替代品，而不是在你明确指定后的实施者，这是个大问题。这里的主要理念是保持架构师和实施者的界限清晰。
你负责思考，这意味着架构、接口、系统意图、结构、设计决策以及相关的权衡。然后智能体负责做事。这就是实施：敲代码、遵循模式、实施你指定的测试、处理样板代码。这就是为什么我们说：委托执行，不要委托思考。
第三条总体原则有点反直觉：慢下来迭代，为了快起来。问题在于推倒重来的循环。如果没有对已验证的工作进行刻意迭代，你最终会反复从零开始。三个月后，你会有多个废弃的尝试，而不是在一个系统上持续改进。
核心理念是，刻意迭代能在理解和生产力上带来复利回报。所以是的，第一周感觉很慢，但第二周建立了势能，第三周就会显著加快。我们称之为：复利进步，加速周转。
规划相关的第一条原则是：规格说明远重于提示工程。提示工程将 AI 交互视为优化问题，而不是沟通问题。试图寻找能产生正确输出的魔法词汇，而不是清晰定义什么是“正确”。
核心理念是，规格说明 (Specifications) 与传统意义上的提示词截然不同。规格说明是对需求、行为、接口和验收标准的结构化、精确定义。编写规格说明迫使你进行架构思考。你必须完全理解问题，然后精确定义接口并预判边缘情况。反过来，规格说明提供了清晰、明确的指导。智能体实施你指定的内容，而不是它从对话提示中推断的内容。我们说：编写蓝图，而不是提示词。
下一条规划原则是：在实施前定义“完成”。如果没有可执行的测试和可观察的成功标准就开始实施，意味着智能体缺乏明确的完成标准和即时反馈。它们无法自我验证，无法自我纠正，也不知道什么时候算做完了——至少是不符合你规格说明的一致性。
核心理念是，在实施前定义“完成”能让你深入思考需求，并使智能体能够自主工作。通过预先定义测试，我们赋予智能体明确的停止条件，使其能够在实施过程中获得即时反馈并在必要时自我纠正。稍后我们会详细讨论多感官验证。但我们要让智能体通过视觉（渲染效果）、听觉（日志和错误）和触觉（如何与系统交互）进行观察。
测试验证规格实施的正确性，而传感器揭示软件在实施过程中的实际行为。“完成”意味着当测试通过且传感器验证一切按预期工作时，功能才算完成。我们说：先指定成功，再进行构建。
功能原子性是下一条原则。编写非原子性的功能意味着将拆解工作留到实施阶段，迫使智能体临时做出架构决策。这里的主要理念是，功能原子性迫使我们在规格说明阶段完全分解每个功能，进而使智能体能在可控范围内进行实施。
在这个意义上，功能变成了实施工作单元。它们是原子的、不可简化的任务，准备好让智能体完全执行。将功能尽可能保持细小，以使智能体实施尽可能成功。我们说：缩减直到不可缩减。
最后一条规划原则是：依赖驱动开发。在没有显式依赖分析的情况下进行实施，意味着将所有功能视为独立的，而事实上我们知道它们形成了一个相互连接的图。核心理念是，依赖驱动开发迫使你了解功能如何关联以及如何集成，进而确保智能体永远不会实施依赖于未完成工作的功能。我们说：按依赖关系安排实施。
现在进入实施相关原则。首先是：一次实施一个原子功能。同时处理多个功能将实施视为可以自由切换上下文的并行工作流。但我们知道，实施质量取决于持续的专注、完整的上下文和非常紧密的反馈循环。在功能之间跳跃会分散我们的注意力。
核心理念是，智能体实施一个已定义为原子级的功能。你研究它、理解它。你验证它是否工作。你将其作为检查点提交，然后继续下一个功能。这种节奏既创造了势能，也加深了理解。我们停止同时玩弄多个功能。我们全神贯注地按顺序实施功能，研究每个实施以保持理解，然后提交每一个作为检查点，以构建可工作的软件和工程知识。我们说：完成一个，提交一个，继续下一个。
下一条实施原则是：上下文工程与管理。将上下文视为自动发生的事情，而不是你主动设计的东西，是一个大问题。任由对话历史被动积累，而不是主动策划对上下文真正重要的内容。如果你不构建上下文弹性，状态最终无法持久，我们就会失去弹性和连续性。
主要理念是，不要依赖对话状态的持久性。将架构决策捕捉在持久文档中，如规格说明、计划和设计文档——我们在流程部分会讨论这些含义——然后从这些工件中构建上下文，而不是从你的记忆中。我们说：策划上下文，不要堆积它。
最后一条原则是：让它工作，让它正确，让它快起来。这是借鉴自软件工程史的经典名言。但一开始就将这三个阶段视为同等重要，或者试图同时实现它们，是个大问题。该框架专注于“让它工作”：可以发布和使用的可工作软件。只有在实际使用揭示了什么最重要之后，我们才选择性地投资于“让它正确”和“让它快起来”。
核心理念是，停止在前期追求优雅和性能。明确指示智能体“让它工作”，我们会讨论如何定义这一点。我们需要通过测试的简单、功能性实施，使我们能快速发布，然后让实际使用来揭示哪里值得进一步投资。我们说：构建，学习，改进。
这就是我们的 10 条原则，让框架运作的哲学。现在让我们回头看看那位宿醉的“氛围编码者”，看看他在接触了框架原则后的反应。是的，脑洞大开了吧？坚持住，伙计，后面还有更精彩的。
流程 - 概览
好的，现在我们转到流程部分。流程是我们应用所有原则的地方。你可以将其视为行动中的原则。
框架流程有两个截然不同的阶段。规划阶段 (Planning phase)，你在这里进行所有架构思考以定义要构建什么；以及实施阶段 (Implementation phase)，智能体在这里在你的监督和验证下执行你的规格说明。规划产生使智能体能自主实施的工件。实施则使用这些工件逐个功能地构建可工作的软件。
流程 - 规划
好的，进入规划阶段。规划是你完成架构思考的地方。你将模糊的项目想法转化为原子的、排序的、完全指定的可实施功能。这纯粹是你的工作：架构决策、分解、编写规格说明、依赖分析。智能体可以作为思考伙伴协助，但每一个决定都由你来做。
五个规划步骤是循序渐进且相互构建的：愿景、功能、规格说明、依赖关系、计划。你会注意到这是一个高度迭代的过程，将思考提取并提炼为可用于与智能体构建软件的有形工件。规划阶段每一步的输入和输出分别是模板和已完成的模板。我们预先做了大量工作，创建了深思熟虑、结构良好的模板，既能引导思考又能捕捉结果。
规划的第一步是愿景捕捉 (Vision Capture)。这一步的目的是将你模糊的项目想法转化为完整、结构化的“主项目规格说明书” (Master Project Specification)，清晰阐述问题、用户、功能、范围和工作流。
这一步解决的问题是，你的初始想法通常只存在于你的脑海中，而且是不完整的。刚开始时通常都是这样。你对问题和方法有个大概的感觉，但细节模糊，隐含假设未经检验，关键方面缺乏信息。如果没有结构化的探索和提炼，你就无法传达你的想法，无法清晰表达需求，也无法创建一个智能体可以构建的共享基础。你需要先审视并提炼你的思考，才能将其分解为功能或架构。
所以我们要做的就是与智能体一起“出声思考”——这是可选的，但强烈推荐——通过五个部分来提炼和捕捉你的愿景。项目目的：澄清你要解决的问题、谁在经历这个问题以及软件提供的核心价值。核心功能：确定解决该问题的三到五个基本工作流。范围边界：做出明确决定。我们称之为“现在做与以后做” (Now not next)。“现在做”意味着必须有才能让“让它工作”版本运行起来。“以后做”意味着超出范围和未来的增强。
然后是技术背景：回答基本问题，如它在哪里运行、用户如何交互、连接到什么系统。最后是工作流细节：针对那三到五个核心工作流，记录目标、高层级步骤以及预期结果。我们会迭代这些部分，直到你的愿景清晰完整。
在这里与智能体合作非常棒，因为它可以帮助发现漏洞、建议边缘情况并探究假设。但关键是，你对愿景做出所有决定。这一步的主要输出是主项目规格说明书 (MPS)。这是一个结构化的工件，捕捉了你对“让它工作”版本软件的完整愿景。这成为规划第二步中提取功能的基础。你看左下角，可以看到该步骤应用了哪些原则。我们不会逐一讨论原则，但这展示了框架的内聚性。
规划的第二步是功能识别与分类。这一步的目的是从主项目规格说明书中系统地提取所有功能单元，并将它们组织成一个分类的功能清单 (Feature Inventory)。
这一步解决的问题是，你不能直接从高层级愿景跳到详细的功能规格说明。这个跨度太大了。你的 MPS 捕捉了软件在高层级做什么，但你需要一个中间步骤，将这种思考逐步细化为具体的可管理功能单元。如果没有系统的提取和分类，你就是在没有完整构建清单的情况下试图指定功能，你也看不到自然的分组和关系。你缺乏下一步细化所需的结构化工件，被迫将所有功能记在脑子里，而不是将其外化以便分析。
这一步的输入是上一步的 MPS。所以我们要做的就是系统地分析 MPS，提取所有功能单元然后进行分类。针对 MPS 的每一部分使用针对性的提取问题进行梳理。比如针对项目目的，该系统需要什么基础能力？针对核心功能，每个工作流需要什么离散能力？针对范围边界，需要什么基础设施来让“让它工作”版本运行？针对技术背景，需要什么平台集成和接口功能？针对每个关键工作流，什么处理输入、发生什么处理、有什么输出、我们应预判哪些错误以及如何反馈？然后是跨领域需求：什么安全、日志、配置和测试功能跨越整个系统？
我们要记录每个功能的来源以便追溯。接下来，建立原始功能列表。捕捉你识别的每一个能力，但暂时不组织它们。确保提取全面。我们要挑战完整性，问像“什么处理错误”或“什么验证输入”这样的问题。
接下来我们分析这些功能。分析整个功能列表，根据你的功能和项目类型识别自然分组。识别出反映你特定软件结构的 3 到 7 个类别。然后进行分类。确定类别，将每个功能分配到最合适的类别，并创建一个唯一的功能 ID，例如 Core 001 或 API 101。这些类别源于分析你的实际功能，而不是预定的分类模板。
最后，我们估算功能复杂性。这只是对每个提取功能的复杂程度的初步估计。简单、中等还是困难？这一步的输出是功能清单。它是所有离散功能单元的完整、分类列表。每个功能包括唯一 ID、描述、复杂性估计，并且我们可以将其追溯回 MPS 中的来源部分。
第三步是迭代式规格说明开发。这一步的目的是将功能清单中的每个功能转化为完整的、原子的、可实施的规格说明，确切定义需要构建什么、如何验证以及它依赖什么。
这个关键步骤解决的问题是，你不能直接从功能清单跳到功能实施。这同样跨度太大。你的功能清单列出了离散的能力，但每个功能仍需要在编码智能体实施之前被完全指定。如果没有迭代式规格说明开发，你给编码智能体的就是高层级描述，并指望它们能正确推断细节。在尝试指定功能之前，你无法验证功能是否真正原子化。你没有系统的方法来识别依赖关系。你缺乏使智能体能自主工作的实施蓝图。最终，你依赖的是提示工程而不是全面的规格说明。
这一步的输入是上一步的功能清单。我们要做的就是与智能体协作，使用三级细化模式转化每个功能。首先，我们起草一个典型的用户故事：作为一个[用户类型]，我想[执行操作]，以便[获得利益]。这捕捉了谁需要这个、他们在做什么以及为什么重要。
接下来我们确定实施契约 (Implementation contracts)，这存在于三个迭代的细化层级中。我们从第一级普通英语开始。用自然语言描述功能做什么。梳理发生了什么、接收了什么、做了什么以及产生了什么。
然后我们将其进一步细化到第二级，即逻辑流。有点像输入、逻辑、输出。我们将描述转化为结构化的伪代码，包含清晰的输入、逐步逻辑和定义的输出。这迫使我们对进什么、发生什么、出什么非常清晰。
然后我们进一步细化到第三级，即形式化接口。在这里我们定义并形式化具有确切签名、数据结构和 API 规范的契约。我们定义每个组件的确切输入类型、返回类型和错误。
接下来我们转到指定验证契约。同样，我们分三个层级进行。第一级也是普通英语。描述场景，识别所有需要验证的情况：快乐路径、错误案例、边缘情况、安全属性。然后我们将其细化到第二级，即测试逻辑，我们使用“给定-当-那么” (given-when-then) 结构。我们将每个场景转化为包含设置、触发和预期结果的结构化验证逻辑。
我们进一步将其细化到第三级，即形式化测试定义。这是我们定义确切测试接口的地方，包括设置、输入、精确断言和任何清理工作。
此时，我们需要验证功能的原子性。我们需要确保该功能可以在单个专注的会话中实施，并且它确实是一个原子功能。如果此时感觉规格说明很分散，或者它定义/描述了多种能力，我们要将该功能拆分为多个功能，然后重复该过程。
最后，在我们确定功能是原子的之后，我们要识别依赖关系。现在我们要真正确定在这个功能实施之前必须存在哪些其他功能。我们记录显式的二进制依赖，意味着这要么依赖另一个功能，要么不依赖。没有部分依赖。
这一步的输出是功能清单中每个功能的完整原子功能规格说明书。该规格说明定义了用户故事、技术蓝图（同样由那三个层级组成）、验证策略及其三个层级、所有依赖关系以及任何实施说明。
规划流程的第四步是依赖分析。这里的目的是将你全套的功能规格说明转化为经过验证的依赖矩阵，该矩阵将定义功能实施的确切顺序。这能消除循环依赖并揭示自然的实施阶段。
这一步解决的问题有好几个：你的功能规格说明包含准确的依赖声明，但这些依赖分散在各个文档中。所以你有局部视图，比如功能 X 依赖功能 Y，但我们还没有全局视图。如果没有合成到依赖矩阵中的全局视图，你就无法看到完整的依赖图，无法检测跨越多个功能的循环依赖，无法识别可以一起构建的功能组的自然实施阶段，也无法确定哪些功能必须先实施，哪些可以等待。
这一步的输入是上一步带有依赖声明的功能规格说明。所以我们要做的就是将分散的依赖声明合成为一个统一的矩阵，然后进行验证。
我们首先提取矩阵。收集单个功能规格说明中的所有依赖关系到一个可视化网格中。每一行是一个功能，每一列也是一个功能。然后我们逐行检查，如果行功能依赖于列功能，就标记一个 X。
接下来生成图表。我们使用 Graphviz 或 Mermaid 等工具从矩阵创建一个可视化图表，将功能显示为节点，依赖关系显示为边。图表使循环依赖作为闭环立即显现，并揭示应用程序依赖的自然分层结构。
接下来我们验证和清理。我们对每个标记的依赖应用二进制依赖测试，大概是这样：行功能是否需要列功能的特定输出配置或功能才能工作？如果是，那就是依赖。如果不是，就移除它。我们会跟踪矩阵中的更改。可能是技术依赖，这有助于我们要澄清一些事情，比如可能只是协调或工具共享，不是真正的硬性形式依赖。
然后我们进入下一步。重新生成图表，我们要这样迭代。最后，检测循环。我们要直观地检查图表——智能体也可以帮我们做这个——寻找循环依赖。如果发现它们，我们在四个（其实是三个）步骤中应用解决策略。首先，尝试消除依赖，即回过头用二进制测试重新检查。如果不行，尝试修改规格说明。我们可以修改接口或重新思考契约，使功能不需要彼此的输出。第三，尝试功能拆分。试着再次拆分它，也许这个功能不是原子的。最后是作为最后手段的合并，这会很乱，但我们今天不会过多讨论这个。
每次循环后我们都会迭代。更新矩阵，重新生成图表，重新检查循环依赖，直到归零。这一步的输出有两样：经过验证的依赖矩阵，也就是我们的可视化网格，显示完整的依赖图，所有循环依赖已解决，所有依赖已验证为技术上必要，且清晰定义了实施层级；以及依赖图，这是一个将功能显示为节点、依赖关系显示为边的可视化图表，使结构和层级立即显现。
规划阶段的第五步也是最后一步是实施计划开发。目的是将你验证过的依赖矩阵转化为全面的、分阶段组织的实施路线图，将功能按依赖层级排序，识别并行开发机会，定义阶段完成标准，并建立启用实施循环的验证策略。
这一步解决的问题是，如果没有全面的实施计划，你将面临实施混乱。尽管有完整的规格说明和验证过的依赖矩阵，你无法回答哪些功能应该先实施以及按什么顺序，哪些可以并行开发——我们要跳过这部分但这是可行的加速器——如何验证一组功能在继续之前是否协同工作，以及何时可以安全地开始实施依赖于早期工作的功能。
这一步的输入是第四步验证过的依赖矩阵和依赖图。所以我们要做的就是将依赖矩阵转化为可执行的实施策略。
首先通过拓扑排序组织实施阶段。我们将功能根据其在依赖图中的深度组织成实施阶段。没有依赖的功能成为第一阶段。仅依赖第一阶段的功能成为第二阶段。我们继续这种模式，创建每个阶段仅依赖先前阶段的阶段。然后我们验证同一阶段内的功能互不依赖。最后我们识别关键路径，即最长的依赖链。
接下来是并行分析，我们今天跳过这个。接下来是验证策略规划。针对每个阶段，我们定义二进制成功标准。必须通过什么测试，必须工作什么集成点，如何验证功能协同工作。然后我们建立反馈循环，启用自主智能体细化和二进制进度跟踪。功能实施了还是没实施？没有“实施了 20%”这种说法。思考当功能组合时可能出什么错，以及什么验证能为后续阶段的依赖功能提供信心。
最后我们转到实施排序。这是我们定义完整执行策略的地方。我们有阶段关卡 (Phase gates)，意思是我们如何确定已准备好并完全实施了一个给定阶段并准备好进入下一个。我们有针对智能体的任务分配指导。我们需要告诉它们如何选择下一个要处理的功能。如果遇到阻塞，我们有阻塞管理流程，解释它们如何处理和解决这些阻塞。最后，我们定义进度跟踪机制。这些是在功能级别、阶段级别以及监控关键路径。
这一步的输出是实施计划。这是一个全面的、分阶段组织的执行策略，将所有功能按依赖层级排序，识别并行开发机会，为每个阶段制定二进制验证关卡，并为自主智能体实施会话提供所需的指导。
流程 - 实施
好的。至此，我们准备好谈论实施循环了。实施是你的规划工件指导将规格说明转化为可工作、经过测试的软件的地方。与规划不同，规划是线性的并经历五个不同的步骤，实施是一个针对每个原子功能重复执行的紧密快速循环。
不过在深入之前，我们需要理解和拆解多感官反馈循环。这是框架中的一个真正关键的理念。智能体实施代码，然后执行它，同时通过这些数字感官收集反馈。视觉感官，你可以将其视为渲染了什么。听觉感官，系统报告了什么。触觉感官，交互如何响应。这种感官反馈提供了关于应用程序中实际发生了什么的丰富诊断信息。
智能体运行形式化测试以验证验收标准。但通过将感官反馈与测试结果关联，智能体既能从测试中理解什么失败了，也能从传感器中理解为什么失败。这个循环持续进行，直到所有验收标准通过且所有传感器报告执行干净。
实施循环的第一步是上下文组装。这里的目的是将规划工件转化为精选的上下文包，使自主功能实施能在一个单一的编码会话中完成。
这一步解决的问题是，你有原子功能被完全指定并排序，但你不能把所有东西都扔给智能体并指望它搞清楚该做什么。如果没有系统的上下文组装，你就是在把整个规划文档倾倒进智能体会话中，这会在无关信息上浪费上下文窗口。这通常导致智能体在没有关键上下文的情况下做出决定，并且没有你——或者频率较低地——停下来寻求指导。最终，这把本应相对自主的实施会话变成了不断的来回拉扯。它浪费上下文窗口并导致验证缺口。
上下文组装的输入是实施计划——同样，仅限与将要实施的特定原子功能相关的部分——功能规格说明，以及该规格说明中引用的所有依赖。我们要做的就是通过四个步骤为这一个原子功能策划确切所需的信息。
我们从功能规格组装开始。这里我们包含完整的功能规格说明。你还记得那包括用户故事、技术契约、验收标准，并且我们使用 @ 符号引用所有依赖关系。这是智能体将遵循的主要蓝图。
下一步是依赖上下文收集。我们跟随功能规格说明中的所有 @ 引用。每个 @ 引用指向一个依赖功能规格说明和实际实施的代码。这点至关重要，因为根据框架定义，所有依赖必须已在之前实施。所以这既是规格也是代码。我们将这些拉进来，以便智能体确切了解它需要集成什么。
接下来我们转到实施指导。这是我们从实施计划中提取相关部分的地方。我们不只是把整个实施计划扔进去。智能体需要知道诸如该功能处于哪个阶段、阶段完成标准是什么、该阶段的验证策略是什么。我们只引入为该功能实施及其验证提供背景的部分。
最后，我们启用感官能力。我们阅读功能的验收标准以识别需要哪些数字传感器。像“看到”、“显示”、“渲染”这样的视觉验证语言需要视觉感官工具。日志或错误语言需要听觉感官工具。像“点击”、“提交”、“完成”这样的交互语言需要触觉感官工具。所以我们将 @ 引用我们编写的相应工具使用指南——顺便说一句，我们在工具部分会讨论这个，每个工具只需编写一次，以便在所有功能中复用——这样智能体就知道如何收集所需的感官反馈。
这一步的输出是精选上下文包。这是智能体所需内容的专注集合：功能规格说明、该功能集成的任何和所有功能的依赖代码、相关实施指导以及用于验证的感官工具说明。
现在我们终于到了这里。请注意，这是整个框架中唯一步骤是“AI 写代码”的地方。现在我们进入实施循环，这是实施的最后一步。目的是将原子功能规格说明转化为可工作的、经过测试的代码。
这解决了一组特定的问题。如果没有结构化的实施，智能体要么在测试任何东西之前编写所有代码，这会积累复利式的问题；要么它们在没有系统反馈的情况下临时编写和测试，这使改进有点像猜谜游戏。“写完再测试”的方法会失败，因为问题积累未被发现，最终你同时在调试多个相互关联的问题。“临时”方法会失败，因为没有全面的感官反馈，你会错过测试没捕捉到的问题。例如，测试通过了，但 UI 渲染不正确，或者工作流完成了但错误填满了日志。功能“能用”，但用户交互是坏的。
这一步通过单一的多感官实施循环解决了所有这些问题，因为功能是原子的。完整的实施适合一个上下文窗口。智能体从头到尾保持完全理解。没有上下文丢失，没有重建，没有保真度下降。
实施循环的输入是之前组装的上下文包。我们要做的就是执行紧密的多感官反馈循环，首先是编写代码。智能体遵循功能规格说明的技术契约实施代码。它将所有三个层级的契约转化为工作代码，确保接口、输入、输出和错误处理与规格说明完全匹配。
然后我们转到执行和感知。这是我们获得全面数字反馈的地方。智能体立即执行已编写的代码，并根据验收标准要求，通过三个数字传感器收集全面的感官反馈。我们已经讨论了起作用的视觉、听觉和触觉感官。智能体捕捉关于执行期间实际发生了什么的丰富诊断信息。
然后转到测试和验证。这是智能体运行规格说明验证契约部分的所有测试场景的地方，测试针对规格说明的要求提供二进制的通过/失败信号。
现在我们取循环最后两步的输出并将它们全部关联起来。智能体关联所有活跃传感器和所有测试结果的信号。多个传感器报告同一问题确认了诊断。传感器之间的冲突信号可能揭示隐藏的复杂性。但这种综合分析揭示了测试中什么失败了以及从感官反馈中得知为什么失败，这使智能体能够进行针对性的改进。
我们循环、循环再循环，直到功能完成。如果所有测试通过且所有传感器报告执行干净，功能就完成了。所以日志中没有错误，没有 UI 渲染问题，交互正常。此时，功能完成。否则，智能体根据收集的诊断信息进行改进，并再次循环。
当我们确定满足这些收敛标准时，功能就完成了，智能体创建一个仅包含该功能更改的原子 git 提交，并附带结构化的提交信息，包括功能 ID、规格摘要、验证确认和实施说明。此时，功能完全完成，代码库准备好迎接下一个功能。
这里的输出是我们终于做到了。我们得到了一个完全可工作的、经过测试的功能，它通过了所有验收标准、所有测试，并已被所有三个数字传感器验证，该功能已准备好集成到更广泛的代码库中。
让我们回头看看我们的“氛围编码”开发者，看看他在接触了框架的原则和流程后情况如何。看来我们要让他大吃一惊，甚至目瞪口呆了。脑洞大开。思维扩展。好了，我们现在要转入最后的部分，进入工具篇。
工具
框架需要四种基础能力来支持通过流程完成工作。
让我们谈谈编码环境。编码环境是一个完整的开发工作区，支持两种同时发生且根本不同的工作类型：你的架构思考和规划，以及智能体的自主实施和测试。
编码环境有四个核心组件。显然，第一个是 AI 编码智能体。其次是执行沙盒，这是一个安全、隔离的环境，所有智能体编写的代码都在其中执行并运行测试。自主实施需要自由实验、迭代，偶尔搞破坏。沙盒在一个可丢弃、无风险的环境中提供完整的开发能力，易于重置且失败无后果。
接下来，我们需要一个 IDE 或文本编辑器，如果你非要这么叫的话。我不想在这里引发 IDE 与文本编辑器的圣战。你选适合你的就行。
最后是语音输入。这是以思维速度将语音转换为文本的快速捕捉系统。规划工作涉及外化架构思考，这通常是不完整的、探索性的和迭代的。语音输入消除了打字瓶颈，让你出声思考并比打字快得多地捕捉想法。我真的无法过分强调，一个好的语音输入工具对应用此框架有多么巨大的影响。
接下来我们有多感官反馈系统。这是一个全面的验证基础设施，使智能体能够通过三种互补的数字传感器——即视觉、听觉和触觉——观察它们的实施，并通过人类在开发过程中使用的类似广度的观察来实现自主改进。
这里的核心组件是视觉感官工具，它们能直接观察产生了什么和存在什么。它们捕捉 UI 渲染（如截图或布局样式）、系统状态（如数据库内容、配置会话数据）以及代码结构（即实际实施）。视觉观察捕捉日志和测试遗漏的问题：渲染损坏、状态不正确和结构问题。
听觉感官工具。这些工具监控系统报告的内容。它们捕捉日志——你可以把这看作系统叙述其操作——错误和警告（系统检测到的问题），以及 API 响应（即系统间通信），关键还有堆栈跟踪（stack traces）即详细的故障信息。这些诊断信息解释了为什么东西失败，而不仅仅是它们失败了。
最后是触觉传感器。这些工具启用主动交互测试。它们模拟并执行用户工作流。这就是完成端到端任务、API 交互（想想请求/响应循环）、性能验证（如响应时间和资源使用）、安全检查和集成测试。这些交互揭示了软件在实际使用下是否行为正确，而不仅仅是在隔离的测试场景中。
接下来我们谈谈上下文工程与组装工具。这是一种系统的方法，通过刻意的交叉引用为 AI 智能体组装专注、完整的上下文包。想想声明式链接、用于流程自动化的斜杠命令 (slash commands)、用于结构可预测性的模板，以及用于高效可传递文档的 Markdown 文档。
让我们谈谈这里的交叉引用系统。这是一种声明式链接机制，允许文档显式引用其他文档或代码文件或部分，通过跟随这些依赖链实现自动上下文组装。大多数好的编码智能体都能理解并跟随这些。
然后我们谈谈斜杠命令，或者在你选择的编码智能体环境中等效的东西。这些是触发单次调用多步框架工作流的流程自动化机制。这对上下文组装、实例化模板、实施会话初始化等非常有用。
然后是模板系统。这些是针对每一个框架工件的结构化文档模板：主项目规格说明书、功能规格说明、依赖矩阵、实施计划、实施记录。这些确保了一致的格式和完整性。如果没有模板，你每次都要重新发明规格说明结构。从零开始是很累人的。
最后是 Markdown 文档格式。我们都知道它是什么。但智能体对它如此熟悉，以至于拥有能将输入快速转换为 Markdown 的工具链至关重要。基本上，任何你想传达给智能体的东西都应该能在工具链中瞬间转换为 Markdown。
最后，版本控制与进度跟踪。这是一个双重机制系统，使用——我就直说了——Git 通过原子功能提交进行实施历史记录，其次使用实施计划进行功能完成跟踪。这些协同工作以提供完整的项目来源和当前状态可见性。
我要说这是最简单的项目跟踪形式。当然可以变得更复杂并与其他系统集成。但对于版本控制，Git 或同类工具，我认为不言而喻。就像电子游戏里的存档。显而易见且必不可少。
然后是带有进度跟踪的实施计划。我们使用之前从模板创建的同一个规划工件来进行功能跟踪。哦抱歉，是进度跟踪。Git 会告诉我们什么变了以及何时变的，但它不显示项目状态。实施计划填补了这个空白。它是一个规划工件，同时也充当进度跟踪器。
这里快速看一下我的工具栈。我不会花时间详细讲，但在走廊遇到我时，我很乐意详细交流。
宿醉后的清晨
好了。如果你喜欢这个演讲，想要 PPT 和其他资源，包括原声带，我专门为此演讲建了一个网站。请访问 vibecodinghangover.com 查看。
