# Xb Role Knowledge

> 调用受用户配置约束：高自动、中先确认、低须明确开启；用户指定其他技能时禁止接管。为 xbskill 补充、校验、匹配并回流岗位专业知识。仅在用户明确要求补充、修订、停用或回测岗位知识，或由已经选定的 xbskill 当前专科作为隐藏支持层解析岗位知识包时使用；普通岗位任务不得把它路由成第二个当前专科，也不用于静态岗位百科。

- Skill: `dennydkt/xb-role-knowledge` (Agent Skill, multi-file: 25 files)
- Install (CLI): `npx skillmds@latest add dennydkt/xb-role-knowledge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dennydkt/xb-role-knowledge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dennydkt (https://skillmd.com/u/dennydkt)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dennydkt/xb-role-knowledge

---


# xbskill 岗位知识补充

调用前先读 `../xbskill/references/interaction-settings.md`，按用户已选调用强度和保存提示执行；明确指定其他技能或拒绝 XB 时退出。未初始化时只允许配置与说明，禁止代选或先执行后确认。

把岗位知识做成会参加当前任务的 `RoleKnowledgeUnit`。运行时返回最小 `RoleKnowledgePacket` 给当前专科；建设时把真实案例、固定来源、边界和现实反馈做成可校验单元。

当前内置目录 2.0.0 含 15 个 active 单元，覆盖数据、产品研发、职能、金融投研、营销五类岗位族；`upstream_sync.py` 能对固定提交、许可、allowlist 与证据坐标做离线校验/在线检查并只生成不可信候选，真正更新仍必须经过单元翻译、四类陌生试跑、独立八门评审和全目录激活门。

直接调用本 Skill 时先读 [../xbskill/references/contracts.md](../xbskill/references/contracts.md)、[../xbskill/references/resolution-standard.md](../xbskill/references/resolution-standard.md) 与 [../xbskill/references/runtime-compatibility.md](../xbskill/references/runtime-compatibility.md)。对象、字段、错误码和持久化约定见 [references/role-knowledge-protocol.md](references/role-knowledge-protocol.md)；内置单元见 [references/builtin-role-knowledge.json](references/builtin-role-knowledge.json)，目录、运行时 Packet/Trace、冻结证据与内置来源注册表结构分别见 [references/role-knowledge.schema.json](references/role-knowledge.schema.json)、[references/role-knowledge-runtime.schema.json](references/role-knowledge-runtime.schema.json)、[references/role-knowledge-evidence.schema.json](references/role-knowledge-evidence.schema.json) 和 [references/builtin-source-registry.schema.json](references/builtin-source-registry.schema.json)。上游仓库固定账及其结构见 [references/upstream-role-sources.json](references/upstream-role-sources.json) 与 [references/upstream-role-sources.schema.json](references/upstream-role-sources.schema.json)。用 [scripts/role_knowledge.py](scripts/role_knowledge.py) 校验和匹配，用 [scripts/upstream_sync.py](scripts/upstream_sync.py) 检查或生成外部候选；不能只凭阅读目录、下载仓库或显示来源名声称知识已参与。

以下命令里的 `<PYTHON3>` 按运行时兼容契约解析为当前平台的 Python 3.10+ 启动命令。契约缺失或解析失败时，报告精确错误并停止脚本操作。

## 触发与核心模型

有两种调用方式：

1. **运行支持**：当前 `xb-*` 专科已经选定，岗位知识会改变本题的专业观察或做法。此时本 Skill 是支持子调用，返回包后结束；当前专科不切换、不让用户重述上下文。
2. **知识补充**：用户明确要新增、修订、失效或回测岗位知识。此时本 Skill 可成为当前专科，完成“缺口—来源—单元—试跑—激活—回流”的建设闭环。

核心链：

`真实岗位任务 → 知识缺口 → 固定证据/案例 → 候选单元 → 匹配试跑 → 独立评审 → 激活 → 当前任务使用 → 现实结果回流 → 修订/失效`

岗位名、企业类别、资历、GitHub stars 或工具功能列表都不能直接生成专业结论。实际责任、当前问题信号、生命周期和证据适用范围共同决定是否命中。

## 可观察信号词典

以下任一信号出现时，检查是否需要岗位知识包：

- 同一个表面任务在不同岗位会有不同责任、失败语义、产物或验收。
- 用户要求“按专业做法”“补充这个岗位的知识”“把这次经验沉淀进去”。
- 通用建议能说通，但无法回答先看什么、怎样区分原因、谁能决定、交付什么、怎样知道现实有效。
- 已有岗位图谱只给检查面，当前任务需要可执行的专业分支。
- 现实结果推翻了已激活单元，或来源、制度、版本、角色边界发生变化。

以下情况不加载：答案简单唯一且岗位不改变动作；只因用户自报职位而展示知识；需要的是本地制度或法律结论但尚无当前真源；单元排除信号已命中。

## 运行支持：让知识参加当前任务

### 1. 建最小请求

从 `RoleContext` 和当前问题建立 JSON 请求，只填已知事实；组织类别不进入专业匹配。最少包含：

```json
{
  "schema_version": 1,
  "current_specialist": "xb-data",
  "job_family": "data",
  "role": "数据工程师",
  "task_family": "数据管道回填",
  "lifecycle_stage": "运行与恢复",
  "proficiency_mode": "S1_working",
  "problem": "任务显示成功，但下游发现重复和漏数，需要安全回填",
  "signals": ["DAG 成功但数据错", "重复", "漏数", "回填"],
  "actual_constraints": [],
  "knowledge_requirement": "required",
  "required_unit_ids": [],
  "max_units": 1
}
```

缺少角色、岗位族或真正会改变匹配的字段时，沿 `role-context-model.md` 每轮只问一个问题；能形成安全的唯一动作就停。

`actual_constraints` 不是自由文本标签。只有项目本地知识需要精确范围匹配时，才放入带证据的对象。`rule_scope.value` 只能是项目单元所绑定 `scope_binding` 的确定性 SHA-256；该对象同时固定项目 ID、packet 文件与摘要、完整权威裁决摘要、claim ID 与完整语义摘要、岗位族、角色、任务族和生命周期，不能手写或只哈希范围名称：

```json
[{"kind":"rule_scope","value":"sha256:<64位小写摘要>","evidence_date":"2026-08-11","evidence_ref":"knowledge/packets/<packet-id>.json"}]
```

`kind` 只能是 `legal_entity / jurisdiction / system_version / rule_scope`。`rule_scope` 同时精确绑定 packet 路径与权威裁决日期；`scope_kind` 固定为 `project_rule`。原始组织标签或其手工摘要没有完整结构绑定，所以“国企、外企、SOE/SOEs、政府部门、某大型国有企业”等类别或同义改写即使漏过友好提示正则，也不能参与岗位知识命中或覆盖。

`init-project` 生成的 `project_scope_id` 绑定项目解析后的绝对根路径；把整个本地目录复制到另一项目也会响亮失败。项目搬迁后必须在新根重新初始化、重新绑定来源包并重跑证据门，不能沿用旧摘要。

### 2. 机械校验与匹配

使用绝对请求路径；不传项目根时只读取随包发布的内置目录：

```text
<PYTHON3> <本Skill绝对路径>/scripts/role_knowledge.py validate
<PYTHON3> <本Skill绝对路径>/scripts/role_knowledge.py resolve --context <绝对request.json> --output <绝对packet.json>
```

只有用户明确给出项目根且希望使用本地增补时才加 `--project-root <绝对项目根>`。显式给了项目根但本地目录未初始化，必须报 `E_PROJECT_UNINITIALIZED`；不能静默回到内置目录并假装加载了本地知识。

### 3. 岗位知识参与闭环

命中后，当前专科必须在内部保留这条追踪链，并以 `verify-trace` 同时读取实际交付物、核对其 SHA-256 与逐字片段、再对当前目录重放后才算已应用：

`unit_id → 本轮新增观察 → 至少两个竞争解释 → 区分动作 → 条件分支 → 产物字段 → 验证 → 现实反馈`

知识只有在至少改变以下一项时才算参加：观察字段、竞争解释、辨别动作、分支、权限边界、动作、产物字段、验收或反馈。Trace 还必须把专业 effect、六项权限、全部风险门和当前阶段适配绑定到交付物中的真实片段，而且每个片段必须逐项包含对应 effect 的原始内容；无关通用段落不能替它作证。六权与风险门以 `RoleKnowledgePacket 1.3` 的固定机器策略为唯一权限真源：AI 只可提出，决定/授权/执行/复核/风险接受由对应人类主体保留；职责原文和风险触发原文都标为 `authority_effect=false`，不能改写机器策略。只在答案末尾列来源、复述岗位常识、填写“result.changed”式形式字段或显示“已加载”均视为未参与。

当前专科消费 `RoleKnowledgePacket.active_injection`，结合本地事实重新推导；不得把单元当万能模板。必须显形采用的 `unit_id`、关键条件和会推翻它的新证据，但不必向用户展示整包 JSON。

```text
<PYTHON3> <本Skill绝对路径>/scripts/role_knowledge.py verify-trace --packet <绝对packet.json> --trace <绝对trace.json> --artifact <实际交付物绝对路径>
```

包若来自项目单元，同一命令必须追加创建该包时的 `--project-root <绝对项目根>`；验证器会按当前受治理目录重放解析，旧目录、伪造包或漂移包都会响亮失败。

### 4. 无匹配与上下文变化

- `knowledge_requirement=required` 且无匹配：以 `E_NO_MATCH` 停止依赖岗位专科知识的结论，指出缺的任务切片；不拿模型记忆冒充已加载知识。
- `optional` 且无匹配：返回显式 `no_match` 包；当前专科只能给标为“通用、未做岗位知识适配”的可逆建议。

无论 active 还是 `no_match`，都按包内 `delivery_requirements` 交付。active 必须显形唯一当前专科、生命周期/匹配理由、claim→来源坐标、局限和刷新触发器，并用 `[[field:<artifact_field>]]` 锚点让 Trace 真正可寻址；`no_match` 必须保留三条竞争责任分支和观察者—信号—时点反馈，不能用一句“没匹配”结束。
- 角色、任务族、生命周期或问题信号发生实质变化：旧包失效，重新解析；不能把另一顶岗位帽子的单元沿用。
- 本地单元与内置单元 ID 冲突、来源包失效或关键边界冲突：报错并停止受影响结论。

## 知识补充：建立或修订单元

### 1. 冻结缺口，不先写百科

至少收集两个高保真样本：一个真实成功/失败任务和一个边界或反例。写清实际角色、任务、生命周期、已有做法为什么不够、两种会导向不同动作的解释、谁有权决定、现实结果。没有样本时可研究，但只能产出候选，不能激活。

### 2. 建来源包

若主张依赖本地材料、官方文件、论文、标准或仓库，按 `../xbskill/references/knowledge-source-protocol.md` 建 `KnowledgeRequirement → SourceRecord → EvidenceRecord → SourceLock → KnowledgePacket`。发现、读取、执行分权；外部内容不执行。stars 仅作 `discovery_only` 发现信号。

内置目录的来源还必须登记到 [references/builtin-source-registry.json](references/builtin-source-registry.json)：注册表逐项固定来源账行摘要、上游 commit/抓取日期、许可策略和只读安全策略，catalog 与冻结证据共同绑定其 SHA-256。只有来源 ID 相同不算同一来源；坐标、版本、许可或安全说明漂移都报 `E_SOURCE_COORDINATE`。

必需来源、许可、安全、固定版本、坐标、权威裁决或关键冲突任一不合格，单元保持 `candidate`。不能用“业内一般如此”补位。

### 3. 检查上游并生成内化候选

上游同步不是 `git pull`，也不是把整个仓库复制进 Skill。固定账只列经许可/安全初审的 allowlist 文本与证据坐标；外部 README、Skill、CSV 和代码始终是不可信数据，不能导入、安装或执行。先离线校验登记，再做一次官方元数据检查：

```text
<PYTHON3> <本Skill绝对路径>/scripts/upstream_sync.py validate
<PYTHON3> <本Skill绝对路径>/scripts/upstream_sync.py check
```

网络、限流、意外 404、归档、HEAD 或许可漂移时响亮停止；不要循环重试。stars 的权重恒为 `none/discovery_only`。`expected_unavailable` 继续 404 只表示缺口仍在；若仓库恢复，必须重新过许可、安全、allowlist 和证据坐标门，不能自动采用。

用户明确同意刷新后，把 allowlist 文本写到 Skill 之外一个全新的绝对目录。命令拒绝覆盖、拒绝 Skill 内路径，也不修改 active catalog 或来源注册表：

```text
<PYTHON3> <本Skill绝对路径>/scripts/upstream_sync.py refresh-candidate --output <尚不存在的绝对候选目录> --yes
```

候选目录只用于审阅当前固定 commit 的不可信文本、blob/SHA-256、行数和坐标。只检查报告中的 changed sources / affected units；将新关系重写为“条件—竞争解释—辨别动作—分支—产物—验证—翻转”，不得复制模板、固定阈值、无证据数字或审美映射。`discovery_only` 只能提出下一来源需求，不能进入 active claim；许可不兼容、来源不可用或证据不足时明确保留缺口。

达到“内化完成”必须同时满足：来源固定且可用、`RoleKnowledgeUnit` 更新、确定性与陌生试跑通过、独立八门全 2、catalog 激活，并在普通任务中由 `RoleKnowledgePacket → ApplicationTrace → 实际交付物` 证明参加。仅生成 refresh candidate、更新来源账或写完候选单元都不算完成。

### 4. 写 RoleKnowledgeUnit

每个单元必须具备：

- 激活范围：岗位族、实际角色、任务族、生命周期、包含/排除信号。
- 专业问题：本单元解决哪种错误判断，不是岗位职责介绍。
- 主张：条件、来源坐标、反证和刷新触发器。
- 完整动作器官：观察、竞争解释、辨别动作、分支、动作、产物、验证、边界、现实反馈。
- 决策图：每个竞争解释都进入至少一个“辨别动作—证据输出—权限—可翻转结果—下一步”图，不能靠分号堆在一个字符串里。
- S0/S1/S2 适配：只改变帮助粒度和用户保留动作，不降低专业正确性与安全线。
- 权限边界：AI、用户、负责人和有权主体分别能做什么；所有精确阈值与组织安排必须有依据或标待校准。

先在项目目录沉淀时，用户明确确认项目根后初始化：

```text
<PYTHON3> <本Skill绝对路径>/scripts/role_knowledge.py init-project --project-root <绝对项目根> --yes
```

该命令只创建标明 `governance_complete=false` 的空候选目录，不表示已经有岗位知识。项目单元写入 `<project>/memory/xbskill/role-knowledge/catalog.json`；`active` 项目单元必须绑定同项目 `<project>/memory/xbskill/knowledge/packets/` 下经验证的 `KnowledgePacket`，同时固定 packet 文件 SHA-256、lock ID/digest、全部 claim ID、authority scope 原文摘要和裁决时间。项目目录、knowledge root、packet 与证据若经 junction/symlink 解析到项目外，必须报 `E_PATH_BOUNDARY`。

若要发布为 xbskill 内置知识，则修改本 Skill 的内置目录与来源账，运行完整套件发布门；不能把某家公司流程、个人信息或内部材料带入公开内置目录。

### 5. 试跑、评审、激活

对每个候选至少做：

1. 正向匹配：该岗位该任务能命中，并改变一条实际动作链。
2. 负向隔离：相似岗位或不相关任务不命中。
3. 阶段分化：S0 与 S2 的帮助方式不同，但权限和验证不缩水。
4. 反例翻转：排除信号或新事实能阻止/推翻单元。
5. 陌生回答者试跑：不读取验收观察；独立评审者按 G/C/A/P/S/E/R/V 八门评分。

修订已发布的内置目录时，先用 [scripts/prepare_candidate.py](scripts/prepare_candidate.py) 生成新候选；它移除旧发布绑定与旧证据引用，绝不复制“已通过”状态：

```text
<PYTHON3> <本Skill绝对路径>/scripts/prepare_candidate.py --catalog <当前内置catalog绝对路径> --output <同目录的新候选绝对路径> --catalog-version <新候选版本>
```

再用 [scripts/deterministic_test.py](scripts/deterministic_test.py) 对候选目录冻结前四类结构与匹配证据；它只在测试进程内把候选视为可匹配，不会改目录状态，也不能替代陌生试跑：

```text
<PYTHON3> <本Skill绝对路径>/scripts/deterministic_test.py --catalog <绝对catalog.json> --output <新的绝对evidence.json> --actor-id <稳定测试者别名>
```

项目候选必须在 deterministic、blind fixture 和 activation 三步都追加同一个 `--project-root <绝对项目根>`；任何一步缺失都停止，不能把本地范围默认为全局。

陌生试跑输入用 [scripts/blind_fixture.py](scripts/blind_fixture.py) 生成；每个需要新证据的单元固定生成 `positive_s0 / positive_s2 / negative / overturn` 四题，其中 S0/S2 使用同一专业事实。文件只含用户题目、目标单元绑定和经候选解析出的运行包，不含 `tests/review` 或评分标准。内容、版本、引用来源行或运行包变化的单元必须生成新文件并换陌生回答者，禁止在旧冻结答案上补写。

八门全部为 2 才可把候选改为 `active`。测试和评审必须写入冻结证据登记，引用具体记录 ID 并校验文件 SHA-256；首次失败、修改原因和冻结重测都要保留。作者补写答案或回答者看到评分标准的轮次不得计入发布证据。

需要合并确定性记录、陌生答案和独立评审时，使用 [scripts/assemble_evidence.py](scripts/assemble_evidence.py)；它会校验三方 case 对齐、Trace、文本摘要和身份分离，任一盲测非全 2 仍会生成失败记录但返回非零，目录不得激活。

只有合并登记全过后，才用 [scripts/activate_catalog.py](scripts/activate_catalog.py) 生成一个新的激活候选文件；它要求四类陌生题八门全 2，精确核对 candidate catalog digest 与每个 `unit_id@version+unit_digest`，拒绝覆盖原文件、拒绝非候选输入，并在写出前按登记摘要重新跑完整激活门。项目目录还必须传 `--project-root`。生成文件仍须经过独立 diff 复核，不能把命令成功等同现实有效。

当一次更新只改变少数单元时，可对 `deterministic_test.py` 与 `blind_fixture.py` 重复传 `--unit-id <changed-id>`，但两者仍用完整候选目录匹配和固定原始目录索引。先按上面的 `assemble_evidence.py` 合并这些变化单元的新证据，再用 [scripts/merge_incremental_evidence.py](scripts/merge_incremental_evidence.py) 复用未变单元的旧冻结记录：

```text
<PYTHON3> <本Skill绝对路径>/scripts/merge_incremental_evidence.py \
  --candidate <完整新候选绝对路径> \
  --previous-catalog <旧 active catalog 绝对路径> \
  --previous-evidence <旧 evidence 绝对路径> \
  --previous-source-registry <旧来源注册表绝对路径> \
  --current-source-registry <新来源注册表绝对路径> \
  --current-evidence <变化单元的新证据绝对路径> \
  --output <新的完整证据绝对路径> --yes
