初创公司怎么和拥有 10 倍人力的大厂竞争？

过去的答案通常是：找到更优秀的工程师、更高效的流程，或者接受更少的产品需求。

但 AI Agent 正在改变这道题。

Anthropic 最近走访了十余家高速增长的 AI 原生初创公司，包括 ClickHouse、Clay、Artemis Security、Omni、Crosby、Heidi、Commure、Emergent 等，并将这些公司的实践整理成了一份《Claude Code 初创公司指南》。

这份指南最值得关注的，并不是“Claude Code 能写多少代码”，而是一个更大的变化：

当 Agent 开始进入研发流程之后，真正被重构的不是某一个开发环节，而是整个软件生产系统。

数据显示，ClickHouse 的功能交付量提升 30%，Omni 的工程效率提升 2–3 倍，Clay 已实现 100% 的缺陷分类自动化，Artemis Security 则达到每周 6,000+ 个 PR 的合入规模。

Anthropic 最终把这些公司的共同实践总结成五条规则：

Everyone ships → Automate the tedium → Trust, but verify → Build for rebuilding → Prototype, dogfood, productionize

翻译成更直白的话就是：

让更多人能交付，让 Agent 接管重复劳动；但所有自动化都必须可验证；代码和架构要敢于推倒重来；最后，把“用 AI 开发”的经验反过来变成“用 AI 做产品”的能力。

这五条规则，可能比单纯学习几个 Claude Code 技巧更值得初创团队关注。

如果你需要在工作流中接入API，自由切换全球200+大模型（客服开白），魔芋AI提供合规保障、财务开票、企业级网关、技术支持与定制服务，助力更高效地管理应用AI能力。

链接注册可领百万Tokens：魔芋AI大模型网关I全球大模型一站式调用及服务平台魔芋AI大模型聚合平台（大模型网关平台）专注于提供高效能、低成本的多品类 AI 模型服务，助力开发者和企业聚焦产品创新。https://www.moyu.info/register?aff=qBX9

01 让真正懂问题的人直接交付

Everyone Ships

传统软件公司的产品流程大致是：

业务提出需求 → PM 理解 → 设计师设计 → 工程师开发 → 测试 → 上线

这套流程解决了专业分工的问题，却也带来了一个长期存在的副作用：

信息在传递过程中不断损耗。

Anthropic 把它称为类似“broken telephone”的问题——最了解问题的人，往往距离最终代码最远。

AI Agent 出现之后，一个重要变化是：

“写代码”不再是把想法变成产品的唯一瓶颈。

Heidi 的 CEO Thomas Kelly 就提到，过去一个想法需要经过产品经理、设计师和工程师层层传递，最终交付的东西经常已经和最初的想法不一样，而且可能需要几周时间。

现在，真正理解问题的人可以先用 Claude Code 做出一个可工作的版本，再让工程师和设计师在需要专业判断的地方介入。

Crosby 的案例更加直接。

这家法律科技公司的律师本身就是产品的深度用户。过去，律师只能向产品团队描述“哪里不好用”；现在，他们可以直接使用 Claude Code 做产品改进。

这并不意味着：

“以后人人都要变成程序员。”

真正发生的变化是：

0 → 1 的原型阶段开始向所有角色开放，而专业工程师更多负责复杂集成、架构、安全和最终质量。

可以把它理解成：

传统模式：

业务想法
   ↓
PM
   ↓
UI / UX
   ↓
研发
   ↓
测试
   ↓
产品

AI 原生模式：

真正理解问题的人
   ↓
Claude Code
   ↓
可运行原型 / PR
   ↓
专业工程师审核、完善、合入

这会直接改变初创公司的组织结构。

因为当“提出需求”和“做出第一个版本”之间的距离被压缩之后，团队就不再需要那么多中间层。

---

关键不是给所有人装 Claude Code，而是让 Agent 看见真实世界

这里还有一个非常容易被忽略的问题：

Claude 看不见的东西，就无法理解。

Anthropic 的建议非常明确：把 Agent 接入团队每天真正使用的数据源和工具。

例如：

• 数据库

• 内部 API

• GitHub

• 监控系统

• 数据仓库

• 企业内部工具

如果已经有成熟的 CLI 工具，甚至不一定需要额外搭建 MCP。

例如：

gh
kubectl
bq
psql

这些工具本身就是 Agent 访问真实数据的重要入口。

Anthropic 特别指出，在已有成熟 CLI 的情况下，直接通过 CLI 调用，有时比通过其他方式传递信息更加节省 Token。

