AI Native 团队研发体系落地手册：上下文工程、Agent 编排与 Skill 设计

1. 从人写代码到人管意图AI Native 团队到底在变什么过去两年我参与过三个不同规模的团队从传统研发模式向 AI Native 模式迁移的过程。最直观的感受是大多数团队把用上 AI 编程助手等同于完成了 AI Native 转型结果三个月后发现代码量涨了但交付质量反而下降了。问题出在认知层面——AI Native 不是给现有流程加一个工具而是把研发流程的第一性原理从人写代码换成人定义意图、Agent 执行、人验收结果。这个转变的核心在于SDLC软件开发生命周期的每个环节都需要重新设计。传统 SDLC 里需求评审、技术方案、编码、测试、部署是一条线性流水线每个环节的产出物是给人看的。但在 AI Native 模式下每个环节的产出物首先要给 Agent 看——这意味着文档格式、上下文组织、任务拆解粒度都要重新考虑。我见过最典型的失败案例是一个二十人的后端团队他们给每个工程师配了 AI 编程助手但需求文档还是传统的 PRD 格式技术方案还是散落在 Confluence 里的长文。结果 Agent 拿到的上下文要么太长塞满整个 PRD 导致关键信息被淹没要么太短只给一个函数签名导致实现偏离预期。三个月后统计AI 生成的代码有 40% 需要大幅重写效率提升几乎为零。所以这篇手册要解决的问题很具体一个团队从零开始搭建 AI Native 研发体系需要哪些基础设施、哪些规范、哪些角色分工以及每一步踩过的坑长什么样。适合正在考虑转型的技术负责人、想了解 AI Native 落地细节的工程师以及已经在用 Agent 但觉得哪里不对的团队参考。2. 上下文工程CLAUDE.md 不是配置文件是团队的意图契约2.1 为什么大多数团队的 CLAUDE.md 写了等于没写CLAUDE.md 这个文件在 AI Native 团队里的地位相当于传统研发里的编码规范加架构决策记录ADR加新人入职文档的合体。但我在至少五个团队里看到的 CLAUDE.md内容都是这样的# 项目说明 这是一个 React Node.js 项目。 请使用 TypeScript。 遵循 ESLint 规则。这种写法的问题在于它描述的是事实而不是意图。Agent 不需要你告诉它这是 React 项目——它读 package.json 就知道了。Agent 真正需要知道的是这个项目里哪些决策是不可协商的哪些是有历史原因的哪些是看起来奇怪但别动的。我自己的团队在迭代了七版 CLAUDE.md 之后总结出一个有效的结构# 项目意图契约 ## 不可协商的约束 - 所有数据库查询必须经过 repository 层禁止在 service 层直接调用 ORM - 原因2024年Q2 出现过一次因为 service 层直接查询导致的 N1 问题影响线上 2 小时 - 错误处理统一使用 Result 类型禁止 throw除启动阶段 - 原因跨服务调用需要区分业务失败和系统异常throw 会丢失这个区分 ## 看起来奇怪但别改的地方 - utils/date.ts 里的 formatDate 函数有 200 行不要重构 - 原因它处理了 17 个国家的时区和日历差异每个分支都有对应的测试用例 - api/legacy/ 目录下的代码不要动 - 原因对接的是合作方十年前的系统改了就挂 ## 当前迭代的上下文 - 正在从 REST 迁移到 GraphQL新接口一律用 GraphQL - 旧 REST 接口保持不动不要顺手改这个结构的关键在于每一条约束都附带了为什么。Agent 在处理边界情况时如果知道约束背后的原因就能做出更合理的判断。比如它遇到一个必须绕过 repository 层的场景比如批量操作性能问题它会知道这个约束的存在然后主动询问而不是默默违反。2.2 上下文分层别把所有东西塞进一个文件CLAUDE.md 只是最顶层的那一层。一个成熟的 AI Native 团队上下文应该至少分三层层级文件内容更新频率团队级CLAUDE.md跨项目的编码哲学、技术栈偏好、通用约束季度项目级项目根目录 CLAUDE.md项目特定约束、架构决策、当前迭代上下文双周模块级模块目录下 .claude.md该模块的接口契约、数据流、边界条件按需我见过一个团队把三层上下文用得很溜他们的支付模块有一个.claude.md里面写清楚了这个模块处理的是人民币支付外币支付在另一个模块不要在这里加外币逻辑。结果有一次 Agent 被要求加一个支持美元的需求它读到这个文件后主动提示这个需求应该放在外币支付模块需要我帮你切换上下文吗注意上下文分层不是越多越好。我试过给每个函数都写上下文结果 Agent 反而因为信息过载而忽略了关键约束。经验值是团队级不超过 200 行项目级不超过 500 行模块级不超过 100 行。2.3 上下文的保鲜机制上下文最大的敌人是过期。一个写了半年的 CLAUDE.md里面可能有一半的约束已经不再适用。我的做法是每次迭代回顾时花 10 分钟检查 CLAUDE.md 里有没有需要更新的条目。具体操作是让 Agent 自己检查。在迭代结束时给 Agent 一个任务读取 CLAUDE.md对比当前代码库的实际状态列出所有可能过期的约束。Agent 会找出比如约束里说用 Redux但代码里已经全换成 Zustand 了这种不一致。这个机制帮我抓到过好几次上下文过期的问题。最惊险的一次是CLAUDE.md 里写着所有 API 调用必须加超时但半年前团队换了一个 HTTP 客户端新客户端的超时配置方式不同Agent 一直按旧方式写导致新代码的超时全部失效。3. Plan Mode 的实战用法让 Agent 先想清楚再动手3.1 为什么直接让 Agent 写代码是灾难我统计过自己团队的数据直接让 Agent 写代码首次通过率大约是 35%先让 Agent 出计划再写代码首次通过率能到 72%。这个差距的来源不是 Agent 变聪明了而是计划这个环节暴露了理解偏差。举个例子。需求是给用户列表加一个导出功能。直接让 Agent 写它可能会在 controller 里加一个 export 方法查数据库生成 CSV返回。看起来没问题但实际需求可能是导出要异步数据量大要支持筛选条件和列表页一致要记录操作日志合规要求。这些 Agent 都不知道因为它没有想的过程。Plan Mode 的核心价值就是强制 Agent 把它的理解写出来让人有机会在写代码之前纠正。3.2 一个可复用的 Plan Mode 提示词模板我用了半年多的一个提示词模板效果很稳在开始写代码之前请先输出一份实现计划包含以下部分 1. 需求理解用你自己的话复述一遍需求包括你认为的边界条件 2. 影响范围列出所有需要修改的文件和模块 3. 实现步骤按顺序列出每一步做什么每步的产出是什么 4. 风险点你认为哪些地方可能出问题为什么 5. 需要确认的问题任何你不确定的地方列出来等我确认 输出计划后停下来等我确认或修改后再开始写代码。这个模板的关键是第 5 点。让 Agent 主动暴露它的不确定性比让它猜然后写错要好得多。我遇到过 Agent 在第 5 点里写我不确定导出是否需要支持分页因为需求里没提但数据量大的话可能需要。这个问题提得非常对如果它没提可能就写了一个全量导出的版本上线后直接 OOM。3.3 Plan Mode 的粒度控制Plan Mode 不是越细越好。我试过让 Agent 把计划细到每个函数怎么写结果计划本身写了 2000 字我审计划的时间比我自己写代码还长。经验粒度是计划应该细到每个文件改什么但不用细到每行代码怎么写。比如好的粒度在user-service.ts里加一个exportUsers方法接收筛选条件返回一个 job ID实际导出逻辑放在export-worker.ts里异步执行太粗的粒度实现导出功能太细的粒度在user-service.ts第 45 行后插入一个 async 函数参数是filters: UserFilters返回Promisestring...3.4 Plan Mode 和 Agent 的记忆Plan Mode 还有一个隐藏价值计划本身可以作为 Agent 的短期记忆。当 Agent 在写代码过程中需要做决策时它可以回看计划保持一致性。我遇到过没有 Plan Mode 时的一个典型问题Agent 在写 controller 时用了 A 方案写到 service 时忘了用了 B 方案结果两层对不上。有了计划之后Agent 会先看计划里怎么说的然后按计划执行。提示如果你的 Agent 工具支持计划持久化把计划存成文件一定要开启。这样即使会话中断重新开始后 Agent 还能读到之前的计划。4. Agent 编排从单 Agent 到多 Agent 的演进路径4.1 什么时候该从单 Agent 换成多 Agent单 Agent 能解决 80% 的日常任务。我自己的经验是当一个任务需要超过 3 个不同领域的知识或者需要超过 10 步操作时就该考虑多 Agent 了。比如给用户模块加一个导出功能这个任务涉及数据库查询后端知识、CSV 生成数据处理知识、异步任务架构知识、权限校验安全知识。单 Agent 做这个任务时经常会在某个环节忘记之前的约束。多 Agent 的做法是一个架构 Agent负责出方案一个后端 Agent负责写数据库和 service一个前端 Agent负责写触发按钮一个测试 Agent负责写测试。但多 Agent 不是没有代价的。最大的代价是协调成本。我见过一个团队上了五个 Agent结果 Agent 之间互相等待、重复劳动、接口对不上效率反而比单 Agent 低。4.2 一个最小可用的多 Agent 编排方案我的团队现在用的方案是12一个 Orchestrator Agent两个 Worker Agent一个写代码一个写测试。Orchestrator 的职责接收需求拆解成任务列表决定每个任务分配给哪个 Worker收集 Worker 的产出检查一致性如果发现冲突决定怎么解决Worker 的职责接收具体任务执行完成后报告做了什么、改了什么文件、有什么不确定的地方这个方案的关键是Orchestrator 不写代码Worker 不做决策。我试过让 Orchestrator 也写代码结果它既要管全局又要管细节经常顾此失彼。4.3 Agent 之间的接口契约多 Agent 最容易出问题的地方是接口。比如代码 Agent 写了一个函数叫exportUsers测试 Agent 以为叫exportUserData测试就挂了。解决办法是在任务分配时Orchestrator 必须明确接口。比如任务实现用户导出功能 接口契约 - 函数名exportUsers - 位置src/services/user-service.ts - 签名exportUsers(filters: UserFilters): PromiseExportJob - 返回值ExportJob 包含 jobId 和 estimatedTime这个契约由 Orchestrator 在分配任务时生成代码 Agent 和测试 Agent 都按这个契约工作。我实测下来加了接口契约之后Agent 之间的接口不一致问题减少了 90%。4.4 Agent 并发怎么扛住同时跑多个任务当团队规模上来之后多个 Agent 同时跑是常态。这时候会遇到几个问题问题一文件冲突。两个 Agent 同时改同一个文件后写的覆盖先写的。解决办法是Orchestrator 在分配任务时做文件级锁——同一个文件同一时间只能被一个 Agent 修改。问题二上下文爆炸。每个 Agent 都要读 CLAUDE.md 和项目上下文十个 Agent 同时读token 消耗巨大。解决办法是上下文缓存。把 CLAUDE.md 的内容缓存在一个共享位置Agent 通过引用读取而不是全文加载。问题三结果合并。多个 Agent 的产出需要合并成一个完整的变更。解决办法是每个 Agent 产出独立的 diffOrchestrator 负责按顺序应用 diff遇到冲突时人工介入。我自己的团队现在跑 5 个 Agent 并发用的是文件锁 上下文缓存 diff 合并这套方案实测下来冲突率在 5% 以下大部分冲突是 Agent 对同一个工具函数的修改人工解决起来很快。5. Agent Skill 的设计把经验变成可复用的能力5.1 Skill 和 Prompt 的区别很多人把 Skill 和 Prompt 混为一谈。我的理解是Prompt 是一次性的指令Skill 是可复用的能力包。比如把网页保存成 Markdown这个需求。如果写成 Prompt每次都要说一遍用 readability 提取正文用 turndown 转 Markdown处理图片链接...。如果写成 Skill就是# Skill: 网页转 Markdown ## 触发条件 当用户要求保存网页、转 Markdown、抓取文章时触发 ## 执行步骤 1. 用 fetch 获取网页 HTML 2. 用 readability 提取正文内容 3. 用 turndown 将 HTML 转为 Markdown 4. 处理图片下载到本地 assets 目录替换链接为相对路径 5. 处理代码块保留语言标识 6. 输出到指定目录文件名用网页标题 ## 注意事项 - 如果网页需要登录提示用户提供 cookie - 如果正文提取失败回退到全文转换 - 图片下载失败时保留原始链接并标注这个 Skill 一旦写好团队里任何人说帮我保存这个网页Agent 都会按这个流程执行产出格式统一。5.2 Skill 的粒度一个 Skill 只做一件事我见过一个团队写了一个万能 Skill叫处理文档里面包含了格式转换、内容提取、摘要生成、翻译等十几个功能。结果 Agent 每次触发这个 Skill 都要读一大堆不相关的内容效率很低。正确的做法是一个 Skill 只做一件事但做到极致。比如web-to-markdown网页转 Markdownpdf-extractPDF 内容提取doc-summarize文档摘要生成doc-translate文档翻译这样 Agent 可以根据任务精确触发对应的 Skill不会浪费上下文。5.3 Skill 的测试和迭代Skill 写完之后必须测试。我的做法是给每个 Skill 准备 3-5 个测试用例覆盖正常情况、边界情况、异常情况。比如web-to-markdown的测试用例正常一个普通的技术博客文章边界一个包含大量代码块和公式的文章异常一个需要登录的页面异常一个图片全部加载失败的页面每次修改 Skill 后跑一遍测试用例确保没有回归。我自己的团队维护了大约 20 个 Skill每个都有对应的测试用例迭代起来很放心。注意Skill 的测试用例本身也可以作为 Skill 的文档。新成员看测试用例就知道这个 Skill 能处理什么、不能处理什么。6. 安全与边界Agent 不能做什么6.1 Agent 的权限边界Agent 最危险的地方在于它不知道什么不该做。我见过 Agent 因为一个清理无用文件的指令把整个node_modules删了它认为那是无用文件。也见过 Agent 因为一个优化数据库查询的指令直接在生产环境跑了DROP INDEX。所以权限边界必须明确。我的团队现在的做法是Agent 的操作分三级。级别操作类型处理方式绿色读文件、写代码、跑测试Agent 自主执行黄色改配置、装依赖、改数据库 schemaAgent 执行前需人工确认红色删文件、改生产配置、执行数据库迁移Agent 禁止执行只能生成脚本由人工执行这个分级写进 CLAUDE.mdAgent 在执行前会检查操作级别。我实测下来这个机制拦住了好几次危险操作。6.2 Agent 的幻觉防范Agent 会编造不存在的东西。最常见的幻觉是编造 API。比如它写了一个fetchWithRetry函数但这个函数在代码库里根本不存在。防范办法是在 CLAUDE.md 里明确列出可用的工具函数和 API。比如## 可用的工具函数 - utils/http.ts: fetchWithRetry, fetchWithTimeout, fetchWithCache - utils/date.ts: formatDate, parseDate, diffDays - utils/validation.ts: isValidEmail, isValidPhone, isValidIdCard ## 禁止使用的 API - 禁止直接使用 axios统一用 utils/http.ts 里的封装 - 禁止直接使用 moment统一用 date-fns这个列表不需要很全但必须覆盖常用场景。Agent 在写代码时会优先从这个列表里找找不到才会自己写。6.3 Agent 的越权防范Agent 有时候会自作主张。比如你让它改一个函数它顺手把整个文件重构了。或者你让它加一个功能它顺手把依赖升级了。防范办法是在 Plan Mode 里明确不做什么。比如任务给 exportUsers 函数加一个参数 约束 - 只改 exportUsers 函数不要动其他函数 - 不要升级任何依赖 - 不要改测试文件测试我会自己写 - 如果发现其他问题列出来但不要改这个负面清单很有效。我实测下来加了负面清单之后Agent 的顺手改行为减少了 80%。7. 落地路线图从零到一的三阶段7.1 第一阶段单点突破第 1-2 周不要一上来就搞全套。先选一个具体的、边界清晰的任务让 Agent 跑通。我推荐从写测试开始。原因测试的边界清晰输入输出明确风险低测试挂了不影响生产而且能快速建立团队对 Agent 的信任。具体操作选一个已有的、测试覆盖率低的模块让 Agent 读代码生成测试用例人工审查测试用例修正 Agent 的理解偏差把修正后的理解写进 CLAUDE.md重复 2-4 步直到 Agent 生成的测试用例首次通过率达到 70%这个阶段的目标不是效率而是建立上下文。CLAUDE.md 里的很多约束都是在这个阶段发现的。7.2 第二阶段流程嵌入第 3-6 周当单点任务跑通后开始把 Agent 嵌入到日常流程里。我的做法是在 SDLC 的每个环节找一个Agent 切入点。环节Agent 切入点产出需求需求澄清Agent 列出需求的边界条件和不确定点设计方案生成Agent 出技术方案人审查编码代码生成Agent 按 Plan Mode 写代码测试测试生成Agent 生成测试用例部署脚本生成Agent 生成部署脚本人执行这个阶段的关键是每个环节都要有人工检查点。不要全自动全自动的后果是错误累积到最后无法排查。7.3 第三阶段多 Agent 协作第 7-12 周当流程嵌入稳定后开始引入多 Agent。我的建议是先引入测试 Agent。因为测试 Agent 和代码 Agent 的职责天然分离协调成本最低。具体操作代码 Agent 写代码产出 diff测试 Agent 读 diff生成测试Orchestrator 检查测试是否覆盖了 diff 的所有变更如果有遗漏Orchestrator 要求测试 Agent 补充这个流程跑通后再引入文档 Agent、部署 Agent等。7.4 一个真实的落地时间线我自己的团队从零到跑通多 Agent 协作用了大约 10 周。时间线大概是第 1-2 周写 CLAUDE.md跑通单点任务写测试第 3-4 周把 Agent 嵌入编码流程建立 Plan Mode 规范第 5-6 周建立 Skill 库把常用操作 Skill 化第 7-8 周引入测试 Agent跑通双 Agent 协作第 9-10 周引入 Orchestrator跑通多 Agent 协作这个时间线不是固定的取决于团队规模和任务复杂度。但有一个规律每个阶段的稳定期至少需要 2 周。不要急着进入下一阶段否则会积累技术债。8. 踩坑实录那些让我半夜爬起来修的问题8.1 Agent 把测试删了有一次Agent 在重构一个模块时发现测试文件里的测试用例过时了因为接口变了于是它把测试文件删了重新写了一份。结果新测试只覆盖了 happy path边界情况的测试全丢了。根因CLAUDE.md 里没有明确测试文件不能删只能改。修复在 CLAUDE.md 里加了一条测试文件只能修改不能删除。如果测试用例过时标记为 skip 并说明原因由人工决定是否删除。8.2 Agent 的上下文漂移有一次Agent 在写一个长任务超过 20 步时写到后面忘了前面的约束。比如前面说用 Result 类型处理错误写到后面又用回了 throw。根因上下文窗口有限长任务中早期的约束被挤出去了。修复把长任务拆成短任务每个短任务重新加载上下文。或者在每个短任务开始时让 Agent 复述一遍关键约束。8.3 Agent 的过度优化有一次Agent 在实现一个简单功能时顺手做了一个性能优化把同步查询改成了异步。结果这个改动引入了一个竞态条件导致偶发的数据不一致。根因Agent 的优化没有经过评估它只是觉得异步更快。修复在 CLAUDE.md 里加了一条禁止在没有明确要求的情况下做性能优化。如果发现性能问题列出来但不要改。8.4 Agent 的依赖地狱有一次Agent 为了实现一个功能引入了一个新的 npm 包。结果这个包和现有的包有版本冲突导致整个项目跑不起来。根因Agent 不知道项目的依赖管理策略。修复在 CLAUDE.md 里明确引入新依赖前必须询问。优先使用已有依赖如果已有依赖不能满足列出候选方案和理由由人工决定。9. 团队角色与协作方式的重新定义9.1 AI Native 团队需要哪些新角色传统团队的角色是产品、开发、测试、运维。AI Native 团队在这个基础上多了几个角色上下文工程师负责维护 CLAUDE.md、Skill 库、上下文分层。这个角色不需要写代码但需要深刻理解项目的架构和约束。Agent 编排师负责设计多 Agent 的协作流程、接口契约、冲突解决策略。这个角色需要懂分布式系统的基本概念。质量守门人负责审查 Agent 的产出决定哪些可以自动通过哪些需要人工介入。这个角色需要很强的代码审查能力。这三个角色不一定是专职的可以由现有成员兼任。但必须有明确的人负责否则会出现大家都以为别人在管的情况。9.2 代码审查的变化AI Native 团队的代码审查和传统团队很不一样。传统审查关注的是代码写得对不对AI Native 审查关注的是Agent 的理解对不对。我的做法是审查 Plan 而不是审查代码。在 Plan Mode 阶段花 5 分钟审查 Agent 的计划比花 30 分钟审查 Agent 写的 500 行代码要高效得多。具体审查什么Agent 对需求的理解是否准确Agent 的影响范围是否完整Agent 的风险点是否识别到位Agent 的不确定点是否合理如果 Plan 没问题代码大概率没问题。如果 Plan 有问题代码写得再好也是白搭。9.3 站会和回顾的变化传统站会问的是你昨天做了什么今天做什么有什么阻塞。AI Native 团队的站会应该问昨天 Agent 的产出中有哪些需要人工修正修正的原因是什么这些修正是否应该反馈到 CLAUDE.md 或 Skill 里今天有哪些任务适合交给 Agent哪些必须人工做回顾会则应该关注这个迭代中Agent 的首次通过率是多少趋势如何哪些类型的任务 Agent 做得好哪些做得差上下文和 Skill 需要怎么更新我自己的团队在站会上加了一个Agent 修正日志环节每个人花 1 分钟说昨天修正了 Agent 的什么问题。这个环节帮我们积累了大量上下文改进的素材。10. 度量与迭代怎么知道 AI Native 转型有没有效果10.1 三个核心指标不要用代码行数或提交次数来衡量 AI Native 的效果这些指标会被 Agent 刷爆。我自己的团队用三个指标首次通过率Agent 生成的代码第一次提交就通过审查的比例。这个指标反映 Agent 对上下文的理解程度。健康值60%-80%。人工修正时间人工修正 Agent 产出所花的时间占总开发时间的比例。这个指标反映 Agent 的产出质量。健康值20%-40%。上下文更新频率CLAUDE.md 和 Skill 库的更新频率。这个指标反映团队的学习速度。健康值每周至少 1 次。10.2 一个反直觉的发现我自己的团队在转型三个月后发现了一个反直觉的现象Agent 的首次通过率越高团队的长期效率反而越低。原因是当首次通过率很高时团队会放松审查把越来越多的任务交给 Agent包括那些 Agent 其实不擅长的任务。结果就是短期效率高但积累的技术债在几个月后爆发。所以我们的做法是故意保持一定的人工介入率。即使 Agent 的产出看起来没问题也要定期抽查确保没有隐藏的问题。10.3 迭代节奏AI Native 团队的迭代节奏和传统团队不同。传统团队是两周一个迭代AI Native 团队更适合一周一个小迭代四周一个大迭代。小迭代用来更新上下文、调整 Skill、优化 Agent 编排。 大迭代用来评估整体效果、调整角色分工、决定是否引入新的 Agent 能力。这个节奏的关键是不要等到大迭代才调整。上下文和 Skill 的更新应该是持续的小迭代就是给这个持续更新留出时间。11. 我自己的几个实操心得第一个心得CLAUDE.md 要当代码来维护。我们团队把 CLAUDE.md 放进了 Git每次修改都要走 PR 流程有 review有 commit message。这样做的效果是上下文的变更历史清晰可查出问题时能快速定位是哪次修改引入的。第二个心得Skill 要当产品来设计。每个 Skill 都要有明确的触发条件、执行步骤、注意事项、测试用例。我见过太多团队把 Skill 写成一段模糊的提示词结果 Agent 触发时行为不稳定。Skill 的质量直接决定了 Agent 的可靠性。第三个心得不要追求全自动。我试过让 Agent 全自动完成一个功能从需求到部署结果在部署环节出了问题回滚花了两个小时。现在的做法是Agent 负责 80% 的工作人工负责 20% 的关键决策。这个比例下效率提升明显风险可控。第四个心得定期做Agent 能力评估。每个月花半天时间让 Agent 做几个标准任务比如给这个模块加一个接口记录首次通过率、人工修正时间、遇到的问题。这个评估帮我们看清了 Agent 能力的边界也帮我们发现了上下文的盲区。第五个心得团队共识比工具重要。AI Native 转型最大的阻力不是技术而是人的习惯。我见过团队买了最贵的 Agent 工具但工程师还是习惯自己写代码Agent 只是用来补全。转型成功的关键是让团队真正相信人管意图、Agent 执行这个模式并且愿意花时间维护上下文和 Skill。最后分享一个具体的技巧在 CLAUDE.md 里加一个最近踩的坑章节。每次遇到 Agent 犯的错就加一条进去。这个章节不需要很正式就是一句话描述问题加一句话描述修复。我自己的团队这个章节已经积累了 30 多条每次新成员加入读一遍这个章节就能避开大部分坑。这个做法比写正式的规范文档有效得多因为它是从真实问题中长出来的。