Xb Stakeholder

---
name: xb-stakeholder
description: 调用受用户配置约束：高自动、中先确认、低须明确开启；用户指定其他技能时禁止接管。分析跨部门与多方协作中的权力、利益、影响、支持和阻力，设计推进顺序。用于跨部门推动、资源争取、多人意见不一、项目政治复杂。触发：$xb-stakeholder、谁会反对、怎么推动跨部门。
---

# xb-stakeholder：利益相关者推进

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

直调契约：还必须读取 `../xbskill/references/resolution-standard.md`；缺失时停止，不得把推进设计写成多方已经行动。

完整读取 `../xbskill/references/context-protocol.md`、`../xbskill/references/contracts.md` 与 `../xbskill/references/intellectual-capabilities.md`。任一文件缺失时，明确报出缺失路径并停止本专科；不得凭记忆补造。公司权责与人物画像是输入证据，不是固定标签；当前项目的新行为可以推翻旧画像。

跨部门问题通常涉及多层归因和实际权力，默认完整读取 `../xbskill/references/people-domain-patterns.md`；仅为已确认单一对象改写一条低风险消息时可不加载并转 `xb-talk`。文件缺失时报告精确路径并停止本专科，不得凭记忆补造模式。

## 触发与权力模型

用户承担对外窗口、内部处理另有负责人的事项时，读取 `references/window-handoff.md`，在现有承诺账区分收悉、接单、处理与验收，并校准内外承诺。文件缺失时报出精确路径并停止受影响分支；保持当前专科，用户自身的处理职责继续保留。

本专科处理“必须由多方共同改变信息、资源、决定或执行，单靠用户无法完成”的 Problem。推进力由以下条件共同形成：`有权决定的人愿意决定 + 有资源执行的人能够承诺 + 承担成本的人能安全表达 + 规则允许承诺被监测和兑现`；关系技巧只能服务这些条件。

四层并查：P 是信息/能力/容量，R 是信任与互惠，F 是依赖/接口/决策流程，I 是权力/激励/实际规则。某人反对不等于人格阻力；先问该方案让其承担什么成本、其是否有权接受、什么流程或激励维持反对。

## 可观察信号词典

| 信号 | 候选模式 | 最小核验 |
|---|---|---|
| 组织图上的决策者总要“再问一个人” | 实际决策链不同（M11） | 最近两次谁实际改变/否决？ |
| 所有人口头支持但无人给资源 | 支持不含承诺 / M05 | 每方具体动作、资源和确认时间 |
| 某部门被称为“总是阻挠” | 成本/激励未显形（M07） | 其指标、风险、所需资源和替代方案 |
| 新增工作稳定落给低权力团队 | 成本下沉 / M02 | 谁受益、谁决定、谁能拒绝？ |
| 正式会上首次出现重大反对 | 预沟通/安全/信息断点 | 反对是否此前有安全表达入口？ |
| “搞定关键人物就行” | 可能绕过合法权责或遗漏受影响者 | 其正式/实际权限与最终使用者 |
| 承诺反复失约但无任何后果 | 监测/激励缺失（M05/M11） | 证据、复核者、升级和改规则权 |
| 只有传闻说某人有影响力 | 未验证人物假设 | 当前项目的一次可核对案例 |

## 思想镜头

每题最多启用 1–2 个镜头；先收集当前项目事实，再形成 `触发证据 → 观察 → 辨别动作 → 产物字段 → 推翻条件`，不作人物扮演或引语。

- 多方立场对撞但可能有可整合利益时，用“利益整合”镜头，写入 `权力/资源`、`表面立场`、`核心利益`、`共同问题`、`整合变量`、`剩余损失`、`同意/升级条件`。存在惩罚风险、不可协商权利冲突或单向转嫁成本时推翻整合路线，不强迫共识。
- 正式权责与实际推进不同、共享资源或申诉机制不清时，用“实际规则”镜头，以近期案例核对 `正式规则`、`实际规则`、`决定权`、`监测/证据`、`申诉`、`改规则权`。连续案例不符或问题只是单一授权关系时更新制度图或停用镜头，不机械搬用治理原则。

## 流程

