对话模式深度使用｜CodeBuddy

来源：腾讯云培训认证中心 · CodeBuddy 架构师认证课程 · ch2

第二章 · Chapter 2

对话模式深度使用

本章学什么

掌握 Ask / Craft / Plan 三种模式的能力边界、使用方法与选型策略
吃透 Craft 四个关键习惯：上下文管理 / Checkpoint 回退 / 迭代协作 / Diff 审查
建立"架构级用 Plan，细节级用 Craft，原子任务用 Ask"的选型法则

CodeBuddy 对话面板提供三种模式：Ask、Craft、Plan，分别对应 AI 不同的介入深度。一句话主线——Ask 是「问」，Craft 是「做」，Plan 是「先想清楚再做」。

三种模式在不同形态上的暴露方式

IDE 形态：Ask / Craft / Plan 三种齐全，手动切换。 插件形态：目前只有 Ask 和 Craft，没有 Plan；遇到架构级任务请切到 IDE。 CLI 形态：统一入口、不分模式——CLI = Ask + Craft + Plan（模型自动调度）。三种能力在每种形态里都存在，只是 IDE 让你手动选、CLI 让模型自动判断。

2.1 Ask 模式 · 精准问答

Ask 模式下 AI 扮演「顾问」角色——只提供信息、只给建议，不会主动修改文件、不会执行命令。本质：安全、可控、透明。

四项核心能力

能力	定位与关键差别
代码问答	基于项目上下文——不是通用搜索引擎。同样问"怎么写一个用户登录"，ChatGPT 给通用代码，Ask 会先读你的项目（用 Express 还是 Koa、用了哪个 ORM、有没有现成中间件）再精准回答
代码解释	自然语言分步说明业务逻辑 + 潜在问题——不是翻译语法，而是告诉你"业务上在做什么、坑在哪里"。接手新项目最省时间的切入方式
代码片段	文本形式输出代码、需手动复制粘贴。Ask 给的是文本，不会写进文件——适合原子性任务（一段正则、一段 snippet、一段配置）
方案咨询	技术方案建议 + 优缺点对比。Redux vs Zustand、REST vs GraphQL，让它从团队能力、迭代频率、性能多维度打分。它给建议，你拍板

三类高频实操场景

① API 用法查询。问"useEffect 的 cleanup function 怎么写？"——AI 返回完整代码片段 + 使用说明 + 结合项目代码风格。最后一项是关键：Google 给你的是全网通用答案，Ask 给你的是结合你项目技术栈的针对性答案，比如已识别 TypeScript 严格模式、用 useRef 管理定时器的项目惯例。

② 解释遗留代码。典型动作：在编辑器里框住一段代码 → 右键「添加到 CodeBuddy」→ 这段代码以引用形式进入对话框 → 提问"解释这段代码的业务逻辑，重点说明状态流转和异常处理"。AI 分段逐步解释、标注潜在风险点。接手老项目最有体会——不是看不懂语法，是看不懂"为什么这么写"。

**③ 方案评估。**同时描述两个候选方案 + 想对比的维度，AI 直接给出结构化对比表（横轴维度、纵轴方案，每格一条短结论）。它不是替你拍板"选 A"，而是给出决策所需的全部要素。

贯穿三场景的关键技巧

善用 @ 引用与「添加到 CodeBuddy」补上下文——这是 Ask 跑出高质量回答的单点最关键技巧。@ 是文件 / 文件夹级引用，片段级就用「选中 + 添加到 CodeBuddy」。两种方式覆盖 95% 的上下文需求。

下面这段视频把 Ask 三个典型场景完整跑一遍，重点观察两件事：Ask 与 Craft 在交互上的差别（只给文本、不动文件），以及 @ 和「添加到 CodeBuddy」分别在什么场景用。

2.2 Craft 模式 · 自动修改与执行

如果 Ask 是「问」，Craft 就是「做」——AI 从顾问升级为执行者，直接动手。Ask 的输出是文本（你自己执行），Craft 的输出是动作（AI 直接执行）——效率差距可以是一个数量级。

四块核心工具链

