# Demand Risk Assessment

> Use when 需要对外包/项目/需求做“接/谈判后接/暂停/拒绝”的风险与收益判断，尤其在范围/验收/付款/合规/工期/依赖不清，或出现应急插队、续约变更、多需求排序、AI/LLM 等高不确定信号时。

- Skill: `starforall/demand-risk-assessment` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add starforall/demand-risk-assessment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/starforall/demand-risk-assessment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: starforall (https://skillmd.com/u/starforall)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/starforall/demand-risk-assessment

---


# 需求风险评估 Skill（v1.0）

## 版本变更（v1.0）

- **第1轮（可用版）模板落地**：在 `0.12` 增加 `0.121` 通用模板，减少“知道要两轮交付但第一轮怎么写”导致的输出漂移。
- **证据锚点标签标准化**：在阶段0与关键表格列名中统一 `证据锚点([直引]/[复述]/[缺口])`，并明确三态写法，降低“引用受限/找不到原文”时的口径分歧。
- **版本历史外移**：主 Skill 仅保留当前版本变更；历史摘要统一放在 README，减少 token 与执行偏移。

## 0) 目标（不要混淆）

本 Skill 只回答三件事，并且必须分别给出理由：
1. **是否可做**：合规可行 + 技术/资源可交付
2. **是否值得做**：价格/收益/机会成本/长期负担综合匹配（含回款/责任风险）
3. **如何做更稳**：合同条款 + 执行流程 + 技术控制 + 止损机制

> 注意：总分只是摘要，不能覆盖单点致命风险（红线/硬门优先）。

---

## 0.15) TL;DR（30秒快速执行）

输出顺序：**先给结论三问 + 承诺门状态**，再给证据与动作（避免“看起来很专业但不可落地”）。

1. 阶段0：结构化抽取 → 关键字段快照 + 信息充分性 `X/8`（见 3 + 3.4）
2. 阶段0.25/0.5：踩坑信号 + 冲突检测（见 4 + 5）
3. 阶段1：红线检查（见 6）→ 命中则 `拒绝/暂停`，不进入完整评分
4. 承诺门（见 2.6 / 附录Q）→ 决定“只能暂停/只能 ROM/可锁里程碑/可锁报价排期”
5. 阶段2：结构化评分（见 7 + 附录A/E/G/H）→ 输出区间 + capping + 置信度
6. 阶段3-6：Pre-mortem → 风险表 → 条款/执行 → 最小补充信息集（见 8-11）

## 0.12) 两轮交付协议（默认：先可用，再展开）

目的：减少“一次性长报告”导致的遗漏与漂移，让用户先拿到可执行结论，再决定是否要展开评分/风险表细节。

默认做法（除非用户明确要求“一次给完整评估”）：
1) **第1轮（可用版）**：只输出 `1.4【概览】` + `【关键字段快照(8项)】` + `【红线检查】` + `【踩坑信号(≤5)】` + `【冲突检测(≤5)】` + `【Top 缺口/假设(3-6)】` + `【需要补充的信息(≤10问)】`。  
2) **第2轮（完整版，可选）**：在信息补齐后再输出 `【评分总览】/【风险登记表】/【谈判条件】/【执行方案】/【ROM】/【拆单】等。

例外（直接做完整版）：
- 用户明确说“请按完整模板输出/给评分表/给 ROM 三情景 + 条款”；或材料已完整（信息充分性 ≥6/8 且冲突可消解）。

### 0.121) 第1轮（可用版）通用模板（建议直接复用）

当用户材料不全、或你尚未完成冲突消解与承诺门判定时，优先用此模板交付“可执行的第一版结论”，并把缺口收敛成 ≤10 个高杠杆问题。

```markdown
## 【概览】（见 1.4，必须先给）
...

## 【关键字段快照（8项）】
...（见 3）

## 【红线检查】
...（见 6）

## 【踩坑信号（≤5）】
...（见 4）

## 【冲突检测（≤5）】
...（见 5）

## 【Top 缺口/关键假设（3-6）】
- ...

## 【需要补充的信息（按优先级，≤10问）】
1) ...（关联维度/为什么会改结论）
```

---

## 0.2) 输入最小集（分层；信息不足默认先补齐）

当用户输入很短、或你发现“关键字段快照”大量缺失时，优先引导用户补齐以下最小信息（能写多少写多少；缺失项会触发 capping/暂停）：

```markdown
【项目/需求名称】：
【场景类型】常规/多需求对比/历史参考/应急/续约变更：
【目标（可验证）】：
【范围边界】in-scope / out-of-scope：（信息充分性 8 项之一）
【交付物清单】代码/文档/部署/培训/源代码归属等：（信息充分性 8 项之一）
【验收口径】验收清单/测试方式/时限/默认通过条件：（信息充分性 8 项之一）
【付款结构】预付款/里程碑/尾款占比/逾期处理：（信息充分性 8 项之一）
【工期与里程碑】用绝对日期时间点（例：2026-03-20 18:00 +08:00 或 Asia/Shanghai）：（信息充分性 8 项之一）
【关键依赖】客户侧账号/接口/数据/白名单/资质与最晚提供时间：（信息充分性 8 项之一）
【数据与合规】涉及的数据类型/授权/留存删除/跨境与共享（如适用）：（信息充分性 8 项之一）
【决策/验收负责人】（信息充分性 8 项之一）：

【预算/报价区间】（如已知）：
【计费口径】固定价/人天/里程碑：
【日费率/人天单价】（如需 ROM 报价/排期，缺省可留空）：

【应急（如适用）】真实 Deadline、可牺牲范围/质量底线、是否接受应急溢价/通道费：
【续约/变更（如适用）】历史履约/遗留债务、历史回款、变更频率与签字机制：
【AI/LLM（如适用）】效果指标与评测集、数据授权边界、成本与延迟预算、供应商与部署、安全与越权：

