[深度拆解] Anthropic内部如何用Claude Code消灭PM文档：一场产品管理的“原生AI”革命
📝 创作说明
- 选题方向: AI原生团队的工作流革命：以Claude Code团队为例
- 评分: AI相关性 50/50 + 故事性 45/50 + 加分项 15/20 = 总分 110/120
- 字数: 2150/2000字
- 核心价值: 揭秘Anthropic核心团队如何抛弃PRD和Google Docs，利用AI Agent实现“非技术人员写代码”和“自动化反馈闭环”，为未来组织形态提供可复制的蓝本。
正文内容
如果你现在还在用50%的工作时间写PRD（产品需求文档），或者在Google Docs里跟团队为了一个按钮的颜色吵上三天，那你可能正在被时代抛弃。
在硅谷最顶尖的AI实验室Anthropic，Claude Code的产品负责人Cat Wu正在进行一场悄无声息的革命。
这里没有冗长的飞书/钉钉文档，没有 endless 的需求评审会。他们甚至很少使用Google Docs。
取而代之的是什么？
是一个拥有1000+名内部活跃用户的实时反馈池，是一个每10分钟就会产生一条高质量反馈的极限测试环境，以及一个能让从没写过代码的设计师直接向主分支提交代码的“AI同事”。
这不仅仅是工具的升级，这是工作流的彻底重构。
Cat Wu，Claude Code的产品负责人（Product Lead）。
在接手这个项目之前，她是一名致力于强化学习（RL）环境的研究员。那时的她，每天大部分时间都在和枯燥的代码重构做斗争。
作为一名典型的“技术型PM”，她面临着一个巨大的反差：
一方面，她深知工程师最讨厌什么——被打断、写文档、处理重复的工单。 另一方面，作为产品负责人，她必须处理海量的用户反馈、维护路线图、确保产品不跑偏。
这似乎是一个死结。在传统互联网大厂，解决这个矛盾的方法是招更多的PM，写更厚的文档，开更长的会。
但Cat Wu面临的挑战更棘手。
Claude Code是一个基于终端（Terminal）的AI编程工具。它的用户是全世界最挑剔的开发者。
在产品早期，Cat面临着核心冲突：
信息过载与迭代速度的矛盾。
Anthropic内部有超过1000名员工在使用Claude Code进行日常开发。这就意味着，Cat的团队每隔10分钟就会收到一条关于Bug或功能的反馈。
如果按照传统流程：收集反馈 -> 归档到Jira -> 编写PRD -> 排期 -> 开发 -> 测试。
这个链条太长了。等功能上线，黄花菜都凉了。
更糟糕的是，很多反馈非常琐碎。比如“这里需要一个进度条”或者“这个报错信息不准确”。让年薪百万美元的顶尖工程师去修这些边角料Bug，简直是资源的极大浪费。
但不修，用户体验就会从90分滑落到60分。
团队陷入了两难：是停下来修补细节，拖慢大版本的进度？还是无视细节，任由体验腐烂？
转折点发生在一个看似不起眼的“To-Do List”功能上。
工程师Sid在使用Claude Code重构代码时发现了一个痛点：当需要修改20个变量名时，AI往往改了5个就停下了，还会“幻觉”说自己改完了。
按照传统流程，Sid应该写个文档给PM，PM写个需求给算法团队，算法团队去调优模型。
但Sid没有。
他直接在终端里命令Claude Code：“你必须先列出一个To-Do List，每做完一个勾选一个，不做完不许停。”
奇迹发生了。仅仅是强迫模型“像人类一样写任务清单”，它就真的老老实实把30个任务全做完了，没有任何早停（Early Stopping）。
这个Bottom-up（自下而上）的瞬间让Cat Wu顿悟：
既然我们在做AI Agent，为什么我们还要用旧时代的流程来管理它？为什么不能让AI自己去处理这些流程？
从此，Claude Code团队确立了一个激进的原则：No Google Docs, Just Code.（别写文档，直接上代码）。
方法论拆解：打造AI原生团队的4个关键步骤
Cat Wu和她的团队是如何把这个理念落地的？通过拆解访谈，我们总结出了一套可复制的“AI原生工作流”。
第一步：用“原型”代替“文档”（Prototype over PRD）
在Claude Code团队，你几乎看不到传统的PRD。
当他们想做一个新功能（比如前面提到的To-Do List）时，流程是这样的：
- 工程师直接上手：工程师（甚至PM）直接在代码库里快速写一个原型。
- 全员狗粮（Dogfooding）：直接推送到内部版本，让Anthropic的1000名员工立即试用。
- 看数据说话：大家是理解了？困惑了？还是爱死它了？
- 决策：如果大家爱用，再花精力去优化代码结构；如果没人用，直接删掉代码。
数据支撑：很多后来被公开发布的核心功能，在内部其实已经迭代了2-3个版本，甚至有很多功能在内部试用阶段就被“杀”掉了，完全没有浪费写文档的时间。
第二步：用AI Agent处理海量反馈（Feedback Synthesis）
面对每10分钟一条的反馈轰炸，Cat Wu没有雇佣实习生来整理Excel。她把Claude Code连接到了公司的Slack和GitHub上。
她是这样工作的：
-
场景A：需求调研 当一个企业客户提出“我想要自定义子Agent的模型”时，Cat不会去翻烂聊天记录。 她直接在终端问Claude Code：
"Hey, check our internal feedback channels. Which other customers have asked for custom models by sub-agent?" （嘿，查一下内部反馈频道，还有哪些客户在这个子Agent上要求自定义模型？） AI会瞬间给出列表，Cat就能精准地知道这个需求的权重，并在功能上线后通知对的人。
-
场景B：GitHub Issue去重 开源项目最怕重复提问。 Cat利用Claude Code自动扫描GitHub Issues：
"Find duplicate issues related to connection timeouts and group them." （找出所有关于连接超时的重复Issue并把它们归类。） AI能自动识别语义重复，帮助团队极大地净化了Backlog。
第三步：让AI接管“最后一公里”的脏活（The Last 10%）
文档更新和逻辑审计是开发中最无聊的环节。
-
文档自动化： Cat透露，他们的功能文档，90%是由Claude Code自己写的。 当一个功能开发完，直接问AI：“根据这个PR（Pull Request）的内容，写一份文档草稿。” 人类只需要做最后的10%——校对准确性和润色语气。
-
逻辑审计： Claude Code有复杂的计费逻辑（Free用户、Pro用户、企业用户看到的提示都不同）。人工检查这些分支逻辑（Branching Logic）非常痛苦。 Cat现在的做法是直接问代码库：
"Trace the code for the rate limit warning flow for a Max Plan user versus a Prosumer user." （追踪一下Max套餐用户和Prosumer用户在触发速率限制时的代码流向。） AI能直接在庞大的代码库中梳理出逻辑路径，比看陈旧的架构图准确一万倍。
第四步：打破职业边界——设计师也能写代码
这是最反直觉的一点。
在传统团队，设计师Megan只能在Figma里画图，然后求着工程师还原。
但在Claude Code团队，Megan开始使用Claude Code工具自己写代码。
- 案例：Megan觉得控制台（Console）的UI间距不对，或者文案需要微调。
- 操作：她不再发截图给工程师，而是直接用自然语言告诉Claude Code：“把这个按钮的Padding调大一点，文案改成XX。”
- 结果：AI生成代码，Megan直接提交PR。
数据验证：Megan现在不仅能修改前端样式，甚至开始向核心库提交功能性的PR。这彻底打破了“PM/设计师 vs 工程师”的对立关系，让每个人都变成了Builder。
理论升华：康威定律的AI式解构
计算机界有一个著名的康威定律（Conway's Law）：设计系统的组织，其产生的设计等同于组织间的沟通结构。
Cat Wu的实践，实际上是在用AI重构康威定律。
在过去，组织结构是分层的（PM -> 设计 -> 开发 -> 测试），所以产品也是分块的，沟通成本极高。
引入Claude Code这样的AI Agent后，组织结构变成了一个个全能节点。PM可以用AI查代码，设计师可以用AI写代码，工程师可以用AI写文档。
中间层消失了。
当沟通成本被AI无限压缩时，组织的效能将不再受限于“协作带宽”，而是受限于“个体的想象力”。
这就是为什么他们不需要PRD。因为代码本身，加上AI的解释能力，就是最好的文档。
局限性提醒：不是所有团队都能这么玩
虽然听起来很性感，但Cat Wu的这套打法有明确的适用边界：
- 代码库规模：Cat提到，Claude Code本身的代码库相对较小（Small Codebase）。如果你的项目是几十年的屎山代码（Legacy Code），AI在理解全局上下文时可能会经常“幻觉”。
- 容错率：他们推崇“Ship to dogfooding”（内部试错）。如果你的产品是医疗设备或银行核心系统，这种“先上线再修Bug”的策略是绝对禁止的。
- 工具门槛：虽然设计师也能用，但这依然需要全员具备基本的Git知识和终端操作习惯。对于完全非技术背景的传统行业团队，上手门槛依然存在。
金句收尾
Cat Wu在访谈最后提到：“我们不需要完美的计划，我们需要的是快速的反馈。”
在这个AI以周为单位迭代的时代，“写文档”本身可能就是一种最大的技术债务。
别再做一个只会画大饼的PM了。
打开你的终端，装上AI工具，去读代码，去改Bug，去直接面对你的用户。
未来属于那些敢于弄脏双手的Builder。