产品经理在处理新增协议上传附件需求时，借助 AI 快速生成原型、补全业务场景并交付，不仅高效解决问题还引发对自身工作的反思，快来了解这一精彩过程。

前几天收到了一线项目组同事发来的消息：

在新增协议的时候可以上传附件，这个需求是计划要做的。 因为目前阶段有更高优先级的需求在做，研发资源也比较紧张，而且不影响功能正常使用，所以暂时还没有排期。 现在系统中实际页面是这样的，注意「选择规则」按钮左边什么都没有：

为了不让项目上催命式的询问，并且给客户能有个交代，于是我打开了AI，把这张系统实际截图扔过去，直接告诉AI我的需求，看下图：

于是我就得到了下图这样的一个效果，它完全复刻了我截图的页面样式，完全实现了我的需求并且按钮是可以点击打开选择附件：

但是我感觉还不够，没有形成闭环，上传后你得让用户看到传的东西才会心里踏实吧，于是又告诉AI：

然后我就得到了这样的一个效果，请看下面视频：（视频无法展示，可关注公众号：PM超进化） 把文件直接下载发给项目上的同事让他体验，体验后他还以为功能已经开发好了：

加上和同事的沟通时间，全程用时不到10分钟。既不用被项目上催了，有个可以看到效果的东西也让他们给客户有个交代。

你以为这就完了？并没有。

虽然看似解决了问题，很明显，我在处理上面这个需求的时候还没有经过详细思考，或者说就算思考了也难免会有疏漏之处。

果然，隔了两天同事又来找我了：

说实话，那一刻，我心一虚。

这个信息其实我是知道的，但就是当时设计的时候没有考虑进去。

尽量考虑全点，优化一次也不容易。

谁说不是呢。

大多数产品经理容易犯的错：只盯着正常流程，却忽略了那些足以搞垮体验的异常现实。

在设计这个功能时，我的脑回路是这样的：用户创建一个协议→上传一份 PDF或Word→ 点击保存 → 完事。因为只有一个文件，所以我设计了点击按钮直接预览，交互顺滑，逻辑闭环。

这就是典型的 Happy Path 思维。

我们在画原型、写文档时，总是习惯性地预设用户会按照最标准、最正确的路径去操作。

但业务现实会告诉你：娃娃你还是太年轻！

复盘这次沟通，产品经理容易忽略异常流程，主要有三个原因：

1. MVP思维的误用：我们常把最小可行性产品挂在嘴边，以此为借口砍掉复杂的逻辑，觉得以后再迭代。但像数据库结构（一对一还是一对多）这种底层逻辑，一旦定型，后续迭代的代价是毁灭性的。
2. 离业务一线太远：如果我不了解合同管理的真实场景（续签、补充），我就永远想不到多文件的需求。产品经理的想象力，永远填补不了业务的真实度。
3. 缺乏QA 思维：我们习惯思考「用户怎么用这个功能」，而很少思考「用户怎么玩坏这个功能」。

人无完人，疏忽是难免的，AI时代，怎么通过AI来最大可能的降低这个风险，我是这么干的，我就进入上次和AI的对话，输入下面这句话：

于是我就得到了下面的回答，每一条都列出了场景和对应的后果及措施，感受一下：

当然，这个回答的内容不能全部采纳，产品经理需要用自己的判断力去决策最终用什么，但确实能让引发更多思考和反省，也给后面测试人员提供了case。

接着我又发给AI一句话：

过了十几秒，我就得到了这样一个支持多文件列表、支持单独预览/删除、继续添加、自动过滤重复文件的全新功能原型。

然后检查了一下没什么问题，我把这个可以直接交互的 HTML 文件发给了项目上的同事。

也可以继续让AI针对这个功能输出一个详细的PRD文档作为参考。

另外值得一提的是，生成后的结果会有一个编辑功能，点击编辑按钮后就可以进入到代码编辑状态，如果你稍微会点前端代码，就可以随心所欲。编辑好后点击右上角的对勾保存就可以直接预览效果。

全程用时又不到 10 分钟。

这在以前，可能需要画原型、写文档、等 UI 出图、等前端开发，流程至少 3 天起步。

在这个 case 中，我没有写一行代码，也没有画一张复杂的 Axure 原型图。

我做的事情是：

• 定义目标（复刻页面，加功能）。
• 可行性验证：利用 AI 快速生成原型，验证交互。
• AI 辅助决策：利用 AI 查找逻辑漏洞，补全业务场景。
• 闭环交付：给出可执行的代码/Demo。

最后和AI交流了一些其他问题后，夸了 AI 一句，它的回答让我甚至觉得是对产品经理未来价值的最好注解：

我只是你的「外脑」和「数字参谋」，而你才是那个拥有「同理心」、「判断力」和「最终决策权」的舰长。

尽量考虑全点，优化一次也不容易。

这句话，也送给所有同行。

未来已来，只是分布不均。

希望我们都能利用好 AI，完成属于自己的职业超进化。