读完 Claude Code 产品负责人的方法论，我觉得 AI PM 最难的不是方法，而是判断

date

Apr 6, 2026

slug

ai-pm-methodology-the-hard-part

status

Published

summary

AI 让信息越来越便宜，但做判断越来越难了。读完 Claude Code 产品负责人的 AI PM 方法论之后的一些思考。

我也是这么干的

先说做法本身。这部分我和她的观点高度一致。

原型先行。 我做 AI 功能，通常也是先搭一个能跑的 demo，而不是先写一份完整文档。有时候是一个可以直接上手体验的前端原型；有时候则是一个把业务逻辑跑通的脚本，里面把路由策略、工具调用、结构化输出都串起来。对我来说，这类东西既是方案表达，也是评估载体，很多时候本身就是 spec，不需要再额外写一份说明文档。当然这不意味着不要文档（PS：我甚至做了一个从 demo 反向生成需求文档的 Agent Skill），但起点一定是一个能跑的东西，而不是一份描述它应该怎么跑的文字。

而且，AI 产品里的「原型」和传统产品里的原型，本来就不是一回事。做传统产品，一个可交互页面往往足够验证流程和交互；但 AI 产品真正的不确定性不在界面上，而在模型行为上：它能不能理解输入、该不该调工具、输出是否稳定、结构化结果能不能落到预期的 schema 里。一个纯前端 mockup 回答不了这些问题。AI 产品的原型必须让真实模型跑起来，哪怕 UI 很粗糙都没关系，但关键逻辑必须是真的。凭空想象模型的行为然后画一个交互稿，做出来的东西和实际表现之间的差距可能大到让整个方案推倒重来。

评估驱动。 这一直是我做 AI 产品时最看重的事。我去年写过一篇文章专门讲这件事：AI 产品从确定性走向概率性，同样的输入可能产生不同的输出，你没办法像传统软件那样靠 if-else 的逻辑去保证正确性，只能靠系统性的评估去理解真实表现。Cat Wu 说她的团队用 eval 来量化功能效果，我的做法是把评估直接嵌入工作流。评估的不只是模型和提示词，编排策略怎么设计、工具调用怎么定义、结构化输出的 schema 怎么约束，这些都是变量，都要拿真实用例去跑。多个模型 × 多种策略 × 多组用例交叉下来，才能看到每种组合的真实表现和失败模式。这套东西搭建起来有成本，但一旦跑通，后续每一次决策都有据可依。

持续回测。 新模型出来，真正有价值的动作从来不是「试两个 prompt 看看感觉」，而是把它带回自己的业务场景，用自己的评测用例去跑一遍。通用 benchmark 上的排名和你实际场景里的表现经常不是一回事。Cat Wu 文章里也强调了每次新模型发布都值得重新审视已上线功能，这一点我非常认同。

这些做 AI 产品的人大多都在往这个方向走，并不算稀奇。真正值得展开的，是她文中提到、但没有深讲的那部分。

「做能工作的最简单实现」听起来很简单

原文里我最在意的一句，其实是：do the simple thing that works。这句话比「做最简单的实现」更准确，因为关键不只是简单，而是「能工作」。

Cat Wu 给的例子也很典型：Claude Code 的 todo list 功能刚上线时，模型不会稳定地把完成项勾掉，于是团队每隔几条消息插入一次提醒，催 agent 去更新自己的 todo list。下个模型升级之后，这个行为模型自己就会了，提醒直接删掉。她还提到，随着模型升级，system prompt 和工具描述不断被精简，到了 Opus 4.6 又削掉了大约 20%。

很顺的一个循环：加临时方案，等模型升级，删掉临时方案。之所以顺，是因为在这个叙事里，决定性变量主要是模型能力本身。

她其实也提到了成本的问题，原文说先为能力优化，用比你觉得需要的更多的 token，之后可以等更便宜的模型追上来再压成本。这个思路没错，但她没有展开的是：当你真的开始在多个模型之间做选择的时候，事情会复杂很多。

