CodeBuddy 三种模式实操：什么时候问、规划和直接开发
这份练习不要求你记住 CodeBuddy 的所有界面，而是通过三个任务建立模式选择习惯。不同版本的入口可能变化，但 Ask 用于理解、Plan 用于复杂任务的可预见性、Craft 用于明确改动的基本分工仍然成立。
前置条件
- 已安装并登录 CodeBuddy IDE 或支持相同工作方式的 AI 编程工具。
- 准备一个可以运行的小型 Web 项目，并先提交 Git 基线。
- 知道项目的启动命令，能够在浏览器里看到当前页面。
- 本练习不使用包含真实密钥或隐私数据的项目。
练习一：用 Ask 读懂陌生项目
打开项目后先不要让 AI 修改文件，提出下面的问题：
请只读分析当前项目，不修改文件。说明技术栈、目录职责、启动命令、主要页面、数据来源和最值得先验证的三条用户流程。每条结论注明来自哪个文件。
然后继续追问：
- 首页数据从哪里来？
- 点击某张卡片后经过哪些组件和路由？
- 当前项目有哪些构建、类型或测试命令？
- 哪些配置在本地运行时必须存在？
成功标准
- AI 没有修改文件。
- 结论能够对应到真实路径，而不是通用猜测。
- 你可以按照说明启动项目并复述一条调用链。
如果它给出的启动命令无法运行，把终端真实输出反馈给它，要求修正认知，而不是立即允许改代码。
练习二：用 Plan 规划一个跨文件功能
选择一个需要页面、接口和数据共同变化的功能，例如“为商品增加库存预警”。输入：
进入 Plan，先澄清需求，不修改代码。目标是在现有商品管理中增加库存预警。请确认用户角色、阈值来源、页面展示、接口和数据库影响、异常场景、验收标准以及明确不做的范围。读取现有架构后输出可执行计划。
回答 AI 的澄清问题后，重点审查：
- 是否沿用了现有技术栈和组件？
- 是否指出具体影响文件和数据迁移？
- 是否包含正常、边界和权限场景？
- 是否把通知、补货等额外想法偷偷加入范围？
- 每一步是否有明确验证方式？
确认计划后再执行。当前 CodeBuddy 官方 Plan 模式会把需求澄清、方案、确认和执行串成一条生命周期；真正关键的是在代码生成前完成人工评审。
成功标准
- 计划与项目真实结构一致。
- 功能被拆成可验证步骤。
- 执行后数据库、接口和页面均有证据。
- 所有验收项完成后才标记结束。
练习三：用 Craft 完成一个明确小改动
选择影响范围很小的任务，例如修改空状态文案并补充图标替代文本：
将商品列表无数据时的文案改为“暂时没有商品”，保留现有布局和样式；为图标补充可访问名称。只修改相关组件，完成后运行类型检查并告诉我实际修改文件。
这类任务不需要长计划，但仍要限制范围和验证结果。
成功标准
- 只修改必要文件。
- 页面真实显示新文案。
- 类型检查通过。
- 不影响有数据状态。
常见问题与处理
Ask 阶段 AI 开始改文件
立即停止，明确要求只读分析，并使用 Git 检查是否产生改动。
Plan 写得很长但没有验证
要求每个步骤增加“完成证据”，例如具体 URL、接口响应、测试命令和截图，而不是“确保功能正常”。
Craft 顺手重构大量代码
停止任务并回退非必要修改。重新把范围写成“只修改哪个组件、保持哪些行为不变”。
显示完成但页面没变化
确认访问的是当前项目的真实端口，必要时停止旧服务并重新启动。不要只相信 AI 的文字总结。
练习记录
完成后建立一张三列表：任务、选择的模式、选择理由。再补一列“我用什么证据确认完成”。能够解释模式选择，比记住快捷键更重要。
把一次对话沉淀成项目约定
当项目不再是一次性练习，可以先在项目根目录执行 CodeBuddy CLI 的 /init，让工具分析仓库并生成 CODEBUDDY.md。人工检查后，把启动命令、目录职责、验证命令和不可触碰的边界留在文件里。它的价值不是“让 AI 永远记住一切”，而是让新会话从同一份可审查的项目事实开始。
还可以把团队长期适用的偏好放入项目记忆，例如统一包管理器、提交前必须运行的检查、禁止写入真实密钥。记忆内容要短、稳定、可验证；临时需求和某次报错不应沉淀成永久规则。
用 Hooks 固化关键动作
如果希望每次修改后自动运行格式检查，或在危险命令前提示，可以在支持的版本中配置 Hooks。CodeBuddy 官方文档将 Hooks 标为 Beta，并要求 CLI 1.16.0 及以上；项目级配置位于 .codebuddy/settings.json。先从只读、快速的检查开始，不要一上来挂载耗时全量构建或未经确认的自动修复。
无论是 CODEBUDDY.md、记忆还是 Hooks，都必须进入代码评审。它们会持续影响后续 Agent 行为，错误规则的影响范围往往比一次错误提示词更大。