メニュー
责任与风险专项评估 - 深度评估人身安全、财产损失、法律责任等风险
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | responsibility-risk-assessment |
| description | 责任与风险专项评估 - 深度评估人身安全、财产损失、法律责任等风险 |
专门评估产品可能带来的各类责任和风险,包括人身安全、财产损失、法律责任、隐私泄露、声誉风险等。这是"好生意评估"七维度模型中的第1维度,也是最重要的维度(一票否决)。
定义: 产品失败或故障可能导致用户人身伤害或生命危险
高风险示例:
评估问题:
□ 产品失败会导致用户受伤吗?
□ 产品给出错误建议会有安全后果吗?
□ 产品承诺了可靠性保障吗?
□ 用户会依赖这个产品保障安全吗?
□ 涉及医疗、驾驶、监护等敏感场景吗?
风险等级判断:
案例:
定义: 产品失败或错误可能导致用户重大财产损失
高风险示例:
评估问题:
□ 产品给出财务建议吗?
□ 涉及用户的资金操作吗?
□ 涉及法律文书或合同吗?
□ 失败可能导致用户财产损失吗?
□ 损失金额可能超过¥10万吗?
风险等级判断:
案例:
定义: 产品运营可能触犯法律,导致严重法律后果
高风险领域:
评估问题:
□ 需要特殊资质/牌照吗?
□ 涉及敏感个人数据(身份证、位置、生物特征)吗?
□ 涉及儿童用户吗?
□ 涉及金融交易吗?
□ 可能出现违法违规内容吗?
□ 需要承担平台责任吗?
风险等级判断:
案例:
定义: 用户隐私数据可能被泄露、滥用或被攻击
敏感数据分类:
评估问题:
□ 收集哪些类型的用户数据?
□ 数据存储在哪里?
□ 是否有完善的安全措施?
□ 是否有第三方数据处理?
□ 数据泄露的最坏后果是什么?
风险等级判断:
案例:
定义: 产品失败或负面事件可能导致长期负面影响
高风险场景:
评估问题:
□ 失败会被媒体报道吗?
□ 会影响个人职业发展吗?
□ 会导致用户强烈不满吗?
□ 负面影响会持续多久?
□ 是否涉及敏感话题?
风险等级判断:
案例:
基础分: 5分
风险扣分:
- 每个高风险: -2分
- 每个中风险: -1分
- 每个低风险: -0.5分
最终得分 = max(0, 基础分 - 扣分)
5分: 无明显风险,可放心做
4分: 有低风险,可控
3分: 有中等风险,需要风控措施
2分: 有高风险,需要规避方案
1分: 有多个高风险,高度危险
0分: 致命风险,不应该做
当风险得分 < 3分时,检查是否有缓解方案:
□ 可以通过保险转移风险?
例: 购买产品责任险、E&O保险
□ 可以通过免责声明降低责任?
例: 明确"仅供参考,非专业建议"
注意: 保护力度有限,不能完全规避
□ 可以通过调整产品定位规避风险?
例: 从"医疗诊断"改为"健康记录"
□ 可以通过技术手段降低风险?
例: 多重备份、冗余设计、人工审核
□ 可以通过合作转移风险?
例: 与有资质的大公司合作,借用其资质和保障
□ 可以通过限制使用场景降低风险?
例: 明确"不适用于生命攸关场景"
## 风险缓解方案
### 风险: [风险描述]
#### 缓解方案1: [方案名称]
- **方法**: __
- **成本**: ¥__
- **有效性**: [高/中/低]
- **残余风险**: [高/中/低]
- **可行性**: [高/中/低]
#### 缓解方案2: ...
### 综合评估
- **最佳方案**: __
- **缓解后风险等级**: [高/中/低/无]
- **是否可接受**: [是/否]
以下风险通常无法有效缓解,应该放弃:
# 责任与风险评估报告
## 项目: [项目名称]
### 1. 风险清单
| 风险类型 | 具体风险 | 风险等级 | 风险描述 |
|---------|---------|---------|---------|
| 人身安全 | __ | 高/中/低/无 | __ |
| 财产损失 | __ | 高/中/低/无 | __ |
| 法律责任 | __ | 高/中/低/无 | __ |
| 隐私泄露 | __ | 高/中/低/无 | __ |
| 声誉风险 | __ | 高/中/低/无 | __ |
### 2. 最坏情况分析
**如果产品失败,可能的最坏后果**:
1. ...
2. ...
3. ...
**是否可承受**: [是/否]
### 3. 风险缓解方案 (如需要)
#### 高风险项: [风险名称]
- **缓解方案**: __
- **成本**: ¥__
- **有效性**: [高/中/低]
- **缓解后风险**: [高/中/低]
### 4. 维度1评分: __/5
**评级**: [可放心做/可控/需要风控措施/需要规避方案/高度危险/不应该做]
**计算过程**:
- 基础分: 5分
- 高风险数: __ × (-2分) = __分
- 中风险数: __ × (-1分) = __分
- 低风险数: __ × (-0.5分) = __分
- **最终得分**: __分
### 5. 结论与建议
**是否通过维度1评估**: [✅通过 / ⚠️需要缓解 / ❌不通过]
**建议**:
1. ...
2. ...
3. ...
在三道防火墙(防火墙1)时使用,快速识别致命风险
在七维度评估时,深度分析各类风险的具体影响
产品上线后,持续监控和评估风险变化
❌ 错误: "加个免责声明就没事了" ✅ 正确: 免责声明在法律上保护力度有限,尤其涉及人身安全和重大财产损失
❌ 错误: "出问题的概率很低,不用担心" ✅ 正确: 小概率事件总会发生,一旦发生个人无法承受
❌ 错误: "大厂都在做,我也可以" ✅ 正确: 大厂有法务团队、保险、资金储备,个人没有
❌ 错误: "我会做好安全措施,不会出问题" ✅ 正确: 没有绝对安全的系统,要考虑被攻击/被破解的可能
❌ 错误: "出了问题再说" ✅ 正确: 涉及风险的问题,事前预防远比事后补救重要
任何一项为"是",立即放弃:
□ 有人身安全高风险
□ 有重大财产损失高风险
□ 有严重法律风险且无合规路径
□ 维度1得分 < 2分
□ 无法有效缓解风险
满足以下条件可以考虑调整后继续:
□ 维度1得分 2-3分
□ 有明确的风险缓解方案
□ 缓解成本可接受
□ 缓解后风险等级降为中/低
□ 最坏情况可承受
□ 维度1得分 ≥ 3分
□ 最坏情况可承受
□ 已有基本风控措施
agents/kuko/docs/好生意.md - 方法论详细说明agents/kuko/SKILLS/business-opportunity-assessment/SKILL.md - 七维度评估agents/kuko/SKILLS/three-firewall-check/SKILL.md - 三道防火墙agents/kuko/SKILLS/risk-assessment/SKILL.md - 通用风险评估Use this skill when debugging complex, multi-factor, or long-running bugs. It maintains a project-root /coe Markdown case file per bug case using a strict Chain-of-Evidence model with only Problem, Hypothesis, and Evidence nodes.
Best practices for Remotion - Video creation in React
Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".
Use when the user needs to design, implement, audit, or govern Storybook stories for frontend components, design systems, page states, interaction tests, accessibility checks, visual baselines, or component-driven UI workflows.
Allows you to view the user's screen as well as several hours of history. Use when the user makes a reference to their recent work, for which it'd be helpful to see the screen. This skill MUST be used whenever you need to resolve ambiguity in a user request, where the user hasn't specified enough context to do the task. Examples include disambiguating the specific user/app/document/error the user is referring to. You must also use this skill if the user asks about any question regarding Chronicle or asks what you can see from the screen.
Use when a frontend redesign or legacy CSS refactor is blocked by global style pollution, selector collisions, unstable DOM reuse, or the need to migrate a page or module to a new UI without breaking the old system.