开篇语

最近 AI 编程有多火，不用我多说，相信很多小伙伴已经在用了。

但有个问题一直绕不开：AI 写代码是快了，团队接得住吗？

网上教程一抓一大把，教的全是怎么"让 AI 多写代码"。可真正卡住团队的从来不是生成速度，是工作方式本身。代码越来越便宜之后，验证成本和组织成本反而成了新的瓶颈——这一点，大部分人压根没在意。

8 月 20 日，Anthropic 发了一份 27 页的《The Claude Code Guide For Startups》，采访了 15 家快速增长公司：ClickHouse、Clay、Cognition、Harvey、Commure、Crosby、Heidi、Omni、Higgsfield、Artemis Security、Cainex、Emergent、Parahelp、Translucent、Zingage。

先看四个数字，都是官方指南里的：

• ClickHouse：功能交付多了 30%
• Omni：工程生产力 2–3 倍
• Clay：100% 的 bug 分诊自动化
• Artemis Security：每周合并 6000+ 个 PR

先泼盆冷水：这些数字都是被访公司自己报的，官方没披露统计周期和基线，也没有独立审计。 谁要是跟你打包票"装上 Claude Code 就能扩大十倍"，你可以直接拉黑。

但这份指南的价值不在这几个数字，而在它把 15 家公司的实践抽象成了五条底层逻辑，回答了一个很本质的问题：如果一家公司从零开始，用 Claude Code 重新设计研发流程，会是什么样？

这期内容分七个部分：

1. 为什么传统研发流程在 AI 时代失效
2. 逻辑一：降低准入门槛，让最懂问题的人直接动手
3. 逻辑二：自动化的边界，把机械的 80% 交给 Agent
4. 逻辑三：验证是自动化的前提，信任但必须验收
5. 逻辑四：为不确定的重写做设计
6. 逻辑五：把内部使用当成生产检验
7. 结尾：五条规则其实是一个飞轮

一. 为什么传统研发流程在 AI 时代失效

先一句话定义：传统软件开发生命周期（SDLC）是一条单向流水线——需求 → 设计 → 编码 → 测试 → 部署，每个环节专人负责。

这套流程在"写代码很贵"的年代是合理的：工程师时间稀缺，所以层层把关、分批传递。

但 AI 时代把前提干掉了。代码生成越来越便宜，组织上下文和验证能力反而越来越贵。

你可以这样理解：以前瓶颈是"写不写得出来"，现在瓶颈是"团队知不知道要写什么、写出来的对不对"。

我翻完整份指南，发现 27 页里大部分篇幅不是在讲怎么让 Claude 写代码，而是在讲三件事：组织上下文怎么沉淀、验证体系怎么建、规则怎么变成门禁。

所以这一节的核心不是"AI 多强"，而是——当代码不再是瓶颈，研发流程必须重新设计。 这就是整份指南的出发点。

二. 逻辑一：降低准入门槛，让最懂问题的人直接动手（Everyone ships）

2.1 想法每传一手，就失真一次

Anthropic 在指南里反复提一个痛点，Heidi 联合创始人 Thomas Kelly 管它叫"传话游戏"（broken telephone），原话大意是：

以前一个想法的流转路径是：有想法的人 → 告诉 PM → PM 告诉设计师 → 设计师再告诉工程师。每一手都丢一点原意，等上线时，往往已经不是最初那个想法了，而且整个过程要好几周。

这个链条的本质问题不是谁不努力，而是信息在层级传递中必然衰减。

Claude Code 做的事不是优化这条链，而是直接把它压扁：最懂问题的那个人，可以直接把想法变成一个能跑的 PR。

Crosby 是家法律 AI 公司，他们的律师直接上手改产品。创始人 Ryan Daniels 的原话我印象很深：“Claude Code 改变了律师在 Crosby 的意义——律师拥有最好的产品洞察，因为他们就是用户。”