所以，真正值得建设的不是一个“更大的 Prompt”，而是一套：

Agent → 工具 → 数据 → 代码库

的上下文基础设施。

---

CLAUDE.md 和 Skills：把个人经验变成组织资产

另一个重要变化，是团队开始把知识写进 Agent 的工作环境。

Anthropic 建议：

• 根目录 CLAUDE.md：放架构原则、安全边界、不可妥协的规则

• 子目录 CLAUDE.md：放具体模块的编码约定

• Skills：保存需要按需调用的工作流程

• MCP / CLI：连接真实的数据和工具

两者不要混在一起。

简单来说：

CLAUDE.md 是“每次都要知道什么”，Skills 是“需要做这件事时怎么做”。

Emergent 甚至建立了一个 GitHub 仓库，用来共享 Claude Code Skills，包括数据库位置、数据仓库信息、Schema 和公司上下文。

这实际上是在建立一个新的组织知识库：

员工的最佳实践 → Skill → Agent → 全公司复用。

---

02 把 80% 的机械工作交给 Agent

Automate the Tedium

如果第一条解决的是：

“谁可以写代码？”

那么第二条解决的是：

“人到底还应该写多少代码？”

Anthropic 在调研中发现，AI 原生团队普遍存在一个共同认识：

让 Agent 接管大约 80% 的机械性工作，让工程师把时间集中到真正需要判断力的 20%。

这里的“机械工作”并不只是写 CRUD。

它包括：

• Bug 分类

• 测试补全

• Flaky Test 修复

• Code Review

• CI/CD 故障排查

• 数据分析

• PR 创建

• 技术债清理

• 文档更新

• 多任务并行执行

ClickHouse：Agent 已经成为核心贡献者

这个案例非常有代表性。

ClickHouse 把大量 SDLC 环节做成了 Agent Loop。

其中两个专门负责：

• 修复 Flaky Tests

• 寻找缺失的测试覆盖率

的 Agent，已经成为 ClickHouse 官方仓库的 #2 和 #3 贡献者。

这意味着一个非常重要的变化：

Agent 不再只是“程序员的 Copilot”，而开始成为代码仓库里的正式贡献者。

---

Commure：一个工程师同时推进 13 个 Ticket

Commure 的案例则展示了 Agent 的另一个优势：

并行。

一位工程师曾经利用 Claude 子 Agent，同时推进一个包含约 13 个 Ticket 的项目。

每个子 Agent 独立处理一个任务，并分别生成 PR。

传统软件开发的基本单位通常是：

一个工程师 → 一个任务 → 一个分支 → 一个 PR

Agent 时代正在变成：

一个工程师 → 一个任务池 → 多个 Agent → 多个并行 PR

这意味着工程师的角色正在从：

“代码生产者”

逐渐变成：

“Agent 编排者 + 结果审核者”。

---

Claude Tag：Agent 开始值班

Anthropic 自己甚至把 Agent 放进了 CI/CD 值班体系。

Claude Tag 拥有独立的服务账号，并可以访问 Datadog、Grafana 等工程工具。

当 CI/CD 出现故障时，它可以自动进入 Slack 线程进行分析。

Anthropic 表示，在最近发生的相关事故中，Claude Tag 通常能在 15 分钟内发布第一份故障分析报告。

这已经不是：

“让 AI 帮我写一段代码。”

而是：

“让 AI 成为软件生产系统里的一个长期运行节点。”

---

03 信任 Agent，但一定要验证

Trust, but Verify

前两条听起来非常激进。

但 Anthropic 最重要的提醒恰恰是：

你可以让 Agent 自动化，但不能让验证也一起自动消失。

因为 Agent 最大的问题不是不会写代码。

而是：

它可能写出看起来完全正确、实际上偏离架构的代码。

Artemis Security 的工程效率之所以能够快速提升，并不是单纯因为用了 Claude，而是因为他们同时投入了大量精力建设：

• 测试基础设施

• 代码库组织

• 团队知识系统

• 自动化验证

他们实际上构建了一个飞轮：

更好的代码结构 → Agent 更容易理解 → Agent 贡献更多代码 → 测试和验证保证质量 → 更多代码进一步沉淀上下文。

---

Zingage：567 行“不变量”

Zingage 的做法非常极端，但很有代表性。

团队曾经发现，Agent 虽然能够快速生成“看起来正确”的代码，却可能逐渐偏离原本的架构。