1. 列出受影响者、正式决策者、实际决策影响者、执行者、否决者、专家、隐性影响者和最终使用者；每个角色标证据来源与日期。
2. 对每人区分公开立场、已证实利益、推测利益、顾虑、权力、信息差和可接受交换；推断必须标注并给验证动作。
3. 画支持度 × 影响力地图，找关键联盟、潜在阻断和被遗漏者。
4. 用最近一次真实资源/排期/审批案例核对正式权责和实际规则；证据不足时先做一次低风险信息核验，不凭职位图猜幕后关系。
5. 设计顺序：先事实核对，再一对一预沟通，再形成方案，最后正式决策；避免公开场合首次暴露重大分歧。
6. 为每方写价值、成本、需要其做的具体动作和不承诺内容；低权力方的安全与底线不作为交换筹码。
7. 设反馈信号和改路条件；不把人标签化为“难搞”。

## 模式与条件分支

1. **信息核验**：决定链或利益未知时，先向项目发起人/正式负责人核对，不公开下注传闻。
2. **双边交换**：两方有可整合利益且能安全表达时，设计新增变量和对等承诺，写清剩余损失。
3. **多方决策**：建立参与、建议、决定、执行、验收和否决链；把不同会议/材料安排到正确节点。
4. **依赖治理**：承诺失约或资源冲突反复时，用 M05/M07/M11 补监测、升级、例外和改规则权，不靠反复催办。
5. **低权力保护**：一方无法安全拒绝、存在报复或基本权利冲突时，停止“共赢”叙事，先边界、证据和正式支持。
6. **无授权推进**：用户只能建议时，产物是地图、提案与请求；不得代替发起人承诺资源、绕过负责人或发布新规则。

## 动作与产物字段

- `角色—权力地图`：人/代号、正式角色、实际作用、决定/否决/资源、证据、日期、置信度。
- `利益—成本账`：公开立场、已证实/推测利益、收益、承担成本、底线、可交换变量、剩余损失。
- `规则图`：正式规则、实际案例、监测、申诉、改规则权、冲突与未知。
- `推进序列`：每一步对象、目的、最小材料、具体请求、成功/失败信号、下一步触发。
- `承诺账`：动作、资源、owner、截止、完成证据、确认状态、未兑现升级。
- `不可承诺清单`：用户无权代表的部门、资源、决定和外发动作。

## 微型分支

- 正例：制度写“部门负责人审批”，但最近两次资源分配均需财务负责人确认；把财务列为“实际关键影响者（两次案例支持）”，先核对约束，再正式提案。
- 证据不足：只听说某人“很有话语权”，先向项目发起人核实该人对本事项的决定/建议权限，不据传闻绕过正式负责人。
- 反例：为了“形成共识”要求资源最少的一方继续承担全部新增成本。
- 边界例：关键方以否决项目威胁用户撤回合规风险。不得寻找“满足双方利益”的包装；保留必要证据，核对有权复核者与安全渠道，用户未授权前不代发指控。

## 验证、失败与翻转

- **假设验证**：每个推测利益或隐性影响者至少对应一次低风险核验；传闻不能升级为事实。
- **推进验证**：真实回应、资源承诺和审批路径是否与地图一致；承诺是否在日期按证据兑现。
- **成功信号**：有权者作出决定、资源 owner 明确承诺、低权力方的新增成本被处理、下一节点可执行。
- **失败信号**：口头支持无动作、幕后否决反复出现、成本继续单向下沉、用户被要求越权承诺、风险上升。
- **翻转条件**：新案例与实际规则不符就更新地图；人物换掉仍同节点失败则转 F/I；改流程后阻力消失则降低人格/关系解释；可信威胁出现则停用整合路线。

## 输出

`人物/权力地图`、`正式规则与实际规则`、`利益与证据/置信度`、`共同问题与剩余损失`、`推进顺序`、`个性化沟通`、`请求动作`、`风险/升级条件`、`镜头链（如启用）`、`现实反馈点`。

只可声明“地图、假设和推进方案已完成”；预沟通、正式决策、资源承诺或落地尚未发生时逐项标注。用各方的真实回应、实际审批路径和承诺是否兑现回流；它们与地图不符时更新角色、规则和顺序。

回流记录 `原地图/模式 → 实际接触顺序 → 各方原意回应 → 决定/资源/承诺兑现 → 用户侧条件变化 → 地图/归因修订 → 下一节点`。只有用户明确授权才把稳定证据写入人物或公司档案；一次项目行为不得固化为人格。