代码越来越便宜之后，真正稀缺的是选择与闭环

代码越来越便宜之后，真正稀缺的是选择与闭环。从 Cat Wu 的实践看 AI-native 产品管理，以及 AI 工程交付团队该保留什么判断力。生成代码的成本正在快速下降。这件事最容易诱发一种过度简单的结论：既然工程执行可以被大幅加速，那么产品管理要么不再重要，要么只剩下把需求更快喂给模型。

Cat Wu 的判断恰恰相反。作为 Claude Code 与 Cowork 的产品负责人，她并不把 AI-native 产品管理描述成"更快写 PRD、更快发功能"，而是描述成一组更难的工作：在技术能力不断改变的情况下，判断什么值得做；为团队设定足够清楚的目标，使更多人能自主做决定；让试验迅速抵达真实用户并产生反馈；识别哪些产品脚手架已经过时；以及在人和模型之间保留对风险、体验与组织关系的最终判断。

本文的总论点是：当代码生产趋于便宜，产品竞争优势不会消失，而会从"组织开发资源"转向"选择正确问题、定义正确体验、建立高质量反馈闭环，并持续删除因旧能力限制而存在的复杂性"。 对 AI 工程交付团队而言，这意味着交付速度只是入场券；真正能沉淀为优势的，是对目标、证据、质量和知识资产的治理能力。

本文依据两份一手材料：Cat Wu 在 Lenny's Podcast 的访谈 transcript，以及她本人署名的文章 Product management on the AI exponential。文中凡是描述其观点之处均标注来源；涉及对一般团队的推广，则明确作为分析提出。

一、PM 的重心从协调路线图，转向压缩 idea-to-feedback 时间

Cat Wu 最直接的观察是产品开发周期发生了数量级变化。在访谈中，她说过去产品功能通常按六到十二个月规划，而 AI 加速工程、模型能力快速提高后，许多功能的周期已经缩短到一个月、一周，甚至一天。因此，PM 不应继续把主要精力放在跨团队对齐多季度 roadmap 上，而应思考怎样最快把想法送到用户手中，并定义产品最重要、必须开箱即用的任务。（Lenny 访谈，00:05:03-00:06:37）

她的署名文章给出了同一判断的理论版本：传统 PM 流程隐含一个前提，即项目开始和结束时技术可能性基本不变；但模型进步会让项目中途原本的约束消失。因此，新的节奏不是"前期尽可能确定、随后执行长期计划"，而是快速实验、持续交付，并对有效方向加倍投入。（署名文章，开篇；Leaning into the AI exponential）

这里容易产生误读：缩短反馈周期，不等于取消方向。Cat Wu 强调的第一件事仍是"设定清晰目标"。她以企业专业开发者的权限提示疲劳为例：如果目标是让这类用户在安全前提下趋近于零 permission prompts，这一目标本身就会排除许多看似可行却不符合对象和约束的方案。（Lenny 访谈，00:06:57-00:07:42）

因此，她主张的不是"先做再说"，而是把规划压缩为更硬、更小、更能驱动选择的目标：目标用户是谁，核心任务是什么，哪种失败不可接受，然后尽快向真实反馈暴露方案。

对 AI 工程交付团队的含义是：交付流程不应再从一份大而完整的方案开始，而应从可验证的交付目标开始。例如，与其写"为客户建设一套智能知识平台"，不如明确第一轮目标是"让一类工程事故复盘在十分钟内生成可回查来源的初稿，且关键结论不可脱离原始证据"。前者会催生无限需求；后者能同时约束实现、验收和风险。

二、代码变便宜之后，product taste 不是审美，而是稀缺的取舍能力

在访谈中，Cat Wu 对"未来什么能力最重要"的回答非常明确：当代码更便宜，变得更重要的是决定写什么代码，什么体验才是正确而令人满意的体验。Claude Code 团队面对大量 GitHub issue，真正困难的不在于把每个需求实现出来，而在于判断哪些值得做，以及怎样做才对。（Lenny 访谈，00:16:15-00:18:53）

这就是她所说的 product taste。它并不是"有品味"的模糊称赞，而包含至少三层可操作判断：