于是，他们把团队的思考框架、架构原则和不可变规则整理进根目录 CLAUDE.md。

最终形成了 567 行的团队工程规则。

核心思想非常简单：

哪些东西可以改，交给 Agent；哪些东西绝对不能改，必须写清楚。

---

Cainex：不要修 Case，要修规则

医疗计费公司 Cainex 的案例则更值得 AI Agent 开发团队借鉴。

他们让 Agent 处理医疗编码，然后由人工审核员检查结果。

如果出现错误，并不是简单地告诉 Agent：

“这个 Case 错了。”

而是：

1. 收集人工纠错

2. 找到导致错误的原始规则

3. 修改 Agent 的指导规则

4. 在失败样本上重新测试

5. 放入 Golden Set

6. 在随机样本上回归

7. 确认没有产生新的 Regression

8. 再进入生产

整个过程可以概括为一句话：

Fix the principle, not the example.

不要让 Agent 为了一个 Case 打补丁，而应该让它从 Case 中找到可以泛化的规则。

这其实也是 Agent 产品从“能跑”走向“越来越可靠”的关键。

---

所以，一套真正可靠的 Agent 工程体系至少需要四层

层级	作用
CLAUDE.md	固化架构、安全和不可变规则
Hooks	在固定生命周期节点设置硬门禁
Loops	让 Agent 持续执行，直到满足明确停止条件
Golden Set / Evals	持续判断 Agent 是否真的变好了

Anthropic 特别强调，Hooks 可以在固定生命周期节点触发，并作为确定性的硬门禁，例如 Lint 不通过就阻止写入、测试失败就阻止 Commit、敏感信息离开沙箱前进行拦截等。

这其实揭示了 Agent 工程的一个基本原则：

模型负责判断，工程系统负责兜底。

---

04 不要害怕推倒重来

Build for Rebuilding

传统软件工程有一个根深蒂固的习惯：

尽量复用旧代码。

因为重写成本太高。

但 AI 原生公司的逻辑正在发生变化。

如果模型能力每隔几个月就发生一次跃迁，那么今天最优的架构，很可能半年之后已经不是最优解。

Anthropic 将这种思路总结成：

Build for rebuilding。

不是追求“一次构建，永久使用”，而是：

让重构变得足够便宜。

---

Clay：第一版只是开始

Clay 创始人 Kareem Amin 对此有一个很形象的描述：

第一次构建、第二次构建、第三次构建，到第四次构建时，你才真正知道所有需求是什么。

这并不意味着浪费。

恰恰相反：

前几次构建本身就是理解问题的过程。

过去，一个团队可能因为重写成本太高，而被迫维护一个已经不适合当前需求的架构。

现在，Agent 把大量重构工作自动化之后，“重新做一遍”的成本开始下降。

---

Commure：清理技术债也可以变成 Agent 任务

Commure 曾经把 Feature Flag 清理这类工作视为典型的“没人愿意做，但又必须做”的技术债。

现在，他们可以直接调用一个 Skill：

找到已经对所有用户开放的 Feature Flag → 删除 Flag → 删除关联代码 → 创建 PR → 工程师审核。

过去可能需要消耗大量开发时间的迁移工作，现在可以通过 Agent 扇出，在几个小时内完成。

这也是一个很重要的变化：

当清理技术债的边际成本下降之后，旧代码不再那么容易变成永久负担。

---

Git Worktree：让重构变得低风险

Anthropic 推荐在大规模重构时使用 git worktree。

简单理解：

          同一个 Git 仓库
                │
      ┌─────────┼─────────┐
      ↓         ↓         ↓
     v1        v2        v3
    当前版本   重构版本   实验版本

旧版本继续运行，新版本在独立目录中开发。

然后分别跑测试和 Eval。

新版本赢了，再合并。

这样一来，“推倒重来”就不再意味着“赌一把”。

而变成：

隔离 → 构建 → 评测 → 对比 → 合并。

Anthropic 也建议，对于复杂重构，先进入 Plan Mode，让 Claude Code 先探索代码库并提出方案，再决定是否执行。

---

05 原型 → 自用 → 产品化

Prototype, Dogfood, Productionize

最后一条，是这五条规则中最有意思的一条。

因为它已经超越了“研发效率”。

AI 原生公司正在形成一个新的产品飞轮：

用 Agent 构建内部工具
        ↓
团队自己高频使用
        ↓
暴露 Agent / Harness 的问题
        ↓
不断改进
        ↓
形成产品能力
        ↓
面向客户商业化
        ↓