2.2 分工没消失，消失的只是"0 到 1"的门槛

这里必须先纠个误区：“人人皆可交付"≠"人人都在写生产代码”。

指南说得很清楚：市场的人还是做市场，开发的人还是做开发。真正开放给所有人的，只有从想法到可讨论原型（0→1）这一步。架构、合并、上线、合规，仍然由专业的人把关。

2.3 把偶发贡献，变成系统性机制

我注意到，做得好的团队没有停留在"鼓励大家用 AI"，而是建了让贡献系统化发生的机制。官方指南给了三个方向，直接抄：

第一，创建连接（Create connections）。 Claude 看不到的东西，对它来说就是不存在的。要么通过 MCP 接入数据库、API 和业务工具；要么直接给它成熟的命令行工具（gh、kubectl、bq、psql 这类），后者更省 token。我个人的经验是：能上 CLI 的别急着上 MCP，简单直接。

第二，展示机制（Showcases）。 Clay 在季度评审里让原型可以进入正式路线图；Omni 专门建了个 Slack 频道展示 Claude 生成的原型，资深技术成员也往里扔东西。别让好原型烂在某个人的本地目录里。

第三，共享 Skills。 把团队上下文和标准写成可复用的 Skill 文件。Emergent 维护了一个 Claude Code Skills 的 GitHub 仓库当知识库，放数据库位置、schema、公司上下文。他们的 CEO 说得挺实在：上下文文件稍微过时也没关系，“只要 Agent 能快速验证并纠正方向”。

所以这一节的核心不是"让非程序员写代码"，而是让最懂问题的人先做出能讨论的版本，再用机制保证这件事持续发生。

三. 逻辑二：自动化的边界，把机械的 80% 交给 Agent（Automate the tedium）

3.1 先记住这句反直觉的话

Artemis Security 联合创始人 Shachar Hirshberg 有句话，我建议你直接摘下来：

所有人都在抢着做 AI 产品，但极少有人重建公司本身的运转方式。后者才是更大的解锁。

第二条规则的本质，就是这句话：自动化不是为了"让 AI 写代码更快"，而是为了把一整类人工操作从工作流里删掉。

3.2 别人都自动化了什么

指南里的案例非常具体，举三个：

• Clay：Agent 把 100% 的 bug 分诊自动化——Bug 进来自动分类、自动分派，人只管审核。
• ClickHouse：让 Agent 修偶发失败的测试、找缺失的测试覆盖。这两个 Agent 一度成为代码库贡献量第二、第三的"贡献者"。
• CI 故障分析：Claude 生成的持续集成故障首份分析报告，通常 15 分钟左右就能出来。以前这事儿至少要等一个工程师腾出手。

3.3 什么该自动化？三个特征直接抄

这里有个判断标准，我建议你贴在工位上。适合先自动化的流程，同时满足三个特征：输入明确、结果能检查、失败能回滚。

• 适合：PR 初审、测试修复、Bug 分派、固定报表、重复的数据整理。
• 不适合：产品路线、权限设计、医疗和合规判断——这些必须人拍板。

3.4 自动化的隐形成本：过期文档

自动化最容易踩的坑，是被过期文档拖累。Agent 读到的如果是一堆互相打架的旧结论，产出的东西还不如不读。

Anthropic 给的分层方案，我整理成清单：

• 根目录 CLAUDE.md：尽量简短，只做索引（构建命令、目录结构、全局约定）。
• Skills：放具体的部署、排障、评审流程，按需加载。
• 一次性计划：做完就归档，别留在工作区里误导 Agent。
• 每份规则：写清负责人、适用范围、失效条件。

我见过太多团队把 CLAUDE.md 写成 500 行的《项目百科全书》，结果 Agent 每次都要先消化半天，还经常被旧结论带偏。CLAUDE.md 是索引，不是文档库。

所以这一节的核心不是"自动化越多越好"，而是只自动化输入明确、结果可验证、失败能回滚的机械工作，人永远保留判断权。

