PRD 文档（Product Requirements Document）

角色定位

本技能是产品经理工作室（pm-project 工作流）的「格式 owner」之一，专门产出 PRD 需求文档，按「文首固定四段 + 正文十节」的固定格式。内容来自项目主档（单一事实源）。

通常由 pm-project 在「第三步 派发」路由调用：用户说"生成 PRD" → pm-project 查路由表 → 调用本技能。

> 注：pm-project 另保留一条「远端付费一键渲染」通道（见其「付费能力」节），适合需要快速整篇渲染的场景；本技能是本地可控的格式 owner，二者并存，优先用本技能保证格式与事实源一致。

> 文首四段是本客户 Word 形式项目文档的通用块（PRD、操作手册等篇幅型文档默认带；表格型短文档如会议纪要除外）。本技能的「文首固定块规格」是这套块的规格权威来源，其他格式 owner 沿用同一套表，只改文档名称类文案（封面文档名称末行、文档控制表的「标题」、页眉右侧）。

文档骨架（固定）

文首四段（每份 PRD 必带，顺序不可调换、不可省略，位于正文「一、文档说明」之前）

• 第 0 段 封面 —— 标题三行（{项目名} / {产品名或子系统名}（无则删去本行） / 需求说明书）+ 2 列 4 行封面信息表
• 第 1 段 ## 文档控制
• 第 2 段 ## 修改历史
• 第 3 段 ## 审阅人

正文（前置块 + 十节）

1. 引言块：只保留「文档状态 / 适用版本」两项；文档版本、编写人、编写日期由文档控制表承载，不再重复
2. ## 图片资源说明：图片目录、命名规则、插入位置、来源
3. # 一、文档说明：编写目的 / 适用范围 / 参考文档 / 术语与缩略语
4. # 二、产品概述：业务背景 / 问题与机会 / 产品定位与目标 / 目标用户与角色 / 核心价值
5. # 三、整体功能架构：表 3-1 系统功能地图（一级 / 二级 / 对应章节）、表 3-2 功能清单（编号 / 所属模块 / 页面名称 / 功能摘要 / 优先级 / 实现状态）、模块关系
6. # 四、全局规则与通用约定：页面骨架、组织树、列表、状态标签、表单、提示条、颜色语义、字段说明表格约定
7. # 五、详细功能需求：全文核心，逐页描述
8. # 六、数据需求 / # 七、非功能需求 / # 八、接口与外部系统 / # 九、风险与待确认问题 / # 十、附录

版本变更只有一处：文首「修改历史」表即本文档唯一的版本变更记录，正文不再设 ## 修订记录 节——同一信息不出现两次。

文件名固定为 PRD_{项目名}.md；文档内不再单独写 PRD_{项目名} 标题行，封面主标题即项目名。

文首固定块规格

第 0 段 封面

封面只有三行居中加粗的标题 + 一张信息表，版面自上而下分三段留白（抬头 / 标题与文档名 / 信息表落地），信息表落在页面下方约 2/3 处，不紧跟标题。标题三行依次为：

信息表固定 2 列 4 行、带网格线、整表居中，标签列约 5.2cm、值列约 7.4cm，行高不小于 1cm：

• 标签列右对齐、半角冒号 :；日期标签写 日　　期:（「日」「期」之间两个全角空格撑开，使标签不显局促）。
• 第三行标签为 (公司简称)项目经理:——半角括号内是占位说明，实际文档直接写承接方公司简称，如「奇策项目经理:」「诚迈项目经理:」；不得写成不具名的「公司项目经理:」。
• 值列左对齐，一律写 {...} 占位符（{客户方项目经理姓名} / {YYYY-MM-DD} / {承接方项目经理姓名}）——不写下划线填空；确认后直接替换为真实值，交付前不留占位符。
• 日期取客户与承接方各自的确认日期，不与文档控制表的编写日期强行取同一天。
• 第 2 行是占位模板行：项目无产品名/子系统名时整行删除，不留空行。
• 封面不放摘要、目录等正文内容。标题三行用居中加粗段落实现，不占标题级别、不进目录；转 Word 时封面独立成页（信息表后加分页符），首页不显示页眉。

