Anthropic 的 CFO Krishna Rao 第一次公开上播客，就把公司的底牌摊了不少。

这期播客是 Patrick O'Shaughnessy 主持的「Invest Like the Best」，时长 82 分钟。两人从算力采购聊到定价策略，从融资故事聊到内部 AI 使用，从 Mythos 发布聊到公司文化，最后落到了一个问题：

“ 什么因素可能让 AI 革命踩刹车？

Krishna Rao 两年前加入 Anthropic 时，公司年化收入 2.5 亿美元。而到今天，这个数字是 300 亿美元。

两年，120 倍。

Krishna Rao 是谁

Krishna Rao 是 Anthropic 第一位 CFO，2024 年 5 月加入。

从履历上，他可以说是位跨界选手：哈佛经济学本科（最优等毕业），耶鲁法学院，贝恩咨询起步，后来去了黑石做私募股权投资。再往后转向科技行业，先是在 Airbnb 做全球企业发展主管，经历了疫情期间的融资和 IPO（Airbnb 七周内收入暴跌 70%，他帮公司筹了 100 多亿美元的股权和债务融资）。之后又分别在医疗支付平台 Cedar 和 Fanatics Commerce 担任 CFO。

到了 Anthropic……则是他职业生涯中最不可预测的一段。

在播客中，他讲了一个加入前的故事：Anthropic 首席算力官 Tom Brown 带他在旧金山 Mission 区散步，走了两个半小时，描绘了公司未来的愿景。回到家，他跟妻子说了一句话：

“ 如果这里面哪怕 10% 是真的，一切范式都会被打破。

结果……不止 10%，大部分都应验了。

算力这盘棋

Krishna Rao 说，哪怕到今天，他大概还是有 30% 到 40% 的时间花在算力上。

在他的描述里，算力是 Anthropic 业务的命脉，也是最难做的决策。买太多，公司会撑不住；买太少，既服务不了客户，也没法待在技术前沿。

两种结果其实是一样的：出局。

Anthropic 内部用了一个概念叫「不确定性锥体」（cone of uncertainty），来思考这个问题。当业务在指数级增长的时候，周度或月度增长率上一个很小的变动，复利之后会导致截然不同的结果。Krishna Rao 坦言，打破「线性思维」这件事，他自己也花了好一阵子。

“ 人类天然是线性思考的。我在公司两年了，才逐渐学会在指数增长的曲线上做判断。

在算力的「灵活性」方面，Anthropic 同时使用三个芯片平台：Amazon 的 Trainium、Google 的 TPU 和 Nvidia 的 GPU。三个平台被当作可互换的资源来用，训练模型、内部加速、服务客户三类需求跑在所有平台上。

为了做到这一点，他们投入了好几年的时间，从芯片层往上自建编译器。

早年 Anthropic 选择 TPU 时，行业里一片质疑：「你们疯了，大家都在用 GPU。」但 Krishna Rao 认为，今天 Anthropic 在每一美元算力上榨出的价值，应该比其他任何前沿实验室都高。

他还透露了一个细节：Anthropic 早上用芯片跑推理服务客户，到了下午或晚上，同一块芯片就切换去做模型训练。这种灵活调度的能力是传统企业无法想象的，就像你不可能让研发部的人白天搞研发、晚上去当客服一样。

惊人的 120 倍

整期播客中最惊人的数字之一，当属过去四个月的增长：2026 年初，Anthropic 的年化收入大约是 90 亿美元；到一季度末，已经超过了 300 亿。

Krishna Rao 把这种增长归结为一个核心命题：前沿智能的回报极高，尤其在企业市场。

他认为，人们倾向于把模型智能理解成智商，一个单一数字。但 Anthropic 的看法不同：智能是多维的。每次发布新模型，被解锁的市场空间（TAM）都是不一样的，更多的用例变得可行，更长时间维度的任务变得可能，Agent 能完成的工作也变得更快。

“ 如果两个员工一样聪明，一个花一周完成任务，另一个一天就搞定，那第二个人的产出是前者的七倍。模型也是同理。

在企业端，这个效应尤其明显。每一代模型发布后，客户都会用更多的 token、投入更多资源。从编程开始，但现在已经远远不止编程了。

模型在训模型

被问到「递归自我提升」时，Krishna Rao 确认了一个在行业内流传已久的数字：Anthropic 内部现在 90% 以上的代码是 Claude Code 写的。更进一步，很多 Claude Code 自身的代码，也是 Claude Code 写的。

这就是 Anthropic 愿意把一部分算力分配给内部使用、宁愿放弃短期收入的原因：模型正在帮助他们构建下一代模型。

不过他也强调，人才依然极其重要。

模型赋能了研发，但并没有完全取代研究人员。最顶尖的人才配上最强的模型，才能真正加速能力的突破。

Anthropic 内部常说的一句话是：

“ 人才密度比人才数量更重要。

至于 scaling laws 是否还成立，Krishna Rao 的回答是：「从我们看到的数据来说，scaling laws 没有在减速。」他特别提到，Anthropic 的创始人里就有好几位是 scaling laws 论文的作者，但即便如此，团队本质上是一群怀疑论者，会用科学方法不断挑战此前的假设。

千亿算力

播客录制当天，Anthropic 与 SpaceX 旗下 xAI 在 Memphis 的 Colossus 设施达成合作的消息刚刚放出。

Patrick 问他是怎么在全球范围内搜罗算力的。

Krishna Rao 透露，就在上个月，Anthropic 跟 Google 和 Broadcom 签了一个 5 吉瓦的 TPU 协议（2027 年开始），同时跟 Amazon 签了同等规模的 Trainium 协议。

这加起来，超过了 1000 亿美元的算力承诺。

Patrick 追问：如果明天凭空给你 2 倍的算力，能消化吗？10 倍呢？

Krishna Rao 说，一两年前，尤其是异构算力，可能还真消化不了那么快。但到今天，Anthropic 已经具备了快速启用几乎任何类型算力的能力。

给多少，就能吃多少。

他还特别提到，Anthropic 是目前唯一一个在三大云（AWS、Google Cloud、Azure）上都有部署的前沿模型，也是唯一一个同时使用三种芯片平台的语言模型实验室。跟 Amazon 的合作远不止采购，Anthropic 的团队深度嵌入了 Annapurna Labs（Amazon 的芯片团队），共同影响芯片路线图。

平台 or 应用

被问到平台和应用之间的取舍时，Krishna Rao 把 Anthropic 的定位类比为 AWS 的早期阶段。

大部分精力花在平台上：不只是原始的模型接口，还有 prompt caching、Claude Code、Dispatch、Agent SDK、托管 Agent 等一系列工具。这些都是让其他公司在 Anthropic 平台上构建产品的入口。

但在少数领域，Anthropic 也会自己做应用。

主要有两种情况：一是对模型未来方向有独特判断（Claude Code 发布时，模型还做不到那种程度，但他们赌对了），二是给生态做示范（Claude for Financial Services、Claude Security）。

策略上大部分是水平的，在少数有独特视角的领域做垂直。

Patrick 还问到了一个尖锐的问题：你的客户怕你吗？毕竟你控制着最底层的智能引擎。

Krishna Rao 的回应是：AI 模型的能力有时候连他们自己都会感到意外。

以前需要 5 年、10 年、20 年的产品迭代周期，现在压缩到了几个月。这对客户来说确实是冲击，但 Anthropic 的做法是尽量走合作路线，在安全、设计、金融服务等垂直领域都跟生态伙伴联手推进。

定价的学问

在所有前沿实验室都算力紧缺的情况下，为什么不大幅涨价呢？

Krishna Rao 的回答跟外界想的可能不太一样。

Anthropic 成立才五年多，第一美元收入是 2024 年 3 月挣的。定价一直比较稳定，Haiku、Sonnet、Opus 三条线几乎没怎么变过。

