解码 Claude Code(八)— 终章:从工具到工作流的艺术

解码 Claude Code(八)— 终章:从工具到工作流的艺术

Art of Workflow

这是我们"解码 Claude Code"系列的最后一章。在过去的七期中,我们从零开始探索了 Claude Code 的核心能力、实战技巧、工作流优化、工具集成、质量保障、真实案例和工作流编排。

现在,让我们回望整条探索之路,看看我们学到了什么,以及更重要的是——下一步该往哪里走


系列回顾:我们走过的路

第一期:初识 Claude Code

核心收获

  • 理解了 Claude Code 与传统 AI 编程工具的本质差异
  • 学会了基本的安装和认证流程
  • 掌握了三种核心用法:交互式、单次任务、全权委托

关键洞察

Claude Code 不是代码补全工具,而是一个能自主执行任务的编程伙伴。它的价值不在于写多快的代码,而在于能独立完成从理解需求到验证结果的完整流程。

第二期:斜杠命令的艺术

核心收获

  • /clear 的魔法:清除上下文,防止旧任务干扰新任务
  • /compact 的妙用:压缩对话历史,节省 Token 消耗
  • /cost 的警觉:实时查看花费,控制预算

关键洞察

每次独立任务完成后 /clear 一次,这是高效使用 Claude Code 的黄金法则。

第三期:CLAUDE.md 的力量

核心收获

  • 通过 CLAUDE.md 把项目规范文件化
  • 三层 CLAUDE.md 架构:项目级、模块级、子模块级
  • 渐进式披露:按需加载知识,节省 Token

关键洞察

把知识写进文件,而不是在聊天里反复说。Claude Code 启动时自动读取 CLAUDE.md,一次配置,终身受益。

第四期:实战开发技巧

核心收获

  • 任务描述的艺术:明确需求、边界、技术细节
  • 自我纠错循环:编译失败自动修复
  • 安全建议:不要在生产环境使用全权委托模式

关键洞察

Claude Code 会真的去读你的文件、修改代码、跑命令,而不是把代码粘贴给你让你自己改。这就是它的本质差异。

第五期:工具生态与集成

核心收获

  • ccswitch:根据任务复杂度动态切换模型
  • cloudcli:云端运行,团队共享配置
  • MCP 集成:访问外部工具和数据源

关键洞察

生态工具让 Claude Code 更强大,但核心还是你自己的工作流。工具是手段,不是目的。

第六期:深度报告——三个真实项目的完整复盘

核心收获

  • 案例一:重构遗留代码库——从混乱到有序
  • 案例二:从零构建 Web 应用——完整开发流程
  • 案例三:集成第三方服务——解决复杂依赖

关键洞察

真实项目中的挑战不是技术,而是决策。Claude Code 能帮你做决策,但最终拍板的是你。

第七期:工作流编排最佳实践

核心收获

  • Subagent 委派模式:主会话是编排者,不是执行者
  • Dev Docs 工作流:防止上下文压缩后遗忘
  • 质量门系统:用证据说话,不是感觉
  • 多 Agent 并行编排:独立任务并行跑,依赖任务串行跑

关键洞察

高效使用 Claude Code 的关键不是掌握更多命令,而是建立适合自己的工作流。


从工具到工作流的质变

Level 1:工具使用者

特点:
- 知道 Claude Code 的基本命令
- 能完成简单的代码生成任务
- 遇到问题就重新开始

问题:
- 重复性工作多
- 上下文管理混乱
- 质量不稳定

改进方向:
- 建立任务描述模板
- 学会使用 /clear 和 /compact
- 写 CLAUDE.md 文件

Level 2:工作流实践者

特点:
- 有固定的任务处理流程
- 使用 CLAUDE.md 规范项目
- 知道什么时候该用 Subagent
- 有质量门概念

问题:
- 工作流不够灵活
- 缺乏长期积累
- 团队协作困难

改进方向:
- 记录工作流到文档
- 建立项目级 Dev Docs
- 团队共享 CLAUDE.md

Level 3:工程化大师

特点:
- 工作流自动化
- 质量保障系统化
- 团队协作标准化
- 持续优化和迭代

关键能力:
- 能诊断工作流瓶颈
- 能设计新的工作流模式
- 能教导团队成员
- 能将最佳实践沉淀为工具

个人成长路线图

第一阶段:基础掌握(1-2周)

目标:熟悉 Claude Code 的核心功能

任务清单

  • 安装 Claude Code 并完成认证
  • 完成第一个任务:实现一个工具函数
  • 掌握 /clear/compact/cost 命令
  • 写一份基础的 CLAUDE.md
  • 尝试 Subagent 委派

验收标准:能独立完成小任务,知道什么时候用 /clear

第二阶段:工作流建立(2-4周)

目标:建立适合自己的工作流

任务清单

  • 建立 Dev Docs 工作流(plan.md、context.md、tasks.md)
  • 配置质量门(build、test、lint)
  • 设计 Subagent 角色和分工
  • 记录常用提示词模板
  • 跑通一个完整的项目

验收标准:有固定的工作流,质量门通过

第三阶段:工程化实践(1-2个月)

目标:工程化使用 Claude Code

任务清单

  • 建立项目级 CLAUDE.md 体系
  • 实现多 Agent 并行编排
  • 集成外部工具(MCP、数据库)
  • 建立团队协作规范
  • 沉淀最佳实践为工具

验收标准:团队协作顺畅,工作流稳定可靠

第四阶段:持续优化(长期)

目标:持续优化和迭代

任务清单

  • 定期复盘工作流效率
  • 收集团队反馈
  • 尝试新的工作流模式
  • 分享最佳实践
  • 贡献开源生态

验收标准:能诊断工作流瓶颈,能设计新的工作流模式


工作流诊断清单

当前状态检查

上下文管理

  • 每个独立任务完成后都 /clear 了吗?
  • 长会话时定期 /compact 了吗?
  • 有预算上限吗?

项目规范

  • 项目有 CLAUDE.md 吗?
  • CLAUDE.md 内容具体吗?
  • 有多层 CLAUDE.md 架构吗?

质量保障

  • 每次代码修改后都跑 build 吗?
  • 每次代码修改后都跑 test 吗?
  • 有禁止"should work"的规则吗?

工作流

  • 有固定的任务处理流程吗?
  • 知道什么时候用 Subagent 吗?
  • 有 Dev Docs 工作流吗?

团队协作

  • 团队共享 CLAUDE.md 吗?
  • 有统一的 Subagent 定义吗?
  • 有代码审查流程吗?

改进优先级

立即改进(高优先级):

  1. 每个独立任务完成后 /clear
  2. 写 CLAUDE.md 文件
  3. 配置质量门

短期改进(中优先级):

  1. 建立 Dev Docs 工作流
  2. 配置 Subagent 角色
  3. 记录常用提示词模板

长期改进(低优先级):

  1. 建立项目级 CLAUDE.md 体系
  2. 实现多 Agent 并行编排
  3. 集成外部工具

社区与资源

官方资源

社区资源

  • 📖 chudi.dev:Claude Code 最佳实践和工作流
  • 🔧 barkain/claude-code-workflow-orchestration:Hook-based 自动委派框架
  • 📝 digitalapplied.com:AI 编程工具评测和对比
  • 🎓 Towards AI:AI 编程教程和案例

开源项目

  • 🚀 ccswitch:Claude Code 模型切换工具
  • ☁️ cloudcli:云端运行 Claude Code
  • 🔌 MCP 集成:外部工具和数据源集成

学习路径

新手入门

  1. 官方文档 → 基础功能
  2. 系列第一期 → 安装和认证
  3. 系列第二期 → 斜杠命令
  4. 系列第三期 → CLAUDE.md

进阶学习

  1. 系列第四期 → 实战开发技巧
  2. 系列第五期 → 工具生态与集成
  3. 社区最佳实践 → 工作流优化

高级实践

  1. 系列第六期 → 真实案例复盘
  2. 系列第七期 → 工作流编排
  3. 社区开源项目 → 贡献和分享

