AiCoding实用技巧与完整流程

AiCoding 实用技巧与完整流程：把 20 人日任务拆成 AI 能稳定完成的工程系统

调研日期：2026-06-09
适用对象：已经在使用 Claude Code、Codex、Cursor、Windsurf/Devin、Cline、GitHub Copilot Agent、Qwen Code、Kimi Code、Roo/OpenCode 等工具，希望把 AI 从“代码助手”提升为“可控执行者”的研发团队。

高手与普通使用者的差别，不在于会不会写 Prompt

同样是一个 20 人日开发任务，有的人能让 AI 稳定推进，有的人会陷入反复返工。差异通常不在模型本身，而在“工程系统”。

普通使用者经常把 AI 当成一个更聪明的搜索框：把需求丢进去，让它规划、执行、验收。这样处理小任务没有问题，但任务一旦跨模块、跨系统、跨多天上下文，就会出现几个典型失败：模型读了太多文件后开始遗忘目标，计划看似完整但无法落地，代码改动过大导致 review 困难，测试失败后开始绕路，修一个 bug 又引入两个新问题，最后人类不得不重新接管。

擅长 AiCoding 的人有一套完全不同的做法。他们会把任务改造成 AI 容易处理的形态：先把模糊目标变成验收标准，把大范围探索移出主上下文，把工作切成可独立验证的阶段，把必须执行的动作交给工具和 hooks，把易错知识沉淀到 AGENTS.md、CLAUDE.md、rules 或 skills，把 code review、测试、截图、日志分析拆给独立上下文的子 Agent。AI 不再是“一个聊天窗口”，而是被放进一个有边界、有记忆、有工具、有门禁的工程流水线。

这篇文章的核心观点是：AiCoding 的实用技巧，本质上是把软件工程里的不确定性、上下文、验证和协作问题显式化。Prompt 只是其中一层，更关键的是任务拆解、上下文工程、工具编排、分阶段验收和风险控制。

调研观察：成熟工具的最佳实践正在收敛

几个主流工具虽然产品形态不同，但最佳实践正在收敛。

Anthropic 的 Claude Code 文档明确强调：要给 Claude 一个可以运行的验证方式，例如测试、构建或截图；复杂任务应先探索、再计划、再实现；CLAUDE.md 适合保存项目级规则，但要短，因为过大的指令文件会降低实际遵循率；hooks 适合做“必须发生”的动作，因为它们比自然语言指令更确定；subagents 适合把调查、日志、测试和 review 这类噪声工作放进独立上下文。OpenAI 的 Codex 文档也把 AGENTS.md、sandbox、approvals、subagents、compaction 和 agent loop 作为核心能力。Aider 的 repo map 说明了另一件事：上下文不是越多越好，关键是把仓库里最相关、最能连接依赖关系的代码片段放进 token 预算。Windsurf、VS Code Copilot 和 Cline 也都支持 rules、instructions、AGENTS.md 或 memory bank，用来解决跨会话上下文丢失和团队规则复用的问题。

学术和安全研究则提醒我们，不要把这些配置文件神化。2026 年一篇关于 AGENTS.md 的研究发现，仓库级上下文文件如果写得太泛、太重，反而可能降低任务成功率，并增加 20% 以上的推理成本。另一篇关于 agentic coding 配置的研究显示，大多数团队仍停留在静态 context file，skills、subagents、hooks 这类高级机制采用率较低。安全方面，OWASP 将 Prompt Injection 列为 LLM 应用核心风险，Cloud Security Alliance 也指出 README、AGENTS.md、.cursorrules 等会被自动读取的仓库文件可能变成间接提示注入攻击面。MCP 虽然已经成为连接外部工具和数据源的重要标准，但相关研究也发现了 tool poisoning、权限扩大和可维护性问题。

这些材料放在一起，可以得到一个务实结论：有效的 AiCoding 不等于“给 AI 更多上下文和更多权限”。有效的 AiCoding 是给 AI 正确的上下文、明确的边界、合适的工具、可运行的反馈，以及在每个风险点设置人工或自动门禁。

一套基础心智模型：AI 是概率执行者，不是项目负责人

要把 AI 用好，先要对它有一个准确定位。

AI 很擅长在已有上下文中生成候选方案、识别模式、写样板代码、补测试、读日志、解释调用链、并行分析多个文件。它不擅长天然记住项目真实目标，也不天然知道哪些风险不能碰，更不会真正对生产结果负责。它可以像一个非常快、非常博学、偶尔会误解上下文的执行者，但不应该被当成项目负责人。

所以完整流程要解决四件事。

第一，把目标变成验收条件。只说“实现订单退款功能”太宽泛，应该变成“支持原路退款和余额退款，退款状态可追踪，幂等键防止重复退款，已有订单状态机不破坏，新增接口通过契约测试，后台页面能显示退款失败原因”。

第二，把探索和执行隔离。探索阶段会读取大量文件、日志、文档和历史提交，这些内容会污染主上下文。高手会让子 Agent 或临时会话做探索，只把结论、证据和文件引用带回主会话。

第三，把每个阶段做成闭环。一个阶段不是“改完一堆代码”，而是“明确输入、修改范围、验证命令、验收条件、回滚点”。没有闭环，AI 很容易越改越大。

