Article

In The AI Era, Judgment Is Scarcer Than Execution

As AI accelerates code, documentation, design, and execution, the product bottleneck moves from who can do the work to who can define the problem, manage complexity, review results, and own delivery.

Jun 08, 2026 Updated Jun 08, 2026
  • AI
  • Product judgment
  • AI PM
  • Agent

The full article body is currently published in Chinese. English titles, summaries, and site navigation are available first; full translations can be added article by article.

过去讨论 AI,我们经常问:

AI 到底能不能写代码?能不能做设计?能不能把一个产品直接做出来?

如果只看执行能力,答案已经越来越清楚:

AI 很强。

它可以理解需求、生成代码、补全接口、修改 bug、重构模块、编写文档、生成测试、整理方案,甚至同时推进多个任务分支。

但另一个问题也变得更明显:

代码生成得越来越快,产品并不会因此自动变好。

很多时候,AI 写出来的代码没有明显错误。真正需要反复调整的,反而是产品本身:

  • 页面信息层级是否合理;
  • 用户第一眼应该看到什么;
  • 功能边界是否过度扩张;
  • 交互是否让用户有掌控感;
  • 任务流程是否足够清楚;
  • 系统复杂度是否已经超过用户和团队的承载能力。

这说明 AI 改变的不只是生产效率。

它改变了生产瓶颈。

以前很多软件项目的瓶颈是:

人写不动代码。

现在 AI 介入后,瓶颈越来越像:

人审不过 AI 产生的复杂度。

AI 时代真正稀缺的,可能不再是单纯执行力,而是判断力。

AI 已经不只是工具

今天的 AI 在很多软件项目里,已经不能只看作一个辅助工具。

它更像一个高执行能力的生产单元。

它能做的事情包括:

  • 根据需求快速生成代码;
  • 根据现有代码理解系统结构;
  • 生成 PRD、技术方案、接口设计和数据库结构;
  • 生成 UI 页面、组件和交互方案;
  • 编写测试、修复错误、解释日志;
  • 协助重构、整理文档、补充注释;
  • 同时推进多个模块和任务分支。

过去一个人一次只能聚焦一个任务。

现在,一个人可以让多个 AI 会话同时推进:

  • 一个写前端;
  • 一个写后端;
  • 一个整理技术方案;
  • 一个改 UI;
  • 一个写文档;
  • 一个分析竞品;
  • 一个做 review。

表面上看,这是生产力爆炸。

但生产力爆炸之后,项目不会自动进入理想状态。

相反,它会带来一个新问题:

产出速度过快,人的理解、审查和决策速度跟不上。

AI 很擅长把局部做出来。

但软件产品不是局部功能的简单堆叠。

一个功能“能用”,不代表它值得存在。

一个页面“完整”,不代表用户能理解。

一个系统“强大”,也可能意味着它对普通用户过于复杂。

AI 的强大首先体现在生成能力和执行能力上。

但这些结果是否正确、是否必要、是否符合产品方向,仍然需要判断。

产品问题不是封闭问题

代码问题通常有相对明确的反馈。

能不能运行?

测试能不能通过?

接口是否对齐?

类型是否正确?

性能是否达标?

这些问题虽然复杂,但可以通过一系列技术手段验证。

产品问题不同。

产品没有唯一答案。

同一个 Agent 产品,可以做成很多形态:

  • 任务列表;
  • 任务拓扑;
  • 对话式助手;
  • 工作台;
  • IDE 插件;
  • 自动化平台;
  • 面向开发者;
  • 面向普通业务用户;
  • 强调执行过程;
  • 强调最终结果;
  • 暴露更多控制项;
  • 尽量隐藏复杂度。

这些选择没有绝对标准。

但每一种选择都会影响用户如何理解、信任和使用这个产品。

所以人在 AI 时代仍然重要,不是因为 AI 不够聪明,而是因为产品判断本身不是封闭问题。

AI 可以提供方案。

但必须有人承担选择的责任。

判断力到底是什么

判断力不是一句抽象口号。

在 AI 产品里,它至少包含六种能力。

1. 定义问题

AI 可以回答“如何实现”,但很难稳定判断“到底应该做成什么样”。

一个产品要服务谁?

解决什么问题?

当前版本边界在哪里?

哪些功能必须做?

哪些功能坚决不做?

用户真正购买的是效率、安全感、掌控感,还是身份认同?

这些不是纯技术问题,而是方向问题。

Agent 产品经理首先要能定义问题,而不是只接收任务。

2. 控制复杂度

AI 很容易热心扩张。

