文件内容
references/scoring-engine-deterministic.md
# OPC 评分引擎
**职责**：根据输入的产品想法/方案，输出结构化评分 JSON。
**原则**：确定性、可重复、严格遵循公式。
---
## 项目目标识别（必须先执行）
先判断项目目标，再识别需求类型。项目目标决定「商业可持续」维度如何评分。
| 目标 | 适用场景 | 商业可持续维度 |
|------|---------|--------------|
| 💰 盈利驱动 | 要赚钱的产品/服务 | 用 B1-B5（商业模式 / 定价 / 跑道 / 差异化 / ROI） |
| 🌐 开源 / 社区驱动 | GitHub 开源项目、公益工具、技术影响力 | 用 B1'-B5'（项目可持续性替代子项） |
| 🧪 个人实验 | 学习项目、技术探索、不追求用户 | 商业可持续可 N/A |
## 需求类型识别
| 类型 | 适用场景 |
|------|---------|
| SaaS / 工具 | 独立开发的软件产品、Chrome 插件、API 服务 |
| 内容产品 | 付费专栏、课程、社群、Newsletter |
| 咨询/服务 | 给客户出方案、外包交付、顾问项目 |
| MVP 验证 | 首次验证假设，最小可行产品 |
| 功能迭代 | 已有产品的改进、数据驱动优化 |
| 开源项目 | GitHub 开源、开发者工具、社区驱动 |
---
## 五维评分维度
| 维度 | 代号 | 衡量什么 | 主评顾问 |
|------|------|---------|---------|
| 逻辑自洽 | L | 需求本身有没有自相矛盾 | **跨顾问**（所有顾问汇总） |
| 独立可交付 | D | 一个人在技术栈舒适区内做不做得出来 | 技术顾问 + 体验顾问（兼评） |
| 增长可行 | G | 冷启动靠什么、用户怎么来怎么留（含体验差异化） | 增长顾问 + 体验顾问（主评） |
| 商业可持续 | B | 能不能赚到钱、跑道够不够 | 商业顾问 |
| 风险可控 | R | 合规/版权/平台规则，一个人搞不搞得定 | 风险顾问 |
---
## 权重表
| 需求类型 | 逻辑自洽 | 独立可交付 | 增长可行 | 商业可持续 | 风险可控 |
|---------|---------|-----------|---------|-----------|---------|
| SaaS / 工具 | 20 | 25 | 20 | 20 | 15 |
| 内容产品 | 20 | 15 | 25 | 25 | 15 |
| 咨询/服务 | 25 | 15 | 15 | 25 | 20 |
| MVP 验证 | 25 | 20 | 20 | 20 | 15 |
| 功能迭代 | 20 | 25 | 25 | 15 | 15 |
| 开源项目 | 20 | 30 | 25 | 10 | 15 |
> 📌 开源项目权重说明：独立可交付和增长可行（社区增长）是开源项目的核心，商业可持续（项目可持续性）权重降低至 10%，避免因"不赚钱"而被不合理惩罚。
---
## N/A 维度判定
| 维度 | N/A 条件 |
|------|---------|
| 逻辑自洽 | **永不 N/A** |
| 独立可交付 | 仅纯咨询/内容且无任何技术实现时 |
| 增长可行 | 仅纯内部自用工具时 |
| 商业可持续 | 仅「个人实验」目标时可 N/A；「开源/社区驱动」用替代子项 B1'-B5' 评分，不可 N/A |
| 风险可控 | 仅极轻量个人实验项目（不涉及用户数据、不上架平台） |
**兜底**：至少保留 3 个维度参与评分。不足时按优先级恢复：独立可交付 → 风险可控。
---
## 子项检查清单（强制，主评分机制）
每维度 5 个子项，每项 0/1/2 分，维度满分 10。
| 判定 | 分值 | 标准 |
|------|------|------|
| 完整 | 2 | 有明确详细描述，可指导执行 |
| 部分 | 1 | 有提及但不够详细或有模糊 |
| 缺失 | 0 | 完全没有相关内容 |
### 信息缺失处理（强制）
- 用户未提供的信息：标记"待确认"，给保守分 1 分（非 0 非 2），evidence 注明"用户未提供，保守分"
- 从上下文推断的信息：标记"推断"，evidence 注明推断依据，允许给 0/1/2 分但必须说明推断逻辑
- **禁止编造**：不得凭想象补充用户未提及的业务细节、市场数据或竞品信息
- **禁止假设意图**：用户没说要赚钱就不假设商业模式，没说目标用户就不编造画像
- 报告必须包含「用户提供的信息」区块，列出每项信息的来源（用户明确提供 / 推断 / 缺失）
---
### 逻辑自洽（L1-L5）
| # | 子项 | 2 分 | 1 分 | 0 分 |
|---|------|------|------|------|
| L1 | 目标明确可衡量 | 有可衡量指标，目标间有优先级 | 有目标但不可衡量或优先级不清 | 无目标或自相矛盾 |
| L2 | 核心交付物明确 | 交付物/功能清单无遗漏，有优先级 | 有列表但遗漏或无优先级 | 无交付物定义 |
| L3 | 功能与目标对齐 | 每个功能服务于明确目标 | 大部分对齐，少量目的不明 | 功能与目标脱节 |
| L4 | 成功标准可衡量 | 有可量化的成功指标（用户数/收入/完课率等） | 有标准但不够精确 | 无成功标准 |
| L5 | 无逻辑矛盾 | 功能间、目标间、约束间无冲突 | 轻微不一致不影响核心 | 明显逻辑矛盾 |
---
### 独立可交付（D1-D5）
| # | 子项 | 2 分 | 1 分 | 0 分 |
|---|------|------|------|------|
| D1 | 技术栈在舒适区 | 主力技术栈，有成熟经验 | 需要学新框架但可控 | 完全陌生的技术栈 |
| D2 | 个人工期合理 | 考虑一人时间约束，有里程碑 | 有粗略排期但可能低估 | 无排期或严重低估 |
| D3 | 边界场景覆盖 | 异常/极端/降级方案有描述 | 覆盖主要异常但有遗漏 | 未考虑边界场景 |
| D4 | 无不可控外部依赖 | 无需审批/资质/第三方关键依赖 | 有依赖但有替代方案 | 存在不可控卡点 |
| D5 | 一人可维护 | 运维自动化/托管，维护成本低 | 需要一定人工运维 | 维护成本超出一人承受 |
---
### 增长可行（G1-G5）
| # | 子项 | 2 分 | 1 分 | 0 分 |
|---|------|------|------|------|
| G1 | 目标用户画像清晰 | 用户是谁、在哪、痛点是什么都明确 | 有用户描述但不够具体 | 不知道卖给谁 |
| G2 | 冷启动渠道明确 | 有具体渠道和前 100 用户获取计划 | 有思路但无具体计划 | 没想过冷启动 |
| G3 | 留存/复购机制 | 有钩子让用户持续回来 | 有一定粘性但不强 | 用完即走无复购 |
| G4 | 增长指标可衡量 | 核心指标定义清晰，有数据追踪方案 | 有指标但不完善 | 无增长指标 |
| G5 | 获客成本可承受 | 一个人的预算和精力能覆盖获客成本 | 成本有压力但勉强可控 | 获客成本超出个人承受 |
---
### 商业可持续（B1-B5）
| # | 子项 | 2 分 | 1 分 | 0 分 |
|---|------|------|------|------|
| B1 | 商业模式清晰 | 怎么赚钱说得明白（订阅/买断/佣金等） | 有收费意向但模式不清 | 不知道怎么赚钱 |
| B2 | 定价有依据 | 参考竞品/用户调研/成本结构定价 | 有定价但无依据 | 未考虑定价 |
| B3 | 跑道充足 | 时间+资金足以验证假设 | 跑道紧张但勉强够 | 跑道明显不足 |
| B4 | 竞品差异化明确 | 差异点清晰且用户可感知 | 有差异但不够突出 | 无差异化或完全同质 |
| B5 | 投入产出合理 | 预期回报与投入时间/金钱匹配 | 有回报预期但未量化 | 投入产出明显不合理 |
---
### 商业可持续-开源替代（B1'-B5'）
> 当项目目标为「🌐 开源/社区驱动」时，用以下子项替代 B1-B5。衡量的不是"能不能赚钱"，而是"这个项目能不能持续活下去、持续产生价值"。
| # | 子项 | 2 分 | 1 分 | 0 分 |
|---|------|------|------|------|
| B1' | 价值主张清晰 | 解决的问题明确，目标用户能一句话说清为什么用 | 有价值但定位模糊 | 不知道给谁用、解决什么问题 |
| B2' | 社区可持续 | 有明确的社区运营计划（文档/贡献指南/交流渠道） | 有基本文档但无社区规划 | 无文档、无社区意识 |
| B3' | 维护者精力可控 | Issue/PR 处理策略清晰，避免 burnout | 意识到维护压力但无策略 | 未考虑长期维护 |
| B4' | 差异化明确 | 与同类开源项目的差异清晰，用户有理由选你 | 有差异但不够突出 | 完全同质化，没有选你的理由 |
| B5' | 影响力路径 | 有明确的传播/推广策略（技术博客/社区分享/SEO） | 有想法但无具体计划 | 没想过怎么让人知道 |
---
### 风险可控（R1-R5）
| # | 子项 | 2 分 | 1 分 | 0 分 |
|---|------|------|------|------|
| R1 | 数据合规 | 隐私政策/用户授权已规划 | 有合规意识但方案不完整 | 未考虑数据合规 |
| R2 | 知识产权 | 字体/素材/代码授权已确认 | 部分确认但有遗漏 | 存在明显侵权风险 |
| R3 | 平台规则合规 | 应用商店/支付/分销合规要求已确认 | 了解但未全面确认 | 未考虑平台规则 |
| R4 | 法律风险可控 | 免责/退款/宣传合规已排查 | 有法律意识但不彻底 | 存在明显法律风险 |
| R5 | 一人兜底能力 | 有应急预案，出事了能快速处理 | 有一定预案但不完善 | 无预案，出事了无法处理 |
---
## 评分计算
### 维度得分
```
维度得分 = 子项1 + 子项2 + 子项3 + 子项4 + 子项5（满分 10）
```
### 综合分计算
**步骤 1**：有效权重归一化（有 N/A 时）
```
Σ_raw = sum(非 N/A 维度的原始权重)
weight_effective[i] = weight_raw[i] / Σ_raw
```
**步骤 2**：计算综合分
```
composite_score = Σ(维度得分[i] × weight_effective[i]) × 10
```
**步骤 3**：算术校验——代回公式确认等式成立，不等时以公式结果为准。
**快捷公式**（五维均 20% 且无 N/A）：`composite_score = 五维得分之和 × 2`
---
## 一致性校验（强制）
子项求和后，与区间描述做一致性检查：
| 总分 | 应匹配描述 |
|------|-----------|
| 9-10 | 该维度几乎无缺陷 |
| 7-8 | 基本过关，有少量待改进 |
| 5-6 | 核心成立但有明显问题 |
| 0-4 | 严重不足 |
若子项总分与描述不一致，最多调整 1 个子项 1 分，并在 evidence 中标注原因。
---
## 评级与决策
| 评级 | 分数 | 决策 |
|------|------|------|
| S | 85-100 | Go |
| A | 75-84.9 | Conditional Go（少量条件） |
| B | 65-74.9 | Conditional Go（明确整改清单） |
| C | 0-64.9 | No Go / 重新想 |
---
## 决策闸门
| 闸门 | OPC 判定标准 |
|------|-------------|
| 价值闸门 | 解决的问题是否真痛？盈利项目：用户愿不愿意付钱？开源项目：用户愿不愿意用并参与社区？ |
| 风险闸门 | 合规/法律/平台规则有没有红线？ |
| 资源闸门 | 一个人做得出来吗？时间和钱够不够？ |
| 战略闸门 | 这个方向值不值得一个人 All in？ |
- **Go**：四闸门通过
- **Conditional Go**：存在可控风险（先 MVP / 先灰度）
- **No Go**：关键闸门不通过，换方向或延期
---
## A/B/C 方案对比（报告必含）
| 维度 | A 完整版 | B 精简版 | C MVP |
|------|---------|---------|-------|
| 范围 | 全功能 | 砍掉非核心 | 只做核心 1 个 |
| 周期 | 长 | 中 | 短（3 周内） |
| 风险 | 高（一人扛不住） | 中 | 低 |
| 适用 | 验证过的成熟方向 | 资源有限但方向明确 | 快速验证假设 |
---
## OPC 决策卡（报告必含）
把 5 顾问质疑折叠成决策清单，三栏：
- ✅ **立刻独立完成**：一个人能做、风险可控
- ⚠️ **必须找外援**：自己搞不定（设计/法务/运维等）
- ❌ **应该砍掉**：投入产出不合理或风险太高
附时间盒方案：3 周 / 6 周 / 3 月各对应什么范围。
---
## 分析框架（评估时参考）
评分时结合以下分析工具提升评估深度，不改变五维评分结构，作为各维度打分的辅助判断依据。
### Lean Canvas 快照 → 商业可持续维度
用 Lean Canvas 结构审视用户的商业模式是否完整：
| 画布块 | OPC 关注点 |
|--------|-----------|
| Problem | 解决的是真痛点还是伪需求？ |
| Solution | 一个人做得出来的方案？ |
| UVP | 一句话说清凭什么用你的？ |
| Unfair Advantage | 一人公司的护城河（速度/垂直专业/低成本）？ |
| Customer Segments | 目标用户够具体吗？ |
| Channels | 一个人能触达的渠道？ |
| Revenue Streams | 怎么收钱？定价有依据吗？ |
| Cost Structure | 固定成本和变动成本算过吗？ |
| Key Metrics | 用什么数据判断活着还是死了？ |
- **盈利驱动**：商业可持续子项（B1-B5）打分时，检查 Lean Canvas 各块是否有覆盖。
- **开源/社区驱动**：Revenue Streams → 改为"可持续来源"（Sponsor / 捐赠 / 基金 / 副产品收入 / 纯热爱，任意一项算覆盖）；其余画布块仍适用，但关注点从"能不能赚钱"转为"能不能持续产生价值"。
### Pre-Mortem 风险分类 → 风险可控维度
打分前先将识别到的风险分为三类：
| 类型 | 含义 | OPC 典型示例 |
|------|------|-------------|
| 🐯 Tigers（真正致命） | 发生就直接死 | 合规红线、核心依赖不可控、资金断裂 |
| 📄 Paper Tigers（看着可怕但可解） | 有替代方案或可规避 | 技术不熟但可学、竞品强但差异化明确 |
| 🐘 Elephants（不愿面对但必须面对） | 被故意忽略的真问题 | 市场可能不存在、创始人能力缺口、跑道不够 |
风险可控子项（R1-R5）打分时，先做 Pre-Mortem 分类，Tigers 直接影响 R 分，Elephants 在报告中单独标注。
### North Star Metric → 增长可行维度
帮用户识别核心衡量指标，判断 G4（增长指标可衡量）：
| 业务类型 | North Star 方向 | 示例 |
|---------|----------------|------|
| 交易型（Transaction） | 交易频次 / GMV | 付费用户数、MRR |
| 注意力型（Attention） | 使用深度 / 时长 | DAU、人均使用时长 |
| 生产力型（Productivity） | 任务完成效率 | 任务完成率、节省时间 |
如果用户说不清自己的核心指标，G4 给 0-1 分。
### MoSCoW → 独立可交付维度
帮用户做 MVP 范围裁剪，判断 D2（个人工期合理）和 D3（边界场景覆盖）：
| 优先级 | 含义 | OPC 原则 |
|--------|------|----------|
| **Must** | 没有就不成立 | 不超过 3 项，超过就追问能否砍 |
| **Should** | 重要但可延后 | V2 再做，不影响上线 |
| **Could** | 锦上添花 | 有精力再说 |
| **Won't** | 明确不做 | 一个人不碰，写清边界 |
Must 列超过 3 项，D2 扣分；Won't 没想清楚，D3 扣分。
### Customer Journey Map → 增长可行 + 独立可交付维度
用 7 阶段框架审视用户旅程完整度，判断 G1（冷启动渠道）、G3（留存）和 D3（边界场景）：
| 阶段 | 关键问题 |
|------|---------|
| Awareness | 目标用户怎么知道你？ |
| Consideration | 用户为什么选你而不选竞品？ |
| Acquisition | 注册/购买流程顺畅吗？ |
| Onboarding | Aha Moment 出现在第几步？超过 3 步就危险 |
| Engagement | 核心使用频率多高？ |
| Retention | 什么机制让用户留下来？ |
| Advocacy | 用户会主动推荐吗？为什么？ |
一个人做不到 7 个阶段都完美，重点追问用户打算优先打磨哪 2-3 个阶段。
---
## 输出 JSON 结构
```json
{
"project_goal": "盈利驱动 | 开源/社区驱动 | 个人实验",
"project_goal_reason": "判定依据",
"demand_type": "SaaS / 工具",
"demand_type_reason": ["判定依据1", "判定依据2"],
"info_sources": [
{ "item": "项目名称", "value": "...", "source": "用户提供 | 推断 | 缺失", "basis": "推断依据（仅推断时填写）" }
],
"na_dimensions": [
{ "name": "维度名", "reason_signals": ["信号1", "信号2"] }
],
"weights_raw": {
"逻辑自洽": 20, "独立可交付": 25, "增长可行": 20,
"商业可持续": 20, "风险可控": 15
},
"weights_effective": {
"逻辑自洽": 20, "独立可交付": 25, "增长可行": 20,
"商业可持续": 20, "风险可控": 15
},
"score_breakdown": {
"逻辑自洽": {
"L1_目标明确可衡量": { "score": 2, "evidence": "..." },
"L2_核心交付物明确": { "score": 1, "evidence": "..." },
"L3_功能与目标对齐": { "score": 2, "evidence": "..." },
"L4_成功标准可衡量": { "score": 1, "evidence": "..." },
"L5_无逻辑矛盾": { "score": 2, "evidence": "..." },
"subtotal": 8,
"consistency_check": "8→7-8 区间→通过"
},
"独立可交付": {
"D1_技术栈在舒适区": { "score": 2, "evidence": "..." },
"D2_个人工期合理": { "score": 1, "evidence": "..." },
"D3_边界场景覆盖": { "score": 2, "evidence": "..." },
"D4_无不可控外部依赖": { "score": 2, "evidence": "..." },
"D5_一人可维护": { "score": 1, "evidence": "..." },
"subtotal": 8,
"consistency_check": "8→7-8 区间→通过"
},
"增长可行": { "...同上结构..." },
"商业可持续": { "...同上结构..." },
"风险可控": { "...同上结构..." }
},
"scores": {
"逻辑自洽": 8, "独立可交付": 8,
"增长可行": 7, "商业可持续": 7, "风险可控": 8
},
"score_reasons": {
"逻辑自洽": "L1=2 L2=1 L3=2 L4=1 L5=2 → 8 分（跨顾问汇总）：...",
"独立可交付": "D1=2 D2=1 D3=2 D4=2 D5=1 → 8 分：...",
"增长可行": "G1=2 G2=1 G3=1 G4=2 G5=1 → 7 分：...",
"商业可持续": "B1=2 B2=1 B3=1 B4=2 B5=1 → 7 分：...",
"风险可控": "R1=2 R2=2 R3=1 R4=2 R5=1 → 8 分：..."
},
"composite_score": 75.5,
"rating": "A",
"decision": "Conditional Go",
"decision_conditions": ["条件1", "条件2"],
"risk_fatal": "致命死穴",
"rescue_point": "救命稻草",
"pre_mortem": {
"tigers": ["真正致命的风险"],
"paper_tigers": ["看着可怕但可解的问题"],
"elephants": ["不愿面对但必须面对的真问题"]
},
"moscow": {
"must": ["核心功能1", "核心功能2"],
"should": ["重要但可延后的功能"],
"could": ["锦上添花的功能"],
"wont": ["明确不做的功能"]
},
"journey_map": {
"stages": [
{ "stage": "Awareness", "status": "当前状态", "issue": "关键问题" },
{ "stage": "Consideration", "status": "...", "issue": "..." },
{ "stage": "Acquisition", "status": "...", "issue": "..." },
{ "stage": "Onboarding", "status": "...", "issue": "..." },
{ "stage": "Engagement", "status": "...", "issue": "..." },
{ "stage": "Retention", "status": "...", "issue": "..." },
{ "stage": "Advocacy", "status": "...", "issue": "..." }
],
"aha_moment": "用户在哪个瞬间感受到核心价值",
"churn_stage": "最可能流失的阶段"
}
}
```
**强制规则**：
- `score_breakdown` 必填且在 `scores` 之前输出
- `scores[维度]` 必须等于 `score_breakdown[维度].subtotal`
- N/A 维度的 score_breakdown / scores 为 `null`，weights_effective 为 `0`
- `composite_score` 保留 1 位小数，必须通过公式计算（禁止凭感觉）
- `score_reasons` 格式：子项分数列表开头 + 总分 + 评语