未来展望

Claude Code 的发展方向

更强的理解能力

  • 理解复杂业务逻辑
  • 跨项目知识迁移
  • 自动推理和决策

更好的自主性

  • 独立完成更复杂的任务
  • 自动优化和重构
  • 自适应工作流

更低的成本

  • 模型优化降低使用成本
  • Token 优化算法
  • 智能上下文管理

更广的生态

  • 更多插件和集成
  • 团队协作工具
  • 企业级功能

AI 编程工具的未来

趋势一:从工具到伙伴
Claude Code 正在从"辅助工具"进化到"真正的合作伙伴"。未来,AI 编程工具会更像一个真实的工程师——能理解你的意图、自主完成任务、提供专业建议。

趋势二:从个人到团队
AI 编程工具正在从个人使用场景扩展到团队协作场景。未来,团队会共享 AI 配置、建立统一规范、实现协作优化。

趋势三:从编码到工程
AI 编程工具正在从"写代码"扩展到"软件工程"。未来,AI 编程工具会覆盖需求分析、架构设计、代码实现、测试、部署、运维的完整流程。

趋势四:从通用到专用
AI 编程工具正在从"通用工具"扩展到"领域专用"。未来,会有针对不同语言、框架、领域的专用 AI 编程工具。

对开发者的影响

短期影响(1-2年):

  • 开发效率提升 5-10 倍
  • 重复性工作大幅减少
  • 代码质量更稳定

中期影响(3-5年):

  • 开发者角色从"写代码"转向"做决策"
  • 软件工程流程自动化
  • AI 编程工具成为基础设施

长期影响(5-10年):

  • 软件开发门槛大幅降低
  • 人人都能构建应用
  • AI 编程工具成为标配

最终建议

给新手的建议

1. 不要急于求成

  • 先熟悉基础功能
  • 建立简单的工作流
  • 逐步提升复杂度

2. 从小任务开始

  • 不要一开始就用全权委托模式
  • 从简单的代码生成开始
  • 逐步尝试复杂任务

3. 建立自己的工作流

  • 记录常用提示词
  • 总结成功经验
  • 持续优化迭代

给进阶者的建议

1. 专注工作流优化

  • 分析瓶颈在哪里
  • 设计新的工作流模式
  • 自动化重复性工作

2. 建立质量保障系统

  • 配置质量门
  • 建立代码审查流程
  • 持续监控和优化

3. 团队协作标准化

  • 共享 CLAUDE.md
  • 统一 Subagent 定义
  • 建立协作规范

给专家的建议

1. 沉淀最佳实践

  • 记录成功案例
  • 总结失败教训
  • 形成方法论

2. 贡献开源社区

  • 分享工作流模板
  • 开源 Subagent 定义
  • 提交 PR 和 Issue

3. 引领行业发展

  • 探索新的工作流模式
  • 推动标准制定
  • 培养下一代开发者

结语:工具的边界

Claude Code 是一把利器,但它不是魔法。

它能帮你:

  • ✅ 生成符合规范的代码
  • ✅ 自动执行重复性工作
  • ✅ 验证和修复错误
  • ✅ 优化和重构代码

但它不能:

  • ❌ 理解业务需求(需要你)
  • ❌ 做架构决策(需要你)
  • ❌ 创新思维(需要你)
  • ❌ 用户体验设计(需要你)

工具的价值不在于它能做什么,而在于你能用它做什么。

真正的工程师不是工具的使用者,而是工具的驾驭者。他们知道什么时候用工具,什么时候不用工具;知道工具的优势和局限;知道如何用工具解决复杂问题。

Claude Code 的终极目标是让你成为更好的工程师——不是取代你,而是增强你;不是让你变得懒惰,而是让你更专注于真正重要的工作。


系列总结

七期文章,我们走过了:

  • 初识 Claude Code
  • 斜杠命令的艺术
  • CLAUDE.md 的力量
  • 实战开发技巧
  • 工具生态与集成
  • 深度报告——三个真实项目的完整复盘
  • 工作流编排最佳实践

现在,轮到你了。

拿起这把利器,去构建你的下一个项目。


作者:鸡哥
发布日期:2026-06-10
标签:#ClaudeCode #AI编程 #工作流 #工程化
分类:工具推荐


系列索引


互动

  • 这八期文章对你有帮助吗?
  • 你的 Claude Code 工作流是什么样的?
  • 你希望看到更多的 AI 编程工具分析吗?

欢迎在评论区分享你的经验和想法!


"工具再强,也需要人来驾驭。真正的工程师不是工具的使用者,而是工具的驾驭者。"

Views: 18

解码 Claude Code(七)— 深度报告:三个真实项目的完整复盘

前六期我们拆解了 Claude Code 的每一个核心模块。这一期,我们走进真实项目——不谈理论,只看结果。

三个案例来自 Anthropic 工程团队和社区开发者的第一手报告。它们规模不同、领域不同,但都回答了同一个问题:当 Claude Code 真正"上阵"的时候,会发生什么?

案例一:16 个 Claude 并行写 C 编译器

项目概况

2026 年 2 月,Anthropic 安全团队研究员 Nicholas Carlini 做了一个疯狂的实验:用 16 个 Claude 实例并行开发一个 C 编译器,目标是可以编译 Linux 内核。

最终结果:

  • 代码量:100,000 行 Rust
  • 会话数:近 2,000 个 Claude Code 会话
  • Token 消耗:20 亿输入 + 1.4 亿输出
  • 成本:约 20,000 美元
  • 能力:能编译 Linux 6.9(x86/ARM/RISC-V)、QEMU、FFmpeg、SQLite、PostgreSQL、Redis
  • 测试通过率:GCC torture test 套件 99%

这不是 demo,不是原型——这是一个能编译 Doom 的编译器。

架构设计:最简并行方案

Carlini 没有设计复杂的编排系统。整个架构只有三个组件:

1. 无限循环(Ralph Loop)

#!/bin/bash
while true; do
  COMMIT=$(git rev-parse --short=6 HEAD)
  LOGFILE="agent_logs/agent_${COMMIT}.log"
  claude --dangerously-skip-permissions \
    -p "$(cat AGENT_PROMPT.md)" \
    --model claude-opus-X-Y &> "$LOGFILE"
done

Claude 完成一个任务,立即开始下一个。它没有选择——循环永远不会停(除非 Claude 不小心执行了 pkill -9 bash 把自己杀了,这确实发生过一次)。

2. Git 文件锁实现任务分配

每个 agent 在 current_tasks/ 目录下创建文件来"锁定"任务。如果两个 agent 抢同一个任务,Git 的同步机制会强制第二个选别的。没有中心调度器,没有消息队列——就是文件系统 + Git。

3. 容器化隔离

每个 agent 运行在独立的 Docker 容器里,各自 clone 代码到本地,完成后 push 到上游仓库。合并冲突频繁发生,但 Claude 有能力自行解决。

关键发现

测试质量决定上限。 Carlini 反复强调:Claude 会不遗余力地解决你给它的任何问题,所以测试套件必须近乎完美,否则 Claude 会解错题。

他发现 Claude 会不断用新功能破坏已有功能,于是搭建了 CI 流水线,强制每次提交不能 break 现有测试。测试不是给自己写的——是给 Claude 写的。

站在 Claude 的角度设计工具。 测试输出不能刷屏(会污染上下文窗口),错误信息必须一行就能 grep 到(ERROR: 具体原因),日志要预计算汇总统计(免得 Claude 自己算一遍浪费时间)。

Claude 还有个致命弱点:无法感知时间。不加限制的话,它会花几个小时跑测试,而不是推进开发。解决方案是 --fast 模式:只跑 1%-10% 的随机抽样,既覆盖全部文件,又能快速定位回归。

并行不是银弹。 当所有 agent 面对同一个大问题时(比如编译 Linux 内核),16 个 agent 会卡在同一个 bug 上,互相覆盖修复。Carlini 的解法很巧妙:用 GCC 作为"对照编译器",随机分配文件给 GCC 和 Claude 的编译器,通过二分法定位哪些文件有问题,从而让不同 agent 修复不同 bug。

