收到5000字业务需求文档那一刻,我就知道以后产品经理要更累了

先点上方蓝字「阿康AI探索号」关注，再点右上角「…」设为星标。 这样以后更新时，更容易第一时间在订阅号消息里看到。

▌▌▌

阿康导读：AI最有价值的能力，不是把一句话扩写成几千字，而是把复杂材料压缩成准确、可判断的信息。需求先说短、说准、说清楚，再决定要不要写完整BRD。

上周，我被一份几千字BRD看累了

上周，我收到一个需求，结果打开一看是一份几千字的需求BRD文档，麻了。

需求背景、目标、功能说明、交互流程写得很完整，甚至是数据、接口、系统设计都写好了，乍一看就是一个专业团队产出的完整方案了。我快速扫了一遍内容，并在追问下才发现，这个需求其实只是一个页面展示内容的小优化。

说明：这段经历来自真实工作场景。为保护相关方信息，本文未展示原始需求文档，上图由我根据当时文档的体量、结构和主观感受，用工具模拟出来的一个效果图，仅供理解内容与还原阅读体验，不对应任何具体项目或业务数据。

后来问了下对方，原来他只是用AI工具花了十分钟就把这份BRD文档写出来了，但是内容实在太多，加上一堆技术名词又看不懂，干脆直接给我扔过来了。最尴尬的是，他10分钟用AI写的内容，我却认真的从头看到尾，花更多时间去理解、核对和寻找重点...真的是太浪费感情了。

这个问题就是最近经常发生在我们身边的，大家都沉浸在这种AI生成文档的喜悦中，动不动就是几千字的文档扔出来，或者是非常酷炫花里胡哨的HTML页面扔出来（说不定附带一个localhost:3000这种实际打不开的地址发群里的），却没几个人真正用心去核对，甚至完整看完自己AI内容的人都不多。

最后导致的问题就是AI给了一堆冗长的废话文档，但是作为接受需求方的产品经理们却要花大量时间思考并发现里面的坑。

我当时就在想，这种内容到底算啥玩意呢，说是需求吧真正的问题并没有讲清楚，说它没用吧可是背景、目标、流程啥的又写了一大堆，最近网上一看原来这种内容已经有个专业名词定义了：Workslop。

微软研究院也经常提到这个词，把它解释为：看起来很精致，却不准确或没有实际用途的AI生成内容，就是表面像完成了工作，实际上却把理解、核验和清理工作留给了接收者。中文有人会把它译成“职场电子泔水“。

微软研究院引用的一项美国调查显示，40%的员工在过去一个月收到过Workslop内容，这个数据很好的说明一个事实：AI省下的时间，不一定真的省下来了，也可能是转移给了其他人。

这件事情让人不舒服的，不只是看一个长篇大论的AI文档，更要命的是这个文档背后的人其实自己也没想清楚到底要解决什么问题，就让AI给出一个结果，最后这个”想清楚要解决什么问题“的过程也随着文档一起转移给了后续的角色了。

工作中使用AI，不能只是把一句模糊的想法扩写成看起来很长、很专业的文档，AI它更有意义的场景是通过追问和归纳，帮我们找出真正想解决的问题，以及最核心的判断，并帮我梳理成内容文档。

对于复杂需求而言，肯定是要写详细说明的，但文档长度应该取决于业务复杂度，而非AI扩写能力。如果场景、痛点和价值还没有想清楚，就让AI开始发挥，只会制造出一堆workslop。

我之前写产品经理价值时也提过，AI时代产品经理的价值正在从“把原型和PRD写出来”，转向“更快、更准确地判断什么值得做”。AI应该先帮我们把杂乱材料提炼成少量、准确、可判断的信息，确认真正有内容以后，再负责展开和整理。

之前我们介绍Agent Loop时写过一句话：“回合制不是低级模式。” 把这个思路放到AI时代的需求协作里同样适用。

业务方不应该一开始就提交几十页BRD，而应该先进入“需求路演”模式：

业务侧人员先用一页需求卡，向产品经理们尽可能讲清楚：需求背景是啥、这次到底要解决什么问题、有什么数据支撑、影响哪些人、预期价值是什么、期望的时间如何，以及验收标准是什么。

产品和技术也不要急着讨论怎么去实现，而是先做一次方案评审：问题是不是真实存在，价值是否足够明确，范围和边界是否清楚，验收标准能不能衡量，以及ROI评估如何。

实际可能就是这么几点：

其实这本质上也是一个Loop：提出问题、路演评估、反馈问题、修改，再评估。通过这个loop之后，再聊后续需求推进吧。

以后再收到很长的AI需求文档，我可能不会再这么认真读下去了，转而先请对方用五句话讲清楚：为什么做、改什么、影响谁、怎么判断完成、这次不做什么。如果连五句话还讲不清楚，写成五千字估计也不会更清楚了。

AI时代不缺长文档，缺的是几句话就能帮助别人作出判断的有效信息。不要急着让AI把需求写很长，先让它帮我们把问题简明扼要的讲清楚吧。

创作说明：本文内容由作者原创完成。

以上，有启发的话，欢迎点个赞、在看，也可以转发给有需要的朋友。

看完记得关注@阿康AI探索号及时收到更多AI实战内容

↓ ↓ ↓