更多真实反馈
        ↓
继续改进

也就是说：

你如何使用 AI 构建产品，本身会反过来影响你最终构建什么产品。

---

Omni：从 Claude Code 学到产品架构

Omni 的案例尤其值得注意。

他们在研究 Claude Code 如何处理上下文时，发现一些看似复杂的问题其实不一定需要复杂的 RAG。

于是，他们在自己的产品里采用了更加简单的文件直读方案。

同时，他们也观察 Claude Code 的并行 Agent 机制，并把类似的设计思路带到了自己的产品 UI 中。

这就是所谓的：

Dogfood。

不是简单地“自己也用一下”。

而是：

在使用 AI 工具的过程中，持续发现产品应该如何设计。

---

ClickHouse：用 AI 开发 AI

ClickHouse 也采取了类似路线。

团队使用 Claude Code 构建自己的：

• SQL Agent

• AI SRE

• 数据分析能力

然后继续用 Claude Code 迭代这些 Agent。

最终形成：

AI 帮团队构建 Agent → 团队使用 Agent → Agent 成为产品能力。

这可能是 AI 原生创业公司与传统软件公司的一个重要区别：

传统公司的研发工具和最终产品通常是两套系统。

而 AI 原生公司正在让两者逐渐形成闭环。

---

真正的“10 倍团队”不是 10 倍写代码

回头看 Anthropic 调研的这些数据：

• ClickHouse：功能交付量 +30%

• Omni：研发效率提升 2–3 倍

• Clay：100% 缺陷分类自动化

• Artemis Security：每周 6,000+ PR

如果只看这些数字，很容易得出一个简单结论：

“Claude Code 让程序员写代码更快了。”

但这其实低估了变化。

Anthropic 真正展示的是另一套研发组织模型：

传统软件公司

人
 ↓
需求
 ↓
PM
 ↓
设计
 ↓
开发
 ↓
测试
 ↓
上线

而 AI 原生团队正在变成：

人提出目标
      ↓
Agent 并行执行
      ↓
自动测试 / Review / Eval
      ↓
人工处理关键决策
      ↓
合并 / 上线
      ↓
生产反馈
      ↓
更新规则 / Skills / Agent
      ↓
下一轮执行更快

于是，效率提升的来源不再只是：

“AI 帮工程师多写了多少代码。”

而是：

“整个组织有没有形成一个会自我加速的工程飞轮。”

---

初创团队真正值得抄的，不是 Prompt，而是这 5 件事

如果把 Anthropic 这份指南压缩成一张执行清单，其实可以非常简单：

1. 让 Agent 接触真实上下文

把数据库、GitHub、监控、内部工具等真实数据源接入 Agent。

优先使用已有 CLI，必要时再通过 MCP 建立连接。

2. 把团队经验写下来

根目录 CLAUDE.md 放不可变规则。

子目录维护局部规范。

重复出现的工作流则沉淀成 Skills。

3. 把重复工作变成 Loop

Bug triage、测试修复、Code Review、CI 故障、数据分析等，只要拥有明确的停止条件，就可以尝试 Agent 化。

4. 把验证系统放在 Agent 前面

不要问：

“Claude 写得对不对？”

而应该建立：

Tests + Hooks + Evals + Golden Set

让系统自动告诉你：

“这次修改到底有没有变好。”

5. 让重构变得便宜

使用 git worktree 隔离实验。

使用 Plan Mode 先规划再执行。

不要因为旧代码已经投入大量时间，就拒绝更好的新架构。

---

最后

Anthropic 这份指南真正值得关注的，并不是又总结出了五个 Claude Code 技巧。

而是它透露了一个越来越清晰的趋势：

AI Agent 正在从“开发工具”，变成“组织基础设施”。

过去，一个软件公司的生产力上限，很大程度上取决于有多少优秀工程师。

未来，这个公式可能逐渐变成：

组织效率 = 人 × Agent 数量 × 上下文质量 × 自动化程度 × 验证能力

这也是为什么真正领先的 AI 初创公司，并没有把 Claude Code 简单理解成一个“写代码工具”。

他们正在重新设计：

• 谁可以交付

• 什么工作应该自动化

• 什么结果必须验证

• 什么代码应该被重写

• 如何让内部研发反哺最终产品

最终形成的，不是一个“更快的程序员”。

而是一套能够持续自我优化的AI 原生研发系统。

而这可能才是 Anthropic 所说的：

“像一个自身规模 10 倍的组织一样交付。”