第 1 段 文档控制

标题 ## 文档控制。表格固定 2 列 9 行：左列为标签、右列为对应值，值单元格左对齐，不设表头行。左列标签单元格加粗 + 浅灰底（#D9D9D9），与「修改历史」「审阅人」的表头行同一底色，三张表的标题区格式统一。

• 标签行序固定：项目编号、文控编号、项目名称、文档标题、当前阶段、文档摘要、当前版本、编写日期、编写作者，不增行不调序。
• 左列宽度固定（约 3cm，容纳四字标签不折行），值列占满其余宽度。
• 文控编号规则：{项目编号}_{两位模块序号}_{三位流水号}，如 SZQC2024010_02_014。
• 当前阶段固定列出全部五个阶段，用顿号分隔，只在当前所处阶段前加 ☑，其余阶段不加任何符号（不是 ☐）；有且只有一个 ☑。
• 文档摘要写本次需求覆盖的范围与目的，不写技术实现；无内容时留空，不留占位文字。

第 2 段 修改历史

标题 ## 修改历史。表头固定 4 列（表头加粗居中）——日期 / 版本 / 作者 / 修改内容；首行为初始版本，其后每更新一版追加一行，末行保留一行空白行供后续填写。

• 「修改内容」写清本版改了什么，可多句、可要点式分条——这是全文唯一的版本变更记录，正文不再另设 ## 修订记录 节；每更新一版追加一行，不覆盖历史行。空值留空，不写「—」「暂无」。
• 日期统一写 YYYY-MM-DD，不用不补零的写法（如 2004-2-9）。

第 3 段 审阅人

标题 ## 审阅人。表头固定 4 列（加粗居中，「审阅签字」列留宽）；首行为示例行——日期 / 姓名 / 职位照实填，未确定时填占位值或留下划线空白，审阅签字列一律留空供手签；末行保留空白行供增补。不写「暂无」。

正文版式、页眉与表格样式（转 Word 时设置）

• 页面：A4（210mm×297mm）；页边距上下 2.54cm、左右 2.5cm，标准页边距，无特殊缩进与留白调整。
• 正文：宋体小四（12pt），全文统一、无特殊字体 / 字号、不加粗 / 不变色 / 不倾斜（行内 **重点** 标注除外）；1.5 倍行距，段前 / 段后间距均 0 行；每个自然段首行缩进 2 字符（列表项随正文左缩进 2 字符，无悬挂缩进、无顶格）；两端对齐（justify）。图题、表格内文字不缩进。
• 标题（H1~H4）：黑体四号（14pt）、加粗、不变色，严格区分层级——一级标题居中对齐、段后间距 1 行、无首行缩进；二级标题左对齐、段后间距 0.5 行、无首行缩进；三级标题左对齐、无段间距、无首行缩进；四级同三级。封面主标题、文首三段标题不倾斜（由 md_to_docx.py 强制 italic=False）。
• 表格内容：与正文一致，宋体小四（12pt），1.5 倍行距；单元格内文字统一左对齐 + 垂直居中，边框完整（网格线）、线条统一、单元格间距均匀。表头行保持加粗 + 浅灰底 #D9D9D9（不再居中，与数据单元格同左对齐），以便区分层级。
• 页眉：从第二页起显示——左侧公司 LOGO + 公司名（如「智汇奇策」），右侧「详细需求说明书」，与封面文档名称末行一致；页眉下方带一条横线。封面页不显示页眉。
• 三段标题：「文档控制」「修改历史」「审阅人」用加粗小标题样式，与正文一级标题区分，不进目录。
• 文首固定块（封面信息表 / 文档控制表）例外：封面信息表整表居中 + 标签列右对齐 + 值列左对齐（2 列 4 行、带网格线），文档控制表左列标签单元格加粗灰底居中，属固定块版式，不受表格「全部左对齐」约束；文档控制表无表头行（左列标签、右列值），值一律左对齐。修改历史 / 审阅人的末行空白行必须保留（给 0.9cm 最小行高，供手写签字 / 增补），md 写成 | | | | |。
• 落地脚本：本技能不含转档脚本，统一用 pm-operation-manual/scripts/md_to_docx.py（本规格即由它实现，自动套 A4 / 页边距、封面分页、页眉、灰底表头、宋体小四 / 1.5 倍行距 / 首行缩进 2 字符 / 两端对齐、表格小四左对齐 + 垂直居中与空白行最小行高）。