他们做过的最大一次定价变动，反而是降价：Opus 4.5 发布时，Opus 系列价格被砍了下来。原因是，Opus 级别的模型一直被严重低估，客户总是试图把 Opus 级别的问题硬塞给 Sonnet 来解决。

降价之后呢？消费量的增长远远超出预期。

经典的杰文斯悖论。

（杰文斯悖论：19 世纪经济学家杰文斯发现，蒸汽机效率提升后煤炭消耗不减反增——因为更便宜的能源催生了更多用途。放到 AI 语境下就是：模型越便宜，用户反而用得越多，总支出不降反升。）

Opus 4.6 发布时，价格没变，客户直接把新模型嵌入现有工作流。Krishna Rao 认为，定价的稳定性对客户来说至关重要，它让企业敢于把 AI 深度嵌入自己的业务。

至于利润率，他不认为传统软件公司的成本结构框架适用于 Anthropic。

他更看重的是「算力总投入的回报」：服务推理是短期收入，模型研发是 6 个月后的 TAM 解锁，内部加速是新产品上线。所有这些共同支撑收入，只是时间维度不同。

70 个 Claude 技能

播客中最值得注意的一段，大概是 Krishna Rao 描述自己的财务团队如何使用 Claude。

大约一年前，他发现团队已经不只是在用 Claude Code 写代码了，而是把它当成了一个数字同事。这其实，其实就是后来 Co-Work 产品的雏形。

而今天，Anthropic 所有法律实体的财务报表都是 Claude 生成的（人会复核）。他们还搭建了一个叫 AntStats 的实时分析平台。以前要花好几个小时才能从数据里得出结论、写一份报告，大约 30 分钟即可完成。

财务团队内部有一个 Claude 技能库，上次统计有 70 多个。

其中有一个月度财务评审（MFR）技能，Claude 生成的报告 90% 到 95% 可以直接用。团队的讨论从「到底发生了什么」变成了「这意味着什么，我们该做什么」。

另一个现象是：团队里最资深的人反而是 token 用量最大的。排名第一的用户是他们的税务主管，正在用 Claude 构建税务策略引擎，自动化了大量工作流。

Krishna Rao 表示：

“ 如果连我们自己都不是超级用户，都不在推这个工具的边界，怎么指望客户去做呢？

融资之仗

Krishna Rao 加入 Anthropic 两年来，帮公司融了约 750 亿美元。上个月跟 Amazon 和 Google 签的协议，还有约 500 亿会陆续到位。

但这条路走得并不轻松。

两年前关 Series D 的时候，Anthropic 刚刚才有了真正意义上的前沿模型，而且 FTX 的清算正在市场上抛售 Anthropic 的股份。

投资人的疑问五花八门：你们为什么需要前沿模型？AI 安全和做大生意不矛盾吗？你的销售团队那么小，不需要像传统企业软件公司那样扩张吗？

2024 年底融 Series E 时，业务已经接近 10 亿美元年化收入。但首次 close 那天，恰好……DeepSeek 的消息出来了。

一脚油门之后，立刻就来了一脚刹车。

投资人看着预测说：

“ 好吧，你们确实长得够猛，但不可能维持的，物理定律在那呢。

然而业务持续在证明之前的假设。

而且投资人也慢慢看到了一个他们之前不理解的关联：Anthropic 在安全领域的投入，反过来成了商业优势。

可解释性研究相当于给模型做 MRI，看清神经网络内部的运作，这让他们更擅长构建模型。而当卖给企业客户时（目前服务着财富 10 强中的 9 家），这些企业把最敏感的数据和工作流托付给 Anthropic，安全投入就成了信任的基础。

净美元留存率（Net Dollar Retention）年化超过 500%。

Krishna Rao 还提到了一个细节：他来录播客的路上，在 Uber 里签了两笔八位数的合同，车程大概 20 分钟。

公众认知的鸿沟

Patrick 提到了一个颇为尴尬的数据：AI 这个概念在普通美国人中的好感度，比国会还低。

Krishna Rao 认为，核心问题在于速度。

以前需要几年甚至几十年的进步，现在被压缩到了几个月。对于习惯线性思考的人来说，这确实会让人不适应。

他提到 Anthropic 内部有一个说法叫「light and shade」，光明与阴影并存。Dario Amodei 写过一篇长文「Machines of Loving Grace」，描绘了 AI 在药物研发、医疗、提升发展中地区生活水平方面的正面潜力。但与此同时，Anthropic 也在主动讲风险。

“ 如果我只跟你说好消息不说坏消息，你凭什么信我呢？

长期来看，机遇会远远大于风险。但这条路不会是一条完美的直线。

Mythos 发布

Mythos 的发布在行业内引发了不小的反响。Patrick 说，他身边很多关注 AI 的朋友第一次表示「这个有点吓人」。

Krishna Rao 回应说，大家可能误解了 Mythos，觉得它只是一个网络安全模型。实际上它在很多维度上都极其强大，只是恰好在网络安全方向上出现了一个能力尖峰。

他给了一个具体数字：之前的模型在一个开源代码库中找到了 22 个安全漏洞，Mythos 找到了 250 个。

确实很有些吓人。

所以 Anthropic 决定用一种此前从未用过的方式来发布 Mythos：分阶段、限范围，先给一小部分用户使用，聚焦在防御性的网络安全应用上，然后逐步扩展。

Krishna Rao 还提到，Anthropic 一直在跟美国 zf 保持紧密沟通。

他们的立场是：创新不应该被减速，但对于这种级别的能力，应该有一个责任框架来规范部署方式。

七个联合创始人

被问到公司文化时，Krishna Rao 提到了几个外界可能不太了解的细节。

Anthropic 有七个联合创始人。

他说，这在纸面上不应该 work，但实际上运转得非常好。七个人至今全部在职。最早加入的二三十号员工，绝大多数也还在。

招聘流程中有一个文化面试环节，Krishna Rao 强调这绝不是走形式。一个候选人其他方面全部优秀，是你见过的最聪明的人，但文化面试不通过，照样不录用。

文化的核心是极度协作，不容忍「山头主义」，不容忍抢功劳。还有一种彻底的谦逊：达到了某个里程碑，不会有人在地上撒纸花庆祝，而是立刻问「下一步是什么」。

Dario Amodei 每两周会站在全公司面前，写一份短文档讲三四个话题，然后开放提问。不是安排好的问题，是大家想问什么就问什么。

去年 Meta 用天价薪酬大规模挖人时，Anthropic 只走了两个人，而其他前沿实验室走了几十个。

“ 我们的薪酬有竞争力，但不一定是市场最高的。人们留下来，是因为使命、因为人才密度、因为在这里能产生的影响力。

什么可能踩刹车

Patrick 问了一个关键的反面问题：如果做一个推演，一年后发现 Anthropic 实际处在不确定性锥体的低端，是什么原因导致的？

Krishna Rao 给出了三个可能。

第一，企业内部的扩散速度。 用例还在追赶模型能力。这些毕竟是有着长期工具和流程的大型组织，改变谈何容易。如果扩散撞墙或者显著放缓，收入增速就会受影响。

第二，scaling laws 不再成立。 他目前没有看到放缓的迹象，但他也不会 100% 打包票，那样说才是不负责的。如果模型能力趋平，所有上游的假设都要重写。

第三，前沿的竞争。 今天 Anthropic 定义了 agentic AI 的前沿，但这不是永恒的。市场竞争异常激烈，需要持续投入技术、算力和市场拓展。

最期待的未来

问到最兴奋的方向，Krishna Rao 没有说 AI 编程或者企业效率，而是选了一个很多人没预料到的答案：生物技术和医疗健康。

他描绘了这样一个场景：未来你被诊断出一种当前不可治愈的疾病，但在你的有生之年，AI 加速的药物研发可以找到治愈方案，你可能不会死于这种病。

