Claude Code 实战工作流：从受控执行到可视化复核

这篇文章把 Claude Code 的用法拆成一条可复核的流水线：先在真实项目里给出边界清晰的任务，再让模型读仓库、出计划，最后用终端和 VS Code 双重验证结果。核心观点是别一上来就丢一个大 prompt，而是用检查点控制每一步。

用真实项目起步，别写万能 prompt

• 在已有明确用途的项目目录里启动，先确认工作目录和当前分支，再挑一个范围小的任务，比如加设置面板、修一个失败测试、改一个 API 返回。
• Claude Code 跑在终端里，可以和 VS Code、JetBrains 等 IDE 并行使用，终端负责执行，编辑器负责复核。
• 反面例子是“帮我把产品做出来”，范围太大没有检查点；好的 prompt 要说清现在代码做什么、要改什么行为、哪些不能动、怎么算成功。
• 示例：仪表盘现在把所有发票放在一个列表里，改成按客户分组，保留导出按钮、URL 结构和现有筛选，先读相关文件给方案，批准前不要改。

先建仓库上下文，再动手改

• 第一个请求应该是让模型读仓库：找出入口、相关功能文件、测试命令和配置文件，总结架构、列出相关文件、给出实现计划，暂不编辑。
• 这样能在纠错成本最低的时候暴露错误假设，比如框架、测试命令或功能边界认错了，先纠正再批准计划。
• 在仓库根目录放 CLAUDE.md 记录语言、框架、命名规范、测试命令、评审标准和禁止改动的文件；CLAUDE.local.md 用于本地、被 git 忽略的偏好。
• 自动记忆存在 MEMORY.md，会话启动时加载前 200 行或 25 KB；CLAUDE.md 有 4 MiB 上限，别把它写成第二套文档系统。

把终端当成受控的工具循环

• 流程是：说一个具体目标，让模型读文件或跑命令，复核它提议的动作，明确批准或拒绝，再看输出、改动文件列表和 diff。
• 每条命令都要回答一个具体问题：搜索定位代码路径，测试看行为是否变化，本地服务看应用能否启动，复现命令确认 bug 是否还在。
• 修表单失败的顺序可以是：找到注册表单的校验逻辑，跑现有表单测试，用最窄的相关测试命令复现失败，在不改 API 契约的前提下提修复方案。
• 请求没有边界时改动会蔓延，“重写认证流程”会带来无关编辑，“修复密码重置成功后的跳转，token 生成、错误信息和路由名不变”搜索空间更小。
• diff 碰到无关模块就拒绝该动作并收窄 prompt；不要在没有隔离分支和复核点的情况下让模型自动改整个工作区。

用 VS Code 做可视化复核

• 终端记录显示的是活动，编辑器显示的是状态：在 VS Code 里打开项目，看改动文件、读 diff、看诊断信息、本地跑应用。
• 终端可能告诉你改了三个文件，但只有编辑器能确认改动是否符合预期、别处是否冒出诊断问题、功能在运行的应用里是否正常。
• Cursor 也是编辑器中心的思路，提供并行自主 agent；选择标准很简单，哪个环境最容易看清改动文件、运行时输出和审批边界就用哪个。
• 合并前的检查点：diff 符合请求范围、诊断信息已理解、相关测试通过、应用能在本地启动、可见行为符合要求。

上下文、MCP 与并行任务要刻意管理

• 读过的文件、发出的 prompt、跑过的命令和工具结果都占上下文窗口，长会话需要主动清理。
• 同一功能还要继续时用 /compact 压缩，但要检查摘要是否丢了细节；当前功能完成、下一个任务目标不同时用 /clear；反复修复后开始出现猜测、矛盾计划或多余编辑，就开新会话。
• MCP 把 Claude Code 接到外部工具和数据源，可按项目、用户或托管范围配置，支持单服务器或全局超时；相关任务文档标注为公开 beta，需要 Claude Code v2.1.304 或更高版本。
• 只开当前任务相关的 MCP 服务；如果某个工具请求了你没预期的凭证或副作用，先暂停，要求手动认证并显式 /mcp login 后再继续。

规模化之前先加运行时检查点

• 四个检查点：上下文（模型知道什么，证据是仓库地图、CLAUDE.md、会话摘要）、动作（能改什么、能调什么，证据是提议的命令、工具范围、worktree）、复核（验证了什么，证据是 diff、诊断、测试、运行时输出）、迭代（下一步是批准后续、/compact、/clear 还是交接）。
• 按任务类型套用这套模型，功能开发、修 bug、重构的复核重点不同，但每个阶段都要留下可检查的证据。

今天就能做

• 下次开 Claude Code 会话时，先让它读仓库并给出计划，批准前不要改任何文件。
• 在项目根目录写一份精简的 CLAUDE.md，列出测试命令、命名规范和禁止改动的目录。
• 合并前固定走一遍：diff 范围、诊断、测试、本地启动、可见行为五项都过。