AI 编程为什么要先 Plan 再 Edit？
TL;DR
解释 AI 编程中的 Plan mode 如何提前发现需求误解、边界遗漏和过大改动，并给出可执行的计划与验证方法。
Plan mode 给 AI 编程增加了一个先理解、再修改的阶段。本文解释计划如何提前暴露需求误解、遗漏边界和过大改动范围，并给出适合普通用户的计划、执行、验证节奏。
很多人第一次使用 AI 编程工具时，会直接输入“帮我把这个功能做出来”。模型很快开始搜索文件、生成代码，几分钟后却发现改动范围越来越大，原本一句话的需求变成一串互相牵连的问题。Plan mode 的价值，就在于给“开始修改”增加一个短暂但重要的阶段：先让 AI 说明它理解了什么、准备怎么做，以及哪里可能出错。
计划不是形式，而是一次低成本的需求审查
人在读计划时，最容易发现三类问题。第一，AI 是否把需求理解错了，例如把“仅本人可见”理解成“登录后可见”。第二，它是否漏掉了边界，例如空状态、权限不足、旧数据和失败重试。第三，它是否打算触碰不该修改的文件，例如为了改一个按钮而重写整个路由。
这些错误如果在写代码之后才发现，返工成本通常更高；如果在计划阶段发现，只需要改一段描述。计划模式并不会让模型变聪明，却能让错误更早暴露，让人把注意力放在目标、约束和验收条件上。
一份好计划应该包含什么
不要满足于“我会修改前端和后端，最后运行测试”这种空泛总结。一个有用的计划至少要回答：
- 会先阅读哪些文件，为什么要读它们？
- 哪些接口、数据结构和公开行为不能改变？
- 会分成哪些独立步骤，每一步如何验证？
- 哪些地方存在不确定性，需要人做决定？
- 如果中途失败，怎样回退或保留已有功能？
例如要给账单页面增加筛选，计划应该说明筛选条件来自哪里、时间范围如何解释、分页是否要重新计算、旧链接能否继续打开。它不需要提前写出所有代码，但必须把真正的决策点暴露出来。
先计划再执行，不等于拒绝迭代
计划不是一次性合同。执行第一步后，模型可能发现真实代码和文档不一致，或者测试显示原来的假设不成立。这时应该更新计划，而不是为了遵守旧计划继续向前冲。好的流程是：计划、完成一个小切片、检查结果、根据证据调整下一步。
可以要求 AI 在每个阶段暂停，并报告实际改动、测试结果和新发现。这样人不会只在任务结束时才看到一大份 diff，也不会把所有判断压到最后一刻。
什么任务尤其适合 Plan mode
跨多个目录的功能、涉及数据库和接口的改动、遗留代码重构、权限逻辑和需要多轮测试的任务，都值得先计划。相反，改一个拼写、解释一段函数或修复一个明确的类型错误，直接在编辑器里小步处理可能更快。
关键不是每次都强制计划，而是根据改动的半径和失败代价选择流程。计划越具体，越容易审查；执行越分段，越容易回滚。
普通用户怎样开始
可以把提示写成：“先不要修改文件。请阅读相关代码，复述需求，列出实现步骤、风险、不会修改的范围和验证方式。等我确认计划后再执行。”如果工具支持计划模式，就先在该模式下运行；如果不支持，也可以用这句话人为建立一个暂停点。
AI 编程的速度很容易让人误以为“越快开始写越高效”。实际上，面对复杂任务，最便宜的错误是计划里的错误。先花几分钟确认方向，往往比最后花几小时收拾一堆局部正确的补丁更划算。
