jorinyang 技术文档套件产出与校验工作流
前置规则（来自用户偏好）
- 先读完所有材料再动手 — 用户提供多份会议纪要/录音转写时，必须全部读取完毕后才开始产出
- 中文输出 — 技术文档使用中文
- 信息密度要一致 — 每份文档的信息量应相当，不能某份文档特别薄
- 逻辑链路要完整闭环 — 每条业务链路必须能从起点追踪到终点
标准输出套件
| 文档 | 内容 | 格式建议 |
|---|---|---|
| PRD | 完整产品需求文档 | Markdown, 12+章节 |
| 数据关系图 | E-R图 + 实体字段 + 关联关系 | Mermaid ERD 代码块 |
| 系统架构图 | 模块层次 + 集成关系 + 角色权限 | Mermaid flowchart |
| 业务流程图集 | 每条核心业务链路的完整流程图 | Mermaid flowchart, 标注关键节点 |
工作流（串行阶段）
阶段1: 信息采集
- 读取所有录音转写(.txt) 和会议纪要(.md)
- 建立需求清单 → 关键决策记录 → 待办追踪的完整索引
- PITFALL: 不要只看纪要，转写中可能有纪要遗漏的操作细节
阶段2: 产出PRD（先做PRD，它是其他文档的锚）
- 结构: 项目概述 → 目标范围 → 用户角色 → 主数据 → 采购 → 仓库 → 销售/领用 → 财务 → 报表 → 集成 → 非功能 → 附录
- 关键规则/算法（如动态加权平均）要在正文和附录中同时体现
- 版本号标注，变更记录表
阶段3: 并行产出图表（使用 delegate_task）
Task A: 业务流程图集（基于PRD）
Task B: ER图 + 架构图（基于PRD）
- 给子代理的context必须包含：PRD路径 + 关键变更清单 + 输出文件路径
- 子代理产出后，主代理负责校验
阶段4: 四维度校验
| 维度 | 检查内容 | 方法 |
|---|---|---|
| 维度1: 需求一致性 | 所有会议纪要中的关键需求是否在PRD中体现 | 逐项对比需求清单 |
| 维度2: 跨文档一致性 | 同一概念在四份文档中是否表述一致 | 交叉搜索关键术语 |
| 维度3: 信息密度一致性 | 各文档篇幅/图表数是否均衡 | 统计行数+图表块数 |
| 维度4: 逻辑正确性 | 各业务链路是否形成完整闭环 | 追踪起点→终点 |
实现建议：使用 execute_code 编写Python校验脚本，对四份文档自动执行上述检查。
PRD迭代修改工作流
当客户反馈（新会议纪要）需要修改PRD时：
- 逐项提取变更清单（变更类型: 重大🔴/扩展🟡/新增🟢/决策🟡）
- 使用
execute_code+patch批量应用变更（避免手动逐条编辑） - 每次patch后验证关键检查点
- 更新版本号
- 如有决策被后续会议反转（如05-20的"两类销售"被05-22反转为"统一过库"），在PRD中注释说明决策演变过程
并行加速策略
- PRD产出 → 串行（它是其他文档的锚点）
- 流程图+ER图+架构图 → 使用
delegate_task并行产出（tasks数组） - 校验 → 使用
execute_code运行自动化校验脚本（模板见 references/validation-script-template.md）
与 prd-and-diagrams-from-transcripts 的合并说明
本技能（technical-documentation-production）是 prd-and-diagrams-from-transcripts（英文版）的合并后继。两者的工作流完全一致：
- 输入：会议纪要/录音转写
- 输出：PRD + ER图 + 架构图 + 业务流程图
- 核心方法：先读完所有材料 → PRD作为锚点 → 并行产出图表 → 四维度校验
英文版的内容已整合进本技能的各章节中。如需英文输出，请基于本技能的步骤结构自行翻译。
参考文件来源（来自已归档的英文版）：
prd-and-diagrams-from-transcripts/references/prd-section-template.md— PRD章节模板prd-and-diagrams-from-transcripts/references/mermaid-patterns.md— Mermaid语法模式与示例
PITFALL: 子代理自报告不可信
子代理声称"文件已写入"或"上传成功"时，主代理必须自己读取文件验证。 子代理可能对文档做未经要求的修改（如添加虚构的会议细节），主代理须抽查关键章节。