它会自动补全方案、增加边界、引入优化、把一个小需求扩展成更完整的系统。

这在写代码时可能是优点。

但在产品开发中经常会变成负担。

很多时候:

  • 少一个按钮,用户更清楚;
  • 少一个配置,系统更可信;
  • 少一个支线,团队更聚焦;
  • 少一个自动化路径,失败时更容易恢复。

成熟的产品判断,不只是“还能做什么”,而是“现在不该做什么”。

AI 能生成更多。

人要决定少做什么。

3. 审查结果

未来很多人都会用 AI 生成内容、代码、设计和方案。

但能生成不等于能交付。

真正有价值的人,看到 AI 输出时,不只是说“看起来不错”,而是能判断:

  • 产品方向有没有偏;
  • 用户路径是否清晰;
  • 技术方案是否过早复杂化;
  • 模块边界是否清楚;
  • 状态流是否可维护;
  • 异常路径是否被覆盖;
  • 这个结果是否真的达到可交付标准。

AI 时代,公司的瓶颈很可能从“谁来做”变成“谁来审”。

而审成果比做局部更难。

4. 系统抽象

AI 很容易把局部做漂亮,但整体变混乱。

一个成熟产品负责人需要知道:

  • 每个模块在系统里的位置;
  • 数据如何流动;
  • 状态如何变化;
  • 错误如何恢复;
  • 用户如何介入;
  • 权限边界在哪里;
  • 哪些信息需要进入上下文;
  • 哪些过程需要可观测。

这不仅是技术架构能力。

也是产品架构能力。

很多产品不是某个局部做错了,而是整体结构失控了。

5. 理解真实用户

用户不是理想化的理性机器。

用户不会仔细阅读每一句说明,不会完整扫描页面,不会耐心理解复杂系统。

他们可能在通勤、焦虑、疲惫、时间紧张的状态下使用产品。

好的产品设计,本质上是承认人的限制:

  • 注意力有限;
  • 记忆有限;
  • 理解能力有限;
  • 耐心有限;
  • 情绪稳定性也有限。

AI 可以生成界面。

但它不会天然理解用户在不确定系统是否可靠时的焦虑。

它也不会自动知道复杂信息堆叠会让人放弃。

产品最终面对的是人。

所以理解人的脆弱,仍然是产品判断的一部分。

6. 真实验证

即使 AI 可以操作浏览器、模拟流程、检查页面,它也不能完全替代真实用户反馈。

自动化测试能验证流程能否跑通。

但不能验证:

  • 用户是否信任它;
  • 用户是否知道下一步该做什么;
  • 用户是否理解产品价值;
  • 用户是否在关键时刻感到失控;
  • 用户是否愿意把真实任务交给它。

真实用户会误解、迟疑、走神、焦虑、放弃,也会提出开发者想不到的问题。

AI 可以帮助分析反馈。

但反馈本身仍然来自人。

公司瓶颈会从执行转向验收

当公司开始充分使用 AI,最大的变化可能不是“人都不需要了”。

而是生产瓶颈发生迁移。

以前的瓶颈是执行能力:

需求写完

设计师画图

开发实现

测试验证

上线运维

每个环节都需要时间,所以公司缺开发资源、缺测试资源、缺设计资源。

AI 介入后,执行环节会被大幅加速。

代码、文档、方案、测试、UI 草图都可以快速生成。

于是新的瓶颈出现:

验收能力
判断能力
注意力资源

AI 可以一天生成十个方案。

但谁来判断哪个方向正确?

AI 可以同时推进五个模块。

但谁来保证它们最终组成一致的系统?

AI 可以写大量代码。

但谁来判断架构是否埋下长期维护风险?

AI 可以生成很多页面。

但谁来判断用户是否真的能理解和使用?

AI 可以不断扩展功能。

但谁来决定当前版本在哪里收口?

真正让人疲惫的,不是亲自写了多少代码。

而是持续决策:

  • 这个功能该不该做?
  • 这个设计是否偏了?
  • 这个方案是否合理?
  • 这个分支是否应该合并?
  • 这个复杂度是否必要?

这不是简单 checklist。

这是一种综合判断力。

Agent 产品经理为什么更重要

在 Agent、开发者工具、知识库、自动化平台这类复杂产品里,纯产品经理可能不懂系统复杂度,纯工程师又可能忽视用户体验。

未来会更需要一种混合型产品 Owner:

懂技术
懂产品
懂用户
懂 AI 协作
能控制复杂度
能设计验证机制
能对最终交付负责

这种人不一定每一项都是顶级。

但必须能把它们组织起来。

Agent 产品尤其如此。