第四，把经验沉淀到工具，而不是一直靠人提醒。凡是每次都要做的事情，例如运行格式化、禁止修改迁移脚本、检查 secrets、补充 PR 模板，应该进入 hooks、rules、skills 或 CI，而不是写进一次性 prompt。

技巧一：任务拆解不是按功能拆，而是按可验证闭环拆

很多人拆任务时会自然拆成“前端、后端、数据库、测试”。这对人类团队分工有用，但对 AI 不一定好。AI 最适合处理的是边界清晰、反馈明确、改动可验证的小闭环。

以 20 人日的“订单退款能力改造”为例，不要把任务拆成“写退款 API、写前端、写测试”。更好的拆法可能是：

先做状态机与数据模型的最小变更，验证老订单流程不受影响；再做退款请求的幂等层，只测试重复请求行为；再接第三方支付退款接口，用 fake adapter 或 sandbox；再做后台查询和失败原因展示；最后做端到端验收和异常补偿。每一段都能独立验证，每一段失败都不会把整个任务拖进混乱状态。

判断一个子任务是否适合交给 AI，可以看五个条件：目标能否用一句话描述，涉及文件是否大致可控，验证命令是否明确，失败后是否容易回滚，输出是否能被 review。如果这五点做不到，就不要急着让 AI 写代码，而是先让 AI 做探索或设计。

还有一种常见误区是把任务拆得太碎。比如“创建文件 A、创建函数 B、添加参数 C”这种拆法会让 AI 丢失业务意图，只能机械执行。更好的粒度是“实现一个可被测试证明的行为”。功能切片应该小，但不能小到没有语义。

技巧二：上下文管理是 AiCoding 的核心能力

模型上下文像工作台，不是仓库。工作台上应该放当前任务需要的工具、材料和图纸，而不是把公司所有文档都堆上来。

高手通常会把上下文分成五层。

第一层是稳定规则，例如技术栈、测试命令、代码风格、安全红线、目录结构。这些适合放进 AGENTS.md、CLAUDE.md、.github/copilot-instructions.md、Cursor/Windsurf rules 等团队共享文件。它们应该短、具体、可执行。比如“修改 TypeScript 代码后运行 npm run typecheck”和“支付模块禁止直接读取环境变量，统一使用 config/payment.ts”，比“遵循最佳实践”有效得多。

第二层是任务简报。它只服务当前任务，包含目标、范围、非目标、验收标准、关键文件、风险、阶段计划。它可以是 docs/ai-tasks/refund-v1.md，也可以是 issue 描述。20 人日任务一定要有这层，否则长会话压缩后模型会忘记最初的边界。

第三层是动态工作记录，例如 CURRENT_PHASE.md、activeContext.md、progress.md、task-log.md。Cline 的 Memory Bank 方法把项目背景、当前工作、系统模式、技术上下文和进度拆成多个 Markdown 文件，本质上就是把“会话记忆”外部化。长任务中，AI 每完成一个阶段都应更新当前状态：已经完成什么，验证了什么，下一步是什么，哪些决策不能反悔。

第四层是按需知识，例如某个 SDK 文档、支付网关接口、设计系统规范、数据库表说明。这些不应该全部塞进主规则文件，而应该通过 Skill、MCP、文档链接或任务中显式引用按需加载。Claude Skills 的 progressive disclosure 思路很重要：入口文件只写什么时候使用、怎么导航，详细参考和脚本放到支持文件里，需要时再读。

第五层是噪声上下文，例如完整测试日志、构建输出、大段 diff、搜索结果、历史聊天。它们对判断有用，但不应该长期留在主会话。做法是让子 Agent 分析，或者让 AI 把日志总结成“错误类型、最相关栈帧、可能原因、下一步命令”，再把原始日志从主上下文中移除。

上下文管理的一个反直觉原则是：少而准，经常比多而全更强。关于 AGENTS.md 的研究也支持这个判断：不必要的仓库要求会让任务更难，人工编写的上下文文件应描述最小必要规则。一个 300 行的规则文件通常不如 40 行高信号规则加几个按需 Skill。

技巧三：让 AI 先采访你，而不是让它直接写计划

复杂任务最容易失败的地方，是一开始需求就没问清楚。人类工程师会在评审会上追问边界条件，AI 默认可能不会问，尤其当用户语气很确定时，它会倾向于直接执行。

对 20 人日任务，推荐第一步就让 AI 采访你：

我要做一个中等复杂度功能，不要急着设计和写代码。 请先像资深工程师做需求澄清一样采访我。 问题要覆盖：业务目标、非目标、用户路径、数据一致性、异常场景、权限、安全、性能、兼容性、测试、上线和回滚。 每轮最多问 8 个问题，问完后把已确认的信息整理成任务简报。

这样做的好处不是让 AI “更礼貌”，而是强制暴露隐含假设。比如“退款失败后是否允许再次发起”“部分退款是否支持”“支付网关超时后状态如何处理”“后台角色是否都能看失败原因”。这些问题如果不在前期问出来，后面就会变成重构成本。

更好的方式是把采访输出沉淀成结构化任务简报，并让人类确认。任务简报一旦确认，就成为后续 prompt 的主要依据。不要让模型依赖散落在聊天历史里的回答。

