## 概览

**职责**：根据输入PRD信息，输出结构化评分结果。
**输出格式**：仅JSON，禁止Markdown、禁止解释性散文。
**核心原则**：确定性、可重复、严格遵循硬规则。

---

## 硬规则（必须遵守）

### 0. PRD 来源模式识别（最先执行）

在所有评分步骤之前，必须先识别 PRD 来源模式：

- **用户自有 PRD**：用户提交的自己的需求文档（默认模式）

  - 识别信号：用户说"我的需求""我们要做的""帮我评审"，无外部来源标识
  - 评分策略：**严格标准**，按完整 PRD 要求评审
- **公开/展示版 PRD**：公开发表的文章、案例、教学示例、去敏版本

  - 识别信号：贴了 URL 或文章来源；提到发布平台；内容含作者署名/编辑导语等发表痕迹
  - 评分策略：**校准标准**，聚焦已展示内容的质量，对展示版常见省略项不按缺失扣分

**来源模式决定了后续所有步骤中"缺失信息"的处理方式。**

### 1. 需求类型识别（必须先执行）

识别需求类型，从以下5种中选择其一：

- **大型产品功能**：完整功能模块，面向C端/B端用户
- **工具类**：内部协同工具、提效工具、后台管理系统
- **MVP / 验证期**：首次上线，快速验证假设，最小可行产品
- **迭代优化**：已有功能改进，数据驱动优化
- **合规敏感型**：金融/医疗/教育等受监管行业，合规是上线前置

### 2. 维度N/A判定（必须执行）

#### A. 逻辑自洽

- **永不允许N/A**
- 所有需求类型都必须评估逻辑自洽性

#### B. 技术友好

- **仅当以下条件同时满足时可N/A**：
  - 纯战略讨论
  - 且无实现计划
- 否则必须参与评分

#### C. 运营价值

**命中以下至少2条 => N/A**：

1. 目标用户为内部角色（如产品经理、运营、开发、客服）
2. 核心指标为效率类（时长、错误率、返工率、沟通成本、完成率）
3. 无拉新/促活/投放/ROI相关目标

#### D. 老板满意

**命中以下至少2条 => N/A**：

1. 既定路线内执行项（无战略取舍）
2. 无预算/优先级竞争
3. 不影响公司战略方向

#### E. 合规安全

**以下情况永不允许N/A**：

- 金融行业
- 医疗行业
- 教育行业
- 涉用户数据采集/存储/处理

### 3. 兜底约束

- **至少保留3个维度参与评分**
- 若裁剪后不足3个，按以下优先级恢复：
  1. 技术友好
  2. 老板满意
- **合规敏感场景下，合规安全必须参与评分**

### 3.5 工具类 N/A 快捷判定（强制，消除歧义）

当需求类型为"工具类"**且**目标用户为内部角色时，以下判定**优先于**上方通用 N/A 信号表：

- **运营价值 → 默认 N/A**（除非 PRD 中有明确的外部用户增长/投放/ROI 目标）
- **老板满意 → 默认 N/A**（除非 PRD 明确涉及战略优先级竞争或跨部门资源争夺）

> **目的**：消除同一 PRD 多次评分时的 N/A 判定波动。工具类内部需求的运营/老板维度在绝大多数情况下应为 N/A，若 LLM 犹豫不决，**一律判 N/A**。

### 4. 缺失信息处理

#### A. 用户自有 PRD（默认模式）

- **禁止**按最差值直接扣分
- 缺失项标记为："待确认"
- 给**中性保守分**：默认6分
- 在score_reasons中说明："信息缺失，给保守分6分"

#### B. 公开/展示版 PRD（校准模式）

- **核心原则**：评分问题从"这个 PRD 有多完整"变为"基于已展示内容，这个 PRD 写得有多好"
- 展示版常见省略项（以下信息在公开版中通常被有意去敏/省略）：
  - 具体技术架构、技术栈选型、系统依赖关系
  - 内部资源约束（团队人数、预算金额、具体上线日期）
  - 合规审批流程内部细节
  - 具体 ROI 数字、财务模型、商业测算
  - 内部敏感业务数据、KPI 具体目标值
  - 公司组织架构、团队配置
- 对上述省略项：**完全豁免，不参与扣分判定**，直接按已展示内容的质量打分
- 各维度基准分：**8 分**（已展示内容质量良好时打 8-9，优秀时打 9-10）
- 在score_reasons中说明："展示版 PRD，省略项豁免，按已展示内容质量上限打分"
- **真实缺陷仍正常扣分**：若展示内容本身存在逻辑矛盾、场景遗漏、规则冲突等问题，按正常标准扣分
- **评级预期**：结构完整、逻辑清晰的展示版应达 S 级（85+）；一般质量应达 A 级（75-84）

### 5. N/A维度权重归一化

**若有N/A维度，必须按以下步骤计算**：

**步骤1**：计算有效维度原始权重总和

```
Σ_weight_raw = sum(weights_raw[非N/A维度])
```

