docs: simplify ERP requirements design skill

skills/erp-requirements-design/references/prd-style.md

@@ -1,76 +1,62 @@
 # PRD 结构与表达规范
 
-本规范适用于本技能生成的中文业务评审稿。用户提供模板或提出其他明确格式要求时优先；局部修订不自动扩大为整篇改版。
+默认交付简洁的业务评审稿。用户指定的结构、字段和详细程度优先；局部修改不触发全文扩写。
 
-## 文档结构
+## 简版结构
 
-从“主标题、版本记录表、业务正文”开始。版本记录位于最前，不在标题下重复副标题及版本、日期、状态说明行。版本表为“版本、修订日期、修订内容”，每个版本一行，版本及日期取真实记录。
+文首为“主标题 → 版本记录表”，表头为“版本、修订日期、修订内容”，每个版本一行。正文按下列结构裁剪，无内容的章节直接省略。
 
-| 章节 | 核心内容 | 适合的表达方式 |
+| 章节 | 保留内容 | 建议表达 |
 |---|---|---|
-| 背景与目标 | 背景、目标、本期边界及完成标准 | 简洁段落，必要时列范围表 |
-| 现状及预期效果 | 业务环节的变化与预期改善 | 环节对照表、功能建设清单 |
-| 整体流程 | 角色衔接及关键分支 | 泳道图或流程图及文字说明 |
-| 详细需求 | 页面、字段、操作及异常 | 按页面展开，结合示意、字段及操作表 |
-| 权限与状态规则 | 角色范围、状态及关键规则 | 权限矩阵、状态图或必要的状态表 |
-| 验收与上线要求 | 完成标准、异常及切换验证 | 场景、前置条件与操作、预期结果 |
-| 评审确认事项 | 未决事项、责任与影响 | 事项名称、建议方案、确认责任及影响 |
+| 背景与目标 | 解决什么问题、本期做什么 | 一至两段，不重复拆背景、目标、范围 |
+| 整体流程 | 角色、顺序、完成标志 | 一条文字流程或一张紧凑主流程图 |
+| 功能需求 | 入口、必要字段、主要操作和结果 | 按实际页面分节，配必要的短表 |
+| 权限与办理规则 | 查看及办理范围、变更、异常与进度 | 短段落或合并规则，不穷举组合 |
+| 验收与上线 | 核心场景、预期结果、准备工作 | 两列表格及简短上线说明 |
+| 评审确认事项 | 影响定稿的真实未决问题及责任人 | 短表或列表，已确认事项移出 |
 
-现状尚未核实时采用“已明确的管理诉求”对照，不为填表编造现行流程。新增功能标明“本期新增”，未复核的既有能力写“拟复用，适配范围待核实”。
+现状对比、功能建设清单、统计口径、详细状态表、页面示意均按需要加入，不是必填章节。不为填表编造现状。篇幅随业务复杂度确定，不把某次四页文档或六项验收当作固定指标。
 
-## 标题与正文
+## 内容粒度
 
-业务章节采用 `1`、`1.1`、`1.1.1`，不与中文序号混排，不为凑三级标题机械拆分。Word 使用对应标题样式和提纲级别，不只加粗普通段落。
+每个功能回答“在哪里、谁使用、做什么、结果是什么”。影响操作的条件在对应句子或字段旁说明；不要为每个功能再建一套前置条件、权限、异常、日志及验收子章节。
 
-| 口语表述 | 正式表述示例 |
-|---|---|
-| 为什么要做 | 业务背景、建设目标 |
-| 这个功能要解决什么问题 | 项目概述、背景与目标 |
-| 谁来审批 | 审批人员与节点配置 |
-| 怎么填写、从哪里申请 | 表单字段与校验、申请入口与提交规则 |
-| 出问题怎么办 | 异常处理、失败恢复 |
-| 需要谁拍板 | 待确认事项、确认责任 |
-| 看看有没有办完 | 办理状态、完成标准、验收要求 |
+| 内容 | 简版写法 | 需要展开的条件 |
+|---|---|---|
+| 菜单 | 共同父级路径写一次，列页面与用途；跨模块入口补完整路径 | 菜单归属或不同角色入口存在实际分歧 |
+| 基础资料 | 维护人、建档方式及必要字段；少量字段直接一句列出 | 导入、同步、资源变更等属于本期明确需求 |
+| 表单 | “信息｜填写要求”，相关字段合并为一组 | 字段单位、金额门槛、条件附件会改变业务结果 |
+| 权限 | 按角色说明可见及可办理范围 | 涉及跨组织数据、金额或敏感对象的差异权限 |
+| 异常 | 合并说明取消、核实、补登记等业务处理原则 | 部分履约、冲销、退款等存在不同后果 |
+| 验收 | “验收场景｜预期结果”，同类操作合并 | 用户要求测试方案，或前置条件会改变预期结果 |
 
-正文及表格也使用正式而具体的表述，例如“审批通过后生成待办，由有权限的管理员领取；登记实际办理结果后记为已完成”。不要只替换标题而保留口语，也不要用空泛术语代替业务动作。
+详细规格按用户指定的章节展开；数量、金额、库存、审批和权限等关键约束按实际业务补齐。不要由一个复杂环节带动所有章节扩写。
 