碰到的天花板

这个项目也暴露了 Opus 4.6 的极限:

  • 无法实现 16 位 x86 代码生成器(输出的代码超过 Linux 的 32K 限制)
  • 生成的代码效率远低于 GCC(即使开了全部优化,还不如 GCC 关优化)
  • Rust 代码质量合理,但远达不到专家水平
  • 新功能和修复经常破坏已有功能

Carlini 的总结很诚实:这个编译器"已经达到了 Opus 能力的极限"。

教训提炼

维度 教训
测试 测试不是验证工具,是导航工具。没有好测试,agent 会迷路
并行 任务独立时并行是免费的,任务耦合时并行反而有害
成本 2 万美元听起来贵,但比一个团队几个月的人力便宜一个数量级
架构 最简方案(文件锁 + Git)往往优于复杂编排系统
局限 即使是最强的模型,在专家级任务上仍有明显天花板

案例二:GAN 启发的三代理全栈开发

项目概况

2026 年 3 月,Anthropic Labs 团队的 Prithvi Rajasekaran 公开了一项研究:如何让 Claude 自主完成复杂的前端设计和全栈应用开发。

他的灵感来源出人意料——生成对抗网络(GAN)。

在 GAN 里,生成器负责产出,判别器负责挑剔。Rajasekaran 把这个结构搬到了 AI 编程中:一个 agent 写代码,另一个 agent 审代码,两者对抗迭代,直到质量达标。

从前端设计开始

问题很明确:Claude 默认倾向于产出"安全但无聊"的布局——技术上能用,但视觉上毫无记忆点。

Rajasekaran 设计了四个评分维度:

维度 权重 核心问题
设计品质 看起来是一个整体,还是零件拼凑?
原创性 有刻意的设计决策,还是模板默认值?
工艺 排版层级、间距一致性、色彩和谐度
功能性 用户能不能不猜就完成任务?

前两个权重更高,因为工艺和功能性 Claude 本来就做得不错,真正缺的是审美上的冒险。

然后他构建了对抗循环:

生成器:根据提示创建 HTML/CSS/JS
    ↓
评估器:用 Playwright 打开页面,截图、导航、逐维度打分、写详细批评
    ↓
生成器:根据批评修改,或彻底转向新的美学方向
    ↓
重复 5-15 轮

关键细节:评估器不是看静态截图打分,而是真的打开浏览器导航页面、截图、仔细研究后再评分。每轮迭代都有真实的墙钟时间,完整运行最长可达四小时。

最精彩的一刻

Rajasekaran 让 Claude 为一个荷兰艺术博物馆设计网站。前九轮迭代产出了一系列干净但中规中矩的暗色主题页面。

然后第十轮,Claude 推翻了之前所有的方向,重新想象了这个网站——它变成了一个空间体验:用 CSS perspective 渲染的 3D 房间,棋盘格地板,画作以自由位置挂在墙上,通过门道在画廊房间之间导航。

这是单次生成不可能出现的创意飞跃。

扩展到全栈开发

验证了生成器-评估器模式后,Rajasekaran 将其扩展为三代理系统:

规划器(Planner):接收 1-4 句话的用户描述,扩展为完整产品规格。关键约束——只描述"做什么"和"为什么",不规定"怎么做"。因为如果规划器在技术细节上猜错了,错误会级联传播到下游。

生成器(Generator):按功能一个接一个地实现(sprint 模式)。每个 sprint 结束后自我评估,然后交给评估器。技术栈固定:React + Vite + FastAPI + SQLite(后换为 PostgreSQL)。

评估器(Evaluator):不只是看代码——它打开应用,实际操作每个功能,记录 bug,写报告反馈给生成器。这一次,评估器真的在"使用"软件,而不是在"读"代码。

解决的三个核心问题

问题一:上下文腐烂。 长时间运行后,agent 开始遗忘早期指令,做出矛盾决策。早期用 Sonnet 4.5 时特别严重("上下文焦虑"——模型会提前结束工作)。Opus 4.5 基本消除了这个问题,配合自动 compaction 就够了。

问题二:自我评价偏差。 Agent 对自己产出的评价几乎总是正面的——即使明显平庸。把评价者和生产者分开后,评价可以校准为"挑剔"风格,而生成器有了具体的改进目标。

问题三:长任务失控。 将完整应用拆解为逐功能 sprint,每个 sprint 有明确的起止和验证条件。这比"一口气写完整个应用"靠谱得多。

教训提炼

维度 教训
评估 分离生成和评估是质量的关键杠杆
迭代 5-15 轮对抗迭代远优于单次生成
规划 规划器应约束"做什么"而非"怎么做"
创意 允许 agent 推翻方向,可能产生意外突破
成本 每次完整运行可达 4 小时,但产出质量显著高于一次性生成

案例三:Managed Agents — 从宠物到牲畜

项目概况

前两个案例都是研究实验。第三个案例是真正的生产系统——Anthropic 的 Managed Agents 托管服务。

这个故事的核心不是 Claude 多聪明,而是如何设计一个能持续运行的 AI agent 基础设施。

"宠物"问题

最初的架构很直觉:把所有东西塞进一个容器——Claude、运行 harness、执行沙箱、会话记录。

问题很快暴露:

  • 容器挂了 = 会话丢了(而且没地方调试)
  • harness 假设所有资源都在旁边(客户要求连接自己的 VPC 时就傻了)
  • 安全隐患:Claude 生成的不可信代码和密钥在同一个容器里(一次提示注入就能拿到 token)

这就是经典的"宠物"问题——你精心照料它,它挂了你很难受。

解耦方案:"大脑"和"手"

Anthropic 的解法来自操作系统设计哲学:像 Unix 把硬件抽象为文件一样,把 agent 组件抽象为接口。

大脑(Brain)= Claude + harness,负责思考和决策
手(Hands)= 沙箱和工具,负责执行
会话(Session)= 事件日志,独立存储

三者通过极简接口连接:

大脑 → 手:execute(name, input) → string
大脑 → 会话:emitEvent(id, event)
会话 → 大脑:getSession(id) / getEvents()

这意味着:

  • 容器挂了?大脑捕获错误,Claude 决定是否重试,新容器按标准配方重建
  • harness 挂了?新 harness 启动,从会话日志恢复,继续上次的事件
  • 客户要连接自己的 VPC?大脑不需要知道手在哪里,只需要调 execute

性能飞跃

解耦带来了意外收获:

  • 首 token 延迟(TTFT)中位数降低 60%,p95 降低超过 90%
  • 原因:之前每个会话都要等容器启动完成才能开始推理;现在推理可以先开始,容器按需创建

安全架构

密钥永远不出现在沙箱里:

  • Git 操作:sandbox 初始化时用 token clone 仓库,配置本地 git remote,之后 push/pull 不需要 token
  • MCP 工具:OAuth token 存在安全保险库,通过专用代理调用,harness 和沙箱都碰不到凭据
  • 原则:Claude 能"用"权限,但永远"看不到"凭据

教训提炼

维度 教训
架构 解耦大脑和手,让每个组件可以独立失败和替换
接口 设计少量稳定的抽象接口,比优化任何单一实现更重要
安全 凭据永远不应存在于不可信代码可达的地方
性能 延迟来自不必要的等待,而非计算本身
演进 为"尚未想到的程序"设计系统,接口比实现更持久

三个案例的共同脉络

把三个项目放在一起看,你会发现它们在说同一件事:

规律一:反馈闭环是第一生产力

C 编译器项目靠 CI 测试套件闭环,前端设计靠评估器打分闭环,Managed Agents 靠会话日志 + 错误恢复闭环。

没有闭环的 agent 就像没有方向盘的车——动力再强也没用。闭环越精确、越自动化,agent 的表现就越好。

规律二:管理上下文 = 管理 AI 的"智商"