【保密限制】是否允许在输出中引用原文短句（≤25字）？如不允许：可否提供脱敏短句/字段值以便审计？
```

---

## 0.25) 快速入口（执行顺序：先门后分）

默认按以下顺序执行（即使输出选择“快速分诊”，内部也要跑完“门”）：

1. **场景识别**（见 0.5）
2. **阶段0：结构化抽取 + 信息充分性 X/8**（见 3 + 3.4）
3. **踩坑信号扫描 + 冲突检测**（见 4 + 5）
4. **红线检查（先决）**（见 6）
   - 红线命中（有证据）⇒ 结论只能 `拒绝`，跳过完整评分；只输出“红线证据 + 风险最小集 + 条款/止损建议 + 下一步”
   - 红线要素缺失且无法判断 ⇒ 结论优先 `暂停（补齐前拒绝承诺）`，只输出“缺口 + 最小补充信息集”
5. **仅当未命中红线且信息足够**：进入评分（7）→ Pre-mortem（8）→ 风险登记表（9）→ 决策/谈判/执行（10）→ 最小补充信息集（11）

> 说明：评分只是摘要，任何“门”（红线/硬门/Score Capping/冲突）都可以直接改写结论上限。

---

## 0.3) 适用边界（防止越权与假确定）

- **不替代法律意见**：本 Skill 只做风险框架与条款建议；涉及“责任/赔偿/IP/数据处理/安全义务”等争议时，建议引入法务。
- **不做事实性脑补**：历史参考必须基于用户提供的历史材料；没有材料只能给“可复用模式/建议”。
- **不伪造证据**：任何“证据锚点”必须来自用户原文短引；若用户明确要求“不转贴/不引用原文”，按 `references/评估标准.md` **附录M** 使用 `[复述]` 并强制降置信度，必要时进入 `暂停`。

---

## 0.5) 场景识别（第一优先级）

用户输入后，先识别场景类型：

| 场景 | 触发条件 | 评估重点 |
|------|----------|----------|
| **常规评估** | 单个需求/项目 | 标准全流程 |
| **多需求对比** | "对比A和B"/"哪个更好"/"优先级排序" | 横向对比、差异分析 |
| **历史参考（需用户提供材料）** | "之前那个项目怎么样"/"类似项目参考" | 历史模式匹配、经验复用（不得编造历史结果） |
| **应急需求** | "很急"/"紧急"/"加急"/"明天就要"/"今天" | 应急溢价、通道费、优先级冲突影响（可承受度） |
| **续约/变更** | 命中"续约/变更/迭代/二期" | 历史履约成本、变更漂移评估 |
| **AI/LLM（附加标签，可叠加）** | "大模型/LLM/RAG/微调/Agent/对话/生成式" | 启用附录O专项扫描（效果指标/数据授权/成本与延迟/注入与越权/供应商政策） |

> 说明：AI/LLM 是“附加标签”，可与应急/续约/多需求对比等场景同时成立；评估时在标准流程外叠加附录O的检查与提问。

---

## 1) 输出策略（两档，避免假精确）

### A. 快速分诊（适用：文本很短/信息缺口大/只求"能不能接"）

仅输出（必须先给 `1.4【概览】`）：
- 概览：总体决策 + 三问结论 + 信息充分性/置信度 + 承诺门（含强承诺上限）
- 红线结论（✅/❌/⚠️）+ 证据锚点/缺口
- 踩坑信号命中（若有）
- 3-6 个最高杠杆缺口/冲突
- 最小补充信息集（≤10问）

### B. 完整评估（适用：证据足够或必须做决策/报价谈判）

按本 Skill 全流程输出完整报告。

### C. 多需求对比（适用：需要横向对比2个以上需求）

输出对比矩阵：
- 各需求独立评分
- 维度横向对比
- 优劣势总结
- 推荐建议

建议输出格式（先独立评估，再汇总对比）：
```markdown
## 【多需求对比：结论与排序】
推荐排序: 1) 需求A 2) 需求B 3) 需求C
排序依据: [用1-3条可审计理由说明：红线/硬门/回款结构/范围确定性/工期风险…]