目前 AI 已经在帮助加速临床研究报告和文书工作。但他更期待的是 AI 深入到药物发现和药物开发的上游。如果实验室的通量提升 10 倍、100 倍，能跑那么多实验，得到更好的结果，而且更快。

“ 这不局限于少数疾病，它可以覆盖的范围远比想象的要大。

最善良的事

播客的最后，Patrick 照例问了他那个标志性的收尾问题：「别人为你做过的最善良的事是什么？」

Krishna Rao 的回答，让做了 600 多期节目的 Patrick 说「从没听过这种类型的答案」。

Krishna 有个哥哥，比他大五岁半。哥哥上大学时拿到了所有申请学校的录取，打算之后读医学院。

但 Krishna 直到很多年后才知道，哥哥最终选择了留在州内的公立大学。原因是：他们家是标准的中产阶级，二十五三十年前的助学金没有现在这么丰厚。哥哥在选大学的时候，考虑到了弟弟，一个当时才 12 岁的孩子。

他想把经济空间留给弟弟，让他将来能去任何想去的学校。

12 岁的 Krishna 完全不知道这件事。

而现在，这件事一直在他心里。

◇ ◆ ◇

相关链接：

YouTube 播客原片：https://www.youtube.com/watch?v=wEEZPpx8qow

Patrick O'Shaughnessy 原帖：https://x.com/patrick_oshag/status/2054532117410054252

Claude 频繁更新的另一边，公司技术博客也开始密集输出了……（推测是新入职的前 CTO 们转型 IC 后开始发力了）

这一次，Anthropic 发的是一篇 Claude Code 的企业级使用指南，讲的是它在大型代码库里怎么用才好使。

这里说的「大型代码库」，包括百万行级的 monorepo、跑了十几年的遗留系统、分散在几十个仓库的微服务架构。

甚至包括 C、C++、Java、PHP 这些的，大家通常不太会联想到 AI 编程工具的语言。

Anthropic 说，Claude Code 在这些语言上的表现，比大多数团队预期的要好不少，尤其是最近几代模型上来之后。

其中最核心的一个观点是：

Claude Code 的能力上限，取决于你怎么配它，模型本身有多强反倒是其次的。

不靠索引

Claude Code 是怎么在大型代码库里找到自己需要的东西的呢？

答案并不花哨，而且非常的简单而朴素：遍历文件系统、读文件、grep 搜索、追踪引用。跟一个真人工程师拿到一个新项目时做的事情，其实真的差不多。

它跑在开发者本地，不需要预先构建索引，也不需要把代码库上传到服务器。

而早期的 AI 编程工具走的是另一条路：RAG，先把整个代码库做 embedding，查询时检索相关代码块。这在小项目上没问题，但到了大型工程团队，就会有个致命缺陷：

索引更新的速度，永远跟不上几千个工程师提交代码的速度。

等你查的时候，拿到的可能是两周前被重命名的函数、上个 sprint 已经删掉的模块。而且没有任何提示告诉你：「这已经过期了」。

Claude Code 的 agent 式搜索避开了这个坑。没有 embedding 管道，没有集中式索引，每个开发者的实例直接对着最新的代码工作。

当然也有代价，Claude 需要足够的起始上下文才能知道从哪里开始找。如果你让它在十亿行代码里盲搜……那 context window 还没开始干活就满了。

所以，花时间把代码库对 Claude 配置好，会有相当可观的收益。

配置比模型重要

这大概是整篇指南里，最为反直觉的一个观点了。

大多数团队评估 Claude Code 时，盯着的是 benchmark、测试表现。但 Anthropic 说，在实际生产中，围绕模型构建的工具生态，对最终表现的影响，会比模型本身还大。

这就好比赛马，马当然重要，但鞍具、马蹄铁、骑手的配合加在一起，对比赛结果的影响未必比马小。

Anthropic 把这套东西称为 harness，由七个扩展点组成，按构建顺序排列：

从底到顶依次是：CLAUDE.md 文件、Hooks、Skills、Plugins、LSP、MCP 服务器、子 agent。

每一层都建立在前一层的基础上，而且顺序非常讲究。

打底两层

CLAUDE.md 文件是第一层，也是最基础的一层。

这是 Claude 每次会话自动加载的上下文文件。根目录放全局信息，比如「我们是什么项目、用什么框架、有哪些关键约定」。子目录放局部约定。Claude 在文件系统中移动时会自动向上遍历，逐层叠加加载。

因为每个会话都会加载 CLAUDE.md，所以内容要克制。塞太多进去反而会拖累性能。

一个常见的错误是把可复用的专业知识也塞到 CLAUDE.md 里。这些东西其实应该放到 Skills 中，按需加载就好。

Hooks 是第二层。

大多数团队把 Hooks 当防护栏用，让 Claude「别做某事」。但 Anthropic 说，Hooks 更有价值的用法其实是让系统自我进化。

比如一个 stop hook，在会话结束时反思发生了什么，趁 context 还热乎，提议更新 CLAUDE.md。

一个 start hook 则可以根据开发者当前所在的模块，动态加载对应的团队配置。每个人进入自己负责的区域，自动获得正确的上下文。

对于 lint、格式化这类确定性检查，Hooks 跑脚本就行了，比让 Claude「记住一条规则」靠谱得多。

知识分发

Skills 是按需加载的专业知识包。

大型代码库有几十种不同类型的任务。把所有专业知识都塞进每个会话，既不现实也不高效。Skills 的做法是「渐进式披露」：安全审查时加载安全 Skill，文档更新时加载文档 Skill。

Skills 还可以绑定到特定目录。支付服务的部署 Skill 绑到支付目录下，在 monorepo 其他地方干活时就不会被自动加载。

Plugins 则解决了一个老问题：好的配置容易变成部落知识。

张三花了两周调出一套完美的 Claude 配置，但李四入职时完全不知道这些。Plugin 把 Skills、Hooks、MCP 配置打成一个包，新人第一天装上就拥有和老手一样的环境。

Plugin 更新可以通过统一的 marketplace 分发到整个组织。（这里我还是得吐槽一下：Skill 没有较好的更新机制，谁来搞一个吧，不搞我搞了……）

Anthropic 提到了一个真实的案例：

一家大型零售企业造了一个 Skill，让 Claude 直接连接他们的内部数据分析平台，从而业务分析师不用切换工具就能拉取性能数据。在大规模推广之前，他们就可以把这个打成了 Plugin 分发了出去。

精准导航

LSP（语言服务器协议）给了 Claude 和开发者在 IDE 里一样的导航能力。

你的 IDE 里大概率已经有 LSP 在跑了，提供「跳转到定义」「查找所有引用」之类的功能。把这些暴露给 Claude，它就能按符号精确导航，区分不同语言里同名函数的差别。

没有 LSP 的话，Claude 只能靠文本匹配。在大型代码库里 grep 一个常见函数名，返回几千个结果，Claude 要逐个打开文件去判断，context 就这么烧完了。

有一家企业软件公司，在全组织部署 Claude Code 之前，先在公司范围铺了 LSP 集成，专门是为了让 C 和 C++ 的代码导航更可靠。对于多语言代码库，这算是回报最高的投入之一。

不过需要注意的是：LSP 不是开箱即用的……你得自己装对应语言的 code intelligence 插件和语言服务器。

外部连接

MCP 服务器是 Claude 连接内部工具、数据源和 API 的方式。

段位最高的团队会构建 MCP 服务器，把结构化搜索暴露为 Claude 可以直接调用的工具。也有团队用 MCP 接上了内部文档系统、工单系统或数据分析平台。

不过 Anthropic 的建议是：别在基础还没搭好的时候就急着上 MCP。 先把 CLAUDE.md、Hooks、Skills 这些基本功做扎实再说。

