如何打造AI原生公司

一家公司在产品里塞了几个 AI 功能，那叫 AI 转型。把开会、交付、审核、推翻重来全部重写一遍，才叫 AI 原生。 这个区分不是我下的，后面会说它从哪儿来。先看一份材料：8月20日，Anthropic 在官方博客上放出一份给创业公司的 Claude Code 指南，署名作者 Michael Segner。他们访谈了十几家高速增长的创业公司，问的是这些公司怎么用智能体编程造产品、扩团队。

指南原文页面。副标题写明了它的来路：五条运作原则，来自对十几家公司的访谈。发布于 2026 年 8 月 20 日，作者 Michael Segner

回来的数字里最扎眼的一个，来自安全公司 Artemis Security：每周六千多个代码合并请求。

代码合并请求是这行的说法，意思是有人改完一批东西提交上去、等人审过再并进产品，可以粗略理解成一次交付动作。一周六千多次，平均每个工作日一千两百次。

指南开头还列了另外三组：数据库公司 ClickHouse，交付的功能多了三成；商业智能公司 Omni，工程效率是原来的两到三倍；销售数据平台 Clay，报上来的问题百分之百由机器先分诊——判断该不该修、归谁修。

四家公司交出的数字。数据来源：Anthropic 创业公司指南，2026 年 8 月

这几家都不是巨头。Anthropic 的原话是，它们的交付节奏像十倍于自己规模的组织。

数字之外，Artemis Security 联合创始人兼首席执行官（CEO）Shachar Hirshberg 有一句话，我读了两遍：

所有人都在抢着造 AI 产品，很少有人在重造公司本身的运行方式。后面这件事才是更大的解锁。Artemis Security 是作为一家 AI 原生公司在运转，而不是一家恰好用了 AI 的公司。

开头那个区分，就是从他这句话里来的。它把"AI 原生公司"这个被用滥的词按回了地面。而这份指南真正的价值还不止五条规则，它顺手回答了另一个问题——如果一家公司从第一天就按智能体的方式搭建产品开发流程，它会长成什么样。

下面是我读完的拆解，以及一个中国公司必须提前知道的问题：这套东西搬回来，会在哪儿断。

医疗记录公司 Heidi 的联合创始人兼 CEO Thomas Kelly 用了一个我见过的最准的比喻。

Claude Code 解决了我们的传话游戏问题。一个新想法过去是这样流动的：有想法的人告诉产品经理，产品经理告诉设计师，设计师再告诉工程师……想法的精髓在这条链上必然会丢。等东西上线，往往已经不像最初那个人脑子里的样子了。而且要几周。

传话游戏小时候都玩过。一句话在几个人耳朵里过一遍，出来就变了形，大家哈哈一笑。公司里天天在玩这个游戏，只是没人笑——变形的是产品，笑的是对手。

上排是传话链条：想法从"有想法的人"起，经产品经理、设计师、工程师逐级转述，光球一路衰减，最后交付出一个破损的盒子，耗时几周；下排是直接交付：最了解问题的人一条直线走到完整产品，设计师和工程师只在需要判断的地方接入，当天完成

这条链上每转一手，都要付一次学费。提出想法的人往往是最懂那个问题的人，可他偏偏不是动手做的人。等做的人拿到需求，手里只剩一份被转述过三次的描述。

智能体编程把这条链压短了。Kelly 接着说：真正理解这个问题的人可以自己提一个代码合并请求，只在需要专业判断的环节把设计师和工程师拉进来。

法律科技公司 Crosby 的联合创始人兼 CEO Ryan Daniels 说得更直白：

Claude Code 改变了在 Crosby 当律师意味着什么。律师们有最好的产品洞察，因为他们就是用户。看他们开工是件很过瘾的事。

客服智能体公司 Parahelp 的联合创始人 Mads Lunau Liechti 干脆拿自己举例：不只是工程师交付得更多了，像我这样的非技术人员也突然开始改界面、提产品改进了。

到这里要泼一盆冷水。"人人都能交付"写成朋友圈文案很好看，落到地上是什么样子？市场部真的在审代码合并请求吗？法务真的在排查那种时好时坏的测试吗？

