⚡ Skill · TRS系统

功能设计文档编写

AI辅助编写企业级追溯系统（Traceability & Recall System）功能设计文档的完整方法论。
连接业务需求与技术实现，让双方都能看懂、都能用。

1.0
当前版本
2
工作模式
5
核心原则
5
质控维度
12
文档章节
🎯 业务+开发双读者 🔀 原型驱动 🛡️ 质控门 📊 数据项11列规范 📋 验收优先
01
解决什么问题？
Why · 5个典型痛点与解法
💢
聊得开心，写出来不是那个意思
需求讨论时很顺畅，写成文档后实现时发现各种歧义
✅ 解：强制5W1H框架 + 逐字段确认
💢
边界没定义，实现时发现各种坑
字段校验、异常流程、超时处理全靠猜，开发过程反复返工
✅ 解：数据项11列规范 + 校验3要素 + 报错模板
💢
追溯系统特殊性，新手容易遗漏
谱系关系、召回演练、审计留痕等非CRUD内容被当成普通功能写
✅ 解：追溯领域6大补充项强制覆盖
💢
写完才发现缺字段/缺验收标准
文档交出去了，开发说字段定义不全，验收标准一条都没有
✅ 解：PRD自检质控门，每章写完自动评分，缺口当场补
💢
业务和开发混写，谁都看不懂
业务人员看不懂JSON，开发看不懂业务语言，两边都抱怨
✅ 解：接口契约业务化 + 分层章节结构
💡
一个Skill，适用所有复杂度
A档（简单CRUD）到C档（跨多系统召回审计），按档位自动裁剪展开深度
✅ 解：范围裁剪决策树（只裁深度，不裁硬字段）
02
两种工作模式
How · 模式选择取决于输入类型
💬
模式A：传统需求沟通
适用于用户口头描述业务需求，通过5W1H框架深度挖掘
📋 确认格式
→
🎯 问题定义
→
🔍 深度挖掘
→
✍️ 引导编写
→
🛡️ 质控门
触发：用户口头描述 / 会议纪要 / 从零需求
⭐
模式B：原型驱动（推荐）
用户提供HTML/图片/Figma设计稿，AI先理解原型，再生成PRD
📥 接收原型
→
🔎 分析结构
→
📝 输出摘要
→
✅ 用户确认
→
✍️ 编写PRD
→
🛡️ 质控门
触发：用户提供HTML / 图片 / Figma文件，或说"给你原型"
03
五大核心原则
Principles · 不可妥协的铁律
🚫
证据优于断言
每个设计决策必须有来源：用户确认的→标注"用户确认"；按假设写的→标注"假设+风险等级"；没有来源的→不能写进文档。"我觉得"不等于"已确认"。
📖
接口契约面向双读者
不展示HTTP方法/URL路径/原始JSON。文档里写：操作名称、用途、字段含义、业务校验规则——业务人员和开发都能看懂，技术细节由后端工程师自行补充。
📊
数据项必须完整（11列规范）
每个字段定义11个属性：字段名 / 控件类型 / 数值类型 / 长度 / 必输 Y/N / 新增 Y/N / 编辑 Y/N / 值列表说明 / 默认值 / 校验规则 / 其他说明。留空必须有理由。
🔗
追溯领域补充项必须覆盖
6大领域（追溯谱系 / 召回演练 / 质量放行 / 条码标签 / 审计留痕 / 集成一致性）至少命中一项并写进文档；如果真的不涉及，必须写明"明确不适用原因"。
🛡️
写完必须自检（质控门）
每完成一个关键章节，AI自动触发质控评估。能自己修的当场修；修不了的写入"假设与待确认"表，标注优先级，让PM去确认。写作者自己不知道的不等于产品经理也知道。
04
PRD自检质控门
Quality Gate · 5维度自动评分
触发时机（完成以下节点后自动触发）
第2章 用户与价值
→
第3章 业务背景
→
第5章 功能列表
→
第7章 详细设计
→
全文初稿
→
📋 质控报告
评估维度（5维度 × 20分 = 100分）
①
完整性
20分
所有必填章节是否齐备？
缺→-10/处
②
无歧义
20分
模糊词/二义性？
每处-5
③
可追踪
20分
功能→验收→详细设计
是否对齐？缺→-10/处
④
一致性
20分
跨章节命名统一？
每处-5
⑤
数据项
完整性
20分
11列表格有留空？
每行-5
评分等级与处置
90-100
🟢 优秀
直接提交
可选标注亮点章节
70-89
🟡 良好
AI自修所有"可自完善"项
重评后剩余→PM确认
50-69
🟠 需改进
修明显缺口
剩余全写假设表，告知PM
<50
🔴 不合格
停止，说明核心缺口
请PM补充信息后再继续
自完善 vs. 标注PM 的判断规则
✅ AI自行修复（能修则修）
字段描述歧义
→ 用更精确的描述替换
命名前后不一致
→ 统一命名+全局替换
数据项表格留空
→ 联系上下文推断，以假设补充
缺少验收标准
→ 自行推导3条 Given/When/Then
❗ 必须标注PM（不能自填）
涉及业务决策
→ 优先级/审批/超时阈值，由PM定
涉及外部依赖
→ 第三方接口/数据来源，不在团队内
涉及特殊权限
→ 未经明确授权的角色操作，需安全确认
业务规则无文档支撑
→ 无法从上下文推断的数值/逻辑
05
PRD文档章节结构
Structure · 12章标准结构
1
文档控制
2
问题定义
5W1H
3
业务背景
+流程
4
总体设计
+功能列表
5
功能列表
+验收标准
6
界面流转
+页面原型
7
详细设计
数据项+接口
8
非功能
需求
9
发布计划
+成功度量
10
协作
管理
11
假设
待确认
🛡️
质控报告
自动追加
必填
建议
可选
自动追加
06
数据项规范（11列标准格式）
Data Fields · 字段级精确定义
序号字段名控件类型数值类型长度必输新增编辑值列表说明默认值校验规则其他说明
1示例字段文本字符200YYN--不能为空创建后只读
🔤
字段类型命名（中文统一）
数据库类型PRD写法
VARCHAR字符（需标长度）
INT整数（可标范围）
DECIMAL小数（标精度）
DATE日期（YYYY-MM-DD）
DATETIME日期时间（HH:mm:ss）
BOOLEAN布尔（是/否）
TEXT长文本
📝
新增/编辑 Y/N 填写规则
页面类型新增编辑
只读详情页NN
新建表单YN
编辑表单NY
创建后只读YN
灰显但可见YN（灰显）
07
Word导出字号规范（微软雅黑）
Typography · 导出后层次感
H1
一级标题
18pt · 加粗
H2
二级标题
14pt · 加粗
H3
三级标题
12pt · 加粗
正文内容
段落正文
10pt · 常规
表格内容
表格内文字
小五（9pt）· 常规
页眉 / 页脚
页眉页脚
小五（9pt）· 常规
📋 表格样式：全包黑色框线 + 表头浅蓝底色（#D9E2F3）
Typora导出：偏好设置 → 导出Word → 勾选"使用pandoc模板" → 指定 reference.docx 路径
08
范围裁剪决策树
Scale · 只裁"展开深度"，不裁"硬字段"
A
A档 · 小型
无谱系拆分/召回/审计更正/离线补传/跨多系统，仅基本CRUD
8/9章 →
简版即可
10/11章 →
可不写
B
B档 · 中型
涉及A档中1-2项，或存在关键业务链路
8/9章 →
标准版
10章 →
建议写
11章 →
可选
C
C档 · 大型
涉及≥2项，或跨ERP/MES/WMS/QMS/PLM多系统一致性
8/9章 →
标准或更细
10/11章 →
至少写一个
09
Skill文件结构
File Tree · 仓库内容一览
📁 追溯系统-功能设计文档编写/
📄 SKILL.md ← ⭐ 主文件（加载此文件）
📄 CHECKLIST_V2.0.md 质量检查清单
📄 README.md 使用说明（你在这里）
📄 CHANGELOG.md 更新日志
📄 VISUAL_README.html ← 🎨 可视化全览图（浏览器打开）
📄 reference.docx ← Word导出模板
📁 reference/
📄 templates.md 11个文档模板
📄 prototype-driven.md ⭐原型驱动详细指南
📄 traceability-domain.md 追溯领域模板
📄 document-structure.md
📄 examples.md
📄 tools.md
📁 testing/
📄 pressure-scenarios.md
10
版本信息
Version · V1.0 首次公开发布（公测）
📅
V1.0 · 首次公开发布
  • 两种工作模式（传统沟通 + 原型驱动）
  • 五大核心原则（证据优于断言 / 接口双读者 / 11列规范 / 追溯领域覆盖 / 质控门）
  • PRD自检质控门（5维度自动评分）
  • 12章标准文档结构
  • Word导出模板（微软雅黑 + 全包框线）
  • 范围裁剪决策树（A/B/C三档）
  • 反失败纠偏脚本（8种施压场景）
🎉 首次对外发布，欢迎使用并反馈！
🔮
未来规划
  • 支持更多场景的模板（报表导出 / 审批流 / 移动端适配）
  • 验收标准自动生成助手（Given/When/Then批量输出）
  • 接口契约模板（各系统对接规范库）
  • 英文版README（国际团队协作）
  • Skill性能评测报告（定期review）
欢迎贡献！
GitHub: github.com/HUHU19961014/Trs-prd-skill
TRS系统 功能设计文档编写 Skill · V1.0 · 2026-04-11（首次公开发布）
基于 企业顾问团队标准 + GitHub热门PRD模板 + 追溯系统行业最佳实践