feat: add ERP requirements design skill

2026-10-27 19:29:36 +08:00
parent 1c92431021
commit 8705381e91
11 changed files with 775 additions and 2 deletions
@@ -0,0 +1,104 @@
+# 业务访谈与产品检查清单
+
+按业务选择使用；这是分析辅助，不是一次性发给用户的问卷。流程已清楚时直接写稿，未知项放回受影响的需求处。
+
+## 从一句话提炼可讨论的业务
+
+优先明确业务背景、目标、使用角色、触发条件、完成标准和本期边界。用户提供流程时沿着“输入 → 处理 → 输出 → 下一位处理人”补齐断点，不先讨论技术。
+
+例：“销售填单，采购处理，仓库收发货。”先区分现货销售与销售带动采购，问是否需要独立备货。不要直接假设每张销售单必然生成一张采购单。
+
+每个重要缺口按业务名称记录：`确认事项 / 业务影响 / 可选方案或建议 / 决策角色 / 相关功能或章节 / 是否影响定稿`。建议不是默认批准；用户不回答时保留待确认。确认后同步正文、菜单、图示、权限、验收及版本表，不继续在待决表中保留该项。
+
+## 角色与权限
+
+- 业务操作者、审核人、管理人、只读查看人分别是谁；组织/岗位变化后如何交接未完成事项。
+- 能否看本人、本部门、负责范围或全部记录；能否查看金额、成本、利润、附件、导出结果。
+- 可见不等于可编辑，可编辑不等于可审批。本人能否审批本人单据、离职人员待办怎么处理，按需要确认。
+- 产品写可验证的权限结果，如“销售不能通过列表、详情、导出或直接访问查看其他销售的订单”；具体实现由开发设计。
+
+## 流程与状态
+
+- 起点、提交条件、接手角色、完成标准和最后一个业务动作。
+- 草稿、待处理、进行中、部分完成、完成、关闭等状态按实际需要采用，不强套统一名称。
+- 审批中允许改哪些内容；退回、驳回、撤回是否不同；修改后是否重审，原记录如何查看。
+- 一单多明细时，部分完成、部分退回、部分关闭如何显示总单状态和剩余工作。
+- 作废、删除、关闭、归档各自代表什么；发生后能否恢复、谁能看历史、关联单据怎么处理。
+- 超时、无人接单、人员停用、处理中断后的责任人和下一步入口。
+- 保存草稿、提交申请、提交业务单据、完成实际办理各自意味着什么；哪些字段允许草稿暂缺、提交前必须补全，用户从哪里继续未完成事项。
+
+## 页面与字段
+
+- 写清一级菜单、二级模块及实际需要的三级页面，区分导航菜单、详情页和申请类型；明确新增、复用或调整。不能仅写“独立入口”。
+- 未确定菜单时依据业务职责和现有导航提出具体建议，标明待确认。确认后给出完整路径；不因内部群管理属于行政中心而将其他模块一律归入行政中心。
+- 申请、审批、办理、查询和基础资料维护分别从哪里进入；多个入口如何关联同一单据、版本和状态；PC 与移动端分别覆盖哪些任务。
+- 父级菜单可见性不应扩大该中心其他功能的权限，子菜单、记录、字段及附件范围分别控制。
+- 基础档案的维护入口、维护角色、建档方式、标识来源、负责人及系统账号关联是否明确；变更、停用、交接与历史记录如何处理。外部角色登记不自动授予平台资格。
+- 接入已有页面时分别记录当前入口、页面标题和拟使用的产品名称。旧菜单规划与实站不一致、标签疑似复制错误时先列差异，不直接照搬。
+- 列表默认视图、筛选、排序、分页、关键列、进度、待办提示；筛选清空后应恢复什么。
+- 新建、编辑、详情、审批、处理、历史记录页之间的关系。
+- 字段含义、来源、选项、单位、是否必填、条件必填、带出/填写、编辑时点、合法范围及错误文案。
+- 查询无结果、无权限、加载失败、处理中、成功、结果不明分别怎么显示；重复点击后的业务结果。
+- 导入、导出、打印、附件只在本期需要时展开。说明导入预览、错误行、重复判断、部分成功是否允许和结果反馈，不设计文件服务实现。
+- 多组明细：每组对应什么对象，允许多少组，逐组必填与整单必填的区别，增删明细如何影响合计、附件和审批条件。
+- 条件附件：何种单价/总额/类型触发，等于门槛如何处理，每组还是整单上传，文件数量和大小、缺失提示、金额修改后是否重新判断。现有行政采购页面的门槛只是该流程的观察值，不自动套给采销。
+- 星号、限额提示、空列表和演示数据分别标注观察层级；没有实际操作验证时，不写成校验已通过或业务已完成。
+
+## 审批与通知
+
+- 哪些单据需要审批、触发条件、节点顺序、审批人来源、多人如何算通过、抄送与通知区别。
+- 无可用审批人时如何提示和处理；人员名单变更对在途单据是否生效。
+- 申请表预览的审批节点、通过方式和抄送信息如何展示；业务要求优先使用岗位/组的职责表述，当前测试账号姓名不作为长期审批规则。
+- 申请人在哪看进度，审批人在哪接待办，办理人从哪里接后续工作；“我发起的、我的待办、我的已办、抄送我的”和全局管理视角按业务分别说明，不仅列一个总菜单。
+- 审批通过后是否生成待办/业务单据，谁继续办理；审批通过不等于业务执行完毕。
+- 相同审批结果被重复处理时，业务单据和待办不应重复；联动失败时显示待处理/异常、由谁核对并恢复。这里只定义用户可观察的结果。
+- 通知渠道、触发事件、接收角色、简要内容、跳转目标、重复或失败时是否重发；不能把“已提交”写成“已通知到所有人”。
+
+## 跨模块接入
+
+每项联动写六件事：来源模块和单据、触发业务动作、带入的业务信息、目标单据或待办、双方可追溯入口、失败时的状态和责任人。
+
+确定已有数据从哪里来、谁维护、修改是否影响历史记录；需要保留成交时名称/价格等历史信息时，用业务语义说明，不指定数据存储结构。
+
+分清“计划生成入库单”“仓库确认收货”“库存已增加”三个结果。若上游可修改或取消，说明下游尚未办理、部分办理、全部办理三种情况下怎么办。
+
+来源单号、目标单号、经办人、审批完成/建单/办理时间分别代表哪个阶段；关联信息为空时显示什么、是否仍允许继续、谁核对补齐。看见已完成状态但关联单号为空，只能记为该记录现象，不能推断关联不需要或功能必然异常。
+
+## 数量与金额
+
+只对涉及它们的业务展开：
+
+- 数量单位、可否小数、最小/最大值、换算、是否允许超量、数量分配到单据或明细的口径。
+- 币种、含税/未税、折扣、运费、税额、金额汇总与舍入位置；客户和供应商价格是否分别管理。
+- 已执行、已退、剩余、可用、占用等名称逐一定义，不能把净数量当累计履约数量。
+- 规则未确认时以具名待确认事项保留；不要把其他系统的税率、审批金额门槛、精度或负库存策略带入本项目。
+- 有示例时标注虚构测试数据，并使用明确公式复核结果；公式和示例必须同一口径。
+
+## 采销业务追加检查
+
+先确认业务模式：现货销售、以销定采、独立备货、代采中的哪些属于本期。
+
+再按已选范围检查：
+
+- 销售与采购是否一对一、多对多；拆单、合单、分仓、分批及未分配数量。
+- 云库分类/品牌/系列/SKU、行政资产分类与实物唯一码分别是什么；新业务选择现有 SKU 还是允许自由填写，历史商品信息如何保留。
+- 有唯一码的商品是否逐件登记，码与数量怎样对应，重复、缺码、错码、换货怎么处理，退货如何核对原件；无唯一码商品按数量还是批次管理。页面有“是否有唯一码”并不证明这些环节已实现。
+- 库存出库现有“销售、寄出、借出”是否与本期场景相关；不同用途是否需要返回、结算或不同责任人，不把所有出库都当销售完成。
+- 库存是否预留、何时预留/释放；无货、可用量不足、多个订单同时申请同一批货时的用户结果。
+- 订单审核、收发货计划、实际收发货各自时点；入出库单生成是否需要人工确认。
+- 部分到货、少货、多货、错货、不良品、剩余取消；历史手工入出库单是否与新单关联，防止重复处理。
+- 客户退货与供应商退货分别关联哪笔原收发货，数量上限和质检/可用状态，是否补发补采。
+- 退货对库存、订单进度和结算的影响分别说明；不要默认退货自动恢复订单未交数量。
+- 合同、付款、收款、发票、物流和财务是否在本期；不因系统叫 ERP 自动纳入全部范围。
+
+## 验收与评审
+
+用“验收场景 / 前置条件与操作 / 预期结果”组织验收，按业务名称或章节关联功能，不默认使用技术式编号，不用“正常”“准确”“友好”代替具体结果。
+
+按风险覆盖主流程、权限拒绝、字段边界、退回修改、取消、部分完成、重复处理、关联失败和存量衔接；不适用的项说明原因即可。
+
+若产品采纳条件附件、多组明细或唯一码规则，对应增加门槛下/等于/超过、明细增删后重新判断、缺失/重复唯一码等验收场景。测试数据来自已确认规则，不能靠测试样例暗定未知规则。
+
+性能、容量、文件上限等指标来源必须可追溯。业务未提出数值时，问可接受的等待时间或使用规模，或列为待确认；不自行写 2 秒、50 并发等数字。
+
+交付前核对：业务词汇一致、角色与动作相容、关键规则有验收场景，图与正文同义；待确认项未被写成定论，已确认内容不再被列为待定。产品评审通过与实际开发测试通过分开记录。
@@ -0,0 +1,48 @@
+# Word 与 Markdown 交付要求
+
+最终产物是业务 PRD，不是技术设计或验收报告。用户指定的格式、模板和位置优先。
+
+## 文件与版本维护
+
+1. 在对应业务目录保存同名 `.md` 和 `.docx`，默认文件名为 `业务名称产品需求文档-v0.1-YYYY-MM-DD`。日期用用户时区，版本取真实修订记录，不以“终稿”表示未确认稿件。
+2. 新建稿件采用“主标题 → 版本记录表 → 业务正文”。版本表为“版本、修订日期、修订内容”，每个版本一行，初稿不虚构上一版。标题下不再重复副标题或版本、日期、状态行。
+3. 持续编辑同一评审稿时保留维护入口。局部措辞、格式和删节一般更新当前版本并保留可恢复备份，不每次小改动都复制一套竞争版本。明确发布新基线、重要业务版本变化或用户要求留新版本时，按版本规则新建并指明最新文件。
+4. 同一版本更新该行修订摘要，不把每次对话视为新版本或生成多行同名版本；未确认决策保持待评审。
+5. Markdown 为维护源稿，Word 为排版版本。定点修改 Word 后同步源稿，核对章节、字段、权限、状态、图示和验收，避免两套内容分歧。
+6. 删除或改写须在两种格式及相关引用中生效。后续生成基于最新源稿，不恢复已删除的资料说明、旧标题或元数据。
+
+## Word 与图表制作
+
+- 优先使用当前可用的 `documents` 技能及其声明的生成、渲染依赖，按该技能发现工作区运行时；没有该技能时，可使用已有、获准的等效 DOCX 生成与渲染工具。安装本技能不会安装这些依赖，不临时安装未知来源程序，不将作者机器路径写入可复用生成逻辑。
+- 缺少生成或渲染能力时保留成果并说明限制，不以改扩展名代替 DOCX，不声称未执行的版面检查已通过。
+- 使用 Word 标题样式，业务章节按 `1`、`1.1`、`1.1.1` 编号并对应提纲级别；文首版本记录不占业务章号。
+- 中文字体和页码清晰，表格按内容设置列宽，允许换行并重复跨页表头；长段规则放正文。
+- Word 嵌入可见流程图、泳道图和页面示意，保留文字说明；Markdown 图片引用有效，需要维护时保留图源。
+- 示意与真实截图明确区分。图片段落不得因固定行高被裁切；检查图中文字、箭头、说明及页面位置。
+- 图示及例子的数量按解释需要确定，不强制每份 PRD 使用固定张数，不新增无依据的业务页面。
+
+## 内容与版面核对
+
+内容核对涵盖两种格式的版本表、标题层级、菜单路径、字段、规则、状态、未决事项和验收。交叉引用用名称或章节；用户明确要求编号时再核对编号集合。图中角色、条件及入口与正文一致。
+
+重点检查：
+
+- 已确认菜单是否仍在待确认表内，图中是否存在旧路径。
+- 删除技术式编号后，功能和验收覆盖是否仍然保留。
+- 文首是否仍有重复副标题或版本日期状态行，版本表是否一版本一行。
+- 已删除资料说明或旧标题是否被旧脚本、模板及副本恢复。
+- 业务完成、人工登记及系统回执是否区分，虚构示例是否被误作证据。
+
+版面核对需生成渲染页，检查字体、表格、图片、跨页表头、标题衔接、页码、空白与溢出。新文档及整体重排逐页检查；局部修改检查受影响页。文件能打开不等于版面已核验。
+
+## 预览与保存内容不一致
+
+用户反馈旧内容时，先读取实际保存的 Word 和 Markdown，核对路径、版本、修改时间及关键文字，按需核对当前预览文件。不能直接归咎于缓存，也不重复改写已经正确的内容。
+
+保存内容正确时说明已核实的版本，提示刷新或重新打开。用户确认只是未刷新后停止排查，不清理应用缓存或修改无关设置。文件确实仍旧时，修改真实维护入口并重新核对。
+
+## 交付说明
+
+提供两个产物的可点击绝对路径，概括改动、关键未决事项及实际核对范围。小改动简短说明，不重复整份目录。文档确认、页面观察、业务验收和部署验证分开表达。
+
+渲染图片、临时 PDF、备份及调试脚本留在独立工作目录。用户未要求时不追加 PDF、演示文稿、测试台账或技术设计。
@@ -0,0 +1,104 @@
+# ERP 测试站产品页面观察
+
+观察日期：2026-10-27，Asia/Shanghai。入口：`https://erp-test.it.aisuan.cn/pc/`。本记录为同日重试成功后的页面证据，供后续产品需求分析按主题读取；不代替未来复核或业务验收。
+
+## 观察范围和证据强度
+
+- 使用已有登录会话，未切换账户，未核对角色授权名称；观察仅代表该会话可见范围。没有访问生产环境或移动端。
+- 通过浏览器读取实际渲染页面的菜单、列表、表单和一条已入库采购详情。下列路径来自页面导航链接，是页面定位信息，不是要求开发采用的接口设计。
+- 打开过出库新增、行政采购申请、SKU 新增表单；在采购申请里展开一组空白明细以查看字段，随后关闭。没有保存草稿、提交申请、保存业务数据、上传文件、审批、刷新缓存或执行入出库。
+- “页面标必填”“页面提示上限”“筛选提供某状态”不代表已验证提交校验、状态迁移或数据一致性。没有完成端到端业务流程测试。
+- 记录只保留结构与业务语义，不复制人员名单、具体单号、金额、附件内容或其他测试业务数据。
+
+## SITE-01 首页与菜单
+
+入口：`/pc/`。
+
+首页明确显示“当前页面为演示界面，数据仅供参考”。销售额、订单数、活动动态等不能用作真实业务指标、使用量或验收证据。
+
+当前会话可见云库管理、行政中心、个人中心、运营中心、服务号管理、审批中心、人事中心、财务中心、生产管理、代采管理、库存管理、报价管理、企微客户群等一级入口。未见独立“采销管理”一级入口；不能据此判断全系统未实现、已停用或没有权限，原因待核实。
+
+当前入口与本地《菜单调整方案》有差别：仍为“生产管理”，发起申请及个人审批相关入口仍在审批中心；行政资产仍位于“行政中心 → 资产管理”。新需求需分别写现状入口和拟调整入口，不将方案当已上线布局。
+
+## SITE-02 库存入库单
+
+入口：库存管理 → 入库单，`/pc/ERP/Inventory/InStockBill/List`。
+
+- 列表标题为“ERP入库单列表”；状态筛选有全部、待入库、部分入库、入库完成、已作废。
+- 列有入库单号、入库类型、业务描述、入库信息、附加信息、备注、操作。
+- 本次列表显示无匹配记录，未查看入库详情或办理表单，不能证明实际分批入库流程已验证。
+
+产品启示：入库可见状态已细分到部分完成和作废。新模块应明确明细与整单完成口径、剩余数量和作废影响；具体迁移条件仍需核实。
+
+## SITE-03 库存出库单
+
+入口：库存管理 → 出库单，`/pc/ERP/Inventory/OutStockBill/List`。
+
+- 列表标题为“ERP出库单列表”，有“新增ERP出库单”按钮；类型选项为销售、寄出、借出，状态选项为已提交、已出库。
+- 列有出库单号、出库类型、业务描述、出库信息、附加信息、备注、提交出库、操作。本次列表为空，没有核对真实行上的办理动作。
+- 两个筛选标签分别显示“入库类型”“入库状态”，与当前出库页面不一致；这是页面文案差异，不能直接沿用为需求术语。
+- 新增弹窗在当前默认“销售”类型下，出库部门、出库类型、业务数据、销售人、出库日期、合同编号带必填标记；运单号、备注没有显示该标记。
+- “业务数据”和“销售人”各有选择入口；本次未打开选择器，业务数据来源及可选范围未核实。没有切换寄出/借出类型，不推断其他类型表单相同。
+
+产品启示：出库用途不等于销售类型；新业务需说明何时选择销售、寄出或借出，以及是否有返还、结算或后续跟踪。现有出库状态与入库状态不对称，不能直接假设已支持相同的分批规则。
+
+## SITE-04 行政采购列表与已入库详情
+
+入口：行政中心 → 资产管理 → 采购管理，`/pc/Operation/AssetPurchase`。
+
+- 页面标题是“采购申请列表”。可按采购单号/标题/申请人姓名、申请部门、状态、发起时间筛选；状态为待采购、已入库。
+- 列有采购单号、申请人、部门、明细数、数量、金额、状态、发起时间、操作。本次看到待采购行有“入库、详情”，已入库行有“详情”；未点击办理入库。
+- 一条已入库详情显示采购申请信息和明细两部分。头部包含期望交付、明细条数、合计数量/金额、单据状态、关联申请单、入库单号、入库经办人、入库时间、用途、审批完成时间、建单时间和审批意见等。
+- 明细列有物品名称、资产类型、分类、物品类型、品牌、型号、数量、单价、金额、是否含税、备注。
+- 所看记录为已入库，能看到入库经办人与时间，但关联申请单及入库单号显示“-”。这是单条测试记录现象，不能判定全系统关联缺失，也不能认为关联字段无需填写。
+
+产品启示：审批完成、创建采购业务记录、实际入库是不同业务阶段。行政资产分类与商品云库的分类/SKU不要混同；展示关联信息缺失时，应明确用户如何追溯和由谁核对。
+
+## SITE-05 审批入口与行政采购表单
+
+入口：审批中心 → 发起申请，`/pc/Approval/Submit`。
+
+审批中心菜单分为发起申请、我的待办、我的已办、抄送我的、我发起的、审批单管理、流程定义、通知发送记录、回调发送记录、分类配置、通知模板。菜单可见不代表本次验证了其查询、操作或管理权限。
+
+发起页按人事、行政、财务分组。本次展开行政组，看见采购、发货、访客、合同审核、物品归还、物品借用、物资领用、用车、纸质盖章申请；只打开采购申请表单。
+
+采购申请页面声明：
+
+| 层次 | 所见字段或交互 | 本轮证据边界 |
+|---|---|---|
+| 申请头 | 期望交付日期、申请事由标必填；事由显示 0/500 | 没有触发空值或超长提交校验 |
+| 明细容器 | 采购明细标必填，已填组数按“当前数/20”显示，支持添加和删除组 | 仅展开一组空白明细，未测试数量上限 |
+| 每组明细 | 物品名称、数量、单价、是否含税标必填；含税选项为是/否 | 数量精度、单价范围及提交校验未核实 |
+| 购买链接 | 可填写，显示 0/2000 | 没有测试链接格式或长度限制 |
+| 比价单 | 文案说明“单价超过 300 元须上传比价单” | 只确认页面提示；等于 300、修改价格后是否重校验等未验证 |
+| 合同附件 | 盖章版采购或相关合同，提示上传相关文件 | 是否在所有场景强制必填未核实 |
+| 两类附件 | 均提示单个文件不超过 50MB、最多 10 个 | 没有选择或上传文件，没有验证实际拦截 |
+| 结尾动作 | 关闭、保存草稿、提交申请 | 只执行关闭，未验证草稿保存、必填差异及提交结果 |
+
+当前表单没有显示资产类型、资产分类或价格区间字段。它不同于历史交接中的价格区间描述，也不同于已入库详情中展示最终资产类型的阶段。
+
+表单还展示审批流程预览，按界面顺序为：总经办终审（或签，一人同意）→ 行政部负责人审批（单人审批）→ 资金执行审批（或签，一人同意）→ 抄送。显示了当前配置的人员，本记录不保留姓名。节点排列及适用对象只代表这张表单的当前预览，未实际提交验证，不作为其他模块固定流程。
+
+产品启示：描述申请人、审批人、后续办理人各自入口；区分审批与抄送；写明草稿和提交的字段要求、多组明细的规则、条件附件口径。300 元、20 组、50MB、10 个等不能默认带入商品采销或其他新业务。
+
+## SITE-06 云库 SKU
+
+入口：云库管理 → SKU，`/pc/IT/SKU`。云库另有分类、品牌、系列入口。
+
+- SKU 页有分类、品牌、系列三个选择控件；本次未切换筛选值，不宣称级联清空或其他联动已验证。
+- 列表展示图片、中文名称、英文名称、唯一码及操作，提供新增、修改、删除和刷新缓存入口；未执行保存、删除或刷新缓存。
+- 新增弹窗显示中文名称、英文名称、是否有唯一码（是/否）、图片选择等必填标记。本次未填写或上传。
+- 弹窗标题写“在【分类】下的【品牌】下的【系列】新增云库系列”，与“新增云库SKU”入口不一致；应记录标题差异，不将它当作实际新增对象发生改变的证据。
+
+产品启示：SKU 表示商品规格，唯一码涉及单件实物身份。新业务应确认是否逐件管理、码与数量如何对应、退换货如何对应原件；当前开关不证明收发货及退货追踪已完整实现。
+
+## 后续需求应保留的待核实项
+
+- 独立采销模块的实际入口、可用角色及已有功能边界。
+- 入出库真实记录及分批、作废、重复办理的实际行为；新单据与现有手工单据的承接。
+- 出库“业务数据”选择来源、不同出库类型的字段差异及合同要求。
+- 行政采购表单提示的强制执行情况、已入库关联字段为空的原因。
+- 唯一码在入出库和退换货中的完整处理规则。
+- 跨角色权限、审批在途变化、通知与后续业务联动、移动端与生产环境。
+
+写产品方案时可以针对上述缺口提出建议和 AC 草案，但需要标明来源与未决项，不能把本次只读观察写成“业务全流程测试通过”。
@@ -0,0 +1,25 @@
+# 开源参考与适配范围
+
+检索与原始文件核对日期：2026-10-27。链接指向上游分支，后续可能变化；这里记录本次查看到的内容，不代表未来版本承诺。本 skill 的中文产品流程与模板为面向本项目编写，未整包复制或安装第三方 skill，也不执行其脚本。
+
+## 采用的方法参考
+
+| 来源 | 本次核对许可 | 借鉴的通用方法 | 本项目的适配 |
+|---|---|---|---|
+| [Ralph PRD skill](https://github.com/snarktank/ralph/blob/main/skills/prd/SKILL.md) | [MIT](https://github.com/snarktank/ralph/blob/main/LICENSE) | 澄清关键缺口、需求可追溯、可验证验收、本期范围和非目标 | 面向业务用户提问；以业务名称和章节定位需求，增加字段、状态、权限、审批及衔接；不沿用其技术式编号、编码任务式故事和固定输出路径 |
+| [GitHub Spec Kit specification template](https://github.com/github/spec-kit/blob/main/templates/spec-template.md) | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) | 按业务场景组织需求、明确未决问题、区分假设与可测结果 | 将这些方法组织为中文产品需求与评审流程，不引入分支创建、代码实施或技术方案流程 |
+
+以上均为方法借鉴及自主表述，没有复制上游模板正文或代码。若未来引入实质原文或脚本，应重新核对许可并保留相应版权和许可声明。
+
+## 调研后未纳入的候选
+
+[Product-Manager-Skills 的 prd-development](https://github.com/deanpeters/Product-Manager-Skills/blob/main/skills/prd-development/SKILL.md) 提供完整产品需求工作流，但本次核对的仓库 [LICENSE](https://github.com/deanpeters/Product-Manager-Skills/blob/main/LICENSE) 为 CC BY-NC-SA 4.0。本项目用于公司内部业务工作，因此未复制、改编或打包其中内容，也未将其作为运行依赖。这里只保留调研来源记录。
+
+## 本项目独立补充
+
+- 产品侧文档边界：说明业务行为和可观察结果，将技术设计交给开发。
+- 区分商品采销、行政采购、代采；关联 SKU、库存、审批、个人与管理入口。
+- 区分历史材料、本轮观察、用户确认、建议与待决问题。
+- Word 和 Markdown 双格式、业务名称及章节定位、文首版本表和内容一致性核对。
+- 正式 PRD 结构、阿拉伯数字提纲、可见流程图及拟建页面示意；明确菜单层级与基础档案维护入口。
+- 分批履约、退货数量口径与存量单据衔接的产品检查。
@@ -0,0 +1,76 @@
+# PRD 结构与表达规范
+
+本规范适用于本技能生成的中文业务评审稿。用户提供模板或提出其他明确格式要求时优先；局部修订不自动扩大为整篇改版。
+
+## 文档结构
+
+从“主标题、版本记录表、业务正文”开始。版本记录位于最前，不在标题下重复副标题及版本、日期、状态说明行。版本表为“版本、修订日期、修订内容”，每个版本一行，版本及日期取真实记录。
+
+| 章节 | 核心内容 | 适合的表达方式 |
+|---|---|---|
+| 背景与目标 | 背景、目标、本期边界及完成标准 | 简洁段落，必要时列范围表 |
+| 现状及预期效果 | 业务环节的变化与预期改善 | 环节对照表、功能建设清单 |
+| 整体流程 | 角色衔接及关键分支 | 泳道图或流程图及文字说明 |
+| 详细需求 | 页面、字段、操作及异常 | 按页面展开，结合示意、字段及操作表 |
+| 权限与状态规则 | 角色范围、状态及关键规则 | 权限矩阵、状态图或必要的状态表 |
+| 验收与上线要求 | 完成标准、异常及切换验证 | 场景、前置条件与操作、预期结果 |
+| 评审确认事项 | 未决事项、责任与影响 | 事项名称、建议方案、确认责任及影响 |
+
+现状尚未核实时采用“已明确的管理诉求”对照，不为填表编造现行流程。新增功能标明“本期新增”，未复核的既有能力写“拟复用，适配范围待核实”。
+
+## 标题与正文
+
+业务章节采用 `1`、`1.1`、`1.1.1`，不与中文序号混排，不为凑三级标题机械拆分。Word 使用对应标题样式和提纲级别，不只加粗普通段落。
+
+| 口语表述 | 正式表述示例 |
+|---|---|
+| 为什么要做 | 业务背景、建设目标 |
+| 这个功能要解决什么问题 | 项目概述、背景与目标 |
+| 谁来审批 | 审批人员与节点配置 |
+| 怎么填写、从哪里申请 | 表单字段与校验、申请入口与提交规则 |
+| 出问题怎么办 | 异常处理、失败恢复 |
+| 需要谁拍板 | 待确认事项、确认责任 |
+| 看看有没有办完 | 办理状态、完成标准、验收要求 |
+
+正文及表格也使用正式而具体的表述，例如“审批通过后生成待办，由有权限的管理员领取；登记实际办理结果后记为已完成”。不要只替换标题而保留口语，也不要用空泛术语代替业务动作。
+
+功能用业务名称，如“供应商准入申请”；验收用场景名称，如“审批人员失效”“取消与办理并发”。交叉定位使用名称或章节号，默认不引入技术式标识及编号追踪矩阵。
+
+## 页面需求的写法
+
+按“建设方式、入口与角色、页面内容、操作与结果、异常与权限”展开。例：
+
+**4.3 资格核对**
+
+建设方式：本期新增，审批结果拟复用审批中心。入口：采购中心下的业务模块，具体层级须根据该业务确认。使用角色：获授权的资格核对人员。
+
+审批通过后形成核对待办。核对人员查看批准版本及允许访问的附件，登记核对结果；核对通过并执行启用后，供应商状态变为已启用。审批通过本身不构成启用完成。处理结果不明时先核实原记录，不重复创建供应商。
+
+此例仅说明描述粒度，不是其他模块的默认菜单或确认规则。实际文档应将已确认入口写成完整路径，并补齐字段和异常要求。
+
+## 图表与示例
+
+- 跨角色主流程使用泳道图，判断节点标明条件和结果，动作与对应角色一致。
+- 新建页面用低保真示意展示信息分区、关键字段和按钮，标注“拟建页面／非现有界面”。正文保留字段和操作条件。
+- 现有截图注明环境、日期和观察范围；只参考表达风格时，不移用其中的业务规则、数据、人员或链接。
+- 状态或异常图承担必要解释，不重复制作同义图。保留文字流程，便于图片无法显示时理解。
+- 对比、字段、状态和验收等重复结构使用表格；长段规则使用正文，避免挤入窄列。设置合理列宽和跨页表头。
+- 示例注明虚构，覆盖关键判断；时间、金额、数量与正文一致，不以示例暗定限制。
+
+## 评审稿与工作记录
+
+交付稿围绕业务背景、目标、规则及待决事项，不默认附带“参考了哪些资料”、工具过程或“本轮未访问哪些页面”等编制过程章节。资料路径、读取时间和观察证据留在工作记录，按需可追溯。
+
+仍须准确表达业务事实：拟建图标为示意，未确认权限和审批层级保留待定，未验证能力不写成已支持，验收条件不写成已通过。用户要求来源说明时另行添加，不能为精简隐瞒影响业务判断的限制。
+
+## 菜单与档案检查
+
+成稿前应能明确回答：
+
+1. 一级菜单、二级模块和三级页面分别是什么；哪些属于详情页或申请类型而非导航菜单。
+2. 申请、审批、办理和资料维护各从哪个完整路径进入；不同入口是否对应同一单据。
+3. 父级和子菜单可见性如何授予，是否会扩大其他功能或数据权限。
+4. 基础档案由谁建立、从哪里维护，人工录入、导入或同步的方式是否已确认。
+5. 识别信息、负责人和系统账号如何关联，变更、停用及历史记录如何处理。
+
+内部群管理归属行政中心是该模块的已确认决策，不是其他业务的默认归属。未决菜单需给出有依据的建议及影响；确认后同步所有引用，移除相应的“归属待确认”表述。
@@ -0,0 +1,71 @@
+# 采销产品需求片段
+
+下面是**虚构演示**，用来展示产品描述的粒度，不是公司当前规则、已确认需求或完整采销设计。不得把示例的数量和审批选择直接用于真实业务。
+
+## 模拟输入
+
+“销售建订单，主管审核后仓库可以分批发货。暂不做财务结算。已发货的部分不能删除，客户可以申请退货。”
+
+可直接记录的用户要求：销售建单、主管审核、分批发货、不含本期财务结算、保留已发货记录、支持客户退货。
+
+先问影响最大的缺口：
+
+- 退货后的补发规则：客户退货确认后，原订单是否需要补发？这决定订单待交付数量是否恢复。
+- 审批后的业务衔接：主管审核通过时，是通知仓库准备，还是立即产生待发货单？这决定衔接时点，不能直接等同库存已减少。
+- 订单及字段权限：销售和仓库分别能看哪些订单，销售能否看成本？这决定记录和字段的可见范围。
+
+用户未回答时，可以先写稿，但上述规则保持待确认。以下“分批发货方案”是产品建议。
+
+## 分批发货
+
+目的：仓库按实际发出的数量逐次登记，销售可查看每次发货记录及尚未交付数量。
+
+操作者：仓库处理人员；数据范围需确认“订单及字段权限”。
+
+入口建议：库存管理（一级）→ 销售出库（二级）→ 待发货（三级），由列表进入订单详情并选择本次发货明细。此为示例菜单，实际导航及模块归属需另行确认；订单详情不新增为独立菜单。
+
+前置条件：订单审批已通过，且当前仍有待交付数量。待发货单生成时点需确认“审批后的业务衔接”。
+
+| 业务字段 | 来源 | 规则与提示 |
+|---|---|---|
+| 商品 SKU | 从原订单带入 | 本次发货不允许换成其他商品 |
+| 本次发货数量 | 仓库填写 | 产品建议为大于零且不超过该行剩余可发量；单位、小数规则另按实际商品确认 |
+| 发货仓库 | 选择可操作仓库 | 可选范围及库存不足处理待业务确认 |
+| 发货说明 | 仓库填写 | 是否必填及长度上限待确认，不随意指定数值 |
+
+处理结果：保存成功后形成一笔可查看的发货记录，销售可看到数量和办理人；订单显示部分完成或全部完成。实际库存变动应在业务确认的发货节点体现，具体节点和现有库存能力需核实。
+
+异常反馈：重复点击或结果不明后再次办理，不应出现同一次发货被重复记账；页面应能查询本次是否已完成。数量超出剩余时提示“本次发货数量超过剩余可发数量”，不改变原记录。
+
+## 未发生退货时的履约计算
+
+产品建议：累计发货量按有效发货记录累计；剩余待交付量 = 原订单数量 − 累计有效发货量。已发货历史不得直接删除，纠正方式需业务确认。
+
+仅演示“无退货、无作废、无改量”场景：订购 10 件，首次发出 4 件，再发出 3 件，累计发货 7 件，剩余 3 件。
+
+若随后退回 2 件，可展示累计发货 7 件、累计退货 2 件、净交付 5 件；**剩余待交付量是否从 3 变为 5 取决于“退货后的补发规则”，不能用净交付量直接推定需要补发。**
+
+## 状态与验收
+
+| 当前状态 | 动作 | 条件 | 建议结果 |
+|---|---|---|---|
+| 待交付 | 仓库确认首次发货 | 发货量大于零且小于待交付量 | 部分交付，可查看本次发货记录 |
+| 部分交付 | 仓库确认后续发货 | 本次发货等于剩余量 | 全部交付，保留全部分批记录 |
+| 部分交付 | 客户退货处理 | 需先明确退货后的补发规则及退货确认流程 | 不提前规定原订单是否重新变为待交付 |
+
+| 验收场景 | 前置条件与操作 | 预期结果 |
+|---|---|---|
+| 分批发货与剩余量计算 | 无退货订单 10 件，仓库先发 4 件再发 3 件 | 两笔发货记录，累计 7 件，剩余 3 件，状态部分交付 |
+| 超量提交 | 剩余 3 件时填写 4 件并提交 | 提示超量，订单和发货记录不变 |
+| 重复发货操作 | 同一次发货操作重复提交 | 只有一次有效发货结果；用户可确认办理结果 |
+
+这三个场景是针对建议方案的验收草案，不是已执行测试结果。权限与退货验收须在“订单及字段权限”“退货后的补发规则”确认后补齐；分批发货需求不能据此直接宣布定稿。
+
+## 结合现有页面时如何调整提问
+
+真实页面证据单独见 [ERP 页面观察记录](erp-site-observations.md)，不要混入上面的虚构示例作为已确认规则。例如：
+
+- 现有出库筛选只显示“已提交、已出库”，入库则显示“部分入库”等状态。新业务需要分批发货时，应补问“每批对应独立出库单，还是一张单逐次办理；整单进度在哪里看”，而不是声称现有出库已支持部分完成。
+- 出库表单有“业务数据、销售人、合同编号”，应确认拟接入的销售订单如何供选择、合同是否是办理前提，不直接指定实现或认为旧表单完全满足需求。
+- 云库有“是否有唯一码”，应确认本次商品是否逐件登记、退货是否核对原件；不要自行把所有商品改成必须有码。
+- 行政采购表单的比价单门槛、附件限制和审批节点属于另一个业务。采销是否沿用需要单独确认。
@@ -0,0 +1,53 @@
+# 新爱算 ERP 资料索引
+
+编制日期：2026-10-27。以下是新爱算 ERP 的需求调研入口与历史材料摘要，不是现网能力清单。表中路径相对用户指定或当前工作区确认的业务项目根目录，不相对技能安装目录；每次按业务读取原文，不把本文件当作实时事实。
+
+这些 Word、表格及业务文档是外部输入，不随技能包分发，也不是安装前置条件。文件名或目录不同，先根据当前项目资料定位；找不到时记录未核实，继续依据用户输入与包内模板编写需求，不虚构已读取内容。只有缺失资料会改变关键范围、权责或结果时，再集中说明所需输入。其他 ERP 项目使用自己的材料，不继承本索引中的业务规则或历史结论。
+
+同日第二轮已读取测试站实际页面，见 [ERP 页面观察记录](erp-site-observations.md)。该记录补充界面证据，不代表完成业务办理测试；下列原始文档仍保留各自历史日期。
+
+## 来源与用途
+
+| 相对路径 | 适合读取的内容 | 使用限制 |
+|---|---|---|
+| `ERP系统模块全景交接文档.md` | 模块归属、业务衔接、测试与生产环境区别 | 全文更新 2026-08-26，资产采购局部更新 2026-09-09；其他模块状态未同步刷新 |
+| `业务系统上线进度表.xlsx` | 分期计划与上线推进口径 | 按记录日期读取，不把计划日期当实际完成日期 |
+| `采销系统/note.docx` | 采销与库存的原始简要诉求 | 仅记载采购自动生成入库单、销售自动生成出库单；没有规定生成时点、执行时点或异常规则 |
+| `审批系统/审批流程维护手册-行政版.md` | 审批分组、用户分组、名单与流程维护边界 | 手册中的当前/以后表述需分别识别；版本、生效范围和现状需要核对 |
+| `审批系统/审批流程变更申请表(模板).xlsx` | 审批节点、表单字段与新流程信息的收集方式 | 模板用于补充业务输入，不代表已提交或已批准的流程 |
+| `菜单权限/菜单调整方案.md` | 入口归属、个人入口与管理入口的规划 | 是调整方案，不能直接称为测试站当前菜单 |
+| `设计需求系统/新爱算-设计需求ERP系统开发文档.docx` | 背景、角色、需求到工单、审核交付等写法 | 含未经本轮核实的技术选型和数值指标，不能照搬到新模块 |
+| `运营中心-商机管理/客户线索管理模块-开发设计文档.md` | 复杂角色、分配粒度、状态和终态的业务线索 | 文内标题为客户商机管理；V1.3 日期 2026-09-01，技术设计不是新需求模板 |
+| `运营中心-商机管理/商机管理系统业务测试与上线梳理.xlsx` | 测试场景、状态与权限设计、未决问题 | 2026-09-08 整理说明明确实际开发、部署和验收待证据确认 |
+| `行政中心-资产管理/固定资产系统测试上线推进台账.xlsx` | 统一采购、入库分类和业务回归场景 | 读取到的记录更新至 2026-09-09，不推断本轮状态 |
+| `行政中心-资产管理/采购领用审批流 20260912.xlsx` | 相关采购领用审批流程材料 | 使用时读取实际单元格内容和修订信息 |
+| `访客管理制度/`、`用车管理系统/` | 管理制度、岗位流程和产品操作说明 | 仅在对应业务或有明确可复用规则时读取；本轮未全面核对这些目录内容 |
+
+## 需要优先检查的模块边界
+
+以下来自交接文档，均属历史描述：
+
+- 云库：分类、品牌、系列、SKU，为报价、库存、采销提供商品基础信息。新模块应先确认能否沿用，避免另建同义商品库。
+- 库存：入库、出库、库存查询、流水、盘库。历史资料记载库管手工建入出库单，上游采购销售自动触发属于后续规划；不是已验证能力。
+- 采销：采购单、销售单及库存联动；完整业务需求待确认。不能从两句 note 推断先款后货、自动扣库存或一单只能一个仓库。
+- 行政资产：统一采购申请，行政在入库时区分资产类型；与商品采销采购、财务代采分别说明归属。
+- 审批：审批通过后联动业务。需要产品侧明确“通过后产生什么、重复到达/失败时用户看到什么”，技术机制由开发设计。
+- 消息：站内信、企业微信等能力可能被其他模块使用；新业务要明确是否通知、通知谁、何时通知、点开到哪里，而不是默认群发。
+- 权限：菜单组织、操作权限和数据可见范围是不同问题；员工自己的入口与管理人员全局入口要分别说明。
+
+## 已发现的材料差异
+
+1. 设计需求 Word 中写 MySQL、删除标记和软删除；商机技术文档写 PostgreSQL、物理删除与全量日志。两份材料不能共同证明全系统技术规范。产品需求只描述删除/作废后业务记录的可见性、追溯和恢复要求，技术方案交开发核实。
+2. 商机技术文档引用同目录《客户商机管理模块-需求文档.md》，本轮文件清单未见该文件；不能假称已与它核对。
+3. 商机技术文档中的部分状态代码片段与表格说明不一致，验收梳理也要求统一状态名称与编码。产品文档应给清晰的业务状态和迁移，不复制有冲突的枚举代码。
+4. 菜单调整方案含新建、迁移、重命名标记，只能用作规划线索。2026-10-27 页面仍可见“生产管理”“行政中心 → 资产管理”及“审批中心 → 发起申请”等原入口；并未完整呈现方案中的新布局。
+5. 2026-09-09 交接说明记载采购申请保留价格区间；2026-10-27 打开的行政采购明细显示“单价、是否含税、购买链接、比价单、盖章版采购或相关合同”，本次所见表单未显示价格区间。写新需求时注明日期和差异，不混合成同一版本字段。
+
+## 网站观察边界
+
+- 用户指定测试入口：`https://erp-test.it.aisuan.cn/pc/`。
+- 首轮观察：2026-10-27 浏览器绑定超时，随后电脑工具因无法可靠识别当前 URL 停止操作；首轮只识别到标签标题和地址，没有读取业务页面。
+- 同日第二轮：在用户要求重试后，成功使用既有登录会话读取 PC 首页、库存入出库列表、出库新增表单、行政采购列表和一条已入库详情、审批入口和采购申请表单、云库 SKU 列表及新增表单。具体证据和路径见页面观察记录。
+- 第二轮只做页面观察，新增表单均已关闭，未保存、提交、上传或审批。没有完成新单据的端到端办理、状态变迁、库存数量变化及跨角色权限验证。
+- 后续写需求时仍需按当次业务做相关只读复核；历史观察不能永久代表当前系统。当前会话未见独立“采销管理”一级菜单，原因尚未确认，不推断全系统缺失该模块。
+- 本文件不包含账号、密码或凭据值。需要登录时按既有授权和正常认证流程处理。