Craft Plan Ask 三种工作模式解析

# WorkBuddy 的三种模式：Craft / Plan / Ask

你有没有这种经历：让 AI 帮你改个 typo，它先输出八百字分析报告，等你读完天都黑了。又或者你只是想聊聊某个方案靠不靠谱，它已经开始建文件了。

这种错位挺常见的。问题不在于 AI 做得好不好，而在于你俩对"这次协作该怎么进行"的理解不一致。

WorkBuddy 把这个问题拆成了三个模式：Craft、Plan、Ask。不是什么高深概念，就是让你选一下"这次你想让我怎么跟你配合"。

---

## 三种模式到底有什么不同

先看一张表，后面再展开说。

| | Craft | Plan | Ask |

|---|---|---|---|

| 一句话 | 你说，我做 | 先想后做 | 只聊不动 |

| 能读文件吗 | 能 | 能 | 能 |

| 能改文件吗 | 能 | 确认后能 | 不能 |

| 能执行命令吗 | 能 | 确认后能 | 不能 |

| 你需要做什么 | 交付后验收 | 审核计划，然后验收 | 自己动手 |

| 像什么人 | 干活的助手 | 出方案的项目经理 | 给建议的顾问 |

核心区别其实就一个字：**干不干**。Craft 直接干，Plan 先给你看方案再干，Ask 光说不干。

---

Craft：你说，我做

Craft 是默认模式。你给一个明确的指令，它直接开始读文件、改代码、跑命令，中间不问你"这样可以吗"，拿到结果你自己验收就行。

适合什么任务？就是你心里已经清楚要什么结果的那些。

举几个例子：

**修复明确的 bug。** 你说"UserController 的 getUserById 空指针了，看下日志修一下"，它就去读代码、定位问题、改掉、验证，然后把结果给你。你不用在旁边盯着。

**生成文档。** 你说"根据当前代码结构生成一份 README"，它扫一遍项目，把文件写好放到该放的位置。你打开看看写得对不对就行。

**批量操作。** 你说"把 src 下所有 .js 改成 .ts 并更新引用"，这种多步骤但路径明确的事，Craft 一口气干完，最后给你一份变更清单。

这里有个经验：Craft 模式下，指令越具体，结果越靠谱。"优化一下这个函数"太模糊，"把这个 O(n²) 的双层循环用 HashMap 优化成 O(n)"就清楚多了。目标加上约束，出来的东西通常能直接用。

---

Plan：先想后做

Plan 模式适合那种你三言两语说不清楚、或者实现路径有好几种走法的任务。

流程是这样的：你说需求，它先分析，然后给你一份分步计划——第一步做什么、第二步做什么、有哪些风险。你看完觉得 OK，说"开始吧"，它才真正动手。

什么时候该用 Plan？我建议在以下几种情况考虑：

**实现一个比较大的新功能。** 比如你说"加一个文件上传功能，要支持断点续传"。它不会上来就写代码，而是先问你：我打算分五步——设计接口、实现分片上传、做断点续传的记录逻辑、合并文件、写测试。这个方案行不行？

**大规模重构。** 比如把整个项目从 JavaScript 迁到 TypeScript。这种事要是直接开干，很可能迁移到一半发现顺序错了、某个模块依赖搞混了。Plan 模式会先评估范围，排好模块迁移的顺序，把风险点标出来。你确认路线图之后再说。

**改动影响面不好预估的任务。** 你不太确定动一个地方会不会牵连别的，那先让它出个方案，看看它打算改哪些文件，你再决定要不要继续。

Plan 模式最值钱的地方在于"先对齐"。你审核计划的时候重点看三件事：步骤顺序合不合理、有没有遗漏的边界情况、风险点有没有标出来。不满意就直接说，它改完再给你看一轮。

---

Ask：只聊不动

Ask 是三个模式里最"克制"的。它只读文件、只分析、只回答问题，绝对不改你的任何东西，也不跑命令。

说白了就是纯聊天。但它不是瞎聊，它能看到你的项目代码，所以回答是基于你的实际代码而不是泛泛而谈的通用知识。

什么时候用？主要是你还在想、还在评估、还不想动手的阶段。

**代码审查。** 你说"帮我看看 PaymentService 有什么设计问题"，它读完代码告诉你：职责太多、直接依赖了具体实现没抽象接口、有几处异常没处理。它只是告诉你问题在哪，不会顺手帮你改。

**技术选型讨论。** 你问"高并发场景 Redis 和 Memcached 怎么选"，它从数据结构、持久化、集群方案、性能这些维度逐项跟你聊，最后给你一个建议。但最终决定是你做的。

**学习和探索。** 你说"讲讲我们项目里 event loop 是怎么用的"，它结合你的实际代码来讲。比看通用教程有针对性多了。

Ask 模式有个隐藏好处：它是最安全的探索方式。你要是不确定一个改动会不会搞坏项目，先用 Ask 让它分析一下影响面，聊清楚之后切到 Craft 或 Plan 再动手。

---

怎么选

其实就回答一个问题：这个任务，我需要它帮我思考，还是帮我执行？

**任务明确，你知道要什么**——用 Craft。直接干，验收就行。

**任务复杂，路径不唯一**——用 Plan。先看方案，确认了再干。

**还在想，不想动任何东西**——用 Ask。先聊聊。

拿"给项目加日志功能"举个例子，同一个任务在三种模式下体验完全不同：

- Craft：直接在关键模块插日志代码，配置好框架，给你一个能跑的日志功能，你验收

- Plan：先列计划（选哪个日志框架、日志级别怎么定、哪些模块要加、测试怎么写），你确认后逐步执行