做 AI 产品不太可能只用一个模型。成本、速度、能力各有侧重，便宜的模型适合跑用户高频使用的日常功能，贵的模型留给需要强推理能力的场景，有时候还要针对不同地区或不同供应商的稳定性做备选。这就意味着你同时在用好几个模型，而它们的迭代节奏完全不同。

只依赖一个模型的时候，「做能工作的最简单实现」执行起来很顺，等模型升级，删掉旧的临时方案，收工。同时用好几个模型的时候，同一个临时方案在旗舰模型上可能一两个月就能去掉了，在便宜模型上可能半年都还得留着。你不能全切贵的，成本扛不住；也不能干等便宜的追上来，体验跟不上。

所以这条原则本身我还是认同，只是到了多模型环境里，「简单」不再意味着「等下个模型就行」，而是意味着你要不断判断：这个临时方案在哪个模型上还要留多久？什么时候该切？切了之后成本怎么变？不同模型之间要不要维护不同策略？真正难的，不是知道要做简单实现，而是知道什么阶段该简，什么阶段还不能简。

支线任务

Cat Wu 在文中用了一个很贴切的说法：side quest（按照个人习惯，翻译成支线任务，开放世界你知道吧？）。她的意思是，团队里每个人都可以拿出一小段时间，做一些路线图之外的自发实验：搭个没人要求的原型，试试模型的新边界，验证一个原本只存在于直觉里的想法。她提到 Claude Code 的一些受欢迎功能：桌面端支持、AskUserQuestion 工具、todo list 等等就是这样长出来的。

这件事我也很有共鸣。对我来说，很多真正推动决策的工作，本质上都是支线任务。有时候是把一个还停留在讨论里的功能，先做成可运行的原型，看看它到底跑不跑得通；有时候是在设计正式开始之前，先把评测框架搭起来，这样后面方案一出来就能直接测；有时候纯粹是因为新模型刚发布，我想知道它在自己的场景里到底比老模型强了多少。

这些支线任务确实推动了很多产品决策。有的原型直接改变了方案方向，有的评测结果让团队在两个争论不下的方案之间有了明确依据。

但支线任务能不能持续产出价值，不只取决于你自己愿不愿意做。 你花半天验证了一个方向，团队的注意力可能已经转走了；你证明一个方案可行，但产品重心突然调整了；你想把上次支线任务的成果接回主线，却被新的优先级覆盖掉了。这些不是例外，反而是现实里很常见的问题。

单次看，一个支线任务被搁置好像没什么大不了。但如果这种事反复发生，代价就会累积成更大的问题：你会持续错过窗口，新模型带来的能力窗口、用户需求变化的窗口、竞品还没反应过来但你已经验证过可行性的窗口。Cat Wu 说 Claude Code 的很多功能是从支线任务里长出来的，反过来说，如果那些支线任务当时没有得到团队的响应和跟进，这些功能可能就永远不会上线。

所以我越来越觉得，支线任务不是「个人是否足够积极」的问题，而是「团队有没有能力吸收个人试出来的东西」。Cat Wu 描述的 Anthropic 是一种组织级的状态：不同角色都在主动跨界做实验，支线任务是团队的默认行为，不是某个人的个人习惯。当这种工作方式只在个别角色身上发生，而不是整个团队的风格时，「角色边界模糊带来的加速」就很难带来产品上的演进。

实践里更难、但原文着墨不多的部分

原文整体是乐观的：模型更强，工具更好用，团队更快。作为方法论介绍，这没有问题。但在实际做事时，有几件事的存在感其实非常强。

AI 把瓶颈从信息获取挪到了判断与取舍。 以前难的是信息不够：搜集、整理、比较、验证，都很慢。现在 AI 几分钟就能铺出十种都说得通的方案。信息获取的成本被压得很低，但「到底选哪个」这件事并没有因此变简单，很多时候反而更难。因为你看到的取舍更多了，每个选项都不荒谬，每个选项都有道理，而最后拍板靠的仍然是你对业务的理解、对风险的偏好、对时机的判断。工具越强，判断越值钱。