| 需求 | 结论 | 红线/硬门 | 总分(base) | 应急调整分(如有) | 置信度 | 3条关键风险 | 必须谈判条件(Top3) | 下一步 |
|------|------|-----------|------------|------------------|--------|-------------|---------------------|--------|
| A    | ...  | ...       | .../100     | ...              | ...    | ...         | ...                 | ...    |
| B    | ...  | ...       | .../100     | ...              | ...    | ...         | ...                 | ...    |
```

多需求对比的输入规范（信息不足时必须先问清）：
- 每个需求必须有可识别的名称（如“需求A/需求B”或真实项目名）。
- 若用户把多个需求混在一段文字里且无法切分：先要求用户按需求分段提供，或用标题标记边界后再评分（禁止“脑补分段”）。
- 若存在 `暂停`：必须明确“缺口导致无法公平对比”的原因，并给出“最小补充信息集（按优先级）”，补齐后再做排序。

多需求对比的排序规则（默认）：
- 先按结论分桶：`接` > `谈判后接` > `暂停` > `拒绝`
- 同桶内再排序：硬门/红线/Score Capping 触发更少者优先；其次看 `总分(base)` 与置信度（置信度优先于总分）

### D. 历史参考（适用：用户要“类似项目参考/之前项目复盘”）

若用户**未提供**历史材料（评估报告、合同条款、复盘、关键事实）：  
仅输出“可复用的失败模式/高频踩坑信号/建议条款与止损点”，并明确标注：`[历史材料缺失，无法做事实性对照]`。

### E. 暂停（适用：信息不足以做承诺）

当满足以下任一条件时，结论必须允许输出为 `暂停`（不是“拒绝”，也不是“谈判后接”）：
- 红线检查出现 `⚠️ 信息不足需补充` 且该缺口决定是否触红线；
- 信息充分性 `<=4/8`，且用户仍要求你“现在就给接不接”；
- 冲突项密集（见附录I）且无法用现有材料消除；
- 付款结构/验收/范围边界三者任一属于“缺失+不可推断”，导致无法形成可执行条款与止损点。

> 解释口径：`暂停` = “补齐信息前不做交付承诺/不报价锁定/不排期承诺；补齐后再进入完整评估或报价谈判”。

### F. 输出裁剪规则（默认，避免“长但不可用”）

除非用户明确要求“展开细节/附全量表格”，默认按以下上限输出：
- 证据账本：默认只输出“关键字段快照（8项）”；全量账本仅在（多需求对比/冲突密集/用户要求）时输出。
- 踩坑信号扫描：最多 5 条（按对结论影响排序）。
- 冲突检测：最多 5 条（按对结论影响排序）。
- Pre-mortem：3 条即可；每条不超过 6 行。
- 风险登记表：6-10 条；并在表格上方点出优先级 Top3（对应谈判/止损动作）。
- 谈判条件：必须条件 3-7 条，且标注 Top3（最影响结论的三条）。

### G. ROM 报价/排期（可选：用户要“报价/排期/人天”或处于报价谈判）

输出目标：在不确定性尚未消除前，**只给区间 + 假设 + 验证动作**，并把“结论上限/谈判条件”与 ROM 绑定，避免“先口头承诺后被反噬”。

默认规则：
- 先判定承诺门（见 2.6/附录Q）：**ROM 属于 G1**；在未达到 G3 前，禁止“锁报价/锁排期/写死上线时间”。
- 若处于 G0：不输出 ROM，只输出 `暂停` + 最小补充信息集（避免“信息不足但看起来给了报价/排期”）。
- 若信息充分性 `<6/8` 或命中关键冲突/硬门/capping：只输出 **ROM 区间**（不要单点报价/单点排期）。
- ROM 必须显式列出：Top 3-6 个关键假设、对应验证计划、以及“必须谈判条件（Top3）”。
- ROM 的区间边界：用 `best/base/worst` 对齐附录H的三情景口径（且不得绕开附录E硬门）。

ROM 参考口径见 `references/评估标准.md` **附录N**。

---

## 1.4) 输出头部（强制，所有输出都要先给这一段）

目的：让“结论是否一致/是否越权承诺/证据是否可审计”能在 30 秒内复核；也让多需求对比的汇总更稳定。

硬规则：
- 即使 `拒绝/暂停/快速分诊` 早停，也必须输出本段（不然容易漏掉承诺门与三问结论）。
- `信息充分性` 若未计算：写 `-/8（未评估）` 并说明原因（例如：红线早停）。

统一模板：
```markdown
## 【概览】
总体决策: 接/谈判后接/暂停/拒绝
是否可做: 接/谈判后接/暂停/拒绝
是否值得做: 值得做/可做但不值得/暂停/N/A（红线早停）
如何做更稳（一句话）: [条款/流程/技术/止损] 的最高杠杆抓手（1-2条即可）

场景标签: 常规/多需求对比/历史参考/应急/续约变更 + AI/LLM(如适用)
总体置信度: 高/中/低
信息充分性: X/8 或 -/8（未评估）
承诺门: G0/G1/G2/G3（原因摘要）| 强承诺上限: 仅暂停/仅ROM/可锁里程碑/可锁报价排期
```

## 1.5) 最小输出模板（早停也可交付）

> 目的：当触发 `拒绝/暂停/快速分诊` 时，避免输出“只有一句结论”或“长但不可执行”的报告。

### T1 拒绝（红线命中）

```markdown
## 【概览】
总体决策: 拒绝
是否可做: 拒绝（红线）
是否值得做: N/A（红线早停）
如何做更稳（一句话）: 给出不触红线的替代路径/合规流程建议（不提供越权实现细节）
场景标签: ...
总体置信度: 中/高（红线证据明确时可高；引用受限或关键要素缺失时降为中/低）
信息充分性: -/8（红线早停）
承诺门: G0（红线）| 强承诺上限: 仅拒绝/仅暂停

## 【红线证据】
- [红线项]: 证据锚点（原文短引）

## 【风险最小集（不展开长报告）】
- 主要风险: ...
- 影响: legal/reputation/…（1句）

## 【下一步（若仍要推进）】
1) 需要用户补充/澄清: ...（缺口）
2) 或者：改造方案/替代路径（不触红线）: ...
```

### T2 暂停（补齐信息后再评估；补齐前拒绝承诺）

```markdown
## 【概览】
总体决策: 暂停（补齐前拒绝承诺）
是否可做: 暂停
是否值得做: 暂停
如何做更稳（一句话）: 先把范围/验收/付款/依赖字段化并形成书面确认，再进入评估/报价谈判
场景标签: ...
总体置信度: 低/中
信息充分性: X/8
承诺门: G0（原因摘要）| 强承诺上限: 仅暂停/仅补齐信息后再评估

## 【关键缺口/冲突（Top 3-6）】
- 缺口/冲突: ...（影响：哪些维度/结论上限）

## 【需要补充的信息（按优先级，≤10问）】
1) ...（关联维度/为什么会改结论）
```

### T3 快速分诊（非红线，但缺口大/只求“能不能接”）

```markdown
## 【概览】
总体决策: 接/谈判后接/暂停/拒绝（快速分诊）
是否可做: 接/谈判后接/暂停/拒绝
是否值得做: 值得做/可做但不值得/暂停
如何做更稳（一句话）: ...
场景标签: ...
总体置信度: 低/中
信息充分性: X/8
承诺门: G0/G1（原因摘要）| 强承诺上限: 仅暂停/仅ROM

红线: ✅/❌/⚠️（见【红线检查】或在此处给出 1 行结论+证据/缺口）

## 【踩坑信号（最多5条）】
- 命中: ...（证据锚点）→ 影响

## 【最高杠杆缺口/冲突（3-6条）】
- ...