四. 逻辑三：验证是自动化的前提，信任但必须验收（Trust, but verify）

4.1 为什么必须验证？因为"看起来对"最危险

第三条规则是第二条的必然推论：你没法自动化一个无法监控和验证结果的流程。

Zingage 联合创始人 Victor Hunt 讲了个特别真实的教训：早期他们给了 Claude 很大自主权，它确实能快速产出代码——问题是，这些代码悄悄偏离了架构，样子是对的，实质是错的。

他们的解法很硬核：把团队所有不变量写下来——怎么定义问题、什么必须永远为真、怎么证明一件事真的有效而不是"自信地回答"。一共 567 行。

4.2 医疗编码公司的三重样本：Cainex 的做法

Cainex 做医疗编码，一个错误代码可能变成计费甚至合规事故，属于错误成本极高的行业。他们的做法是：把人工审核意见、原始预测、错误分类、版本化指令全部串起来，任何候选修改必须重跑三类样本：

1. 失败样本：之前出过错的 case，修复后必须不再错。
2. 固定测试样本：一组稳定不变的回归用例。
3. 随机样本：随机抽的用例，防止"只对已知答案过拟合"。

三类跑不完的，直接交给工程师人工处理。而且他们修的是共性原则，不是为某一个失败样本临时打补丁。

这条我觉得值得每个团队抄：样本集就是你团队记忆的实体化。 没有样本集，你所谓的"经验"只是散落在个人脑子里的印象。

4.3 判断"能否长期自主运行"的四问

指南给了四个标准，任何想上"长时间自主 Agent"的团队先过一遍：

1. 结果能否观察？
2. 停止条件是否明确？
3. 有没有失败样本？
4. 错误成本能否承受？

四项全满足，才值得做长期自主 Agent；少一项，就先做成有人盯着的半自动。 官方原话说得很直接：CLAUDE.md 里写"不要泄露密钥"只是提醒，真正能拦住问题的是硬门禁——提交前扫密钥、测试失败就阻断合并、禁止破坏性命令。软提醒永远代替不了硬门禁，记住这句。

4.4 别用 PR 数衡量团队效果

最后是衡量方法。指南建议：从过去一个月挑 20 个真实任务，固定代码库、工具权限和验收口径，然后记录六个指标：首次通过率、总耗时、模型费用、人工审核时间、返工轮数、回归问题。

按一次完整任务的成本算，而不是按产出数量算。 PR 数量是虚荣指标，完整任务成本才是真实效率。

所以这一节的核心不是"不信任 AI"，而是信任必须建立在可观察、可验证、可回滚的体系上。

五. 逻辑四：为不确定的重写做设计（Build for rebuilding）

5.1 重写不是意外，是必然

Clay 创始人说过一句实在话：同一个东西你可能要做四遍，做到第四遍才知道自己真正需要什么。 Harvey 也提到，模型能力一变，平台可能就得重做。

底层模型的迭代速度摆在那——今天的"最佳实践"，三个月后可能就过时了。所以指南的判断是：既然重写难以避免，系统从一开始就要允许旧实现被隔离、比较和替换。

5.2 实现可以替换，验证资产不能丢

这是这一节最关键的区分，一定要划重点：

• 实现（代码）是廉价的，随时可以重写。
• 验证资产（测试、数据迁移方案、兼容边界、回滚路径）是昂贵的，重写四遍只会重踩老坑。

没有验证资产的重写叫"赌运气"，有验证资产的重写才叫"迭代"。

5.3 落地三件套：worktrees + Plan mode + 同任务对比

具体怎么落地，指南给了三个动作：

1. git worktrees：在仓库的隔离副本里跑重建，当前版本继续正常工作——重写四遍不等于四次宕机。这一条我强烈建议团队都配上，成本极低收益极高。
2. Plan mode：先审方案再动手，别让 Agent 直接开写。
3. 同一组任务对比：新旧实现跑同一批任务，用结果说话，不用嘴说话。

