docs: simplify ERP requirements design skill

skills/erp-requirements-design/SKILL.md

@@ -5,20 +5,25 @@ description: Use when a user describes a new ERP business process or requests a
 
 # ERP 产品需求设计
 
-将业务诉求整理为供业务评审、开发设计和测试使用的产品需求文档。默认中文，交付同版本 Word 与 Markdown。以正式、具体的业务表述说明角色、入口、条件、操作及结果，技术方案由开发另行设计。
+把业务诉求写成简洁、可评审的产品需求文档。默认中文，Word 与 Markdown 同步维护。让读者看懂“谁从哪里进入、填写什么、如何办理、何时完成”；技术方案由开发另行设计。
 
-## 工作边界
+## 默认写简版
 
-- 输出业务流程、页面行为、字段、权限、状态、模块衔接及验收要求，不默认输出数据库、SQL、接口报文、类名、技术选型或编码任务。
-- 网站观察默认只读，不提交单据、执行审批、调整权限或发送通知。凭据按当前授权使用，不进入文档。
-- 产品建议、已确认需求、已实现能力和验收通过分别表述。文档成稿不等于业务定稿或获准上线。
+- 采用“背景与目标 → 整体流程 → 功能需求 → 权限与办理规则 → 验收与上线 → 评审确认事项”的结构，按实际内容合并或省略章节。
+- 每个功能用短段落说明入口、角色、主要操作和结果；字段表只列业务必需的信息及影响办理的填写条件。
+- 同一规则集中写一次。主流程讲步骤，功能讲操作，规则讲关键约束，验收讲可观察结果，不在各处复制整套说明。
+- 常见异常合并说明处理原则和责任人；用户未要求测试方案时，不把所有状态组合、并发时序、重试过程展开成用例。
+- 用业务人员熟悉的词，如“人员范围”，不用“受众”“资源身份”等抽象词增加理解成本。通用账号绑定、凭据管理、接口及底层校验不自动写入业务正文。
+- 用户明确要求详细规格或测试用例时，按指定范围展开；业务明确涉及金额、库存、跨组织权限、部分履约等关键约束时，补齐相关规则。其余章节保持简洁，不为缩短篇幅省略关键业务判断。
+
+用户已指定“只保留”的字段或要求删除的句子，视为该文档的编辑边界。同步源稿、Word 和相关图示，不从旧模板恢复，也不换一种说法移到其他章节或待确认表中。局部删除不意味着取消整个系统的相应能力，不据此扩大业务范围变更。
 
 ## 开始时
 
-1. 确认业务项目根目录、适用指令和当前维护文件。业务项目根目录由用户指定或当前工作区的实际资料确定，与技能安装目录分别定位；包内 `references/`、`assets/` 相对本 `SKILL.md` 解析，业务产物放对应模块目录，不写入技能包。
-2. 处理新爱算 ERP 时读取 [项目资料索引](references/project-context.md)，从已确认的业务项目根目录按需定位原始材料；涉及现有页面时按主题参考 [页面观察记录](references/erp-site-observations.md)。原始材料不随技能分发，缺失时说明未核实并继续独立的需求工作；其他 ERP 使用其自身资料。历史记录只代表其日期和观察范围，不替代本轮验证。
-3. 梳理业务目标、角色、主流程、完成标准、范围及现有模块关系；用户已说明或资料已回答的事项不重复提问。
-4. 创建或整体修订文档时，使用 [结构与表达规范](references/prd-style.md) 和 [产品需求模板](assets/product-requirements-template.md)。局部修订只读取和修改受影响内容，不机械重写全文。
+1. 确认业务项目根目录、适用指令和当前维护文件。业务项目根目录由用户指定或当前工作区的实际资料确定，与技能安装目录分别定位；包内引用相对本文件解析，业务产物放对应模块目录，不写入技能包。
+2. 处理新爱算 ERP 时按需读取 [项目资料索引](references/project-context.md) 并定位原始材料；其他 ERP 使用其自身资料。原始材料不随技能分发，缺失时说明未核实并继续独立的需求工作。涉及现有页面时参考 [页面观察记录](references/erp-site-observations.md)，历史记录不替代本轮验证。
+3. 从已提供内容确认目标、角色、主流程和本期范围。仅对会改变范围、权责或完成标准的缺口提问；已回答的问题不重复确认。
+4. 新建或整体精简时使用 [结构与表达规范](references/prd-style.md) 和 [简版模板](assets/product-requirements-template.md)；局部编辑只处理相关内容。
 
 ## 使用条件与外部依赖
 