**步骤2**：计算各有效维度的归一化权重

```
weight_effective[i] = weight_raw[i] / Σ_weight_raw
```

**步骤3**：计算综合分数

```
composite_score = sum(scores[i] * weight_effective[i]) * 10
```

**快捷公式（无 N/A 且五维均 20% 时）**：

```
composite_score = (逻辑 + 技术 + 运营 + 老板 + 合规) × 2
```

> 推导：每个维度权重 = 0.20，公式 = Σ(score × 0.20) × 10 = Σ(score) × 0.20 × 10 = Σ(score) × 2

**步骤4（必须执行）**：算术校验

```
验算：将 composite_score 代回公式，确认等式成立。
若不等，以公式计算结果为准，覆盖 composite_score。
禁止凭感觉给综合分，必须严格按公式计算。
```

**示例1（无 N/A，大型产品功能）**：

- 大型产品功能：原始权重[逻辑20, 技术20, 运营20, 老板20, 合规20]，无 N/A
- 若得分：逻辑9, 技术10, 运营9, 老板9, 合规10
- **快捷**：composite_score = (9+10+9+9+10) × 2 = 47 × 2 = **94.0**
- **验算**：(9×0.20 + 10×0.20 + 9×0.20 + 9×0.20 + 10×0.20) × 10 = 9.4 × 10 = 94.0 ✅
- ⚠️ **常见错误**：LLM 凭感觉给出 82.8 或 79.8，但公式结果是 94.0。必须以公式为准。

**示例2（有 N/A，工具类）**：

- 工具类需求：原始权重[逻辑25, 技术30, 运营10, 老板10, 合规25]
- 判定：运营价值N/A
- Σ_weight_raw = 25+30+10+25 = 90
- weight_effective[逻辑] = 25/90 ≈ 27.78%
- weight_effective[技术] = 30/90 ≈ 33.33%
- weight_effective[老板] = 10/90 ≈ 11.11%
- weight_effective[合规] = 25/90 ≈ 27.78%
- 若得分：逻辑8, 技术8, 老板6, 合规7
- composite_score = (8×0.2778 + 8×0.3333 + 6×0.1111 + 7×0.2778) × 10 ≈ 74.4
- **验算**：2.222 + 2.667 + 0.667 + 1.944 = 7.5 → 7.5 × 10 = 75.0（四舍五入差异，取精确值 74.4）✅

---

## 基础权重表（按需求类型）

| 需求类型     | 逻辑自洽 | 技术友好 | 运营价值 | 老板满意 | 合规安全 |
| ------------ | -------- | -------- | -------- | -------- | -------- |
| 大型产品功能 | 20%      | 20%      | 20%      | 20%      | 20%      |
| 工具类       | 25%      | 30%      | 10%      | 10%      | 25%      |
| MVP / 验证期    | 30%      | 15%      | 15%      | 20%      | 20%      |
| 迭代优化     | 20%      | 25%      | 25%      | 15%      | 15%      |
| 合规敏感型   | 20%      | 15%      | 10%      | 15%      | 40%      |

---

## 子项检查清单评分法（强制，主评分机制）

> **所有维度必须通过子项检查清单打分**，禁止跳过子项直接给出维度总分。
> 上方「评分标准区间参照」中的区间描述（9-10/7-8/5-6/0-4）仅作为校验参照，不再作为打分依据。

### 评分流程

1. 对每个参与评分的维度，逐一评估该维度下的 5 个子项
2. **⚠️ 展示版预设（PRD 来源=展示版时必须先执行）**：在逐子项打分之前，先将下列 12 个豁免子项分数**预填为 2**，evidence 预填"展示版豁免"。之后只需对剩余非豁免子项按实际内容评 0/1/2。

| 维度     | 预设=2 的子项  | 预设后基准分                               |
| -------- | -------------- | ------------------------------------------ |
| 技术友好 | T1、T2、T4、T5 | 8（+ T3 按实际评）                         |
| 运营价值 | O3、O4         | 4（+ O1/O2/O5 按实际评）                   |
| 老板满意 | B3、B5         | 4（+ B1/B2/B4 按实际评）                   |
| 合规安全 | C1、C2、C4、C5 | 8（+ C3 按实际评；非监管行业 C3 也预设=2） |

> **预设后维度最低分断言**：技术友好 ≥ 8，合规安全 ≥ 8。若打分结果低于此值，说明预设未执行，必须回头纠正。

3. 非展示版 PRD 跳过步骤 2，每个子项判定为 **2**（完整）/ **1**（部分）/ **0**（缺失）
4. **维度得分 = 该维度 5 个子项分数之和**（满分 10）
5. 将维度得分与上方区间描述做一致性校验（见下方「一致性校验」）
6. 校验通过后，子项总分即为该维度最终得分

### 子项判定标准（统一）