## 【下一步：最小补充信息集（≤10问）】
1) ...
```

---

## 2) 强制规则（提高准确性，违者视为未完成）

1. **禁止伪造引文**：任何"证据锚点"必须来自用户原文短引；若用户要求不转贴原文，按 `references/评估标准.md` **附录M** 使用 `[复述]` 并显式标注“引用受限”。找不到就写：`[未找到原文证据]`。
2. **冲突优先**：出现关键冲突时，相关维度不得给 4-5 分，总体置信度通常不得为"高"。
3. **缺口触发上限（Score Capping）**：严格按 `references/评估标准.md` 附录E执行，并在报告中**列出触发项**。
4. **非线性决策门优先于总分**：严格按附录E"硬门"，并在报告中**列出触发的门**。
5. **先止损后乐观**：best/worst 情景只能建立在"关键假设已明示"的前提下，且不得绕过 capping/硬门。
6. **评分口径必须一致**：维度评分统一为 **0-5**；总分统一为 **/100**（公式见附录H）。任何表格必须显式标注单位。
7. **历史参考不允许“脑补结局”**：除非用户提供历史评估报告/项目复盘/关键事实，否则只能输出“可复用的风险模式/条款建议”，不得断言“当时发生了什么/结果如何”。
8. **多需求对比先独立、后对比**：每个需求必须先按同一口径完成“红线/踩坑/冲突/评分/Pre-mortem/风险表”，再输出横向差异与推荐排序（不得只给一个合并总分）。
9. **结论必须拆分三问**：最终输出必须分别给出“是否可做 / 是否值得做 / 如何做更稳”，并映射到证据/缺口/冲突与条款动作。
10. **结论集合必须包含暂停**：当触发“信息不足/关键红线缺口/冲突不可消解”时，必须允许输出 `暂停`，不得硬给分或硬选“接/谈判后接/拒绝”。
11. **时间必须可审计**：遇到“明天/下周/尽快/越快越好”等表述，必须转写为绝对时间点（含时区）；无法转写时，视为关键缺口并下调置信度/触发暂停或 capping（尤其影响工期可行性与应急识别）。
12. **报价/排期不许假精确**：当用户要求“报价/排期/人天”时，默认输出 ROM 区间（附录N）；若信息充分性 < 6/8 或触发关键 capping/冲突，则禁止给“单点报价/锁排期承诺”，只能给“区间 + 假设 + 必须谈判条件 + 验证计划”。
13. **best/worst 必须可验证**：只要给出 best/worst 或“如果…就…”的情景推演，必须同步给出“验证计划（Top 3-6）”，把关键假设变成可执行验证动作（附录N）。
14. **AI/LLM 触发专项扫描**：命中“大模型/LLM/RAG/微调/Agent/对话/生成式”等关键词时，必须叠加附录O的红线/踩坑/问题与条款；若效果指标/评测集/数据授权/成本与延迟任一无法字段化，结论优先 `暂停` 或最多 `谈判后接`（禁止硬承诺效果）。
15. **安全与运维不许缺席**：需求涉及对公网、登录鉴权、支付、个人信息/敏感信息、对外 API、AI/LLM 工具调用/数据回流等时，必须至少按 `references/评估标准.md` 附录P补问“最小安全/运维基线”，缺口必须进入风险登记表并影响结论上限/谈判条件（不要只写一句“注意安全”）。
16. **高不确定性默认拆单**：当信息充分性 `<6/8`、或关键假设 ≥ 3、或 ROM 被标注为“仅供探索”时，默认建议“Phase 0（验证/Discovery）→ Phase 1（交付）”的阶段化交付，并把 Phase 0 作为前置里程碑与付款/验收节点（见 10.6）。
17. **承诺门必须显式给出**：当用户要求“锁报价/锁排期/强承诺效果/签字背书”时，必须输出 `承诺门: G0~G3`（见 2.6/附录Q），并明确“允许承诺的上限”（例如：仅 ROM/不可锁排期/不可承诺效果）。
18. **敏感信息最小披露**：证据锚点与示例中若包含手机号/邮箱/身份证/银行卡/客户全名/具体地址/账号/密钥/token/私有链接等，必须用占位符脱敏（例：`[客户A]`、`[金额X]`、`[Token已省略]`），仅保留能支撑判断的最小信息。
19. **分数→结论映射仅作摘要**：若需要用“分数区间”辅助摘要结论，按 `references/评估标准.md` 附录N3；但任何红线/硬门/capping/冲突都优先于分数。

---

## 2.5) 决策算法（先门后分，避免总分掩盖致命风险）

按以下顺序给结论（并在报告中明确命中项）：
1. **红线（附录B）**：若有明确证据命中 ⇒ `拒绝`；若关键红线要素缺失导致无法判断 ⇒ `暂停（补齐前拒绝承诺）`。
2. **Score Capping + 冲突（附录E/I）**：触发项 ⇒ 对相关维度执行上限；总体置信度按附录G下调。
3. **非线性决策门（附录E）**：任一命中 ⇒ 结论最多 `谈判后接`（或 `拒绝`），不得“接”。
4. **再看总分与区间（附录H）**：总分只作为摘要；推荐建议必须回扣到（红线/硬门/风险登记表/谈判条件）。

> 说明：当“门”与“分”冲突时，以“门”为准。

## 2.6) 承诺门（Commitment Gates：决定你能承诺到什么程度）

目的：把“接/报价/排期/效果”这类**强承诺**，收敛为可审计门槛；在证据不足时默认降档为 `暂停` 或 `ROM 区间`，避免单点承诺反噬。

### G0-G3（从低到高）

- **G0：暂停门**（默认保守）  
  触发：红线 `⚠️` 且关键要素缺失、信息充分性 `<=4/8`、或范围/验收/付款任一“缺失+不可推断”。  
  允许输出：`暂停`（或红线明确则 `拒绝`）+ 最小补充信息集。  
  禁止：报价/锁排期/承诺上线时间/承诺效果。

- **G1：ROM 门（仅供探索）**  
  触发：未命中红线，且信息充分性 `>=5/8`；允许用“关键假设 + 验证计划”形成 ROM。  
  允许输出：ROM 区间（附录N）+ 必须谈判条件(Top3) + 验证计划（Top 3-6）。  
  禁止：单点报价、锁排期、对效果做强承诺（尤其 AI/LLM）。

- **G2：可谈判承诺门（可锁里程碑，但仍禁止强承诺）**  
  触发：信息充分性 `>=6/8`，且范围/验收/付款/依赖能字段化；硬门/冲突有明确条款兜底。  
  允许输出：阶段化交付（10.6）+ 里程碑/验收/付款建议；可给“条件式排期/报价区间”（以条款与依赖为前置条件）。  
  禁止：在合同/依赖未落地前“锁死排期与单点报价”；禁止承诺 AI/LLM 绝对效果。

- **G3：强承诺门（可锁报价/排期，但仍需写明边界）**  
  触发：G2 条件满足，且关键条款已书面化（合同/订单/邮件确认）、关键依赖与验收环境可获得、责任边界与止损机制可执行。  
  允许输出：在明确边界/假设/变更机制前提下，可锁报价与排期（仍建议保留缓冲与变更条款）。  
  仍禁止：承诺“100% 无错/效果必达/无限责任”等不可控结果；AI/LLM 只能承诺“评测口径+阈值+灰度与回滚”。

### 输出要求（强制）

- 在完整评估的 `【评分总览】` 中增加一行：`承诺门: Gx（原因摘要）| 强承诺上限: ...`
- 当用户明确要求“今天就定死报价/排期/效果”时，先给承诺门结论，再给 ROM/缺口与下一步（不要先算分）。

## 3) 阶段0：结构化抽取 + 证据账本（必须先做）

把需求文本抽取为字段，并为每个字段记录：
- 状态：`明确 / 暗示(假设) / 缺失 / 冲突`
- 证据锚点：1-3 条原文短引；若用户要求不转贴原文，按 `references/评估标准.md` **附录M** 使用 `[复述]`（并显式标注“引用受限”）
- 备注：如果是"暗示"，必须写"关键假设"

证据锚点三态（统一写法，降低口径漂移）：
- `[直引] "..."`：用户原文短引或用户提供的脱敏短引（若含敏感字段先按附录M脱敏）
- `[复述] ...（引用受限）`：用户不允许贴原文，但提供了字段化事实/可审计概述
- `[缺口] ...`：需要证据但用户材料中未找到（必须影响置信度/触发 capping/触发暂停门之一）

强制要求：
- **先完成全量证据账本（内部步骤）**：用于后续评分、capping、冲突与提问；避免“凭感觉给分”。
- **默认只对外输出关键字段快照**：除非用户要求或需要做多需求对比/冲突溯源，否则不展开全量账本。

默认输出（关键字段快照，8项）：
```markdown
## 【关键字段快照】
| 关键字段 | 状态(明确/暗示/缺失/冲突) | 证据锚点([直引]/[复述]/[缺口]) | 关键假设/缺口备注 |
|----------|---------------------------|--------------------|------------------|
| 范围边界 | ... | ... | ... |
| 交付物清单 | ... | ... | ... |
| 验收口径 | ... | ... | ... |
| 付款结构 | ... | ... | ... |
| 工期/里程碑 | ... | ... | ... |
| 关键依赖 | ... | ... | ... |
| 数据合规要点 | ... | ... | ... |
| 决策/验收负责人 | ... | ... | ... |
```

按需展开（全量证据账本）：
```markdown
## 【证据账本（结构化抽取）】
| 字段 | 状态(明确/暗示/缺失/冲突) | 证据锚点([直引]/[复述]/[缺口]) | 关键假设(如有) | 缺口/冲突备注 |
|------|---------------------------|--------------------|----------------|--------------|
| 背景 | ... | ... | ... | ... |
| 目标 | ... | ... | ... | ... |
| 范围 | ... | ... | ... | ... |
| 交付物 | ... | ... | ... | ... |
| 验收 | ... | ... | ... | ... |
| ... | ... | ... | ... | ... |
```

### 3.1 标准字段（尽量覆盖）
- 背景：现状痛点与驱动
- 目标：业务目标/成功指标（可验证）
- 范围：in-scope / out-of-scope（边界）
- 交付物：代码/文档/部署/培训/源代码归属等
- 验收：验收标准 + 流程 + 时限 + 默认通过条件
- 非功能需求：安全/性能/可用性/合规/可观测性/兼容性（对公网/敏感数据/对外API时，按 `references/评估标准.md` 附录P补问最小基线）
- 数据与合规：数据类型/敏感级别/来源授权/留存删除/跨境与共享
- 依赖与集成：第三方API/内部系统/客户侧输入/账号资质
- 干系人与决策：决策人、owner、验收负责人、反馈链路
- 计划与资源：里程碑、关键日期、客户配合事项、己方资源约束
- 商业与合同：预算、付款节点、变更机制、维保范围、SLA（如有）
- 责任与边界：责任上限、赔偿范围、保密、安全义务、争议解决

### 3.2 续约/变更专用字段（输入命中"续约/变更/迭代/二期"时必须补抽）
- 历史履约：过去延期/返工/扯皮点、已知遗留缺陷/技术债
- 现状成本：支持/运维/应急投入（人天/频率）
- 回款与信用：未结款、历史逾期、主体变化
- 变更历史：范围漂移次数、是否有变更单与签字、是否频繁插单
- 资产与产权：现有代码/文档归属、第三方依赖与许可证、素材授权

### 3.3 应急需求专用字段（输入命中"紧急/加急/很急/插队/今天/明天/48小时/来不及走流程"等硬信号时必须补抽）
- 真实Deadline：客户声称的截止日期 vs 实际可执行窗口
- 优先级冲突影响：插队对现有项目的影响（延期、资源抢占、质量下降），并在评分时换算为“优先级冲突可承受度”(A6)
- 应急溢价：是否包含加急费用、是否需要调动额外资源
- 通道费：是否需要占用"紧急通道"、是否有额外沟通成本
- 质量牺牲度：可以牺牲哪些质量/功能来换取时间
- 验收风险：应急模式下验收扯皮概率上升

### 3.4 信息充分性快检（防止"看起来很专业但不可靠"）

对以下"关键字段"做是否有**明确证据**的计数：
- 范围边界、交付物清单、验收口径、付款结构、工期/里程碑、关键依赖、数据合规要点、决策/验收负责人

输出：
- `信息充分性: X/8`
- 若 `<=4/8`：默认走"快速分诊"并优先给出 `暂停`（除非用户明确表示“只是探索，不做承诺/不报价/不排期”）；完整评估中总体置信度不得为"高"。

---

## 4) 阶段0.25：踩坑信号扫描（必须）

使用 `references/评估标准.md` 附录C，做两件事：
1. 列出命中的原文短句（证据锚点）
2. 声明它会影响哪些维度/结论倾向（至少：置信度下调、进入风险登记表）

> 规则：命中项必须进入"风险登记表"，并至少影响置信度或触发谈判条件（不要只当作"吐槽"）。

输出格式：
```markdown
## 【踩坑信号扫描】
- 命中: [话术/信号] - 证据锚点 - 影响
```

---

## 5) 阶段0.5：冲突检测（必须）

按 `references/评估标准.md` 附录I 检测关键冲突，输出命中项清单与证据锚点，并声明影响：
- 影响哪些维度评分上限/置信度
- 是否触发"谈判后接/拒绝"的倾向

---

## 6) 阶段1：红线检查（先决条件）

使用 `references/评估标准.md` 附录B。
任一命中：结论只能是 **拒绝** 或 **暂停（信息不足，补齐前拒绝承诺）**。

输出格式：
```markdown
## 【红线检查】
✅ 通过 / ❌ 不通过 / ⚠️ 信息不足需补充
- [检查项]: 通过/不通过/不足 - 证据锚点或缺口
```

---

## 7) 阶段2：结构化评分（证据 + 置信度 + 三情景）

维度与权重按 `references/评估标准.md` 附录A；计算公式按附录H。

### 7.0 口径澄清（避免应急场景“算分漂移”）

- **base 总分(/100)**：仅使用 A1-A5（权重合计=100）。
- **应急调整分**：仅在识别为“应急需求”时计算，范围 `-5 ~ +15`（公式见 `references/评估标准.md` 附录H）。
- **应急总分**：`base 总分 + 应急调整分`（可在报告中同时展示“应急调整分”与“应急总分(是否封顶)”）。

### 7.1 评分输出必须额外包含两项（可审计性）
- **触发的 Score Capping**：逐条列出（来自附录E）
- **触发的非线性决策门**：逐条列出（来自附录E）

### 7.2 分值口径（必须显式写清）
- `维度得分`：0-5
- `贡献分`：换算到 /100（例如 A1 合规风险：`30 * 4/5 = 24`）

### 7.3 输出格式
```markdown
## 【评分总览】
总分(base): XX/100 | 区间(best~worst): AA~BB/100 | 总体置信度: 高/中/低
信息充分性: X/8
承诺门: G0/G1/G2/G3（原因摘要）| 强承诺上限: 仅暂停/仅ROM/可锁里程碑/可锁报价排期
[应急评估]: 是/否
- 若是：应急调整分: (+/-)N（-5~+15）| 应急总分: ZZ/100（可注明是否封顶）| 应急溢价: X% | 优先级冲突可承受度: 低/中/高（越高越能插队） | 质量牺牲度: 0-5（越高越糟）