-功能用业务名称，如“供应商准入申请”；验收用场景名称，如“审批人员失效”“取消与办理并发”。交叉定位使用名称或章节号，默认不引入技术式标识及编号追踪矩阵。
+## 字段与语言示例
 
-## 页面需求的写法
+采用业务人员熟悉的词，能说“人员范围”就不写“受众”。字段来源、只读状态、字符数、系统标识及账号绑定只在影响业务办理时写，不为普通资料维护自动补齐这些说明。
 
-按“建设方式、入口与角色、页面内容、操作与结果、异常与权限”展开。例：
+例如用户已确认渠道档案字段时，可直接写：
 
-**4.3 资格核对**
+> 业务管理员在“通知渠道”人工建档。群聊记录群名称、人员范围和群主；公共邮箱记录邮箱名称、发件地址和发送负责人。
 
-建设方式：本期新增，审批结果拟复用审批中心。入口：采购中心下的业务模块，具体层级须根据该业务确认。使用角色：获授权的资格核对人员。
+这段说明用于示范字段取舍，不代表所有通知业务都用同一字段集。用户指定“只保留”的清单按其原意执行，不自动补回平台、群 ID、用途、账号关联或凭据管理等细节，也不移到验收或待确认事项中。
 
-审批通过后形成核对待办。核对人员查看批准版本及允许访问的附件，登记核对结果；核对通过并执行启用后，供应商状态变为已启用。审批通过本身不构成启用完成。处理结果不明时先核实原记录，不重复创建供应商。
+正文采用正式、直接的业务表达，如“审批通过后生成待办，由负责人办理并登记结果”。标题使用“背景与目标、申请、审批、发送与回执”等具体名称，通常保留两级标题；不机械拆成三级。
 
-此例仅说明描述粒度，不是其他模块的默认菜单或确认规则。实际文档应将已确认入口写成完整路径，并补齐字段和异常要求。
+功能、规则和验收用业务名称定位，默认不引入技术式编号。重要规则集中说明，验收只写结果，不再复述完整规则。
 
-## 图表与示例
+## 图示与示例
 
-- 跨角色主流程使用泳道图，判断节点标明条件和结果，动作与对应角色一致。
-- 新建页面用低保真示意展示信息分区、关键字段和按钮，标注“拟建页面／非现有界面”。正文保留字段和操作条件。
-- 现有截图注明环境、日期和观察范围；只参考表达风格时，不移用其中的业务规则、数据、人员或链接。
-- 状态或异常图承担必要解释，不重复制作同义图。保留文字流程，便于图片无法显示时理解。
-- 对比、字段、状态和验收等重复结构使用表格；长段规则使用正文，避免挤入窄列。设置合理列宽和跨页表头。
-- 示例注明虚构，覆盖关键判断；时间、金额、数量与正文一致，不以示例暗定限制。
+- 图用于解释角色衔接或不易理解的页面；一张主流程图已能说明时，不重复增加同义图或逐步骤示例表。
+- 页面示意标注“拟建页面／非现有界面”；实站截图注明环境和观察日期，不能把图上的字段、数量或状态当作行为验证。
+- 虚构例子明确标注，不通过样例设定未知限额；金额和时间计算用确定性方法核对。
+- 表格适合菜单、字段、角色和验收的并列信息；长说明用正文。删节靠减少重复和合并内容，不靠缩小字号或挤压行距。
 
-## 评审稿与工作记录
+## 修改和交付前核对
 
-交付稿围绕业务背景、目标、规则及待决事项，不默认附带“参考了哪些资料”、工具过程或“本轮未访问哪些页面”等编制过程章节。资料路径、读取时间和观察证据留在工作记录，按需可追溯。
+先读当前维护稿及用户最新修改，保留已确认的范围和删节决定。将同类细节从模板提示中移除后再生成，避免 Word、Markdown 或图示把它们恢复。
 
-仍须准确表达业务事实：拟建图标为示意，未确认权限和审批层级保留待定，未验证能力不写成已支持，验收条件不写成已通过。用户要求来源说明时另行添加，不能为精简隐瞒影响业务判断的限制。
+业务事实和证据边界保留在相关句子旁：建议不写成定论、拟建不写成已实现、待验收不写成已通过。正文不额外添加工具过程、资料清单或泛化安全说明。
 
-## 菜单与档案检查
-
-成稿前应能明确回答：
-
-1. 一级菜单、二级模块和三级页面分别是什么；哪些属于详情页或申请类型而非导航菜单。
-2. 申请、审批、办理和资料维护各从哪个完整路径进入；不同入口是否对应同一单据。
-3. 父级和子菜单可见性如何授予，是否会扩大其他功能或数据权限。
-4. 基础档案由谁建立、从哪里维护，人工录入、导入或同步的方式是否已确认。
-5. 识别信息、负责人和系统账号如何关联，变更、停用及历史记录如何处理。
-
-内部群管理归属行政中心是该模块的已确认决策，不是其他业务的默认归属。未决菜单需给出有依据的建议及影响；确认后同步所有引用，移除相应的“归属待确认”表述。
+最后通读：主流程能否贯通，字段是否必要，同一规则是否写了多次，常见异常是否可合并，关键约束和真正未决问题是否仍然清楚。