Claude Code 创业公司指南：15 家公司、5 条规则与落地清单

全文核心要点

• 让问题拥有者完成 0→1。 市场、法务、销售、医生等角色可以先做出工作原型；工程、设计、安全和合规人员负责评审与生产化。
• 优先自动化可检查的机械工作。 PR 审查、缺陷分流、测试修复、覆盖率补全、事故初查和批量数据分析，都有明确输入与可验证结果。
• 验证能力决定 Agent 权限。 CLAUDE.md 保存规则，Loops 负责重复执行，Hooks 提供硬门禁，评测和人工升级负责发现漂移与阻断回归。
• 把重建成本压低。 Worktree 隔离新旧版本，Plan Mode 先审方案，同一套评测决定是否合并，迁移完成后删除旧路径。
• 内部验证后再产品化。 团队先在真实数据、权限和工作节奏中使用内部 Agent，再根据失败记录决定哪些能力可以交给客户。

15 家公司，分别把 Claude Code 用在哪

同一件工具，在这 15 家公司里进入了完全不同的位置：有人让律师和市场直接做产品，有人把测试、Code Review 和值班交给 Agent，有人重建评测系统，也有人用 Claude Code 反过来设计自己的 AI 产品。

15 家公司

5 RULES / 15 TEAMS

15 家公司，把五条规则跑起来

点公司看具体做法；点规则筛选对应团队。15 家公司默认全部展开。

全部 15 01 人人交付 02 自动化 03 验证 04 重建 05 产品化

Artemis Security02 · 03 Cainex03 Clay01 · 02 · 04 ClickHouse02 · 05 Cognition04 Commure02 · 04 Crosby01 · 02 Emergent01 · 02 · 05 Harvey04 Heidi01 · 02 Higgsfield03 Omni01 · 02 · 05 Parahelp01 Translucent01 · 02 Zingage03

02 · 05ClickHouse

30% 更多功能交付

两个测试 Agent 成为仓库第 2、第 3 大贡献者；团队还用 Claude Code 迭代 SQL 控制台 Agent 和 AI SRE。

1. Artemis Security6,000+ PR / 周。把机械工作交给 Agent，同时用测试基础设施、代码库组织和团队知识系统支撑端到端交付。
2. Cainex医疗编码验证闭环。审计员检查编码与推理，纠正按错误类型入库；Claude Code 修订通用原则，再跑黄金集和随机样本。
3. Clay100% 缺陷分流自动化。季度评审让非技术员工的原型进入路线图；Bug Agent 从初筛一直做到提出代码修改建议，并反复重建同一功能。
4. ClickHouse30% 更多功能交付。两个测试 Agent 成为仓库第 2、第 3 大贡献者；团队还用 Claude Code 迭代 SQL 控制台 Agent 和 AI SRE。
5. Cognition6–12 个月系统寿命。接受今天的 AI 系统可能在半年到一年后被淘汰，并围绕未来模型能力提前设计架构。
6. Commure约 13 个 ticket 并行。Subagents 分别拥有 ticket 和 PR；另一项 Skill 自动扫描并删除已全量发布的 feature flag 与旧代码。
7. Crosby数千份法律文件并行汇总。把 Claude Code 接进律师熟悉的工具，让律师直接做产品原型，并用 Subagents 批量处理法律材料。
8. EmergentMarkdown 完成首日环境初始化。新员工让 Claude 读取一份 Markdown 即可搭好环境；共享 Skills 仓库保存数据库、Schema 和公司上下文。
9. Harvey为新模型能力重做平台架构。推理、自动化、规划和编排能力每进一波，平台就重新设计；旧架构该丢就丢。
10. Heidi领域人员直接 PR + 合规审查。最懂问题的人先提交 PR；自动审查再对照既定技术与合规框架，标出严重问题并路由给专业审阅者。
11. Higgsfield模型接入：数天 → 数小时。新视频和图像模型进入生产前要补 Skills、评测、路由和测试；Claude Code 把这轮接入压缩到同一工作会话。
12. Omni2–3× 工程生产力。用 Slack 展示全员原型，让工程师直接参加客户访谈；产品侧借鉴文件式上下文和并行 Harness。
13. Parahelp非技术角色直接交付 UI。工程师加速的同时，非技术联合创始人也开始直接提交 UI 修改和其他产品改进。
14. Translucent多视角 Code Review + Agent 市场。内部审查 Agent 并行检查同一改动并合并结论；工程、交付和销售分别使用专属 Agent。
15. Zingage567 行团队不变量。Claude 产出的代码看似合理却偏离架构后，团队写下问题框架、不变量和证明方式，约束每次会话。

