用 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 画出高保真原型，通过 MCP（Model 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 编程环境。
关注我们，一起把技术讲明白 —— 寻码札记
