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

代码越来越便宜之后，真正稀缺的不是把需求更快喂给模型，而是判断什么值得做、怎样才算做好，以及如何从真实反馈里持续修正。

这是我从 Cat Wu 的访谈和文章里看到的核心变化。她负责 Claude Code 与 Cowork，却没有把 AI-native 产品管理描述成“更快写 PRD、更快发功能”。相反，她强调的是一组更难的工作：在模型能力不断变化时设定清晰目标，让团队能自主做决定；把想法快速送到用户手里；识别哪些旧脚手架已经过时；并在人和模型之间保留对风险、体验与组织关系的最终判断。

换句话说，当代码生产趋于便宜，产品优势不会消失，而会从“组织开发资源”转向“选择正确问题、定义正确体验、建立高质量反馈闭环，并持续删除不再必要的复杂性”。

一、PM 的重心从路线图转向反馈速度

Cat Wu 提到，过去产品功能可能按六到十二个月规划；现在 AI 加速工程、模型能力快速提高后，很多功能周期缩短到一个月、一周，甚至一天。PM 不应继续把主要精力放在多季度路线图上，而要思考怎样最快让想法抵达用户，并明确产品最重要、必须开箱即用的任务。

但缩短周期不等于取消方向。她仍然把“清晰目标”放在第一位。比如 Claude Code 面向企业专业开发者时，如果目标是“在安全前提下尽量减少权限提示疲劳”，这个目标本身就会排除许多看似可行、但不符合对象和约束的方案。

对 AI 工程交付团队来说，这意味着项目不应从一份宏大的方案开始，而应从可验证的交付目标开始。不要只写“建设智能知识平台”，而要写清楚：第一轮要让哪类任务变快，什么结果算成功，哪些错误不可接受，哪些结论必须能回查来源。

二、代码变便宜后，product taste 更贵了

Cat Wu 对未来能力的判断很直接：当代码更便宜，真正重要的是决定写什么代码，以及什么体验才是正确的。Claude Code 团队面对大量用户反馈，困难不在于把每个 issue 都实现出来，而在于判断哪些需求值得做，以及怎样做才对。

这里的 product taste 不是抽象的审美，而是三种取舍能力。

第一，需求筛选。哪些反馈代表高频真实问题，哪些只是局部偏好或短期噪声。

第二，体验定义。即使一个功能值得做，也要判断它是否真的减少用户负担，而不是只增加一个能力入口。

第三，时机判断。一个想法是一小时能试，还是需要长期基础设施，会直接改变优先级。

AI 可以低成本生成十种实现，但不会天然替团队回答“我们为什么服务这类用户”“什么失败会伤害信任”“什么复杂度不值得长期背负”。选择变多之后，选择质量反而更稀缺。

三、角色边界会重叠，但组织约束不能消失

Cat Wu 描述 Claude Code 团队时说，PM 会做部分工程工作，工程师会做产品决策，设计师也能落代码。这个趋势很容易被误读成“职能消失”。但她真正说的是：角色可以重叠，前提是团队有足够清楚的目标、原则和发布机制。

她提到几件很具体的做法：团队每周做 metrics readout，让所有人理解关键目标；团队明确 principles，让成员不用等 PM 批准每个决定；多数功能先以 research preview 发布，降低试验承诺成本；工程、文档、市场和开发者关系围绕持续发布机制协作。

这对 AI 团队尤其重要。模型让每个人都更容易动手，也会让团队更容易同时制造不一致的脚本、agent、知识片段和客户承诺。角色边界变松之后，需要的不是更多审批，而是更明确的公共边界：权威数据源在哪里，哪些输出可以预览，哪些必须审核才能进入正式资产，谁对客户承诺负责。

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

四、Demo 和 eval 取代的是空转文档，不是思考

Cat Wu 说 Claude Code 团队从 documentation-first 转向 prototype-first：与其在会上讲想法，不如展示 demo，让内部用户实际试用。因为下午就能完成原型，错误下注的成本下降了。

但 demo 只能展示能力，eval 才能支撑信任。她强调，不是每项功能都需要大型评测；有时十个高质量 eval 就足以帮助团队看清目标、进展和失败条件。尤其是 memory、agent workflow 这类非确定性功能，代表性任务和失败案例比抽象规格更有用。

对工程交付团队来说，交付件不应只有方案、代码和演示视频，还应包含一个小型证据包：典型任务集合、成功标准、不可接受错误、当前模型与提示配置下的结果、失败案例复现路径，以及人工审核位置。

如果团队用 AI 把资料编译成知识库，demo 可以展示漂亮页面；eval 必须进一步检查关键结论能否回查原文，是否产生不存在的关系，重复概念是否被错误合并，低质量来源是否污染核心页面。

五、模型变强后，团队要会删除旧复杂度

Cat Wu 最值得工程团队重视的观点之一，是模型进步后要主动删除旧机制。

她举过 todo list 的例子：早期 Claude Code 不一定可靠完成长任务，所以团队用系统提醒逼模型维护列表；当新模型自然具备更完整的执行能力后，这些提醒就可以移除。她还提到，随着模型升级，system prompt 和工具描述可以减少一部分。

这背后有两个相反动作：模型不可靠时，要建立约束、工具和验证机制；模型跨过能力门槛后，要删除只为旧缺陷存在的补偿逻辑。

但要区分补丁和护栏。提示模型记得更新待办事项，可能随着模型增强而取消；证据留痕、权限隔离、隐私控制、发布审批和回滚机制，不是模型变聪明就可以删除的东西。前者弥补能力不足，后者管理业务风险。

所以每个 harness、提示模板、工作流步骤和人工门禁，都应该标注它存在的原因。为了模型缺陷存在的，要定期重测能否简化；为了信任、合规和责任存在的，要作为治理机制保留下来。

结语

Cat Wu 的核心判断，不是 PM 会因为 AI 而变得更会写代码，而是团队必须重新理解什么值得由人负责。

代码生成成本降低，会淘汰一部分协调和制作上的稀缺性；但它同时把更大的压力推向目标选择、体验判断、反馈设计、风险治理和持续简化。

对 AI 工程交付团队来说，最快把东西做出来并不是终点。真正能沉淀为优势的是：快速制造可验证的候选方案，严格区分试验与正式资产，用证据决定什么值得保留，并在模型变强后及时删掉不再必要的复杂性。

代码会越来越便宜。决定什么值得沉淀、什么必须拒绝、什么可以放心交付，仍然昂贵。