C 编译器项目用 Git 文件锁隔离任务上下文,前端项目用三代理分工隔离角色上下文,Managed Agents 用会话日志解耦存储上下文。

三个项目的核心挑战都是同一个:随着任务变长,上下文窗口会被垃圾填满,模型的注意力被分散,性能下降。解决方案不是更大的上下文窗口——而是更聪明的上下文隔离。

规律三:最简架构往往赢

C 编译器没有复杂编排,只有文件锁 + Git。前端项目没有微服务,只有三个 agent + 一个循环。Managed Agents 的核心就是三个接口。

这不是巧合。在 AI agent 领域,模型的智力在飞速增长,但 harness 编码的假设会迅速过时。越简单的架构,越容易适配新一代模型。

规律四:评估比生成更难

三个项目都花了大量精力在"怎么评判结果好不好"上——而不是"怎么让 Claude 写出结果"。

C 编译器的测试套件、前端项目的四维评分体系、Managed Agents 的会话恢复机制——这些才是真正的工程挑战。生成代码 Claude 已经很擅长了,但告诉它"你做得好不好"仍然需要人类精心设计。

用户的真实感受

社区开发者 @svpino 在用 Claude Code 构建了一个完整的 SaaS 应用后写道:

"我用 Claude Code 写了一个从前端到数据库的完整应用。期间我只做了一件事:坐在旁边看它工作,偶尔在它走偏的时候拉一下。这种感觉就像你在驾驶一辆自动驾驶汽车——你知道它大部分时间在正确行驶,但你随时准备接管方向盘。"

另一位开发者 @swyx 的总结更精炼:

"Claude Code 改变的不是你写代码的速度,而是你思考代码的方式。你不再想'怎么实现这个功能',而是想'怎么描述这个功能才能让 AI 做对'。这是一个元认知层面的转变。"

展望:从工具到伙伴

三个案例揭示了一个趋势:Claude Code 正在从"工具"进化为"伙伴"。

C 编译器项目展示了它的极限能力——在结构良好的环境里,它已经可以完成专家级的工程任务。前端项目展示了它的创意潜力——在对抗迭代的驱动下,它能做出超越预期的设计决策。Managed Agents 展示了它的工程成熟度——在生产环境里,它已经可以作为可靠的基础设施运行。

但所有案例也指向同一个瓶颈:AI 仍然需要一个精心设计的环境才能发挥最大潜力。测试、评估、反馈、上下文管理——这些"脚手架"决定了 AI 的天花板。

下一期,也是本系列的最后一期,我们将跳出具体案例,看看 AI 编程的未来。Karpathy 预言的 Software 3.0 时代,Boris Cherny 心中的终极开发体验,以及 Anthropic 对 AI 编程的长期愿景。


系列导航

参考来源

Views: 19

解码 Claude Code(六)— 实战技巧:从 Boris 和团队偷师的 30 条黄金法则

不是官方文档,不是营销话术。这是一个每天用 AI 写 100% 代码的人,用半年时间摸索出来的真实经验。

写在前面

前五期我们聊了 Claude Code 的起源、架构、记忆系统、技能和多代理协作。这一期换个节奏——不讲理论,只讲实操。

这篇文章的素材来自 Boris Cherny(Claude Code 创造者)在 2026 年 1-4 月发布的四组技巧分享,以及 Anthropic 团队成员 Thariq 关于会话管理的深度指南。我把它们重新组织成 6 个主题,30 条具体可执行的建议。

每一条都有出处,每一条都经过 Anthropic 内部团队的日常验证。

Coding Tips

一、并行是一切的起点

Boris 反复强调:并行是最大的生产力提升,没有之一。

1. 同时跑 5 个 Claude

Boris 的日常:5 个终端窗口,每个运行一个独立的 Claude Code 实例。一个重构代码,一个写测试,一个搜索依赖,一个审查 PR,一个处理 bug 报告。

具体操作:用 git worktree 创建 5 个独立的工作树,每个窗口一个。这样 5 个 Claude 互不干扰,各自操作各自的代码副本。

# 创建 worktree
git worktree add ../feature-a feature-a
git worktree add ../feature-b feature-b

# 在每个 worktree 里启动 Claude
cd ../feature-a && claude
cd ../feature-b && claude

或者用更简单的方式:claude -w 一键在 worktree 中启动。

2. 本地 + 云端双线作战

5 个本地 Claude 还不够?再开 5-10 个云端实例。claude.ai/code 支持在浏览器里运行 Claude Code,用 /teleport 可以在本地终端和云端之间无缝切换。

Boris 的组合拳:5 个本地 + 10 个云端 = 同时 15 个 Claude 在干活。

3. 把”每天做两次的事”变成斜杠命令

如果某个操作你一天要做两次以上,把它变成一条斜杠命令。

---
name: commit-push-pr
description: "提交代码、推送、创建 PR"
---

执行以下步骤:
1. 运行测试
2. git add 所有变更
3. 根据变更内容生成 commit message
4. git push
5. 创建 Pull Request

Boris 的 /commit-push-pr 命令可能是他用得最多的一条——每天执行几十次。

4. 用 /loop 把重复工作自动化

/loop 是 Boris 最喜欢的"隐藏功能"之一。它可以让 Claude 按固定间隔自动执行任务,最长持续一周。

他的日常配置:

/loop 5m /babysit          → 每5分钟自动处理PR review
/loop 30m /slack-feedback  → 每30分钟把Slack反馈变成PR
/loop 1h /pr-pruner        → 每小时清理过期PR

把技能和 loop 组合起来,就变成了一个 7x24 小时工作的 AI 助手。

二、验证闭环:最重要的一条

Boris 说过一句话,被整个社区反复引用:

给 Claude 验证自己工作的方式,效果提升 2-3 倍。这是获得高质量输出的最重要单一因素。

5. Claude 测试每一次变更

Boris 每次让 Claude 写完代码后,都会让它自己测试。不是"帮我看看有没有问题"——而是"运行测试,确保通过"。

这是他从 Meta 带来的习惯:代码质量不是审查出来的,是验证出来的。

6. 前端必须给 Claude 浏览器

让 Claude 写前端代码但不给它浏览器,就像让设计师蒙着眼睛画画。

Chrome 扩展是 Boris 做前端时的标配。Claude 写完代码后自动打开浏览器截图,对比设计稿,发现差异后自动修复。这个循环一直持续到页面看起来"对了"为止。

7. 用”挑战式提示”逼迫 Claude 自审

不要只说"帮我写这个功能"。试试这样说:

"审查这段代码,不要创建 PR,直到我通过你的测试。"

或者:

"向我证明这个方案有效。对比 main 分支和当前分支的行为差异。"

Boris 把这叫做"让 Claude 当你的审查者"——反向利用 AI 的能力来提升输出质量。

8. 失败后不要纠正,要重写

当一个修复方案"勉强能用"时,Boris 会说:

"基于你现在知道的一切,扔掉这个方案,实现那个优雅的解法。"

这个技巧的底层逻辑是:Claude 在尝试过程中学到了很多关于代码库的上下文,但它当前的实现可能只是在最初的错误假设上打补丁。让它带着新知识重新来过,往往能得到更好的结果。

9. 让 Claude 修复大多数 bug

不需要手把手教。直接说"修复失败的 CI 测试",或者把 Slack 里的 bug 线程贴给 Claude,只说一个字:"修。"

Claude 可以读日志、分析堆栈、定位代码、提出修复方案、运行测试验证。整个过程你只需要审查最终结果。

三、会话管理:对抗”上下文腐烂”

这一节的素材来自 Thariq(Anthropic 团队成员),他给出了目前最系统的会话管理指南。

10. 理解 Context Rot

即使有 1M token 的上下文窗口,模型性能也不是线性的。大约在 300-400k token 时,模型开始被无关信息干扰——注意力被分散到越来越多的 token 上,旧的不相关内容开始影响当前的判断。

这就是 Context Rot(上下文腐烂)。

11. 每个回合结束都是一个决策点