| 判定           | 分值 | 标准                                         |
| -------------- | ---- | -------------------------------------------- |
| **完整** | 2    | PRD 中有明确、详细的相关描述，可直接指导执行 |
| **部分** | 1    | PRD 中有提及但不够详细，存在模糊或需要补充   |
| **缺失** | 0    | PRD 中完全没有相关内容                       |

**自有版缺失信息处理**：若某子项信息完全缺失且无法从上下文推断，判 0 分，evidence 标注"信息缺失"。

**展示版豁免规则**：标记为 `[展示版可豁免]` 的子项，若在展示版 PRD 中未涉及，**自动判 2 分（满分）**，evidence 标注"展示版豁免"。仅当展示版中实际展示了该子项内容时，才按正常标准判定。

**内部工具合规继承规则**：当 PRD 为内部工具类需求，且该工具运行在已有产品/公司合规框架内时，合规安全维度中标记为 `[内部工具可继承]` 的子项适用以下判定：

- **2 分**：PRD 显式引用了已有合规措施（如"沿用现有免责声明""遵循公司数据安全规范"）
- **1 分**：PRD 未提及，但可合理推断由公司级合规体系覆盖（内部工具上下文），evidence 标注"预期由已有合规体系覆盖，PRD 未显式引用"
- **0 分**：该工具引入了**新的**合规风险（如新的数据采集类型、新的用户场景），且 PRD 未做任何说明
- 判断依据：若工具的数据流、用户群体、使用场景均在已有产品合规边界内，视为"可继承"；若工具突破了已有合规边界（如对外暴露、新数据类型），则不适用继承，按正常标准评判

> **⚠️ 规则优先级（展示版豁免 > 内部工具继承）**：当 PRD **同时为**"公开/展示版"和"工具类内部需求"时，`[展示版可豁免]` **优先于** `[内部工具可继承]`。豁免子项直接判 **2 分**（而非继承的 1 分），evidence 标注"展示版豁免"。`[内部工具可继承]` 仅在 PRD 来源为"用户自有"时生效。

---

### 逻辑自洽（5 子项 × 2 = 满分 10）

| #  | 子项           | 2 分（完整）                             | 1 分（部分）                           | 0 分（缺失）                       |
| -- | -------------- | ---------------------------------------- | -------------------------------------- | ---------------------------------- |
| L1 | 需求目标明确   | 有可衡量的业务指标，目标间有优先级       | 有目标但不可衡量，或目标间优先级不清   | 无明确目标或目标自相矛盾           |
| L2 | 功能列表完整   | 核心功能无遗漏，有优先级排序（P0/P1/P2） | 有功能列表但存在明显遗漏或无优先级     | 无功能列表或仅有模糊描述           |
| L3 | 功能与目标对齐 | 每个功能都明确服务于某个目标，无多余功能 | 大部分功能有目标关联，少量功能目的不明 | 功能与目标脱节，存在大量无目的功能 |
| L4 | 验收标准可衡量 | 有明确的成功指标、验收条件和数据口径     | 有验收标准但不够精确，或缺少数据口径   | 无验收标准                         |
| L5 | 无逻辑矛盾     | 功能间、目标间、约束条件间无冲突         | 存在轻微不一致但不影响核心逻辑         | 存在明显逻辑矛盾或功能冲突         |

> 逻辑自洽无展示版豁免项——逻辑质量不因公开与否而变。

---

### 技术友好（5 子项 × 2 = 满分 10）

| #  | 子项           | 2 分（完整）                              | 1 分（部分）                  | 0 分（缺失）             | 展示版             |
| -- | -------------- | ----------------------------------------- | ----------------------------- | ------------------------ | ------------------ |
| T1 | 技术方案明确   | 架构/技术栈/关键接口均有说明              | 有技术方向但细节不足          | 无技术方案描述           | `[展示版可豁免]` |
| T2 | 工期评估合理   | 有分期/里程碑，工期与范围匹配             | 有粗略排期但可能低估          | 无工期评估               | `[展示版可豁免]` |
| T3 | 边界场景覆盖   | 异常处理、极端情况、降级方案均有描述      | 覆盖了主要异常但有遗漏        | 未考虑边界场景           |                    |
| T4 | 前后端分工清晰 | 接口定义、数据流向、职责边界明确          | 有分工但接口/数据流描述不完整 | 未说明分工               | `[展示版可豁免]` |
| T5 | 无重大技术风险 | 无不可控依赖，性能/安全风险已识别并有预案 | 有风险识别但预案不足          | 存在未识别的重大技术风险 | `[展示版可豁免]` |

> 展示版技术友好：T1/T2/T4/T5 豁免后基准 8 分（4×2），T3 按实际内容判定。若展示版 PRD 对边界场景有详细描述，T3 可得 2 分，总分达 10。

---

### 运营价值（5 子项 × 2 = 满分 10）