第五章目录层级（与系统菜单一致）

• 一级菜单 → ## 5.x
• 二级菜单 → ### 5.x.y
• 页面四节：一级菜单即页面时落为 ### 5.x.1 ~ 5.x.4；二级菜单下落为 #### 5.x.y.1 ~ 5.x.y.4

逐页四节（每页固定四节）

1. 页面概述 —— 一段话，先说清所属菜单与页面定位，再说页面分区；节后紧跟一张该页功能 / 菜单的整页截图（呈现页面全貌），不放局部图
2. 功能设计描述 —— 「一、功能」编号分条：每个功能点先一句话说清它是页面上哪一块、用来做什么，再展开子项（区块数量与列数、按钮、弹窗的字段与按钮）/「二、规则限制」/「三、字段说明」；通篇不放截图
3. 交互设计描述 —— 「一、交互操作」/「二、状态与联动」；只放具体交互涉及的弹框、按钮、下拉、状态提示等需标识的局部截图（图紧贴它说明的那一步操作）；整页截图不放此节，无局部图时该节为纯文字。排版基准（强制，不可省略）：「一、交互操作」下采用两级有序编号——1. 操作组（概括一类操作，如「组织树与查询」「列表行内操作」「弹框提交」「筛选与排序」），其下 1.1 / 1.2 / 1.3 … 为逐条独立成行的子步骤，每条写"怎么点、点了之后看到什么"；每条子步骤文字之后紧跟该步骤对应的局部截图（图随步走，不堆在节末）；严禁用 ① ② ③ 把多个子步骤连排成同一段，严禁把多张图集中堆在节末或节首而无步骤文字呼应。子步骤粒度到"一次可完成的点击动作"，不可过粗到一段概括全部。
4. 验收要点 —— 分条，正常路径与异常分支都要有

三节分工不要越界：功能段回答「这个页面有哪些功能点」，交互段回答「这些功能点怎么操作、操作后看到什么」。功能段写的是"有什么"，不写点击行为；交互段写的是"怎么点"，不再重复罗列元素清单。

字段说明表格表头固定为「序号 / 字段名称 / 是否必填 / 字段描述 / 示例」；「是否必填」只用于表单类录入字段，列表与展示类写「—」；「示例」取原型实际取值，原型未呈现具体值的写「—」。

内容来源（严格按此，不得臆造）

• 页面名、所属菜单、用途 ← 主档第 3 章页面清单
• 功能设计 / 交互设计 ← 原型的页面说明数据（SPEC 对象，若有）
• 功能编号 F-nn 与页面 P-nn 一一对应，不新增编号
• 优先级、验收要点、非功能指标属推导项，须在表中或章节内注明「为初判，待主档确认」
• 主档空章节（背景、目标、角色）不编造，写待确认项并说明依据来源
• 文首四段的项目编号、文控编号、客户/承接方项目经理、审阅人 ← 主档第 0 章文档信息；主档无值时向用户索取，不自行编造

截图与图片

放哪里（硬规则）

