用 Claude Code下称 CC半年多累计消耗数十亿 tokens。踩过不少坑也读了大量官方文档和实践者分享慢慢沉淀出一套自己的工作流。这篇不追求面面俱到只讲经过长期验证、确实能提升交付质量的 7 个实践。核心思路**CC 的开箱体验已经足够好效率差距来自工作流的组合方式。**以下每个技巧都是在解决一个具体的工程问题而非通用建议。01Plan 模式先行用规格文档代替即兴编码CC 最容易踩的坑是直接开始改代码。模型在缺乏规格约束时会基于对需求的直觉理解做决策而这些决策往往和你的预期有偏差——尤其是跨文件重构和新功能开发。Plan 模式的价值在于把理解需求和执行实现分成两个阶段前者可逆、成本低后者一旦开始就消耗 tokens 和上下文。具体做法除了单文件的小修改bug fix、文案调整一律先在对话里输出一份执行计划包含——涉及哪些文件、改动策略、风险点、验证方式。你可以来回迭代这份计划直到它和你的设计意图对齐。确认后再切到自动接受模式执行。对于更复杂的任务多模块、跨会话用spec 模式把需求写成结构化文档功能描述、验收标准、技术约束CC 会基于 spec 分解为子任务逐一执行。spec 的价值是让后续会话也能回溯同一份规格而不是依赖对话记忆。推理深度上复杂问题可以用 think、think hard、ulrathink 分级触发更深的推理链。但注意推理深度不是越深越好简单任务用默认档即可否则响应时间会显著拉长。02CLAUDE.md 的工程化写法最小约束集CLAUDE.md 会被注入到每次会话的系统提示词中。这意味着它的每一行都在占用上下文窗口同时在影响模型行为。常见误区是把项目文档、API 说明、设计规范全部塞进去——结果关键指令被淹没模型反而抓不住重点。我的原则是只写三类约束控制在 20 行以内Code Style遵循项目已有的命名和结构不引入新框架Decision Policy涉及架构选型或数据模型变更时先提出 2-3 个方案及权衡等待确认后再写代码Anti-Overengineering不为未来可能的需求添加抽象层或兼容分支**第一类代码风格约束。**明确告诉模型跟着现有代码走避免它引入不一致的模式。比如已有项目用 Composition API就不要让它 Options API 重写一个组件。**第二类决策点拦截。**模型最大的风险不是写不出代码而是在关键设计决策上替你做了选择。这条规则的作用是在架构选型、数据模型、接口设计这类不可逆决策上先出方案等确认而不是直接实现。**第三类拒绝过度工程。**AI 修改代码时倾向于添加防御性分支和抽象层来保证健壮性但大部分场景下这些是冗余。这条规则让它只做当前需求要求的事不替你设计你没要求的扩展性。**原则**CLAUDE.md 是配置文件不是文档。每加一条规则都要问自己——这条规则值不值得占用每次会话的上下文预算不值得的放到按需加载的文件里见技巧 04。03UI 生成的三种约束策略AI 生成 UI 的典型问题是功能完整但视觉粗糙——默认配色方案、间距不一致、组件风格不统一。解决思路是在生成代码之前先用某种形式把设计决策固定下来而不是让模型自己猜。**策略一Figma 原型 MCP 直连。**用 Figma 画出高保真原型通过 MCPModel Context Protocol把设计稿的布局、间距、颜色变量直接传给 CC。Opus 级别模型的还原度可以到 90% 以上Sonnet 级别约 85%。适合有设计基础、对视觉精度要求高的场景。**策略二草图 ASCII 布局确认。**在 Excalidraw 或白板上画低保真线框拍照喂给 CC要求它先用 ASCII 字符画出布局树——哪个区域放什么组件、层级关系如何。你在这个阶段调整布局逻辑确认后再让它生成组件代码。这个方法不需要设计软件迭代速度快适合快速验证信息架构。Excalidraw 线框草图 CC 生成的 ASCII 布局结构**策略三设计系统文档注入。**把产品的配色 token、字体层级、组件规范写成一份设计 Guideline让 CC 在生成 UI 时严格引用。这个方法的本质是把审美判断转化为规则查询减少模型在视觉细节上的自由发挥。三种策略可以叠加Figma 定结构设计系统定细节。另外专门的 UI/UX 审查类 Skill 很有价值——它能在代码生成后做一轮设计规范检查过滤掉 AI 高频犯的错误模式如滥用蓝紫渐变、默认 Material Design 风格、间距不统一等。04上下文窗口管理主动压缩而非被动等截断Claude Code 的上下文窗口不是无限的。当占用超过约 50% 时模型开始出现注意力衰减漏掉早期指令、重复已经解决过的问题、响应质量下降。这不是 bug而是长上下文模型的已知特性——位置越靠后的内容权重越高前面的内容会被逐步压缩。**一个会话只做一件事。**任务完成后用 /clear 或 /new 重置不要在同一个会话里连续做不相关的任务。CC 会自动做上下文压缩compaction但压缩是有损的——历史细节会被概括成摘要精确的代码片段和决策理由可能丢失。**用 Git 做任务隔离。**每个任务开独立分支完成后合并或丢弃。这有两个作用一是 AI 改错了可以立刻回退二是分支本身就是任务边界——新开分支意味着新会话不需要清理上下文。**把决策沉淀到项目文件里。**会话结束前把讨论中的关键设计决策、技术选型理由写进项目文档如 ARCHITECTURE.md、DECISIONS.md。这些文档是给下一个会话的 CC 看的——它启动时会读 CLAUDE.md 和相关文档而不是依赖对话记忆。**CLAUDE.md 懒加载模式。**不要把所有项目文档都塞进 CLAUDE.md。主文件只放索引表告诉 CC遇到什么场景去读哪个文件CLAUDE.md 懒加载索引按场景指向对应文档这样 CLAUDE.md 始终保持在几十行以内详细文档架构说明、API 规范、调试指南只在 CC 判断需要时才主动读取。这比一次性把所有内容灌入上下文有效得多。05Skill 与 SubAgent 的选型逻辑CC 有两种扩展能力的机制但它们的上下文模型完全不同选错了会直接影响效果和 token 成本。**Skill 是主上下文内的渐进式加载。**CC 判断需要时才加载 Skill 的指令文件加载后这些内容进入主对话的上下文窗口。这意味着 Skill 能看到你当前会话的完整历史——你之前写了什么代码、讨论了什么设计决策它都知道。适合需要理解项目上下文、但产出相对独立的任务比如代码审查需要看你刚写的代码、写文档需要理解当前实现。**SubAgent 是完全隔离的子上下文。**它启动一个全新的对话窗口不继承主会话的历史只接收你传入的任务描述。执行过程中产生的中间步骤、文件读写记录都不会回传主对话只有最终结果被汇报回来。适合独立、可并行、不需要看你当前对话历史的任务比如跑测试、生成报告、批量处理文件。**决策框架**如果任务需要知道你刚才在做什么——用 Skill如果任务是给你一个独立目标做完把结果给你——用 SubAgent。两者也可以组合Skill 负责理解上下文并拆解任务SubAgent 负责并行执行子任务。06多会话并行与对抗式校验CC 支持长时间自主执行不需要你盯着每一步。实践中我同时开多个 CC 会话每个跑一个独立任务分支系统通知提醒需要确认时再切过去。这样我可以同时推进前端重构、后端接口、文档更新而不是串行等待。多个 CC 会话并行执行不同任务分支并行的关键是任务边界要干净每个会话改不同的文件或模块避免多个 CC 同时改同一个文件导致 Git 冲突。如果任务之间有依赖关系比如先定接口再写前端就不要并行串行执行更可靠。更进一步是对抗式校验让一个 Agent 写实现另一个 Agent 做 Code Review第三个跑测试。多个独立上下文从不同视角审视同一份代码互相补盲。这比让同一个 Agent 自己写自己审要有效得多——后者存在确认偏误倾向于维护自己刚生成的代码。07模型分层按任务复杂度分配算力不同模型在推理深度、工具调用准确率、响应速度上差异明显。全用最强模型成本高全用最轻量模型质量不稳定。我的做法是按任务类型分层层级模型适用场景主力Opus thinking架构设计、复杂重构、关键 bug 定位副手Sonnet / Kimi K2.5 / GLM 5常规功能开发、单文件修改、代码解释专项Codex深度 debug、性能分析、安全审查主力模型用 thinking 模式的理由虽然单次响应慢但推理链更长工具调用的准确率更高需要人工纠偏的轮次更少。整体算下来省下的纠正时间超过了等待时间。副手模型处理明确的、边界清晰的任务不浪费强模型的算力。专项模型在特定类型问题上如底层 bug、性能瓶颈的表现往往超过通用主力。两个工程化细节**权限模式的权衡。**本地开发环境中–dangerously-skip-permissions 可以跳过每次文件读写的确认弹窗显著提升交互流畅度。但这意味着 CC 可以不受限制地执行 shell 命令和修改文件。建议只在 Git 已提交、分支隔离干净的前提下使用避免模型在无确认状态下做不可逆操作。**/insights 定期复盘。**这个命令会分析你的使用历史生成一份结构化报告——项目时间分布、工具调用频率、主要阻塞点、效率趋势。它的价值不是看数字而是发现自己的使用模式问题比如你是否在重复让 CC 做同一件事、哪个阶段最容易卡住、模型选择是否合理。建议每月跑一次。**总结**这 7 个实践的底层逻辑是一致的——把不确定性留到可逆的阶段把确定性交给自动化。Plan 模式在编码前消除需求歧义CLAUDE.md 在每次会话注入最低必要约束上下文管理防止长对话中的注意力衰减Skill/SubAgent 按隔离级别选择执行路径并行和多 Agent 用空间换时间模型分层按任务分配算力。工具本身会持续迭代但这套先约束后执行、先设计后编码的方法论可以迁移到任何 AI 编程环境。关注我们一起把技术讲明白 —— 寻码札记
我的 Claude Code 最佳实践 7 个经过验证的工作流技巧
用 Claude Code下称 CC半年多累计消耗数十亿 tokens。踩过不少坑也读了大量官方文档和实践者分享慢慢沉淀出一套自己的工作流。这篇不追求面面俱到只讲经过长期验证、确实能提升交付质量的 7 个实践。核心思路**CC 的开箱体验已经足够好效率差距来自工作流的组合方式。**以下每个技巧都是在解决一个具体的工程问题而非通用建议。01Plan 模式先行用规格文档代替即兴编码CC 最容易踩的坑是直接开始改代码。模型在缺乏规格约束时会基于对需求的直觉理解做决策而这些决策往往和你的预期有偏差——尤其是跨文件重构和新功能开发。Plan 模式的价值在于把理解需求和执行实现分成两个阶段前者可逆、成本低后者一旦开始就消耗 tokens 和上下文。具体做法除了单文件的小修改bug fix、文案调整一律先在对话里输出一份执行计划包含——涉及哪些文件、改动策略、风险点、验证方式。你可以来回迭代这份计划直到它和你的设计意图对齐。确认后再切到自动接受模式执行。对于更复杂的任务多模块、跨会话用spec 模式把需求写成结构化文档功能描述、验收标准、技术约束CC 会基于 spec 分解为子任务逐一执行。spec 的价值是让后续会话也能回溯同一份规格而不是依赖对话记忆。推理深度上复杂问题可以用 think、think hard、ulrathink 分级触发更深的推理链。但注意推理深度不是越深越好简单任务用默认档即可否则响应时间会显著拉长。02CLAUDE.md 的工程化写法最小约束集CLAUDE.md 会被注入到每次会话的系统提示词中。这意味着它的每一行都在占用上下文窗口同时在影响模型行为。常见误区是把项目文档、API 说明、设计规范全部塞进去——结果关键指令被淹没模型反而抓不住重点。我的原则是只写三类约束控制在 20 行以内Code Style遵循项目已有的命名和结构不引入新框架Decision Policy涉及架构选型或数据模型变更时先提出 2-3 个方案及权衡等待确认后再写代码Anti-Overengineering不为未来可能的需求添加抽象层或兼容分支**第一类代码风格约束。**明确告诉模型跟着现有代码走避免它引入不一致的模式。比如已有项目用 Composition API就不要让它 Options API 重写一个组件。**第二类决策点拦截。**模型最大的风险不是写不出代码而是在关键设计决策上替你做了选择。这条规则的作用是在架构选型、数据模型、接口设计这类不可逆决策上先出方案等确认而不是直接实现。**第三类拒绝过度工程。**AI 修改代码时倾向于添加防御性分支和抽象层来保证健壮性但大部分场景下这些是冗余。这条规则让它只做当前需求要求的事不替你设计你没要求的扩展性。**原则**CLAUDE.md 是配置文件不是文档。每加一条规则都要问自己——这条规则值不值得占用每次会话的上下文预算不值得的放到按需加载的文件里见技巧 04。03UI 生成的三种约束策略AI 生成 UI 的典型问题是功能完整但视觉粗糙——默认配色方案、间距不一致、组件风格不统一。解决思路是在生成代码之前先用某种形式把设计决策固定下来而不是让模型自己猜。**策略一Figma 原型 MCP 直连。**用 Figma 画出高保真原型通过 MCPModel Context Protocol把设计稿的布局、间距、颜色变量直接传给 CC。Opus 级别模型的还原度可以到 90% 以上Sonnet 级别约 85%。适合有设计基础、对视觉精度要求高的场景。**策略二草图 ASCII 布局确认。**在 Excalidraw 或白板上画低保真线框拍照喂给 CC要求它先用 ASCII 字符画出布局树——哪个区域放什么组件、层级关系如何。你在这个阶段调整布局逻辑确认后再让它生成组件代码。这个方法不需要设计软件迭代速度快适合快速验证信息架构。Excalidraw 线框草图 CC 生成的 ASCII 布局结构**策略三设计系统文档注入。**把产品的配色 token、字体层级、组件规范写成一份设计 Guideline让 CC 在生成 UI 时严格引用。这个方法的本质是把审美判断转化为规则查询减少模型在视觉细节上的自由发挥。三种策略可以叠加Figma 定结构设计系统定细节。另外专门的 UI/UX 审查类 Skill 很有价值——它能在代码生成后做一轮设计规范检查过滤掉 AI 高频犯的错误模式如滥用蓝紫渐变、默认 Material Design 风格、间距不统一等。04上下文窗口管理主动压缩而非被动等截断Claude Code 的上下文窗口不是无限的。当占用超过约 50% 时模型开始出现注意力衰减漏掉早期指令、重复已经解决过的问题、响应质量下降。这不是 bug而是长上下文模型的已知特性——位置越靠后的内容权重越高前面的内容会被逐步压缩。**一个会话只做一件事。**任务完成后用 /clear 或 /new 重置不要在同一个会话里连续做不相关的任务。CC 会自动做上下文压缩compaction但压缩是有损的——历史细节会被概括成摘要精确的代码片段和决策理由可能丢失。**用 Git 做任务隔离。**每个任务开独立分支完成后合并或丢弃。这有两个作用一是 AI 改错了可以立刻回退二是分支本身就是任务边界——新开分支意味着新会话不需要清理上下文。**把决策沉淀到项目文件里。**会话结束前把讨论中的关键设计决策、技术选型理由写进项目文档如 ARCHITECTURE.md、DECISIONS.md。这些文档是给下一个会话的 CC 看的——它启动时会读 CLAUDE.md 和相关文档而不是依赖对话记忆。**CLAUDE.md 懒加载模式。**不要把所有项目文档都塞进 CLAUDE.md。主文件只放索引表告诉 CC遇到什么场景去读哪个文件CLAUDE.md 懒加载索引按场景指向对应文档这样 CLAUDE.md 始终保持在几十行以内详细文档架构说明、API 规范、调试指南只在 CC 判断需要时才主动读取。这比一次性把所有内容灌入上下文有效得多。05Skill 与 SubAgent 的选型逻辑CC 有两种扩展能力的机制但它们的上下文模型完全不同选错了会直接影响效果和 token 成本。**Skill 是主上下文内的渐进式加载。**CC 判断需要时才加载 Skill 的指令文件加载后这些内容进入主对话的上下文窗口。这意味着 Skill 能看到你当前会话的完整历史——你之前写了什么代码、讨论了什么设计决策它都知道。适合需要理解项目上下文、但产出相对独立的任务比如代码审查需要看你刚写的代码、写文档需要理解当前实现。**SubAgent 是完全隔离的子上下文。**它启动一个全新的对话窗口不继承主会话的历史只接收你传入的任务描述。执行过程中产生的中间步骤、文件读写记录都不会回传主对话只有最终结果被汇报回来。适合独立、可并行、不需要看你当前对话历史的任务比如跑测试、生成报告、批量处理文件。**决策框架**如果任务需要知道你刚才在做什么——用 Skill如果任务是给你一个独立目标做完把结果给你——用 SubAgent。两者也可以组合Skill 负责理解上下文并拆解任务SubAgent 负责并行执行子任务。06多会话并行与对抗式校验CC 支持长时间自主执行不需要你盯着每一步。实践中我同时开多个 CC 会话每个跑一个独立任务分支系统通知提醒需要确认时再切过去。这样我可以同时推进前端重构、后端接口、文档更新而不是串行等待。多个 CC 会话并行执行不同任务分支并行的关键是任务边界要干净每个会话改不同的文件或模块避免多个 CC 同时改同一个文件导致 Git 冲突。如果任务之间有依赖关系比如先定接口再写前端就不要并行串行执行更可靠。更进一步是对抗式校验让一个 Agent 写实现另一个 Agent 做 Code Review第三个跑测试。多个独立上下文从不同视角审视同一份代码互相补盲。这比让同一个 Agent 自己写自己审要有效得多——后者存在确认偏误倾向于维护自己刚生成的代码。07模型分层按任务复杂度分配算力不同模型在推理深度、工具调用准确率、响应速度上差异明显。全用最强模型成本高全用最轻量模型质量不稳定。我的做法是按任务类型分层层级模型适用场景主力Opus thinking架构设计、复杂重构、关键 bug 定位副手Sonnet / Kimi K2.5 / GLM 5常规功能开发、单文件修改、代码解释专项Codex深度 debug、性能分析、安全审查主力模型用 thinking 模式的理由虽然单次响应慢但推理链更长工具调用的准确率更高需要人工纠偏的轮次更少。整体算下来省下的纠正时间超过了等待时间。副手模型处理明确的、边界清晰的任务不浪费强模型的算力。专项模型在特定类型问题上如底层 bug、性能瓶颈的表现往往超过通用主力。两个工程化细节**权限模式的权衡。**本地开发环境中–dangerously-skip-permissions 可以跳过每次文件读写的确认弹窗显著提升交互流畅度。但这意味着 CC 可以不受限制地执行 shell 命令和修改文件。建议只在 Git 已提交、分支隔离干净的前提下使用避免模型在无确认状态下做不可逆操作。**/insights 定期复盘。**这个命令会分析你的使用历史生成一份结构化报告——项目时间分布、工具调用频率、主要阻塞点、效率趋势。它的价值不是看数字而是发现自己的使用模式问题比如你是否在重复让 CC 做同一件事、哪个阶段最容易卡住、模型选择是否合理。建议每月跑一次。**总结**这 7 个实践的底层逻辑是一致的——把不确定性留到可逆的阶段把确定性交给自动化。Plan 模式在编码前消除需求歧义CLAUDE.md 在每次会话注入最低必要约束上下文管理防止长对话中的注意力衰减Skill/SubAgent 按隔离级别选择执行路径并行和多 Agent 用空间换时间模型分层按任务分配算力。工具本身会持续迭代但这套先约束后执行、先设计后编码的方法论可以迁移到任何 AI 编程环境。关注我们一起把技术讲明白 —— 寻码札记