Claude Code产品经理亲述：我是如何用AI彻底重构PM工作流的

AI模型能力的进化速度正在颠覆产品管理的传统逻辑。根据METR的研究数据，AI模型的能力每16个月就能提升41倍。这意味着产品经理在上个月还认为「AI做不了」的功能，可能在模型更新后就变得轻而易举。当技术限制的窗口期大幅缩短，传统的「花三个月做规划再执行」的工作方式正在失效。

三工具分工协作：日常工作流揭秘

Cat Wu的经历极具代表性。她工程师出身，后来转型做VC，但在投资岗位上依然闲不住——写脚本自动化扫描Twitter寻找新公司、监测GitHub上的热门开源项目。2024年8月加入Anthropic担任研究PM后，她开始用Claude Code各种「搞事情」：做Streamlit应用分析用户反馈、跑评估测试模型能力、甚至搭建强化学习环境。几百小时的工作量，她一行代码都没手写，全通过与Claude Code对话完成。这个经历让她意识到：以前PM有想法得先说服工程师排期，等两周才能看到原型；现在她自己下午就能做出来。

转变一：从长期路线图到短周期实验

经过长期探索，Cat Wu总结出一套清晰的三工具分工体系。核心思路不是思考「这是什么任务」，而是明确「我要什么输出」： • Claude.ai：用于思考。当写策略文档没思路、或遇到棘手问题需要理清时，就找它纯聊天。不需要AI动手做什么产出，只是对话梳理思路。 • Claude Code：用于构建。只要最后输出是代码——想要一个能跑的原型、想写个脚本跑数据——就交给它。 • Cowork：用于处理杂事。清理邮件、管理待办、做PPT、翻阅Slack历史记录查找当时为何做出某决策、订机票酒店等。 这套工作流正在被更多产品人验证。Decagon产品总监Bihan Jiang表示：「以前做个能演示的东西要几周，现在几小时就行。我在Cowork里把Slack聊天记录、代码库、文档都扔进去，让它理解背景，然后切到Claude Code，下午就能拿出可以给用户看的版本。」

转变二：从文档优先到Demo优先

传统PM的工作流程是：花两周调研，写PRD，开评审会，排进路线图，等工程师开发。整个流程走下来，两三个月过去了。但Claude Code团队现在的做法截然不同：鼓励所有人（工程师、PM、设计师）随时做「side quest」——有想法别开会，下午自己就去试试。测测那个你觉得「AI应该做不到」的功能，或者故意给模型出难题看看它能到什么程度。 事实上，Anthropic最火的几个功能——桌面版Claude Code、AskUserQuestion工具、todo lists——都是这么「玩」出来的，而非规划出来的。 团队现在基本不开传统站会，改成「Demo分享会」。有新想法就做个能跑的原型出来，让内部用户试试。如果大家真的在用，就继续打磨；没人理，就算了。一个下午就能做出来，试错成本极低。

转变三：保持简单，避免过度工程

另一个重要转变是「Demo优先」。Cat Wu的建议是：写完需求文档后，先别发给团队，发给Claude Code试试它能不能做出来。哪怕是个粗糙的原型，也比一堆文字更能说明问题。 同时，她推荐做评估测试（evals）。以Agent teams功能（让多个Claude Code协同工作）为例，团队成员Conner专门做了一套测试：什么场景下有效、什么时候会出问题、该怎么改进。数据支撑下，抽象的功能描述变得具体可衡量。 此外，每次新模型发布后，都值得把已有功能重新审视一遍。你上个月发布的功能，这个月新模型可能让它突然变强了。Chrome集成功能就是这个逻辑——团队发现用户在Claude Code里做web应用后手动切到浏览器测试，来回复制粘贴指令。虽然流程麻烦，但用户真的在这么做，于是团队直接把它做成了产品功能。 Cat Wu特别提醒：做新功能时别一上来就想着省token成本。先用足够多的token把能力做出来，确认功能可行。等后面便宜的模型能力上来，成本自然就降下来了。

如有侵权，请联系删除。