技巧四：探索阶段要产出证据，不要只产出观点

很多人会问 AI：“帮我看看应该怎么改。”模型会给出看起来合理的方案，但不一定真的读过相关代码。更可靠的探索 prompt 应该要求证据：

请只做代码探索，不修改文件。 目标：理解订单状态机、支付退款适配器、后台订单详情页之间的关系。 输出： 1. 相关文件列表，每个文件说明为什么相关。 2. 当前调用链，用文件和函数名表示。 3. 已有测试覆盖情况。 4. 可能复用的接口或模式。 5. 不确定点，标注需要我确认还是需要继续查代码。 每个结论都要带文件路径或命令证据。

证据化探索有三个好处。它能防止模型凭经验编造架构；它能让人类快速判断探索是否到位；它也能形成后续阶段的上下文索引。对于大仓库，可以让多个子 Agent 分别探索“状态机”“支付适配器”“后台页面”“测试体系”，主会话只接收每个子 Agent 的摘要。

探索阶段不要过早要求模型写完整方案。此时更需要的是代码地图、风险点和可选路径。方案应该建立在证据上，而不是建立在模型的通用软件工程想象上。

技巧五：计划要有决策点，不要只有任务列表

AI 很擅长生成任务列表，但任务列表不等于工程计划。一个可执行计划至少要包含：目标、阶段、每阶段输入输出、改动文件、测试方式、风险、回滚点、人工确认点。

普通计划像这样：

1. 修改数据库 2. 添加退款接口 3. 实现前端页面 4. 添加测试

更适合 AiCoding 的计划应该像这样：

阶段 1：建立退款状态模型 范围：只改订单状态枚举、退款记录实体、状态转换测试。 不做：不接支付网关，不改后台页面。 验收：订单原有状态机测试全部通过；新增退款状态转换测试覆盖成功、失败、重复请求。 风险：旧订单状态兼容；迁移脚本回滚。 人工确认点：字段命名和状态枚举是否符合团队约定。

为什么要这么写？因为 AI 执行时最需要的是边界。没有“不做什么”，它会主动把后续阶段也改掉；没有验收，它会把“看起来完成”当成完成；没有人工确认点，它会替你做业务决策。

是否有更好的方式？有。对于高风险改造，可以先让两个模型或两个子 Agent 独立出方案，再让 reviewer 模型做 trade-off 对比。对中等风险任务，一个主方案加一个备选方案通常够用。不要为小任务搞过度设计，文档成本会超过收益。

技巧六：Prompt 工程的重点是约束行为，而不是堆形容词

有效 prompt 不需要“你是世界顶级工程师”这种套话。它要给出任务目标、上下文入口、约束、验证方式、输出形式和停止条件。

一个通用任务 prompt 可以这样写：

任务目标： 实现 [具体行为]，使 [用户/系统] 在 [场景] 下可以 [结果]。 上下文入口： - 先阅读 @docs/ai-tasks/refund-v1.md - 重点检查 src/orders、src/payments、tests/orders - 如果发现任务简报与代码不一致，先停下来说明，不要直接改。 约束： - 只做当前阶段，不处理后续阶段。 - 不改变 public API，除非计划中明确写了。 - 不添加新依赖，除非先说明必要性并等待确认。 - 保持 diff 小，优先复用现有模式。 验证： - 先写或更新能失败的测试。 - 修改后运行 npm run test:orders 和 npm run typecheck。 - 如果测试无法运行，说明原因和手动验证步骤。 输出： - 修改摘要 - 验证结果 - 风险和遗留问题

这里每一行都有用。上下文入口降低搜索成本；“不一致先停”防止模型基于错误假设继续写；“只做当前阶段”控制范围；验证命令让模型有反馈；输出格式方便 review。

Prompt 还有几个实用技巧。

描述症状比描述猜测更好。不要说“修复缓存 bug”，而是说“用户在修改邮箱后 5 分钟内个人资料页仍显示旧邮箱，怀疑缓存失效路径有问题，但请以代码证据为准”。

引用现有模式比抽象要求更好。不要说“按项目最佳实践实现”，而是说“参考 src/billing/invoiceService.ts 的事务处理和 tests/billing/invoiceService.test.ts 的测试风格”。

要求 AI 先复述边界。对于复杂任务，先让它输出“我理解本阶段要做/不做的事情”，人类确认后再执行。

要求 AI 提供失败判断。比如“如果你认为当前阶段无法安全完成，请说明阻塞原因，而不是硬做”。这能减少模型为了完成任务而过度自信。

技巧七：把验证设计前置，AI 的可靠性会明显提升

成熟工具文档都反复强调：给 Agent 一个能运行的检查。没有检查的任务，人类必须一直盯；有检查的任务，AI 才能在失败后迭代。

验证可以分层。

最快的是静态验证：类型检查、lint、格式化、schema 校验、生成文件一致性检查。它们反馈快，适合在每个小阶段后运行。

其次是单元测试和契约测试。AI 修改逻辑时，最好先让它写一个失败测试，再改代码让测试通过。对于 bug 修复，这尤其有效，因为测试能防止模型修错地方。

再往上是集成测试、端到端测试、截图对比、性能基准、日志检查。前端任务尤其不能只看代码，应该让 AI 启动页面、截屏、检查响应式布局和交互状态。

