热点来源：Anthropic 官网 Claude Blog -《The Claude Code Guide For Startups》（https://claude.com/blog/claude-code-guide-for-startups）

为什么这篇值得读

昨天刚写完值班智能体怎么当 CI/CD 一线响应者，今天 Anthropic 又发了一篇分量更重的：基于对十几家高增长公司的调研，总结出"用 Claude Code 规模化交付"的五大规则。如果说上一篇是"单个 Agent 怎么排障"，这篇就是"一个团队怎么用 Code Agent 重构整个公司的开发方式"。对正在把 AI 编程助手从玩具变成生产工具的开发者来说，这些规则直接决定你能不能复制那些公司的效率，而不是把 Agent 用成一个高级自动补全。

一、指南讲了什么

Anthropic 采访了 ClickHouse、Harvey、Cognition、Clay、Omni、Artemis Security 等十几家增长最快的公司，结论一句话：这些公司正在以相当于自身规模十倍的大组织的速度交付产品。注意一个关键措辞——文章把重点放在"如何构建"而不只是"构建什么"。大多数团队在用 AI 造产品，但很少有人重新设计公司的实际运营方式，后者才是更大的解锁。下面五条规则就是这套运营方式的骨架。

二、规则 1：人人皆可交付（Everyone ships）

Agentic coding 把"从想法到可运行原型"的门槛拉平了，理解问题的人可以直接交付第一版，不必先过一遍编程语言和 IDE。Heidi 的 CEO 用一个很准的比喻解释这件事：过去一个新想法要在团队里走"有想法的人 → 产品经理 → 设计师 → 工程师"的传话游戏，等交付时往往已经不像最初那个人脑海里的样子，而且花掉数周。Claude Code 把这条链条折叠了，真正理解问题的人可以直接提交 PR，需要时再引入设计师和工程师的专业能力。

但注意，这不是让所有人都去写代码。文章强调劳动力分工仍然存在——营销人员还是做营销，只是他们现在能自己交付"获取线索 → 填表单 → 计时响应 → 生成体验报告"这类自动化 agent。最有效的公司不是靠个人自觉，而是把这种贡献机制化：Omni 专门开了一个 Slack 频道放 Claude 生成的原型，Clay 设了季度评审会，原型可以直接进入正式路线图。

三、规则 2：自动化繁琐之事（Automate the tedium）

多家创始人的共识是"agent 拥有机械的 80%"：生命周期里那些重复、机械、不需要判断力的部分，全交给 agent，工程师只处理真正需要判断力的案例。数据很直观：

• ClickHouse 交付的功能多了 30%，用来修 flaky tests、发现缺失测试覆盖的两个 agent 已经成为仓库的第 2、3 大贡献者；
• Commure 一位工程师用 Claude 子 agent 并行跑了一个约 13 个 ticket 的项目，每个 agent 负责一个 ticket 和自己的 PR；
• Higgsfield 新模型部署周期从数天压缩到数小时；
• Artemis Security 每周产出 6000+ 个 PR。

这里有个值得学习的分寸：自动化的对象是"有清晰停止条件"的任务。修复 flaky test 之所以适合做 agent，是因为"测试通过"就是自包含的验收标准，agent 可以反复迭代直到达标，不需要人盯着。没想清楚停止条件的任务，不要急着交给 agent。

四、规则 3：信任，但验证（Trust, but verify）

这是规则 2 成立的前提：除非有可靠的监控和验证手段，否则无法自动化任何流程。没有一家调研公司让 agent 直接往主分支合并然后祈祷。两个机制值得展开：

第一，“修复原则，而非修复案例”。Zingage 早期给了 Claude 完全自主权，它快速交付了"看起来合理"的代码，但偏离了团队架构。于是团队写下了 567 行"这个团队如何思考"的不变式文档——如何框定问题、什么必须无条件成立、如何证明某事有效而不是相信一个自信的回答。专家评审用来指导 agent 的推理，而不是逐个修正错误例子。