Anthropic 得到的答案是：分工没有消失。做市场的还是做市场，写代码的还是写代码。变的只有一段——从零到一那一步，向所有人开放了。

这一段恰恰是最贵的。我以前讲组织进化时说过，从零到一靠的是原创能力，从一到一百靠的是复制和协作能力。过去公司里的绝大多数人被卡在"我有个想法"这一格，因为下一格需要一张他没有的门票：会写代码。在这些公司里，这张门票被印发给了每一个人。

Clay 走得更远，干脆把这件事写进了招聘标准——注意那是招人的口径，不是分工的口径。联合创始人兼 CEO Kareem Amin 说：

我们不但不躲着让非技术员工参与，我们是主动往那个方向走的。我们的看法是，每一个岗位都在变成工程岗位，因为你能为它造软件……所以我们招那种爱折腾、对造东西有兴趣的人。

律师能交付，靠的不是律师突然学会了写代码。

Crosby 的做法是反过来的：他们没有把律师请到 Claude Code 面前，而是把 Claude Code 接到了律师每天在用的那些工具和系统里。

这是原文里我认为最容易被忽略、也最容易做错的一条提示：Claude 看不见的东西，它就理解不了。

具体到手段有两种。一种是 MCP（模型上下文协议），一个开源标准，把工具、数据库、接口接给模型。判断什么时候该接：当你的团队开始频繁地从某个工具里复制粘贴信息到对话框，那个工具就该接进来了。另一种是命令行。如果这件事已经有成熟的命令行工具（查数据库、看服务器状态那些），直接让模型用命令行更省钱，而且它看到的和工程师看到的是同一份真相。

Claude Code 桌面端的连接器目录（原始截图）。列表里是员工每天在用的东西——云盘、日历、设计工具、办公套件、聊天工具。打上勾就是已接入，接上之后模型才看得见这些地方的真相

想法能被做出来，只是第一步。想法还得有机会被排上优先级，否则就是一堆自娱自乐的原型。产品经理有这条路——那本来就是他的活。非技术岗的人没有。

所以这些公司都在造入口。

Clay 设了季度评审，原型在这里被审议，通过的进入正式路线图。Clay 一个做市场增长的同事就是这么造出了一个智能体：它会自己访问你的网站、填写你的线索收集表单、给你的响应速度计时、给这次体验打分，最后生成一份报告。

Omni 开了一个专门的 Slack 频道，谁做了 Claude 生成的原型都往里发，包括资深技术骨干。他们还做了这件事的反面：人人交付的配套是人人跟客户聊天。联合创始人兼首席技术官（CTO）Chris Merrick 说，工程师天然不爱参加客户电话，Omni 就故意把他们推到客户面前，因为这样反馈闭环转得更快。

门槛降低有代价。人人都能交付的另一面，是产品变成一盘散沙。

无论原型来自谁，最后都要拼进同一个产品里，还得让人感觉是一个整体。指南里给的解法叫 skill，可以叫它技能文件：把团队的标准、规矩和背景写进一个文件，谁开工都先读一遍。

Heidi 的 Kelly 说，团队里任何人都能拿他们的设计系统当参照，从 Claude Code 里起草产品组件、市场物料或者演示材料；但凡碰到产品本身的 AI，要过高得多的门槛，而 Claude Code 帮他们把这道门槛守得更精确。

应用构建平台 Emergent 的联合创始人兼 CEO Mukund Jha 描述了他们的做法：

我们有一个放 Claude Code skill 的 GitHub 仓库，当共享知识库用，能快速把一次会话引导到 Emergent 的已知信息上，比如数据库和数据仓库在哪、部分表结构、公司整体背景……与其在这上面追求完美，不如接受上下文文件稍微过期一点，只要智能体能快速核对并自我纠偏就行。

最后半句值得单拎出来。国内公司做知识库，我见过的多数死在追求完美文档上：立项、评审、模板、责任人、季度更新，然后半年后没人看。Emergent 的判断是相反的——文档可以脏，只要读它的那个东西有能力当场核对。这是一个只有在有了智能体之后才成立的判断。

