docs: simplify ERP requirements design skill

README.md

@@ -15,7 +15,7 @@
 | 名称 | 用途 | 额外依赖 |
 | --- | --- | --- |
 | [xas-skill-review](skills/xas-skill-review/SKILL.md) | 检查待共享技能的元数据、引用文件、路径可移植性和依赖说明，给出位置、证据与修改建议 | 无 |
-| [erp-requirements-design](skills/erp-requirements-design/SKILL.md) | 将 ERP 业务诉求整理为产品需求文档，覆盖流程、页面、字段、权限、状态和验收，默认交付 Word 与 Markdown | Markdown 无额外依赖；Word 需文档生成与渲染工具，现有页面核对需已授权的浏览器环境；详见技能入口 |
+| [erp-requirements-design](skills/erp-requirements-design/SKILL.md) | 默认编写简洁的 ERP 产品需求文档，保留核心流程、必要字段及关键业务规则，按需展开，同步交付 Word 与 Markdown | Markdown 无额外依赖；Word 需文档生成与渲染工具，现有页面核对需已授权的浏览器环境；详见技能入口 |
 
 `skills/` 只包含正式技能；`templates/` 用于创建新技能，不会出现在安装清单中。
 

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 历史的授权。

skills/erp-requirements-design/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "ERP 产品需求设计"
-  short_description: "将业务流程整理为面向开发评审的产品需求文档，交付 Word 与 Markdown"
-  default_prompt: "请使用 $erp-requirements-design，根据我描述的业务流程编写 ERP 产品需求文档，补齐关键业务问题并生成 Word 与 Markdown，技术方案由开发另行设计。"
+  short_description: "编写简洁的 ERP 业务需求，保留核心流程和关键规则，同步 Word 与 Markdown"
+  default_prompt: "请使用 $erp-requirements-design，根据我描述的业务流程编写简洁的 ERP 产品需求文档，保留必要字段、角色职责和关键规则，同步生成 Word 与 Markdown。"

skills/erp-requirements-design/assets/product-requirements-template.md

@@ -4,169 +4,58 @@
 
 | 版本 | 修订日期 | 修订内容 |
 |---|---|---|
-| {{实际版本}} | {{用户时区日期}} | {{本版本实际新增、调整和确认内容}} |
+| {{实际版本}} | {{用户时区日期}} | {{本版本实际调整内容}} |
 
-<!-- 维护用模板：生成时替换占位符并删除提示，按业务规模裁剪，不保留空节。主标题后直接进入版本表，不添加重复副标题、版本日期状态行。每个版本一行。 -->
+<!-- 简版模板：替换占位符并删除提示。按业务裁剪，无内容的章节省略；不强制页数、字段数或验收数量。用户已删内容不恢复。 -->
 
 ## 1 背景与目标
 
-### 1.1 业务背景
+用简短段落说明业务问题、目标和本期范围。无需分别铺开背景、目标、现状对比和建设清单。
 
-说明背景、问题及需求起点，区分已确认事实与尚未核实的现状。采用正式业务表述，不写编制过程。
+## 2 整体流程
 
-### 1.2 建设目标
+写出“发起 → 审批 → 办理 → 结果”的实际流程及负责角色，按业务调整。跨角色衔接可配一张紧凑主流程图，不重复堆叠同义图示。
 
-说明期望改变的结果及完成标准。未确认的量化指标不自行设定；需要说明待评审状态时放在必要的业务说明中，不在标题下重复设状态行。
+## 3 功能需求
 
-### 1.3 需求范围
+### 3.1 菜单与入口
 
-| 范围 | 本期要求 |
+明确“一级菜单 → 二级模块”，再列实际三级页面。跨模块申请、审批等入口补充完整路径；同一事项共用单据。
+
+| 页面 | 使用人员与主要功能 |
 |---|---|
-| 本期必备能力 | 根据实际业务填写 |
-| 后续评估范围 | 仅列实际存在的后续需求 |
-| 本期不纳入 | 明确容易混淆的边界 |
 
-说明已确认或建议的模块归属和关键依赖。未知决策以事项名称标明，纳入文末评审表。
+### 3.2 基础资料
 