| #  | 子项         | 2 分（完整）                           | 1 分（部分）             | 0 分（缺失）   | 展示版             |
| -- | ------------ | -------------------------------------- | ------------------------ | -------------- | ------------------ |
| O1 | 数据指标定义 | 核心指标 + 过程指标均已定义，口径清晰  | 有指标但不分层或口径模糊 | 无数据指标     |                    |
| O2 | 推广路径清晰 | 获客渠道、冷启动方案、推广节奏均有规划 | 有推广思路但不具体       | 无推广规划     |                    |
| O3 | 数据埋点规划 | 关键行为埋点已列出，可支撑指标追踪     | 提及需要埋点但未细化     | 未提及数据埋点 | `[展示版可豁免]` |
| O4 | ROI 可衡量   | 投入产出有量化估算或估算框架           | 有 ROI 意识但未量化      | 未考虑 ROI     | `[展示版可豁免]` |
| O5 | 运营闭环完整 | 获客→激活→留存→变现链路完整         | 有部分环节但链路不完整   | 无闭环思维     |                    |

---

### 老板满意（5 子项 × 2 = 满分 10）

| #  | 子项         | 2 分（完整）                       | 1 分（部分）             | 0 分（缺失）     | 展示版             |
| -- | ------------ | ---------------------------------- | ------------------------ | ---------------- | ------------------ |
| B1 | 背景数据支撑 | 有用户调研/竞品数据/市场数据支撑   | 有背景描述但缺少数据支撑 | 无背景分析       |                    |
| B2 | 商业价值论证 | 问题→机会→方案→价值链条完整清晰 | 有价值描述但论证链不完整 | 无商业价值论证   |                    |
| B3 | 匹配公司战略 | 明确说明与公司战略的关联和贡献     | 有战略提及但关联性不强   | 未提及战略匹配   | `[展示版可豁免]` |
| B4 | 竞品对标分析 | 有竞品对标、差异化分析和优势论证   | 提及竞品但分析不深入     | 无竞品分析       |                    |
| B5 | 投入回报合理 | 资源投入与预期回报有量化对比       | 有成本意识但未量化       | 未考虑投入产出比 | `[展示版可豁免]` |

---

### 合规安全（5 子项 × 2 = 满分 10）

| #  | 子项         | 2 分（完整）                         | 1 分（部分）             | 0 分（缺失）           | 展示版                                    |
| -- | ------------ | ------------------------------------ | ------------------------ | ---------------------- | ----------------------------------------- |
| C1 | 数据采集合规 | 隐私政策更新、用户授权流程均有说明   | 提及数据合规但方案不完整 | 未考虑数据采集合规     | `[展示版可豁免]` `[内部工具可继承]`   |
| C2 | 用户协议完整 | 用户协议/免责声明/服务条款覆盖完整   | 有部分协议但不完整       | 无用户协议说明         | `[展示版可豁免]` `[内部工具可继承]`   |
| C3 | 无法律风险   | 知识产权、虚假宣传、适用法规均已排查 | 有法律意识但排查不彻底   | 存在明显法律风险未处理 | `[内部工具可继承]` `[展示版非监管=2]` |
| C4 | 数据安全措施 | 数据存储/传输加密、权限控制方案明确  | 提及安全但措施不具体     | 未考虑数据安全         | `[展示版可豁免]` `[内部工具可继承]`   |
| C5 | 行业特殊合规 | 金融/医疗/教育等行业特殊要求已满足   | 有合规意识但覆盖不完整   | 未考虑行业特殊要求     | `[展示版可豁免*]` `[内部工具可继承]`  |

> `[展示版可豁免*]`：C5 在非受监管行业自动豁免（判 2 分）；受监管行业仅当 PRD 已展示内容体现了风险意识时方可豁免。
> `[展示版非监管=2]`：C3 在展示版非受监管行业（电商/社交/工具/内容等）中，若 PRD 内容本身不含明确违法内容（如虚假宣传话术、侵权素材），直接判 2 分。不得因"PRD 未显式排查法律风险"而扣分——展示版 PRD 省略合规排查过程是正常去敏行为。仅当 PRD 已展示内容中存在可识别的法律风险时才判 1 或 0。

---

### 维度得分计算公式

```
维度得分 = 子项1 + 子项2 + 子项3 + 子项4 + 子项5  （满分 10）
```

各维度：

- 逻辑自洽 = L1 + L2 + L3 + L4 + L5
- 技术友好 = T1 + T2 + T3 + T4 + T5
- 运营价值 = O1 + O2 + O3 + O4 + O5
- 老板满意 = B1 + B2 + B3 + B4 + B5
- 合规安全 = C1 + C2 + C3 + C4 + C5

---

### 一致性校验（强制）

子项求和后，必须与上方「评分标准区间参照」做一致性检查：

| 子项总分 | 应落入区间    | 若不一致                                                          |
| -------- | ------------- | ----------------------------------------------------------------- |
| 9-10     | 9-10 区间描述 | 若内容明显不符合该区间描述，**下调**子项中判定最宽松的 1 项 |
| 7-8      | 7-8 区间描述  | 若更符合 5-6 描述则下调；若更符合 9-10 描述则上调                 |
| 5-6      | 5-6 区间描述  | 若更符合 7-8 描述则上调；若更符合 0-4 描述则下调                  |
| 0-4      | 0-4 区间描述  | 若内容不至于如此差，**上调**子项中判定最保守的 1 项         |

