Vibe Coding – Claude Code 上下文管理实战指南

面向人群：日常使用 Claude Code 或其他 AI 助手写代码、查日志、排 Bug 的开发者、架构师和技术负责人，希望系统提升「AI 生产力」而不是被它拖累。

一、引言：AI 不是变笨了，是你把它喂废了

很多人都有这种体验：
和 AI 助手刚开始聊天时，它像个经验老道的架构师，能分析系统、梳理依赖、写出像样的代码；但聊上半小时后，它突然就像个听不懂人话的实习生，开始犯各种低级错误、忘事、答非所问。

多数人会怪模型：是不是出 Bug 了？是不是自己没选对模型？是不是提示词还不够“高级”？作者给出的结论很直接：它没变笨，是你把它的脑子塞满了垃圾。

在使用 Claude Code 三个月的实战中，最大的坑不是“玄学 Prompt”，而是大多数人每天在用，却没有搞懂底层逻辑的东西——上下文窗口（Context Window）。

二、核心概念：上下文窗口是一块会写满的白板

Claude 的“大脑”可以被看作一块白板：你发给它的每条消息、它读过的每个代码文件、看过的每条终端命令输出，都会被写在这块白板上。

问题在于：这块白板会写满。一旦写满，模型就不得不“遗忘”一部分内容，表现为：

• 忘记之前你反复强调的业务约束和编码规范
• 开始犯非常基础的语法或逻辑错误
• 回答变得啰嗦、模糊，甚至反复自我重复

这种现象称为 “上下文污染”。

Anthropic 工程师 Boris Cherny 的观点是：想驾驭好 Claude Code 这种强大的代码代理工具，根本中的根本，就是管理好这块白板。

后面的 9 条策略，就是围绕「如何管理好上下文白板」展开的体系化实战经验。

三、策略一：别一上来就写代码，先让 AI 进入“计划模式”

新手最容易踩的坑：抛出一个宏大的需求，就直接让 Claude 开始写代码。
结果常常是：

• 代码改了一大堆，核心问题没解决
• 生成的废代码占据了大量上下文空间，后面即使想“抢救”也做不到

推荐的做法是：先谋定而后动，优先进入 Plan Mode（计划模式）。

在 Claude Code 中，可以通过 Shift + Tab 切换到计划模式，此时 Claude 只做这些事：

• 阅读相关文件、梳理依赖和调用链路
• 形成详细的改动计划
• 但不会真正改动任何代码

典型的高效流程是：

1. 先切到计划模式，让 Claude 系统性地阅读、理解相关代码。
2. 强制它列出详细计划：改哪些文件、先后顺序、潜在风险点。
3. 像技术总监一样审查计划，发现不合理就打回重写。
4. 确认方案后，切回正常模式，严格按计划执行。
5. 完工后，让 Claude 生成清晰、规范的 commit message。

Boris 团队甚至会：用一个 Claude 实例专门写计划，再用另一个实例扮演“高级工程师”审查这个计划，等计划过关后才允许真正改动代码。

关键心法：多花 10 分钟在“思考与规划”上，能省掉之后几天在 Bug 和返工中的内耗。

四、策略二：用子代理（Subagent）把“脏活累活”隔离出去

当你需要排查一个复杂的线上问题时，往往需要：

• 翻大量微服务日志
• 看配置文件
• 顺着调用链追源码

如果这些操作都在主会话中进行，很快就会把上下文白板写满，等真正需要动手修复时，它已经“脑子不够用了”。

子代理（Subagent） 提供了一个硬核解法：

• 子代理是一个独立的 Claude 实例
• 它在自己的上下文中疯狂干脏活（读日志、扒源码等）
• 最后只把精炼后的结论汇报给主会话
• 主会话的上下文保持干净、聚焦在“决策和实施”上

使用方式非常简单：在调研指令后加一句魔法咒语：use subagents。

例如：

“用子代理帮我查一下支付中台那边异常重试链路是怎么处理超时交易的。”

子代理负责沉到“日志地狱”里挖结论，主会话则保持简洁专注，有足够空间来做重构、修复和新需求的实现。

对于前后端老兵来说，把“读日志、查源码、分析调用链”统统交给子代理，是效率跃迁的关键步骤。

五、策略三：把 CLAUDE.md 打造成你的“活规则书”