-## 2 现状及预期效果
+有基础资料维护需求时，写维护入口、维护人、建档方式和必要字段；少量字段直接用一句话列出。没有则删除本节，不自动添加系统标识、账号绑定等说明。
 
-| 业务环节 | 当前方式或已明确的管理诉求 | 本期预期效果 |
-|---|---|---|
+### 3.3 核心业务功能
 
-现状未核实时采用管理诉求对照，不编造现行流程或已验证缺陷。
+按实际功能名称调整标题，按需增加同级节。每节说明使用角色、主要操作和结果，影响办理的条件写在对应内容旁。
 
-### 2.1 功能建设清单
+| 信息 | 填写要求 |
+|---|---|
 
-| 功能 | 新增 复用 调整或待核实 | 本期变化 |
-|---|---|---|
+相关字段按业务信息分组；只解释影响业务判断的必填、来源、单位和条件。申请、审批、办理、结果查询按实际范围编写，不强制每类都单独成节。
 
-用业务名称定位功能，不默认增加技术式编号。
+## 4 权限与办理规则
 
-## 3 整体流程
+简要说明查看及操作范围、修改重审、取消和异常处理。涉及多明细时说明整单进度；审批通过、实际办理及登记结果分别表达。同一规则只写一次。
 
-### 3.1 主流程
+已明确涉及金额、库存、部分履约或数据隔离时，保留相关关键规则。其余通用技术细节交由开发设计。
 
-说明起点、角色、关键动作和完成标志。跨角色流程使用可见泳道图；判断分支标明条件，图后保留简短文字。建议规则与正文保持一致。
+## 5 验收与上线
 
-### 3.2 分支与业务示例
+以下为待执行的验收要求。
 
-按实际风险说明退回、取消、部分完成及异常恢复。复杂规则可用示例表，注明虚构数据，不作为业务默认值。
+| 验收场景 | 预期结果 |
+|---|---|
 
-| 场景 | 输入或操作 | 预期处理 |
-|---|---|---|
+按核心业务合并场景，不逐项重述正文。条件会改变结果时再增加前置条件列；上线只写本模块需要的准备与衔接。
 
-## 4 详细需求
+## 6 评审确认事项
 
-### 4.1 菜单与页面入口
+| 事项 | 待确认内容与责任人 |
+|---|---|
 