规则一：把 0→1 交给最懂问题的人

“Everyone ships”开放的是工作原型和第一版 PR。市场、法务、销售、医生可以直接把领域知识做成可运行方案；设计师、工程师、安全与合规负责人继续处理各自的专业环节。

Heidi 的联合创始人 Thomas Kelly 把旧流程称为“传话游戏”：提出想法的人先告诉产品经理，产品经理再告诉设计师，最后转给工程师。几周之后，交付结果可能已经偏离最初的问题。Claude Code 允许问题拥有者先做出 PR，再邀请设计和工程人员处理体验、架构与生产化。

要让这种做法成为团队机制，需要同时建立三条通道。

1. 连接工作所需的事实源

员工频繁把数据库、CRM、文档或监控信息复制进 Claude，说明 Agent 与事实源之间缺少连接。

• MCP 适合把 Claude Code 接到工具、数据库和 API，并为团队提供统一的集成方式。
• CLI 适合已经拥有成熟命令行工具的场景。官方 PDF 列出的例子包括 gh、kubectl、bq 和 psql；这些工具能让 Claude 使用工程师正在使用的同一套真实数据，有时也比额外搭建 MCP 连接更省 Token。

Crosby 直接把 Claude Code 接进律师熟悉的工具和操作系统，省去了额外学习工程工作台的步骤。选择连接方式时，可以先查一个简单信号：团队是否每天都在为同一个流程复制粘贴信息。

Anthropic 原图。MCP Connector Directory 展示 Claude Code 可连接的外部工具；界面会随产品更新，正文保留的是 MCP 与 CLI 的选择原则。

2. 给原型安排评审入口

原型需要进入优先级、资源和正式路线图。Clay 每季度集中评审员工提交的原型；一名市场团队成员由此做出了自动访问网站、填写获客表单、计算响应时间并生成体验报告的 Agent。Omni 建立了专门的 Slack 频道，让所有人展示 Claude 生成的原型。

Omni 还让工程师直接参加客户访谈。原型展示解决内部发现问题，客户交流补上外部反馈，两者一起缩短从想法到修正的周期。

3. 共享团队规则和工作流

贡献者增加后，设计系统、数据库位置、代码约定和审查标准需要成为共享资产。

• 子目录里的 CLAUDE.md 保存该目录每次都要遵守的编码约定。
• Skills 保存按需调用的操作流程，例如生成报告、执行迁移或检查合规项。
• 共享目录或公司插件市场负责分发 Skills，让一名员工验证过的做法可以被其他人复用。
• 官方 PDF 还把 /init 作为生成初始 CLAUDE.md 的常见入口，用来记录构建命令、项目布局和约定。

Emergent 把 Skills 仓库当作共享知识库，保存数据库位置、Schema 和公司背景。它允许上下文文件存在少量滞后，同时要求 Agent 能查询事实并修正。Translucent 则按工程、交付和销售等角色建立内部 Agent 市场。

本章的验收标准很具体：问题拥有者可以独立做出可评审的原型；原型有固定展示和优先级入口；团队约定来自共享文件；生产合并仍经过专业审查。

规则二：自动化输入明确、结果可检查的机械工作

原材料用“机械 80%”描述 Agent 的职责。适合优先自动化的任务通常具备四个条件：重复发生、输入可取得、结果可检查、失败可以安全升级给人。

从软件生命周期开始

受访公司把 Claude Code 接进了多个 SDLC 环节：

