上个月部门来了个新实习生，叫小王。刚来第一天就被安排写产品需求文档，结果第二天就被项目经理在会上当众打回重写——不是格式问题，也不是逻辑不清，而是他写的‘用户能上传图片’这句话，漏了三个关键点：最大文件5MB、仅支持JPG/PNG、每天限传10次。

这已经是我们组今年第三次因为‘看似明确、实则模糊’的需求导致开发返工了。之前有个功能上线前夜才发现按钮颜色没指定，UI和前端各做了一版，最后临时合并，代码里留了个‘if环境=测试 then 红 else 蓝’的诡异逻辑。

可问题是，谁都没法怪谁。产品经理觉得‘上传图片’四个字足够清晰；开发认为限制条件应该由产品主动写明；测试更委屈：你们不写，我怎么测？

小王被批完没吭声，但第三天早上，大家发现他桌上多了个奇怪的东西：一张贴着‘需求错题本’标签的共享表格，里面整整齐齐列着他被退回的每一条需求，左边是原话，右边是‘实际要表达的内容’，中间还加了一栏‘为什么会被误解’。

比如那条‘用户能上传图片’，旁边写着：‘口语化表达未覆盖边界条件’。另一条‘点击后弹出提示’，补充说明是‘未定义提示文案、出现位置、关闭方式及是否可配置’。

起初大家只当是个自嘲笔记，直到有天另一个同事写需求时卡住了，顺手翻了下这个表，突然说：‘哦！原来‘支持搜索’也得写清是否支持模糊匹配、关键词高亮、历史记录这些。’

两周后，这个表格被悄悄复制了一份，命名为‘团队需求编写指南V1.0’，挂在了项目管理工具的首页。再后来，有人开始往里面加‘高频坑点’分类，比如‘状态类字段必须枚举所有值’‘时间相关描述统一用北京时间’……

真正让我觉得有点意思的是，小王说他其实没想搞什么知识沉淀，只是不想再被当众打脸。他原本打算用Excel维护，但发现一旦多人编辑就乱序、冲突，评论也分散，索性试了试蓝点通用管理系统。

他说选它是因为‘不用等IT排期’。他自己拖了个‘需求缺陷库’模块，字段包括原始描述、修正版本、误解类型（如歧义、缺边界、术语不一致）、关联项目、责任人，还能上传截图。最关键是加了个‘引用次数’自动计数——每当有人在新需求文档里标注‘参考缺陷ID#007’，那个条目就会自动+1。

后来他们组开会时，PM主管说了句玩笑话：‘现在写需求不带缺陷编号的，一律视为未完成。’结果底下人真照做了。现在新人入职第一件事，不是领电脑，而是花半天刷完前20条高频缺陷记录。

其实这类‘经验资产化’的做法在制造业早就不稀奇。产线老师傅把机器异响录成音频库，维修新人对着听；客服团队把典型投诉对话脱敏归档，标出情绪拐点和化解话术。但在我们这种快节奏的产品团队，知识往往散在个人脑子里，离职就带走，重复踩坑成了常态。

有个细节挺有意思。小王最初想给每个缺陷标‘严重等级’，但很快发现不好量化。后来改成‘返工工时统计’，每次同类问题重现，负责人要补填实际消耗时间。结果有次一个P0级需求因描述不清导致后端重构两天，那条记录的返工工时写了‘16h’，整个表格突然就有了重量。

现在这个库已经衍生出两个副产品：一个是自动生成‘需求检查清单’的功能，填新需求时系统会弹窗提醒‘您未填写文件大小限制，参考缺陷#003曾导致CDN超载’；另一个是每月‘缺陷热力图’，用颜色深浅显示哪类问题最多发。

上周复盘会上，技术主管看着热力图沉默了几秒，然后说：‘过去三个月，47%的返工集中在‘状态流转’描述模糊。建议下周我们专门开个会，把所有涉及状态的词汇先统一定义一遍。’

散会后我在走廊碰到小王，问他接下来打算怎么弄。他说正考虑加个‘预防措施’字段，让每次修复不仅能记录问题，还能沉淀解决方案。比如‘使用标准化模板片段库’或‘增加原型标注层级’。

我随口问了一句：‘要是以后没人新增缺陷了呢？’

他笑了笑：‘那说明我们终于把常识变成共识了。’