-#### 4.1.1 菜单归属及层级
-
-明确归属现有一级菜单还是新增一级模块，给出依据及确认状态。不得只写“独立入口”。
-
-| 一级菜单 | 二级模块 | 三级菜单或页面 | 使用角色 |
-|---|---|---|---|
-
-说明与既有功能的关系，分别标识详情页、申请类型及导航菜单；父级菜单可见不等于获得其余模块权限。
-
-#### 4.1.2 跨模块入口衔接
-
-分别写申请、审批待办、办理、查询及配置的完整路径。同一事项有多个入口时，说明单据、版本及状态一致性。
-
-#### 4.1.3 页面功能与交互
-
-| 页面 | 默认信息与筛选 | 主要操作及权限范围 |
-|---|---|---|
-
-覆盖加载、空状态、失败、重试、结果不明、重复操作及筛选恢复；明确 PC 与移动端范围。
-
-### 4.2 基础资料维护
-
-适用于业务依赖档案或配置的情况；无独立维护需求时并入对应功能，不保留空节。
-
-**建设方式**：新增、复用或调整；人工建档、导入或同步及其确认状态。
-
-**入口与角色**：完整维护路径、维护权限及负责岗位。
-
-| 资料字段 | 来源及关联方式 | 校验与维护规则 |
-|---|---|---|
-
-明确识别信息、负责人及账号关联、启用条件、停用与交接、在途事项及历史记录影响。外部资格需单独核对，登记资料不自动授予外部权限。
-
-### 4.3 核心业务页面
-
-将本节替换为实际功能名，如“供应商准入申请”。其他核心页面依次续写，不照搬不存在的功能。
-
-#### 4.3.1 页面与操作
-
-说明建设方式、完整入口、使用角色及前置条件。复杂页面配拟建示意或已核实截图，注明其性质及适用范围。
-
-| 操作 | 前置条件 | 处理结果及异常反馈 |
-|---|---|---|
-
-#### 4.3.2 字段与校验
-
-| 字段 | 来源与必填条件 | 编辑时点 格式范围及错误反馈 |
-|---|---|---|
-
-说明条件必填、选项来源、附件权限和限额依据。多组明细、条件附件需明确逐组规则、增删影响、门槛边界及缺失反馈；未知数值列为具名待确认事项。
-
-#### 4.3.3 变更与异常处理
-
-说明提交后修改、重审、撤回、取消、人员变更、重复处理、部分完成及结果不明的条件和后续路径，仅保留适用分支。
-
-### 4.4 现有模块衔接与通知
-
-| 来源模块 | 触发条件及带入信息 | 目标结果 追溯入口及异常责任 |
-|---|---|---|
-
-审批通过、产生后续任务、实际办理、消息送达和已读分别表达；重复或迟到结果不得重复办理或恢复已结束事项。
-
-| 通知事件 | 接收角色与渠道 | 内容 时机及跳转入口 |
-|---|---|---|
-
-说明提醒失败与业务失败的区别，以及重复提醒和人工恢复规则；不自行确定未确认的渠道或定时规则。
-
-### 4.5 查询统计与操作记录
-
-| 指标或记录 | 业务口径与时间 | 可见范围及缺失值处理 |
-|---|---|---|
-
-明确操作记录、关联单号、办理人及时间、历史变更、纠错和保留期限。数值用确定性计算核对，不以零代替缺失，不指定日志框架或数据表。
-
-## 5 权限与状态规则
-
-### 5.1 角色权限
-
-| 角色 | 可见范围 | 允许操作 | 权限限制 |
-|---|---|---|---|
-
-覆盖菜单、操作、记录、字段及附件权限；说明本人审批、兼任角色、停用及交接，服务端及直接访问遵守相同边界。
-
-### 5.2 状态与关键规则
-
-采用状态图、简洁文字或必要的状态表，避免重复叙述。
-
-| 当前状态 | 操作及角色 | 条件与下一状态 | 关联影响及恢复限制 |
-|---|---|---|---|
-
-区分草稿、提交、审批、建单和实际办理的完成标志；有明细时说明总单汇总规则。金额、数量、时区及舍入按实际业务展开。
-
-## 6 验收与上线要求
-
-### 6.1 验收场景
-
-| 验收场景 | 前置条件与操作 | 预期结果 |
-|---|---|---|
-
-采用业务场景名称，覆盖核心功能和适用的权限、拒绝、边界、重复、取消、部分完成、异常恢复及跨入口一致性。此处为待执行标准，不填写“已通过”。
-
-### 6.2 上线衔接
-
-说明责任人、资料准备、外部权限核对、真实角色验收、存量与在途事项、切换及故障期间处理。产品评审、业务验收及部署结果分别记录。
-
-## 7 评审确认事项
-
-| 确认事项 | 建议方案及理由 | 确认责任及业务影响 |
-|---|---|---|
-
-仅保留未决事项。已确认内容写回对应章节，同步菜单、图、字段、权限、验收和版本记录，不得一处已确认而另一处仍待定。
+仅保留影响定稿的未决问题。已确认事项写回正文，用户已删的字段或细节不以待确认方式恢复；没有未决事项时省略本节。

skills/erp-requirements-design/references/business-checklist.md

@@ -1,104 +1,68 @@
 # 业务访谈与产品检查清单
 
-按业务选择使用；这是分析辅助，不是一次性发给用户的问卷。流程已清楚时直接写稿，未知项放回受影响的需求处。
+本文件用于内部查漏，不是文档目录、必写清单或一次发给用户的问卷。先用已有资料贯通主流程，只对影响范围、权责或完成标准的缺口提问；已明确的内容直接写稿。
 
-## 从一句话提炼可讨论的业务
+## 所有业务先检查
 
