Claude Code 团队如何使用 Claude Code：一年之内，从逐条审批到只给目标

本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。

How the Claude Code team uses Claude Code https://www.youtube.com/watch?v=S-sYlFiGFv8&t=3s

Claude Code 团队三位工程师（Thariq Shihipar @trq212 负责 Claude Code，Sid Bidasaria 负责 workflows，Robert Boyce 负责 Claude Tag）的圆桌对谈，回顾加入团队约一年来，自身工作方式与软件开发范式的变化。

工作方式的根本转变：从 "盯 transcript" 到 "给目标"

一年前的用法是：给 Claude Code 写 prompt、逐条反馈、逐个批准权限请求；现在团队成员 70–80% 的工作在 Claude Tag（Slack 原生 agent）中完成，只有约 20% 的精修或"微观管理"场景才打开 TUI 或桌面端。
交给 AI 的任务复杂度已从"实现这个类/写这个函数"跃升到端到端的复杂问题。
核心心态变化：不再关注每一次工具调用和每一个决策，而是拉远视角——"我有一个目标，把目标交给模型去达成"。
Claude Tag 之所以有效，是因为它生活在 Slack 中，能主动检索产品上下文和团队历史决策，从而做出更好的判断。

为 "两个月一换代" 的技术构建产品

传统产品底层技术的"保质期"以年计；AI 模型的能力每两个月就会在脚下发生根本位移，且周期还在压缩。
团队必须同时做到两件事：站在（甚至超越）前沿感知边界，又要为今天的用户提供当下价值。这是"半艺术半科学"的平衡。
关键原则：对自己构建的功能保持"不依恋"。很多 harness 层的特性本质上是在弥补当前模型的失败模式，模型进步后就该果断删除；随之而来的是任务规模扩大，模型需要的工具形态也随之改变。
典型案例：To-do list：Sonnet 3.5 时代模型无法完成长程任务（给 5 件事只做 3 件就放弃），to-do list 完美解决了那个时刻的问题；一年后已基本不再需要，被更复杂的记忆状态替代。 AskUserQuestion 工具：设计耗时极长、起初模型很难正确调用；后来模型调用得很好；再后来作者自己都不太用了——直接让 Claude 生成带图表和 mockup 的 HTML artifact 来向他提问。
团队自称是软件开发未来走向的"精神时光屋"：一边要快速组小团队做全新的主动式 agent，一边还在重写权限系统、开发 artifacts。方法论是构建可叠加的原语（primitives）——权限、可视化、记忆、验证等——再让它们层层组合。

Loops / Routines 的由来：从本地到云端

演进路径很务实：

在笔记本本地跑 agent → 下班关机 agent 就停了；
改用远程托管开发机 → 但需要 ssh 回去，体验割裂；
由此催生 Claude Code on the web：托管容器持续后台运行；难点是要让容器获得开发环境的访问权限，配置有些麻烦，但"值得，生产力提升约 10 倍"；
一旦跑在云端，就能做 routines：例如每天自动汇总所有反馈，按重要性分桶，并自动修复那些高置信度能修的问题。

这就是 Boris 常讲的"loop journey"：从在一个 session 里 prompt 模型，突破 session 边界，转而去 prompt 更高一层的东西，让它替你持续修 bug、办事。

代码审查的重构，以及 Workflows 的诞生

代码审查的角色变化

传统人类 review 常见模式是挑三个小 nit 来"证明我读了代码"，这部分现在完全可以由 Claude 发现并自主修复。
人类 reviewer 的价值上移到大局判断：为什么 API 这样设计、服务边界为何划在这里——这些 Claude 写 PR 时可能没有完全内化的背景。Claude 的作用是把相关信息提炼后交给人，让人在更高抽象层次思考。

Fan-out + 测试时计算（test-time compute）

代码审查是团队第一次大规模使用 fan-out：并行搜索所有潜在 bug，再收敛。对每个候选 bug 做对抗式审查——从三个不同视角判断是否真实存在——从而过滤噪音，只留下真正需要人关注的问题。
本质是 MapReduce 式问题：fan-out 后信息量爆炸，必须再 reduce 到人类可消费的程度；建立置信度的手段就是往问题上投入更多推理算力。
同一模式可泛化到性能问题、通用深度研究（例如"带父母去 Tahoe 住哪"：10 路搜索 → 排序 agent → 验证 agent → 汇总）。

Workflows 的关键洞察

Claude 很擅长自己构建 harness：自行决定 fan-out 拓扑、如何把一层 agent 的输出接入下一层、如何最终汇总。
Workflows 由 agent 编写代码来编排子 agent，形成"确定性代码 + agentic LLM 行为"的混合。一个 for 循环不会漏掉某一项、会对所有条目一致地施加同一处理——这种确定性显著提升了对 Claude 行为的信任。

Claude Tag：UI 与 transcript 首次解耦

团队正"激进地用 Claude Tag 开发 Claude Tag"，Robert 的重点是确保开发环境和 dev loop 对 Claude 足够友好，使其能独立完成人类构建与端到端测试软件所需的一切。软件越复杂、集成越重，这件事越难也越关键。
这是第一次将用户界面与 transcript 彻底分离：Slack 中看到的 Claude 消息是它主动调用"发消息"工具的结果，内部推理不可见（仅提供完整 transcript 链接）。
起初"看不到 Claude 在想什么"令人不安，但很快变得解放：Claude 自己决定说什么、何时说；开发者被迫"让 Claude 放手做"，而结果证明模型已经足够好，不再需要逐条监督。
一个完整的实践案例（推动一个需要多方 buy-in 的新工具）：问 Claude Tag "谁会对这个想法感兴趣" → 找到利害相关方；在 Slack（甚至手机上）让它出 mockup；让它实现，并大量埋事件点；内部部署后由 Claude Tag 持续监控使用情况，有人反馈时主动 tag 作者；发现漏斗转化不佳时，不再是"我有个想法你去做"，而是"请你来提出改进漏斗的方案，我的想法只作为一个示例"——在更高层次协作。
这个案例串起了 Claude Code 的三大原语：验证（verification）、代码审查（code review）、反馈获取（连接指标/事件/Slack/GitHub issues 等数据源）。团队尤其重视验证：Claude 给 Claude Code 提 PR 时会自行测试并发送截图；作者甚至让它用 TUI 录屏自证，自己再 clone 下来"为保险起见"验一遍——并预期未来连这一步也会省掉。

对 "旧时代软件工程" 的怀念与角色重塑

一位工程师曾从性能工程中获得巨大乐趣，如今承认 Claude 做得比自己更好，但依然能享受性能提升带来的收益；注意力转向更快地产生新想法，缩短从想法→原型→生产的路径，从"深入细节"切换为"拉远视角"，接受在单一领域"少一些精通"。
另一位曾花一整天手写 CSS 复刻 macOS 10.4 Aqua 按钮的径向渐变叠层，现在"再也不会手工做了"。这让他想起七八岁时想做游戏、不会编程只能用 PowerPoint 做可点击形状的经历——Claude 让整个软件工程变得可及：不再有"我没有这项技术能力"的障碍，只需说清目标、拆解、与 Claude 协作。
结语：软件工程本就是"关于变化的职业"——从手写无框架 JavaScript到框架、编译器的出现，变化一直在发生，只是现在更快。本质没变：用工具创造出色的东西，解决问题——只是解决的问题不同了。