Claude 完成一个回合后,你有 5 个选择:

选项 上下文保留 适用场景
Continue 保留全部 同一任务,上下文仍然相关
Rewind 保留前半,丢弃后半 Claude 走错方向了
/compact 有损摘要 中期任务,需要清理冗余
/clear 只保留你写的 brief 全新任务
Subagent 主上下文 + 最终结果 会产生大量中间输出的任务

12. Rewind > 纠正

这是 Thariq 最推荐的习惯。

当 Claude 尝试方案 A 失败了,你的直觉可能是说"不对,试方案 B"。但这会把失败的方案 A 和你的纠正都留在上下文里。

更好的做法是 Rewind(双击 Esc):回退到失败尝试之前,用你学到的信息重新提示。

纠正后:上下文 = 5个文件读取 + 2次失败尝试 + 2次纠正 + 最终修复
回退后:上下文 = 5个文件读取 + 1个有经验的提示 + 最终修复

上下文更干净,模型的注意力更集中。

13. Compact 是中期任务的救星

当会话变长但你不想从头来过,/compact 是最好的选择。它会要求 Claude 摘要当前对话,然后用摘要替换历史。

关键技巧:用提示词引导 compact 的方向

/compact 保留认证重构的细节,丢弃测试调试的过程

不引导的 compact 可能会丢失重要信息——因为模型在做 compact 时处于"最不聪明"的状态(上下文已经很满了)。

14. 主动 compact,不要等到自动触发

等到自动 compact 触发时,模型已经处于 Context Rot 状态,摘要质量会下降。

正确做法:在你觉得上下文开始膨胀但模型还没变笨的时候,主动执行 /compact,带上方向提示。

四、CLAUDE.md:投资回报率最高的 5 分钟

15. 每次纠错后更新 CLAUDE.md

Boris 的原话:

每次你纠正 Claude 后,以这句话结尾:"更新你的 CLAUDE.md,确保你不再犯这个错误。"

Claude 非常擅长为自己写规则。它会精确地提取错误的模式,写成可执行的指令。

16. 团队共享,通过 PR 协作更新

CLAUDE.md 不应该是某个人的私有文件。Boris 的团队把它检入 git,通过 PR 协作更新。

一个更有趣的做法:在同事的 PR 上 @claude,让 Claude 在 review 过程中自动更新 CLAUDE.md。Boris 把这叫做"复利工程"——每次代码审查都在为未来的 AI 辅助投资。

17. 持续迭代直到错误率可测量地下降

CLAUDE.md 不是写一次就完事的。Boris 建议:

  1. 用一周时间记录 Claude 犯的所有错误
  2. 为每类错误添加一条规则
  3. 再用一周观察错误率是否下降
  4. 重复直到效果显著

这个过程可能需要几轮迭代,但每一轮都在让 Claude 变得更好。

18. 用 notes 目录积累项目知识

一个 Anthropic 工程师的做法:让 Claude 为每个任务/项目维护一个 notes 目录,每次 PR 后更新。然后在 CLAUDE.md 里指向这个目录。

这样 CLAUDE.md 本身保持简洁(只放规则和约定),而详细的项目知识存在 notes 里,按需加载。

五、工具和环境优化

19. 用 Opus + Thinking 处理一切

这听起来违反直觉——Opus 比 Sonnet 慢,为什么还要用?

Boris 的解释:虽然单次响应更慢,但因为 Opus 犯错更少、工具使用更准确,你需要纠错的次数大幅减少。总耗时反而更短。

这就像开车走高速 vs 走小路:高速看起来绕远了,但因为不用等红灯,总时间更短。

20. 用 PostToolUse Hook 自动格式化代码

Claude 生成的代码通常格式良好,但最后 10% 可能和项目的 lint 规则不一致。一个简单的 Hook 就能解决:

"PostToolUse": [{
  "matcher": "Write|Edit",
  "hooks": [{
    "type": "command",
    "command": "bun run format || true"
  }]
}]

每次 Claude 写入或编辑文件后自动格式化,CI 再也不会因为格式问题失败。

21. 预授权权限,不要跳过权限检查

--dangerously-skip-permissions 看起来很方便,但 Boris 坚决反对。正确做法是用 /permissions 预先授权已知的安全操作:

{
  "permissions": {
    "allow": [
      "Bash(npm test*)",
      "Bash(npm run lint*)",
      "Bash(git status*)",
      "Bash(git diff*)"
    ]
  }
}

把这些规则检入 settings.json,整个团队共享。

22. 给 Claude 接入你所有的工具

通过 MCP,Claude 可以访问 Slack、BigQuery、Sentry、GitHub 等所有团队工具。Boris 已经 6 个月没写过一行 SQL 了——所有数据查询都通过 Claude + BigQuery 完成。

配置方法:在 .mcp.json 中定义 MCP 服务器,检入 git 共享。

23. 语音输入:说得比打得快 3 倍

Boris 大部分代码是"说"出来的,不是"打"出来的。

语音输入的好处不只是速度——它让你的 prompt 自然变得更详细。打字时你会下意识压缩信息,说话时你会自然补充更多上下文。而 prompt 越详细,Claude 的输出越好。

终端里运行 /voice,然后按住空格键说话。macOS 上也可以双击 fn 键触发系统听写。

24. --bare 让 SDK 启动快 10 倍

用 Claude Code 做 CI/CD 或自动化时,默认会搜索所有 CLAUDE.md、settings 和 MCP 配置。加上 --bare 跳过这些搜索,启动速度提升 10 倍:

claude -p "总结这个代码库" \
  --output-format=stream-json \
  --bare

Boris 透露,未来的版本会把 --bare 变成默认行为——因为它在非交互场景下几乎总是更好的选择。

六、高级工作流

25. /batch:大规模变更的核武器

需要把一个重构应用到几十甚至几百个文件?/batch 会先和你确认方案,然后自动分发到数十/数百个 worktree agent 并行执行。

每个 agent 在独立的代码副本上工作,完成后自动合并。这是 Claude Code 处理大规模代码迁移的终极工具。

26. 用 Hooks 挂载到 Agent 生命周期

Hooks 让你在 Claude 的关键节点执行自定义逻辑:

  • SessionStart:每次启动时动态加载上下文
  • PreToolUse:记录模型执行的所有 bash 命令
  • Stop:Claude 停止时"戳"它一下让它继续

第三个特别有用——长时间运行的任务中,Claude 有时会过早停止。用 Stop Hook 自动推送它继续,直到任务真正完成。

27. 子代理不只是”分工”,更是”上下文隔离”

子代理最大的价值不是并行执行——而是上下文隔离。

当你知道接下来的一块工作会产生大量中间输出(20 次文件读取、12 次 grep、3 条死路),而这些输出你之后不再需要——把它交给子代理。只有最终结论会返回主上下文。

判断标准很简单:我之后还需要这些工具输出吗?不需要就丢给子代理。

28. 会话分支:探索不同方向的安全网

/branch 从当前会话分叉出一个新方向。原来的会话完好无损,你可以随时切回来。

适用场景:一个方案不确定能不能走通?先 branch 一下,在分支里试。失败了切回来,零损失。

29. 跨仓库工作:--add-dir

当你需要同时操作多个代码仓库时,用 --add-dir 把其他目录加入 Claude 的工作范围:

claude --add-dir ../shared-libs --add-dir ../api-gateway

这不仅让 Claude "看到"这些仓库,还自动授予了操作权限。

30. 用 Explanatory 模式学新东西

Claude Code 不只是写代码的工具,也是学习工具。在 /config 里切换到 "Explanatory" 或 "Learning" 输出风格,Claude 会在每次变更时解释"为什么这么做"。

还可以让它:
- 生成 HTML 幻灯片解释不熟悉的代码
- 画 ASCII 图描述新协议和代码架构
- 构建间隔重复学习技能——你解释理解,Claude 提问补漏洞


总结:30 条法则的底层逻辑

把 30 条技巧摊开看,你会发现它们都围绕三个核心原则:

原则一:给 AI 反馈闭环。 验证工作(5-9)是最重要的一组技巧。没有反馈的 AI 就像没有方向盘的车——动力再强也没用。

原则二:管理上下文就是管理 AI 的"智商"。 会话管理(10-14)、CLAUDE.md(15-18)、子代理(27)都在做同一件事——确保模型的注意力集中在正确的事情上。

原则三:自动化一切重复操作。 斜杠命令(3)、/loop(4)、Hooks(26)、权限预授权(21)——把人类从重复劳动中解放出来,让 AI 处理 AI 最擅长的事。

这三条原则不只适用于 Claude Code。它们是 2026 年"AI 辅助开发"这个领域的通用方法论。不管你用什么工具,只要你记住这三条,就能显著提升 AI 编程的效率和质量。


系列导航

下期预告:真正的项目是怎么用 Claude Code 完成的?从天气应用到大规模重构,从个人 side project 到 Anthropic 内部的生产系统。第七期,我们走进真实案例。

Views: 6

Views: 25

解码 Claude Code(五)— 多代理协作:从单兵作战到 AI 军团

一个人走得快,一群人走得远。这句老话在 AI 编程的世界里有了新的含义——只不过"一群人"变成了"一群 AI"。

Boris Cherny 的日常工作方式是这样的:同时打开 5 个终端窗口,每个窗口运行一个独立的 Claude Code 实例。一个负责重构代码,一个负责写测试,一个负责搜索依赖,一个在审查 PR,还有一个在处理 bug 报告。它们并行工作,互不干扰,像一支训练有素的开发团队。

这不是科幻。这是 2026 年 Anthropic 内部的日常。

Team Collaboration

为什么需要多个 AI

要理解多代理协作的价值,先要理解单代理的局限。

大语言模型有一个被低估的特征:上下文是它的全部记忆,也是它的全部认知边界。你在一次对话中塞进去的东西,就是它"知道"的全部。它不知道你上一次会话做了什么,不知道隔壁终端在跑什么,不知道代码库的全貌——除非你显式地告诉它。

这意味着,当任务变得复杂时,单个 AI 会遇到三个硬墙:

1. 上下文污染
你让 Claude Code 做一个复杂功能。它在尝试方案 A,失败了。换方案 B,又失败了。换方案 C,成功了。但这时候上下文窗口里已经塞满了 A 和 B 的失败记录、错误日志、来回讨论。Claude Code 开始被这些噪声干扰——它会反复引用已经放弃的方案,或者陷入自我怀疑的循环。

TypeScript 社区知名开发者 Matt Pocock 给出了一个精准的类比:LLM 像电影《记忆碎片》的主角——每次上下文被压缩或清除,它就回到初始状态,忘记之前的探索和失败。唯一的记忆是你写在 CLAUDE.md 里的笔记。

2. Smart Zone 和 Dumb Zone
Matt 还提出了一个关键概念。LLM 的性能不是均匀的。会话开始时,上下文窗口干净、信号密度高,模型处于 Smart Zone——推理准确,输出质量高。但随着上下文增长到约 100K tokens,噪声开始淹没信号,模型进入 Dumb Zone——开始重复自己、忽略指令、犯低级错误。

这个分界线不是精确的 100K,而是取决于任务类型和上下文质量。但趋势是明确的:上下文越长,质量越差。

3. 注意力稀缺
即使上下文没有溢出,单个 AI 也很难同时处理多个不同维度的思考。它在写代码的时候,很难同时做架构评审。在做架构评审的时候,很难同时思考用户体验。人类团队之所以需要分工,不是因为我们笨,而是因为深度思考需要排他性的注意力——AI 也一样。

三个层次:从子代理到军团

Claude Code 的多代理系统不是一个功能,而是三个逐渐升级的协作层次。

层次一:子代理(Subagent)

子代理是最基础的多代理形式。主会话保持清洁,把特定任务委托给一个临时创建的独立 AI 实例。

想象你在写一个复杂功能。你需要先了解现有代码的结构。你可以自己逐个文件翻看(浪费主会话上下文),也可以派出一个子代理:"去搜索代码库中所有与支付相关的模块,整理出调用关系和数据流"。

子代理在独立的上下文窗口中运行。它可能读了几十个文件,产生了大量中间输出——但这些不会污染你的主会话。它最终只返回一个精炼的结果:一张清晰的调用关系图和一段摘要。

Anthropic 的工程师 Thariq 说得直白:子代理首先是上下文管理工具,其次才是任务执行工具。它最大的价值不是"帮你干活",而是"把干活的噪声隔离在另一个窗口里"。

每个子代理都可以精确配置:

参数 作用 示例
model 使用哪个模型 Explore 用 haiku(便宜快速),审查用 opus(深度思考)
tools 允许使用哪些工具 代码搜索代理只需 Read,不需要 Edit
maxTurns 最多执行多少步 防止代理陷入死循环
color 终端里的颜色标识 绿色 = 数据获取,红色 = 代码修改
memory 记忆作用域 project 级让代理跨会话积累经验

这种精细控制揭示了一个设计哲学:不是所有代理都需要同样的能力。探索代码的代理只需要读权限,用最便宜的模型就行。写代码的代理需要完整权限,用最强的模型。就像人类团队里,实习生做调研,资深工程师做架构——能力和权限匹配角色。

层次二:Agent Teams

Agent Teams 是 Claude Code 最令人兴奋的实验性功能。和子代理不同,每个 teammate 是一个完全独立的 Claude Code 会话——拥有自己的完整上下文窗口、自己的 CLAUDE.md、自己的 MCP 服务器、自己的技能。

如果子代理是"你派出去的临时工",Agent Teams 就是"你组建的正式团队"。

Boris 在分享中演示了一个实际案例:用三个 teammate 协作构建一个"时间编排器"命令。

Command Architect(命令设计师):负责设计用户交互流程和命令结构。它思考的问题是"用户怎么触发这个功能?需要什么参数?输出是什么格式?"

Agent Engineer(代理工程师):负责实现具体的数据获取代理。它关注"怎么获取时区数据?怎么处理错误?模型用什么?"

Skill Designer(技能设计师):负责创建可视化技能。它的任务是"怎么把时区数据渲染成漂亮的 SVG?"

三个 teammate 通过共享任务列表协调工作。它们约定了数据契约——比如 Agent Engineer 输出的数据格式必须是 {time, tz, formatted},Skill Designer 据此设计渲染逻辑。

这种协作需要 iTerm2 + tmux 环境来实现分屏显示。三个 Claude Code 实例在三个终端面板中同时运行,你可以实时看到每个 teammate 在做什么。需要 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 环境变量来启用。

Agent Teams 和子代理的关键区别是独立性和完整性。子代理是主会话的延伸——它从主会话获取任务,返回结果后就消失。而 Agent Teams 的每个成员都是一个完整的 Claude Code 实例,有自己的上下文和记忆,可以独立做出复杂决策。

层次三:/batch 大规模并行

这是 Boris 最喜欢炫耀的功能。/batch 可以把一个操作并行分发到数百个独立的 git worktree 中,每个 worktree 由一个独立的代理处理。

实际例子:Boris 需要在 200 个仓库中统一升级某个依赖版本。过去这需要一个人花一周时间,逐个仓库修改、测试、提交 PR。用 /batch,他只需要描述一次操作——"在每个仓库中把 package X 从版本 2.x 升级到 3.x,运行测试,如果通过就提交 PR"——然后 200 个代理同时开工。

每个代理在独立的 git worktree 中工作,不会互相冲突。每个代理独立测试、独立提交、独立创建 PR。整个过程可能只需要几十分钟。

Boris 自己的数据更有说服力:某天他提交了 266 个贡献(141 个 PR),全部使用 squash merge。PR 的中位数只有 118 行。也就是说,绝大多数修改都非常小而专注——这正是大规模并行最擅长的场景。

一个更深的设计原则

多代理协作背后有一个常被忽略但极其重要的设计原则:独立上下文窗口是发现 bug 的好方法