-优先明确业务背景、目标、使用角色、触发条件、完成标准和本期边界。用户提供流程时沿着“输入 → 处理 → 输出 → 下一位处理人”补齐断点，不先讨论技术。
+| 关注点 | 需要明确的业务结论 |
+|---|---|
+| 目标与范围 | 解决什么问题，本期做到哪一步，哪些事项未纳入 |
+| 角色与入口 | 谁申请、审批、办理和管理，各从哪里进入 |
+| 必要信息 | 办理必须填写什么、哪些可从已有资料带出 |
+| 完成标准 | 审批、实际办理和登记分别何时完成 |
+| 权限与变更 | 谁能查看及处理，修改或取消如何影响已办理事项 |
+| 验收与未决 | 核心结果如何检查，哪些问题确需业务确认 |
 
-例：“销售填单，采购处理，仓库收发货。”先区分现货销售与销售带动采购，问是否需要独立备货。不要直接假设每张销售单必然生成一张采购单。
+检查不等于全部展开。一个明确的短句可以承载结论，无需将每项再拆成字段、状态、权限和异常表。
 
-每个重要缺口按业务名称记录：`确认事项 / 业务影响 / 可选方案或建议 / 决策角色 / 相关功能或章节 / 是否影响定稿`。建议不是默认批准；用户不回答时保留待确认。确认后同步正文、菜单、图示、权限、验收及版本表，不继续在待决表中保留该项。
+## 页面与基础资料
 
-## 角色与权限
+确认菜单所属中心、模块和实际页面；共同父级路径集中写一次，跨模块入口单独补充。不同入口处理同一事项时，说明共用单据。菜单归属不能直接套用其他模块。
 
-- 业务操作者、审核人、管理人、只读查看人分别是谁；组织/岗位变化后如何交接未完成事项。
-- 能否看本人、本部门、负责范围或全部记录；能否查看金额、成本、利润、附件、导出结果。
-- 可见不等于可编辑，可编辑不等于可审批。本人能否审批本人单据、离职人员待办怎么处理，按需要确认。
-- 产品写可验证的权限结果，如“销售不能通过列表、详情、导出或直接访问查看其他销售的订单”；具体实现由开发设计。
+基础档案通常只需维护入口、维护人、建档方式及业务必要字段。用户已确定字段清单时按清单执行，不从通用检查项自动补入平台、系统标识、账号绑定、用途或凭据管理。
 
-## 流程与状态
-
-- 起点、提交条件、接手角色、完成标准和最后一个业务动作。
-- 草稿、待处理、进行中、部分完成、完成、关闭等状态按实际需要采用，不强套统一名称。
-- 审批中允许改哪些内容；退回、驳回、撤回是否不同；修改后是否重审，原记录如何查看。
-- 一单多明细时，部分完成、部分退回、部分关闭如何显示总单状态和剩余工作。
-- 作废、删除、关闭、归档各自代表什么；发生后能否恢复、谁能看历史、关联单据怎么处理。
-- 超时、无人接单、人员停用、处理中断后的责任人和下一步入口。
-- 保存草稿、提交申请、提交业务单据、完成实际办理各自意味着什么；哪些字段允许草稿暂缺、提交前必须补全，用户从哪里继续未完成事项。
-
-## 页面与字段
-
-- 写清一级菜单、二级模块及实际需要的三级页面，区分导航菜单、详情页和申请类型；明确新增、复用或调整。不能仅写“独立入口”。
-- 未确定菜单时依据业务职责和现有导航提出具体建议，标明待确认。确认后给出完整路径；不因内部群管理属于行政中心而将其他模块一律归入行政中心。
-- 申请、审批、办理、查询和基础资料维护分别从哪里进入；多个入口如何关联同一单据、版本和状态；PC 与移动端分别覆盖哪些任务。
-- 父级菜单可见性不应扩大该中心其他功能的权限，子菜单、记录、字段及附件范围分别控制。
-- 基础档案的维护入口、维护角色、建档方式、标识来源、负责人及系统账号关联是否明确；变更、停用、交接与历史记录如何处理。外部角色登记不自动授予平台资格。
-- 接入已有页面时分别记录当前入口、页面标题和拟使用的产品名称。旧菜单规划与实站不一致、标签疑似复制错误时先列差异，不直接照搬。
-- 列表默认视图、筛选、排序、分页、关键列、进度、待办提示；筛选清空后应恢复什么。
-- 新建、编辑、详情、审批、处理、历史记录页之间的关系。
-- 字段含义、来源、选项、单位、是否必填、条件必填、带出/填写、编辑时点、合法范围及错误文案。
-- 查询无结果、无权限、加载失败、处理中、成功、结果不明分别怎么显示；重复点击后的业务结果。
-- 导入、导出、打印、附件只在本期需要时展开。说明导入预览、错误行、重复判断、部分成功是否允许和结果反馈，不设计文件服务实现。
-- 多组明细：每组对应什么对象，允许多少组，逐组必填与整单必填的区别，增删明细如何影响合计、附件和审批条件。
-- 条件附件：何种单价/总额/类型触发，等于门槛如何处理，每组还是整单上传，文件数量和大小、缺失提示、金额修改后是否重新判断。现有行政采购页面的门槛只是该流程的观察值，不自动套给采销。
-- 星号、限额提示、空列表和演示数据分别标注观察层级；没有实际操作验证时，不写成校验已通过或业务已完成。
+列表保留业务需要的查询、进度及操作，通用排序、分页、加载提示和每个错误文案不用逐项写。只有用户提出专项交互要求，或这些行为直接影响办理判断时再展开。
 
 ## 审批与通知
 