子 agent 是独立的 Claude 实例，有自己的 context window。

接收一个任务，做完之后只把最终结果返回给主 agent。有些团队会先用一个只读的子 agent 把某个子系统摸清楚，把发现写成文件，然后主 agent 带着完整的上下文去做编辑。

（这不是在说我吗……）

核心价值是：把探索和编辑分开做。

在同一个会话里又探索又编辑，context 很容易就撑爆了。

代码可读性

七层扩展讲完了，接下来是怎么在实际的大型代码库里做配置。

Anthropic 总结了三个在成功部署中反复出现的模式。第一个：

让代码库对 Claude 可读。

Claude 在大型代码库里能帮多少忙，取决于它能不能找到正确的上下文。加载太多会拖累性能，加载太少 Claude 就两眼一抹黑了。

几个实践经验：

CLAUDE.md 文件要精简且分层。根目录只放指针和关键注意事项，细节下沉到子目录。

在子目录初始化 Claude，别从仓库根目录开始。

这在 monorepo 里有点反直觉，但 Claude 会自动向上遍历加载所有 CLAUDE.md 文件，根目录的上下文不会丢。好处是工作范围被精确限定在了相关的代码区域。

测试和 lint 命令也应该按子目录配置。Claude 改了一个服务就跑整个测试套件？那就等着超时吧。每个子目录的 CLAUDE.md 应该写清楚该跑哪些命令。

用 .claudeignore 排除生成文件、构建产物和第三方代码。把 permissions.deny 规则提交到 .claude/settings.json，整个团队就能自动共享这些排除规则。

对于做代码生成器开发的同学，可以在本地设置里覆盖项目级别的排除规则，不会影响其他人。

给代码库画张地图。

如果目录结构本身不够自解释，那就在根目录放一个 markdown 文件，列出每个顶层文件夹的一句话说明。几百个文件夹的代码库用分层方式：根文件描述最高层结构，子目录 CLAUDE.md 补充下一级细节。

简单场景下，直接在对话中 @-mention 具体文件或目录也行。

Anthropic 也坦承一个边界情况：几十万个文件夹、上百万个文件的代码库，或者跑在非 Git 版本控制上的遗留系统，即使分层 CLAUDE.md 也可能搞不定。这个留到后续系列文章解决。

配置要迭代

第二个模式：随模型进化，主动维护你的配置。

为当前模型写的指令，在下一代模型上可能适得其反。

一个例子是，一条 CLAUDE.md 规则要求 Claude 每次重构只改一个文件。在老模型上确实有效，能帮它保持专注。但新模型已经完全能做跨文件的协调编辑了，这条规则反而变成了枷锁。

同样的道理，为弥补模型弱点而写的 Skills 和 Hooks，模型一升级就可能变成多余的负担。

Anthropic 还举了个例子：有团队写了个 Hook，在每次文件写入时自动执行 p4 edit（Perforce 版本控制命令）。后来 Claude Code 原生支持了 Perforce 模式，这个 Hook 就没用了。

建议每 3-6 个月做一次完整的配置审查。每次大模型发布后也值得检查一轮。

如果你觉得 Claude Code 的表现到了某个瓶颈怎么也上不去……问题可能不在模型，而在你的配置没跟上。

毕竟模型都已经往前跑了，你的 CLAUDE.md 可能还停在三个月前。

得有人管

第三个模式：指定专人负责 Claude Code 的管理和推广。

技术配置做得再好，也撑不起全组织的采用。

Anthropic 观察到一个共同点：推广最快的组织，在大面积开放之前，都是先有一小队人把基础设施搭好了。

有的公司是两三个工程师在 rollout 前就造好了一整套 Plugins 和 MCP。有的甚至组了专门管理 AI 编程工具的团队，一切就绪才开放访问。

效果是：开发者第一次接触 Claude Code 就能跑通。

第一印象如果是「这东西不好使」，后面要翻盘就太难了。

目前承担这个职能的通常在「开发者体验」或「开发者效率」部门下面。一个正在浮现的新角色叫 Agent Manager：半 PM 半工程师，专门负责管理 Claude Code 生态。

规模更小的组织至少需要一个 DRI（直接责任人）：一个人负责配置、权限策略、Plugin 管理、CLAUDE.md 规范，并且有拍板权。

自底向上的采用能激发热情，但缺了组织层面的收敛，好用的实践就会变成部落知识，采用率到某个点就上不去了。

治理先行

大组织，尤其是受监管行业的公司，治理问题会更早出现。

谁控制哪些 Skills 和 Plugins 可用？怎么防止几千个工程师各自造轮子？AI 生成的代码怎么走和人类代码相同的审查流程？

Anthropic 的建议是从小开始：一组预定义的已批准 Skills、必须的代码审查流程、有限的初始访问权限。随着信心的增长再逐步放开。

最顺畅的部署，来自那些早期就成立了跨职能工作组的组织：工程、信息安全、治理的代表坐到一起，共同定义需求，一起画路线图。

三步部署

Anthropic 把企业级部署分为三个阶段：

基础设施阶段：小团队先搭好工具链、Plugins、MCP，把地基打好。

试点阶段：有限的初始访问，配上已经定义好的审批流程。

规模阶段：在已建立的治理体系和约定基础上，再大面积推广。

适用边界

最后一个问题：什么样的代码库能用这套方案呢？

Claude Code 设计的前提是常规的软件工程环境：工程师是主要贡献者、仓库用 Git、目录结构标准。大多数大型代码库都符合。

但也有一些非常规场景需要额外的配置工作：带大量二进制资产的游戏引擎、非 Git 版本控制的环境、非工程师往代码库里贡献内容的情况。

这些场景下，Anthropic 的 Applied AI 团队可以直接和工程团队合作，把通用模式翻译成具体组织的定制方案。

◇ ◆ ◇

整篇指南读下来，Anthropic 想传达的核心逻辑是：模型能力是地板，配置质量才是天花板。

七层扩展，三步部署，先搞基础再上规模，有人负责，定期翻新。

这倒也算不上太过新鲜的道理，可能许多各位也已经在这么做了。但 A 厂这也算是第一个把企业级部署的经验写得这么系统，并分享出来的。

这个系列后面还会持续更新，Anthropic 说的是，更极端场景（超大规模文件系统、非 Git 版本控制）的实践指南正在路上。

本号也会继续追踪，分享出来，敬请期待。

我是 John，感谢阅读。进 Claude Code 交流群可加我（公众号后台有联系方式）后备注 cc。

◇ ◆ ◇

指南链接：

https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

Anthropic 发了一份 34 页的 PDF，手把手教创业者们怎么用 AI 把公司从 0 做到 1。

（当然，你也可以理解为，怎么更多消耗 Claude Token……）

这份手册叫 The Founder's Playbook: Building an AI-Native Startup，覆盖了创业的四个核心阶段：想法验证、MVP 开发、产品发布、规模扩张。

每个阶段都给出了具体的目标、退出标准、常见陷阱，以及 Claude 的三个产品形态（Chat、Claude Cowork、Claude Code）分别该怎么用。

这并不是一份自媒体们泛泛而谈的「AI 赋能创业」鸡汤，它是一份操作级别的实战指南，精确到每个阶段该做哪些练习、用哪个工具、甚至可能会踩哪些坑。

游戏规则正在改变

手册开篇抛出了一个判断：2026 年的创业生命周期，跟过去完全不一样了。

传统创业的路径是：验证想法 → 融资 → 招人 → 开发 → 增长 → 再融资 → 再招人，循环往复。每进入一个新阶段，都意味着更大的团队、更多的技能需求、更多的钱。

而 AI 的出现，把这个循环打碎了。

现在，一个从来没写过代码的创业者，也能把产品做出来并上线。过去需要一整个工程团队才能搞定的事，现在一个创始人配上 agentic coding 工具可能在一夜之间，就能完成。

