如果你最近在开发时开始尝试用 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 编程辅助的体验会和最初那种“有时有用、有时添乱”的感受完全不同。 
长河君 · 2026/10/21 4:21:54 · 阅读 1.2k CodeBuddy三种模式怎么选？ask、craft、plan适用场景全解析
如果你最近在开发时开始尝试用 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 编程辅助的体验会和最初那种“有时有用、有时添乱”的感受完全不同。