-- 哪些单据需要审批、触发条件、节点顺序、审批人来源、多人如何算通过、抄送与通知区别。
-- 无可用审批人时如何提示和处理；人员名单变更对在途单据是否生效。
-- 申请表预览的审批节点、通过方式和抄送信息如何展示；业务要求优先使用岗位/组的职责表述，当前测试账号姓名不作为长期审批规则。
-- 申请人在哪看进度，审批人在哪接待办，办理人从哪里接后续工作；“我发起的、我的待办、我的已办、抄送我的”和全局管理视角按业务分别说明，不仅列一个总菜单。
-- 审批通过后是否生成待办/业务单据，谁继续办理；审批通过不等于业务执行完毕。
-- 相同审批结果被重复处理时，业务单据和待办不应重复；联动失败时显示待处理/异常、由谁核对并恢复。这里只定义用户可观察的结果。
-- 通知渠道、触发事件、接收角色、简要内容、跳转目标、重复或失败时是否重发；不能把“已提交”写成“已通知到所有人”。
+涉及审批时检查申请人、有效审批人、通过后的接手人和完成标志；退回、撤回及批准后修改按实际流程简述。审批层级、金额门槛和多人通过规则未确认时保留待定，不从示例推断。
 
-## 跨模块接入
+涉及通知时写明何时提醒、提醒谁、通过什么渠道、进入何处办理。提醒成功和业务完成分开表达；失败处理合并为业务原则，不扩写发送机制与重试时序。
 
-每项联动写六件事：来源模块和单据、触发业务动作、带入的业务信息、目标单据或待办、双方可追溯入口、失败时的状态和责任人。
+## 按业务条件追加检查
 
-确定已有数据从哪里来、谁维护、修改是否影响历史记录；需要保留成交时名称/价格等历史信息时，用业务语义说明，不指定数据存储结构。
+以下只检查本期实际涉及的部分。结果写回对应功能，不新建一套“完整性附录”。
 
-分清“计划生成入库单”“仓库确认收货”“库存已增加”三个结果。若上游可修改或取消，说明下游尚未办理、部分办理、全部办理三种情况下怎么办。
+| 业务条件 | 必须保留的判断 |
+|---|---|
+| 多明细或部分办理 | 明细粒度、整单进度、剩余工作；部分完成不能显示全部完成 |
+| 已执行后变更或取消 | 保留已发生事实，明确未办理部分及后续补充、重审方式 |
+| 外部执行结果未知 | 先核实再处理，不把未知当失败而直接重复执行；明确跟进人 |
+| 跨部门或组织权限 | 查看和办理范围、敏感字段的必要隔离，不能只靠菜单名称表达 |
+| 跨模块联动 | 来源、触发动作、目标结果及可追溯关系；失败由谁核对，避免重复业务单据 |
+| 金额和数量 | 单位、币种、精度、合计及上下界；关键口径和舍入规则不得为简洁而省略 |
+| 条件附件或门槛 | 触发条件、等于门槛如何处理及修改后的影响；未知上限待确认 |
+| 存量或在途记录 | 历史与新流程如何衔接，避免覆盖事实或重复办理 |
 