「10 人独角兽」正在从传奇故事变成可操作的路线图。

手册用了一句话概括这个变化：agentic coding 把「我有一个想法」到「我有一个产品」之间的时间 gap，压缩到了从前难以想象的程度。

角色转变

过去，创始人按能力被分成两类：技术创始人写代码，非技术创始人跑业务、谈合作。

到了 2026 年，这条分界线正在消失。

没有工程背景的人，可以直接用 AI 把想法变成可运行的软件。而技术背景的创始人呢，也能轻松搞定商业计划、财务模型、融资材料这些以前得找人帮忙的事。

创始人的角色从「亲自执行」变成了「指挥 Agent」。

创始人的注意力应该从动手干活，转移到更高阶的工作上，也就是产生想法、确定方向，然后指挥 AI agent、工具和小团队去实现。

这就像从「一个人搬砖」变成了「一个人指挥一群机器人搬砖」，你需要的核心能力变了，从执行力变成了编排力。

三大件

手册里给了一个工具选择矩阵，即官方三件套：

Chat 适合快速问答和头脑风暴，像是随时在线的顾问。投资人备忘录里一句话没看懂？问它。开会前需要 sanity check 一个数据？问它。不用设置，不用准备，打开就聊。

Claude Cowork 适合需要时间、需要整合多个来源的知识型工作。它能连接你的文件、日历、工具，像是一个按需上岗的自动化运营团队。把一堆客户通话录音变成一份主题报告？用它。每周自动从各个数据源拉 KPI 汇总？也用它。

Claude Code 是给工程团队用的 agentic coding 环境。直接在代码库里操作，能生成、测试、调试、重构代码。一个小团队靠它就能持续交付功能，不用等招人。

三者的底层模型是同一个 Claude，区别在于工作台不一样。

Idea 阶段

每个创业者都会从同一个地方开始，这也是一个挥之不去的问题：Idea。

手册在这个阶段的核心观点是，2026 年创业成功的关键恰恰是克制住不要动手做的冲动，先把想法验证清楚了再说。

这个阶段的目标是以研究为导向的验证：组装足够的证据，证明问题是真实存在的，你的方案确实能解决它。

需要回答四个问题：

•  这个问题是真实的、具体的、高频的吗？ 

•  谁在遭受这个问题，他们构成一个市场吗？ 

•  有人在解决这个问题了吗？解决得怎么样？ 

•  解决这个问题到底需要什么，我的方案做到了吗？ 

退出标准是找到 problem-solution fit，通过真实的用户对话获得定性证据，证明你在为真实的人解决一个真实的问题。

三大坑

除了官方三大件，手册还给出了三个大坑，每个都跟 AI 时代密切相关。

把「做出来了」当成「验证了」。过去 42% 的创业公司失败，是因为做了一个没人要的东西。现在 agentic coding 把「有想法」到「有产品」的距离压缩到了几乎为零，这个失败率……当然只会更高。

原型做出来了，创始人就觉得假设被验证了。但一个能跑的原型只是一个压力测试工具，真正的证据来自与潜在用户的对话。

过早扩张。AI 让执行变得几乎无成本，创始人很容易在验证 problem-solution fit 之前就开始扩张。agentic coding 的执行力太强了，你甚至都没意识到自己已经，偏离了验证的轨道。

怎么讲，就好像肆无忌惮的 Claude Code，在没有经过人工验证之后，就继续放手开干更野的事情了。

结果，自然是惨不忍睹……

丧失客观性。这个坑则最为隐蔽。让 AI 去验证你的创业想法，它会帮你找到支持证据。让它估算市场规模，它会给你找到一个非常好看、让你心动的数字。

AI 听从你的方向，一个不会提出尖锐问题的创始人，现在可以比以往更快地为一个糟糕的想法构建出一份精美的商业计划书，同时信心满满。

那么……解药是什么呢？

答案是 AI 本身，只不过让它扮演反方。让 Claude 去论证你的想法为什么会失败，去找到反驳你假设的证据。

手册里反复强调：要把 AI 当作结构化的「魔鬼辩护人」，是 AI 创业生命周期中每个阶段的核心用例。

如何验证

手册给了一套完整的实操流程。

定义和压力测试问题假设。跟 Claude 合作，把模糊的观察打磨成可测试的假设。「大家报销流程都有问题」只是一个观察，但「中型企业的内部法务团队每份合同审核要花 3 天以上，因为红线修改分散在邮件里，没有版本控制的文档」才是一个可测试的假设。

然后让 Claude 去找反面证据，找到能推翻假设的市场信号、失败的竞争对手、客户行为模式和结构性障碍。

市场调研和竞品分析。让 Claude Cowork 去综合竞品评价，识别现有方案没解决的核心痛点。构建 TAM/SAM/SOM 模型，并对其中的假设做压力测试。追踪行业趋势，判断每一个趋势是你的顺风还是逆风。

设计客户访谈。让 Claude 帮你设计访谈问题，别问「你会用这种产品吗？」这种诱导性的未来式问题，应该问「上次你遇到这个问题时是怎么处理的？」这种具体的过去式问题。

每做完五次访谈，就让 Claude Cowork 综合出两张列表：支持你假设的证据，和挑战你假设的证据。如果第一张清单比第二张长得多，就该问问自己是不是在选择性倾听了。

构建轻量原型。当假设通过验证、方案经过压力测试后，用 Claude Code 做一个最小可行原型。注意了，这还算不上真正的产品，它只是一个放到真人面前让他们触摸并做出反应的功能样本。

给 5 个目标用户看，他们的反应决定你是继续做还是推倒重来。

MVP 阶段

Idea 阶段结束，进入 MVP。

很多创始人把 MVP 阶段当成纯粹的「施工期」，但手册指出，MVP 本质上仍然是一个收集证据的过程，只是从问题空间转移到了方案空间：这群人是否觉得你的方案有足够价值，愿意用它、留下来、为它付费、或者告诉别人？

MVP 阶段有三个目标：

把验证过的问题转化为可用产品。不要求全功能版本，只需要最小的、最聚焦的迭代，能放到真实用户面前产生真实的 product-market fit 信号。

快速推进，但不积累技术债。AI 生成代码的速度快得惊人，但没有架构约束的 AI 编码，每个 session 都会从头推导架构决策，决策会漂移，最终得到一个没有连贯心智模型的代码库。

投资于持久化上下文。从第一天就把架构决策写进 CLAUDE.md 文件。跳过 spec、跳过架构文档、跳过上下文文件的创始人，会撞上一堵墙：每开一个新 session 都要重新解释整个代码库。

退出标准是 product-market fit 的真实证据：一个可识别的用户群体，觉得产品有足够价值，愿意持续使用、付费或推荐给别人。

四大新坑

除了三大老坑，还有四大新坑。

Agentic 技术债。AI 写的代码能跑，但未必安全，未必结构合理。当速度成为唯一变量，创始人很容易在 MVP 阶段疯狂堆功能，积累出难以偿还的技术债。

没有 spec 和架构约束的情况下，AI 每个 session 都从头推导基础决策，决策不断漂移。你最终得到的是一个没有任何单个部件有问题、但所有部件从未被设计成组合在一起的代码库。

虚假的 product-market fit。AI 工具能帮你更快地到达「产品上线」那个令人兴奋的时刻，但早期的增长势能跟真正的 PMF 不是一回事。来自创始人朋友圈、投资人的 portfolio 公司、或一条 Hacker News 帖子的用户热度，没有一个能预测第 6 周或第 12 周之后会发生什么。

零成本的范围蠕变。做功能几乎不花时间了，于是总想着「再加一个功能」。每一个单独的新增看起来都合理，但产品慢慢偏离了原来的方向和势能。