• 需求筛选：用户提出的要求中，哪些代表高价值反复出现的问题，哪些只是局部偏好或短期噪声。
• 体验定义：即使某个功能值得做，也要判断怎样的交互路径真正减少用户负担，而非仅增加一个能力入口。
• 成本与时机判断：工程背景在当下仍有帮助，因为知道一个想法是"一小时即可试验"还是需要长期基础设施，会改变优先级决策。（Lenny 访谈，00:18:53-00:19:59）

更深的一层是，模型能力本身成为产品变量。Cat Wu 说，最难的技能之一，是判断一个月后的产品应是什么样：模型能力和用户行为都可能发生变化，优秀 PM 要从用户如何突破现有产品限制中识别模式，设定方向，并在能力变化时调整路径。（Lenny 访谈，00:51:35-00:53:19）

这解释了为什么 AI 不会自动消除产品判断。模型可以低成本生成十种实现，却不会自然替团队承担"我们为何服务这类用户""什么失败会伤害信任""什么复杂度不值得长期背负"这些责任。选择增多，反而会提高选择质量的价值。

对 AI 工程交付团队而言，product taste 应被转化为验收纪律，而不是依赖某位负责人的直觉。每项 AI 交付至少需要回答四个问题：它解决的是哪个高频真实任务；什么结果算让用户得到实质收益；什么错误即使出现一次也不可接受；如果模型下个月明显变强，当前实现中哪些部分应能被删除。无法回答这四个问题的"快速交付"，很可能只是更快速地生产维护负担。

三、角色边界会重叠，但清晰目标和发布机制不会自动出现

Cat Wu 描述 Claude Code 团队时指出，PM 在做部分工程工作，工程师在做产品决策，设计师也会落代码。她说团队倾向招聘具有 product taste 的工程师，因为一些工程师能够从看到用户反馈到周末前发布产品，几乎无需产品介入；她也提到团队的 PM 多数有工程背景或会直接 ship code，设计师亦有前端工程经历。（Lenny 访谈，00:16:15-00:18:16）

这一描述常被理解为"职能消失"。但她给出的实际做法说明，角色边界变模糊并没有消除组织设计，反而要求有人搭好团队自主行动的框架：

• 团队每周做 metrics readout，让每个人理解关键目标、趋势和驱动因素。
• 团队明确 principles，包括关键用户、取舍方式以及愿意牺牲什么，从而让成员不必等待 PM 批准每个决定。
• 多数功能先以 research preview 发布，清楚告知用户这是早期想法、仍在迭代、未必长期支持，从而降低试验承诺成本。
• 工程、文档、市场和开发者关系围绕 evergreen launch room 建立快速发布协作路径，让已被内部试用的功能能够迅速对外沟通。（Lenny 访谈，00:07:42-00:10:29）

署名文章进一步强调：角色融合之所以可行，不是因为所有人随意行动，而是因为清晰战略和目标允许成员自主排序；PM 的任务是为模型快速变化造成的模糊性建立清晰度，并清除更快发布的障碍。（署名文章，Leaning into the AI exponential）

这对 AI 工程交付非常关键。模型可以让每个人都更容易动手，却也会让团队更容易同时制造不一致的脚本、agent、知识片段和客户承诺。角色边界松动之后，团队需要更少的审批等待，但更明确的公共约束：权威数据源在哪里，哪些输出可以预览、哪些必须审核才能交付，谁对客户承诺负责，哪些证据必须保留。

换言之，AI-native 团队不是取消流程，而是把流程从"控制谁可以做事"改造成"让更多人能在清楚边界内安全做事"。

四、Demo 与 eval 取代的不是思考，而是空转的文档确定性

Cat Wu 在署名文章中说，Claude Code 团队大幅从 documentation-first 转向 prototype-first：与其在传统站会上报告想法，不如展示 demo，让内部用户实际尝试；因为下午就可以完成原型，错误下注的成本降低。她也指出，eval 能把抽象功能变具体，例如通过为 agent teams 手工设计评测，识别它在什么条件下工作、什么条件下失败，以及接下来修什么。（署名文章，Encourage demos and evals over docs）

在访谈中，她对此做了更有边界的补充。她并未说所有功能都应建立大型评测体系，而是指出，只做十个高质量 eval 就足以帮助团队量化目标、进展和缺失；当某个功能需要更多产品定义时，她会用少量 eval 明确哪些场景成功、哪些失败，以及什么提示方式提高成功率。她同时明确表示，并非每项功能都需要 eval，memory 这类功能尤其受益。（Lenny 访谈，00:53:32-00:56:46）