-来源单号、目标单号、经办人、审批完成/建单/办理时间分别代表哪个阶段；关联信息为空时显示什么、是否仍允许继续、谁核对补齐。看见已完成状态但关联单号为空，只能记为该记录现象，不能推断关联不需要或功能必然异常。
-
-## 数量与金额
-
-只对涉及它们的业务展开：
-
-- 数量单位、可否小数、最小/最大值、换算、是否允许超量、数量分配到单据或明细的口径。
-- 币种、含税/未税、折扣、运费、税额、金额汇总与舍入位置；客户和供应商价格是否分别管理。
-- 已执行、已退、剩余、可用、占用等名称逐一定义，不能把净数量当累计履约数量。
-- 规则未确认时以具名待确认事项保留；不要把其他系统的税率、审批金额门槛、精度或负库存策略带入本项目。
-- 有示例时标注虚构测试数据，并使用明确公式复核结果；公式和示例必须同一口径。
+金额、人数、容量和时限没有依据时不虚构数值。缺少页面或操作证据时标为未核实，不把标签、星号、空列表当作行为验证。
 
 ## 采销业务追加检查
 
-先确认业务模式：现货销售、以销定采、独立备货、代采中的哪些属于本期。
+先确认现货销售、以销定采、独立备货、代采中的哪些属于本期，不因系统名为 ERP 自动加入合同、收付款、发票和财务。
 
-再按已选范围检查：
+涉及分批履约、退货或库存时，再核对：
 
-- 销售与采购是否一对一、多对多；拆单、合单、分仓、分批及未分配数量。
-- 云库分类/品牌/系列/SKU、行政资产分类与实物唯一码分别是什么；新业务选择现有 SKU 还是允许自由填写，历史商品信息如何保留。
-- 有唯一码的商品是否逐件登记，码与数量怎样对应，重复、缺码、错码、换货怎么处理，退货如何核对原件；无唯一码商品按数量还是批次管理。页面有“是否有唯一码”并不证明这些环节已实现。
-- 库存出库现有“销售、寄出、借出”是否与本期场景相关；不同用途是否需要返回、结算或不同责任人，不把所有出库都当销售完成。
-- 库存是否预留、何时预留/释放；无货、可用量不足、多个订单同时申请同一批货时的用户结果。
-- 订单审核、收发货计划、实际收发货各自时点；入出库单生成是否需要人工确认。
-- 部分到货、少货、多货、错货、不良品、剩余取消；历史手工入出库单是否与新单关联，防止重复处理。
-- 客户退货与供应商退货分别关联哪笔原收发货，数量上限和质检/可用状态，是否补发补采。
-- 退货对库存、订单进度和结算的影响分别说明；不要默认退货自动恢复订单未交数量。
-- 合同、付款、收款、发票、物流和财务是否在本期；不因系统叫 ERP 自动纳入全部范围。
+- 销售、采购与收发货的关联关系，分批数量、已执行与剩余口径。
+- 商品来源、单位及有无实物唯一码；实际收发货时点和库存变动时点。
+- 部分到货、剩余取消、客户或供应商退货的责任及数量边界。
+- 退货对库存、进度和结算的影响，是否补发或补采，不默认恢复原单未交数量。
+
+需要例子时参考 [采销需求片段](procurement-example.md)，不把示例规则或数字直接套为本项目要求。
 
 ## 验收与评审
 
-用“验收场景 / 前置条件与操作 / 预期结果”组织验收，按业务名称或章节关联功能，不默认使用技术式编号，不用“正常”“准确”“友好”代替具体结果。
+默认按核心业务合并为“验收场景｜预期结果”，用具体结果代替“正常、准确、友好”。需要前置条件才能判断结果时再补条件；用户要求测试用例时另行展开边界组合。
 
