Claude Code团队不写Google Docs。
这个做出我最常用的AI编程工具的团队，没有产品需求文档，没有三年规划，甚至连路线图都不怎么维护。产品负责人Cat说这话的时候，语气平静得像在陈述「今天天气不错」。
如果你的团队还在花三周写PRD，再花两周评审，那你可能正在用传真机时代的方式造AI产品。
Cat不是传统意义上的产品经理。她会自己提交代码。两个月前，团队和音乐制作人Rick Rubin合作推出「氛围编程」概念，品牌团队想加一个/vibe命令。Cat没写需求文档，也没找工程师，直接自己写代码提交了PR。
她说，「让别人做这个太慢了。」
这不是个例。团队的设计师Megan以前从不碰代码，现在她给Console（Anthropic的API管理平台）提PR，也给Claude Code本身提PR。PM写代码，设计师改后端，工程师直接把原型发给1000名内部用户测试。
角色的边界正在消失。
这个团队的诞生方式也很特别。2023年，Boris（Anthropic工程师）想更好地理解公司的API，就给自己做了个命令行工具。他没想着「做产品」，只是想提高自己的效率。
然后他的队友开始用。接着整个工程部门开始用。再后来，研究团队、数据科学家、产品经理都开始用。产品还没对外发布，内部病毒式传播因子就已经爆表。
Cat当时在做RL环境开发，发现这工具让她效率翻倍。她开始疯狂给Boris发反馈。当团队决定对外发布时，她立刻申请全职投入。
没有立项会议，没有可行性分析。产品从一个工程师的周末项目，变成了Anthropic的核心产品之一。
但真正的转折点不是Boris做了个工具，而是他们发现了一个反常识的事实——最好的产品功能，来自工程师直接把原型扔给用户。
他们如何在没有PRD的情况下发布功能
Claude Code的待办清单功能经历了三次形态变化，但从来没有一份正式的设计文档。
第一阶段：解决模型健忘症
工程师Sid发现，用户让Claude Code重构代码或批量改变量名时，AI经常做完前5个就忘了还有25个没做。这是个能力问题——模型缺少「工作记忆」。
Sid的解决方案简单粗暴：强制模型写下待办清单。就像人类工作时会列Todo一样，让AI也把任务写下来，然后不断提醒它「你还没做完」。
效果惊人。模型真的会把20-30项任务全做完，不再早停。
但这时的待办清单只是个「工具痕迹」——它会在终端里一闪而过，用户看到了，但转瞬即逝。
第二阶段：从痕迹到仪表盘
团队通过内部反馈发现，很多人其实不关心AI在「做什么」，他们关心的是AI「做到哪儿了」。
待办清单从工具的内部机制，变成了用户的进度追踪器。
如果它只在终端里闪过，用户就得疯狂往上翻屏才能看到当前进展。Boris开始实验新形态：让待办清单「钉」在屏幕上，随时可以通过/todo命令调出来。
这个过程中他们试过很多失败的方案。比如把待办清单塞进「思考泡泡」里（那个显示AI正在思考的小UI），结果用户完全不买账。
第三阶段：触发逻辑的调教
功能上线后，新问题来了：Claude Code开始为「一个任务」创建待办清单。
比如你让它「把这个变量改成驼峰命名」，它会认真地创建一个待办清单，写上一条「改变量名」，然后打勾完成。这太蠢了。
Cat说，这种情况下根本不需要待办清单，「直接做就完了」。
团队开始调教「触发逻辑」：什么时候该用待办清单，什么时候不该用。这是另一类评估体系——不是测「能不能做」，而是测「该不该做」。
他们定义了明确的黑白区域：一个任务不触发，三个以上任务必触发。灰色地带暂时放着，等用户反馈。
从想法到发布，整个过程没有一份PRD。
Sid提出问题，Boris做原型，发到内部1000人的测试频道，Cat根据反馈决定是否对外发布。每次迭代周期一到两周。功能在内部可能已经迭代了三次，外部用户才第一次看到。
问题出在下一步。
如果你觉得「没有PRD」意味着「没有规划」，那你误解了这个团队的工作方式。
Demo先行：原型就是文档
Cat给PM的建议里，第一条就是：「Demo not Docs」。
传统流程是：写文档 → 评审 → 排期 → 开发 → 上线。Claude Code团队的流程是：做原型 → 测试 → 上线。文档在这个流程里不存在。
原型就是最好的文档。
Cat说，当你不确定该不该做一个功能时，与其写五页分析报告，不如让Claude Code直接给你做一个能跑的版本。你体验10分钟，比读10页文档更清楚这东西有没有价值。
代码库就是最好的知识库。
团队的代码库很小，所以与其写「我们为什么做待办清单」的回顾文档，不如直接问Claude Code：「去GitHub找最早的待办清单PR，告诉我最初的设计意图。」它会直接翻出Sid当时写的提交信息和代码注释。
这个答案永远不会过期，因为源代码就是真相。
反馈就是最好的路线图。
团队有个内部Slack频道，1000多名Anthropic员工自愿加入（不是强制的）。Cat说他们每10分钟就会收到一条新反馈，质量都很高。
当一个需求被提10次，销售团队也来说「三个客户都在要这个」，GitHub Issue收到100个赞，这时候什么需求最紧急已经一目了然。不需要优先级矩阵，不需要评分系统。
Cat的工作不是「决定做什么」，而是「看见什么最重要」。
能力边界的消失
这个团队最激进的地方不是「不写文档」，而是「不再区分谁该做什么」。
设计师Megan的Claude Code配置文件第一句话是：「我是产品设计师，你需要把所有技术概念都给我解释清楚。」她现在会提交代码。
PM Cat会自己实现小功能。
工程师会直接跟客户聊需求。
Cat说，这不是因为他们特别全栈，而是Claude Code降低了「跨界成本」。设计师不需要真的学会写代码，她只需要学会「用自然语言描述她想改什么」，然后让AI写代码，她负责检查改动是否符合预期。
这带来了一个副作用：审查流程变简单了。
举例：Claude Code有很多计费逻辑，不同套餐（Pro/Enterprise/API用户）看到的提示信息都不一样。传统方式是PM写文档，工程师实现，QA测试所有分支。
现在Cat直接问Claude Code：「追踪所有套餐的计费提示逻辑，告诉我每个用户会看到什么。」AI把所有分支情况列出来，她扫一眼就知道有没有问题。
她不需要懂代码，但她能直接验证代码的正确性。
这种工作方式的理论内核，其实是一个很老的产品哲学：让正确答案自己浮现。
想想你上次去超市买电钻。你不是在买电钻，你是在买墙上那个洞。PRD就是电钻，原型就是那个洞。
传统产品流程假设「正确答案在纸上」，所以要花大量时间写文档、对齐认知、评审细节。但AI原生团队相信「正确答案在现实中」，所以直接做出来，让用户告诉你对不对。
这不是敏捷开发。敏捷仍然需要Sprint计划、Story拆分、验收标准。
这是更激进的东西：假设做原型的成本已经低到可以忽略，那产品流程还需要什么？
答案是：高频反馈 + 快速判断 + 持续迭代。
Cat说她无法规划两年后的产品形态，「因为六个月后的模型能力都没法预测」。但她能规划下周做什么，因为这周的反馈已经告诉她用户最痛的点在哪。
这种方法论有明确的适用边界。
如果你的团队没有1000个高质量的内部测试用户，这套方法会失效。因为你失去了「快速验证」的反馈回路，原型做出来也不知道对不对。
如果你的产品涉及硬件、合规、或者改动成本极高的底层架构，「原型先行」会变成「翻车先行」。有些东西确实需要在纸上想清楚再动手。
如果你的团队没有强大的工程文化，PM写代码会变成「制造技术债」。Cat能提交代码是因为她有工程背景，而且团队有严格的Code Review。这不是鼓励所有PM直接提PR，而是说「当工具成本足够低时，角色边界可以适度模糊」。
Cat最后说的一句话我一直记得：「我们做的是下周想用的产品，不是明年想用的产品。」
因为明年的模型可能让今天的所有规划都过时。