Ask、Plan、Craft 怎么选？AI 编程任务的三种执行方式

课堂上讲到 Ask、Plan、Craft 时，我没有让同学们死记按钮，而是让大家判断三个场景：接手陌生项目、开发一个全新模块、修改按钮颜色。三件事都可以交给 AI，但显然不该用同一种工作方式。

模式选择的本质，是根据任务的不确定性和影响范围，决定 AI 先理解、先规划，还是直接执行。

Ask：先建立认知，不急着动代码

Ask 适合回答问题、解释项目和头脑风暴。它的价值是帮助我们快速获得信息，而不是立刻改变项目。

常见场景包括：

• 第一次打开陌生仓库，了解技术栈和目录职责。
• 阅读一段看不懂的代码，追踪调用链。
• 讨论一个功能可能有哪些方案和风险。
• 分析报错可能来自前端、后端还是数据库。
• 在立项前发散用户问题和产品方向。

Ask 阶段最好的结果不是一堆代码，而是一份更清晰的问题地图。对于不了解的事情，先问明白再动手，通常比边改边猜更快。

Plan：复杂任务先获得“可预见性”

Plan 适合新功能、跨文件修改、架构调整和需求仍然存在空白的任务。

一个有效计划至少应该说明：

• 当前需求和不做的范围。
• 会影响哪些模块和数据。
• 技术选型是否沿用现有架构。
• 任务之间有什么依赖关系。
• 每一步完成后如何验证。
• 风险出现时如何回退。

CodeBuddy 当前官方文档也把 Plan 描述为在理解和执行之间加入规划阶段，支持需求澄清、方案生成、人工确认再执行。这个设计真正有价值的地方，不是多了一份文档，而是让开发者在代码生成前看到 AI 准备做什么。

训练营里生成原型的对比很直观：直接把 PRD 交给 AI，页面可能缺功能、风格随机；先进入 Plan，回答技术栈、页面范围和保真度问题，结果通常更完整。规划不能保证一定好看，但能显著减少“做错东西”。

Craft：范围明确时直接完成

Craft 适合目标清楚、影响局部、验收简单的任务，例如：

• 修改一处明确的文案或样式。
• 修复已经定位到原因的 Bug。
• 给现有函数补一组边界测试。
• 按既定迁移规范增加一个字段。
• 清理已经确认无用的 Demo 代码。

这类任务如果强行先写长计划，规划成本可能高于实施成本。直接执行、立即验证、完成后提交，反而更合适。

用两个维度做判断

我建议用“不确定性”和“影响范围”快速选择：

例如“登录失败”不一定是小任务。如果不知道原因，先用 Ask 追踪请求、日志和数据库；原因确认只是字段名错误后，再用 Craft 修复。相反，“新增会员体系”即使描述很清楚，也涉及页面、接口、数据和权限，仍然需要 Plan。

模式可以切换，不是三选一

真实项目里经常是一条连续链路：

1. 用 Ask 熟悉项目并识别问题。
2. 用 Plan 澄清范围、技术方案和任务清单。
3. 人工评审计划，补充遗漏。
4. 进入执行阶段完成主体开发。
5. 局部报错切到 Craft 快速修复。
6. 回到计划核对所有验收项。

重点是每次切换都有理由，而不是让 AI 在一个模糊会话里持续自由发挥。

常见误区

• 简单任务过度规划：改一个标题却产出十页方案，浪费时间。
• 复杂任务直接开写：没有确认数据模型就同时改前后端，返工巨大。
• 计划从不评审：AI 写完方案就自动执行，Plan 退化成形式。
• 只看完成提示：模式显示 Finished，不代表真实功能可用。
• 一次计划塞完整项目：范围太大后，命名、样式和接口仍会漂移。

讲师判断：模式选择本质上是在配置风险

Ask、Plan、Craft 并不是三个等级，也不是从初级到高级的固定顺序。它们对应的是不同的不确定性。如果问题尚未理解，先 Ask；如果目标明确但路径复杂，先 Plan；如果改动小、边界清晰并且容易回归，就直接 Craft。模式选错的代价，通常表现为无意义的长计划或失控的大范围修改。

在团队项目里，我还会要求把模式选择写进任务记录。这样复盘时可以区分：问题来自需求没说清、计划漏项，还是执行偏离。久而久之，学生积累的不是按钮记忆，而是一套根据风险配置工作方式的判断框架。

课后练习

列出你手头的五个开发任务，为每个任务标记不确定性和影响范围，再选择 Ask、Plan 或 Craft。重点写出选择理由，以及该模式结束时你必须拿到什么证据。