Boris 在一次分享中透露了一个内部发现:同一个模型,在不同的上下文窗口中,能发现自己引入的 bug

如果你让一个代理写代码然后自己审查,它往往会陷入"创作者盲点"——因为它知道自己的意图,所以会不自觉地假设代码是正确的。

但如果你让代理 A 写代码,然后把代码交给代理 B(在独立上下文中)审查,代理 B 没有"意图包袱",更容易发现逻辑漏洞。

这就像人类工程团队的交叉审查——你更容易发现别人代码里的问题,而不是自己的。AI 也是如此。

这个原则催生了 Claude Code 的代码审查功能:自动派出一组独立代理对每个 PR 进行深度审查。Anthropic 内部数据显示,引入多代理审查后,代码审查不再成为瓶颈,同时每位工程师的代码产出同比增长了 200%。

另一种跨模型验证更进一步:用 Claude 做初始实现,用 GPT(通过 Codex CLI)做独立审查。Plan(Claude Opus)→ QA Review(Codex GPT)→ Implement(Claude Opus)→ Verify(Codex GPT)。不同模型的盲点不同,交叉验证比单模型自审更可靠。

RPI:让多代理不是乱来

多代理协作最怕的不是技术问题,而是协调问题。五个代理各干各的,结果比一个代理更差——这种事经常发生。

Claude Code 社区发展出了一套系统化的多代理工作流,叫 RPI:Research → Plan → Implement

Research 阶段是可行性分析。六个专业代理串行工作:

  1. 需求解析器:把模糊的需求变成结构化的功能描述
  2. 产品经理:写出 PRD,定义用户故事和验收标准
  3. 代码探索器:在现有代码库中搜索相似功能的实现(用 haiku 模型,只读权限)
  4. 高级工程师:评估技术可行性,选择实现方案
  5. CTO 顾问:从战略层面审查决策,防止过度工程
  6. 文档分析师:把所有分析整合成一份清晰的 Research 报告

完成之后,系统给出一个 GO / NO-GO 决策。如果不可行,到此为止,不浪费更多资源。如果可行,进入 Plan 阶段。

Plan 阶段产出四份文档:产品需求(pm.md)、用户体验设计(ux.md)、技术规格(eng.md)和实施路线图(PLAN.md)。每份文档由不同的专业代理负责。

Implement 阶段按路线图分步执行,每一步都有严格的六步验证门:

代码发现 → 实现 → 自验证 → 独立代码审查 → 用户确认 → 文档更新

其中"独立代码审查"和"用户确认"是两个强制停止点。代码审查由独立的 review 代理执行(不是实现者自己审查)。用户确认要求人类明确批准才能继续下一步。

这个流程的核心思想是:多代理协作的价值不在于"更多 AI",而在于"更多独立视角"。六个代理串行分析需求,不是因为一个代理做不了,而是因为六个不同角色的代理能从产品、技术、战略、UX 四个维度交叉验证,发现单一视角的盲点。

RPI 的创建者 Dexter Horthy 在 MLOps Community 分享时坦承了他们犯过的错误:研究阶段不应该告诉模型"要构建什么"——那会导致 opinions 而非 facts。正确的研究应该"压缩真相"——只包含客观信息,让下游代理自己得出结论。他还强调了一个核心原则:"不要外包思考"——工程师在 AI 辅助编码中仍然是关键环节,不能让 AI 替代所有决策。

为什么这个设计有效

回过头来看,Claude Code 的多代理系统为什么有效?因为它遵循了三个基本原则。

原则一:能力匹配角色

不是所有代理都需要最强的模型。Explore 代理用 haiku(便宜、快速),code-review 代理用 opus(深度、准确),Command 入口用 sonnet(均衡)。模型选择像金字塔——底层大量调用用便宜模型,顶层关键决策用贵模型。

原则二:上下文隔离

每个代理在独立的上下文窗口中工作。一个代理的中间输出、失败尝试、调试日志不会污染其他代理。主会话保持干净,只接收精炼后的结果。

原则三:独立验证

实现者和审查者是不同的代理。写代码和审代码的 AI 实例在不同的上下文中运行,没有"创作者盲点"。这是多代理系统最重要的安全机制——它让 AI 具备了"自我纠错"的能力,只不过纠错的"自己"是另一个独立的实例。

Anthropic 内部有个说法:2026 年的编程不是"一个人写代码",而是"编排一支 AI 军团"。Boris 本人每天 10-30 个 PR,100% 由 AI 生成,141 个 PR 的中位数只有 118 行。这不是一个人在写代码——这是一个指挥官在调度一支精锐部队。

而他的武器只有一个:终端里并排打开的五个 Claude Code 窗口。

下期预告

下一篇,我们将从理论走向实战。Boris 分享的 50 条黄金法则——从并行工作到计划模式,从 CLAUDE.md 迭代到验证闭环——每一条都来自 Anthropic 内部数百工程师的真实经验。这不是教科书上的建议,这是战场上总结的生存法则。

下期见。

Views: 28

解码 Claude Code(四)— 技能系统:用 Markdown 打造可复用的 AI 能力

如果 AI 编程助手只能做一件事,它永远比不上能做一百件事的助手。但如果这一百件事每次都要你手把手教,那也不比自己做快多少。真正的效率飞跃,来自把"教过一次的经验"变成"随时可调用的能力"。

这就是 Claude Code 技能系统要解决的问题。

Code Skills

从一个真实场景说起

Anthropic 内部有数百个活跃技能,每天都在被工程师使用。这些技能不是什么高深的 AI 黑科技——它们就是 Markdown 文件。

一个典型的技能长这样:

---
name: code-review
description: "当用户要求审查代码变更时使用此技能"
when_to_use: "用户说'审查这段代码'、'review这个PR'、或提到代码质量时"
model: sonnet
effort: high
---

你是一名高级代码审查者。请检查以下内容:

1. 逻辑错误和潜在 bug
2. 安全漏洞
3. 性能问题
4. 代码风格一致性

对于每个发现,给出严重程度(🔴 严重 / 🟡 警告 / 🟢 建议)和修复建议。

就这么简单。一个 YAML 头部描述元数据,一段 Markdown 正文描述指令。没有 JSON schema,没有 Python 插件系统,没有 npm 依赖——纯文本。

Anthropic 的工程师 Thariq 在分享中提到一个有趣的数据:内部最受欢迎的技能不是那些复杂的工作流编排,而是最简单的几行规则——比如"每次保存文件后自动格式化",或者"提交代码前检查有没有遗留的 console.log"。

技能的九种类型

Thariq 把 Anthropic 内部的数百个技能归纳为九大类型,覆盖了软件开发的几乎所有环节:

1. 库/API 参考
把常用库的 API 文档整理成技能,让 Claude 不用每次都去查文档。比如"React Server Actions 最佳实践",里面包含了完整的用法示例和常见坑。

2. 产品验证
定义什么是"好的用户体验",让 Claude 在写代码时有判断标准。比如"移动端适配检查清单",列出了触摸目标大小、字体层级、断点处理等标准。

3. 数据获取与分析
教 Claude 如何连接内部数据库、如何写特定格式的查询、如何解读结果。

4. 业务流程自动化
把重复的业务操作封装成技能——生成周报、同步状态、发送通知。

5. 代码脚手架
项目初始化模板、新组件创建规范、文件命名约定。

6. 代码质量审查
这是使用最频繁的类型。代码审查、安全扫描、性能检查。

7. CI/CD 部署
定义构建、测试、部署的完整流程。

8. Runbooks
故障排查手册——出问题时 Claude 照着步骤走就行。

9. 基础设施运维
Kubernetes 配置、服务器管理、日志分析。

这九种类型揭示了一个关键洞察:技能的本质不是"教 AI 新能力",而是"把团队的最佳实践固化成可复用的知识单元"

两种技能模式

技能系统有两种工作模式,它们看起来相似,但设计哲学完全不同。

模式一:主动技能(Skill)

