夜雨聆风做AI产品三年，我见过太多同行深夜被开发拉群催文档。
"这个功能的数据格式说一下？" "向量库的chunk大小你定多少？" "prompt模板存哪？版本怎么管？"
这些问题，本该在需求评审前就写清楚。但现实是，80%的AI产品经理习惯口头沟通，开发一动手就发现缺这缺那，最后产品经理凌晨两点对着飞书文档狂补技术说明。
不是开发难伺候，是你的文档清单没建好。
今天这篇文章，我把三年踩坑总结出的AI产品经理必备文档清单一次性交出来。5类文档，每类都有模板，照着填就行。这是本系列的最后一期，也是我最想留给新人的东西。
一、为什么AI产品必须有文档清单？
传统产品经理画个原型、写个PRD基本就够了。但AI产品不一样——你的需求里有模型参数、有数据管道、有prompt工程、有评估指标，每一项都需要明确的文档支撑。
左边是"临时补文档"的惨状：开发问什么补什么，文档零散、版本混乱、口径不一。右边是"提前备清单"的状态：5类文档各司其职，开发拿着文档直接干活，产品经理专注盯进度。
差距不在能力，在习惯。
二、5类必备文档清单
1. 需求规格说明书（PRD-AI版）
这是基础中的基础，但AI产品的PRD比传统产品多三个必填模块：
模型能力边界：明确模型能做什么、不能做什么。比如"支持中文问答，不支持代码生成"。 输入输出规格：输入文本长度上限、输出格式（JSON/纯文本/Markdown）、token限制。 异常处理策略：模型超时怎么办？回答为空怎么办？触发安全过滤怎么办？
没有这三块，开发只能靠猜，测试只能靠蒙。
2. 数据规格文档
AI产品的数据规格文档，核心回答三个问题：
数据从哪来：来源系统、采集频率、数据格式。 数据怎么处理：清洗规则、分块策略（chunk size、overlap）、向量化方式。 数据怎么管：版本号、更新机制、回滚方案。
数据从源头到向量库，经过采集、清洗、分块、嵌入、入库五个环节，每个环节都有对应的文档字段。开发看到这个文档，就知道数据管道该怎么搭。
3. Prompt工程文档
这是AI产品最容易翻车的地方。prompt没有标准化文档，就会出现：同一个功能，三个版本三种写法，上线后效果飘忽不定。
Prompt工程文档必须包含：
prompt模板库：每个功能的system prompt和user prompt模板，带版本号。 变量定义：哪些是动态变量（用户输入、上下文），哪些是固定参数。 效果记录：每个版本的测试用例和输出对比，方便回溯。
4. 评估测试文档
模型上线前，必须有一份评估文档。不是随便跑几个case就说"效果不错"，而是要有结构化的评估框架：
评估维度：准确率、相关性、流畅度、安全性，每项有明确的评分标准。 测试集：至少50条覆盖核心场景的测试用例，标注期望输出。 通过标准：每个维度的及格线是多少，达不到就打回。
评估文档的框架：维度定义 → 测试集构建 → 自动化评测 → 人工抽检 → 通过判定。这个流程跑一遍，上线底气就足了。
5. 运维监控文档
上线不是终点，是起点。运维监控文档要写清楚：
监控指标：响应延迟、错误率、调用量、成本消耗。 告警阈值：延迟超过几秒报警？错误率达到多少触发通知？ 应急方案：模型服务挂了切哪个备用？数据异常怎么回滚？
三、文档管理的3条铁律
有了清单还不够，管理方式决定文档能不能真正用起来。
第一，模板先行。 每类文档都有标准模板，产品经理填空就行，不用从零写。模板存在团队共享空间，所有人用同一套。
第二，版本可控。 每次修改打版本号，记录修改人和修改原因。别小看这一步，上线出问题时，版本记录就是排查线索。
第三，评审必过。 需求评审前，PRD和数据规格文档必须提前1天发给开发和测试。评审会上对着文档逐项确认，而不是现场口头描述。这一条执行下去，返工率至少降一半。
写在最后
这是AI产品经理系列的第21期，也是最后一期。
21篇文章，从Prompt工程到数据成本，从RAG选型到模型评估，从需求评审到文档管理——我试图把一个AI产品经理从入门到成熟需要的核心知识，全部拆成可落地的干货。
如果你一路跟下来，现在手里应该有了一套完整的AI产品方法论：知道怎么选型、怎么算成本、怎么做评审、怎么管数据、怎么写文档。
文档清单不是形式主义，而是让团队协作效率翻倍的杠杆。当你把5类文档备齐、模板建好、流程跑通，你会发现——开发不催了，返工少了，下班也能准时了。
好的产品经理不是最忙的那个，而是文档最齐全的那个。