解药是在动手之前写一份书面的范围定义：产品做什么、刻意不做什么、以及什么样的用户证据才能证明加新功能是合理的。

因为不懂安全而裸奔。agentic coding 工具生成的代码能跑，但未必安全。功能代码是可见的，安全漏洞是不可见的，没有天然的反馈回路来提醒新手创始人哪里有问题。在 MVP 上线给真实用户之前，安全审查是最低门槛。

搭 MVP

先定义架构，再写一行代码。让 Claude Code 帮你定义和记录架构决策：遵循的模式、避免的依赖、做出的 tradeoff 以及为什么。然后把这些输出保存为 CLAUDE.md 文件。

这是你 MVP 的第一个产出物，后续每个 session 都建立在它之上。每次开 Claude Code session 前，先过一遍 scope 文档和架构上下文文档，session 结束时更新它。

目标是一个你能解释其结构的代码库，不只是一个能跑的代码库。

在发布前建立度量框架。那些把早期增长误判为 PMF 的创始人，往往也是在发布后才开始追踪数据的人。在第一个用户来之前，就用 Claude 定义哪些指标重要、什么样的数据表明了真实的 PMF，什么只是虚荣指标。

手册提到了两个 PMF 测试方法：

• Sean Ellis 测试：问活跃用户「如果你不能再用这个产品了，你会有多失望？」超过 40% 的人回答「非常失望」，才是有意义的 PMF 信号。 

• 努力度测试：PMF 之前，留存需要持续干预，个性化跟进、激励措施、创始人亲自发力。PMF 之后，产品自己就能拉动增长。当事情从「推」变成「拉」，才是真正有东西变了。 

当证据要求你调整方向时，调整。如果三个以上的迭代周期都没有朝 PMF 基准靠近，用 Claude 做一次诊断：喂入留存数据、用户反馈和原始问题假设，问三个问题：

数据中是否有某个细分群体表现不同？设计价值和体验价值之间的差距，是定位问题还是产品问题？当前产品要找到真正的 PMF 需要什么条件成立，这些条件现实吗？

Launch 阶段

MVP 阶段证明你的产品值得存在，Launch 阶段要证明你的业务值得增长。

这个阶段的目标是把早期势能变成可重复、可持续的增长引擎。同时，你还要加固底层基础设施，建设产品之外的公司。

退出标准有三条：

•  增长可重复、渠道驱动。你通过可预测的渠道获取和留存用户，CAC、LTV、回收期这些数据你都能算清楚。 

•  产品能扛住生产负载。基础设施已加固，安全和合规到位，在真实生产条件下可靠运行。 

•  运营不再依赖创始人。流程和自动化到位了，你不再亲自处理支持请求、sprint 计划或报告。 

上线

而上线并不代表成功，而是有更多的坑要踩。

技术债到期了。MVP 阶段为了速度积累的技术债，在 Launch 阶段开始「收利息」了。生产流量、新功能、不断增长的复杂性，都在暴露当初走的捷径。越拖，修复成本越高。

创始人变成了瓶颈。MVP 阶段，创始人参与每个环节算是优势。但到了 Launch 阶段，如果你还试图亲自把控每条线，整个组织就会因为你而停转。一个本来一小时能搞定的决策，因为要排队等你处理，变成了一周。

手册的建议是：做一次彻底的审计，把你手上的所有事从最小的琐事到最大的决策排列出来，区分哪些可以系统化、哪些可以委托出去、哪些真正需要创始人判断。

安全和合规不再是可选项。MVP 阶段只有少量 beta 用户，安全漏洞是理论风险。但一旦有真实用户、真实数据、潜在的企业合同，安全就变成了法律责任。合规要求在你处理客户数据、处理支付、卖给受监管行业的那一刻就生效了。

过早扩张到新市场。早期的增长是真实的，但也是针对特定早期用户群的。过早进入一个与原来截然不同的市场，会引入新的用户行为、合规要求、支付基础设施和基线预期，你的产品并没有为此设计过。

运营

然后，还有运营，重要性不亚于比产品做好。

修复技术债。用 Claude Code 做一次全面的架构审计，识别结构性弱点、测试覆盖不足的区域、以及重构候选项。同时，把 MVP 阶段存在你脑子里的架构决策写进 CLAUDE.md，确保以后每个 Claude Code session 都从一个共享的理解出发。

构建替代创始人注意力的系统。用 Claude Cowork 审计你当前的运营负荷，记录每个重复性任务、每个落到你桌上的决策、每个只有你记得所以只有你做的工作流。然后把它们分成三类：可以完全自动化的、需要人但不一定是你的、以及真正需要创始人判断的。

对可自动化的候选项，用 Claude Cowork 设计工作流逻辑：什么触发、什么规则、什么产出、交给谁。

安全和合规变成产品工作流。用 Claude Code 扫描代码库中常见的 SOC 2、GDPR、HIPAA 问题，把安全合规融入开发周期，别当成一次性项目。对于即将签企业合同的创始人，这也是准备独立安全评估的时机。

建立产品管理流程。用 Claude 设计一套轻量的产品管理操作系统：sprint 节奏、spec 模板、bug 分诊流程、每周指标报告。然后用 Claude Cowork 来跑这些流程的运营层面，比如定时编译报告、路由 bug、追踪反馈闭环。

Scale

产品做出来了，市场认可了，业务跑起来了……然后呢？

Scale 阶段，创始人的角色从 builder 变成了面向公众的 executive。你的日常工作不再是产品本身，而是公司本身：分析师简报、IPO roadshow、董事会、企业合同。

这个阶段的目标是通过不断积累深度，构建防御性护城河。

你在产品中沉淀的专业知识、你与其他工具和平台的集成深度、你的用户在你的产品上构建的私有化工作流和数据，这些都是护城河的砖。

退出标准不再是一个单一里程碑，而是一个门槛事件：公司可以在创始人不直接参与日常运营的情况下可持续运转。具体形式可以是可持续的盈利、不再需要外部资本的规模化、IPO-ready 状态，或者被收购。

扩张之痛

委托运营层。Launch 阶段你在搭建系统，Scale 阶段你要让这些系统足够成熟以至于你能信任它们。对于一个从第一天就亲力亲为的创始人来说，这既是结构性挑战，也是心理挑战。

放手太快……关键决策缺少只有创始人能提供的上下文；放手太慢，你就成了瓶颈。核心挑战是识别哪些机构知识只存在于创始人脑中或未文档化的工作流里，然后把它们编码成可审计、可转移的系统。

技术运营要企业级。大客户和机构采购方签的是多年合同，他们不只是评估你的产品，还要确认你的组织是一个可靠的基础设施合作伙伴。支持体系、文档、响应时间保证、可观测性、SLA，都得到位。

搭建 GTM 机制。有机增长有天花板。大多数 Scale 阶段的创始人第一次面对「要搞营销、销售、分析师关系」这些事。一个真正的 GTM 动作需要的不只是新系统和新流程，还有品牌叙事和产品故事。

Scale 实操

把日常事务交给 Claude Cowork。先列出你在这个阶段应该做的事：产品叙事决策、董事会关系、企业合约、founder-to-founder 对话。清单上没有的，都是委托或自动化的候选项。

用 Claude 画一张你当前运营层的瓶颈地图，标注每个需要你审批的工作流、每个你不在就会停滞的决策点。然后压力测试这些系统：假设你消失一周，哪些工作流会停转？那些就是需要加固的地方。

技术运营升级到企业级。用 Claude Code 去加固代码库，审计安全标准，搭建企业级支持基础设施：日志、监控、事件响应工具、以及让 SLA 可执行的可观测层。

Claude Cowork 跑企业支持的运营层：工单路由、因产品变更触发的文档更新、续约追踪、客户成功报告。三件套一起上，一个小团队就能撑起远超其人数的支持架构。