这是最常见的模式。用户通过斜杠命令或自然语言触发,技能像一个独立的工具被调用。

比如"天气 SVG 生成器"技能——你问"今天天气怎么样",Command 组件收到请求后,让 Agent 去获取天气数据,然后调用这个技能把数据渲染成一张漂亮的 SVG 图表。

关键特征:

  • 用户可见,可以主动调用
  • 接收对话上下文中的数据作为输入
  • 独立执行,产出自包含的结果
  • 类比:工具箱里的专用工具

模式二:代理技能(Agent Skill)

这种技能不直接被用户调用。它被注入到某个代理的启动上下文中,作为该代理的"领域知识"。

比如一个"天气数据获取"技能——它不会被用户直接使用,而是被预加载到天气代理的知识中。当天气代理启动时,这个技能的完整内容已经被塞进了上下文窗口。代理知道该调用哪个 API、参数格式是什么、怎么解析返回值。

关键特征:

  • 用户不可见(user-invocable: false
  • 在代理启动时注入,不是运行时调用
  • 提供指令性知识而非可执行操作
  • 类比:新员工的入职手册

这两种模式的配合方式很优雅:代理技能负责"怎么获取数据",主动技能负责"怎么呈现结果"。获取和渲染解耦,各管各的。

写好技能的九条铁律

根据 Thariq 分享的 Anthropic 内部经验,写好一个技能需要遵循九条最佳实践。

1. 不说废话

技能正文里不要写"你是一个优秀的 AI 助手"之类的客套话。每一行都应该是有信息量的指令。模型不需要鼓励,它需要规则。

❌ "请仔细检查代码,你很棒的!"
✅ "检查以下三项:空指针引用、SQL 注入、未处理的 Promise"

2. 建 Gotchas 区

这是整个技能系统里价值最高的部分。Gotchas 就是"踩坑记录"——记录那些看起来正确但实际会出错的地方。

## Gotchas
- Stream API 的 `.collect()` 在空流上不会抛异常,但会返回空集合
- `@Transactional` 只对 public 方法生效,private 方法上的注解会被静默忽略
- Docker 多阶段构建中,COPY 指令的路径是相对于前一个阶段的

Thariq 特别强调:在技能被 Claude 加载时,Gotchas 区域的信号量(即注意力权重)最高。因为这些是来自真实失败的经验,模型会优先参考。

3. 文件系统渐进式披露

不要把所有内容塞进一个巨大的 SKILL.md。告诉 Claude 文件结构,让它按需读取。

## 参考文件
- `api-spec.yaml` — 完整的 API 规格
- `examples/` — 使用示例
- `gotchas.md` — 常见陷阱

这样 Claude 在处理简单问题时只读 SKILL.md 本身,遇到复杂场景才去翻参考文件。上下文更精简,响应更快。

4. 不要过度约束

这是最常见的错误。给目标和约束,不要给步骤式指令。

❌ "第一步打开文件,第二步找到函数,第三步修改参数..."
✅ "将所有 API 调用从 REST 迁移到 GraphQL,保持向后兼容"

原因很简单:模型比你更擅长规划执行步骤。你规定步骤反而限制了它的优化空间。

5. 描述字段是触发条件,不是摘要

技能的 description 字段不是给人类看的简介,而是告诉模型"什么时候该用这个技能"的触发条件。

description: "当用户提到部署、发布、上线、或者需要将代码推送到生产环境时使用"

模型会根据这个描述判断是否激活技能。写成摘要就失去了这个功能。

6. 想清楚设置流程

有些技能依赖外部配置——API 密钥、数据库连接、MCP 服务器。在技能里明确写出设置步骤,避免 Claude 盲目尝试。

7. 记忆与数据存储

告诉 Claude 技能产出的数据应该存哪里。是写入文件、更新数据库、还是只在对话中返回。这避免了结果丢失或重复计算。

8. 脚本与代码生成

技能不只是文字指令,可以包含完整的脚本模板。比如一个"数据库迁移"技能,里面可能包含 SQL 模板、回滚脚本、验证查询。

9. 按需 Hooks

Hooks 是确定性挂载到代理生命周期的钩子函数。比如 PostToolUse Hook 可以在每次文件写入后自动运行格式化。不是每个技能都需要 Hook,但在需要自动化流程时它非常强大。

编排的艺术:Command → Agent → Skill

技能不是孤立使用的。Claude Code 的架构推崇一种三层编排模式:

Command(入口)→ Agent(执行者)→ Skill(能力单元)

以"天气查询"为例:

  1. Command 收到用户请求"今天天气怎么样",先用轻量模型(haiku)询问用户偏好(摄氏还是华氏)
  2. Agent 被派出去获取天气数据,它启动时已经预加载了天气获取技能(Agent Skill),知道该调用哪个 API
  3. Skill 被调用来把数据渲染成 SVG 图表(主动技能)

每一层各司其职:Command 负责交互和路由,Agent 负责执行和获取数据,Skill 负责专业输出。这种分离让每个组件可以独立替换——换一个城市的天气 API?改 Agent Skill。换一种图表风格?改主动 Skill。用户交互流程变了?改 Command。互不影响。

Boris 在分享中提到一个深刻的设计原则:入口轻,执行重。Command 用便宜快速的模型,Agent 用中等模型处理逻辑,只有在真正需要深度思考的时候才用 Opus 这种顶级模型。整个调用链的模型选择像一个金字塔——底层频繁调用用便宜模型,顶层复杂决策用贵模型。

10 个官方内置技能

Claude Code 自带 10 个内置技能,覆盖了最常见的开发场景:

技能 用途
code-review 深度代码审查
batch 大规模批量操作
debug 系统化调试
loop 定时循环任务
claude-api SDK 开发辅助
fewer-permission-prompts 减少权限弹窗
run 启动应用服务
verify 验证代码变更
run-skill-generator 生成新的启动配方
simplify 代码精简

其中最值得细说的是三个:

/batch 是 Boris 最喜欢炫耀的功能。它能把一个大规模变更并行分发到数百个独立的 git worktree 中,每个 worktree 由一个独立的 Agent 处理。Boris 曾经一次性让 Claude 在 200 个仓库中统一升级依赖版本——整个过程全自动,每个仓库一个独立 PR。

/loop 是定时任务的优雅实现。/loop 5m /simplify 会每 5 分钟运行一次代码简化技能,最长持续 3 天。任务绑定在会话上,退出 Claude 就自动停止。底层使用 CronCreate/CronList/CronDelete 工具,但用户完全不需要知道这些。

/simplify 的设计很有意思。它不是让一个 Agent 去简化代码,而是同时派出 4 个独立的 review Agent,从不同角度审查代码质量。4 个 Agent 各自给出简化建议,然后汇总决策。这种"多视角并行审查"的模式,比单个 Agent 反复检查更有效。

从个人技能到团队知识库

技能的威力在于它的分发方式。

小团队把技能文件夹检入 Git 仓库,所有人共享。每次有人踩了新坑,就更新 Gotchas。技能在 PR review 中不断迭代,越用越精准。

大团队用插件市场。Anthropic 内部有一个技能商店,工程师可以发布、搜索、安装技能。好的技能会自然浮上来——不是因为有人推广,而是因为用的人多。

Boris 有一个观点值得深思:技能系统的终极目标不是让 AI 更聪明,而是让团队的知识不再只存在于个人的脑子里。 每个人的经验、踩过的坑、总结的最佳实践——都变成一个 .md 文件,可以版本控制、可以 review、可以传承。

当资深工程师离职时,他留下的不是空荡荡的工位,而是一套经过千锤百炼的技能文件。新来的工程师不需要"跟老人学习三个月"——Claude 已经学会了所有前人的经验。

这可能是技能系统最深远的影响。

下期预告

下一篇,我们将深入 Claude Code 最令人兴奋的能力:多代理协作。Boris 怎样同时指挥 5 个 AI 实例并行工作?Agent Teams 和 Subagent 有什么区别?从单兵作战到 AI 军团的组织方法是什么?

下期见。

Views: 18