工具链	关键能力
代码编辑	直接修改项目文件 · Diff 视图审查变更 · 自动创建 Checkpoint。Checkpoint 是 Craft 最重要的安全机制——没有它大胆用 Craft 就是冒险，有了它才敢真正放手让它干
终端命令	自动执行 Shell 命令——`npm install`、运行测试、启动开发服务器。代码和环境一起动，改完顺手把依赖装了、测试跑了、服务起了
语义搜索	代码库语义级搜索 · 理解代码意图 · 非简单文本匹配。「找出所有处理用户权限校验的逻辑」——能同时捞出中间件、装饰器、工具函数、路由守卫里的相关代码，哪怕函数名完全不一样
外部集成	浏览器预览调试 · Figma 设计导入 · MCP / Git 集成。Craft 的边界远超"改代码"——它是全开发流程的自动化引擎

三类代表性实操场景

场景	输入	AI 自动完成
需求驱动开发	「创建用户注册模块，JWT 认证 + 邮箱验证」	创建路由 / 控制器 → 安装依赖 → 编写中间件 → 生成测试用例。半天的样板代码工作量几分钟串完
Bug 修复全流程	粘贴错误信息 + `@` 引用出错文件	分析根因 → 定位问题代码 → Diff 视图展示修复 → Accept 后应用 → 运行测试确认。全程 Checkpoint 保护，改坏了直接回退
多文件重构	「拆分 500 行 service，按职责分离原则重构」	创建新文件 → 移动函数 → 更新 import 路径 → 处理依赖关系。多文件协同修改是 Craft 的最强能力——手工重构最怕的不是写代码，是漏改引用、破坏依赖

下面这段视频聚焦在「Bug 修复全流程」——把"输入 + AI 自动完成"的 Craft 标准句式完整跑一遍，重点感受 Craft动手的效率。

Craft 四个关键习惯

吃透下面四个习惯，Craft 使用水平能直接上一个台阶。

习惯	核心要点
① 上下文管理	`@` 添加文件 / 目录 · 精确优于全量 · 避免信息过载。一次性 `@` 进 50 个文件，AI 反而抓不住重点。好的实践是精准选 3–5 个：核心模块 + `package.json` + 类型定义。Craft 的上下文质量 = 输出质量
② Checkpoint 回退	每轮自动 Checkpoint · 出问题随时回退 · 敢于大胆尝试。Checkpoint 像 Git 的 commit，让你放心让 AI 做激进的改动——改坏了一键回退，不丢任何代码。知道这个安全网，Craft 才是你手上真正的"自动化团队"
③ 迭代式协作	分步骤给小目标 · 搭建 → 验证 → 迭代 · 不要一句话说完。"做一个完整电商系统支持商品、订单、支付、物流"——这种给法几乎注定失败。每一轮给一个能独立验证的小目标，任何一步出问题都能及时止损
④ Diff 审查	不盲目 Accept · 重点看四件事：变量命名 / 边界异常 / 安全问题（SQL 注入、XSS、权限绕过）/ 是否破坏现有逻辑。支付、鉴权、数据写入这类业务关键代码必须人工复核，这一步不能省

下面这段视频不再演示新场景，专门聚焦"怎么用好 Craft"——故意给 Craft 一个边界模糊的需求，让它"犯一次错"，然后现场演示 Checkpoint 一键回退 + 重新迭代的完整过程。

2.3 Plan 模式 · 需求驱动开发

Plan 是 CodeBuddy 里"最重"的对话模式，架构级任务的首选——它不会像 Craft 那样接到需求就开干，而是先把方案完整列出来给你审。

环境说明

Plan 作为独立模式目前只在 IDE 形态里提供，插件形态暂时没有这个独立选项。IDE 学员请跟着实操；插件学员重点建立认知，做架构级任务时切到 IDE；CLI 学员知道"Plan 的规划能力已融合在统一入口里"即可——把需求描述得够复杂，模型会自动进入规划模式。

五步生命周期

官方定义：需求澄清 → 方案制定 → 方案编辑 / 确认 → 方案实施 → 方案完成。其中四个关键节点：

节点	关键动作与价值
① 需求澄清	AI 反过来问你几个问题——技术栈？性能要求？兼容老版本？用户量级？通过一两轮澄清把模糊需求变成清晰需求。拒绝"一拍脑袋就开始写"——需求不清的时候，越快动手越要返工
② 方案制定	需求 + 技术 + 设计 · 任务拆解完整输出。不只给代码骨架，而是一份可以直接当设计文档用的产物：需求列表、技术选型、架构图、数据模型、接口契约、前后端任务拆解。团队成员看着这份方案就能跟上你的思路
③ 方案编辑 / 确认	这是 Plan 最独特的价值所在——AI 真正动手前你可以直接改方案文字：换技术选型、调整任务顺序、补充约束条件。改一行方案的成本，远远低于改一行已生成的代码
④ 方案归档	方案执行完不会丢——自动保存到项目的 `.codebuddy` 目录，可以提交 Git 作为设计文档、可以分享、可以复用。Plan 的产出是团队级资产，不是一次性消耗品