最大的风险不是 AI 做不到，而是它做出了一个「看起来对」的东西。 报错不可怕，报错是诚实的失败。真正麻烦的是它产出了一个逻辑自洽、运行正常、甚至局部表现不错，但整体行为和你目标并不一致的结果。很多 AI 原型最危险的地方，不在于它跑不通，而在于它跑得太通顺，以至于你误把「能运行」当成「已验证」。

评测减少了未知，但没有替你做选择。 跑完一轮评测，你拿到的常常不是答案，而是一组取舍：这个模型准确率高但贵，那个便宜但某类场景会出错，另一个速度快但输出格式不稳定。评测当然重要，它至少让你不再在黑暗里做决定；但它并不会把复杂选择变成单选题。很多时候，数据越充分，你看到的矛盾越清楚，决策也就越难。

评估本身也越来越像一个独立的系统工程。 最早期的评估很直接：出一组问题，对一组标准答案，看对了几个。后来产品逻辑变复杂了，评估开始变成流程化的事情：定义一套 workflow，规定每一步的输入输出和判断标准，按流程跑一遍看结果。再后来产品开始用 Agent 架构，评估的对象就不再是单个回答了，而是一整条决策链路：它选了什么路由、调了什么工具、中间状态对不对、最终结果合不合理。你没办法用一个固定答案去判对错，因为合理的路径可能有好几条。这意味着评估本身也在从固定流程走向 agentic 化：你可能需要用 agent 去评估 agent，用模拟环境去复现真实场景，用运行时的行为轨迹去做判断而不只是比对最终输出。针对自己业务的评估体系会越来越重，越来越像一个需要持续投入的工程问题。

Excalidraw 这个故事成立的前提

Cat Wu 的 Excalidraw 例子之所以让人觉得理所当然，是因为这个故事里最显眼的变量几乎只有模型能力：模型弱的时候做不到，模型强了就做到了。这个叙事非常顺，也非常有说服力。

但它之所以能成立，还有一个前提：她所在的团队与模型演进之间的距离很短。原文里其实也反复在讲，团队会随着模型能力变化快速重做原型、回看功能、压缩 prompt 和工具描述，并且原型阶段优先追求 capability，再等待更便宜的模型追上来。对拥有模型、并且能更早感知模型变化的团队来说，这种节奏天然更顺。

而大多数做 AI 产品的团队，并不拥有模型，而是站在模型之上做产品。你没有办法决定模型什么时候变强、朝哪个方向变强、价格怎么改、供应是否稳定。你能做的，是持续评估、持续对比、持续适配。

当然，反过来看，不绑定一家也意味着你拥有选择权。你可以把同一个功能放到多个模型上跑，选最适合自己的那个；你可以在不同链路里搭配不同模型，把能力、成本和速度压到一个更合适的组合上；某一家涨价、波动或者退步了，你也可以换。拥有模型的一方少了一层选型的压力，不拥有模型的一方则必须把选择本身做成能力。

但选择本身也是成本。你要维护的不只是一个功能，而是一组不断变化的判断：哪个模型该用在什么地方；哪个临时方案在谁身上还能留多久；什么时候该为了能力付更高成本，什么时候该为了成本接受不完美；某个支线任务验证出来的方向，到底该不该现在接进主线。

这些问题，原型回答不了，评测也只能回答一部分。最后真正要做决定的，还是人。

所以我读完这篇文章，最大的感受不是「这些方法对不对」，而是最难的那一步始终没变。Demo 可以更快搭，评测可以更全面跑，原型可以更容易出，但什么时候该删临时方案、什么时候该换模型、什么时候该把支线任务推进主线，这些仍然是人的工作。

AI 的确改变了产品工作的成本结构：信息更便宜了，原型更便宜了，试错也更便宜了。但它没有让判断更便宜。恰恰相反，判断变成了更贵的部分。