• 整页截图放「页面概述」节后：每页一张整页截图（{章节编号}_{页面名}_功能描述.jpg 或 _页面.png），置于「页面概述」节之后，呈现该页功能 / 菜单全貌；「功能设计描述」不放任何图。
• 局部截图只放「交互设计描述」：弹窗、下拉、二级页面、状态提示、按钮态等需标识的局部图（{章节编号}_{页面名}_{用途}.png），紧贴描述它的那一条操作步骤，放在该步骤文字之后；整页截图不进此节，无局部图时该节为纯文字。
• 一个操作组内有多张图时按操作先后排列；每张局部图必须紧跟在引用它的那条子步骤（1.1 / 1.2 …）文字之后，不出现没有文字呼应的孤立图，也不把图集中堆在节末或节首。
• 功能段提到的元素（按钮、列、弹窗）若需配图，图放交互段对应步骤下，功能段保持纯文字。

图怎么来

• 截图从原型无头渲染获取（做探针页按 ?p=<页面编号> 切页 + 关过渡动画，量高度后整页截图）。
• 图片必须先上传到资料库图床换公网直链，再写入正文；直接写本地路径线上看不到图。
• 识图纪律：列名、按钮文案、弹窗标题、字段标签属于小字，必须裁剪放大 3~5 倍逐项核对后再落笔；总览缩略图极易看错（实测把「连接设备数量」看成「连接设备数据」、「北向消息」看成「北向通道」、「刷新列表」看成「列列表」、「仅下发」看成「下载」）。同一元素在总览图与局部放大图不一致时，以放大图为准。
• 同一弹窗的多张截图内容重复时，只保留信息量最大的那一张写入正文，不重复引用。

工作流程

1. 读取主档第 0、1、2、3、4、5、6 章（由 pm-project 传入）。
2. 先落文首四段（封面 / 文档控制 / 修改历史 / 审阅人），再按「前置块 + 十节」骨架写正文（正文不设「修订记录」节），文件名 PRD_{项目名}.md，存「03-PRD」。
3. 双落库与链接回执由 pm-project 收口；带截图文档走「Markdown → Word → 文件导入」链路（腾讯文档 insert_markdown 不导入图片），导入后用 doc.get_images 核对图片数量、用 manage.move_file 归位到镜像目录。
4. 转 Word 时按本文规格设置封面（三行标题的抬头空白 / 段间距、2 列 4 行信息表带网格线居中、信息表落地留白、分页）、文档控制表 2 列 9 行（左列标签加粗灰底、右列值左对齐）、页眉。

自检

