我是 Ward，做了九年 B 端产品经理，做过生产制造、供应链和批发零售的业务系统。后来我开始用 AI 做自己的小产品，从需求、开发到上线都自己走完。两段经历叠在一起，我感受最明显的变化有两处，一是需求文档里哪些话还算需求，二是做用户研究时要看什么。
需求文档先写边界，再写功能
传统 PRD 写的是，用户点了这个按钮，系统做什么。同样的操作，结果是确定的，验收就看按钮在不在，点了有没有反应。
AI 功能就没有这么确定了。同一句话，模型这次答得很好，下次可能答偏。所以我建议写需求时，先写能力边界和失败模式，最后才是验收标准。
能力边界要写到销售、研发和产品说的是同一件事。下面这些是示例，我没有做过实测。例如能总结八千字以内的文章，不处理图片和视频，知识库以外的问题直接说不知道。边界写清楚，销售就不会承诺一个研发做不出来的功能。
失败模式也要写。AI 一定会出错，常见的情况有三类。它不知道答案，它答了但用户不满意，它答错了。每一种都要有产品上的对策。不知道就直说，并给出其他途径；不满意就给重新生成和补充要求的入口；答错了要能纠正，并且有人接手。这些最好整理成一张表，体验和技术方案分开写。
我在纺织工艺问答的复盘里写过一条，资料不够的时候，不硬答，告诉用户去哪里查。这就是一种失败模式的对策。
验收从功能有没有，变成质量怎么样
传统产品的验收是功能有没有实现。AI 产品要看质量指标。下面的数字只是示例，写法可以参考，具体值要按你的场景定。比如总结准确率达到百分之九十五以上，人工抽检一百条；幻觉率低于百分之三；每条回答后的用户评分均值超过四分。
验收最后要靠日志和抽样来回答，靠感觉答不了。我的多模型路由配完以后，用了几天，只觉得活没有交给该交的模型，具体是哪里出了问题，光靠感觉说不清。后来让 AI 对着 2026 年 10 月的四千六百多条请求日志做了体检，又抽样检查了 248 轮推理强度的判断，才看出问题在哪。比如，用户只回一句“继续”的时候，意图模型经常会判成低强度，因为它只看这一轮输入的字面内容。配置能跑，只说明它能用。跑起来有没有按设计走，只有日志能回答。
用户研究，先分清问题出在哪边
用户说“这个 AI 不行”，这句话底下通常压着两种问题。一种是模型确实答不准。在纺织工艺问答里，行业词被搜偏，要改的是检索和词库。另一种是用户不会问。我们很快发现，工厂的用户不习惯写完整的问题，很多人只打一两个词。纯对话框对他们太难，要改的是界面，把对话换成场景按钮加表单。
两种问题的改法完全不同，混在一起看，就会在错的地方使劲。
AI 产品的访谈，比较适合让用户边用边说。用户在哪一步觉得惊喜，在哪一步觉得失望，最容易从这里看出来。测试也可以专门设计几类，比如问一个资料里没有的问题，看它会不会编；多轮对话里，看它能不能跟上上下文；指出它的错误之后，看它能不能改对。
产品的事实，放在一个地方
最后是我自己做小产品的一个做法。我把产品的名称、状态、价格和版本放进一份配置，页面、脚本和 SEO 信息都从它读，不在几处手写。自己做产品，没有人替你核对口径，只能靠结构保证。
回头看那个纺织问答项目，我最该先做的一件事，是去看工人实际会怎么问。