最高层是人工验收。AI 可以帮忙准备验收脚本、测试账号、数据构造和 PR 描述，但最终是否符合业务目标，需要人负责。

验证前置还有一个副作用：它会改善任务拆解。如果某个阶段无法定义验证方式，说明这个阶段边界还不清楚，应该继续拆或改成探索任务。

技巧八：执行阶段采用“小步闭环”，而不是长时间自动驾驶

20 人日任务不能让 AI 一口气从设计写到上线。更稳的方式是小步闭环：

读取当前阶段简报 确认要改的文件和不改的文件 写测试或更新测试 做最小实现 运行目标验证 修复失败 自查 diff 更新阶段记录 等待下一阶段指令

每个闭环最好控制在 30 分钟到 2 小时的人类审查粒度。AI 实际执行可能更快，但审查粒度不能太大。一个阶段产生 200 行可解释 diff，通常比一次性产生 2000 行 diff 更容易合并。

小步闭环的关键是让 AI 每次只持有一个明确目标。不要在同一个 prompt 里同时要求它“重构状态机、接支付网关、改后台页面、补 e2e、优化性能”。模型会尝试并行满足所有要求，结果往往是每个都做得半截。

有没有更激进的方式？有。对于机械性迁移、批量替换、文档生成、简单测试补齐，可以让 AI 进入更自动化的 fan-out 模式，甚至多个会话并行。但前提是变更边界清晰、验证命令可靠、冲突成本低。写-heavy 的并行任务要谨慎，因为多个 Agent 同时改代码会带来合并冲突和架构不一致。

技巧九：Code Review 要独立上下文，最好分角色

让同一个会话 review 自己刚写的代码，效果有限。模型会受前文计划和自己刚做的决策影响，倾向于解释为什么合理。更好的方式是使用独立会话或子 Agent，让它只看 diff、任务简报和项目规则。

一个高质量 review prompt 可以这样写：

请以严格代码审查方式检查当前 diff。 不要总结优点。 优先找会导致线上故障、数据错误、安全问题、权限绕过、性能退化、兼容性破坏或测试缺口的问题。 每个问题必须包含：严重级别、文件位置、触发条件、影响、建议修复、需要补充的测试。 如果没有高置信问题，请明确说没有发现，并列出剩余风险。

对于 20 人日任务，可以把 review 拆给三个角色。

安全 reviewer 只看权限、输入校验、敏感信息、依赖、命令执行、提示注入、数据泄漏。

测试 reviewer 只看测试覆盖、边界条件、是否过度 mock、是否缺少回归测试。

维护性 reviewer 只看架构边界、重复代码、命名、可读性、与现有模式的一致性。

为什么分角色？因为一个模型在一次 review 中很容易泛泛而谈。分角色能提高问题密度，也能避免“看了很多但都不深”。OpenAI Codex 的 subagent 文档也建议把并行子 Agent 用于安全、测试缺口、可维护性这类独立分析，并让主线程汇总。

技巧十：用 Hooks 处理“每次都必须发生”的事

很多团队把大量规则写进 AGENTS.md 或 CLAUDE.md：“每次改完代码都运行 lint”“不要提交 secrets”“不要改 migrations”“写完测试要格式化”。这些指令有用，但它们只是建议，模型可能忘。

Hooks 的价值在于确定性。比如 Claude Code hooks 可以在工具调用前后运行脚本，PreToolUse 可以拦截危险命令，PostToolUse 可以在文件编辑后自动运行格式化或检查。Codex 也有 sandbox、approval、rules 等机制来控制命令和权限。工具层面的门禁比自然语言提醒更可靠。

适合做 hook 的事情包括：

• 文件编辑后运行格式化或局部 lint
• 阻止删除关键目录、修改迁移历史、写入 secrets
• 在停止前检查测试是否通过
• 记录 AI 执行过的命令
• 对 package install、数据库操作、云资源操作要求人工审批

不适合做 hook 的事情是复杂业务判断。比如“退款逻辑是否正确”不能靠 hook 判断，应该靠测试和 review。Hook 是安全带，不是架构师。

更好的方式是把高频、低歧义、可脚本化的要求从 prompt 中移出去。这样既节省上下文，也减少模型忘记执行的概率。

技巧十一：Skills 适合封装“低频但复杂”的团队知识

Skills 与规则文件的区别，在于它们按需加载。稳定规则每次都需要，放在 AGENTS.md/CLAUDE.md；复杂流程不是每次都需要，放在 Skill。

适合做 Skill 的场景包括：

• 新建 API 端点的团队规范
• 支付网关接入流程
• 前端组件验收流程
• 数据库迁移 checklist
• 安全审查流程
• 发布说明生成
• 特定 SDK 的使用方法与版本坑

一个好 Skill 的入口文件应该短，说明什么时候使用、使用步骤、需要读哪些支持文件、可以运行哪些脚本。详细 API 文档、示例、模板、校验脚本放到 Skill 目录下的 reference、examples、scripts 中。这样模型平时不背负大量上下文，真正需要时又能获得完整流程。

是否所有流程都应该做 Skill？不。只执行一次的任务没有必要。Skill 应该服务重复出现、容易出错、跨项目复用或需要支持文件的流程。如果一个规则只有一句话，就放 rules；如果一个动作必须强制执行，就放 hook；如果要连接外部系统，就考虑 MCP；如果要隔离上下文或角色，就用 subagent。

