在一个真实研发团队里，开发者会把不同类型的任务交给 AI Coding Agent：有的是小改动，比如改一个按钮文案；有的是中等改动，比如新增一个 API 字段；也有的是复杂改动，比如重构权限逻辑或改造一条业务流程。
请你回答：
你会如何设计一个判断机制，决定 AI Coding Agent 在什么情况下必须先输出 implementation plan，什么情况下可以直接进入代码修改？
可以重点展开这几个方面：
首先，如果任务包含了跨模块的改动，或者需要外部配合的改动。就需要先给出计划，然后再确认执行。一个好的 plan 里面，首先要有明确的目标，其次要有验收的手段，最后是改动的细节，必要时还要明确不可以改动的范围。先有 plan 主要是避免一次性 review 过多的代码改动，而 plan 本身也不能够量级过大，难以 review，如果通过 plan 已经很难理解改动的范围了，那么应该主动缩小范围，先进行更小范围的修改。
你的回答方向是对的，尤其抓住了两个关键点：跨模块/外部依赖要先 plan，以及 plan 本身也要可 review，不能变成另一个大而空的文档。
主要缺三类内容：
触发 plan 的信号还可以更系统 你提到了跨模块、外部配合，但还可以补充：高风险改动、需求不确定、数据/权限/安全相关、测试边界不清、已有上下文不足等。
plan 的结构还可以更工程化 你说到了目标、验收、改动细节和不可改范围，这是核心。但如果面试中想更完整，可以再加上：
对 plan 的验证机制可以再具体 你提到了 plan 过大时要缩小范围，这很好。还可以补充：让 Agent 先做只读代码调研、要求引用具体文件/函数、用 checklist 审查 plan、禁止未确认前写文件等。
我会把这个机制设计成一个 risk-based gating：低风险、局部、可回滚的小任务可以直接修改；一旦任务存在范围不确定、影响面较大或验证成本较高，就必须先输出 implementation plan，经确认后再执行。
主要看四类信号。
第一类是 改动范围信号。如果任务涉及多个模块、多个服务、公共组件、权限逻辑、数据模型、数据库 migration、接口契约变化，就不能直接改。因为 Agent 很容易在局部理解下做出全局副作用。
第二类是 需求不确定信号。如果用户目标比较抽象，例如“优化 AI Coding 效果”“重构这块逻辑”“让它更稳定”，Agent 应先澄清目标并给出 plan，而不是直接猜实现。
第三类是 风险信号。凡是涉及安全、权限、支付、数据删除、线上配置、CI/CD、依赖升级、批量脚本等高风险操作，都需要先计划，并明确回滚方案和人工确认点。
第四类是 验证复杂度信号。如果改动无法通过单个测试快速验证，或者需要端到端测试、人工验收、跨团队配合，也应该先 plan。
反过来，只有当任务满足 局部、明确、低风险、易验证、易回滚 这几个条件时，才允许 Agent 直接修改代码，例如改文案、补一个明显的类型错误、修一个局部样式问题。
plan 不是写大纲，而是降低误改风险的执行契约。至少包含：
这样 plan 的作用不是“让 Agent 多说几句”，而是提前暴露它对代码库的理解是否正确。
我会对 plan 做三层约束。
第一，先只读调研，再写 plan。Agent 在 plan 阶段只能读取代码、搜索引用、分析调用链，不能修改文件。否则它可能边想边改，失去控制点。
第二，要求 plan 可验证、可 review。plan 不能只说“重构权限模块”，而要具体到“修改 A 文件的 B 函数，新增 C 测试，保持 D 接口不变”。如果 plan 本身已经很长、很难 review，说明任务需要继续拆小。
第三，执行时绑定 plan。进入代码修改后，Agent 只能做 plan 中列出的改动。如果发现需要扩大范围，必须停下来更新 plan 并重新确认，而不是自动蔓延。
所以我的整体原则是：不是所有任务都需要 plan，但凡 Agent 的错误成本高于 plan 的 review 成本，就应该先 plan。plan 的价值在于把隐含理解显性化，把大改动拆成可确认、可验证、可回滚的小步。