Emergent 还有一条更狠的：新人入职第一天，把 Claude 指向那个 markdown（一种纯文本文档格式）文件，整套开发环境就自己跑起来了。如果 Claude 在这个过程中撞见任何坏掉的或过期的内容，它顺手把那个文件改掉。

文档从给人看的，变成给机器执行的。连修文档也不用人动手了。

财务 AI 公司 Translucent 的创始人兼 CEO Jack O'Hara 走得更远：他们的工程师用 Claude Code 搭了一个内部智能体市场，按角色组织，工程、交付、销售各自拿到为自己实际工作方式定制的工具。

这些做法背后是同一件事，我把它叫做可以被编译的共识。

左边是"贴在墙上"：公司规矩挂在墙上，靠人一层层往下传，每一环打折；右边是"写进仓库"：把"什么必须永远成立"写成规范文件，每次开工先读一遍，谁来做都一样

传统公司的共识贴在墙上、印在员工手册里、藏在老员工的脑子里。它要靠人一层层传下去，每一环都打折。AI 原生公司的共识写成文件，放在仓库里，智能体每次开工先读一遍，然后照着做。前者是标语，后者是可以被编译的。

我自己有一份小样本。这个写文章的项目，根目录的规范文件到今天是 282 行，里面写的全是教训：微信编辑器会丢弃某类标签的样式，所以容器只能用某一种；表格表头不许用深色底加白字，因为渲染可能丢背景色导致白字看不见。这些都是我们踩坑踩出来的，现在每次开工模型自己读一遍，不用我再交代第二遍。

多位创始人给出的说法几乎一致：让智能体拿走机械的百分之八十，工程师的时间只花在真正需要判断的那部分上。

这句话听着像口号，直到你看到 ClickHouse 的数据。

联合创始人兼 CTO Alexey Milovidov 说，他们几乎把研发生命周期的每一个环节都变成了自主循环。两个专门造出来的智能体——一个修随机失败的测试（就是时好时坏、重跑一次又能过的那种，最烦人也最没人愿意修），一个找测试没覆盖到的地方——现在是 ClickHouse 仓库的第二和第三大贡献者。另有一族智能体负责运维，而这些智能体本身，是团队用 Claude Code 造和迭代的。

一个开源数据库项目，贡献榜前三名里两个是机器人。

医疗平台 Commure 的 CEO 兼创始人 Tanay Tandon 给的是另一个画面。他嘴里的"子智能体"，是主模型派出去的一批分身，各干一摊：

我们这儿的工程师在指挥智能体舰队，当天发现的生产数据问题当天修完，同时推进多个代码合并请求。有位工程师用一组并行的 Claude 子智能体跑了一个大约十三张工单的计划，每个子智能体自己负责一张工单和它对应的合并请求。

Anthropic 也把自己的家底掀了。他们把 Claude 挂在聊天工具里当值班机器人用（产品名叫 Claude Tag），已经顶了几个月 CI/CD（代码改完自动测试、自动上线的那条流水线）的一线值班：最近每一起有情况报告的事故，第一份报告都是 Claude 写的，通常在十五分钟内发出。它有自己的服务账号，能用 Datadog、Grafana——持续集成工程师盯线上要用的那些监控工具。值班规程写成 markdown 当 skill 提交在 GitHub 仓库里——这样多个同事可以一起迭代，而且改动可以像管代码一样管。

Slack 里的值班现场（原始截图）。有人 @Claude 说结账失败率从 0.3% 跳到 6%，Claude 挂上"值班中"的标记，逐条回报它已经做完的事：拉取了当次发布的代码差异、查了监控发现 502 集中在购物车服务、关联到数据库连接池超时暴涨五倍、按地区比对了错误率，最后一行是"正在写根因小结和回滚建议"

值班手册进了版本控制。这个细节比任何一个效率数字都更能说明"AI 原生"是什么意思。

Translucent 的 Jack 说他最喜欢的智能体是"Translucent 代码审查员"：它对着一次改动同时开好几路，各从一个角度审，再把结果汇总，像他们的资深工程师那样，但比任何一个人都快。Clay 则造了一个智能体接手缺陷分诊，从第一轮判断一直做到给出修复的代码建议。

