# 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 之前，可以先想一句：这次我想要的是什么？想清楚了再选模式。

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

Craft / Plan / Ask 三种工作模式解析

WorkBuddy 有三种协作模式：Craft（直接执行）、Plan（先出方案再执行）、Ask（只聊不动手）。本文用一张对比表、三个模式的详细解读，以及一个完整的 MUD 游戏二开实战案例，讲清楚每种模式适合什么场景、怎么选、怎么组合着用。读完你应该能判断手里这个任务该用哪个模式，少走弯路。

开发工具

人工智能

职业发展

WorkBuddy提供Craft、Plan、Ask三种AI协作模式，精准匹配不同任务需求。Craft模式直接执行明确指令，Plan模式先出方案再执行，Ask模式仅提供分析建议。三种模式可灵活组合，Ask→Plan→Craft流程适合复杂任务，简单任务可直接Craft执行。根据任务明确程度选择模式，能显著提升人机协作效率。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

WorkBuddy提供Craft、Plan、Ask三种AI协作模式，精准匹配不同任务需求。Craft模式直接执行明确指令，Plan模式先出方案再执行，Ask模式仅提供分析建议。三种模式可灵活组合，Ask→Plan→Craft流程适合复杂任务，简单任务可直接Craft执行。根据任务明确程度选择模式，能显著提升人机协作效率...

Craft / Plan / Ask 三种工作模式解析-腾讯云开发者社区-腾讯云

Craft / Plan / Ask 三种工作模式解析

Craft / Plan / Ask 三种工作模式解析

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