夜雨聆风零、前言
以前总觉得 AI 离我们还很遥远，没想到从 2022 年到现在不过短短 4 年，它已经从一个对话助手，变成了真正的生产力工具。细思极恐😔。
最早的时候，大家都觉得软件是有壁垒的，AI 最不容易替代。后面发现全错了……软件本质上全是文本符号，而处理文本符号刚好是 AI 最擅长的。这两年下来，我以前学习和总结的那套产品方法论，已经明显不太够用了。
所以想趁这个时间点，把自己在一线踩过的、想明白的东西记录下来，这也是这个公众号第一篇文章的由来。
（顺便说下名字里为什么带"人类"二字：现在很多公众号已经全 AI 自动化了，但总感觉有点画蛇添足——本来几句话能说完的事，用 AI 啪啪啪输出一堆文档，收到的人又用 AI 总结一遍，全是废话文学。还是想留点人写的东西。当然，将来用来蒸馏自己🐶，或者给 AI 留点训练语料，也都挺有意义）
下面就聊聊我自己理解的，AI 时代下产品方法论的变化。
一、传统产品方法论
传统产品方法无非几个核心步骤：
需求分析 需求文档 UI 设计 监督开发过程 功能验收
这套流程大家已经用了很多年，其实并没有什么特别大的问题，就是慢，而且中间环节众多，导致沟通效率不高，浪费的时间也很多。
从产品角度来讲，还有个比较大的问题：产品经理在写需求文档时，不可能对每个细节面面俱到，因此开发过程中还会产生很多沟通问题。另外，很多交互性的东西，要描述完整耗时巨大，一般就会简化，但简化之后开发出来的效果又很差。
举个例子：在产品中想给开发描述一个块的效果，要从很多方面来说——悬停样式、动画样式、颜色、字体、图标……非常多。一般情况下，一是为了赶进度不会写得很详细，二是也没那么多时间来细琢磨，UI 同样没那么多机会做这么细。这种情况下基本就靠开发自己发挥，出来的结果往往是"没 Bug 就不深究细节"（B 端产品特色）。
其实主要问题还是在沟通成本上。双方知识面不一样，理解起来不会很快。有可能开发觉得自己理解了，实际做出来却不是产品想要的样子。
还有一个问题：当你看到实际开发效果后，想让开发改一些细节，但开发也有排期压力，很多其实并没有机会改。这些都会阻碍一个产品往更好的方向发展。
二、初级：AI 生成交互式原型
在这个阶段，产品还保持着原有的流程，核心依然围绕原型来设计，只是在各个环节加入了 AI 的辅助。
需求调研阶段，可以让 AI 生成调研清单、整理调研报告……各种辅助，这些本质上还是 AI 生成文本或文件。
另一类就是生成原型：给定合理的需求和原型提示词，让 AI 辅助生成高保真原型，可以更高效地和开发及客户沟通最终效果。生成原型有多种方案，可以直接生成设计图 UI，也可以直接生成 HTML 这种可交互的原型。
这个阶段的产品，最终交付产物建议是「HTML 可交互原型 + 需求文档」：
可交互原型用于直接给开发或客户演示最终效果，直观清晰，不容易产生歧义，能降低沟通摩擦。 需求文档用于给开发或客户看细节。
其实在这个阶段，如果用好 AI，相比传统工作流程也能带来很大的提升，只是对 AI 的使用还不够深度，流程还是以前的流程，还有很多可以调优和加快进度的办法。
三、中级：参与 Bug 及调优过程
在这个阶段，产品在验收功能过程中发现的 Bug 和优化性问题，可以直接借助 vibe coding 来修复。
这里有个天然的点，和设计这个功能的产品能力强相关——但不管多牛的产品来设计，必然会有一些小的细节问题。这种情况下，用 vibe coding 的方式来调优就很靠谱了。
人与人之间协作，因为沟通、效率等问题，很多情况下只要不是很严重的问题，产品一般也就放行了，不会让开发反复改（除非是产品权力比较大的公司）。这样导致实际的产品和设计的想法往往存在一些出入，也会有一些产品没考虑完善、又不那么重要、但确实影响体验的地方。在这些场景下，用 AI 来处理是很好的解决方案：不用麻烦开发，自己直接让 AI 修复。
PS：其实 Bug 更好的处理方式，是测试在提 Bug 的过程中，把不那么严重的 Bug 直接让 AI 改了，这样测试效率最高。否则现在有些开发是直接把测试写的问题描述发给 AI，让 AI 去处理，甚至都不过脑子——可测试实际上才是最了解情况的人。不过在我们公司，测试对 AI 的运用还是很薄弱……
四、高级：直接从开发过程介入
到了高级阶段，Anthropic 的产品经理也曾在一个访谈中提到过他们的工作流程，其中最核心的观点是：在 AI 时代，产品的角色更应该关注判断力和方向的把握，而不是大量细节的控制。
（我个人觉得是因为现在的模型足够强大了，放权给 AI 后，不需要关注那么多细节，AI 自己也能理解并处理得比较好；反而控制太死，效果不那么好。）
所以这个阶段更重要的是出设计文档，取代之前那种很细节的产品需求文档。我自己把这个新模板叫「产品设计方案」，核心就五块，挨个说下里面该写什么：
背景：为什么要做这个功能、解决谁的什么问题。这块以前经常被省略，但在 AI 开发模式下特别重要——AI 不像人那样自带上下文，你把背景讲清楚，它才能在细节上替你做出合理判断，而不是机械地照字面执行。 使用场景：用户在什么情况下、走什么路径来用这个功能。场景写清楚了，很多交互细节 AI 自己就能补全，不需要你一条条去抠。 产品设计方案：功能的整体设计、核心流程、边界和范围。这里要严格——AI 时代产品最该把控的就是"这个功能到底做什么、不做什么"，范围一旦定死，后面就能放心交给 AI。 UI/UE 方案：大方向的视觉和交互风格、关键页面的预期效果。不需要像传统那样抠每个像素，给定方向 + 一份可交互原型，比写十页交互说明管用得多。 验收标准：做到什么程度算合格。这块以前靠产品和测试口头对，现在直接写进文档，AI 开发完可以自己对照着自检。
和传统需求文档比，最大的区别就一句话：以前是"把每个细节都替开发想好"，现在是"把方向和边界定死，细节放权给 AI"。一是交互和一些产品细节不需要像传统那么细；二是 AI 开发模式下，产品对每个功能的定义和范围反而比以前更重要，必须严格规定。
如果是和研发协作，也可以先基于产品设计方案出 HTML 可交互原型，用模拟数据实现想要的效果，然后把整个原型代码交给开发，让开发基于此来实现。
建议可以试试 用产品设计方案直接代替传统需求文档。
五、未来：AI 的上限取决于用它的人的上限
在当下来看，AI 的能力已经超越很多个人了，几乎做到了无所不知。但 AI 的上限反过来又受限于使用它的人：如果你知识面不够，甚至都不知道该怎么向 AI 描述你的想法、你到底要什么，那 AI 也帮不了你。
就拿我们公司来说，同样的模型，很多人觉得很强，很多人觉得不行。实际上这就是使用方法带来的差异，并不是 AI 真的不行。
未来的产品，核心在于把握方向和产品品味，而不是大量纠结细节。而且产品、开发、测试之间那道严格的分界线，只会越来越弱——一个人借助 AI，就能把过去一个小团队的活儿干完。
到那个时候，决定差距的就不再是你会不会用某个工具，而是你的判断力、品味和知识面够不够撑得起 AI 的能力。说到底，AI 的上限，就是用它的人的上限。
愿意去研究 AI、把 AI 用透的人，会比别人多出一大截机会。
这也是我想开这个公众号的原因——大家可以一起聊聊产品的 AI 工具、方法论，以及实际工作里遇到的那些坑。