这些循环也不只在研发里。Crosby 用子智能体总结几千份法律文书，Commure 扫理赔数据在多个站点之间找异常，Translucent 持续挖医院的财务数据找预警信号——按原文的说法，那是任何分析师团队都来不及发现的。

这一条是上一条的必要配套。一个流程只有在你能可靠地监控和验证结果时，才谈得上自动化。

开头那个每周六千多次交付的数字，底下是有东西撑着的。Artemis Security 的联合创始人 Dan Shiebler 说，他们提速能成，是因为在测试基础设施、代码库组织和团队知识系统上投入很深，深到智能体可以端到端地交付。他把这叫飞轮：把代码库、知识库和团队按对的方式组织好，之后每一次贡献都会累加。

居家护理软件公司 Zingage 的联合创始人兼 CEO Victor Hunt 讲了他们的翻车：

早期我们给了 Claude 完全的自主权，然后它做了 AI 会做的事。它飞快地交付了看上去合理的代码。问题是它偏离了我们的架构，而且偏离的方式看起来是对的，其实不是。所以我们……把每一条不变量都写了下来。我们怎么定义问题。什么必须永远成立。怎么去证明一个东西真的能用，而不是听信一个自信的回答。567 行，写的是这个团队怎么思考。

567 行"这个团队怎么思考"。这是我在整份指南里最想请你记住的一个数字。

它的对照面是这样的：很多公司的架构原则和安全红线，从来没有被完整写下来过。它们活在两三个资深工程师的脑子里，靠代码评审时的一句"这样不行"传递。这套机制对人勉强够用，对智能体完全无效——模型每次开工都是新人，你不告诉它，它就按最合理的样子来，然后飞快地交付一堆看起来对的东西。

指南给的操作很简单：把不能变的东西放进仓库根目录的规范文件里。模型每次会话开始都会读，架构规则、安全边界、不可谈判的底线，就跟着每一次会话走。

医疗编码公司 Cainex 是最有说明性的一个例子。他们的智能体读病历、生成医院账单用的编码。联合创始人兼 CTO Uriah Israel 一句话定了他们的建设方针：

在医疗编码里，一个错误的编码不是笔误，它是一个账单事件和合规事件。这一个事实决定了我们怎么造东西。

他们的闭环是这样跑的。智能体批处理一批病历，人类审核员在内部应用里审。审核员看到的不只是编码结果，还有模型的推理过程，两样都可以评论。所有东西带版本，可审计。

然后 Claude Code 接手。它从数据库里直接读原始预测，连同每一条修正和评论一起读。每条修正都按涉及的编码类型打了标签，所以 Claude Code 知道自己面对的是诊断问题、操作问题还是别的类别，可以直接去找管这类编码的那份规范。

接下来是关键动作：它找到智能体指令里导致这个错误的那一段，改掉；如果这个案例是全新的，就写一条新指引。每一次改动都是针对一套带版本的指令做的，并且要拿失败过的那些病历重新测。

最后是回测。同一份病历可能有不止一种合法编码，所以不能拿字符串直接对。他们的办法是先跟已经认可的编码做语义比对，再让另一个模型当裁判，专门判"这到底是个真错误，还是另一条同样成立的路径"。改动上线前要在一套黄金测试集里跑一遍——那是一批已经确认过正确答案的病历，专门用来验有没有把原本做对的做错——再加上随机抽样，任何退步都会当场暴露。最后交到工程师手上的是一份短清单：建议的修改、它搞不定的病历、它想问的问题。

Uriah 还老实交代了第一版是怎么错的：

一开始没这么干净。我们的第一版过拟合了。它"修复"问题的方式是把那个具体案例编码进去，我们在积累补丁，而不是在变聪明。后来我们改了做法，强制它总结成通用原则，并且限制一次改动最多能塞进多少具体细节。

积累补丁，而不是变聪明。这句话可以直接贴在很多技术团队的墙上——不用 AI 也一样适用。

循环是怎么跑的：先给一个带停止条件的目标（比如"修好随机失败的测试，最多试五次"），智能体干活，评审模型检查条件——没达标就退回重做，达标或者用完次数才结束。根据 Anthropic 指南原图重绘