把域知识转化为 AI 上下文。很多创始人做的是垂直领域的产品，他们的核心竞争力是行业 know-how。用 Claude 把这些知识外化，变成结构化的、可搜索的上下文。通过 Skills，把「我怎么审计一份商业租约」「我怎么分诊患者入院表格」这类重复性工作流编码成可复用的自动化流程。

日积月累，这就变成了一个通用 AI 无法匹配的私有知识底座。

构建工作流锁定。数据网络效应让你的产品难以复制，而用户的工作流锁定则让你的产品难以离开。用户在你的产品上跑得越久，它就越深地嵌入日常运营：他们在上面搭建了自动化、训练了员工、连接了数据源。到了这个阶段，「换产品」等同于「换操作系统」。

用 Claude 分析你的客户集成深度：每个客户细分搭建了什么工作流，依赖了哪些集成，估算其切换成本。哪种集成类型创造了最深的锁定，就优先加深它。

把用户数据变成护城河。用户与产品的每次交互都产生行为信号：他们接受什么、拒绝什么。这些数据锁定了时间、锁定了上下文，竞争对手无法复制。你买不到几千个用户在你产品内长期打磨工作流留下的行为指纹。

用 Claude 审计你已收集的交互数据，识别最高信号的行为模式，设计反馈循环把持续使用变成系统性的模型改进。每次改进让产品更好用，更好用带来更多使用，更多使用带来更多反馈。飞轮就这么转起来了。

创业者故事

手册的最后一章，列出了一批正在用 Claude 构建产品的创业公司案例：

• Carta Healthcare：用 Claude 驱动临床数据抽取平台，每年处理 22,000 个手术案例，数据抽取时间缩短了 66%。 

• Anything：由 Claude 和 Agent SDK 驱动，帮助 150 万用户把想法变成可运行的软件产品。一个没有技术背景的创始人，已经在卖一个完整的招聘平台了。 

• Cogent：用 Claude 作为推理层来自动化企业安全任务，覆盖漏洞调查、优先级排序和修复的全生命周期。 

• Airtree：把 Claude Cowork 作为运营基础设施的中心，统一了之前分散在十几个工具和团队中的数据。当一个人搭建的工作流自动化通过 Skills 共享出去，整个组织都能复用。 

• Duvo：完全基于 Claude 和 Agent SDK 构建的 AI Agent，跑采购、供应链、品类管理，跨越 ERP、供应商门户、邮件甚至电话。 

• Zingage：面向居家护理行业的 24/7 AI Agent 平台，用 Claude 的结构化工具调用和上下文推理在 EMR 和多个通讯渠道间协调，做到个性化的患者护理方案。 

• Kindora：一个非营利高管用 Claude Sonnet 构建的 AI 平台，智能匹配慈善机构和资助方，从几千个候选中筛选出精准匹配。 

• GC AI：创始人用自身的法务行业经验构建了一个 Claude 驱动的法务工作平台，每家企业有自己的 playbook、利益相关方结构和风险容忍度。 

万事俱备，只差你了

这份手册有着非常高的操作密度。

每个阶段都不只是「告诉你应该怎么想」，它直接给练习题：用 Claude 做什么、怎么做、做完之后怎么判断结果。它像一本驾校教材，不跟你聊汽车文化，直接告诉你方向盘往哪打、油门踩多深。

当然了，这也毫无疑问是一份 Anthropic 的产品推广材料。手册里提到的所有工具都是自家的 Chat、Claude Cowork、Claude Code。

但干货是实打实的。即便你换成别的 AI 工具，手册里关于创业阶段划分、每个阶段的陷阱分析、验证框架和度量方法，都是通用的。

一份 34 页的 PDF 能做到是：

让你看完就知道自己在哪个阶段，该做什么，不该做什么，以及，下一步往哪走。

接下来，就看你的了。

◇ ◆ ◇

相关链接：

博客：https://claude.com/blog/the-founders-playbook

PDF 下载：https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/69fe2a55b93bb0732b1fe33c_The-Founders-Playbook-05062026_v3%20(1).pdf

👆一个小细节：上面链接里的这个“（1）”真的是官方链接里的……不知道是哪个 AI 干的

你应该还记得，今年愚人节的前一天，3 月 31 号，Anthropic 的 Claude Code 整个源代码，包括 1900 多个 TypeScript 文件、51 万行，通过 npm 包里一个忘记排除的 .map 文件，被官方给开源了。

见：Claude Code 源码泄露，全面剖析【长文】。

Claude Code 的负责人 Boris Cherny 给出的官方定性是：

“ plain developer error（普通的开发失误）。

这里有两个细节。

根因是有人在打包流程里没有把 *.map 加进 .npmignore。一个 checklist 项，一行配置，没人补上。

而 Boris 自己在另一个场合说过一句话：他对 Claude Code 100% 的贡献，都是 Claude Code 自己写的。

也就是说，世界上最先进的 AI 公司，用自己最先进的 AI 写自己的产品代码，依然在一个「理应有人复核」的环节上栽了跟头。

不过这件事，在我看来，它不该被解读成「AI 不靠谱」。

它应该被解读成：哪怕你雇了世界上最聪明的员工，只要流程上是单点兜底，事故就是时间问题。

薯条的秘密

大公司为什么要搞 SOP 呢？

麦当劳的薯条流程，不是为了让员工炸得更香，是为了让全世界任何一家店的薯条都不至于难吃。

SOP 的本质，是把「个人能力」转换成「组织能力」。

个体可以离职、可以累、可以失误。流程不会。

当然 SOP 也有代价：整体会变慢、僵化、协同成本高、优秀的员工容易被磨成打螺丝的……

所以过去二十年，硅谷的小公司一直在用「小团队 + 高信任 + 高自驱」来对抗大厂的流程。Stripe、Linear、Notion 都是这套打法的产物。

这条路以前是成立的，毕竟人不会无限复制，团队不可能无限拆细。

但 AI 改变了这个前提。

审计师吐血

打开 Codex、Claude Code、或任何主流的 AI Agent 产品，你看到的都是同一个东西：一个 TUI 或 GUI 的窗口，背后是一个无所不能的 Agent。

让它写 PRD、写代码、做竞调、回邮件……它什么都能接、敢接、还基本都能接住。

我不止一次说过，这已经就是「AGI」。见：对我来说，Claude Code 就是 AGI

但站在组织视角看，这其实是一个绕过了所有职责边界、所有交叉校验的「全能员工」。

放在真实公司里，这对应的是什么场景呢？

同一个人既写代码又 review 自己的代码、同一个人既谈合同又签合同、同一个人既做产品决策又做财务审批、心里同时在想着一百件事……

而且这个人记忆力还不太稳定，虽然脑容量越来越大了，但上下文（context）一长就忘前面说过什么。

审计师看到了，真的会当场吐血。

Claude Code 那次源码泄漏的原因也就在这里：当所有事都集中在一个「超级个体」身上，缺的从来不是能力，是组织的结构。没有第二个角色去问一句「你打包的时候排除 .map 了吗」。

自说自话

那 AI 为什么比人还更需要分工呢？

让同一个 AI 实例既当 PM 又当工程师又当法务，结果并不是三个角色都做得好。它在三个角色之间不断切换语境、不断丢上下文。

它不是在协作，它是在自我对话。而自我对话这事，我们和 AI 自己都很有经验了……天然就不太会给自己提反对意见。

而 Claude Code 在前两天新推出的 /goal 时，也算是吸取了此前的教训，把裁判和运动员进行了分离：

在每轮结束后，系统把目标条件和对话记录发给一个独立的小模型（默认是 Haiku），由它来判断条件是否满足。如果没满足，它还会返回一段理由，告诉主模型哪里还差，作为下一轮的方向指引。

从而让干活的归干活，验收的归验收。

而在人类公司里，PM 和工程师会“吵架”，而这种所谓的吵架从本质上来说，是两种视角在碰撞。