第二，用确定性检查兜底。Cainex 做医疗编码，一句话点醒：错误的编码不是错别字，是计费和合规事件。所以它把 agent 和确定性检查结合起来，审计员在内置应用里不仅看输出代码，还看模型推理过程并评论，agent 再根据修正反向修订产生错误的指令——形成一个自我改进闭环。每个公司还应该为关键用例维护多套 eval 金标准集并定期更新，防止漂移。

五、规则 4：为重建而构建（Build for rebuilding）

模型能力在脚下不断变化，所以几乎没有东西是永久的。Clay 的说法最有代表性：你构建它，然后你再构建它，然后再构建它——第四次构建时你知道了所有需要知道的东西，就能做对了。注意重建的定义很严格：不是新路径上线就算完成，旧路径被移除才算。

文章给了两个让"重建"变便宜的具体工具。一是 git worktrees：在隔离的仓库副本里跑重建，v2 和 v1 并行，对两者跑评估，只有新版本胜出才合并，让"构建四次"变得廉价。二是计划模式：重要重写以 --plan 或 Shift+Tab 启动，Claude 先探索代码库、提出重建方案，你批准或重定向，这是捕捉"将要偏离你架构的重建"最便宜的场所。Cognition 联合创始人的态度值得记下来：接受你今天构建的东西很可能在六个月到一年内被废弃，但"这在今天可能不奏效，但很快会"。

六、规则 5：原型、自用、产品化（Prototype, dogfood, productionize）

最后一条规则串起了整个飞轮：用 Claude Code 构建内部 agent → 团队自己先用（dogfood）→ 根据真实反馈，用 Claude API、SDK 或 Managed Agents 推广成客户面向的产品。ClickHouse 的 SQL 控制台 agent 和 AI SRE 就是"为客户 AI 体验提供动力的工具，部分是由 AI 构建的"。

自用还有一个隐藏收益：对自家产品性能保持敏锐。团队能快速判断一个问题是模型行为还是 harness 的问题，这对做 Agent 产品的人来说是极其宝贵的能力。Omni 还提到，他们从 Anthropic 的"文件与嵌入"方法里汲取灵感，刻意保持简单，避免了很多 RAG 流水线自带的复杂度——这提醒我们，从"自己用"到"产品化"的过程中，简单往往是更好的默认选择。

七、对 AI Agent 开发学习者的三点启示

1. 个人用和团队用的分水岭是知识沉淀。CLAUDE.md 分两层：根目录放不可变规则（架构、安全边界、不可协商事项），每次会话开始自动读取；子目录放该目录的编码约定。skills 则用于按需的程序性工作流，可以通过公司目录共享，让一个人的最佳实践瞬间变成全公司的。个人开发者从现在起就养成"把约定写进 CLAUDE.md、把流程写成 skills"的习惯，就是为团队化做准备。

2. "信任但验证"要落到机制而不是口号。hooks 是 Claude Code 生命周期固定点触发的用户定义命令，无论模型怎么决定都会执行，可以用作硬门槛：阻止未通过 lint 的写入、要求提交前测试通过、离开沙箱前剥离密钥。MCP 和 CLI 连接（gh、kubectl、psql 这类成熟命令行工具）让 agent 和工程师共享同一个 ground truth。这些机制任何一个都比"提醒它小心点"可靠。

3. 用 Agent 的方式也在被 Agent 重塑。规则 5 的飞轮意味着，今天你写 prompt、搭 harness 的经验，明天就是你产品里的功能。一边用 Claude Code 写代码，一边观察它怎么理解你的仓库、怎么失败、怎么被约束，本身就是最便宜的 Agent 产品课——这也是这篇文章和上一篇值班智能体案例真正连起来的地方。

总结

五大规则是一条完整的链路：人人可交付解决"谁来做"，自动化繁琐解决"做什么"，信任但验证解决"怎么保证质量"，为重建而构建解决"怎么应对变化"，原型-自用-产品化解决"怎么持续放大"。对学习者来说，最有价值的不是记住案例数字，而是看到这些公司在把 Code Agent 当成基础设施在建设。从今天开始给项目写一个根目录 CLAUDE.md，设一条 hooks 硬门槛，比等"Agent 成熟了"再行动要靠谱得多。文中功能与版本细节以 Anthropic 官方文档为准，本文未验证最新版本。