视频生成公司 Higgsfield 的联合创始人兼 CEO Alex Mashrabov 从另一个角度讲了验收的价值：新的视频和图像模型不停地来，每一个都要配新的技能文件、新的评估、新的分派规则（哪种活交给哪个模型）和生产测试才能上线。Claude Code 把这个周期从几天压到了几小时，让他们能在生产环境发现问题、同一次会话里就把修复发出去。他补了一句：当你在跟人头是你十倍的公司竞争，这种杠杆能改变一切。

指南里还有一条容易被跳过的提醒：智能体本身不是确定性的，但很多强监管的活要求每次都用同一种方式做完。解法叫钩子（hooks）——你事先钉死的一道卡口，到那个点就自动执行，模型绕不过去。它可以拦住一次没通过检查的改动，可以要求测试通过才允许提交，可以在任何东西离开隔离环境之前先把密钥抹掉。

我在这个写作项目里也放了一道这样的闸。推送草稿前必须跑一个 434 行的检查脚本，退出码非零就不许发。它管的是模型凭语感必错的东西，比如文章里写"九个字"，那句话到底是不是九个字。这类错误人眼扫读根本发现不了，而模型看到的是 token（模型切分文本的最小单位）不是汉字，写"九个字"的时候它是在估，不是在数。这道闸不需要模型同意。

这些公司里很多都处在持续自我推翻的状态。

AI 既是它们造的东西，也是它们造东西的方式。模型能力一直在变，所以昨天还惊艳的功能、辛苦搭的脚手架，一旦变成沉没成本就被扔掉。不少公司把这种反复重建当成自己的竞争优势。

Clay 的 Kareem 说：

我们在 Clay 的做法是，你造一遍，然后再造一遍，然后再造一遍。等你造第四遍的时候，你已经知道全部需要什么了，你就把它做对了。所以我们也不算是扔掉东西，我们只是重建它，而这次带着更多的清楚。

Commure 的 Tanay 补上了最扎心的一句：

一次重建不是新路径上线就算完成，是旧路径被删掉才算完成。以前拆除永远打不赢优先级评审：它又琐碎，又不产出任何新功能。

这句话我读了三遍。任何一家有点年头的公司里，都堆着无数条本该被删掉却还在跑的旧路径。它们不出故障，也没人敢动，因为拆除在任何一张 KPI（绩效考核指标）表里都是零分。

Commure 现在的做法是：一个工程师调用一个 skill，大意是"把所有已经全量放开的功能开关，连同相关代码，逐个开代码合并请求删掉"，然后人来审返回的结果。以前要吃掉大量开发周期的迁移，现在是一个计划加一次派活——一口气派出去一批分身，几个小时搞定。

拆除的成本一降，"该删的删掉"才真的排得上号。

法律 AI 公司 Harvey 的应用 AI 负责人 Niko Grupen 在今年五月的一场活动上说：

如果你六个月前问我我们的架构长什么样，我给你的答案会和今天完全不同。如果我们当时不肯说"这套得扔了，我们要变成智能体原生"，我们的平台现在根本不可能有这些能力。

同一场活动上，Devin 的开发商 Cognition 的联合创始人 Walden Yan 说得更彻底：现在做 AI 的生活方式，就是接受你今天造的东西很可能在半年到一年内被扔掉；Devin 用两年前的模型根本做不出来，但当时的赌注是——今天可能不成，但很快会成。

让"造四遍"变得便宜的是工具。指南给的办法是再开一份代码副本（git 里叫 worktree），在副本里跑重建，当前那份原封不动。你得到的是 v2 和 v1 并排跑着，各自跑一遍评估，新的赢了才合并。对于稍微复杂点的重写，先用计划模式让模型把仓库读一遍、提出重建方案，你批准或者掉头——那是拦住一次跑偏重建的最便宜的地方。

指南的最后一条讲的是一个飞轮：用 AI 造东西，帮它们造出用 AI 的产品。

当团队把智能体编程的功夫练深了，他们对模型能力的把握、对前沿 harness（给模型套的那副挽具，决定它能用哪些工具、按什么顺序干活）设计的理解也就跟着深了，然后把这些搬进自己的智能体和产品里。