这透露出一种适用于 AI 产品的定义方式：对于非确定性系统，规格说明书只描述意图；代表性任务、失败案例和可复现证据，才能描述系统实际上是否有效。

对 AI 工程交付团队而言，交付件不应只有方案、代码和演示视频，还应包含一个小型证据包：

• 真实或脱敏后的典型任务集合；
• 成功标准与不可接受错误；
• 当前模型和提示配置在这些任务上的结果；
• 失败案例的复现路径；
• 人工审核位置与升级规则。

例如，若团队使用模型把原始资料编译成知识库，demo 可以展示一篇文章生成了漂亮的概念页，但 eval 必须进一步检查：关键结论能否回查原文，是否产生不存在的关系，重复概念是否被错误合并，低质量来源是否污染核心页面。速度能展示能力，证据才能支撑信任。

五、模型进步要求团队会删除：不要把临时补丁误当护城河

Cat Wu 最值得工程团队重视的观点之一，不是如何增加 agent 功能，而是如何在模型变化后主动删除旧机制。

她在文章中以 todo lists 为例：早期 Claude Code 不会可靠地完成长任务中的所有项目，因此团队通过系统提醒促使模型维护列表；当新模型自然具备更完整的执行能力后，提醒机制便被移除。她提到，随着 Opus 4.6 上线，系统提示与工具描述能够减少约 20%。（署名文章，Do the simple thing）

在访谈中，她进一步说明，团队每次发布新模型都会重新阅读整个 system prompt，逐段判断模型是否仍需这些提醒；与此同时，模型升级也让过去准确率不足以发布的 code review 功能达到可依赖状态。（Lenny 访谈，01:01:03-01:04:52）

这一观点包含两个相反但同样重要的动作：

• 当模型尚不可靠时，建立明确的约束、工具和验证机制，补足它的不足。
• 当模型已经跨过能力门槛时，删除只为旧缺陷存在的复杂机制，避免产品被历史补丁拖累。

这里需要谨慎区分"补丁"和"护栏"。让模型记得更新待办事项，可能随着模型增强而无需强制；但证据留痕、权限隔离、发布审批、隐私控制、可回滚机制，并不是模型变聪明就可以随意删除的东西。这些机制约束的是业务风险和责任，而非模型智力不足。

对 AI 工程交付团队的推论是：harness、提示模板、工作流步骤与人工门禁都应标注其存在原因。若一个步骤是为了弥补模型当下能力，就应定期重测是否可简化；若一个步骤是为了满足客户信任、法规、来源追溯或损失控制，就应把它视为治理机制，而不是等待模型升级后被"优化掉"的摩擦。

六、人类仍需把关的地方：隐性关系、可靠性与真实价值

Cat Wu 并没有把更快发布说成没有成本。她坦言，大量发布会牺牲产品一致性：重叠功能会让新用户不知道最佳路径，用户也会因为变化太快而感觉必须每天追踪最新动态。（Lenny 访谈，00:25:00-00:27:57）这是对"速度优先"非常重要的自我限制：更快的实验速度必须由更好的教育、整合和淘汰机制来偿还。

她也明确指出，目前人类仍提供模型欠缺的常识与 tacit EQ：一次发布涉及大量细节，模型并不总能理解所有利益相关方、他们之间的关系、偏好以及应通过什么渠道保持沟通。（Lenny 访谈，00:21:43-00:22:27）

在个人自动化方面，她甚至给出相当严格的可靠性标准：一个自动化如果只达到 90% 或 95% 而不能被真正依赖，其价值很有限；要选择确实需要的自动化，把最后的可靠性补足。她同时提醒，沉迷定制技能、MCP 和工作流本身，可能使人忘记原本要发布的产品或完成的任务；简单配置往往更有效。（Lenny 访谈，01:09:46-01:13:58）

这几处表述共同构成了对其"快"哲学的纠偏：AI 让制作便宜，不代表错误便宜；它让原型便宜，不代表交付承诺、客户信任和知识污染的成本也下降。