触发的 Score Capping:
- ...

触发的非线性决策门:
- ...

| 维度(权重) | 维度得分(base/best/worst, 0-5) | 贡献分(base, /100) | 置信度 | 证据/缺口/冲突 | 关键假设 |
|------------|---------------------------------|--------------------|--------|----------------|----------|
| 合规风险(30) | x/x/x | yy.y | ... | ... | ... |
| 可交付性(20) | x/x/x | yy.y | ... | ... | ... |
| 工期可行性(20) | x/x/x | yy.y | ... | ... | ... |
| 价格与收益匹配(20) | x/x/x | yy.y | ... | ... | ... |
| 协作与沟通风险(10) | x/x/x | yy.y | ... | ... | ... |
| [应急]优先级冲突可承受度(+10) | x/x/x | yy.y | ... | ... | ... |
| [应急]应急溢价覆盖(+5) | x/x/x | yy.y | ... | ... | ... |
| [应急]质量牺牲度(-5, 惩罚项) | x/x/x | yy.y | ... | ... | ... |
```

### 7.4 应急需求评分补充（应急场景额外评分项）

当识别为应急需求时，增加以下评分项：

| 额外维度 | 权重 | 评分说明 |
|----------|------|----------|
| 优先级冲突可承受度 | +10 | 插队对现有项目的冲击**可承受程度**，0-5分（越高越可承受） |
| 应急溢价覆盖 | +5 | 加急费用是否cover额外成本，0-5分 |
| 质量牺牲度 | -5 | **惩罚项**：牺牲越大分越高，0-5分（反向，0最好） |

> 注：应急“通道费/插队成本”应优先通过 **应急溢价** 与 **里程碑/变更/验收条款** 来覆盖，而不是用“主观抬分”绕开红线、硬门与 capping。

---

## 8) 阶段3：Pre-mortem（失败链路 + 交互项）

至少输出 3 条"最可能失败链路"，并强制包含：
- 触发条件 / 放大机制 / 损失形态
- 早期信号（可观测）
- 止损点（可量化）
- 监控与责任（频率 + 责任方）
- 预防动作（合同/流程/技术）

> 额外要求：至少指出 1-2 个"交互风险"（例如：验收不清 + 尾款过大 + 工期极短 会把延期直接变成坏账/扯皮）。

---

## 9) 阶段4：风险登记表（让建议可落地）

输出 6-10 条真正"会改变结论或条款"的风险项，用表格收敛：
- 风险陈述（不要抽象词）
- 影响（schedule/cost/quality/legal/reputation）
- 概率（1-5）与影响等级（1-5），用于排序（**不参与总分**）
- 触发条件 & 早期信号
- 预防/缓解（合同/流程/技术）
- 止损/退出条件（Kill Criteria）
- 风险归属（当前谁承担？如何转移/共享？）
- 风险责任人/责任方（谁来盯、谁来做）
- 证据/缺口/冲突（含踩坑信号/冲突命中）

示例格式：
```markdown
## 【风险登记表】
| 风险 | 影响类型 | 概率(1-5) | 影响(1-5) | 优先级(P*I) | 触发条件/早期信号 | 缓解动作 | Kill Criteria | 风险归属 | 责任方 | 证据/缺口 |
|------|----------|-----------|-----------|--------------|-------------------|----------|--------------|----------|--------|----------|
| ...  | ...      | ...       | ...       | ...          | ...               | ...      | ...          | ...      | ...    | ...      |
```

建议口径（便于快速一致）：
- 概率 1-5：1=很少发生；3=可能发生；5=几乎必然发生
- 影响 1-5：1=可忽略；3=需要额外人天/延期但可控；5=重大损失/法律或声誉事故

---

## 10) 阶段5：决策 + 谈判条件 + 执行方案

### 10.1 结论（四选一）
- **接**
- **谈判后接（必须条件清单）**
- **拒绝**
- **暂停（补齐信息后再评估，补齐前拒绝承诺）**

结论必须与：红线、capping、硬门、风险归属一致。

`暂停` 的典型触发：
- 红线检查属于 `⚠️ 信息不足需补充`，且该缺口决定是否触红线；
- 信息充分性不足（<=4/8）且缺口集中在验收/付款/范围/数据合规/关键依赖；
- 冲突项无法用现有材料消解（附录I）。

### 10.2 谈判条件（必须可验证、可执行）

使用 `references/评估标准.md` 附录D，只选与阶段3/4强相关的条件。
并强制写明：每条条件对应哪个"失败链路/风险项"。

> 提示：若出现"责任/赔偿/IP/数据处理/安全义务"等法律条款争议，建议引入法务审阅（本 Skill 提供风险框架，不替代法律意见）。

### 10.3 执行方案（把风险变成计划）

至少包含：
- 范围收敛与冻结点（何时冻结、变更怎么收费）
- 里程碑与验收节奏（验收窗口与默认通过）
- 客户侧依赖交付清单（谁/何时/格式）
- 质量与安全底线（最低可观测/备份/权限等）
- 止损触发器（逾期付款、变更超限、依赖不可用等）

### 10.4 ROM 报价与排期（可选：用户明确要求或处于报价谈判）

输出要求：
- 默认输出 `best/base/worst` 的 **区间**（不要单点）。
- 每个区间必须绑定：关键假设（≤6条）+ 必须谈判条件（Top3）+ 验证计划（Top 3-6）。
- 若信息充分性 < 6/8 或触发关键硬门/冲突/capping：明确写 `ROM 仅供探索，不可用于锁报价/锁排期`。

口径与公式见 `references/评估标准.md` **附录N**。

### 10.5 验证计划（可选但强烈推荐：把关键假设变成可执行验证）

当存在以下任一情况时，必须输出验证计划：
- 你给了 best/worst 情景；
- 关键假设 ≥ 3 条；
- 用户要求“现在就报价/锁排期”，但信息充分性不足或冲突未消解。

建议格式：
```markdown
## 【验证计划（Top 3-6）】
| 假设/不确定点 | 验证方式（POC/Spike/样本数据/接口联调） | 通过标准（可验收） | 责任方 | 截止时间 |
|--------------|----------------------------------------|-------------------|--------|----------|
| ...          | ...                                    | ...               | ...    | ...      |
```

### 10.6 阶段化交付/拆单建议（可选但强烈推荐：把不确定性变成里程碑）

适用：信息不足/关键假设较多/客户希望你“现在就锁报价或锁排期”。

目标：把“验证计划”变成**可谈判的合同与付款节点**，避免一次性背全量交付风险。

建议输出格式：
```markdown
## 【阶段化交付/拆单建议】
Phase 0（验证/Discovery，先把关键假设打穿）:
- 目标: ...
- 交付物: POC/Spike/样本数据验证报告 + 明确范围边界 + 验收草案 + ROM 区间收敛
- 验收口径: ...（可验证）
- 工期: ...（区间） | 费用/计费口径: ...
- 关键止损点: ...（未达标则可终止/不进入 Phase 1）

