跳转至

业务知识维护指南

新增内容先确定业务概念，再检查现有词条，避免按每份 PRD 的章节重新建立一套同义词。只接纳能够解释业务对象、用户操作、规则、关系和业务异常的内容。

录入新来源

  1. 在 data/sources.yaml 登记来源 ID、文档名、日期、版本和校验值。新版本使用新的来源 ID，不复用旧校验值。
  2. 本地执行 python scripts/extract_source.py <新文档.docx>，阅读完整正文、表格、批注和业务附图。提取文件留在 .local/，不能直接变成知识库事实。
  3. 在 data/evidence.yaml 保存经审阅的业务摘录和原文定位。新增来源的证据 ID 必须全局唯一，例如 prd-2026-11-p0120。记录来源 ID和实际段落，不猜测页码。
  4. 记录覆盖范围和筛选理由；处理原文与现有规则之间的差异，不静默覆盖旧规则。

修改或新增词条

data/glossary.yaml 是词条的唯一编辑源。维护中文定义、通俗解释、规则及各规则证据；推荐和候选西语分别保存。词条 Markdown 由脚本生成，直接修改会被覆盖，持续集成也会发现未同步的生成页。

新增词条使用英文 kebab-case ID，并在 data/urls.yaml 登记固定路径。名称更正不改变 ID 或页面路径。不要删除已有 ID；废弃概念需要保留说明页面，迁移路径必须另行提供旧 URL 跳转并核验。

关系在 data/relationships.yaml 维护，端点必须是现有词条，附来源证据、适用范围和状态。related_terms 保存人工确认的相关项；增加或调整关系时同步它。不要仅因为译名接近自动认定两个概念相同。

复杂流程、模型和概念辨析使用人工 Markdown。每项业务判断都提供来源链接，补充内容与原文事实分别表达。不从缺失的空白章节创造状态机或规则。

记录客户确认

确认西语时填写 name_es，设置 customer_confirmed: true、spanish_status: confirmed，并填入 confirmation_record 的日期、记录依据、确认范围和确认人角色。推荐字段可以保留讨论历史。确认记录示例结构：

confirmation_record:
  date: YYYY-MM-DD
  reference: 内部客户会议或书面确认记录的真实位置
  confirmed_by: 实际确认人或其业务角色
  scope: 此次明确确认的用语及范围

这个片段说明字段格式，不是实际确认记录。不要复制示例作为证据。业务仍有问题时，整体 status 保留 pending_confirmation；只有业务边界清楚且客户用语已确认，才设为 confirmed。把独立业务问题的答案和确认依据同步到 data/pending-confirmation.yaml。闭合的条目保留其历史和证据。

生成与检查

python scripts/build_indexes.py
python scripts/verify.py

提交 YAML、生成 Markdown、人工说明和来源更新，采用 Pull Request 审阅业务证据及固定链接。不要提交完整内部 Word、本地提取文本、个人信息或预览构建目录。

查看项目根目录 README 中的环境安装、内部托管和 GitHub 配置步骤。