9.1 KiB
name, description
| name | description |
|---|---|
| erp-requirements-design | Use when a user describes a new ERP business process or requests a product-side requirements document, PRD, module onboarding specification, or revision to an existing ERP requirement. 适用于新爱算 ERP 新业务接入和存量模块需求迭代；不用于技术设计、编码或上线验收报告。 |
ERP 产品需求设计
把业务诉求写成简洁、可评审的产品需求文档。默认中文，Word 与 Markdown 同步维护。让读者看懂“谁从哪里进入、填写什么、如何办理、何时完成”；技术方案由开发另行设计。
默认写简版
- 采用“背景与目标 → 整体流程 → 功能需求 → 权限与办理规则 → 验收与上线 → 评审确认事项”的结构，按实际内容合并或省略章节。
- 每个功能用短段落说明入口、角色、主要操作和结果；字段表只列业务必需的信息及影响办理的填写条件。
- 同一规则集中写一次。主流程讲步骤，功能讲操作，规则讲关键约束，验收讲可观察结果，不在各处复制整套说明。
- 常见异常合并说明处理原则和责任人；用户未要求测试方案时，不把所有状态组合、并发时序、重试过程展开成用例。
- 用业务人员熟悉的词，如“人员范围”，不用“受众”“资源身份”等抽象词增加理解成本。通用账号绑定、凭据管理、接口及底层校验不自动写入业务正文。
- 用户明确要求详细规格或测试用例时，按指定范围展开；业务明确涉及金额、库存、跨组织权限、部分履约等关键约束时，补齐相关规则。其余章节保持简洁，不为缩短篇幅省略关键业务判断。
用户已指定“只保留”的字段或要求删除的句子，视为该文档的编辑边界。同步源稿、Word 和相关图示，不从旧模板恢复，也不换一种说法移到其他章节或待确认表中。局部删除不意味着取消整个系统的相应能力，不据此扩大业务范围变更。
开始时
- 确认业务项目根目录、适用指令和当前维护文件。业务项目根目录由用户指定或当前工作区的实际资料确定，与技能安装目录分别定位；包内引用相对本文件解析，业务产物放对应模块目录，不写入技能包。
- 处理新爱算 ERP 时按需读取 项目资料索引 并定位原始材料；其他 ERP 使用其自身资料。原始材料不随技能分发，缺失时说明未核实并继续独立的需求工作。涉及现有页面时参考 页面观察记录，历史记录不替代本轮验证。
- 从已提供内容确认目标、角色、主流程和本期范围。仅对会改变范围、权责或完成标准的缺口提问；已回答的问题不重复确认。
- 新建或整体精简时使用 结构与表达规范 和 简版模板；局部编辑只处理相关内容。
使用条件与外部依赖
本包提供需求设计流程、参考和模板，不包含一键生成程序；由支持 Skills 的助手结合用户输入执行。安装本包不会自动安装下列工具或复制业务原始资料。
| 任务 | 所需能力及准备方式 |
|---|---|
| 编写 Markdown 需求稿 | 文件读写能力及用户业务输入；无额外脚本运行时依赖 |
| 默认交付 Word 与 Markdown | 在当前环境启用 documents 文档技能及其声明的生成、渲染依赖，按该技能发现工作区运行时；也可使用已有、获准的等效 DOCX 生成与渲染工具。参见 交付要求 |
| 读取 Word、表格或 PDF 原始资料 | 按实际文件格式使用已配置的文档、表格或 PDF 读取工具；未能读取的内容保留未核实状态 |
| 核对 ERP 现有页面（按需） | 用户指定或已确认的目标环境、可用浏览器工具或连接器，以及正常授权的账号或登录会话；历史网址不代表本轮访问授权 |
开始任务时按本次交付范围检查可用能力。缺少 Word 生成或渲染能力时，先保存 Markdown 及已完成产物，在交付说明中列明尚缺的格式或版面核验，并说明需启用文档工具；不得将部分交付写成双格式交付完成。用户只要求 Markdown 时按其要求交付。
编写顺序
1 确定主流程和入口
先写起点、接手角色、主要动作和完成标志，再补实际页面。明确一级菜单、二级模块及需要的三级页面；共同前缀写一次，申请、审批等跨模块入口补充完整路径。多个入口办理同一事项时说明共用单据。
归属未确定时给出有依据的建议并标为待确认，不因某模块归属行政中心就套用到其他业务。详情页和申请类型不自动变为独立菜单。
2 保留必要功能和字段
按申请、审批、办理、查询、基础资料等实际功能组织，不强求每类都有独立页面。复用已有能力时写清衔接结果，不重复描述通用功能。
基础资料通常写明维护入口、维护人、建档方式和必要字段即可；启停、交接影响在途业务时，用短段落补充。字段按业务信息分组，只有影响使用或判断的必填、来源、单位、条件和范围才单独解释。未知数值不自行设定。
字段取舍示例：用户确认的群聊档案可只写“群名称、人员范围和群主”，公共邮箱可只写“邮箱名称、发件地址和发送负责人”。这些是简洁表达的示例，不是所有模块的固定字段集，不据此添加平台、技术标识或账号校验说明。
3 说明关键规则
简要说明谁能查看和办理、修改后是否重审、取消后的处理及历史保留。审批通过、实际办理、结果登记和送达等不同完成标志不能混淆。
涉及多明细或部分执行时，说明整单进度及未完成部分如何处理；有结果未知或重复办理风险时，说明先核实、不重复执行及负责处理的人。技术恢复机制留给设计环节。
用 业务检查清单 做内部查漏，只将适用且影响业务决策的结论写入正文，不把清单逐项搬入文档。金额、数量、数据权限等本业务已明确的关键约束必须保留。
4 配置图示与验收
跨角色流程优先用一张紧凑的主流程图，简单流程可用文字箭头表达；图能帮助理解复杂表单时才增加页面示意。不同时堆叠功能相同的流程图、状态图和例子。
当角色与功能职责需要集中说明时，增加一张用例图，只展示主要角色和核心功能。已有流程图或角色表能够清楚表达时，可省略，避免重复。
图示标明拟建页面或示意，虚构例子不得当作实际记录。Word 嵌入可见图形，Markdown 引用有效图片；图文中的角色、字段和结果保持一致。
默认使用“验收场景｜预期结果”表，按核心业务合并场景。操作条件确有歧义时再增加“前置条件与操作”列。验收是待执行要求，不写成已通过；上线准备和未决事项各保留必要的简短说明。
表达与交付
- 主标题后放版本记录表，表头为“版本、修订日期、修订内容”；不重复副标题、日期状态行，不为小改动新建一套竞争版本。
- 正文用阿拉伯数字编号，通常两级标题即可。默认使用业务名称，不引入 FR、BR、AC、Q 等技术式追踪编号；用户指定编号或模板时遵从其要求。
- 已确认、建议、待确认、已实现和已验证分别表述。页面可见不等于流程可用，旧资料不等于当前状态，来源未核实时不编造现状。
- 网站观察默认只读，不提交、审批、调整权限或发送通知；原始凭据不进入交付稿。资料路径和工具过程保留在工作记录，正文不另设编制过程章节。
- 交付前按角色通读主流程，删除重复和无业务判断价值的细节；检查用户已删字段、正文、图示、状态、验收及待确认项一致。
- 按 交付要求 同步 Word 和 Markdown 并核对内容、排版。缺少生成或渲染能力时说明实际完成范围，不宣称双格式或版面核验完成。
按需参考
- 结构与表达规范：简版结构、字段取舍、按需展开及措辞示例。
- 业务检查清单：内部查漏和复杂业务的补充检查。
- 采销需求片段：涉及分批履约、退货及数量口径时参考。
- 交付要求：维护入口、双格式、渲染及预览核对。
- 开源参考说明：仅在维护来源时读取。
此包可由共享仓库安装到技能目录后通过 $erp-requirements-design 调用，也可直接读取实际位置的 SKILL.md 使用。安装位置不改变业务项目根目录或产物归属；技能调用不包含发送给开发、自动发布或创建 Git 历史的授权。