- Ask：分析项目现在的日志现状，对比 log4j 和 logback 的优缺点，给你建议，但不写代码

---

进阶：组合着用

实际干活的时候，很少有人一个模式走到底。比较好用的组合方式有这么几种：

**Ask → Plan → Craft。** 先用 Ask 模式讨论需求，搞清楚要做什么、大概怎么做。然后切到 Plan 模式让它出详细方案。确认之后切到 Craft 执行。复杂任务我推荐走这条路线，思考够深，执行也干脆。

**Plan → Craft。** 你对领域很熟，需求也清楚，但实现比较复杂。那就跳过前期讨论，Plan 出方案，确认后直接 Craft 执行。

**直接 Craft。** 简单活儿别绕弯子。改个 bug、写个脚本、生成个配置，一把梭就完了。

我个人的习惯是在发指令前花几秒钟过一下脑子：这事儿我需不需要先看方案？如果不需要，Craft 直接上。如果心里没底，Plan 先出方案。要是压根还没想好做什么，就先 Ask 聊聊。

这个判断本身不花什么时间，但能省掉后面很多返工的功夫。

---

走一遍：一个完整的二开项目

光说策略有点抽象，我们举例一个场景走一遍：假设你手里有一份 MUD 游戏的源码，想做二次开发。这个项目从零到能跑，三种模式是怎么配合的。

---

### 第一阶段：Ask，把方向聊清楚

源码到手，你先把整个项目文件夹拖进 WorkBuddy，切换到 Ask 模式，然后开始问。

"这个项目是什么架构，用的是哪些技术？"

它读一遍代码，告诉你：后端是 C 写的，用的 telnet 协议，数据存在文件里，没有数据库。模块化程度不高，游戏逻辑和业务逻辑混在一起。

这时候你心里大概有数了，接着聊需求。

"我想保留核心玩法，但后端想换成现代技术栈，前端加个 Web 界面，你有什么建议？"

它不会直接动手改，而是跟你讨论：后端可以考虑 Go 或 Rust，各有优劣；数据库从文件迁到 PostgreSQL 或 MySQL；前端可以用 WebSocket 代替 telnet，这样浏览器能直接连。它把这些选项的利弊摊开，你问它，它答，来回几轮，方向就聊出来了。

这个阶段持续多久看你自己——聊到你觉得"好了，我知道要做什么了"为止。Ask 模式全程不会碰你的文件，所以怎么聊都安全。

---

### 第二阶段：Plan，把方案拆成步骤

方向定了，切到 Plan 模式，把聊出来的需求整理成正式的计划。

你可以这样说："好，需求确认了：后端用 Go 重写，保留 MUD 核心指令系统，数据迁到 PostgreSQL，前端用 WebSocket 简单 Web UI。帮我出一份开发计划。"

它开始分析，然后给你一份东西，大概长这样：

**阶段一：环境搭建**

1. 搭 Go 项目结构，选框架（gin 或 echo）

2. 配 PostgreSQL，设计用户表、房间表、物品表

3. 把原有 C 代码的协议搞清楚，整理成文档

**阶段二：核心功能迁移**

1. 实现 telnet WebSocket 双协议接入

2. 迁移指令系统（look、move、take、drop 等）

3. 实现房间系统、物品系统、战斗系统

**阶段三：数据迁移**

1. 写脚本把原有文件数据导入 PostgreSQL

2. 验证数据完整性

**阶段四：前端**

1. 用 React 或 Vue 写 Web 终端界面

2. WebSocket 连接后端

你看完这个计划，可能会发现有些步骤顺序不对，或者有些风险它没考虑到。比如你发现数据迁移应该放在核心功能迁移之前，因为新代码要基于新数据库来写。你就直接说，它调整计划，再给你看一轮。来回几轮，直到你觉得这个计划可以执行了，说一句"开始吧"。

---

### 第三阶段：Craft，按计划一步一步干

计划确认之后，切到 Craft 模式，它开始执行。

它先做阶段一的第一步：搭 Go 项目结构。它建好目录、配好 go.mod、把 gin 装上、写好 main.go 的骨架，然后告诉你"阶段一第一步完成了，你可以看一下"。

你看一下，没问题，它就继续。

整个过程是一步一步来的。每完成一个步骤，它会停下来给你看结果。你验收通过，它才进下一步。这跟直接把整个项目一口气写完不一样——你是参与其中的，随时可以喊停、调整方向。

如果某个步骤出了问题，你也可以随时切回 Ask 模式，让它帮你分析哪里错了，搞清楚了再切回 Craft 继续。

---

### 回头看这个流程

Ask 阶段解决了"做什么"和"怎么做"的问题。你没有一上来就写代码，而是先把方向聊透。

Plan 阶段解决了"按什么顺序做"的问题。你有了一份路线图，知道每一步大概要干什么，风险点在哪里。

Craft 阶段解决了"怎么把活干完"的问题。你不用每一步都盯着，但关键节点你都会看到结果，随时可以干预。

如果一开始就直接用 Craft 模式会怎样？它可能会基于自己对"MUD 游戏"的理解直接开始写代码，写出来发现不是你想要的方向，然后你得花时间改回来。三种模式分开用，本质上是在不同的决策节点上，选对参与深度。

---

最后

三种模式没有什么好坏之分，就是三种不同的协作姿势。选错模式，要么它干得太快你没准备好，要么它太磨叽你等不及。选对了，配合起来就顺。

你下次用 WorkBuddy 之前，可以先想一句：这次我想要的是什么？想清楚了再选模式。","createTime":1783401961,"ext":{"closeTextLink":1,"comment_ban":1,"description":"","focusRead":0},"favNum":0,"html":"","isOriginal":0,"likeNum":0,