-按风险覆盖主流程、权限拒绝、字段边界、退回修改、取消、部分完成、重复处理、关联失败和存量衔接；不适用的项说明原因即可。
+只记录影响业务定稿的未决事项及责任人，不把被用户删去的字段或通用技术参数重新列为待确认。已确认内容写回正文并移出待定表。
 
-若产品采纳条件附件、多组明细或唯一码规则，对应增加门槛下/等于/超过、明细增删后重新判断、缺失/重复唯一码等验收场景。测试数据来自已确认规则，不能靠测试样例暗定未知规则。
-
-性能、容量、文件上限等指标来源必须可追溯。业务未提出数值时，问可接受的等待时间或使用规模，或列为待确认；不自行写 2 秒、50 并发等数字。
-
-交付前核对：业务词汇一致、角色与动作相容、关键规则有验收场景，图与正文同义；待确认项未被写成定论，已确认内容不再被列为待定。产品评审通过与实际开发测试通过分开记录。
+交付前核对主流程、关键权限、已发生事实和进度口径仍然完整，Word、Markdown、图示同步；需求稿的验收要求不表示系统已验收通过。

skills/erp-requirements-design/references/delivery.md

@@ -9,7 +9,7 @@
 3. 持续编辑同一评审稿时保留维护入口。局部措辞、格式和删节一般更新当前版本并保留可恢复备份，不每次小改动都复制一套竞争版本。明确发布新基线、重要业务版本变化或用户要求留新版本时，按版本规则新建并指明最新文件。
 4. 同一版本更新该行修订摘要，不把每次对话视为新版本或生成多行同名版本；未确认决策保持待评审。
 5. Markdown 为维护源稿，Word 为排版版本。定点修改 Word 后同步源稿，核对章节、字段、权限、状态、图示和验收，避免两套内容分歧。
-6. 删除或改写须在两种格式及相关引用中生效。后续生成基于最新源稿，不恢复已删除的资料说明、旧标题或元数据。
+6. 删除或改写须在两种格式及相关引用中生效。后续生成基于最新源稿，不恢复用户已删的字段、句子、资料说明、旧标题或元数据，也不将其移到其他章节、图示、验收或待确认表中。
 
 ## Word 与图表制作
 
@@ -30,10 +30,11 @@
 - 已确认菜单是否仍在待确认表内，图中是否存在旧路径。
 - 删除技术式编号后，功能和验收覆盖是否仍然保留。
 - 文首是否仍有重复副标题或版本日期状态行，版本表是否一版本一行。
-- 已删除资料说明或旧标题是否被旧脚本、模板及副本恢复。
+- 用户已删的字段、句子及旧标题是否被模板、脚本、图示或副本恢复。
+- 同一规则是否重复展开，字段和验收是否可合并；必要的业务约束及完成标志是否仍然明确。
 - 业务完成、人工登记及系统回执是否区分，虚构示例是否被误作证据。
 
-版面核对需生成渲染页，检查字体、表格、图片、跨页表头、标题衔接、页码、空白与溢出。新文档及整体重排逐页检查；局部修改检查受影响页。文件能打开不等于版面已核验。
+版面核对需生成渲染页，检查字体、表格、图片、跨页表头、标题衔接、页码、空白与溢出。新文档及整体重排逐页检查；局部修改检查受影响页。文件能打开不等于版面已核验。精简优先合并内容和图示、优化分页，不靠缩小字号挤成固定页数。
 
 ## 预览与保存内容不一致
 

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. 识别信息、负责人和系统账号如何关联，变更、停用及历史记录如何处理。
-
-内部群管理归属行政中心是该模块的已确认决策，不是其他业务的默认归属。未决菜单需给出有依据的建议及影响；确认后同步所有引用，移除相应的“归属待确认”表述。
+最后通读：主流程能否贯通，字段是否必要，同一规则是否写了多次，常见异常是否可合并，关键约束和真正未决问题是否仍然清楚。