工作库 Wiki Schema¶
这个 Wiki 是金光集团中国区 IT 知识资产系统。AI Agent 须遵守以下规则。
核心规则（不可违抗）¶
- raw 只能追加和读取，不要改写原文
- concepts 存放概念页，entities 存放实体页
- 重要概念使用
[[wikilink]] - 关键结论尽量绑定来源
- 不确定内容必须标记为
> [!warning] 待验证 - 每次重要修改后更新 log.md
- 新增重要页面后更新 index.md
- 省心更新模式：新数据与已确认内容冲突或补充时，直接合并更新正文，不追加待确认区块、不询问（用户要求，已记入 memory）
-
SOP 范围：仅限中国区 — 所有 SOP 相关分析/提取/对照以
DSH-FOD-*（食品）和DSH-AGR-*（粮油）开头文件为准。GIT-/G-GCC-/DSC-等集团全球策略不计入「中国区 SOP」，仅做参考。 -
A2 + SOP 双规则体系 — 金光中国治理底层逻辑
A2 核决权限表是整个金光中国所有工作事项的审批流底层逻辑和基础，必须严格遵守。SOP 对金光中国业务进行管理和约束。两者的关系是分层嵌套的：
- A2 = 刚 — 审批角色、金额阈值（RMB'000）、审批链顺序是不可逾越的硬约束，系统/流程/项目必须严格遵守，不可讨价还价
- SOP = 柔 — 业务流程怎么做、谁执行、什么标准是行为规范，需遵守；当系统实现与 SOP 不一致时，可双向调整（改 SOP 或改系统）
任何项目类文档必须同时遵守 A2 和 SOP 两套规则。 不存在「项目特殊可以绕开」的情况。
10.1 规则第一性：A2 是审批底层¶
- 任何审批流设计必须从 A2 出发，A2 定义的审批角色、金额阈值（RMB'000）、审批链顺序是唯一合法基准
- SOP 中的审批节点不得与 A2 冲突——若冲突，以 A2 为准
- 组织架构图中的人员分配仅用于角色映射（人→岗），不可替代 A2 定义的审批链
- 项目文档中禁止自创审批角色名 → 必须使用 A2 原文角色名（全中文，除 Agri 英文原文外）
10.2 规则第二性：SOP 是执行约束¶
- SOP 规定业务流程怎么做、谁执行、什么标准。项目文档中的操作流程、部门职责、验收标准必须与相关 SOP 一致
- 若 SOP 与 A2 在审批节点上有交叉——审批走 A2，执行走 SOP
- 若项目文档发现 SOP 不合理或缺失 → 走制度变更流程，不做绕过动作
10.3 版本漂移管理（核心机制）¶
A2 和 SOP 不定期发布更新版本，导致「旧项目文档 vs 新制度」之间产生版本漂移。以下四种情况必须触发重新审视：
# 触发事件 审视范围 执行方式 1 A2 新版发布（有正式邮件/通知） S4 蓝图/TPM 设计/纷享销客配置/KUBE-OA审批流/权限设计 Diff 受影响域 → 逐节点自检 → 更新关联文档 2 SOP 新版发布 所有引用该 SOP 的项目文档 流程变更 diff → 交叉比对 A2 → 更新文档 3 组织架构变动（换人/调岗/层级调整） A2 审批角色「当前在位人」映射、SOP 部门职责分配 更新岗位对照表 → 确认不影响审批链 4 新项目启动 对应审批域 + 相关 SOP 先查 A2 → 再查 SOP → 再动笔（见 10.4） 审视流程（收件→执行闭环）：
收到新版 A2/SOP │ ├─ 解析变更范围（Diff 受影响的审批域 / 操作域） ├─ 列出受影响的现有项目文档（01-Projects/ 下关联的） ├─ 逐项目过合规自检清单（审批角色/金额阈值/流程节点/部门职责） ├─ 发现不一致 → 记录到对应项目的 决策记录.md └─ 修复后更新项目文档 + 标记审视完成10.4 "先查后做"铁律¶
新建或更新任何项目文档前，必须执行以下三步，不可跳步：
① 查 A2：这个业务需要什么审批域？涉及哪些角色/金额阈值/审批链？ ② 查 SOP：这个业务怎么执行？涉及哪些流程/部门/操作标准？ ③ 查岗位对照表：角色名怎么统一？当前谁在位？ → 三个都查了 → 再动笔10.5 合规自检清单¶
每个新建/更新的项目文档在交付前必须自我过一遍：
# 检查项 通过标准 1 文档中的审批角色是否与 A2 定义一致？ 禁用自定义角色名，必须使用 A2 原文 2 金额阈值是否与 A2 一致？ 单位必须为 RMB'000，数值完全匹配 3 审批链顺序是否与 A2 一致？ A→B→C 不能写成 A→C→B 4 流程步骤是否与相关 SOP 描述一致？ 步骤数、参与方、标准均匹配 5 部门职责划分是否与 SOP 一致？ 不出现 SOP 未规定的职责分配 6 操作标准/验收条件是否在 SOP 范围内？ 不高于也不低于 SOP 标准 7 角色名称是否使用岗位对照表中的规范名？ 跨文档角色名一致 8 不确定的内容是否标记了 > [!warning] 待验证？不遗漏任何风险点 10.7 版本审视范围闭环（A2/SOP 更新后的强制动作）¶
A2 和 SOP 不定期发布新版本。每收到一次正式更新通知，必须对重点项目进行重新审视和评估，确保一致性。 不可跳过、不可延迟、不可「等下次更新一起看」。
审视对象 优先级 触发条件 执行方式 S4 HANA 蓝图（权限设计/审批流） 🔴 高 A2 或 SOP 任一更新 Diff 受影响域 → 逐节点自检 TPM 系统设计（纷享销客） 🔴 高 A2 或 SOP 任一更新 Diff 受影响域 → 逐节点自检 纷享销客 DMS 集成接口 🟡 中 A2 审批链变更 确认接口审批角色映射正确 KUBE-OA 审批流配置 🟡 中 A2 更新 确认 OA 审批流与 A2 一致 其他项目文档（如培训材料） 🟢 低 A2/SOP 重大变更 抽查核心章节 审视流程：
收到新版 A2/SOP │ ├─ 确定受影响范围（按审批域/操作域） ├─ 列出关联项目（01-Projects/ 下所有受影响的） ├─ 逐项目过合规自检清单 ├─ 发现不一致 → 记录到对应项目的决策记录.md └─ 修复后更新项目文档 + 标记审视完成10.8 SOP 柔性管理¶
SOP 是业务流程的执行规范，需严格执行，但允许因系统自动化升级而调整：
- 当系统自动化替代了 SOP 中的手工环节 → SOP 需要重写该环节，不能「有系统就绕过 SOP」
- 当 SOP 描述的流程与系统实现不一致 → 判断根因：系统做错了还是 SOP 过时了，分别处理
- 系统上线前 → 必须在 UAT 阶段完成 SOP 修订，确保上线日新版 SOP 和系统同步就绪
- 不存在「系统先上，SOP 以后再补」 — 这是违规行为
10.9 日常微调管理（人与岗位变动）¶
当 A2、SOP 和运营系统均处于相对稳定状态时，团队处理的主要是人员层面的微调（离职、调岗、晋升）。这些变动 不需要触发完整的版本审视机制，但必须有规范的应对方式：
微调类型 对规则的影响 应对动作 轻量程度 人员离职 A2 审批角色仍在，仅占位人缺失 更新岗位对照表「当前在位人」标记为「待确认」→ 通知业务线确认接班人 ✅ 只改人，不改规则 内部调岗 同一角色换人 更新岗位对照表「当前在位人」→ 确认新人的授权范围 ✅ 只改人，不改规则 调岗导致原角色消失 系统内该角色无关联人员 确认 A2 中该角色是否需要重新分配 → 更新对照表 ⚠️ 可能影响审批链 晋升/职责扩大 角色层级不变，人名换 更新对照表即可 ✅ 只改人 岗位合并（降本） 原 A2 角色可能不再对应独立的人 确认该审批节点是取消还是由上级兼任 → 更新对照表 ⚠️ 需审视审批链完整性 换人不改规则： 只要 A2/SOP 的审批角色、金额阈值、链顺序没有变化，仅人员变更 → 不要修改 A2 wiki、不要触发项目文档审视。只需要更新岗位对照表的人名列。
何种情况要升级为完整审视：
人员微调 → 只更新对照表 ✅ │ ├─ 换人后审批链断了吗（上级兼管还是空缺）？ │ ├ 有接班人 → 完毕 ✅ │ └ 未定 → 对照表标记 待确认，下次审视时补 ⏳ │ └─ 人员变动是否同时触发了 A2/SOP 实际更新？ ├ 是 → 走 10.3 完整审视 🔄 └ 否 → 完毕 ✅10.10 数据导入校验（多来源岗位名称联动+人员变动检测）¶
当 OA / A2 / Workday / KUBE-OA 等含岗位名称的数据表导入知识库时，必须联动「岗位名称对照表」进行校验和更新。 这是知识库数据一致性的底线。
步骤 动作 说明 ① 提取新数据中的岗位/角色名称 自动识别所有职位列、审批角色列 ② 比对「岗位名称对照表」 新角色名 → 匹配 IT 规范名称 → 写入对应来源列（OA 写法 / A2 写法等） ③ 标记差异 新名称在对照表中找不到匹配 → 出差异清单，等你确认是补充映射还是数据错误 ④ 人员在位检测 新数据中找不到的「当前在位人」→ 按敏感级别提示（见下方规则） ⑤ 更新对照表 确认后补充新行或修正现有映射 ⑥ 更新导入表 只写数据的来源列，不动 IT 规范名称列和其他来源列 人员变动检测规则（按岗位敏感级别分级提示）：
敏感级别 涉及范围 新数据中找不到该人时 处理流程 🔴 高 中国区核心管理层（20 个角色） 该人不再在职 → 审批链可能断 仅提示：XXX 疑似已离职 → 你人工核实确认 → 你再告诉我结果 → 我更新对照表 🟡 中 业务/职能线（23 个角色） 该人不再在职 → 业务操作节点空缺 仅提示：XXX 疑似已离职 → 你人工核实确认 → 你再告诉我结果 → 我更新对照表 🟢 低 核心管理层+职能线以外的所有人（~590 人） 不在 A2 审批流上 静默更新 — 只改映射表，不弹消息，不做人工确认 核心管理层和职能线均来源于 A2（金光中国审批流基线），A2 约束所有线上/线下系统与流程。因此这两类角色的人员变动必须由你人工校验核实确认后，才更新到知识库。更新后必须触发全盘一致性校验，确保关联页面（岗位对照表/映射表/审批域索引/相关概念页）的数据一致。每笔变动自动追加至 人员变动记录 实体页，支持按人/按角色查询历史。
仅当新导入数据中找不到某人的记录时触发提示。新增人员不做提示（正常入职），仅在出差异报告时列出。此规则仅作用于 OA（来自 Workday 每日同步）等含「当前在位人」的数据导入场景。Workday 是数据源，OA 每日同步，你从 OA 导出即可。
禁止行为： - ❌ 导入时自创角色名，绕过对照表 - ❌ 导入后修改已经确定的来源名称 - ❌ 导入数据中包含非当前版本的旧角色名（必须先确认版本有效性）
两表关系与增量更新规则（⚡ 高优先级约束）：
岗位名称对照表（~232 行，A2 角色定义层）和 关键岗位权限映射表（~635 行，在职人员实例层）有严格的先后关系：
核心原则：增量更新，永不全量覆盖。
岗位名称对照表更新规则：
列 更新策略 说明 IT 规范名称 不动 手动映射，OA 数据不碰这里 各来源写法列（A2/OA/SOP/组织架构） 不动 只有对应来源导入/手动确认时才动 当前在位人 增量更新 逐角色匹配员工号，人和上次一样就跳过，变了才写 新增角色（A2 新增控制点） 手动确认后插入 你明确告知「新增角色」才写 关键岗位权限映射表更新规则：
动作 策略 说明 已有员工（员工号匹配成功） 逐列比对，变了才写 姓名/事业部/公司/部门/职位/上级 六列 OA 来源 → 和上次差异写入 IT规范名称 / A2审批角色 不动 从对照表自动匹配，不因 OA 数据变动而改写 层级 重新计算 根据上级员工号刷新层级树 新增员工（员工号匹配失败） 插入新行 标记为「新导入」，自动参与对照表角色匹配 员工消失（旧名单有，新名单无） 移出活跃区，标注离职日期 核心管理层/职能线走🔴🟡在位检测；其他静默处理 历史数据 保留 不删行，离职人员保留为历史记录，新增状态列标记「在职」/「离职」 每次导入必须输出差异报告（不可省略）：
导入 OA 名单 YYYY-MM-DD（N 人 → M 人） ┌────────────────────────────────────────────────┐ │ 🔴 核心管理层：X 人变动 │ │ [姓名] 疑似离职 / [新姓名] 接任 [角色] │ │ │ │ 🟡 职能线：Y 人变动 │ │ [姓名] 疑似离职 / [新姓名] 接任 [角色] │ │ │ │ 🟢 其他员工：+A 新入, -B 离职（静默处理） │ │ │ │ 映射表数据：C 行 OA 字段变动（部门/职位升迁） │ └────────────────────────────────────────────────┘此规则为高优先级约束。如果在导入过程中发现某人的数据变化但不确认正确（如部门名冲突、职位名异常），必须暂停处理并列出疑点由你判断，不可自动覆盖。
离职员工排除校验规则与配套补偿校验：
标注为离职的员工，不参与任何在职交叉校验（在位检测、审批链完整性检查、A2 角色匹配验证等），避免假阳性/假阴性。但必须配套以下三条补偿校验，防止数据断裂：
# 问题 原因 补偿校验 触发时机 1 A2 角色「在位空缺」被掩盖 离职人的「当前在位人」被清空但无新人补位，角色无人坐但不报错 空缺角色检测：遍历岗位名称对照表，检查「当前在位人」是否为「空缺」→ 输出清单等你手动确认谁来接任 每次导入完成 + 全盘校验 2 在职员工的上级指向已离职人 A离职了，B/C/D的上级员工号仍指向A，层级树断裂但离职人不参与校验所以不报 孤立员工号检测：遍历映射表所有在职员工的「上级员工号」，验证该员工号在活跃区中是否存在。若不存在→输出报告（「XX人的上级员工号 20100350 指向已离职人员，请确认OA数据是否有误」） 每次导入完成后强制触发 3 离职又复职产生重复记录 张三三月离职移出活跃区，七月重新入职→新OA插入新行，库里两个张三 复职合并检测：导入新OA名单时，用「姓名+员工号」双匹配查找历史离职记录。如果匹配成功→恢复为「复职」状态（状态列改回在职，合并历史轨迹，不新增行） 每次导入的匹配阶段 具体流程：
标记离职 → ① 对照表「当前在位人」置为「空缺」 → ② 映射表该人行状态列→「离职」，保留历史 → ③ 孤立员工号检测（在职员工的上司引用） → ④ 空缺角色检测（A2角色无在位人） → ⑤ 输出离职影响报告复职流程：
触发事件：
① 反推 A2（系统 vs A2） │ ├─ 系统内的审批节点是否与 A2 定义的角色一致？ │ （禁用自定义替代角色名） ├─ 金额阈值是否与 A2 一致？ │ （单位 RMB'000，逐线对照） ├─ 审批链顺序是否与 A2 一致？ │ （A→B→C 不可简化为 A→C） └─ 系统能否支撑 A2 要求的审批层级？ （如果 A2 要求三级审批但系统只支持两级 → 系统改）「导入知识库」（丢文件到 Inbox 后说这句话） │ ├─ ① 文件类型判断 │ ├ OA 人员清单 → 比对 OA 写法列 → 更新当前在位人 → 人员在位检测 │ ├ OA 导出（来自 Workday 每日同步）→ 比对 OA 职位名 → 更新 OA 写法列 → 人员在位检测 │ ├ KUBE-OA 审批流 → 提取审批角色 → 比对 A2 写法列 │ └ 新系统/新模块导入 → 先问你要不要新建来源列 │ ├─ ② 差异报告输出 │ 新角色名 vs IT 规范名称 → 逐条列出匹配状态 │ ✅ 匹配成功 / ⚠️ 近似匹配需确认 / ❌ 未匹配需补充 │ └─ ③ 输出更新后的对照表摘要 ### 10.11 违规后果 | 违规行为 | 典型后果 | |:--------|:--------| | 项目文档自定义审批角色名 | 与 A2 脱节，上线后审批跑不通，UAT 返工 | | 项目文档自创审批链 | 越权或漏批，审核不过 | | 新项目不查 SOP 直接设计流程 | 上线后和制度打架，验收不通过 | | A2/SOP 更新后不审视关联项目 | 旧文档和新制度脱节，UAT 才发现 | | 版本审视只做不做记录 | 下次更新无法追溯，重复审视 | ### 10.12 UAT 反推机制（系统上线前必经环节） **任何新系统（S4 模块、TPM/纷享销客、KUBE-OA 审批流等）进入 UAT 阶段时，必须在 sign-off 前完成 A2/SOP 反推检查。** 这不是可选步骤。 **核心原则：A2 刚，SOP 柔。** **时机价值：UAT 反推的关键目的之一，是让项目团队在系统上线前获得充足的缓冲时间，重新撰写或修订 SOP，确保系统上线时新版 SOP 同步发布。** 不存在「系统先上，SOP 以后再补」的情况。UAT 阶段识别出的 SOP 差异 → 立即启动 SOP 更新 → 上线日 SOP 和系统同时就绪。 | 检查方向 | 规则 | A2/SOP 变不变 | 调整方 | |:--------|:----|:-------------|:------| | **系统审批流 → 反推 A2** | A2 是审批底层约束，系统必须严格遵守，**不可讨价还价** | A2 不变 | 系统改 | | **系统操作流程 → 反推 SOP** | 系统自动化可能让原有手工流程/职责/标准不再适用 | SOP 可能因系统流程更新而需对应调整 | 双向调整 | **具体检查项：**② 反推 SOP（系统 vs SOP） │ ├─ 系统实现的操作步骤与 SOP 描述一致吗？ │ （不一致 → 判断是系统做错了还是 SOP 过时了） ├─ 系统自动化替代了 SOP 中手工环节吗？ │ （是 → SOP 需重写该环节） ├─ 系统引入的新职责/操作有对应的 SOP 覆盖吗？ │ （无 → 需新增或补充 SOP） └─ SOP 描述与系统实际行为严重不符吗？ （不符 → 要么改 SOP 追系统，要么改系统追 SOP）
UAT 反推发现不一致 │ ├─ A2 的 → 不改 A2，必须修系统 │ ↓ │ 修系统配置 → 重新 UAT → 确认通过 │ └─ SOP 的 → 判断根因 │ ├─ 系统做得跟 SOP 不一样 → 系统修 ├─ SOP 过时了跟不上系统 → SOP 更新 └─ 两者都要调 → 同步改 ```UAT sign-off 底线： - 🔴 A2 反推未通过 → 不可 sign-off - 🟡 SOP 反推发现不一致但已有整改计划 → 有条件通过，整改期限不超 UAT 窗口 - ✅ 两者均一致 → 可 sign-off
触发规则（最重要）¶
日常对话中，不要主动去动知识库。只有用户明确说出以下关键词时才执行：
写入操作¶
说「写入知识库」「导入知识库」「记入知识库」「更新知识库」「把这个文件放进知识库」时：
→ 检查 00-Inbox/ 下未处理文件：
├─ 仅 1 个 → 直接导入 ✅
├─ 多个 → 列出清单回问你「要导入哪个？」
└─ 无 → 提示「收件箱为空」
→ 执行 Ingest 流程，把资料编译进 _wiki/
读取操作¶
说「查一下知识库」时：
→ 仅检索 _wiki/ 目录下的内容（概念/实体/规则），返回精炼结果
说「结合知识库」「根据知识库回答」时：
→ 检索 _wiki/ + 01-Projects/ + 02-Reference/，结合项目文档和参考资料回答
普通对话¶
没有上述关键词 → 不要读写知识库
来源目录¶
_wiki/ 编译时从以下目录读取原始资料：
00-Inbox/— 微信推入的资料（先判断是否工作相关）01-Projects/S4-HANA/— S/4HANA 升级项目01-Projects/TPM/— TPM 项目02-Reference/Policy_SOP/— 公司制度流程01-Projects/Infra/— 基础设施资料
目录结构¶
| 目录 | 用途 | 操作规则 |
|---|---|---|
concepts/ |
概念页 — SAP 模块、IT 术语、业务概念 | 创建+更新，双链关联相关页面 |
entities/ |
实体页 — 人、公司、系统、工厂 | 创建+更新，标注角色/关系 |
comparisons/ |
比较页 — 系统对比、方案对比 | 持续更新，每篇新资料都可能补充新维度 |
moc/ |
主题地图 — 理解路线图 | 新概念/实体增多时更新索引 |
queries/ |
重要问答沉淀 | 解决重要问题后才创建，不是每次都存 |
drafts/ |
输出草稿 — 报告、方案、文档 | 生产内容时使用 |
页面写作规则¶
- 重要概念必须使用
[[wikilink]]— 没有双链，知识网络形成不了 - 关键结论必须绑定来源 — 标注
Source: [[来源页面]] - 不确定内容标记为
> [!warning] 待验证 - 概念和实体必须分开 — 不要把人名/工具名混进概念页
- 新增页面后更新 index.md
- 每次修改后更新 log.md
- 新页面必须有 frontmatter：
status: 已确认 | 待确认 | 个人阅读 已确认— 你看过内容没问题，可信任待确认— AI 编译的，等你看过再改为已确认个人阅读— 非工作内容，不参与知识库检索
知识编译流程（Ingest）¶
收到"写入/导入"指令后：
1. 读取资料内容，判断是否有价值收录
2. 来自 Inbox 的先过过滤规则（工作相关才进 wiki）
3. 拆出核心概念 → 创建/更新 concepts/ 页面
4. 拆出涉及的人/公司/系统 → 创建/更新 entities/ 页面
5. 如果与已有内容形成对比 → 创建/更新 comparisons/ 页面
6. 相关概念使用 [[wikilink]] 互链
7. 更新 index.md（新增页面加进去）
8. 更新 log.md（记录本次改了什么）
反例黑名单（不要做）¶
触发违规¶
- ❌ 日常对话不要主动读写
_wiki/— 没听到触发词就别动 - ❌ 不要说"我来看看知识库里有没有相关内容"自己动手 — 等用户叫你查
- ❌ 不要自作主张把聊天记录里的结论写进 wiki — 用户说"导入"再动手
内容安全¶
- ❌ 不要修改 raw 原始资料（来源目录的文件只读不写）
- ❌ 不要将非工作内容编译进 wiki — Inbox 里的个人阅读文章标记
status: 个人阅读后跳过 - ❌ 不要随意改变目录结构 — concepts/entities/comparisons/moc 各司其职
写作质量¶
- ❌ 不要创建目录规范外的页面类型 — 每个页面必须属于上述6个目录之一
- ❌ 不要只写正向流程不写失败分支 — 必须写"如果 X 失败→Y"的 fallback
- ❌ 不要使用「建议/可以考虑/根据情况/灵活把握/视情况而定」等模糊词
- ❌ 不要新建页面后不建
[[wikilink]]双链 — 没有双链的页面是孤岛 - ❌ 不要重复建摘要 — 已有概念/实体页时只更新，不另起炉灶
流程规范¶
- ❌ 不要跳过来源标注 — 关键结论必须写
Source: [[来源页面]] - ❌ 不要改完不更新 log.md
- ❌ 不要新增重要页面后不更新 index.md