• 文首四段是否齐全且顺序为「封面 → 文档控制 → 修改历史 → 审阅人」。
• 封面标题是否为三行（{项目名} 26pt / {产品名或子系统名}（无则删去本行） 18pt / 需求说明书 18pt）、均居中加粗且标题行不进目录；封面信息表是否为 2 列 4 行、带网格线、整表居中、标签列右对齐且用半角冒号 :（日期标签 日　　期:）、值列左对齐且写 {...} 占位符（未留下划线）、信息表是否落在页面下方约 2/3 处。
• 文档控制表是否为 2 列 9 行、9 个标签是否齐全且顺序为「项目编号 / 文控编号 / 项目名称 / 文档标题 / 当前阶段 / 文档摘要 / 当前版本 / 编写日期 / 编写作者」、左列标签是否加粗灰底（与修改历史表头同底色）、值是否左对齐（未居中）、当前阶段是否只有当前项带 ☑（其余阶段不加 ☐）、文控编号是否符合 {项目编号}_{两位}_{三位} 规则。
• 「修改历史」是否为 4 列表头（日期 / 版本 / 作者 / 修改内容，不含评审号、更改请求号）、首行是否为初始版本、是否覆盖全部版本、末行是否留空行（转 Word 后仍在）；正文是否已无 ## 修订记录 节（版本变更只在「修改历史」一处）。
• 「审阅人」是否为 4 列表头（含「审阅签字」列）、首行是否为示例行、末行是否留空白行（转 Word 后仍在，行高约 0.9cm）、签字列是否留空。
• 正文版式是否到位：A4 / 页边距（左右 2.5cm）、宋体小四（12pt）、1.5 倍行距、每个自然段首行缩进 2 字符且两端对齐；标题黑体四号加粗、H1 居中 / H2·H3 左对齐；表格全部单元格宋体小四、左对齐 + 垂直居中，表头行保持加粗 + 浅灰底（不再居中）。
• 引言块是否已去掉与文档控制表重复的版本 / 编写人 / 编写日期三项。
• 章节数是否与主档页面数一致（第五章小节数 = 页面数）。
• 每页是否四节齐全（概述 / 功能设计 / 交互设计 / 验收要点）。
• 推导项是否标「待确认」。
• 编号是否只引用不新增。
• 截图布局是否合规：每页「页面概述」节后是否有一张整页截图；「交互设计描述」是否只含弹框 / 按钮等局部交互图（整页截图不进此节、无局部图时为纯文字）；每张图是否紧贴它说明的那一步操作、有文字呼应；图片是否已换公网直链。
• 功能段是否只写「有哪些功能点」，未混入点击行为描述；交互段是否只写「怎么操作」，未重复罗列元素清单。
• 交互设计描述的「一、交互操作」是否采用「1. 操作组 → 1.1 / 1.2 / 1.3 … 子步骤」两级编号、每条子步骤独立成行且文字之后紧跟对应局部截图（图随步走）；是否出现 ① ② ③ 把多步连排成同一段、图堆在节末 / 节首而无步骤文字呼应、子步骤粒度过粗（一段概括全部操作）等问题。

付费能力（支付宝 AI 按量付费 / A2M）

本 Skill 的核心产出规格由远端付费服务下发，脱离后端服务无法独立完成。调用链严格遵循支付宝 A2M 按次计费协议。

付费端点

POST https://skillpay-gateway.app.workbuddy.link/api/skill/pm-prd-doc/invoke

免费端点（先看契约再付费）

GET https://skillpay-gateway.app.workbuddy.link/api/skill/pm-prd-doc/spec

六步调用链

1. 探测（probe） —— 先请求 spec 端点，获取入参契约、产出结构（sections）与当前价格。
2. 账单下发（402） —— 直接调用 invoke 端点时，服务返回 HTTP 402 Payment Required，响应头携带 Payment-Needed 字段（Base64URL 编码的账单，含 out_trade_no、amount、currency=CNY、resource_id、pay_before、seller_signature）。此时不产出任何内容。
3. 用户支付 —— 按账单金额完成支付，取得支付凭证。
4. 携带凭证重试（Payment-Proof） —— 用同一请求体重放，并在 Payment-Proof 请求头携带 Base64URL 编码的支付凭证（含 payment_proof 与 trade_no）。
5. 验付（verify） —— 服务端调用支付宝接口 alipay.aipay.agent.payment.verify 验签，校验金额、资源、商户一致。
6. 履约确认（fulfillment complete / ack） —— 验付通过后服务调用 alipay.aipay.agent.fulfillment.confirm 完成履约回执，并在响应中返回产出规格包（PRD 结构骨架〔文首四段 + 正文十节 + 逐页四节〕+ 硬规则 + 本次入参）与 fulfillment_confirmed: true。

费用

• 计费方式：按次调用计费
• 单价：¥0.20 / 次
• 币种：CNY

幂等与安全

• 严禁伪造、复用或改造 Payment-Proof 凭证。
• 严禁在未完成付费的情况下，由本地逻辑补齐或模拟付费端点应有的产出。
• 不得改写 Payment-Needed 账单中的签名与金额字段。
• 同一凭证重复提交必须返回同一结果，且不重复扣费。
• 验付失败时服务回退为 402，不得降级放行。

> 本节的付费链路只下发产出规格；最终 Markdown → Word 渲染由 pm-operation-manual/scripts/md_to_docx.py 完成（本技能不含独立转档脚本）。