Phase 1（交付）:
- 目标: ...
- 交付物: ...（按冻结范围）
- 里程碑与付款: 预付款/里程碑/尾款（尾款≤30%）+ 验收窗口 + 逾期默认通过
```

---

## 11) 阶段6：最小补充信息集（高杠杆提问）

输出 5-12 个问题即可，按"改变结论的可能性"排序。
每个问题必须标注：
- 关联维度/风险项
- 为什么会改变结论（1句）

优先从 `references/评估标准.md` 的 **附录L：最小补充信息问题库** 选取/改写问题，再结合当前缺口做裁剪。

---

# 最终输出模板（统一）

```markdown
# 需求风险评估报告

## 【概览】
总体决策: 接/谈判后接/暂停/拒绝
是否可做: 接/谈判后接/暂停/拒绝
是否值得做: 值得做/可做但不值得/暂停/N/A（红线早停）
如何做更稳（一句话）: ...
场景标签: ...
总体置信度: 高/中/低
信息充分性: X/8 或 -/8（未评估）
承诺门: G0/G1/G2/G3（原因摘要）| 强承诺上限: 仅暂停/仅ROM/可锁里程碑/可锁报价排期

理由(1-3条，必须可审计): ...（映射到红线/硬门/冲突/付款与验收/关键依赖）