对工程交付团队尤其如此。生成一份看似完整的技术报告、一套代码变更或一组知识页可能只需要几分钟，但错误的依赖升级、遗漏的安全条件、未经证实却进入组织知识层的结论，都会在后续重复使用时放大成本。模型适合扩大候选方案和执行吞吐量；人类仍必须对进入生产、客户环境与长期知识资产的内容承担判定责任。

哪些不能照搬 Anthropic

Cat Wu 的方法具有启发性，但其经验来自一个非常特殊的环境，普通团队不能直接把结果当成公式。

首先，Anthropic 同时拥有前沿模型、产品团队、密集内部 dogfooding 用户和快速反馈渠道。Cat Wu 自己承认，团队幸运地能够使用 frontier models；她也描述了员工能够广泛使用 Claude Code、Cowork、Slack 历史上下文与内部发布渠道的环境。（Lenny 访谈，00:11:03-00:11:46；00:32:44-00:50:49）普通公司若缺少高质量内部试用群体和足够计算预算，research preview 的学习速度可能显著更慢。

其次，Claude Code 是面向开发者的工具，用户愿意尝试新能力、接受一定程度的试验性。医疗、财务、法律审批或关键企业操作中的 AI 产品，不能因为原型便宜就把相同程度的不确定性交给外部用户。可逆的试验适合加速；不可逆或高损害的动作仍需前置治理。

再次，"低流程"依赖高人才密度和共同目标。Cat Wu 描述的团队中，大量工程师具备产品判断，PM 和设计人员也能落代码，且存在清晰原则、指标 readout 和快速协作渠道。缺少这些基础时，简单削减流程不会产生自主性，而会产生方向分散、返工和质量事故。

最后，她关于自动化接近 100% 才真正可依赖的说法，更适合作为高风险自动执行的要求，而不是所有 AI 辅助工作的统一门槛。对于带人工审阅的研究初稿、候选分类或创意探索，低于完全可靠的工具仍可能显著有用。关键不在于统一准确率，而在于失败的损害程度、是否可发现、是否可逆，以及谁承担最后审核。

对 AI 工程交付团队的行动建议

• 以可验证目标替代大方案开局。 每个 AI 交付先定义用户、核心任务、成功标准与不可接受错误，再开始生成代码或原型。
• 把快速原型放进隔离区。 对新 agent、自动化和知识编译链路，先生成 preview 或候选输出，不直接修改生产数据、客户资产或正式知识层；审核通过再合入。
• 为关键流程建立少量高价值 eval。 不以评测数量取胜，先选择十个左右真正代表价值和风险的任务，持续记录模型、提示词、工具链变更前后的结果。
• 保留来源与证据链。 对研究、知识整理、决策辅助和客户输出，模型生成的关键判断必须能回查原始材料、日志或输入条件；没有证据的强结论不得成为长期资产。
• 让团队成员能行动，但公开边界。 明确哪些改动可自主试验，哪些需要安全或客户审核；建立轻量发布渠道、指标回看和失败复盘，而不是让每个决定排队等待审批。
• 定期审计 harness 与提示复杂度。 新模型上线后，重新运行 eval，识别哪些提醒、编排和补偿逻辑已可删除；同时不要误删权限、证据、隐私和回滚等风险护栏。
• 以真实日常使用判断价值。 优先投资每天会被使用、能积累反馈的内部工具或交付流程；对只展示一次、随后无人依赖的原型保持克制。
• 把"产品品味"做成组织学习。 收集可靠用户反馈与失败案例，记录为何选择一个方案而放弃另一个方案；让判断标准成为团队可复用的知识，而不是少数人的隐性直觉。

结语

Cat Wu 的核心判断，不是 PM 会因为 AI 而变得更会写代码，而是团队必须重新理解什么值得由人来负责。代码生成成本降低，会淘汰一部分协调与制作上的稀缺性；但它同时把更大的压力推向目标选择、体验判断、反馈设计、风险治理和持续简化。

对于 AI 工程交付团队，最快把东西做出来并不是终点。真正形成优势的是：能够快速制造可验证的候选方案，严格区分试验与正式资产，用证据决定什么值得保留，并在模型变强后及时删去已经没有必要的复杂性。代码会越来越便宜；决定什么值得沉淀、什么必须拒绝、什么可以放心交付，仍然昂贵。

关键证据索引