一个 AI 同时扮演两个角色时，它会自动找到一个「看起来都过得去」的中庸答案。这恰恰是最危险的产出，因为它在每个维度都不够深。

所以在我看来，Agent 之间的协作，绝不能是只为了酷炫、好看、暴力、显得牛逼……它最重要的，是要把人类花了一百年发明的「职责分离 + 交叉校验」，重新装回去。

这样再结合 AI 毫无情绪、不知疲倦、架吵得快（是也得吵一会，但显然比人快且不会真干起来）的特点，才能对 SOP 实现取其精华，去其糟粕。

保留结构的好处，并去掉结构的代价。

先去招人

说了这么多，有没有产品真的在按这个逻辑做呢？

答案是：还真的有。这便是今天要介绍的，一个叫做 Helio 的产品：

Helio 在做的，正是上面说的这件事情：让 AI 以团队成员身份进入组织，有独立身份、独立邮箱、独立记忆、独立岗位。

押注于打造一个 AI-Native 的 Workforce。

下载好后，打开 Helio 的第一个画面，有点意外的不是个聊天框，而是个「认识你的团队」的界面。

然后，系统就给分配了一个 HR Manager 过来，会先来帮忙搞清楚作为老板你想要做什么，然后再根据需求来帮你「招人」。

注意这里说的是「招募」，居然不是「创建」或「配置」……而整个产品的设计意图，也可以说正是藏在了这样的细节里：你这是一支团队，是组建的，不是瞎凑的。

一个管理者在给团队招聘时，对每个可能的候选人，真的是会仔细思考其定位，反复斟酌的（我自己招人时，也会特别谨慎，需要对双方负责）。

各有各的 JD

我试着用 Helio 来搭建一个叫 PatentGuard 的专利监控产品（最近的一个比赛项目，过多信息暂先不透露了……）。

我也懒得多说无用的废话，直接把我的 PRD 扔了过去，让它给我找需要的人。

HR 帮我们招了 7 个 AI 同事：PM、前端工程师、后端工程师（两位）、CV 算法工程师、数据工程师、设计师。然后全给拉进了一个叫 #chuhai 项目频道。

而这帮 AI 同事们，每个都有自己的岗位档案。

以 PatentGuard PM 为例，它的 Settings 页面写的是：负责需求拆解、roadmap 规划、用户调研。

不负责法律意见，不负责招聘决策，不负责写生产代码。

这就是岗位说明书，SOP 的最小单元。

每个 AI 有明确的职责边界，就像真实公司里的 JD。它有自己该管和不该管的事、有该聚焦的和该放下的。

开工

于是我在频道里 @PatentGuard PM：「拆解一下这个产品，然后分配任务给各个队友。」

PM 读完需求后，产出了一份 12 个月的 roadmap，包含技术栈选型、里程碑划分、每个角色的分工表和时间表。

这里插播一句：AI 的智能还是部分继承了人类遗留的烙印啊……显然用不了 12 个月，2 天还差不多。

这里表面看，它是完成了一个「任务」，但从项目角度看，它是做了一件非常重要的事：整个项目的管理动作。

然后 PM 把产品要求和任务分配发到了频道里：

拆解完成后，紧接着……七个 AI 就同时开工了。

到这一步，人类老板就可以聊聊天干点其他的去了。不过我还是打开了后台的 Activity 面板扫了眼，能看到 CV 算法在跑，Data Engineer 在跑，Frontend 在跑，Backend 在跑，Designer 也正在跑。

没有一个歇着的，非常之好。

这种“好”的感觉，你如果当过老板，或者给一帮人发过工资，就会知道……

AI 吵架

接下来发生的这一幕，则是整个过程中，真正最像人类组织的……

AI 们开始在频道里互相对话了，不是各自回复我的指令，而是 AI 跟 AI 之间真的开始掐起来了……在讨论问题。

CV 算法工程师和设计师在讨论浮窗的三种交互状态怎么跟模型推理对接。CV 算法主动指出 DiNOv2 有三个变种，各自的 tradeoff 不同，给出了 ODP XML 的备选方案。

前端工程师和后端工程师在确认 API 接口格式和数据结构。

最后，它们自己达成了一致，并把协作方案同步到频道。

这是「单点兜底」模式下，不会发生的场景。

一个全能 AI 自己做需求、自己写代码、自己 review，它会因 context 的惯性而迷之自信，并且，永远不会跟自己吵一架（谁没事抽抽干自己呢……）。

但在 Helio 里，由于各自 JD 和职能的差异、目标的差异，所以 PM 和工程师之间能进行有效的交流，算法工程师和设计师之间有真正的技术评审。

这也正是前面说的，终于有第二个角色问出「你确定这个方案没问题吗」了。

过程可查

在 Helio 里，每个 AI 都有个 Activity 面板，我们可能随时去看到它调用了什么工具、读了什么文件、做了什么判断、产出了什么结果、捅了什么篓子。

某个角度来说，这比人类老板对人类员工的监视要强得太多了，关键还没什么道德上可以谴责的……

在其他的 AI 工具里，我们把需求丢进去并最后拿到了结果，但中间发生了什么往往偏黑盒或很难灵活查看。在 Helio 里，每一步都被设计的有迹可循，一旦出了什么问题，都可以精确定位到是哪个 AI 在哪一步做了什么决策。

而且每个 AI 的记忆是独立的，不会互相污染。PM 记住的偏好不会影响工程师的判断，等于每个员工有自己的工作笔记。

此外，Helio 还引入了一个叫 Dream 的机制：每个 AI 同事每天凌晨会触发一次「做梦」，回顾白天的工作，识别哪些做对了、哪些做错了，然后更新自己的行为规范。

每次改动都写入 changelog，可以审阅、也可以回滚。

也就是说，用了三周的 AI，会比用了三天的好，因为它每晚都会在学习、反思、进化。

放权有度

还有一个设计细节。

Helio 里 AI 执行涉及外部系统的操作时，会主动弹出审批请求。

而这里的审批，也不是简单的 Yes 或 No，它有三档：

• Trust：长期信任，以后这类操作直接执行 

• Always：永久授权，但每次仍需确认 

• Onetime：一次性放行，用完即失效 

就像给新员工授权访问公司系统的逻辑一样：哪个凭证、什么用途、多久有效，都可以精确控制。

让 AI 主动干活，但不能放任它胡来。10

自有 API

值得一提的是，整个团队会默认走 Helio 自己的额度，但 Helio 心态上也很开放，支持用户接入自己的 API Key。

毕竟这么一堆 AI 花起钱来还是非常之快的……

如果你有 Anthropic、OpenAI 的订阅，或是昨晚用零花钱在京东抢到了几张卡部署了自己的模型，那你可以把 Key 填进去，AI 团队们就直接走你自己的账户了。

组织的回归

回到开头 Claude Code 代码泄露的事故。

那个 .map 文件忘了排除，不是因为 AI 不够聪明，也不是因为程序员不够细心……

只是因为流程上，缺了一个角色去基于自己的岗位职责，去问出那个问题。

过去两年，主流的 AI Agent 产品的形态都是「一个全能助手」。这种形态在简单任务、个人工具、或是小型产品的初级阶段时还是基本够用的，但随着任务复杂度上升，缺少结构的代价就会越来越明显。

Helio 押注的，是打造一个 AI-Native 的 Workforce，把 AI 放在一个 AI-Native  的组织里去，有岗位、有分工、有流程、有审计，像人类组织，甚至，会超越人类组织。

下一代 AI 产品的形态，大概会回归人类工业组织积累了一百年的智慧。

区别只是这次，执行这些机制的，不再是人类了。

◇ ◆ ◇

相关链接：

Helio 官网：https://helio.im

Helio 下载（macOS）：https://downloads.helio.im/macos/latest