## 【关键字段快照（可选）】
| 关键字段 | 状态(明确/暗示/缺失/冲突) | 证据锚点([直引]/[复述]/[缺口]) | 关键假设/缺口备注 |
|----------|---------------------------|--------------------|------------------|
| 范围边界 | ... | ... | ... |
| 交付物清单 | ... | ... | ... |
| 验收口径 | ... | ... | ... |
| 付款结构 | ... | ... | ... |
| 工期/里程碑 | ... | ... | ... |
| 关键依赖 | ... | ... | ... |
| 数据合规要点 | ... | ... | ... |
| 决策/验收负责人 | ... | ... | ... |

## 【红线检查】
...

## 【踩坑信号扫描】
...

## 【冲突检测】
- 命中项: ...（证据锚点）
- 影响: ...

## 【关键假设清单】
- 假设1: ...（若不成立会如何影响结论/分数/条款）
- 假设2: ...

## 【验证计划（Top 3-6，可选但强烈推荐）】
| 假设/不确定点 | 验证方式（POC/Spike/样本数据/接口联调） | 通过标准（可验收） | 责任方 | 截止时间 |
|--------------|----------------------------------------|-------------------|--------|----------|
| ...          | ...                                    | ...               | ...    | ...      |

## 【评分总览】
...（含分值口径、触发的 Score Capping 与非线性决策门）