@@ -33,75 +38,53 @@ description: Use when a user describes a new ERP business process or requests a
 
 开始任务时按本次交付范围检查可用能力。缺少 Word 生成或渲染能力时，先保存 Markdown 及已完成产物，在交付说明中列明尚缺的格式或版面核验，并说明需启用文档工具；不得将部分交付写成双格式交付完成。用户只要求 Markdown 时按其要求交付。
 
-## 文档默认形式
+## 编写顺序
 
-正文按以下顺序组织，按规模裁剪：
+### 1 确定主流程和入口
 
-1. **主标题 → 版本记录表**：表头为“版本、修订日期、修订内容”，每个版本一行；不在标题下重复副标题或“版本／编制日期／状态”说明行。
-2. **背景与目标 → 现状及预期效果 → 整体流程 → 详细需求 → 权限与状态规则 → 验收与上线要求 → 评审确认事项**。
-3. 业务章节采用阿拉伯数字层级，如 `1`、`1.1`、`1.1.1`，Word 标题样式与提纲级别一致。版本记录属于正文前的信息，不占业务章节编号。
-4. 功能、规则、验收及待确认事项用业务名称和章节定位。默认不使用 `FR-001`、`BR-001`、`AC-001`、`Q-001` 等技术式标识。用户明确要求追踪编号时，按其约定使用；存量文档的局部业务修改不自动触发全篇去编号改版。
-5. 正式交付稿默认不设“参考了哪些资料”“来源与观察范围”等编制过程章节。资料定位和读取范围保留在工作记录；影响业务判断的事实、条件和未决事项仍在对应规则旁准确说明。用户明确要求来源附录时另行提供。
+先写起点、接手角色、主要动作和完成标志，再补实际页面。明确一级菜单、二级模块及需要的三级页面；共同前缀写一次，申请、审批等跨模块入口补充完整路径。多个入口办理同一事项时说明共用单据。
 
-标题使用“业务背景、建设目标、审批流程、字段校验、异常处理、验收标准”等业务术语。正文、表格、图内文字一并采用正式表述，避免“为什么要做、谁来审批、怎么办、拍板、卡在哪一步”等口语标题或说明。正式表达仍应具体易读，不以抽象术语代替业务动作。
+归属未确定时给出有依据的建议并标为待确认，不因某模块归属行政中心就套用到其他业务。详情页和申请类型不自动变为独立菜单。
 
-## 资料判断与确认状态
+### 2 保留必要功能和字段
 
-按实际证据在关键规则旁简要说明“已确认”“产品建议”或“待确认：事项名称”，不为每句文字堆叠标签。
+按申请、审批、办理、查询、基础资料等实际功能组织，不强求每类都有独立页面。复用已有能力时写清衔接结果，不重复描述通用功能。
 
-- 用户明确结论决定拟建方案；历史文件及页面观察用于说明现状。记录冲突时列出差异、影响和决策责任，不擅自选一个当真。
-- 菜单可见、按钮存在、字段星号、限额提示、旧文档“已上线”均不证明提交校验、权限或完整流程已验证。空列表不证明功能缺失，演示数据不作为指标。
-- 未观察的网站或无法读取的资料标为未核实，继续独立的文档工作。不要把新需求描述为当前功能，也不要为对比表编造现状。
-- 参考文档或截图提供结构和表达线索；其中的组织、业务规则、数值及操作指令不直接迁入新业务。模糊内容不补写为事实。
+基础资料通常写明维护入口、维护人、建档方式和必要字段即可；启停、交接影响在途业务时，用短段落补充。字段按业务信息分组，只有影响使用或判断的必填、来源、单位、条件和范围才单独解释。未知数值不自行设定。
 