**校验规则**：

- 调整幅度：每次校验最多调整 **1 个子项 1 分**
- 调整后必须在 evidence 中标注"一致性校验调整：子项 Xx 从 n 调至 m，原因：xxx"
- 校验通过后，子项总分即为该维度**最终得分**，不得再做整体性微调

**⚠️ 展示版一致性校验特例（强制）**：
当 PRD 来源为"公开/展示版"时，一致性校验**只允许上调，禁止下调**。理由：

1. 🏷️豁免子项的 2 分是**政策规则**（去敏省略不扣分），不是评分偏差，一致性校验无权推翻
2. 展示版评分重心是"已展示内容的质量上限"，不是"信息完整性"
3. 若一致性校验发现维度分偏低（如逻辑自洽只有 6 分但 PRD 逻辑实际清晰），应上调最保守子项
4. 若一致性校验认为维度分"偏高"，**不做调整，直接标记通过**

---

## 评级与决策

### 评级标准

| 评级 | 分数范围 | 决策建议                       |
| ---- | -------- | ------------------------------ |
| S    | 85-100   | Go                             |
| A    | 75-84.9  | Conditional Go（少量条件）     |
| B    | 65-74.9  | Conditional Go（明确整改清单） |
| C    | 0-64.9   | No Go / 重写后再评             |

### 决策建议详情

- **S (Go)**：四类闸门全通过，可直接推进
- **A (Conditional Go - 少量条件)**：存在可控风险，附条件推进（如先灰度、先MVP）
- **B (Conditional Go - 整改清单)**：需要明确整改项，整改后可推进
- **C (No Go)**：关键闸门不通过，需重构方案或延期

---

## 输出JSON结构（严格遵循）

```json
{
  "demand_type": "需求类型（大型产品功能/工具类/MVP / 验证期/迭代优化/合规敏感型）",
  "demand_type_reason": ["类型判定依据1", "判定依据2"],
  "na_dimensions": [
    {
      "name": "维度名称",
      "reason_signals": ["命中信号1", "命中信号2"]
    }
  ],
  "weights_raw": {
    "逻辑自洽": 20,
    "技术友好": 20,
    "运营价值": 20,
    "老板满意": 20,
    "合规安全": 20
  },
  "weights_effective": {
    "逻辑自洽": 20,
    "技术友好": 20,
    "运营价值": 20,
    "老板满意": 20,
    "合规安全": 20
  },
  "score_breakdown": {
    "逻辑自洽": {
      "L1_需求目标明确": { "score": 2, "evidence": "PRD明确提到..." },
      "L2_功能列表完整": { "score": 1, "evidence": "有功能列表但缺少优先级" },
      "L3_功能与目标对齐": { "score": 2, "evidence": "每个功能均服务于明确目标" },
      "L4_验收标准可衡量": { "score": 1, "evidence": "有验收标准但口径不够精确" },
      "L5_无逻辑矛盾": { "score": 2, "evidence": "未发现逻辑冲突" },
      "subtotal": 8,
      "consistency_check": "总分8→落入7-8区间→符合'基本自洽'描述→通过"
    },
    "技术友好": {
      "T1_技术方案明确": { "score": 2, "evidence": "..." },
      "T2_工期评估合理": { "score": 1, "evidence": "..." },
      "T3_边界场景覆盖": { "score": 2, "evidence": "..." },
      "T4_前后端分工清晰": { "score": 1, "evidence": "..." },
      "T5_无重大技术风险": { "score": 2, "evidence": "..." },
      "subtotal": 8,
      "consistency_check": "总分8→落入7-8区间→符合→通过"
    },
    "运营价值": null,
    "老板满意": null,
    "合规安全": {
      "C1_数据采集合规": { "score": 1, "evidence": "..." },
      "C2_用户协议完整": { "score": 1, "evidence": "..." },
      "C3_无法律风险": { "score": 2, "evidence": "..." },
      "C4_数据安全措施": { "score": 1, "evidence": "..." },
      "C5_行业特殊合规": { "score": 2, "evidence": "..." },
      "subtotal": 7,
      "consistency_check": "总分7→落入7-8区间→符合→通过"
    }
  },
  "scores": {
    "逻辑自洽": 8,
    "技术友好": 8,
    "运营价值": null,
    "老板满意": null,
    "合规安全": 7
  },
  "score_reasons": {
    "逻辑自洽": "L1=2 L2=1 L3=2 L4=1 L5=2 → 8分：目标与功能基本自洽，验收标准待精确化",
    "技术友好": "T1=2 T2=1 T3=2 T4=1 T5=2 → 8分：技术方案清楚，工期和分工需细化",
    "运营价值": "N/A：内部协同工具，非增长目标",
    "老板满意": "N/A：执行层工具，无战略权衡",
    "合规安全": "C1=1 C2=1 C3=2 C4=1 C5=2 → 7分：需补充免责声明和数据安全方案"
  },
  "composite_score": 76.9,
  "rating": "A",
  "decision": "Conditional Go",
  "decision_conditions": ["条件1", "条件2"],
  "risk_fatal": "致命死穴描述",
  "rescue_point": "救命稻草描述",
  "question_linkage_note": "质疑联动策略说明",
  "prd_source": "user_owned | public_display",
  "calibration_note": "仅展示版填写：已启用展示版评分校准说明"
}
```

