和 AI 一起做产品，哪些判断不能交给它？

尝试做独立开发者的现在，几乎每一步都依赖 AI tools。

需求讨论、功能拆解、PRD、交互方案、技术设计、写代码、review，很多工作都不是我一个人先想完，再交给 AI 执行，而是在反复对话中一起完成的。

这确实让我可以做以前一个人很难完成的事。

但合作越深入，我越容易遇到一个问题：

哪些事情可以直接让 AI 做，哪些判断仍然必须由 PM 自己完成？

如果所有内容都要先由 PM 想清楚，AI 只负责整理和改写，它能提供的价值会很有限。

但如果直接让 AI 拆需求、定 Scope、补规则，再从结果里挑一个看起来合理的方案，PM 也很容易变成最后签字的人。

所以，真正需要区分的不是：

• 哪份文档是 PM 写的；
• 哪份文档是 AI 写的。

而是：

一项工作是在整理和探索，还是在替产品作决定。

AI 可以做很多，但“生成”不等于“决定”

一份产品文档里，通常混合了几类不同的工作：

• 整理已知信息；
• 补充可能遗漏的内容；
• 提出不同方案；
• 在方案之间作出取舍；
• 确定产品最终要怎样运行。

前面几项很适合交给 AI。

它可以快速整理讨论、拆流程、列异常情况，也可以指出矛盾，提出几种不同的阶段方案。

但到了取舍和最终确认，责任就不一样了。

AI 可以给出建议，但它不会真正承担结果。产品做复杂了、开发返工了、用户遇到问题了，最后还是人需要解释为什么这样决定。

因此，我现在更愿意把分工理解成：

AI 负责扩大选择和展开细节，PM 负责收敛、取舍和确认。

产品解决什么问题，不能直接由 AI 定义

AI 很擅长把一个模糊想法整理成完整的问题陈述。

它可以快速生成目标用户、使用场景、用户痛点和产品价值，而且通常读起来很合理。

但合理不等于真实。

有时 AI 只是根据已有材料，把一个想法包装成了一个完整的产品机会。至于这个问题是不是真的存在、是否足够重要、用户是否愿意改变现有行为，它并不知道。

这部分当然可以和 AI 一起讨论。

它可以挑战问题定义，提出其他解释，也可以帮我识别自己是不是过早跳到了方案。

但最终我仍然需要判断：

• 我真正想解决的是什么；
• 这是用户的问题，还是我想象中的问题；
• 现在做它，是因为它重要，还是因为它容易被做成功能；
• 产品是在解决根因，还是只是在已有流程上增加一层 AI。

AI 可以帮助我把问题想清楚，但不能因为它写出了一段完整的问题定义，就默认这件事已经被验证。

Scope 可以让 AI 拆，但边界要由 PM 确认

Scope 和阶段拆解，并不一定要由 PM 独立完成。

很多时候，我只有一个大方向，并不知道每个阶段应该具体做到什么程度。

让 AI 先提出几种拆法，再比较依赖、工作量和风险，通常比我一个人从空白开始更有效。

但 AI 给出的拆解，往往会倾向于让方案看起来完整。

它可能会顺手补上更多功能、状态和异常处理，因为从文档角度看，这些内容都很合理。

问题是，Scope 从来不只是“完整地列出需要做什么”，而是在有限资源下决定：

• 这一阶段究竟要验证什么；
• 哪些体验暂时不完整也可以接受；
• 哪些用户和场景这次先不覆盖；
• 哪些风险必须现在解决；
• 哪些问题可以明确留到后面。

AI 可以提出 Scope，但最后做到哪里、为什么停在这里，仍然需要 PM 确认。

尤其是独立开发时，最难的通常不是找到更多可以做的事，而是有理由地不做。

产品规则不能在“补全流程”时被默认决定

很多真正影响产品行为的内容，并不出现在产品目标里，而是在流程和细节中逐渐形成的。

例如：

• 什么条件下进入下一个状态；
• 谁可以执行某项操作；
• 什么情况下需要用户确认；
• AI 输出不确定时如何处理；
• 两条规则冲突时哪一条优先；
• 数据缺失或服务失败时，系统继续还是停止。

这些内容很适合让 AI 帮忙展开。

它经常能发现 PM 没有想到的边界情况，也能补出更完整的状态和失败路径。

但风险在于：AI 为了让流程完整，会自然地替空白处补上答案。

如果 PM 没有意识到这是一条新规则，它就可能从“AI 根据上下文推测的做法”，直接进入 PRD，最后变成开发实现的产品行为。

所以，在看 AI 生成的流程时，我需要分清：

• 哪些是在展开已经确认的规则；
• 哪些是在提醒我还有问题没想清楚；
• 哪些是 AI 为了完成文档，自己补出的决定。

风险可以让 AI 枚举，但接受什么风险需要人决定

AI 可以列出很多潜在风险。

但不同产品对于风险的容忍程度并不一样。

例如：

• 一个结果可以自动执行，还是只能作为建议；
• 用户是否必须在操作前确认；
• 错误能否撤销；
• 系统不确定时应该继续完成任务，还是停止；
• 为了提高效率，可以接受多大程度的误判。

这些问题通常没有一个纯粹正确的答案。

它们背后是产品愿意牺牲什么、保护什么。

AI 可以帮助分析利弊，也可以提醒我遗漏了什么，但最终的风险边界不能由它默认选择。

PM 不需要在使用 AI 前先想清楚一切

强调这些判断不能外包，并不意味着 PM 必须先把所有答案都想好，再让 AI 开始工作。

事实上，很多判断本来就是在协作过程中逐渐形成的。

AI 提出几种 Scope，我才可能意识到自己真正想验证的是什么。

它补出一个自动化流程，我才可能发现某一步必须保留人工确认。

它列出异常场景，我才发现原来的设计根本没有恢复路径。

这些都是 AI 真正有价值的地方。

所以，我不认为合理的分工是：

• PM 先独立完成思考；
• AI 再负责执行。

更现实的方式是：

• PM 提供目标、事实和约束；
• AI 帮助探索方案、补充细节和发现遗漏；
• PM 对关键取舍作出确认；
• AI 再根据已确认的决定继续展开。

产品判断可以在人与 AI 的互动中形成。

但在一轮讨论结束后，PM 至少应该知道：

• 最终决定了什么；
• 为什么这样决定；
• 哪些仍然只是假设；
• 哪些只是 AI 提出的建议；
• 哪些结果需要自己承担。

真正不能交给 AI 的，是默认决定权

我不会为了证明自己仍然在做 PM，坚持所有内容都由自己先写一遍。

AI 能做得更好的整理、拆解和展开，我会直接交给它。

但方向、优先级、边界、规则和风险，不应该因为 AI 给出了完整答案，就在没有确认的情况下成为产品决定。

AI 可以参与思考，也可以影响判断。

但最后需要有人明确地说：

我理解这个决定，也接受它带来的后果。