• 环境初始化。 Emergent 的新员工把 Claude 指向一份 Markdown 文件即可初始化开发环境；遇到失效步骤时，Claude 会更新这份文件。
• PR 审查。 Claude Code 的 Code Review 在原材料发布时属于 research preview，可对指定仓库的 PR 做自动审查。开发者可以手工修复，也可以在配置 GitHub Actions 后对发现评论 @Claude，让它继续处理。
• 合规检查。 Heidi 用已经审定的技术和合规框架检查改动，先标出严重问题，再把建议交给合适的审阅者。
• 多角度审查。 Translucent 的内部代码审查 Agent 会从多个角度展开检查，再把结果合并成接近高级工程师审阅方式的报告。
• Bug 分诊。 Clay 的 Agent 从第一轮分类一直做到提出代码修改建议。
• 测试与覆盖率。 ClickHouse 设计了两个专用 Agent，分别修复 flaky tests 和寻找缺失测试覆盖；它们已经成为仓库第 2、第 3 大贡献者。

Anthropic 原图。Code Review 给 PR 中的发现标注严重级别，并允许开发者继续交给 Claude 处理；原材料发布时该功能处于 research preview。

Commure 提到，一名工程师曾并行推进约 13 个 ticket，每个 Subagent 负责一个 ticket 和对应 PR。并行任务需要清楚的所有权和验收条件。多个任务频繁修改同一状态时，合并冲突和返工可能抵消并行收益。

把 Agent 放进持续运行的值班流程

Anthropic 自己的 Claude Tag 展示了另一种自动化形态。它拥有独立服务账号，可以读取 Datadog、Grafana 等 CI 工程工具；固定操作说明作为 Skills 保存在 Git 仓库中，团队用代码审查方式维护这些说明。

在 Anthropic 的内部流程中，Claude Tag 会为近期有情况报告的事故先写第一份报告，通常在 15 分钟内发布初步分析。

Anthropic 原图。Claude Tag 读取真实监控工具，在 Slack 事故线程里持续更新调查进度；团队成员可以在同一线程纠正方向。

从研发扩展到批量信息工作

原材料列出的非研发场景包括：Clay 的内部分析 Agent；Heidi 对客户和临床人员反馈进行分类；Crosby 用 Subagents 汇总数千份法律文件；Commure 扫描索赔数据寻找跨站点异常；Translucent 持续分析医院财务数据中的风险信号。

Dynamic workflows 可让多个 Subagent 并行分析大量材料，也可以安排一个 Agent 对另一个 Agent 的结果做对抗审查。批量执行前应先固定输入范围、输出格式、合并规则和失败升级条件。

本章的验收标准：自动化有明确起点、停止条件和负责人；结果进入可见的审查或监控系统；异常不会被静默吞掉；工程师能把时间转给架构、复杂异常、合规和客户问题。

规则三：先建立验证系统，再扩大 Agent 权限

Agent 的自主范围应当受验证能力约束。Zingage 曾给 Claude 很大自主权，得到的代码表面合理，却逐步偏离团队架构。团队随后把问题框架、不变量和证明方式写成 567 行说明。

把不能漂移的内容写进根目录

根目录 CLAUDE.md 适合保存架构规则、安全边界和其他不可协商项，因为 Claude Code 会在每次会话开始时读取它。局部代码约定放在对应子目录，按需流程放入 Skills，固定执行的硬门禁交给 Hooks。

为长任务设置循环和停止条件

Loops 让 Agent 重复执行任务，直到满足条件或达到轮次上限。Flaky test 修复是一个合适例子：失败信号明确，Agent 可以修改后重新运行同一个测试。停止条件含糊的任务不适合直接进入长循环。

Anthropic 原图。循环能持续运行的前提是 Evaluator 可以检查目标，并在未满足时给出继续工作的信号。

在该 PDF 的 2026 年 8 月产品语境中，Dynamic workflows 用来安排确定性顺序、隔离上下文和聚焦目标；/goal 被推荐给容易提前宣布完成、在自审时偏向自身结论或逐渐偏离目标的长任务。具体命令可能随 Claude Code 更新，使用前应以当前官方文档为准。

用人工纠正改进原则

Cainex 的医疗编码流程展示了一个完整验证循环：