如果你天天用 Claude Code，但忽略项目根目录下的 CLAUDE.md 文件，那基本还是在“原始社会”玩 AI。

Claude 每次启动都会优先读取这个文件，它里面写的是：

• 代码风格和模块化约定（例如“必须使用 ES Modules，禁止 CommonJS”）
• 测试策略（例如“写单元测试时禁止使用 Mocks”）
• 提交前强制检查（例如“必须先跑 Linter”）
• 分支命名规范（例如 feature/Jira-XXX）

高阶玩法在于：让规则持续进化。
推荐的做法是：每当 Claude 犯错并被纠正后，都会在对话最后补一句：

“立刻更新 CLAUDE.md，把这个教训写进去，以免下次再犯！”

这样，AI 会把踩过的坑逐步固化到规则文件里。久而久之，CLAUDE.md 会演化成一份与你团队、与你项目高度匹配的“活规则书”。

举一个例子：Claude 曾在 Obsidian 库里乱建 .txt 文件，被多次纠正并写入规则后，这个错误就再也没出现过。

需要注意的是：

• 规则贵在精简，而不是越多越好
• 如果文件膨胀到 500 行，AI 的注意力会被严重稀释
• 要定期修剪，只保留“删了就会翻车”的铁律

六、策略四：把验证和验收标准写进提示词，拒绝人肉质检

传统工作流往往是：

1. 提出需求
2. 让 AI 写代码
3. 人类自己逐行 Review

这相当于把自己变成了唯一的质检员，长期下来非常消耗心力。

更优思路是：在提示词里直接内置验证和验收标准，让 AI 自己闭环校验。

示例一：写校验函数时，不要说：

“帮我写一个验证邮箱的函数。”

而应该说：

“写一个判断邮箱有效性的函数。写完后必须用以下测试用例进行自检：

• hello@gmail.com 应返回 true
• hello@ 应抛出异常
• @domain.com 应返回 false
  写完立刻在本地跑一遍测试，把结果发给我。”

示例二：改 UI 时，不要只说“改成这个设计图”，而是：

“把当前页面改成附件中的设计稿。改完后，请在本地起服务截图发我，并列出你改动的三处核心 CSS 属性。”

这种设计让：

• AI 先自测再给你看，减少明显错误
• 你只需关注关键逻辑是否符合业务，而不是人肉挑格式和边缘用例

要点是：不要让自己成为系统里唯一的反馈节点。

七、策略五：把 Prompt 当 API 文档来写

Claude 能从上下文里推断很多东西，但它终归不是“你肚子里的蛔虫”。

垃圾式提示词举例：

“给 auth.py 加个测试。”

更专业的写法是：

“为 auth.py 编写测试用例，必须覆盖用户在请求中途 Session 过期的场景。严禁使用任何外部库 Mock。重点覆盖 Token 表面有效但服务端已吊销的边缘分支。”

同样的问题，输出质量可能是天差地别。

提问 Bug 时也一样：

• 模糊问法：“为什么这个鉴权函数最近怪怪的？”
• 精准问法：“去查这个文件的 git 提交历史，找出这个异常鉴权拦截行为是在哪个版本引入的，当时关联的 Issue 是什么。”

实践原则：像写 API 文档一样写 Prompt：

• 明确输入边界和前置条件
• 明确输出形态和精度要求
• 明确约束（不能使用哪些库 / 手段）
• 明确验收标准（用什么方式认为“完成”）

你给出的“参数”越清晰，AI 的输出就越靠近你心里那个“正确答案”。

八、策略六：每 30–45 分钟进行一次上下文重置

对话时间拉得越长，Claude 越容易：

• 变得啰嗦、冗长
• 忘记一开始的硬性规则
• 回答质量肉眼可见地下滑

这背后的根本原因还是：白板被写满，不断在覆盖旧信息。

Anthropic 团队给自己的硬性规范是：每工作 30–45 分钟，强制进行一次上下文重置（Context Reset）。

具体操作流程：

1. 让 Claude 做一次阶段性总结：“过去 40 分钟做了什么、完成了哪些任务、还有哪些问题未解决。”
2. 关闭当前对话，重新开启一个全新的会话。
3. 把刚刚的总结贴到新会话中作为起点，继续工作。

这样，你得到的是：

• 一份结构清晰的阶段总结
• 一个干净利落的新上下文白板

