智能体工程：从氛围编程到结构化AI辅助开发方法论

1. 项目概述从“氛围编程”到“智能体工程”如果你和我一样在过去一年里深度使用过 Claude Code、Cursor 或者 GitHub Copilot 来写代码大概率经历过两种极端状态一种是“哇这 AI 太神了我动动嘴皮子代码就出来了”的狂喜另一种是“这写的什么玩意儿改了三遍还不如我自己重写”的崩溃。这种在“天才”和“白痴”之间反复横跳的体验业界有个精准又带点自嘲的词来形容——Vibe Coding氛围编程。Vibe Coding 的本质是“走一步看一步”把 AI 当成一个超级自动补全工具想到哪说到哪缺乏系统性的规划和约束。对于周末做个原型、验证一个想法这完全没问题甚至很爽。但一旦你开始处理正经的、需要交付的、未来需要维护的软件项目Vibe Coding 的弊端就会暴露无遗代码质量参差不齐、架构混乱、隐性 Bug 丛生最终积累成难以偿还的技术债。你会发现自己花在理解和修正 AI 产出上的时间可能比亲手写还要多。那么有没有一种方法既能享受 AI 带来的十倍速杠杆又能保证产出是可靠、可维护、符合工程标准的这就是Agentic Engineering智能体工程要回答的问题。它不是一个具体的工具而是一套以人为核心、结构化、可重复的方法论。其核心思想非常反直觉在真正动手写代码之前你需要花 2-3 倍的时间进行周密的规划。这听起来像是增加了“开销”但正是这部分“慢思考”为后续的“快执行”提供了坚实的杠杆。你不是在管理一个无所不能的 AI而是在领导一个“知识渊博、充满勇气但缺乏品味、且时不时会胡说八道的初级天才实习生”借用 Andrej Karpathy 的精彩比喻。你的角色从“打字员”转变为“架构师兼质检员”。这套方法论源自一线开发者的实践并融合了 Andrej Karpathy、Addy Osmani 等社区领袖的见解。它适用于任何使用 AI 编码助手进行严肃软件开发的场景——无论是构建生产级功能、交付客户项目还是带领团队建立 AI 辅助开发的共同标准。接下来我将为你拆解这套方法的七个阶段并附上大量只有踩过坑才知道的实操细节。2. 方法论核心七大阶段全景解析智能体工程方法论将项目从构思到交付甚至到经验固化的过程清晰地划分为七个阶段。前四个阶段专注于“规划”后两个阶段专注于“执行”最后一个阶段是可选的“升华”。理解每个阶段的目标、产出和参与者至关重要。2.1 阶段划分与时间投入很多人误以为用 AI 编程就是省时间所以应该把大部分时间花在“写代码”上。但这套方法论给出了一个截然不同的时间分配模型它更符合复杂系统构建的客观规律阶段建议时间占比核心活动与产出阶段 1-4项目规划~50%明确目标、深入研究、迭代精炼、清晰化文档。产出是一份锁定、无歧义的《项目计划书》。阶段 4.5 (可选)视觉设计0-15%针对 UI 项目在写代码前完成视觉稿和交互设计锁定产品形态。阶段 5实施计划~25%将宏观计划拆解为具体、可验证、有序的执行步骤。产出是《实施计划》。阶段 6逐步执行~25%AI 根据计划一步步编码人类逐行审查、验证。产出是可运行的、通过验证的代码。阶段 7 (可选)技能固化~0-10%将稳定的工作流抽象为可复用的技能或插件。这个比例可能会让习惯“敏捷开发、快速迭代”的开发者感到惊讶。但请相信我在 AI 辅助的语境下“想清楚”比“快速试错”的成本低得多。AI 的试错会生成大量需要你理解和清理的代码垃圾而人类的“想清楚”则是在文本层面进行的低成本、高杠杆的思考。2.2 各阶段角色与核心产出每个阶段都有明确的“第一责任人”这避免了 AI 和人类职责的模糊地带阶段 1 (人类)你且只有你。产出项目愿景、目标和范围。阶段 2 (AI)AI 作为研究助理产出详尽的研究文档。阶段 3 (协作)AI 发现问题人类做决策。产出是经过多轮讨论、矛盾已解决的计划。阶段 4 (AI 起草人类审查)AI 优化文档可读性人类确保准确性。产出是最终版《项目计划书》。阶段 5 (AI 起草人类审查)AI 拆解任务人类确认顺序和验收标准。产出是《实施计划》。阶段 6 (AI 执行人类审查)AI 编码人类进行代码审查和结果验证。产出是提交的代码。阶段 7 (人类)你将重复的工作流固化为技能。这个流程的核心是“人类决策AI 执行”。AI 的优势在于信息检索、方案生成和机械性劳动而人类的优势在于判断、品味和承担最终责任。混淆这个边界就会回到 Vibe Coding 的老路。3. 深度规划阶段 1 至 4 的实战精要规划阶段是杠杆的支点。这里多花一小时执行阶段可能省下五小时。我们深入每个阶段。3.1 阶段 1人类撰写项目基石这个阶段禁止使用 AI。你需要在一个纯文本文件比如project_plan.md中写下最原始的想法。标题用一句话说清楚你要构建什么。例如“用户仪表盘数据导出功能”。目标2-3 行阐述要达成什么以及为什么。避免描述“怎么做”。例如“目标允许用户将其仪表盘上的图表数据以 CSV 格式导出。原因用户频繁请求此功能以进行离线分析目前只能截图效率低下。”非目标这是最容易被忽略但价值最高的部分。明确写下你不打算做的事情。LLM 天生有“功能蔓延”的倾向它会“好心”地添加它认为有用的东西。例如“非目标不支持 PDF 导出不包含数据实时刷新功能不修改现有图表渲染逻辑。” 写下它们你就有了一份“契约”可以在 AI 越界时直接指出来。关键要点从你脑子里蹦出 5-10 个高层级任务点。不用追求完整或有序。例如“需要新的后端 API 端点”、“前端添加导出按钮”、“处理大数据集的分页导出”、“考虑文件格式CSV/JSON”、“需要权限校验”。实操心得我习惯把“非目标”放在非常显眼的位置甚至用 **非目标**这样的 Markdown 引用块高亮。在后续与 AI 的讨论中每当它提出“也许我们可以加一个...”的建议时我会立刻引用这部分内容这能有效遏制范围蔓延。可选访谈模式如果你对问题域不熟悉不确定自己遗漏了什么可以在阶段 1 之前开启一个独立的对话上下文让 AI 采访你。提示词可以这样写“我想构建一个 [简要描述]。请就此采访我。询问技术实现、边界情况、权衡取舍以及我可能没考虑到的事情。不要问显而易见的问题——深入挖掘难点。” 利用 AI 的提问来激发你的思考然后用这些思考成果去撰写阶段 1 的文档。切记采访结束后开启一个全新的对话上下文来开始正式的阶段 1避免采访中的发散性讨论污染你的核心规划。3.2 阶段 2AI 生成研究文档现在让 AI 上场。在一个专用的对话上下文中将你的阶段 1 文档和整个代码库或相关文档、API 说明交给它并给出明确指令“请超级彻底地研究这个项目计划以及相关的代码库/文档生成一份全面的研究文档。不要遗漏任何东西。”这份文档可能会非常长2000-5000 行对于复杂项目很常见它应该包含现有架构核心模块、数据流、技术栈。相关文件列出所有需要查看或修改的文件及其路径。API 合约与数据模型接口定义、请求/响应格式、数据库表结构。依赖与约束第三方库版本、环境变量、性能限制、合规要求。外部依赖这是关键明确列出需要提前准备的东西API 密钥、访问权限、需要其他团队先完成的工作、需要测试的第三方服务。这份研究文档将成为 AI 在整个项目中的“外部记忆”。在后续阶段你只需让 AI “参考研究文档”而不是每次都重新读取整个代码库这能极大节省上下文令牌Token并保持焦点。高级技巧使用子智能体进行研究如果你的工具支持如 Claude Code强烈建议使用“探索”子智能体。你可以在主对话中指派一个子智能体去专门探索代码库它会在独立的上下文中工作最后给你一份总结报告。这样做的好处是探索过程中产生的大量中间输出和无关文件列表不会污染你的主工作上下文让你的主对话保持干净专注于核心的规划和决策。基础设施建立 CLAUDE.md 实现持久化上下文研究文档虽好但如果你每次开启新会话都要手动上传它那就太麻烦了。Claude Code 提供了一个杀手级功能CLAUDE.md文件。你可以在项目根目录创建这个文件内容类似## 研究 请首先阅读 RESEARCH.md 文件以了解项目背景。 ## 计划 当前实施计划在 PLAN.md 中顶部有“当前状态”更新。Claude Code 会在该目录下启动任何新会话时自动读取CLAUDE.md的内容。这意味着AI 每次“醒来”都已经知道该去哪里获取项目上下文。这是提升首次响应质量最高效的方法之一。从此刻开始版本控制立即对这份计划文档以及后续的研究文档进行 Git 初始化并提交。从此以后所有的修改都将以差异diff的形式呈现。审查一个 50 行的 diff 比重新阅读一份 5000 行的文档要快得多也安全得多。3.3 阶段 3迭代式精炼这是规划阶段最需要“人机协作”的部分。你需要进行 3-4 轮的精炼循环每轮遵循一个严格的模式指令告诉 AI“请阅读研究文档和计划文档。找出其中的矛盾之处、缺失的决策、模糊点以及我可能没考虑到的事情。”AI 输出AI 将其发现写在文档的底部切记不是直接修改原文。每条发现最好以“问题 #X: [描述]”的格式列出。人类决策你亲自在文档中在每个问题下方以 bullet points 的形式写下你的决定和理由。聚焦讨论一次只深入讨论一个问题。LLM 在处理多个并行话题时容易混淆。彻底解决一个问题后再让 AI 基于更新后的文档提出下一轮问题。精炼什么第 1-2 轮寻找结构性缺口。例如“计划中提到要使用缓存但研究文档显示当前架构没有引入 Redis 客户端。” 或者“你假设用户数据来自 A 表但根据 B 服务的 API实际数据源是 C。”第 3-4 轮关注更细致的问题。例如“导出失败时的错误信息格式未定义。”、“CSV 文件名的生成规则是否包含时间戳”、“对于超时请求是返回部分数据还是直接报错”何时停止当 AI 提出的问题开始变得琐碎或纯属假设时例如“也许我们可以考虑支持 XML 格式”——但这已在非目标中排除就说明精炼已到达收益递减点可以停止了。关键对话技巧询问方案而非代码当遇到技术决策时不要问“这该怎么实现”而要问“针对这个问题请给出 2-3 种实现方案并列出每种方案的优缺点。” 你来基于项目上下文性能、可维护性、团队熟悉度做选择。AI 可以提供信息但最终判断在你。利用扩展思考处理难题对于特别复杂的架构决策或依赖关系梳理可以提示 AI “请仔细思考后再回答”。像 Claude 4.7 这样的模型会为复杂问题动态分配更多推理令牌。组建“LLM 理事会”如果对一个关键决策犹豫不决可以将同一个问题抛给不同的模型如 Claude Opus, GPT-4, DeepSeek。不同模型有不同的知识盲区和思维倾向它们的集体意见能帮你更全面地审视问题。定义中止标准在开始前就写下“如果在实施过程中发现 X我们就停止并重新规划。” 例如“如果目标 API 不支持批量操作则重新规划为单条调用。” 这能将对未知风险的焦虑转化为清晰的行动规则。3.4 阶段 4为清晰而重写当计划的内容已经扎实就需要提升其可读性和简洁性。让 AI 来执行重写“请重写这份计划文档使其更加清晰。在保证信息准确的前提下尽可能精简文字。”AI 的重写通常会去除迭代过程中产生的重复内容让逻辑更流畅。但是你必须亲自审查重写后的 diffLLM 在重写时可能会无意中改变细微的含义或者删除它不完全理解的注释。使用git diff工具逐行对比确保没有丢失任何关键约束或细节。添加“完成的定义”在重写后在“目标”部分附近增加一个“完成的定义”小节。用可验证的陈述来描述项目完成时的状态用户能看到/做到什么例如“用户可以在仪表盘点击‘导出 CSV’按钮并成功下载一个包含当前视图所有数据的 CSV 文件。”哪些接口/页面/功能必须正常工作部署状态是什么例如“代码合并至主分支并通过 CI/CD 管道部署到预发布环境。”如何确认它已“交付”而不仅仅是“代码写完”这呼应了 Karpathy 的观点“演示版是works.any()产品是works.all()”。完成的定义确保你构建的是产品而不仅仅是一个能跑起来的演示。4. 从计划到代码阶段 5 与 6 的执行艺术规划完成后我们进入执行层面。这里的关键是将宏大的目标转化为机械的、可验证的步骤。4.1 阶段 5制定实施计划只有在项目计划阶段 1-4锁定后才能开始这一步。让 AI 基于最终版计划和研究文档起草一份实施计划。提示词可以是“请仔细思考。重新阅读研究文档。创建一份实施计划明确列出这些任务需要发生的具体顺序。”这份计划应该包含5-10 个编号的步骤每个步骤必须包含行动内容要做什么可包含子步骤。成功标准这是核心必须用声明式而非命令式的语言描述。不是“添加验证逻辑”而是“当输入的用户ID不存在时API 应返回 HTTP 400 状态码及错误信息{“error”: “User not found”}”。不是“修复 Bug”而是“自动化测试用例test_export_large_dataset通过。”验证方式标明哪些验证 AI 可以自动完成运行测试、通过 lint 检查哪些需要人工介入在浏览器中打开页面、检查数据库记录。声明式成功标准的威力声明式标准为 AI 提供了一个明确无误的“靶心”也为你提供了一个客观的验收工具。步骤完成后你不需要去“理解”代码只需要去“验证”结果是否符合标准。审查与标注像审查代码一样审查实施计划。逐行阅读并在有疑问或发现错误的地方用个人标签进行行内标注。例如步骤 3创建数据库迁移文件。 note_AB - 这个迁移需要依赖步骤 1 创建的新模型顺序正确。 步骤 4实现导出 API 端点。 note_AB - 这里需要调用步骤 2 封装的数据服务确认一下。 note_AB - 成功标准需要明确响应格式是 JSON 还是直接返回文件流。然后你可以指示 AI“找到所有note_AB标记并逐一处理它们。”会话交接块在计划文档的最顶部添加一个“当前状态”区块。例如## 当前状态 - 步骤 1-3已完成 - 步骤 4进行中 - API 端点框架已搭建业务逻辑待实现 - 阻塞项等待运维提供新的数据库连接池配置 - 下一步完成步骤 4 的业务逻辑然后进行步骤 5前端集成每完成一个步骤或会话就更新这个区块。这确保了无论是你隔天回来还是需要同事接手都能在 10 秒内了解项目进度无缝衔接。4.2 阶段 6逐步执行与严格验证这是 AI 大量产出代码的阶段也是你最需要保持警惕的阶段。你的角色是严格的质检员。准备工作清空上下文开始一个全新的对话会话。这是至关重要的一步。规划阶段的对话充满了讨论、备选方案和死胡同会干扰纯净的执行。让 AI 重读计划在新的会话中让 AI 完整阅读最新的项目计划和实施计划得益于CLAUDE.md这通常是自动的。确认理解让 AI 复述当前状态和下一步要做什么。单步执行流程对实施计划中的每一个步骤循环以下操作指令“请完成本计划中的步骤 N。仅完成步骤 N并彻底完成它。持续执行直到满足该步骤的所有成功标准。”等待让 AI 运行直至完成。一个复杂的步骤可能需要 AI 进行多次工具调用读文件、写文件、运行测试耗时 20-30 分钟。在此期间不要打断它。审查步骤完成后逐行阅读所有变更的代码。使用git diff查看差异。要做好心理准备LLM 生成的代码常常过度设计包含不必要的抽象、冗余的错误处理、丑陋的变量名。这是正常现象。你的任务就是清理它们要么自己动手简化要么指示 AI “这段代码太复杂了请用更简洁、直接的方式重写”。验证按照“验证层级”严格执行全部通过后才能进入下一步。提交验证通过后执行git commit。这是你的安全检查点。更新更新计划顶部的“当前状态”区块。下一步继续步骤 N1。四级验证层级验证不是简单地“运行一下看看”。必须按顺序执行任何一级失败都不能标记步骤完成自动化验证单元测试通过、代码风格检查lint无误、类型检查通过。这部分可以由 AI 自动执行并报告。逻辑验证代码变更是否精确地符合成功标准中的声明仔细阅读 diff理解每一行修改的意图而不仅仅是运行它。行为验证实际运行一下。打开浏览器访问页面、用 curl 调用 API、检查生成的文件。确认实际行为与预期一致。语义验证退一步看这个步骤的完成是否真正推动项目向“完成的定义”前进有没有可能代码完美实现了错误的东西例如成功创建了导出功能但导出的数据字段完全错了。处理 AI 的“信心阈值”当 AI 在回答中使用“可能”、“我认为”、“大概”等词汇时这是一个危险信号。你应该立即追问“你有多大把握哪些地方可能出错” 如果 AI 自己都信心不足那么在投入时间执行之前必须重新审视方法。当问题出现时小的计划调整正常。直接更新计划文档然后继续。步骤验证失败在同一会话上下文中调试。不要进入下一步直到当前步骤完全正确。同一问题纠正两次仍失败清空当前会话上下文。带着从失败中学到的经验写一个更清晰的提示词开启新会话重新开始。一个干净的开局通常比在充满纠错历史的混乱上下文中继续挣扎更有效。触发中止标准立即停止。回到阶段 3从失败点开始重新规划。不要试图在一个从根本上就有缺陷的方案上打补丁。上下文过大20万令牌如果感觉 AI 开始遗忘或胡言乱语清空上下文让它重新读取计划然后从当前状态继续。上下文质量在超过一定规模后会显著下降。AI “记错了”如果 AI 反复建议一些“标准做法”而你在计划中明确采用了不同的非标准方案这可能是它的训练数据在作祟。你需要更明确地指出“根据我们的计划我们采用 X 方案原因是 Y。请严格按照 X 方案实施。” 如果还不行这部分可能就需要你亲手来写。独立审查可选但高价值在所有步骤完成后开启一个全新的、干净的会话让 AI 以“第三方审计员”的身份将最终的代码 diff 与原始的实施计划进行比对。一个没有参与编码的 AI没有“作者偏见”往往能发现实施者忽略的细节或偏差。5. 可选阶段与高级工具运用5.1 阶段 4.5视觉设计先行对于任何包含用户界面的项目强烈建议加入这个可选阶段。在写一行界面代码之前先用 AI 生成可视化的设计稿。何时使用项目涉及任何用户界面。需要与利益相关者确认布局后再开发。交互模式或视觉层级尚未确定。如何操作以 Claude Code 为例使用/frontend-design指令描述你的需求“设计一个用户数据仪表盘界面。深色主题。优先考虑数据可视化的清晰度。主要区域包括概览卡片、趋势图、数据表格、筛选器。”Claude 会生成可渲染的 HTML/CSS你可以在浏览器中直接打开这个实时原型进行交互。像与设计师沟通一样迭代“把导航栏移到左侧边栏”、“让这个表格可以排序”、“在顶部加一个状态提示条”。对最终确认的设计进行截图并将其作为视觉参考放入你的项目计划中。在阶段 5 的实施计划中步骤描述可以引用这些截图“构建与dashboard_design_v2.png一致的仪表盘主页。”注意事项这个阶段产出的是视觉参考稿而非生产代码。生成的 HTML 是用于确认视觉效果的“线框图”或“高保真原型”。真正的、可维护的、与后端集成的界面代码仍然需要在阶段 6 根据实施计划来构建。不要试图直接使用生成的 HTML/CSS。5.2 阶段 7技能化稳定工作流这不是每个项目必需的。但当你发现某个工作流在多个项目或会话中重复使用时就应该考虑将其“技能化”。技能化测试当一个工作流同时满足以下三点时就值得提取重复性跨多个会话或项目被调用不是一次性的。稳定性提示词已经固定下来你不再需要每次调整。有明确的触发点例如“新建营销活动”、“部署到预发布环境”、“运行质量检查”而不是临时起意的任务。技能 vs. 插件技能一个单一的SKILL.md文件放在~/.claude/skills/技能名/目录下。在任何项目中都可以通过/技能名快速调用。安装成本为零对你个人而言。插件多个相关技能、斜杠命令、MCP 服务器的集合通过 Git 或市场分发。当你有 3 个或以上逻辑上紧密关联的技能并且需要团队成员也安装时才需要打包成插件。如何提取技能将你稳定下来的提示词例如从CLAUDE.md中复制某个阶段的完整指令保存到~/.claude/skills/your_skill_name/SKILL.md。在文件顶部添加 frontmatter包含name、description和清晰的trigger when何时触发说明。如果技能需要调用项目内的脚本使用相对路径引用不要将脚本逻辑内联到技能文件中。在一个新目录中测试调用/技能名确保它能端到端运行。为什么这是可选的技能化有成本你需要额外维护一个独立的技能文件并确保它与项目内的脚本同步。不要过早支付这个成本。一个实用的经验法则是在项目本地成功运行两次之后第三次再考虑将其提取为技能。5.3 利用现代工具特性自适应思考Claude 4.7 等先进模型具备自适应思考能力能为复杂问题分配更多“思考”令牌。在智能体工程中你应该在复杂规划阶段使用它阶段 3发现矛盾和阶段 5制定实施顺序涉及复杂的依赖分析和权衡取舍值得让 AI 进行深度思考。在简单执行阶段信任其自动判断阶段 6 的常规编码任务模型会自动分配适量资源无需强制开启深度思考模式。MCP 服务器MCP 允许 Claude 在运行时直接调用外部工具数据库、内部 API。如果你的项目需要与复杂的外部 API 交互为其编写一个 MCP 服务器比让 AI 生成一个脆弱的、一次性的封装层更可靠。Claude Code 内置了一些 MCP 服务器你也可以在.claude/settings.json中配置自定义的。钩子钩子允许你在特定事件如工具运行前、代理停止后、文件保存时自动执行 Shell 命令。这是设立“护栏”的绝佳方式不依赖于可能被忽略的提示词指令。例如你可以配置钩子在每次文件保存后自动运行 linter或者在提交代码前自动运行测试套件。这些规则在工具层面强制执行AI 无法绕过。6. 预期问题与应对策略LLM 不是完美的程序员它们有可预测的失败模式。提前了解并制定应对策略能让你从被动救火转为主动管理。预期问题现象描述应对策略过度复杂化代码充满不必要的抽象层、过度设计的错误处理、冗余逻辑。直接询问“一个资深工程师会认为这段代码过度复杂了吗如果是请简化它。”范围蔓延AI 擅自添加“锦上添花”的功能或重构你未要求修改的相邻代码。立即指出“非目标”列表。强调“只修改步骤中明确要求的内容。”静默失败代码能运行不报错但产出结果是错误的。严格进行行为验证和语义验证。检查实际输出而非仅仅依赖测试通过。自信的胡说八道AI 非常肯定地陈述一个错误的事实尤其是关于外部 API 或库的细节。永远不要完全信任 AI 对外部知识的记忆。亲自查阅官方文档进行核实。糟糕的品味变量命名丑陋、代码风格不一致、添加大量无用的注释。在代码审查中清理或者在计划中提供具体的代码风格示例供 AI 参考。训练数据干扰当你故意采用非标准方案时AI 仍反复建议标准做法。在提示词中更加明确地强调你的独特选择及其原因或者直接手动编写该部分。注释/代码变异AI 在修改代码时可能会“顺手”更改或删除它不完全理解的注释。仔细审查每一个 diff。每一行被修改的代码都必须能追溯到明确的变更请求。7. 核心原则与常见陷阱总结经过多个项目的实践我总结出一些贯穿始终的核心原则和必须避免的陷阱。时刻对照这张表能帮你省下无数调试时间。核心原则清单人类是船长AI 是桨手你负责导航和决策AI 负责提供动力和执行。规划即杠杆在文本和计划上多花时间是在高杠杆率环节投资。验证高于信任永远用可观测的成功标准来验证而不是相信 AI 的“我完成了”。上下文是稀缺资源积极管理对话上下文在任务间、规划与执行间及时清空。一次一件事无论是讨论问题还是执行步骤保持焦点单一避免混淆。必须避免的十大陷阱让 AI 同时处理多件事这会导致混乱和低质量输出。坚持“一次一个问题一个步骤”。在精炼阶段让 AI 直接修改原计划这会使跟踪变更变得困难。坚持让 AI 将发现写在底部由你决策并整合。计划未固就仓促编码这是通往技术债务的捷径。必须完成阶段 1-4获得锁定的计划后才能进入阶段 5。每次编辑后重读全文学会使用git diff它比你想象的要快得多。在过大的上下文20万令牌中继续工作性能会急剧下降。清空上下文重新加载计划。忽视“中止标准”事前明确的“熔断”机制能防止你在错误道路上浪费大量时间。在阶段 6 之前开始写代码任何在阶段 6 之前产出的代码都是未经结构化审查的“氛围代码”应被视为草稿并丢弃。陷入无限规划当 AI 提出的问题变得琐碎时就果断停止精炼进入下一阶段。在同一问题上重复纠正 AI 三次这通常意味着提示词或上下文有问题。清空会话带着更清晰的指令重新开始。完全相信 AI 关于外部系统的记忆对于 API 签名、库的行为等永远以官方文档为准。最后我想分享一个深刻的体会这也回应了 Karpathy 提到的“专业悖论”这套方法论最能发挥威力的人恰恰是那些没有 AI 也能亲手把东西做出来的开发者。AI 提供的是杠杆——速度、广度和不知疲倦。而你提供的是判断力、品味和最终的正确性。你需要有能力阅读 AI 生成的代码并知道它是对是错。对于经验较浅的开发者风险在于如果你看不懂 diff你就无法验证步骤那么你实质上又回到了“氛围编程”只是在更大的规模上生产“代码垃圾”。这套方法通过将决策前置到规划阶段在这里你可以从容思考并将执行简化为机械验证标准已预先定义来缓解这一问题。但归根结底你对所构建系统的理解深度决定了你能从 AI 那里获得多大的杠杆。智能体工程不是让新手变成高手而是让高手变得超级高效。