1. Agent 处理一批医疗记录，审计员在内部应用中查看编码和推理。
2. 每条纠正按诊断、手术等错误类型标记，所有输入、输出、评论和说明版本都可以审计。
3. Claude Code 找到产生错误的指导部分，修订通用原则；遇到新类型时新增指导。
4. 候选修改先在失败记录上重跑，再进入黄金集和随机样本。
5. 医疗编码可能存在多个有效答案，因此验证结合语义匹配和 Judge，判断差异属于错误还是另一条合理路径。
6. 回归被拦截；无法解决的记录和待确认问题进入人工队列。

Cainex 给这套方法定了一条规则：修原则，不修例子。 它的第一版曾把具体病例直接编码进规则，补丁越积越多。后来团队限制单次修改能写入多少具体细节，迫使系统归纳更通用的指导。

Anthropic 原图。一次 Agent 评测需要保留任务、试验过程、最终环境状态、评分器和跟踪指标。

建立分层验证

• 确定性检查： Lint、类型检查、单元测试、静态分析和安全扫描。
• Hooks： 在 Claude Code 生命周期的固定位置执行，每次都会触发；可阻止未通过 Lint 的写入、要求测试通过后才能提交，或在数据离开沙箱前去除密钥。
• 用例评测： 为每个关键用例维护多套评测，定期加入新失败、边界输入和模型升级后的回归样本。
• 黄金集与随机样本： 黄金集守住已知正确行为，随机样本帮助发现团队没有预先写进测试的变化。
• 人工升级： 高风险、模糊或存在多个合理答案的案例由领域专家处理。
• 真实结果检查： Agent 声称任务完成后，还要检查数据库、文件、服务或用户状态是否真的发生了预期变化。

权限扩大的前提可以写成一句操作规则：测试能覆盖到哪里，Agent 就运行到哪里；验证不到的部分留在人工审批之后。

规则四：用 Worktree、评测和清理降低重建成本

模型能力和 Agent 架构持续变化，早期为能力缺口搭建的复杂脚手架可能很快过时。Clay 的做法是反复重建同一个功能，在多轮实现中补齐对问题的认识。Harvey 提到，新的推理、自动化、规划和编排能力曾要求平台重新设计；Cognition 则判断，今天完成的 AI 系统可能在六个月到一年后被废弃。

Cognition 谈的是 AI 系统和架构寿命：今天搭好的系统，六个月到一年后就可能被新能力淘汰。

一个安全重建流程包含四个动作：

1. Worktree 隔离。 v1 继续在主工作目录运行，v2 使用独立目录和分支。多个 linked worktrees 共享同一个 .git 对象库，不需要复制全部仓库历史。

Anthropic 原图。三个 worktree 使用独立目录和分支，同时共享仓库历史；这种隔离让新版试验不干扰当前版本。

2. Plan Mode 先审方案。 对复杂重写使用 --plan 或 Shift+Tab，先让 Claude 探索代码库并提交方案。团队在改代码前检查依赖、迁移、权限和架构边界。
3. 同口径评测。 v1 和 v2 使用同一套任务、数据、评分器和成本指标。v2 在关键指标上胜出后再合并。
4. 删除旧路径。 清理已经全量发布的 feature flags、旧代码和旧迁移。两套路径长期并存会增加测试面、认知负担和事故风险。

Commure 把清理也做成了 Skill：扫描已经对所有用户发布的 feature flags，为相关标记和代码分别开 PR，再由工程师审阅。以前消耗大量开发周期的迁移，现在可以通过计划和并行执行在数小时内完成。

本章的验收标准：旧版始终可用；新版改动被隔离；两版比较使用同一口径；合并具有明确胜出条件；旧路径在迁移完成后被删除。

规则五：内部 Agent 经过 dogfood，再考虑产品化

受访团队反复采用一条路线：用 Claude Code 建内部 Agent，在团队日常工作中使用，再根据反馈决定是否做成客户功能。内部使用同时承担产品研究和故障定位。

• Omni 从 Claude Code 的文件式上下文获得启发，减少了一套复杂 RAG 管线；它还把 Harness 的并行工作方式借鉴到产品界面。
• Emergent 在产品行为异常时，用 Claude Code 本地复现，帮助团队区分模型行为和自身 Harness 问题。
• ClickHouse 用 Claude Code 构建和迭代 SQL 控制台 Agent 与 AI SRE，这些 Agent 会直接服务客户。

