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 fileskills、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 一样 reviewMCP server 要有来源审查、版本固定、权限最小化PR 合并前做安全专项 reviewPrompt 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 的执行边界。没有阶段边界模型会把相关但不该现在做的东西一起改掉。更好的方式是按“可发布切片”拆而不是按技术层拆。每个阶段最好能独立通过测试并且失败时能回滚。节点 5Phase 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、常用验收脚本、失败案例。团队成员共享这些资产新人也能快速达到较高水平。流程节点总表节点主要产物AI 角色人类角色关键门禁环境预备AGENTS/CLAUDE/rules、测试命令、权限配置检查和补建议确认权限和工具sandbox、测试可运行需求采访task-brief.md提问、整理回答、确认验收标准清晰代码探索context-map.md只读探索、证据整理判断探索是否充分文件证据和不确定点方案选择decisions.md方案和 trade-off做最终决策风险和回滚明确阶段切片plan.md、verification.md拆阶段、定义验证调整优先级每阶段可验证Spike实验结论最小实验判断是否采用不把实验代码混进主线阶段执行小 diff、测试结果编码、修复审查边界目标测试通过阶段验收checkpoint、active-context.md总结、更新状态阶段 review可恢复点集成验证验收脚本、全量结果跑测试、查日志判断发布风险全链路验证独立 Reviewreview-notes.md分角色审查triage高风险问题清零PR 打包PR 描述、截图、回滚说明整理材料最终 review团队 review 通过知识沉淀更新规则/Skill/hook总结可复用资产选择沉淀范围不污染全局规则一组可直接复用的 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再配合严格的阶段验收。参考资料AnthropicClaude Code Best Practiceshttps://code.claude.com/docs/en/best-practicesAnthropicClaude Code Memory / CLAUDE.mdhttps://code.claude.com/docs/en/memoryAnthropicClaude Code Skillshttps://code.claude.com/docs/en/skillsAnthropicClaude Code Hookshttps://code.claude.com/docs/en/hooks-guideAnthropicClaude Code Subagentshttps://code.claude.com/docs/en/sub-agentsAnthropicModel Context Protocol 介绍https://www.anthropic.com/news/model-context-protocolClaude Agent SDKMCPhttps://code.claude.com/docs/en/agent-sdk/mcpOpenAIIntroducing Codexhttps://openai.com/index/introducing-codex/OpenAIUnrolling the Codex agent loophttps://openai.com/index/unrolling-the-codex-agent-loop/OpenAI DevelopersCodex AGENTS.mdhttps://developers.openai.com/codex/guides/agents-mdOpenAI DevelopersCodex Subagentshttps://developers.openai.com/codex/concepts/subagentsOpenAI DevelopersCodex Sandboxhttps://developers.openai.com/codex/concepts/sandboxingAiderRepository Maphttps://aider.chat/docs/repomap.htmlWindsurf/DevinCascade Memories Ruleshttps://docs.devin.ai/desktop/cascade/memoriesVS CodeCopilot Custom Instructionshttps://code.visualstudio.com/docs/agent-customization/custom-instructionsClineMemory Bankhttps://docs.cline.bot/best-practices/memory-bankarXivEvaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?https://arxiv.org/abs/2602.11988arXivConfiguring Agentic AI Coding Tools: An Exploratory Studyhttps://arxiv.org/abs/2602.14690arXivComparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptancehttps://arxiv.org/abs/2602.08915OWASPTop 10 for Large Language Model Applicationshttps://owasp.org/www-project-top-10-for-large-language-model-applications/Cloud Security AllianceREADME Injection: Repository Files Hijacking AI Coding Assistantshttps://labs.cloudsecurityalliance.org/wp-content/uploads/2026/03/CSA_research_note_readme_instruction_injection_ai_coding_agents_20260317-csa-styled.pdfarXivModel Context Protocol at First Glancehttps://arxiv.org/abs/2506.13538