技巧十二：MCP 的价值是接入真实世界，但不要滥用权限

MCP 是把 AI Agent 连接到外部工具和数据源的开放标准。它能让 Agent 查询 GitHub、Linear、Slack、数据库、监控系统、Figma、内部文档、日志平台，而不用每个工具都写一套定制集成。

在 AiCoding 中，MCP 最有价值的场景是：

• 从 issue/PR 系统读取真实需求、评论和验收讨论
• 从设计工具读取组件尺寸、颜色、截图和交互说明
• 从数据库或 schema 服务读取表结构
• 从监控平台读取错误日志、trace、指标
• 从文档系统读取最新 API 文档
• 从内部平台触发受控的测试、构建或部署

但 MCP 也扩大了攻击面。MCP server 是代码和权限边界，不只是“上下文来源”。研究已经指出 MCP 生态存在 tool poisoning、权限组合导致数据外泄、服务器可维护性等问题。因此使用 MCP 要遵循最小权限：只接入当前任务需要的 server，只暴露必要工具，敏感操作要人工审批，外部仓库和第三方 MCP 不要默认信任。

一个实用判断是：如果信息是静态、低频更新的，优先放文档或 Skill；如果信息是动态、需要查询权限或实时系统状态，才使用 MCP；如果动作有副作用，例如发消息、改 issue、写数据库、部署，就必须有权限边界和确认机制。

技巧十三：用子 Agent 处理噪声、并行和偏见

子 Agent 的核心作用不是“显得高级”，而是隔离上下文。主会话应该保留需求、决策、计划和最终输出；子 Agent 负责会产生大量中间信息的工作，例如搜索、日志分析、测试失败定位、依赖扫描、代码审查。

适合子 Agent 的任务有：

• 阅读大量文件后输出架构摘要
• 并行调查多个模块
• 分析长日志或测试失败
• 独立 review 当前 diff
• 安全、性能、测试缺口专项检查
• 大规模文档或代码批处理的分块总结

不适合子 Agent 的任务是高耦合写代码。多个 Agent 同时写同一片代码，通常会带来冲突。若必须并行写代码，应该使用 git worktree，把模块边界切开，并要求每个 Agent 只改自己的目录。

子 Agent 的 prompt 要说明三件事：任务边界、需要返回什么、不要返回什么。不要让它把所有搜索结果贴回主会话，要让它返回“结论 + 证据 + 风险 + 下一步”。

请作为独立探索 Agent 调查退款状态机。 只读代码，不修改文件。 返回最多 800 字摘要，必须包含相关文件、关键函数、已有测试、风险点和不确定问题。 不要返回完整源码或长日志。

技巧十四：长任务需要“外部记忆”，不能只靠聊天历史

20 人日任务通常跨越多次会话、多个上下文压缩和多轮 review。只靠聊天历史不稳。你需要外部记忆。

推荐为每个中大型任务建立一个任务目录：

docs/ai-tasks/refund-v1/ ├── task-brief.md # 目标、范围、非目标、验收标准 ├── context-map.md # 相关模块、文件、调用链、术语 ├── plan.md # 阶段计划、依赖、人工确认点 ├── decisions.md # 已做技术决策和原因 ├── active-context.md # 当前阶段、最近变更、下一步 ├── verification.md # 测试命令、验收脚本、已跑结果 └── review-notes.md # AI review 与人工 review 结论

这些文件不是为了形式主义，而是为了让新会话能恢复上下文。每次阶段结束，让 AI 更新 active-context.md 和 verification.md。每次做了不可逆设计选择，更新 decisions.md。每次发现项目坑，判断它是任务级知识还是项目级知识：任务级放当前目录，项目级再沉淀到 AGENTS.md、CLAUDE.md 或 Skill。

有没有更轻的方式？有。小任务只需要 issue 描述和一段当前状态即可。不要为半小时任务建七个文件。但对于 20 人日任务，外部记忆几乎是必要成本。

技巧十五：模型选择要按任务节点，而不是按整件事

同一个任务中，不同节点需要不同模型。

需求澄清、架构方案、风险评估、最终 review，应该用强推理模型。这里犯错代价高，节省 token 没意义。

批量改样板代码、补测试、文档整理、简单脚本，可以用便宜快速模型。这里关键是验证，而不是模型最强。

长上下文探索可以用支持大上下文且成本低的模型，但要要求它输出摘要，不要把所有内容带回主会话。

视觉还原、截图检查、设计稿转代码，要用多模态能力强的模型，并配合浏览器截图或视觉 diff。

安全审查和高风险代码 review，最好双模型交叉。一个模型找问题，另一个模型反驳或补充。不要让写代码的同一个上下文承担最终审查。

这就是为什么“规划 + 执行 + 验收”太粗。真正的模型路由应该更细：采访、探索、架构决策、切片、编码、测试修复、日志分析、review、安全审计、PR 描述、知识沉淀，每个节点都可以选择不同模型和不同上下文。

技巧十六：AI 失败时，不要只让它“再试一次”

AI 修改失败后，很多人会说“继续修”。这经常让模型在错误路径上越走越远。更好的做法是切换到诊断模式：