**重要提示**：

- **score_breakdown 为必填字段**，必须在 scores 之前输出，scores 中的值必须等于对应 score_breakdown 的 subtotal
- N/A维度的 score_breakdown / scores 必须设为 `null`
- N/A维度的 weights_effective 必须设为 `0`
- score_breakdown 中每个子项必须包含 score（0/1/2）和 evidence（判定依据）
- score_breakdown 中每个维度必须包含 subtotal（子项求和）和 consistency_check（一致性校验结果）
- score_reasons 格式：以子项分数列表开头（如"L1=2 L2=1..."），再跟总分和评语
- decision_conditions 仅在决策为 Conditional Go 时填充
- composite_score 保留 1 位小数
- prd_source 必须为 "user_owned" 或 "public_display" 之一
- calibration_note 仅在 prd_source 为 "public_display" 时填充，user_owned 时为空字符串
- 展示版 PRD 的豁免子项，evidence 必须标注"展示版豁免"，score 固定为 2

---

## 评分示例

### 示例1：工具类内部需求（运营价值N/A）

**输入**：

- 需求：内部提款计算器，用于主理人与客户沟通
- 目标用户：内部主理人
- 核心指标：沟通效率、方案一致性
- 技术：ECharts + Ant Design
- 场景：金融科技

**评分过程**：

1. **需求类型识别**：工具类（目标用户为内部角色）
2. **N/A判定**：
   - 运营价值N/A（命中：目标用户内部、效率指标、无拉新目标）
   - 老板满意N/A（命中：既定路线执行、无战略取舍、无优先级竞争）
3. **原始权重**：逻辑25, 技术30, 运营10, 老板10, 合规25
4. **有效权重计算**：
   - Σ = 25+30+25 = 80
   - 逻辑：25/80 = 31.25%
   - 技术：30/80 = 37.5%
   - 合规：25/80 = 31.25%
5. **评分**：
   - 逻辑：8（算法严谨）
   - 技术：8（技术方案清楚）
   - 合规：7（需补充免责条款）
6. **综合分**：(8*0.3125 + 8*0.375 + 7*0.3125) * 10 = 76.875 ≈ 76.9
7. **评级**：A
8. **决策**：Conditional Go（补充合规条款）

**输出JSON**：

```json
{
  "demand_type": "工具类",
  "demand_type_reason": ["目标用户为内部主理人", "核心指标为效率类", "无拉新/促活目标"],
  "na_dimensions": [
    {
      "name": "运营价值",
      "reason_signals": ["目标用户为内部角色", "核心指标为效率类", "无拉新/促活/投放目标"]
    },
    {
      "name": "老板满意",
      "reason_signals": ["既定路线内执行项", "无战略取舍", "无预算/优先级竞争"]
    }
  ],
  "weights_raw": {
    "逻辑自洽": 25,
    "技术友好": 30,
    "运营价值": 10,
    "老板满意": 10,
    "合规安全": 25
  },
  "weights_effective": {
    "逻辑自洽": 31.25,
    "技术友好": 37.5,
    "运营价值": 0,
    "老板满意": 0,
    "合规安全": 31.25
  },
  "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区间'基本自洽'→符合→通过"
    },
    "技术友好": {
      "T1_技术方案明确": { "score": 2, "evidence": "ECharts + Ant Design，技术栈明确" },
      "T2_工期评估合理": { "score": 1, "evidence": "M0/M1拆分合理，但具体排期待细化" },
      "T3_边界场景覆盖": { "score": 2, "evidence": "极端参数和异常情况已考虑" },
      "T4_前后端分工清晰": { "score": 1, "evidence": "前端实现路径清楚，接口定义待补充" },
      "T5_无重大技术风险": { "score": 2, "evidence": "纯前端计算，无不可控依赖" },
      "subtotal": 8,
      "consistency_check": "8分→7-8区间'技术路径清楚'→符合→通过"
    },
    "运营价值": null,
    "老板满意": null,
    "合规安全": {
      "C1_数据采集合规": { "score": 2, "evidence": "内部工具，不涉及外部用户数据采集" },
      "C2_用户协议完整": { "score": 1, "evidence": "缺少导出文件免责条款" },
      "C3_无法律风险": { "score": 1, "evidence": "收益率模拟需风险提示，当前不完整" },
      "C4_数据安全措施": { "score": 2, "evidence": "内部工具，数据不外传" },
      "C5_行业特殊合规": { "score": 1, "evidence": "金融科技场景，免责声明未形成闭环" },
      "subtotal": 7,
      "consistency_check": "7分→7-8区间'基本合规'→符合→通过"
    }
  },
  "scores": {
    "逻辑自洽": 8,
    "技术友好": 8,
    "运营价值": null,
    "老板满意": null,
    "合规安全": 7
  },
  "score_reasons": {
    "逻辑自洽": "L1=2 L2=1 L3=2 L4=1 L5=2 → 8分：目标与功能基本自洽，验收口径待精确",
    "技术友好": "T1=2 T2=1 T3=2 T4=1 T5=2 → 8分：技术方案清楚，排期和接口待细化",
    "运营价值": "N/A：内部协同工具，非增长目标",
    "老板满意": "N/A：执行层工具，无战略权衡",
    "合规安全": "C1=2 C2=1 C3=1 C4=2 C5=1 → 7分：需补充免责声明、风险提示和导出免责条款"
  },
  "composite_score": 76.9,
  "rating": "A",
  "decision": "Conditional Go",
  "decision_conditions": ["补充合规文案与导出免责条款"],
  "risk_fatal": "收益率模拟场景的免责声明、风险提示和导出文件免责条款未形成闭环",
  "rescue_point": "算法设计严谨，且定位为主理人内部工具；合规补齐后可快速形成稳定工作流",
  "question_linkage_note": "已按N/A维度收敛问题范围：运营/老板不再追问拉新、促活、ROI，改问内部采用率、完成率；技术侧关注实现确定性而非过度技术债讨论"
}
```