```

复用不是免测：只有 `id + version + reviewable_unit_digest` 完全相同、该单元引用的每条来源记录在新旧注册表逐对象相同、旧四类确定性/答案/全 2 独立评审完整，并能在新完整目录中逐题重放时才允许。旧答案文本、hash、时间和身份原样保留；任一字段漂移即要求该单元重新外测。合并器最后对 15/全部候选重放，不能用差分范围绕过完整激活门。

## 匹配与条件分支

- 默认选一个主单元，最多两个；能覆盖当前瓶颈就不注入岗位全景。
- 实际角色、岗位族与已填写的生命周期是硬门；任务词或问题信号至少命中一项。`required_unit_ids` 只用于调用方已明确知道单元 ID 的情况，仍不能绕过角色、任务/信号、生命周期和排除信号，也不能被 `max_units` 静默截断。
- 项目单元不能用同 ID 覆盖内置单元；修订用新 ID 和 `supersedes`，保留来源、范围与失效条件。
- 企业类别完全不参与专业单元得分。只有 `evidenced` 的组织基因可在专业包形成后调整沟通、授权路径或制品包装，不能改写专业事实。
- 多角色任务一次只按当前责任帽子解析；换帽子即重建请求。

## 微型边界例

**正例**：数据工程师说“DAG 绿但下游重复”。命中管道正确性单元后，当前 `xb-data`/`xb-it` 不再只查任务状态，而会增加部分成功语义、幂等重跑、消费者侧核验与回填/回滚决定包。

**反例**：产品经理只让把已经确认的三句话排成邮件。岗位知识不会改变答案，直接由 `xb-writing` 完成，不加载产品发现单元。

**边界例**：行政用户问某事业单位采购是否必须走特定程序。内置单元只能要求核验实际实体、资金、现行制度和有权者，不能凭“事业单位”给法律结论；缺当前真源时停止正式动作。

## 验证、失败与翻转

交付前检查：

1. 是运行支持还是知识补充？当前专科是否保持唯一？
2. 命中的单元是否实际改变了一条动作链，而非只被引用？
3. 是否保留至少两个竞争解释、一个辨别动作和会翻转判断的证据？
4. 阶段适配是否保留用户判断、验证和授权责任？
5. 本地制度、精确阈值和组织职责是否有当前证据；类别是否只作问题种子？
6. 是否给出当前产物边界与下一现实反馈点，没有把包生成写成现实问题已解决？

`validate`、`resolve`、独立行为试跑任一失败都不得声称知识已激活。来源过期、现实反复证伪、角色边界变化、反指标游戏或验证结果恶化时，将单元降为 `stale`/`rejected`，回到补充流程；不得静默换成模型先验。