三类典型场景

**① 新功能实现。**需求"电商优惠券功能，固定金额 + 百分比折扣"，Plan 先澄清两个关键问题——*能否组合使用？有无次数限制？*这两个问题不想清楚直接 Craft，方案做到一半会卡住：Schema 要不要加"组合规则"字段？API 要不要支持多券核销？这些决定直接影响数据模型。

② 项目迁移。需求"JS → TypeScript 迁移"——这类任务几乎只有 Plan 能做好。Plan 制定分步迁移计划：配置 tsconfig → 核心模块优先 → 逐步覆盖更新 → 更新构建流程。每步可独立验证是迁移类任务的关键——一次性全改完，出问题不知道哪一步引起的。

③ 多文件协同。需求"WebSocket 聊天功能，前端 + 后端推送"——核心难点是前后端要对齐。Plan 在开工前就把接口契约、消息格式、状态管理定死，前后端照着同一份方案各自实现，联调一次过。

下面这段视频聚焦"新功能实现"，把澄清 → 方案 → 编辑 → 执行这条 Plan 的灵魂主线完整跑一遍，看 Plan 在动手前"反问你"这个 Craft 永远不会有的瞬间。

Plan vs Craft 深度对比

"Plan 和 Craft 到底怎么选？"——核心结论：架构级改动用 Plan，细节级调整用 Craft。

维度	Plan	Craft
工作方式	先规划后执行	直接执行快速响应
输出形式	完整方案文档（需求 + 技术 + 设计 + 任务）	代码 Diff 结果
可控性	高 · 执行前审阅	中 · 边做边调
适用场景	复杂功能 / 架构	Bug 修复 / 局部优化

判断标准

改动会不会影响文件结构、接口契约、数据模型？会，Plan；不会，Craft。最高效的用法是组合——Plan 整体规划，中间切 Craft 处理局部问题。Plan 保方向，Craft 保效率。

2.4 三模式选择决策框架

Ask 是「问」，Craft 是「做」，Plan 是「先想清楚再做」。

四类场景的选择路径

场景	推荐模式	核心特点
快速获取信息	Ask	查 API / 解释代码 / 获取片段。安全、无副作用，探索阶段最放心
明确任务执行	Craft	修 Bug / 重构 / 实现功能。问题明确 + 直接动手，效率最高
复杂需求规划	Plan	新功能 / 迁移 / 多模块协同。需要全局视角，跑偏代价高
四阶段闭环	组合使用	Ask 评估 → Plan 规划 → Craft 执行 → Ask 验证

最佳组合流程

Ask 评估——先问 AI 这个方案有没有明显的坑、选型有没有替代方案
Plan 规划——出完整方案并编辑确认方向
Craft 执行——按方案落地代码
Ask 验证——写完让 AI 从审查者角度检查一遍代码

高效 AI 协作 · 四个维度

需求描述——具体明确（避免"优化一下代码"，改成"把这个函数从 O(n²) 降到 O(n)"）+ 指定技术栈 + 给出约束。 上下文管理——@ 精确引用 + 保持对话连贯 + 关键文件先添加。 质量保证——关键代码人工复核 + Checkpoint 大胆尝试 + 从简单开始验证。 效率提升——Diff 审查习惯 + 迭代式小目标 + Ctrl+Shift+V（对话面板）/ Cmd+I（内联编辑）。

本章小结

Ask · 顾问角色——只建议不执行，安全可控透明。关键技巧：@ 引用给精准上下文
Craft · 执行者角色——直接读写文件、运行命令、Checkpoint 保护。关键习惯四件套：上下文管理 + Checkpoint + 迭代协作 + Diff 审查
Plan · 架构师角色——先规划后执行，方案可归档复用。五步生命周期：澄清 → 制定 → 编辑 → 实施 → 归档（仅 IDE 形态支持）
选型策略——架构级用 Plan，细节级用 Craft；最佳组合 Ask 评估 → Plan 规划 → Craft 执行 → Ask 验证

下一模块进入**「System Prompt 与 Rules」**——把个人编码规范、团队代码标准、项目约束条件固化到每一次对话里，让 Craft 和 Plan 真正"听话"。