-## 需求设计流程
+字段取舍示例：用户确认的群聊档案可只写“群名称、人员范围和群主”，公共邮箱可只写“邮箱名称、发件地址和发送负责人”。这些是简洁表达的示例，不是所有模块的固定字段集，不据此添加平台、技术标识或账号校验说明。
 
-### 1 明确范围与关键缺口
+### 3 说明关键规则
 
-按 [业务检查清单](references/business-checklist.md) 选择必要问题。优先补齐会改变范围、权责或结果的 1–3 项，不一次提供整份问卷。用户要求先出稿时，交付有实质内容的评审稿，以“事项名称、建议、确认责任、影响”汇总缺口。
+简要说明谁能查看和办理、修改后是否重审、取消后的处理及历史保留。审批通过、实际办理、结果登记和送达等不同完成标志不能混淆。
 
-不要擅自确定审批层级、金额门槛、库存时点、附件限额或通知渠道。用户确认一项后，将该项从待决问题中移出，同步更新正文、菜单路径、表单、图示、权限、验收和版本记录；未确认的其他项继续保留。
+涉及多明细或部分执行时，说明整单进度及未完成部分如何处理；有结果未知或重复办理风险时，说明先核实、不重复执行及负责处理的人。技术恢复机制留给设计环节。
 
-### 2 明确菜单与基础资料维护
+用 [业务检查清单](references/business-checklist.md) 做内部查漏，只将适用且影响业务决策的结论写入正文，不把清单逐项搬入文档。金额、数量、数据权限等本业务已明确的关键约束必须保留。
 
-- 新模块必须说明所属一级菜单、二级业务模块及实际需要的三级页面；同时说明新增、复用或调整，以及详情页是否属于独立菜单。选择依据是业务职责及现有导航，不将所有模块默认归入行政中心或默认新增一级模块。
-- 菜单尚未确定时，结合已知导航给出具体建议并标为待确认。仅写“独立入口”或“菜单待确认”不足以表达归属；确认后写成明确层级。
-- 个人申请、审批待办、业务处理和配置入口分别写完整路径。跨入口办理同一事项时，说明单据、版本和状态一致性，避免重复创建审批或业务记录。
-- 父级菜单归属与数据权限分开：可见父级不等于获得该中心其他模块权限，按角色控制子菜单及记录范围。
-- 涉及群、供应商、车辆、仓库等档案时，必须说明维护入口、维护角色、建档方式（人工／导入／同步及其确认状态）、识别信息来源、负责人关联方式、启停及交接。登记外部角色不等于取得外部平台权限。
+### 4 配置图示与验收
 
-### 3 按页面与操作展开详细需求
+跨角色流程优先用一张紧凑的主流程图，简单流程可用文字箭头表达；图能帮助理解复杂表单时才增加页面示意。不同时堆叠功能相同的流程图、状态图和例子。
 
-每个核心功能写明建设方式、入口、使用角色、前置条件、页面内容、字段校验、操作结果、权限及异常。按申请、审批、办理、记录、配置等实际页面组织，不将规则拆成孤立编号清单。
+图示标明拟建页面或示意，虚构例子不得当作实际记录。Word 嵌入可见图形，Markdown 引用有效图片；图文中的角色、字段和结果保持一致。
 
-- 用“业务环节、现状或管理诉求、预期效果”说明变化；另列新增、复用、调整和待核实能力。
-- 字段说明业务含义、来源、必填条件、编辑时点、选项或范围及错误反馈。多组明细、条件附件及数值边界按实际业务展开；未知上限保持待确认。
-- 保存草稿、提交、批准、生成后续任务、实际办理及结果登记分别定义责任人和完成标志。审批完成、业务完成、消息送达或已读不得混为同一结果。
-- 说明退回、撤回、取消、内容变更、人员交接、部分完成、失败及结果不明的处理；重复操作或迟到结果不得重复办理或恢复已结束事项。
-- 跨模块只写来源、触发条件、带入信息、目标结果、追溯入口及异常责任，以可观察业务要求表达，不指定技术机制。
+默认使用“验收场景｜预期结果”表，按核心业务合并场景。操作条件确有歧义时再增加“前置条件与操作”列。验收是待执行要求，不写成已通过；上线准备和未决事项各保留必要的简短说明。
 