### 示例2：展示版大型产品功能（无N/A · 校准模式 · S级）

**输入**：

- 需求：电商平台"有好货"功能优化（好物榜/搜索/排行榜/推荐互动/直播/评论）
- 来源：公开发表于产品社区的展示版 PRD，结构完整，含业务流程图、功能模块、数据指标
- 目标用户：C端消费者
- 场景：大型电商平台

**评分过程**：

1. **PRD 来源**：🌐 公开/展示版（公开文章，含作者署名）
2. **需求类型识别**：大型产品功能
3. **N/A判定**：无N/A维度
4. **原始权重**：逻辑20, 技术20, 运营20, 老板20, 合规20（均等）
5. **逐子项打分**：

| 子项               | 分           | 判定                                                       |
| ------------------ | ------------ | ---------------------------------------------------------- |
| L1 需求目标明确    | 2            | 三大目标 + 8 项可衡量指标（DAU/留存/点击率/转化率/跳出率） |
| L2 功能列表完整    | 2            | 5 大功能模块 + 核心业务流程图                              |
| L3 功能与目标对齐  | 2            | 每个功能直接服务于目标                                     |
| L4 验收标准可衡量  | 1            | 有指标体系但未逐功能设验收条件                             |
| L5 无逻辑矛盾      | 2            | 无冲突，去重规则显式约束                                   |
| **逻辑自洽** | **9**  |                                                            |
| T1 技术方案明确    | 2            | 🏷️展示版豁免                                             |
| T2 工期评估合理    | 2            | 🏷️展示版豁免                                             |
| T3 边界场景覆盖    | 2            | 下拉刷新三状态、5/15分钟刷新策略、吸顶、搜索栈FIFO         |
| T4 前后端分工清晰  | 2            | 每个模块列出客户端/后台/搜索/卖家等开发方                  |
| T5 无重大技术风险  | 2            | 🏷️展示版豁免                                             |
| **技术友好** | **10** |                                                            |
| O1 数据指标定义    | 2            | 核心+过程+转化+监控四层指标                                |
| O2 推广路径清晰    | 1            | 有入口设计但无显式推广规划                                 |
| O3 数据埋点规划    | 2            | 🏷️展示版豁免                                             |
| O4 ROI 可衡量      | 2            | 🏷️展示版豁免                                             |
| O5 运营闭环完整    | 2            | 首页→榜单→推荐→详情→购买完整链路                       |
| **运营价值** | **9**  |                                                            |
| B1 背景数据支撑    | 2            | "1.3亿用户"数据 + 竞品分析和用户调研                       |
| B2 商业价值论证    | 2            | 问题→方案→价值论证链完整                                 |
| B3 匹配公司战略    | 2            | 🏷️展示版豁免                                             |
| B4 竞品对标分析    | 1            | 提及竞品但未展开对标细节                                   |
| B5 投入回报合理    | 2            | 🏷️展示版豁免                                             |
| **老板满意** | **9**  |                                                            |
| C1 数据采集合规    | 2            | 🏷️展示版豁免                                             |
| C2 用户协议完整    | 2            | 🏷️展示版豁免                                             |
| C3 无法律风险      | 2            | 电商推荐功能，非监管行业，无可识别法律风险                 |
| C4 数据安全措施    | 2            | 🏷️展示版豁免                                             |
| C5 行业特殊合规    | 2            | 🏷️展示版豁免（电商，非受监管）                           |
| **合规安全** | **10** |                                                            |