官方 Checklist 没有列出第五章条目。下面五步根据正文案例整理，属于本文的实施归纳：

1. 选择团队内部持续发生、结果容易观察的问题，先做内部 Agent。
2. 让真实用户在真实权限、数据和工作节奏下使用，记录成功、失败、人工接管和停止原因。
3. 把失败分成模型、提示与规则、Harness、数据、权限、界面和运营支持等类型。
4. 提炼跨用户、跨输入仍然成立的能力，并补上客户场景需要的隔离、审计、解释、支持和合规要求。
5. 在稳定能力得到重复验证后，再决定接入 Claude API、SDK、Managed Agents 或其他生产方案。

内部工具可以依赖团队默契，客户产品需要明确合同。产品化决策应基于真实使用记录和失败分布，不能只看一次演示效果。

官方 Checklist：四章十一项操作

官方 PDF 第 26 页把前四章的技术提示汇总成一页。以下按原范围翻译整理：

Anthropic 官方 PDF 原页。清单共有四章十一项；第五条规则没有单独的 Checklist 章节。下文提供完整中文整理。

Chapter 1 · Everyone ships

• 通过 MCP 或 CLI 把 Claude 接到团队每天使用的事实源和工具。
• 建立公司插件市场或共享目录，通过 Skills 分发最佳实践；子目录 CLAUDE.md 保存持续生效的局部编码约定，Skills 保存按需流程。

Chapter 2 · Automate Tedium

• 在仓库启用 Code Review（当时为 research preview），自动审查 PR。
• 把 Claude Tag（当时为 public beta）接入 CI/CD 值班响应和 Bug 分诊。
• 使用 Dynamic workflows 并行分析大量数据，或对另一个 Agent 的工作做对抗审查。

Chapter 3 · Trust, but verify

• 把不能变化的架构、安全和项目规则写进根目录 CLAUDE.md。
• 对停止条件清楚的长任务使用 Loops。
• 建立 Agent 评测的创建、维护和更新流程。
• 在必须确定执行的环节使用 Hooks 作为硬门禁。

Chapter 4 · Build for rebuilding

• 使用 Git worktrees 隔离重建，保持当前版本不受影响。
• 复杂重写先进入 Plan Mode，审阅方案后再开始改代码。

第五章没有出现在官方 Checklist 中；这应被视为原材料的编辑缺口，不能自行补成“官方第十二项”。

两周起步方案：先做一个可验证闭环

小团队可以把五条规则压缩成一次两周试验。目标是交付一条可运行、可验收、可复盘的工作流，不追求“无人值守公司”。

第一周：连接、规则和原型

1. 选一个每周重复、当前依赖复制粘贴、失败成本可控的任务。
2. 写清输入、预期输出、停止条件、人工负责人和禁止动作。
3. 有成熟 CLI 就先让 Claude 使用 CLI；缺少统一集成时再评估 MCP。
4. 根目录写入安全和架构底线，局部规则放进子目录 CLAUDE.md，操作步骤放进 Skill。
5. 做出原型，并安排一次由任务使用者、工程师和风险负责人共同参加的评审。

第二周：验证、运行和复盘

1. 加入 Lint、测试或其他确定性检查；必须执行的检查配置成 Hook。
2. 准备一小组已验证样本，再加入随机样本和过去真实失败。
3. 运行多批次，记录成功率、人工接管、成本、耗时和错误类型。
4. 把一次失败修成可复用原则，重新跑全部样本，检查是否出现回归。
5. 根据验证覆盖调整权限；适合并行的独立任务再引入 Subagents 或 Dynamic workflows。

两周结束时，团队至少应留下六件东西：一个工作原型、一份事实源连接说明、一组 CLAUDE.md/Skills、一套验收与评测样本、一条人工升级路径、一份运行与失败记录。这些产物决定下一轮应扩大自动化、继续修正，还是停止该方向。

继续阅读Anthropic AI原生创业手册：四段主线 + 退出标准，附全套可直接抄的提示词36 页官方手册拆开四阶段的毕业标准、常见陷阱与对应 Claude 提示词，可直接照抄使用→