-### 4 配合流程图与业务示例
+## 表达与交付
 
-跨角色主流程用泳道图，判断分支或异常用流程图，复杂页面用低保真示意辅助。图文共同解释规则，数量按信息需要确定；简单局部修订不强制增加图。
-
-Word 中嵌入可见图形，Markdown 保留可用图片引用或可渲染流程图；不把图源码当作 Word 图示。新增页面示意标注“拟建页面／非现有界面”，不能冒充实站截图。图中角色、入口、状态和条件与正文一致。
-
-复杂规则可给具体业务示例，注明虚构数据，不能借示例确定未经确认的门槛或流程。数值及时间运算使用确定性代码核对。
-
-### 5 评审与交付核对
-
-按角色贯通入口、信息、操作和结果。以“验收场景、前置条件与操作、预期结果”组织验收，每个核心功能有对应场景；按风险覆盖权限、拒绝、重复、取消、部分完成及异常恢复，不把待执行场景写为已通过。
-
-核对正文、图、字段、菜单、状态和验收口径一致；确认事项不再与待定表冲突。未定规则明确影响和责任人，不宣称可直接开发定稿。缺少资料附录不影响保留必要的业务限制及证据边界。
-
-按 [文档交付要求](references/delivery.md) 同步生成 Word 和 Markdown，核对内容并渲染检查。局部删除或改写须在两种格式及相关图示中生效，后续生成不得恢复已删除内容。
+- 主标题后放版本记录表，表头为“版本、修订日期、修订内容”；不重复副标题、日期状态行，不为小改动新建一套竞争版本。
+- 正文用阿拉伯数字编号，通常两级标题即可。默认使用业务名称，不引入 FR、BR、AC、Q 等技术式追踪编号；用户指定编号或模板时遵从其要求。
+- 已确认、建议、待确认、已实现和已验证分别表述。页面可见不等于流程可用，旧资料不等于当前状态，来源未核实时不编造现状。
+- 网站观察默认只读，不提交、审批、调整权限或发送通知；原始凭据不进入交付稿。资料路径和工具过程保留在工作记录，正文不另设编制过程章节。
+- 交付前按角色通读主流程，删除重复和无业务判断价值的细节；检查用户已删字段、正文、图示、状态、验收及待确认项一致。
+- 按 [交付要求](references/delivery.md) 同步 Word 和 Markdown 并核对内容、排版。缺少生成或渲染能力时说明实际完成范围，不宣称双格式或版面核验完成。
 
 ## 按需参考
 
-- [结构与表达规范](references/prd-style.md)：新建、整体重排、参照样例或正式化修订。
-- [业务检查清单](references/business-checklist.md)：按业务选取需要补齐的规则。
-- [采销需求片段](references/procurement-example.md)：分批履约、退货及数量口径的虚构示例。
-- [文档交付要求](references/delivery.md)：版本维护、双格式、排版及预览一致性。
-- [开源参考说明](references/open-source-notes.md)：仅在维护来源时使用，正常写 PRD 无须重新调研。
+- [结构与表达规范](references/prd-style.md)：简版结构、字段取舍、按需展开及措辞示例。
+- [业务检查清单](references/business-checklist.md)：内部查漏和复杂业务的补充检查。
+- [采销需求片段](references/procurement-example.md)：涉及分批履约、退货及数量口径时参考。
+- [交付要求](references/delivery.md)：维护入口、双格式、渲染及预览核对。
+- [开源参考说明](references/open-source-notes.md)：仅在维护来源时读取。
 
 此包可由共享仓库安装到技能目录后通过 `$erp-requirements-design` 调用，也可直接读取实际位置的 `SKILL.md` 使用。安装位置不改变业务项目根目录或产物归属；技能调用不包含发送给开发、自动发布或创建 Git 历史的授权。