starforall/ai-coding-toolkit

demand-risk-assessment

Use when 需要对外?

First seen Mar 14, 2026

Installation

$ npx skills add starforall/ai-coding-toolkit --skill demand-risk-assessment

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from starforall/ai-coding-toolkit.

npx skills add starforall/ai-coding-toolkit

Browse all from starforall/ai-coding-toolkit

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 46,460 B
  • docs README.md 285 B
  • docs SUMMARY.md 284 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 51 installs

SKILL.md

需求风险评估 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)

- 红线命中(有证据)⇒ 结论只能 拒绝,跳过完整评分;只输出“红线证据 + 风险最小集 + 条款/止损建议 + 下一步” - 红线要素缺失且无法判断 ⇒ 结论优先 暂停(补齐前拒绝承诺),只输出“缺口 + 最小补充信息集”

  1. 仅当未命中红线且信息足够:进入评分(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个以上需求)

输出对比矩阵:

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

建议输出格式(先独立评估,再汇总对比):

## 【多需求对比:结论与排序】
推荐排序: 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 应急需求评分补充(应急场景额外评分项)

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

额外维度 权重 评分说明
优先级冲突可承受度 +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)
  • 风险归属(当前谁承担?如何转移/共享?)
  • 风险责任人/责任方(谁来盯、谁来做)
  • 证据/缺口/冲突(含踩坑信号/冲突命中)

示例格式:

## 【风险登记表】
| 风险 | 影响类型 | 概率(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轮可用版,并把结论锁在 暂停 或最多 谈判后接;明确“补齐信息前拒绝承诺/拒绝锁报价排期”的边界。