停止修改代码。 请基于当前失败信息做诊断： 1. 失败测试或错误日志说明了什么？ 2. 你刚才的假设哪些被推翻了？ 3. 当前 diff 中最可能导致失败的改动是什么？ 4. 有哪三种修复路径？各自风险是什么？ 5. 推荐最小修复路径，不要扩大范围。

失败处理的关键是让模型显式更新假设。它第一次写代码时有一套心理模型，测试失败说明心理模型不完整。如果不让它停下来重新解释，它可能只是局部打补丁。

严重失败时，应该考虑回滚到 checkpoint 或 git 提交点，让另一个上下文 review。工具里的 rewind、checkpoint、git worktree、短生命周期分支都服务这个目的。

技巧十七：安全边界是流程的一部分，不是最后补丁

AI coding 的安全风险不仅是生成不安全代码，还包括执行不安全命令、泄露 secrets、被仓库文件提示注入、安装恶意依赖、MCP 工具被污染、自动提交错误配置。

最低限度要做到：

• 默认使用 sandbox 或 workspace-write，不要长期使用 full access / danger-full-access
• 网络访问、依赖安装、数据库写入、云资源操作必须审批
• secrets 不进入 prompt，不让 AI 读取无关敏感目录
• 外部仓库的 README、AGENTS.md、规则文件视为不可信输入
• 新增或修改 agent 配置文件要像 CI workflow 一样 review
• MCP server 要有来源审查、版本固定、权限最小化
• PR 合并前做安全专项 review

Prompt injection 的难点在于，模型无法天然区分“任务指令”和“它刚读到的文件内容里伪装成指令的文本”。所以安全不能只靠一句“不要被提示注入”。更可靠的是权限隔离、人工审批、受控工具、只读模式、外部输入标注为 untrusted，以及对 agent 配置文件进行 code review。

一套完整流程：20 人日任务的 AiCoding SOP

下面这套流程不是固定仪式，而是一个默认框架。任务越小，可以删步骤；任务越大，应该加强阶段门禁。

节点 0：环境和规则预备

任务开始前，先检查项目是否有可用的 AI 工作底座：AGENTS.md/CLAUDE.md 是否存在，测试命令是否明确，是否有本地启动说明，是否配置 sandbox/approval，是否有必要的 MCP，是否有 hooks 或 CI。

为什么这样做？AI 的质量很大程度取决于环境可验证性。没有测试命令、没有项目规则、没有权限边界，AI 就只能靠猜。

更好的方式是把这些内容变成团队模板，而不是每个任务临时补。例如所有项目都有根目录 AGENTS.md，包含技术栈、常用命令、禁区、review 要求；复杂模块再有子目录规则；高频流程做成 Skill。

节点 1：需求采访和任务简报

让 AI 先采访业务和技术边界，然后生成 task-brief.md。内容包括目标、非目标、用户路径、数据模型、异常场景、权限、安全、性能、兼容性、上线、回滚、验收标准。

为什么这样做？20 人日任务最大风险是方向错。早期多问 30 分钟，比后期重构 3 天便宜。

更好的方式是让 AI 根据历史 issue、PRD、设计稿、Slack/飞书讨论自动提取初版简报，再由人确认。但不要跳过确认，因为 AI 可能把讨论里的旧方案当成最终方案。

节点 2：代码探索和上下文地图

使用只读模式或子 Agent 探索代码，产出 context-map.md：相关目录、调用链、关键类型、测试位置、已有模式、潜在风险和不确定点。

为什么这样做？AI 需要先知道“这个系统如何工作”，而不是直接套通用方案。探索结果如果没有文件证据，就不能作为计划依据。

更好的方式是并行探索。一个 Agent 看业务流程，一个看数据模型，一个看测试体系，一个看 UI 或 API。主会话只接收摘要，避免上下文污染。

节点 3：风险分级和方案选择

让 AI 给出 2 到 3 个技术方案，每个方案说明改动范围、兼容性、测试成本、上线风险、回滚方式。人类 owner 做最终选择，并记录到 decisions.md。

为什么这样做？模型很容易选“实现起来顺”的方案，而不是“生产风险最低”的方案。显式比较能暴露 trade-off。

更好的方式是双模型对抗：一个模型提出方案，一个模型攻击方案。对于支付、权限、数据一致性、迁移等高风险任务，这一步值得花时间。

节点 4：阶段切片和验收计划

把任务拆成多个可验证阶段，每个阶段包含范围、不做什么、预计改动文件、验证命令、人工确认点。同步写 verification.md。

为什么这样做？阶段是 AI 的执行边界。没有阶段边界，模型会把相关但不该现在做的东西一起改掉。

更好的方式是按“可发布切片”拆，而不是按技术层拆。每个阶段最好能独立通过测试，并且失败时能回滚。

节点 5：Phase 0 Spike 或架构探针

对不确定性最高的点做最小实验。例如验证第三方 SDK 行为、数据库迁移兼容性、状态机扩展方式、前端组件库限制。Spike 的输出是结论，不是最终代码。

为什么这样做？复杂任务往往有一个关键未知点，先验证它能避免后续计划整体失效。

更好的方式是把 Spike 放在临时分支或 worktree。实验代码可以丢弃，保留结论和验证脚本。

