1. 课程导入
1.1 为什么我们需要这两份文档？
先聊个我亲身经历的事。几年前我参与一个智能客服项目，团队花了三个月训练模型，准确率做到85%以上。结果交付时，业务方问了个问题：「这个模型什么时候会犯错？它能不能处理方言？如果用户骂人它会怎么反应？」
我们当时就愣住了。技术指标很漂亮，但业务方要的答案，我们一个都拿不出来。说白了，我们只交付了一个「黑盒」，没有配套的说明文档。
从那以后，我养成了一个习惯：任何AI项目，必须同时产出两份文档——产品需求文档（PRD）和模型卡片。一个管「做什么」，一个管「怎么做、有什么风险」。
核心观点：AI产品不是单纯的算法模型，而是一个「技术+业务+风险」的综合体。没有文档，项目就是空中楼阁。
1.2 产品需求文档（PRD）到底长什么样？
AI产品的PRD和传统软件PRD有区别。传统PRD写功能、写交互，AI产品的PRD还要写数据、写评估标准、写失败处理。
我个人习惯把AI-PRD拆成六个模块：
- 业务背景与目标——为什么要做这个模型？解决什么痛点？
- 用户场景与用例——谁在用？在什么场景下用？
- 数据需求——需要什么数据？数据量级？标注标准？
- 模型性能指标——准确率、召回率、延迟、吞吐量，具体数值是多少？
- 失败模式与兜底策略——模型答错了怎么办？置信度低时怎么处理？
- 评估与验收标准——怎么才算「做完了」？
举个例子，我之前做的一个文本分类项目，PRD里明确写了：「当模型置信度低于0.6时，必须转人工处理」。这个看似简单的规则，后来救了我们好几次——因为线上数据分布和训练数据差异很大，低置信度样本几乎全是错的。
小技巧：写PRD时，多问自己一句「如果模型在这里失败了，用户会看到什么？」。把失败场景写清楚，比写成功场景更重要。
1.3 模型卡片——给模型一个「身份证」
模型卡片这个概念，最早是Google在2018年提出的。说白了，它就是一份关于模型的「说明书」或「体检报告」。
我见过太多团队，模型训练完了，参数调好了，但半年后连自己都忘了当时用了什么数据、做了什么预处理。模型卡片就是为了解决这个问题。
一份标准的模型卡片通常包含：
| 模块 | 内容 | 我的经验 |
|---|---|---|
| 模型概述 | 模型名称、版本、类型、用途 | 版本号一定要写，我见过「最终版v3_final_真的最终」这种命名 |
| 训练数据 | 数据来源、规模、标注方式、时间范围 | 标注标准要写清楚，否则换个人标注结果完全不同 |
| 性能评估 | 在测试集上的各项指标 | 别忘了写测试集的分布，否则指标没有意义 |
| 已知限制 | 模型在哪些场景下表现不好 | 这块最难写，但最有价值 |
| 公平性与偏见 | 是否存在对特定群体的偏差 | 现在合规审查越来越严，这块不能省 |
| 使用建议 | 推荐的使用场景、不推荐的使用场景 | 写清楚「不要用这个模型做什么」 |
我曾经在一个金融风控项目里，因为模型卡片里没写「该模型在用户年龄小于18岁时准确率下降20%」，结果上线后被监管点名。嗯，从那以后，我再也不敢漏掉「已知限制」这一栏了。
1.4 行业现状：大家都在做，但做得好的不多
说实话，现在AI行业对文档的重视程度，参差不齐。
大厂基本都有成熟的模板和流程。比如Google的Model Cards工具包，微软的Responsible AI Dashboard，都提供了标准化的文档生成方式。但中小团队，尤其是创业公司，往往「先跑起来再说」，文档能省则省。
我观察到的几个典型问题：
- PRD和模型卡片脱节——PRD写一套，模型卡片写另一套，两者对不上
- 只写技术指标，不写业务指标——模型准确率99%，但用户满意度反而下降了，为什么？因为没写清楚使用边界
- 文档写完就吃灰——没人维护，模型迭代了文档还是老版本
为什么会这样？我觉得核心原因是：文档的「产出者」和「受益者」不是同一个人。写文档的人觉得是负担，看文档的人又觉得不够用。
注意：如果你现在正在做一个AI项目，我建议你从第一天就开始写文档。哪怕只是几行字，也比最后补强一百倍。补出来的文档，永远缺细节。
1.5 这门课能给你什么？
这门课一共30章，我会从零开始，带你完整走一遍AI产品需求文档和模型卡片的制作流程。
你会学到：
- 怎么写一份让开发和业务都满意的AI-PRD
- 怎么构建一份合规、可追溯的模型卡片
- 怎么把文档和实际开发流程结合起来，而不是「两张皮」
- 怎么应对监管审查、客户审计等场景
每一章我都会结合真实项目案例来讲。有些是我踩过的坑，有些是我看到别人踩过的坑。你想想看，如果能提前避开这些坑，能省多少时间？