## 【ROM 报价与排期（可选）】
口径: best/base/worst（区间，不给单点承诺）
...

## 【阶段化交付/拆单建议（可选但推荐）】
Phase 0（验证/Discovery）: ...
Phase 1（交付）: ...

## 【Pre-mortem：最可能的失败链路】
1. ...
2. ...
3. ...

## 【风险登记表】
...

## 【谈判条件（必须达成）】
- [ ] 条件 ...（映射：失败链路/风险项）
- [ ] ...

## 【执行方案（把风险变成动作）】
- 范围与冻结: ...
- 里程碑与验收: ...
- 依赖与责任: ...
- 技术底线: ...
- 止损触发: ...

## 【需要补充的信息（按优先级）】
1. ...
```

---

## 常见失败模式（必须避免）

1. **单点总分掩盖红线**：始终执行阶段1 + 附录E非线性门
2. **证据缺失还给高分**：执行 Score Capping + 低置信度 + 提问
3. **只列风险不落动作**：每个风险必须映射到合同/流程/技术控制
4. **结论不一致**：结论必须与门、付款、验收、责任/风险归属一致
5. **忽略冲突/踩坑信号**：阶段0.25/0.5命中项必须体现在评分、置信度与结论中
6. **伪造引文**：必须使用用户原文，没有就写`[未找到原文证据]`
7. **应急场景漏评估**：识别到应急需求但未执行应急评分逻辑
8. **多需求对比不做横向分析**：只分别评估，未做维度对比
9. **报价/排期假精确**：信息不足还给单点报价/锁排期；应输出 ROM 区间 + 假设 + 验证计划
10. **best/worst 无验证抓手**：情景推演未给验证计划，导致建议不可落地
11. **高不确定性不拆单**：关键假设多/信息不足仍一次性承诺全量交付；应输出 Phase 0→Phase 1 的阶段化交付建议（见 10.6）
12. **安全/运维留白**：对公网/敏感数据场景未补问最小安全/运维基线，导致上线事故或责任失控（附录P）

---

## 触发场景

- 用户发送 PRD/会议纪要/聊天记录/邮件
- 用户问"这个需求能不能接/要不要立项/有什么风险/要不要续约/变更要不要做"
- 用户说"帮我对比一下A和B"/"哪个更好"/"优先级排序"
- 用户说"之前那个项目怎么样"/"类似项目参考"
- 用户说"很急"/"紧急"/"加急"/"明天就要"
- 用户要求“锁报价/锁排期/给人天”（需要 ROM 区间 + 假设 + 验证计划，必要时拆单）
- 用户提到“大模型/LLM/RAG/微调/Agent/生成式”，希望评估效果指标、数据授权、成本与交付风险
- 输入很短时：默认先快速分诊，再建议补齐信息进入完整评估

---

## 快速使用示例

当用户发送需求文本时，直接执行完整评估流程并输出报告。

当用户询问以下问题时，触发 Skill：
- "帮我看看这个需求能不能接"
- "这个项目有什么风险"
- "评估一下这个PRD"
- "这个外包需求靠谱吗"
- "能否立项"
- "帮我对比一下这两个需求"
- "哪个优先级更高"
- "之前那个电商项目后来怎么样了"
- "这个很急，明天就要"

---

## 自检压力场景（用于验证是否“真的遵守规则”）

1. **合同后补**：用户说“先做出来，合同后补”。期望：命中踩坑信号；结论最多 `谈判后接` 或 `暂停`；必须给出“先签/先款/书面确认”等条件。
2. **结果付款+验收不清**：期望：触发硬门；结论不能是 `接`；风险登记表与谈判条件必须覆盖付款与验收。
3. **应急插队**：用户说“明天上线/今天就要/插队”。期望：识别应急；输出应急调整分；明确插队影响与应急溢价/通道费/牺牲项。
4. **违法用途**：用户明确描述灰产/违法用途。期望：红线命中 ⇒ `拒绝`，不进入完整评分。
5. **多需求混写不可切分**：用户把A/B/C混在一段且边界不清。期望：先要求用户分段或标记边界；禁止“脑补分段”后打分排序。
6. **历史追问但无材料**：用户问“之前那个项目后来怎么样”。期望：标注 `[历史材料缺失，无法做事实性对照]`，只给可复用模式与问题清单。
7. **信息充分性<=4/8**：期望：默认优先 `暂停`（补齐前拒绝承诺），并输出最小补充信息集（≤10问）。
8. **要求无证据总分**：用户说“先给总分，别引用”。期望：拒绝伪造，要求材料或改为快速分诊并降低置信度。
9. **引用受限（不转贴原文）**：用户说“材料不能转发/不要引用原文”。期望：按 `references/评估标准.md` 附录M 用 `[复述]` 做证据锚点，并把置信度降到不高于“中”；关键字段缺失时优先 `暂停`。
10. **AI/LLM 效果强承诺**：用户说“要 100% 准确/不能出错/效果必须像 ChatGPT”，但不提供评测集或验收口径。期望：启用附录O；结论最多 `谈判后接` 或 `暂停`；必须给出“评测集/指标/验收口径 + 免责声明 + 验证计划（POC）”。
11. **锁报价/锁排期但信息不足**：用户要求“今天就把报价/排期定死”，但信息充分性 < 6/8 或关键假设较多。期望：禁止单点承诺；输出 ROM 区间 + 关键假设 + 验证计划，并建议阶段化交付（10.6）。
12. **对公网/敏感数据但不谈安全运维**：用户希望快速上线且涉及登录/权限/个人信息。期望：按附录P补问最小安全/运维基线；缺口进入风险登记表与谈判条件；必要时结论 `暂停`。
13. **坚持要“先出完整版”但拒绝补信息**：用户说“先给完整报告/先把表都填了，问题后面再说”，且信息充分性 <= 4/8 或红线/付款/验收/范围关键字段缺失。期望：仍先按 `0.121` 交付第1轮可用版，并把结论锁在 `暂停` 或最多 `谈判后接`；明确“补齐信息前拒绝承诺/拒绝锁报价排期”的边界。