节点 6：阶段执行闭环

每个阶段按固定循环执行：重读阶段简报，确认边界，写失败测试或补测试，做最小实现，运行验证，修复失败，自查 diff，更新 active-context.md。

为什么这样做？这是把 AI 从“生成代码”变成“用反馈修代码”的关键。没有测试反馈，AI 只能输出看起来合理的代码。

更好的方式是自动化其中的低风险动作，例如格式化和 lint 用 hook；目标测试命令写进阶段文件；失败日志交给子 Agent 分析。

节点 7：阶段验收和 checkpoint

每个阶段结束，要求 AI 输出修改摘要、验证结果、遗留风险、下一阶段建议。人类 review 后打 checkpoint 或提交小 commit。

为什么这样做？长任务必须有可恢复点。等 20 人日任务全部完成再 review，成本太高。

更好的方式是每个阶段都能形成一个小 PR 或至少一个清晰 commit。团队如果不想频繁开 PR，也应该保留本地提交和阶段文档。

节点 8：集成验证

多个阶段完成后，运行更大范围的验证：全量测试、端到端流程、截图、性能基准、数据库迁移演练、日志检查、兼容性测试。

为什么这样做？局部阶段都通过，不代表组合起来正确。状态机、缓存、权限、异步任务、UI 路由都可能在集成阶段暴露问题。

更好的方式是让 AI 生成一份人工验收脚本，包括测试账号、测试数据、操作步骤、预期结果和回滚方式。这样 QA 或业务验收不依赖聊天记录。

节点 9：独立 AI Review

使用新的上下文或子 Agent 分角色 review：安全、测试、维护性、性能、兼容性。review 输入只给任务简报、diff、相关规则和验证结果。

为什么这样做？独立上下文能减少自我确认偏差。分角色能提高问题密度。

更好的方式是并行 review 后让主会话做 triage：哪些必须修，哪些可以延期，哪些是误报。人类 owner 最终决定。

节点 10：人工 Review 和 PR 打包

让 AI 准备 PR 描述：背景、改动摘要、测试结果、风险、回滚、截图、迁移说明。人类重点 review 行为变化、风险点和 AI 未覆盖的业务判断。

为什么这样做？AI 可以提高 PR 表达质量，但不能替代责任判断。PR 是团队协作界面，不是模型输出展示页。

更好的方式是把 PR 模板做成 Skill 或命令，自动读取 diff、测试结果和 task-brief.md，生成一致格式。

节点 11：上线前安全和运维检查

检查 secrets、权限、日志、监控、告警、feature flag、回滚脚本、数据库迁移、外部依赖、配置开关。必要时让 AI 根据运维规范生成 checklist。

为什么这样做？很多 AI 生成代码的风险不在编译期，而在运行期。尤其是支付、权限、消息队列、定时任务、缓存、迁移。

更好的方式是把高风险上线 checklist 做成团队级 Skill，并把必须项接入 CI 或发布平台，避免靠人记。

节点 12：知识沉淀和规则更新

任务结束后，让 AI 总结：哪些项目规则应该进入 AGENTS.md/CLAUDE.md，哪些流程应该做成 Skill，哪些检查应该做成 hook，哪些坑只属于当前任务。更新文档和团队模板。

为什么这样做？AiCoding 能力是复利。每次任务后如果不沉淀，下次仍然靠人重复提醒。

更好的方式是建立“AI 工程资产库”：项目规则、Skills、hooks、MCP 配置、review prompts、常用验收脚本、失败案例。团队成员共享这些资产，新人也能快速达到较高水平。

流程节点总表

一组可直接复用的 Prompt 模板

需求采访模板

我准备做一个预计 20 人日左右的开发任务：[一句话描述]。 请不要写方案，也不要写代码。先采访我。 请从业务目标、用户路径、数据模型、异常场景、权限、安全、性能、兼容性、测试、上线和回滚角度提问。 每轮最多 8 个问题。问题要具体，不要泛泛问“还有什么要求”。 采访结束后整理成 task-brief.md 格式。

只读探索模板

进入只读探索模式，不要修改文件。 请根据 task-brief.md 调查当前代码如何支持相关流程。 输出 context-map.md： - 相关文件和原因 - 调用链 - 数据模型 - 已有测试 - 可复用模式 - 风险点 - 仍需确认的问题 每个结论都要有文件路径、函数名、测试名或命令证据。

阶段计划模板

基于 task-brief.md 和 context-map.md，把任务拆成 5 到 8 个可验证阶段。 每个阶段必须包含： - 本阶段目标 - 修改范围 - 明确不做什么 - 预计涉及文件 - 验证命令 - 人工确认点 - 风险和回滚方式 优先按可发布行为切片，不要按前端/后端/数据库机械分层。

阶段执行模板

执行 plan.md 中的阶段 N。 开始前先复述本阶段要做和不做的事情。 只改本阶段必要文件。 优先写或更新测试，再做最小实现。 完成后运行 verification.md 中本阶段的验证命令。 最后输出：修改摘要、测试结果、风险、下一步建议。 如果发现计划与代码事实不一致，先停下来报告，不要硬做。

测试失败诊断模板