5.4 变与不变的边界

指南还给了个很实用的分层判断：

• 可以激进尝试的：前端交互、Agent 路由、实验性工作流。
• 必须保守的：账务、权限、核心数据模型、外部协议。

道理很简单：模型变化再快，数据库里的用户资产也不能跟着抖。

所以这一节的核心不是"鼓励乱重构"，而是用隔离、比较、替换的机制让重写变成低风险动作，同时把验证资产当成不可丢的财富。

六. 逻辑五：把内部使用当成生产检验（Prototype → dogfood → productionize）

6.1 先做内部 Agent，让自己的团队天天用

第五条规则把前四条串成了一条完整路径：先做一个内部 Agent，让团队在真实任务里天天用。 它在真实场景暴露失败后，再补上下文、测试、权限和人工接管；只有内部使用证明它稳定、有价值，才把能力做进客户产品。

道理很简单：内部试用就是一轮低成本的生产检验。 你的团队就是最挑剔的第一批用户，任何"演示很酷但实际不顶用"的问题，都会在日常使用里暴露出来。

我见过太多团队，demo 做得惊艳，一上生产就崩。区别就在于有没有 dogfood 这一步。

6.2 案例：从内部到产品的转化

• Omni：把 Claude Code 的一些工作方式改造成面向用户的界面。
• Emergent：用 Claude Code 判断问题是出在模型本身，还是出在 Agent 外层系统。
• ClickHouse：他们的产品 Agent 也是先在内部持续使用、持续改进。

6.3 官方两周试点 checklist，直接抄

想真正开始，指南给了一份可以直接照做的检查清单，我原样整理给你：

1. 选一个输入清楚、重复发生、可回滚的流程。
2. 接入权威数据源：有成熟 CLI 就用 CLI，需要统一接入再上 MCP。
3. 写一份短 CLAUDE.md（只做索引，别写成长篇大论）。
4. 把操作步骤做成一个 Skill。
5. 用 Permissions 和 Hooks 卡住危险动作。
6. 从历史任务里抽固定测试样本。
7. 在独立 worktree 里产出 PR，不自动合并。
8. 连续运行两周后，按完整任务成本决定：扩大、修改，还是关闭。

记住：两周，不自动合并，按完整任务成本决策。 这三条是试点的安全绳。

所以这一节的核心不是"做个演示级 Agent"，而是先让内部使用把问题暴露干净，再决定要不要交给客户——别把"demo 能跑"当成"可以上线"。

七. 结尾：五条规则其实是一个飞轮

最后把五条逻辑串起来，你会发现它们不是并列的清单，而是一个闭环飞轮：

降低门槛（Everyone ships）→ 更多原型和交付 → 自动化机械工作（Automate the tedium）→ 人腾出手做判断 → 验证体系跟上（Trust, but verify）→ 沉淀更多测试和门禁 → 重写成本变低（Build for rebuilding）→ 敢于迭代 → 内部验证后产品化（Prototype → dogfood → productionize）→ 更好的机制 → 回到第一步。

这五条规则真正留下的，不是某家公司的具体做法，而是一种能力：把失败变成测试、把经验写成流程、把边界做成门禁。

模型会换、代码会重写、评测方法也会过期，但**“让最懂问题的人先动手 + 机械工作交给 Agent + 用硬门禁验证 + 为重写设计 + 内部先试”**这套组织能力，会一直在。

最后留两个思考题给你：

1. 如果只把你团队的一个流程交给 Claude Code，你会选哪个？
2. 它的停止条件是什么？错一次要付出多大代价？

想清楚这两个问题，比记住五条规则的名字重要得多。

---

本文基于 Anthropic 官方发布的《The Claude Code Guide For Startups》（2026-08-20）整理。文中所引公司数据均为被访公司自述，官方未披露统计周期与基线，无独立审计，请理性看待。