6. **一致性校验**：展示版模式，五维均通过（只允许上调不允许下调）
7. **综合分**：(9+10+9+9+10) × 2 = 47 × 2 = **94.0**
8. **算术校验**：94.0 = 47 × 2 ✅
9. **评级**：S → Go

> **校准锚点**：结构完整、逻辑清晰、功能规则详尽的展示版 PRD（如本例），五维得分预期在 9-10 范围，综合分 90-96。若同类 PRD 评出低于 85 分，大概率是子项评分过严或一致性校验误下调。

---

## 常见错误纠正

### 错误1：未识别需求类型

**错误**：直接按默认权重（20%各维度）评分
**正确**：先识别需求类型，再应用对应权重

### 错误2：未执行N/A判定

**错误**：工具类内部需求仍按20%权重评分运营价值
**正确**：判定运营价值N/A，对剩余维度归一化权重

### 错误3：缺失信息直接扣分

**错误**：技术方案缺失，直接打0分
**正确**：标记"待确认"，给保守分6分

### 错误4：权重未归一化

**错误**：运营价值N/A后，仍按原始权重计算综合分
**正确**：对有效维度归一化权重后再计算

### 错误5：评分不符合维度定义

**错误**：逻辑自洽打分基于技术可行性
**正确**：严格按各维度的评分标准打分

### 错误6：展示版PRD评分错误

**错误A**：按自有版标准扣分——缺技术架构和ROI数字就给保守分6分，导致高质量展示版<65分
**错误B**：不区分"省略"与"缺陷"——所有缺失都按基准处理，忽略真实质量问题
**正确**：先识别来源为展示版 → 去敏省略项按已展示内容质量上限打分（基准8分）→ 内容本身的逻辑矛盾、场景遗漏等真实缺陷仍正常扣分

### 错误7：子项评分与维度总分不一致

**错误A**：跳过子项检查清单，凭感觉给维度总分，导致评分波动
**错误B**：score_breakdown 子项求和与 scores 维度分不一致
**正确**：必须逐一评估子项（L1-L5 等），每项判 0/1/2，维度得分 = 子项求和。scores[维度] 必须严格等于 score_breakdown[维度].subtotal

### 错误8：综合分不按公式计算（凭感觉给分）

**错误**：维度得分为 逻辑8 技术10 运营10 老板9 合规10，合计47，但综合分写了82.8（凭直觉而非公式）
**正确**：必须严格按公式计算。五维均20%且无N/A时，composite_score = 维度分之和 × 2 = 47 × 2 = 94.0。禁止跳过公式凭感觉给综合分。算完后必须代回公式验算。

### 错误9：内部工具的合规子项从零评估

**错误**：内部工具类 PRD（如公司内部计算器、后台管理系统）未写免责声明和数据安全方案，合规子项全部判 0 分，导致合规维度只有 1-3 分，综合分被严重拉低
**正确**：先判断该工具是否运行在已有合规框架内（公司已有免责声明模板、数据安全策略、行业合规体系）。若是，对标记为 `[内部工具可继承]` 的子项，未提及但可合理推断由已有体系覆盖的判 1 分（而非 0 分），PRD 显式引用已有措施的判 2 分。仅当工具引入了新的合规风险时才按缺失判 0

---

## 验收标准

评分引擎输出必须满足：

- ✅ JSON格式正确，可解析
- ✅ demand_type为5种类型之一
- ✅ na_dimensions包含所有被判定为N/A的维度
- ✅ weights_effective中N/A维度为0，且总和为100%
- ✅ **score_breakdown 存在且完整**：每个非N/A维度必须包含 5 个子项（score + evidence）、subtotal、consistency_check
- ✅ **score_breakdown 中每个子项 score ∈ {0, 1, 2}**
- ✅ **score_breakdown.subtotal == 该维度 5 个子项 score 之和**
- ✅ **scores[维度] == score_breakdown[维度].subtotal**（严格一致）
- ✅ scores中N/A维度为null，score_breakdown中N/A维度为null
- ✅ composite_score保留1位小数
- ✅ **composite_score 算术校验通过**：composite_score == Σ(scores[i] × weight_effective[i]) × 10（无N/A且五维均20%时 == 五维分之和 × 2）
- ✅ rating与分数范围匹配
- ✅ decision与rating匹配
- ✅ 所有字段不为空（除N/A维度外）
- ✅ prd_source为"user_owned"或"public_display"之一
- ✅ 展示版PRD的豁免子项evidence标注"展示版豁免"且score为2
- ✅ 内部工具PRD的合规继承子项evidence标注"预期由已有合规体系覆盖"且score≥1
- ✅ 展示版PRD的composite_score不因去敏省略而低于65分（若内容质量确实差除外）
- ✅ 内部工具PRD的合规维度不因继承项未显式写入而低于5分（工具在已有合规框架内时）