很多人对旧会话“恋恋不舍”，总觉得里面有很多“宝贵上下文”。作者的观点很干脆：一个条理清晰的精炼总结，远比臃肿杂乱的历史对话有价值。

九、策略七：并行会话 + Git Worktree，像包工头一样组织多个 AI

Boris 团队公认的一条效率“核武器”是：并行会话配合 Git Worktree。

Git Worktree 允许你为同一个仓库创建多个独立工作区，而 Claude Code 可以针对不同工作区开不同会话。
典型的“流水线式”玩法是：

• 会话 A：专职实现新功能，疯狂写代码
• 会话 B：专职做代码审查，挑内存泄漏、边界情况和安全漏洞

流程大致是：

1. 让 A 写完功能。
2. 把 A 的改动交给 B，要求 B 用“冷酷的 reviewer”视角挑刺。
3. 再把 B 的审查意见丢给 A，要求其逐条修复。

在 TDD 流程中，更可以：

• 让一个 Claude 专门写刁钻的测试用例
• 让另一个 Claude 专门写能通过这些测试的业务代码

人类在这里真正变成了“包工头”：

• 负责目标拆解、资源分配和验收
• 把重体力活交给多个 AI 实例并行完成

一些高手甚至会同时开 3–5 个终端，为不同 Worktree 配置极简 Shell 别名（如 za、zb、zc），一键在不同 AI 工作流之间切换。

十、策略八：把重复流程固化为 Skill（技能）

在程序员世界里，有个朴素原则：一件事做第二遍，就该考虑自动化。 在 Claude Code 中，这种自动化的载体就是 Skill。

Skill 的本质是：

• 把一整套经过验证的高效工作流封装起来
• 用一个简短代号代替长提示词和复杂步骤
• 下次只需呼叫代号，整个流程自动展开

比如：

• 一键检查冗余代码
• 一键根据当前分支生成发布日志
• 一键把凌乱的接口说明整理成结构化 Markdown 文档等

这类 Skill 的意义在于：

• 把“每次都要复制粘贴一大堆话”的操作
• 变成“敲几个字母就能完成”的指令

现实经验是：任何你每天都要做两遍以上的 AI 操作，都值得封装成一个 Skill。

十一、策略九：用真实数据而不是主观猜测喂给 AI

传统排查 Bug 的方式通常是：

1. 工程师先用“模糊且可能带偏见”的语言描述问题
2. AI 根据这种描述去猜
3. 双方来回试错多轮，最终“撞大运”解决问题

这不仅耗时，还严重浪费上下文空间。

更硬核的做法是：把冷冰冰的真实数据直接砸给 AI，然后闭嘴。

Boris 团队的典型做法是：

• 监控报警时，直接把 Slack 中的错误日志、堆栈跟踪原样贴给 Claude
• 只给一个冷酷指令：“fix”

不做额外解释，不带任何主观倾向。大模型会自己：

• 顺着堆栈分析调用链
• 在代码中定位问题
• 给出修复方案

另一种用法是：

“去修好刚才 CI 流水线里挂掉的那个测试。”

你甚至不需要指出是哪个测试、为什么挂，它会自己查。

原则可以总结为：

• 多提供真实的错误日志、Docker 崩溃输出、网络抓包、CI 报错等
• 少提供带情绪和偏见的“口头转述”

在面对海量、枯燥的分布式系统日志时，大模型在“追踪故障根因”上的表现，往往会超出人类工程师的直觉。

十二、从「提示词技巧」到「注意力管理」：真正的核心能力是什么？

• 上下文窗口就是 AI 脑子里的那块白板
• 它的“面积”由模型和系统决定，总是有限的
• 但你可以决定在上面写什么、什么时候擦掉什么

从本质上看：上下文管理，其实就是在管理 AI 的认知注意力和算力分配。

这是一种新的技术能力：

• 它和你写不写得出高级算法无关
• 也和你是否是某个业务领域专家没有直接关系
• 但它会直接决定：你能从 AI 身上榨出多少实际生产力

在这个意义上，真正的“护城河”不是花哨高深的 Prompt，而是：

• 对上下文窗口的结构化管理能力
• 对“该写什么、该丢什么”的取舍能力
• 对如何组合多实例、多会话、多 Skill 的“工程化编排”能力

如把这 9 条策略变成自己的日常工作习惯，你和 AI 之间的关系，会从“会聊天的搜索引擎”，跃迁为“真正的工程搭档”。