核心用法
该 Skill 提供一套结构化的六阶段风险评估工作流，将风险管理的最佳实践转化为可操作的对话引导框架。用户触发后，系统会依次引导完成：范围界定与利益相关方识别 → 多维度风险识别（技术、安全、运营、法律、声誉、财务）→ 可能性与影响量化分析 → 预防/检测/响应控制措施规划 → 责任人与截止时间确认 → 持续跟踪与复盘机制建立。整个流程采用 RAID（Risk, Action, Issue, Decision）日志形式输出，支持简单矩阵或定量评分两种量化方式，并可适配初创公司轻量化和受监管行业合规模板两种极端场景。
显著优点
方法论成熟度高：直接对标 ISO 31000 和企业级风险管理（ERM）框架，预置预失效分析（Pre-mortem）等经过验证的技术，避免"拍脑袋"式风险讨论。协作对齐能力强：通过共享评分标准（shared rubric）和 RACI 表明确决策权限，解决跨部门风险沟通中的定义冲突和责任模糊问题。场景覆盖全面：内置对重大发布、供应商评估、系统迁移、审计响应等高频场景的触发条件识别，并提供针对安全密集型系统的威胁建模衔接建议。落地执行导向：不同于泛泛而谈的风险提示，强制要求每条重大风险配备 owner、deadline 和升级路径，输出物可直接纳入项目管理工具跟踪。
潜在缺点与局限性
需要用户主动投入：作为纯文档型引导工具，无法自动抓取系统日志或代码仓库进行技术风险扫描，高度依赖参与者的领域知识和坦诚度。量化精度有限：虽然提供了评分框架，但"可能性×影响"的传统矩阵在极端尾部风险（黑天鹅事件）面前容易失效，且不同评估者的主观偏差难以消除。行业适配成本：金融、医疗等强监管领域虽有提及，但仍需用户手动替换为内部合规模板；对于超大规模分布式系统的技术风险评估，建议结合专门的 SRE/混沌工程工具。无实时数据集成：无法对接 Jira、ServiceNow 等系统同步风险状态，跟踪环节仍需人工维护。
适合的目标群体
- 产品经理/项目经理：负责重大功能发布或跨团队项目，需要向管理层呈现结构化风险论证
- 技术负责人/架构师：主导系统迁移、技术选型或供应商评估，需识别技术债务和安全盲区
- 合规/审计团队：应对内外部审计要求，快速生成符合规范的风险登记册
- 初创公司 CEO/运营负责人：在资源有限情况下识别"致命风险"，避免过度工程化
- 咨询顾问：为客户提供风险管理咨询服务时使用的标准化访谈框架
使用风险
信息泄露风险：风险讨论天然涉及敏感的项目细节、供应商信息、安全漏洞或法律争议，建议在组织批准的 AI 使用政策范围内运行，避免输入机密数据。流程僵化风险：六阶段框架对于简单变更可能造成过度文档化，建议根据实际复杂度灵活裁剪阶段。责任归属错觉：AI 生成的风险清单和缓解方案不能替代专业判断，最终"接受残余风险"的决策必须由具有权限的人类利益相关方正式签署。版本维护风险：当前为 1.0.0 版本，来自个人开发者（T3 来源），长期维护承诺未经验证，建议关键业务场景建立内部 fork 或备选方案。