Omni 的 Chris 举了个具体的例子：他们看到 Anthropic 用的是最笨的办法——让模型直接读文件，而不是先把资料切碎、编号、建索引再去检索——效果反而好，于是自己的产品也跟着保持简单，省掉了一整套检索系统本来会带来的复杂度。他们还看到 Claude Code 的 harness 让用户能并行做多件事，就把这个概念改造进了自己的界面。

Emergent 的 Mukund 说的是另一种好处：因为他们的应用构建器背后也在用 Anthropic 的模型，产品上一旦出现某种异常行为，他们能立刻在本地用 Claude Code 调一遍，判断这是模型行为还是 harness 的问题——这对他们的问题分诊周期帮助巨大。

ClickHouse 的 Alexey 把这个循环说圆了：

我们在自己产品里造了 AI 智能体让团队直接交互，包括 SQL（数据库查询语言）控制台里的智能体和一个 AI 运维工程师。我们用 Claude Code 来造和迭代这些智能体本身。给我们客户提供 AI 体验的那套工具，本身就有一部分是 AI 造的。

自己不天天用的东西，你不会知道它哪儿疼。这个道理在 AI 时代没变，只是变得更贵了——你少练一个月，对模型能力的判断就落后一个月，而模型每个月都在变。

上面这些做法很漂亮，但它们长在一片特定的土壤上：小团队、扁平、创始人自己写代码、犯错的代价是钱不是乌纱帽。搬回国内的组织里，我判断会在四个地方断。

第一个断点：没人给"第一版"的所有权。

在很多国内公司里，一个非技术岗的人绕过流程直接交付第一版，这不是技术问题，是政治问题。他会被问"谁让你做的"，而不是"这个想法好不好"。Clay 敢说"每个岗位都在变成工程岗位"，前提是它先接受了这个岗位边界的模糊。国内组织的边界通常比这硬得多，而边界越硬，传话游戏的链条就越长。

想解这个结，光发工具没用，得有一个明确的授权和一个明确的入口——Clay 的季度评审、Omni 的原型频道，那才是真正的机制。工具是谁都能买的，机制得自己建。

第二个断点：共识不写下来。

国内公司的共识多半没写下来，它活在会议和群聊里，靠老员工的经验兜着。这套东西传给人，还能靠会上一句"这样不行"补回来；传给智能体，连个补的口子都没有。我见过太多团队，一年开几百场会，却拿不出一份"什么必须永远成立"的文件。

Zingage 那 567 行是把一群人脑子里的东西倒出来，一条一条。这活儿没人替你干，也没有模板可套。

第三个断点：没有验收装置，就不敢放权。

这一条是我最担心的。没有黄金测试集、没有评估、没有硬闸，管理者能做的就只剩要求"AI 生成的必须人工审核一遍"。这句话听起来很负责任，实际效果是把 AI 变成一台打字机——所有的效率都在最后那道人工复核上还回去了。

Cainex 那一整套闭环，本质上是在造一件事：让审核员的功夫花在指令上，不花在单条输出上。做不到这一点，规模就永远上不去。

第四个断点：不敢扔。

Commure 那句"旧路径被删掉才算完成"，在国内环境里还要再叠一层难度。既有沉没成本，又有考核只认新功能，还有一层"这是某某当年主推的"。

有意思的是，AI 恰恰让扔东西变便宜了。当推翻重来的代价降到上面那个量级，"要不要推翻"这个问题的答案会自然改变。重建本身不难，难的是承认上一版该扔。

这份指南结尾附了一页清单。我按国内团队的实际情况重排了一下，如果只做五件事，我建议是这个顺序：

传话游戏之所以好玩，是因为最后一句话变了形，大家一起笑。公司里也天天在玩，区别是能笑出来的人都不在这家公司里。

"AI 原生公司"现在被用得很随便，几乎成了一句公关话术。我给一个更省事的判断方法：

写在墙上的，是给人看的，人会忘，会曲解，会走样。写在仓库里的，每一次开工都会被读一遍；再配一道不需要模型同意的闸，它才真的落得下去。那才叫可以被编译的共识。

不用等明天。今天就找你们最资深的那个人，让他把"什么必须永远成立"写下来。写不满一页纸的公司，先别急着说自己是 AI 原生。