如果你最近在开发时开始尝试用 CodeBuddy 来辅助编码，可能已经发现它的对话框并不是只有一种默认的问答形态，而是能按需切换成 craft、ask 和 plan 三种工作模式。先说结论：这三种模式分别对应“直接动手改代码”“只回答不改动”“先规划后执行”三类完全不同的协作方式。很多人第一次使用时最大的困惑就是：到底该用哪个？其实只要理解了它们各自的定位、行为边界和适用场景，选择就会变得非常直观。这篇文章会把三种模式的核心原理、实操细节、典型使用场景以及它们之间的区别一次讲透，既能帮刚开始用工具的新手少踩坑，也能给已经在日常开发中重度使用工具的人提供一些可复用的组合工作流。
1. 三种模式的定位与设计初衷
CodeBuddy 之所以把对话能力拆成三种模式，而不是一个框里统一处理，是因为真实开发中程序员的需求是分层的：我有时候只想被科普一个知识点，有时候希望有人帮我把代码立刻改了，有时候又需要先想清楚改动方案再动手。把这三种需求混在一起，模型很难判断你到底是“随口问问”还是“准备落地”，而拆开之后，模式的边界就是权限边界，你选了什么，它就按什么尺度来协作。
1.1 ask模式：随叫随到的技术顾问
ask 模式本质上是把一个 AI 编程助手变成一个“只动口、不动手”的技术顾问。它不会去读取和修改你工作区里的文件，所有输出都停留在聊天面板里，以文字、代码片段或建议的形式呈现。这个模式最典型的用法就是你有一个具体问题想搞清楚：某个 API 为什么这么用、这个报错信息代表什么、这段逻辑有没有潜在问题、某个框架的底层机制是什么，等等。
我特别喜欢用它做代码走查。把自己写的一段代码贴给它，然后问“这段代码有没有隐患”，它能从边界条件、资源释放、性能损耗这些角度给出点评，但不会自作主张去改动你的源代码。对于团队里需要互相 review 但又找不到人聊的场景，ask 模式是一个很好的替代方案。
为什么需要有这样一个模式？因为真实开发中有大量需求是“问清楚”，而不是“改起来”。如果每次都要模型直接动代码，反而很危险——它可能在你没有保存的文件上一顿乱改，你要么花时间核对 diff，要么被迫回退。ask 模式把风险降到最低：它只输出信息，改不改完全由你决定。
举一个具体例子。我在写一个 Python 脚本时遇到 TypeError，把报错栈粘贴到 ask 模式里问“为什么这里会抛错”，它会分析出可能是类型不匹配、变量作用域问题或者某个函数返回值不是预期类型，并给出排查方向。它不会去打开我的.py文件修改，只是一步步帮我定位问题。这就是“问与改”的边界。
1.2 craft模式：直接上手改代码的结对程序员
craft 模式的核心动作是“改”。它会基于当前项目的上下文，在你指定的文件或目录内直接编辑代码：生成新函数、修改既有实现、修复 bug、重构命名、补充注释和类型标注等。它的输出不是建议，而是实实在在落盘的文件改动。这个模式更像是一个坐在你旁边、拿到需求就能动手写代码的结对程序员。
它最适用的场景是那些“已经有了明确目标、只需要快速落实到代码里”的任务。比如我想在页面里加一个按钮，给某个函数增加异常处理，把一个循环改成列表推导式，或者把一个接口的返回结构从字典改成数据模型。这些任务不需要花很长时间做全局规划，也不太需要评估跨模块影响，直接改了看效果就行。如果用 plan 模式走完整流程会觉得重，用 ask 模式又只是“打嘴炮”不落地，craft 的介入程度正好。
但请注意，craft 模式的风险比 ask 高不少。因为它会直接写入文件，所以在我使用它时，始终默认一个原则：改动之前先通过对话把任务范围说清楚。比如我会说“只修改service/user.py中的create_user函数，不要动其他部分”，而不是笼统地说“帮我优化一下项目”。任务的边界越清晰，它就越不容易在其他地方“顺手”改出问题。
使用 craft 模式后，还建议第一时间检查它改了哪些文件，不放过任何一行 diff。在这个模式下，它不是在“建议你这样做”，而是“我已经这样做了”，所以你的确认环节不能省。
1.3 plan模式：先把蓝图理清的架构评审员
plan 模式提供的是“在执行真正改动之前，先把方案想清楚”的工作方式。它会把需求拆分成若干步骤，列出需要改动的文件，给出实施顺序，标注风险点，甚至补充测试验证方法。它的产出通常是一份计划文档，而不是直接写好的代码。
这个模式最适用于中大型改动：跨模块调整、核心接口变更、老项目重构、新功能模块落地。因为这些任务一旦直接动手，很容易出现“牵一发而动全身”的连锁问题。plan 模式强制先做设计层面的推演，把影响面和控制点找出来，再决定怎么动手。从协作流程上看，它就像是团队里负责架构评审的同事，先出设计说明，再让开发照着执行。
举个例子，如果我要做一个“用户认证方式从单因素升级为双因素”的改造，涉及数据库表、登录接口、前端页面、过期策略等多处修改，直接开一个 craft 窗口硬写，大概率会在某个反馈链路里漏掉关键改动点。但先切到 plan 模式，输入目标和约束条件，它会输出一个包含“改动文件清单、依赖顺序、验证策略、回滚方案”的列表，下一步可以照着这个列表逐项执行。
换句话说，plan 模式回答的问题是“怎么做”，craft 模式回答的是“动手做”，ask 模式回答的是“是什么”。三种模式并不是竞争关系，而是面对不同任务节点时的不同介入深度。
2. 三种模式的核心细节与实操要点
理解了三种模式“是什么”之后，更重要的问题是“怎么用”。这一章的实操要点都来自我自己的使用经历，基本上是把常见的坑提前替大家踩一遍。
2.1 ask模式的提问技巧与边界
同一个问题，问法不同，ask 模式给出的答案质量会差很多。我自己的习惯是：不提问笼统的问题，而是把上下文完整地给出去。比如不要只说“帮我看看这段代码哪里有问题”，而要说“下面这段函数在输入为['2024-01-01', '2024-01-02']时返回了错误的日期结果，请帮我分析可能的原因”。把目标、输入、期望输出、实际现象都描述清楚，模型才能给出足够精确的定位线索。
ask 模式还有一个非常好的用法是让 AI 做一次前保险式的逻辑审查。在提交代码前，把关键 diff 贴给它，问它有没有边界遗漏、性能隐患、潜在异常，它通常能给出我容易忽略的细节。比如有一次它指出我的重试逻辑里缺少退避策略，服务端一旦抖动，客户端会瞬间重复请求成百上千次。这种“防患于未然”的价值非常高。
需要强调的是，ask 模式回答的内容只存在于聊天面板。它有时会给你一段完整代码，但这不代表代码已经写入你的项目。你需要自己复制粘贴到对应文件里。这不是 bug，而是模式设计的一部分——它把最终决定权留给你。所以如果你发现自己频繁地复制 ask 的回答到文件里，就说明这个任务其实更适合切到 craft 模式，让模型直接完成修改并保存。
2.2 craft模式：让每一次改动都精准落地
craft 模式最大的优势是“直接”，最大的风险也是“直接”。几个关键操作习惯非常有必要养成。
第一，给任务设定明确边界。指令里最好带上文件路径和函数名，例如：“请修改utils/date_helper.py中的parse_time函数，让它兼容 ISO 格式字符串，不要修改其他函数。”这相当于给这次的改动画了一道边界，它能在这个范围内自由发挥，但不会越界。如果任务本身涉及多个文件，建议分多次执行，而不是一条指令跨整个项目大改，因为改动范围越大，出问题的概率越高，你也越难逐行审查。
第二，一次只做一件事。如果你要求“顺便把 A 函数优化一下，再改一下 B 模块的样式”，它可能会同时搞定两个完全无关的改动，这会极大增加 review 的负担，万一有一个部分不符合预期，要调回来时很难只保留其中一部分。更可控的做法是：每次只提一个最小目标，完成后立刻检查，通过后再继续下一个。
第三，改完必看 diff。凡是 craft 模式动过的文件，都要用编辑器或命令行工具把改动行列出来确认一遍。它不是“建议稿”，而是“已落盘的真实改动”。我看过太多开发者因为闭眼信任 craft 的改动，后续 debug 才发现它顺手把另一个依赖顺序也调了，这种问题在交付前检查 diff 时都能被发现。
第四，保留回退空间。在动手之前，如果项目没有处于版本管理之下，建议复制一份当前文件或者把改动记录在一个可恢复的位置。多数情况下我会依赖 Git 等版本管理工具，在任务开始前确认当前分支干净，这样即使 craft 改坏了也能快速回退。
2.3 plan模式：把模糊目标拆成任务清单
使用 plan 模式的时候，输入一个含糊目标也能得到一个计划，但质量通常不高。想让它的规划真正可用，我会在描述中尽量包含三个要素：期望结果、约束条件、影响范围。比如“在不改变现有数据库表结构的前提下，做一个用户登录历史查询功能，只涉及后端接口和前端一个页面”，这样它就知道哪些是不能碰的约束，哪些是可以发挥的部分。
一个好用的 plan 模式产出，不一定是一大段文字，而更应该是可执行的步骤清单。如果它给的计划过于宽泛，我会继续追问：“请把第二步细化成可以逐条执行的子任务，并标注每个步骤涉及的文件路径。”这相当于一次规划迭代，能大幅提升后续切换到 craft 模式时的落地效率。
还有一个特别实用的技巧：让 plan 模式输出“不要做什么”。比如“这个需求我不需要支持管理员备注功能，请你在规划时默认排除”。把边界也写进计划里，能避免它在设计阶段引入不必要的复杂度，也能防止后续执行时模型“顺手”把多余功能也实现出来。
另外，plan 模式生成的计划文件本身也值得长期保存。它可以作为开发任务文档使用：后续接手的同事看到这份计划，也能快速知道整个改动的前因后果，比一个聊天窗口里的上下文要直观得多。
2.4 一句口诀快速判断当前用哪个模式
我总结了一个很简单的判断口诀，在开发中经常用它来做决定：
- 如果只是想得到答案，不想让任何人动我代码，用 ask。
- 如果需要代码最终出现在文件里，且改动范围在一个小范围内，用 craft。
- 如果任务牵涉多个文件、多个模块，或者需要先论证才能动手，用 plan。
听起来很简单，但实际上很多人在使用时不知道切模式，甚至不知道还有模式切换功能，结果就导致“让 AI 干活”的体验非常差——要么询问后还要自己复制代码，要么被改了不在预期内的文件。模式选对了，工具才好用。
3. 三种模式的区别对照与场景选择
把三种模式摆在一起看，区别会更清楚。下面这张表是我自己整理的对照表，基本覆盖了最核心的差异维度。
| 维度 | ask模式 | craft模式 | plan模式 |
|---|---|---|---|
| 核心行为 | 回答问题、解释代码、给建议 | 直接读取并修改代码文件 | 分析需求、制定计划、输出步骤 |
| 是否改动文件 | 否 | 是 | 通常不直接改，视后续操作而定 |
| 输出形式 | 聊天文本、代码片段 | 文件中的真实代码改动 | 计划文本、改动清单、风险列表 |
| 风险程度 | 低 | 中高，需要人工确认 diff | 中，取决于执行过程 |
| 典型任务 | 概念咨询、报错分析、代码走查建议 | 写函数、修 bug、局部重构、改样式 | 跨模块改造、多文件规划、老项目重构 |
| 交互深度 | 一问一答为主，适合多轮追问 | 边改边确认，适合小步迭代 | 先规划后执行，适合任务前推演 |
| 对你的要求 | 能把问题描述清楚 | 能给出边界和范围 | 能定义目标与约束条件 |
3.1 三者差异逐项对比
从交互方式来看，ask 模式更像是“咨询”，craft 模式更像是“执行”，plan 模式更像是“设计”。这三个词是理解它们差异的基础。
从操作权限来看，ask 不碰文件，plan 一般不直接碰文件，craft 会直接写入文件。这一点是三者最根本的边界。我见过很多第一次使用 craft 模式的人，会很惊讶“它居然真的把代码改了”，这就是没有理解模式权限差异的表现。
从适用阶段来看，一个功能的生命周期往往会经历“调研—规划—实现—验证”四个阶段。ask 适合调研阶段，plan 适合规划阶段，craft 适合实现阶段，而验证阶段中三者都能用：看到报错用 ask 分析，发现小问题用 craft 修，发现方案偏差回到 plan 重新调整。
从人工参与度来看，ask 模式的参与成本最低，craft 模式的审查成本最高，plan 模式的思考成本最高。你需要想清楚自己的需求和当前环境，再决定把哪部分成本交给工具，哪部分留给自己。
3.2 常见任务场景与模式速查表
下面这张速查表按“场景 → 推荐模式 → 理由”的结构，覆盖了开发中最常遇到的任务类型。
| 场景示例 | 推荐模式 | 理由 |
|---|---|---|
| 表单校验写完后，想确认有没有边界问题 | ask | 只需要分析和反馈，不需要落地改动 |
| 新写一个小函数，比如把日期字符串转成时间戳 | craft | 任务明确、范围小，直接写入最快 |
| 想在页面上新增一个筛选组件，并关联已有接口 | craft | 两三个文件内的小改动，边改边看 |
| 登录模块需要增加第三方认证，涉及后端配置和前端页面 | plan | 跨模块，影响面大，先规划更稳妥 |
| 想了解某个框架的缓存机制原理 | ask | 这是知识性问题，代码未必要落地 |
| 旧项目里大量重复代码需要抽取公共模块 | plan | 改动范围大，且存在较多潜在耦合 |
| 一个线上 bug 是空指针，需要快速定位修复 | craft | 先修主要问题，再通过 ask 复盘根因 |
这个表可以作为日常选择模式的快速参考，覆盖面不算全，但套路基本清晰：影响面越小、目标越明确，越适合 craft；影响面越大、越需要设计判断，越适合 plan；只要没有落地需求，就用 ask。
3.3 一个任务在不同阶段切换模式
这里要强调一个观点：三种模式并不是互斥的，而是可以在一个任务的整个流程中被切换使用。很多任务其实不是简单的“单模式”任务，它可能一开始是知识询问，然后变成规划，最后落到实现。
例如有一次我需要给项目增加一个 Excel 导出功能，但我对当前用的导出库并不熟悉。我先用 ask 模式了解到这个库的核心 API 和常见用法，然后再切到 plan 模式，请它规划“新增导出接口 + 前端下载按钮 + 异常处理”的具体改动步骤。确认计划后，再切到 craft 模式，按步骤让模型把代码逐段写入文件。这个过程用到了三种模式，目标却只有一个——整个思路是通过不同模式在不同的任务节点提供合适的协作深度，而不是一上来就让模型直接写代码。
所以平时不用纠结“这个任务该锁定哪个模式”，而是要想清楚“当前这一步需要什么”。这样用起来会顺很多。
4. 常见问题与排查技巧实录
4.1 选错模式的典型翻车现场
翻车案例一：想快速实现一个功能，却选成了 plan 模式。结果模型只顾输出“第一步做什么、第二步做什么”，完全没有产出可运行代码。这不怪工具，而是因为任务本身不是一个需要规划的大改动，选一个直接落地的方式更合适。
翻车案例二：只是想问一个概念，比如“闭包是什么”，结果不小心切到了 craft 模式。模型以为你要在项目里写闭包，直接创建或修改了一个文件，导致工作区多了一个你不认识的文件。这是模式边界没搞清楚造成的，白白增加清理成本。
翻车案例三：一个跨模块重构任务，直接开 craft 模式让模型改。它确实改了，但改了五个文件后，你发现自己不太确定这些改动之间有没有遗漏依赖，甚至有一处接口调用没同步更新，跑起来全是问题。这就是把需要规划的任务错误地下放给了“直接执行”。
这些案例说明一个道理：模式的本质是权限边界。选错模式，轻则输出不匹配，重则产生不必要的代码改动和返工成本。
4.2 快速识别模式状态并及时止损
在对话过程中，可以从模型的输出风格判断当前处于什么工作状态。
如果模型在不停地列出可能性、解释概念、补充背景知识，这通常是你正处在 ask 式对话中。如果你其实想让代码落地，就需要切到 craft 模式，而不是继续追问。
如果模型开始频繁地给出“第一步：修改文件A；第二步：修改文件B；第三步：验证”，这是它正在用 plan 的逻辑处理你的问题。如果你其实只想让它把一个按钮加上，就可以直接切到 craft 模式让它立刻动手。
如果你发现模型已经连续改了多个文件，但你没有主动确认过这些改动目标，这种情况要特别警惕。建议立刻停下来，逐个检查改动文件，对不需要的部分果断回退。不要带着一个“不知道它改了什么”的状态继续开发，那是大坑。
还有一个实用的小技巧：如果你不确定当前任务该用哪种模式，先默认用 ask 问一下：“这个需求你觉得应该先规划还是直接实现，涉及哪些文件？”它会给你一个基于任务规模的判断建议，再根据它的回答选择合适的模式，这样能有效减少错误选择。
4.3 推荐的使用工作流与习惯
我经过几轮折腾后，形成了下面这套工作流，按部就班执行就能减少大多数踩坑问题。
- 接到任务后，先评估规模：只涉及一个或两个文件且目标明确，直接 craft；跨模块、牵扯数据库或配置，进入下一步。
- 用 ask 模式做一次前置调研。把你不确定的知识点问清楚，比如新库的 API、框架的官方推荐写法、当前代码里的隐患点。
- 切到 plan 模式，请它输出包含文件清单、改动步骤、验证方法、风险点的任务计划。这一步像是在草稿纸上写方案，能改能揉。
- 确认计划没问题后，切到 craft 模式，按照计划中的步骤逐项落地。每完成一步，检查一次 diff。
- 后期碰到新的报错或疑问，再开一个 ask 窗口提问，而不是让正在执行的 craft 窗口中断逻辑去聊大量背景知识。
- 全部改完后，再把核心 diff 贴给 ask 模式做一次整体 review，确认没有遗漏边界或潜在 bug。
这套工作流把三种模式各自的优势都放到最大：ask 负责信息输入，plan 负责降低复杂度，craft 负责高效落地。对于规模特别小的任务，可以直接从第 4 步开始，不必每次都走完整流程。
最后再分享一个长期习惯：不要把所有对话都放在一个窗口里。遇到不同类型的任务，主动新建对应模式的对话，这会让模型保留更干净的上下文。比如我通常保持一个长期活跃的 ask 窗口用于日常提问，开一个新的 craft 窗口处理特定代码改动，再开一个 plan 窗口做模块级规划。窗口本身也是上下文隔离的一种手段，用好了，整个工作的清晰度会立刻提升。
我在实际使用中还有一个很深的体会：刚开始使用这类工具时，会把 craft 模式当成万能模式，什么任务都让它直接改。后来踩过几次坑才明白，真正重要的是在自己的脑子里建立一条清晰的决策链——先问“我需要什么”，再选“工具用什么模式”。CodeBuddy 的三种模式就像是同一把工具的三段变速：该深挖时深挖，该推行时推行，该规划时规划。把这三种模式用熟之后，AI 编程辅助的体验会和最初那种“有时有用、有时添乱”的感受完全不同。