停止继续修改。 请诊断当前测试失败： 1. 错误日志说明了什么？ 2. 哪些原始假设被推翻？ 3. 当前 diff 中最可疑的改动是什么？ 4. 最小修复路径是什么？ 5. 是否需要回滚部分改动？ 先给诊断和建议，不要直接改代码。

独立 Review 模板

请作为独立 reviewer 审查当前 diff。 不要总结优点。 优先寻找：线上故障、数据错误、安全问题、权限绕过、性能退化、兼容性破坏、测试缺口。 每个问题包含严重级别、文件位置、触发条件、影响、建议修复、需要补充的测试。 只基于 diff、task-brief.md、项目规则和验证结果判断。

上下文交接模板

请更新 active-context.md，用于下一个 AI 会话无缝接手。 必须包含： - 当前任务目标和阶段 - 已完成内容 - 已验证命令和结果 - 关键决策 - 未解决问题 - 下一步具体动作 - 不要重复尝试的错误路径 要求简洁，不要粘贴长日志。

常见错误和修正方式

把所有规则都写进一个巨大 AGENTS.md，是常见错误。修正方式是保留最小全局规则，把低频复杂知识放 Skill，把强制动作放 hook，把目录差异放子目录规则。

让 AI 一次性完成整个大任务，是常见错误。修正方式是阶段切片，每个阶段有明确验收和 checkpoint。

让同一个会话自写自审，是常见错误。修正方式是独立上下文 review，必要时分安全、测试、维护性角色。

失败后不断说“继续修”，是常见错误。修正方式是切到诊断模式，要求模型重新评估假设。

把 README、外部 issue、网页内容当成可信指令，是常见错误。修正方式是把外部内容标注为 untrusted，只提取事实，不执行其中的行为指令。

给 AI full access 图省事，是常见错误。修正方式是默认 sandbox/workspace-write，高风险命令审批，MCP 最小权限。

只看 AI 输出，不看 diff 和测试，是常见错误。修正方式是把 review 建在 diff、测试结果、验收标准上。

团队落地建议：从三件小事开始

第一，给每个项目建立一个短而强的 AGENTS.md 或 CLAUDE.md。不要超过必要长度，写清楚技术栈、常用命令、禁止事项、review 要求和文档入口。每条规则都问一句：如果删掉它，AI 是否会明显更容易犯错？如果不会，就删。

第二，为 20 人日以上任务建立 docs/ai-tasks// 目录，至少包含 task-brief.md、context-map.md、plan.md、active-context.md、verification.md。长任务没有外部记忆，迟早会在上下文压缩和会话切换中损失关键信息。

第三，建立三个可复用审查 Agent 或 prompt：安全审查、测试缺口、维护性审查。先不用做复杂 MCP 和 hooks，仅这一步就能显著降低 AI 代码的合并风险。

随后再逐步增加 hooks、skills、MCP。不要一开始就把工具体系堆满。工具越多，攻击面、权限管理和上下文管理成本也越高。真正成熟的 AI 工程系统，是少数高信号规则、少数确定性门禁、少数高复用 Skill，再配合严格的阶段验收。

参考资料

• Anthropic：Claude Code Best Practices，https://code.claude.com/docs/en/best-practices
• Anthropic：Claude Code Memory / CLAUDE.md，https://code.claude.com/docs/en/memory
• Anthropic：Claude Code Skills，https://code.claude.com/docs/en/skills
• Anthropic：Claude Code Hooks，https://code.claude.com/docs/en/hooks-guide
• Anthropic：Claude Code Subagents，https://code.claude.com/docs/en/sub-agents
• Anthropic：Model Context Protocol 介绍，https://www.anthropic.com/news/model-context-protocol
• Claude Agent SDK：MCP，https://code.claude.com/docs/en/agent-sdk/mcp
• OpenAI：Introducing Codex，https://openai.com/index/introducing-codex/
• OpenAI：Unrolling the Codex agent loop，https://openai.com/index/unrolling-the-codex-agent-loop/
• OpenAI Developers：Codex AGENTS.md，https://developers.openai.com/codex/guides/agents-md
• OpenAI Developers：Codex Subagents，https://developers.openai.com/codex/concepts/subagents
• OpenAI Developers：Codex Sandbox，https://developers.openai.com/codex/concepts/sandboxing
• Aider：Repository Map，https://aider.chat/docs/repomap.html
• Windsurf/Devin：Cascade Memories & Rules，https://docs.devin.ai/desktop/cascade/memories
• VS Code：Copilot Custom Instructions，https://code.visualstudio.com/docs/agent-customization/custom-instructions
• Cline：Memory Bank，https://docs.cline.bot/best-practices/memory-bank
• arXiv：Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?，https://arxiv.org/abs/2602.11988
• arXiv：Configuring Agentic AI Coding Tools: An Exploratory Study，https://arxiv.org/abs/2602.14690
• arXiv：Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance，https://arxiv.org/abs/2602.08915
• OWASP：Top 10 for Large Language Model Applications，https://owasp.org/www-project-top-10-for-large-language-model-applications/
• Cloud Security Alliance：README Injection: Repository Files Hijacking AI Coding Assistants，https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/03/CSA_research_note_readme_instruction_injection_ai_coding_agents_20260317-csa-styled.pdf
• arXiv：Model Context Protocol at First Glance，https://arxiv.org/abs/2506.13538