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 个高杠杆问题。

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

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

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

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

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

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

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

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

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

【项目/需求名称】：
【场景类型】常规/多需求对比/历史参考/应急/续约变更：
【目标（可验证）】：
【范围边界】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) 场景识别（第一优先级）

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

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

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

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

仅输出（必须先给 1.4【概览】）：

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

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

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

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

输出对比矩阵：

• 各需求独立评分
• 维度横向对比
• 优劣势总结
• 推荐建议

建议输出格式（先独立评估，再汇总对比）：

## 【多需求对比：结论与排序】
推荐排序: 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（未评估） 并说明原因（例如：红线早停）。

统一模板：

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

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

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

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

T1 拒绝（红线命中）

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

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

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

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

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

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

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

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

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

## 【概览】
总体决策: 接/谈判后接/暂停/拒绝（快速分诊）
是否可做: 接/谈判后接/暂停/拒绝
是否值得做: 值得做/可做但不值得/暂停
如何做更稳（一句话）: ...
场景标签: ...
总体置信度: 低/中
信息充分性: 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项）：

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

按需展开（全量证据账本）：

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

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. 声明它会影响哪些维度/结论倾向（至少：置信度下调、进入风险登记表）

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

输出格式：

## 【踩坑信号扫描】
- 命中: [话术/信号] - 证据锚点 - 影响

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

按 references/评估标准.md 附录I 检测关键冲突，输出命中项清单与证据锚点，并声明影响：

• 影响哪些维度评分上限/置信度
• 是否触发"谈判后接/拒绝"的倾向

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

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

输出格式：

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

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 输出格式

## 【评分总览】
总分(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 应急需求评分补充（应急场景额外评分项）

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

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

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

至少输出 3 条"最可能失败链路"，并强制包含：

• 触发条件 / 放大机制 / 损失形态
• 早期信号（可观测）
• 止损点（可量化）
• 监控与责任（频率 + 责任方）
• 预防动作（合同/流程/技术）

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

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

输出 6-10 条真正"会改变结论或条款"的风险项，用表格收敛：

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

示例格式：

## 【风险登记表】
| 风险 | 影响类型 | 概率(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 条；
• 用户要求“现在就报价/锁排期”，但信息充分性不足或冲突未消解。

建议格式：

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

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

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

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

建议输出格式：

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

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

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

输出 5-12 个问题即可，按"改变结论的可能性"排序。 每个问题必须标注：

• 关联维度/风险项
• 为什么会改变结论（1句）

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

最终输出模板（统一）

# 需求风险评估报告

## 【概览】
总体决策: 接/谈判后接/暂停/拒绝
是否可做: 接/谈判后接/暂停/拒绝
是否值得做: 值得做/可做但不值得/暂停/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轮可用版，并把结论锁在 暂停 或最多 谈判后接；明确“补齐信息前拒绝承诺/拒绝锁报价排期”的边界。