因为 Agent 产品不是普通 SaaS 表单,也不是单次聊天。

它会主动执行,会修改环境,会产生中间结果,会请求权限,会失败恢复,也会让用户产生信任或不信任。

所以 Agent 产品经理要回答的问题不是:

如何让 AI 执行更多?

而是:

如何让 AI 执行正确的事?
如何让用户知道它在做什么?
如何让结果可验证?
如何让失败可恢复?
如何让复杂度不失控?

这正是判断力的具体体现。

判断力如何成长

判断力不是读几篇文章就能获得的。

它来自反复试错。

一个人不是听完“产品要控制复杂度”就真的会控制复杂度。

他必须亲眼看见复杂度如何膨胀,亲自感受到系统失控,亲手经历需求发散后的疲惫,才会真正理解为什么要收口。

一个人也不是看完“用户注意力有限”就真的懂用户体验。

他必须看到用户不看说明、点错按钮、误解文案、放弃流程,才会理解产品设计为什么重要。

AI 时代的问题是:

市场越来越需要成熟判断者,但新人获得低风险训练的机会可能变少。

大量初级任务原本是人的训练场。

修 bug、改页面、补测试、参加 code review、上线出问题、被用户反馈、被 leader 追问,这些都是成长材料。

如果这些低阶任务大量被 AI 自动化,公司可能更倾向于招聘已经成熟的人。

但成熟的人从哪里来?

这是 AI 时代人才成长的真实矛盾:

没有经验
  → 很难形成判断力

没有岗位
  → 很难积累经验

没有判断力
  → 很难获得更高价值岗位

所以人的成长方式必须变化。

用 AI 搭建自己的训练场

AI 压缩了一部分初级任务,也提供了一种新的训练方式。

个人可以用 AI 低成本构造完整项目训练场。

过去,一个新人很难独立经历一个产品从 0 到 1。

因为他没有团队、没有设计、没有后端、没有前端、没有测试和部署能力。

现在,AI 可以帮助个人模拟一个小型团队。

你可以让 AI:

  • 写代码;
  • 写文档;
  • 做设计草案;
  • 生成测试;
  • 分析竞品;
  • 复盘问题;
  • 模拟用户反馈;
  • 生成不同方案。

但关键不是把项目无限做大。

而是反复做小闭环:

定义目标

限制范围

让 AI 实施

审查结果

发现问题

调整方向

写复盘

进入下一轮

判断力不是靠一次大项目直接获得。

它靠很多次小闭环积累。

这也是我做 Plato 的原因之一。

Plato 不只是一个项目展示。

它更像一个持续训练产品判断、Agent 协作、上下文治理和复杂度控制的工作台。

和 Plato 三平面的关系

这篇文章也解释了为什么 Plato 需要启发面、控制面和信任面。

因为 AI 执行力增强之后,产品真正要解决的不是“让 AI 多做一点”。

而是让 AI 的执行处在正确的判断框架里。

平面对应的判断问题
启发面用户是否知道 AI 能做什么,以及如何提出高质量任务?
控制面Agent 是否按照可执行、可约束、可验证的流程推进?
信任面用户是否能理解、审查、确认和恢复 Agent 的行动?

这三个平面共同回答一个问题:

当 AI 能快速执行时,人如何保持方向、边界和责任?

启发面帮助用户形成更好的任务。

控制面让任务进入结构化执行。

信任面让用户能审查和接管结果。

这不是为了减慢 AI。

而是为了让 AI 的速度不把产品带偏。

结论

AI 的能力会继续增强。

它会越来越会写代码,越来越会做 UI,越来越会写产品方案,越来越会生成测试。

但这不意味着人不再重要。

人的价值正在上移。

普通执行力会贬值。

普通代码能力会贬值。

普通文档能力会贬值。

普通 UI 生成能力也会贬值。

更有价值的是:

  • 能定义值得解决的问题;
  • 能判断 AI 输出是否达标;
  • 能控制产品和系统复杂度;
  • 能理解真实用户的限制;
  • 能决定什么不做;
  • 能把 AI 的生产力组织成真正可交付的产品。

AI 时代最大的矛盾,也许不是“AI 会不会替代人”。

而是:

AI 能快速产生结果,但人类需要缓慢积累判断结果的能力。

未来值得追求的,不是和 AI 拼执行速度。

而是建立一种新的合作方式:

AI 负责扩大生产力。

人负责定义方向、控制边界、审查结果、理解用户,并通过高频小闭环持续成长。

AI 可以快速生成结果。

但什么结果值得交付,仍然需要人来判断。