# 产品规范

创建人员：Codex  
文件职责：定义通用产品体系的定位、核心流程、文档职责、产品事项边界、审核闭环和与开发/实验/案例分析体系的关系。  
管理规范/模板：../../全局规范.md；../../体系说明.md；../../体系创建流程.md。  
引用文件：需求规范.md；产品环境创建指南.md；产品审核规范.md；产品总纲模版.md；产品设计模版.md；产品方案文档范本.md；产品架构文档范本.md；产品模块说明文档范本.md；产品核心流程文档范本.md；产品执行日志模版.md；产品审计报告模版.md；产品问题记录模版.md；需求文档范本.md。  
记录方式：全局产品体系规范；产品体系流程、文档职责或审核口径变化时更新。

## 1. 定位

产品体系管理产品、需求、策略和业务规则类事项。

它负责：

1. 把聊天要求、方法论、业务想法、实验结论、案例结论整理成可审计的产品事项。
2. 形成清楚的产品方案、需求文档、策略说明或规则说明。
3. 判断产物是否能进入开发、实验、案例分析或项目管理。
4. 保留产品事项的来源、设计、执行、产物、审计和问题闭环。

它不负责：

1. 写代码。
2. 跑实验。
3. 做案例分析。
4. 维护项目级配置。
5. 把未经审核的想法直接交给开发。

## 2. 核心原则

1. 产品事项必须能追到来源聊天记录或上游文档。
2. 产品设计必须说明目标、边界、输入、输出、消费方和验收方式。
3. 审核通过前，产品产物不能进入正式开发或正式实验。
4. 小需求走轻流程，重型系统需求走完整流程。
5. 不把诊断项、建议项、边角料写成主流程硬要求。
6. 如果产品事项要转成需求文档，需求文档必须遵守 `需求规范.md`。
7. 如果产品事项要进入代码实现，必须进入开发体系。

## 3. 核心流程

产品体系分四类主流程，不同规模不要混用。

### 3.1 产品大量修改流程

适用场景：

1. 修改范围跨多个模块、多个流程或多个文档。
2. 修改会改变产品核心口径、核心流程、角色边界或下游研发实现。
3. 修改背景复杂，直接改需求文档容易漏项或冲突。

流程：

```text
来源聊天记录 / 上游文档 / 方法论 / 实验结论 / 案例结论
-> 写入产品总纲，记录背景、目标、边界和结论等级
-> 写产品方案文档，说明修改背景、修改内容、影响范围、前后口径、风险和验收
-> 产品审核员审核产品方案
-> 审核通过后进入需求文档书写流程
-> 交付产品-开发交接审核（研发审核）
-> 研发审核通过后进入开发流程
-> 开发完成后按产品回交验收流程验收
```

### 3.2 产品少量修改流程

适用场景：

1. 修改范围小，通常只影响一份或少量需求文档。
2. 不改变整体架构、核心流程和模块边界。
3. 直接改需求文档不会造成上下游分叉。

流程：

```text
来源聊天记录 / 上游反馈
-> 写入产品总纲或产品执行日志，记录修改原因和边界
-> 直接修改对应需求文档
-> 执行需求文档书写流程中的一致性检查
-> 交付产品-开发交接审核（研发审核）
-> 研发审核通过后进入开发流程
-> 开发完成后按产品回交验收流程验收
```

少量修改不强制先写产品方案文档，但必须记录修改背景、修改范围和需求一致性检查结论。

### 3.3 第一版产品交付流程

如果第一版产品需求包含大量模块、复杂流程或多个下游实现对象，必须先产出三大产品文档：

1. 架构文档：说明整体结构、模块关系、上下游边界。
2. 模块说明文档：说明每个模块的功能、职责、输入输出、边界。
3. 核心流程文档：说明主流程、关键分支、异常路径和交付链路。

流程：

```text
来源聊天记录 / 产品想法 / 方法论 / 上游结论
-> 写入产品总纲，记录第一版产品目标、背景和边界
-> 写架构文档、模块说明文档、核心流程文档
-> 产品审核员审核三大文档
-> 审核通过后进入需求文档书写流程
-> 交付产品-开发交接审核（研发审核）
-> 研发审核通过后进入开发流程
-> 开发完成后按产品回交验收流程验收
```

如果第一版产品需求很小，只涉及单一工具、单一文档或单一规则，可以不写三大文档，直接进入需求文档书写流程。

### 3.4 需求文档书写流程

无论是新写需求文档还是修改需求文档，写完后必须做一致性检查。

一致性检查必须参考：

1. 架构文档、模块说明文档、核心流程文档：有就参考，没有就说明“不适用”。
2. 产品方案文档：有就参考，没有就说明“不适用”。
3. 产品总纲里的目标、背景、边界和关键聊天要求。
4. 已有相关需求文档。

检查重点：

1. 需求文档是否和产品方案一致。
2. 需求文档是否和架构、模块说明、核心流程一致。
3. 是否有冲突。
4. 是否漏写必须实现的需求。
5. 是否把未确认内容写成正式需求。
6. 是否把小需求写成重型系统。

流程：

```text
写需求文档 / 修改需求文档
-> 对照产品方案和三大文档做一致性检查
-> 记录一致性检查结论
-> 交付产品-开发交接审核（研发审核）
-> 研发审核通过后进入开发流程
-> 开发完成后按产品回交验收流程验收
```

### 3.5 产品-开发交接和回交验收流程

本节定义产品侧交接口径，不替代开发体系。

研发审核在产品体系里指“产品-开发交接审核”：开发侧接收前检查需求是否可实现、上游产品文档是否清楚、轻重流程判断是否合理、验收口径是否可执行。它不是新增重型 gate，也不替代开发体系里的方案审核和实现审计。

交付开发前，产品侧必须给开发侧提供：

1. 产品总纲事项 ID。
2. 需求文档。
3. 如有产品方案文档，必须提供。
4. 如有架构文档、模块说明文档、核心流程文档，必须提供。
5. 产品审核或需求审核结论。
6. 产品侧验收口径。

开发侧如果发现需求不清、产品文档冲突、无法实现、轻重判断不合理或验收口径不可执行，应记录为产品/需求问题并退回产品体系，不得靠代码猜。

开发完成后，开发侧回交给产品侧的材料至少包括：

1. 代码变更说明。
2. 运行入口或使用方式。
3. 自测 / 测试结果。
4. 开发审计结论。
5. 需求-代码一致性自检结论。
6. 已知限制和未解决问题。

产品验收记录写入 `产品审计报告.md`，结论回写产品总纲或产品执行日志。产品验收只判断交付行为是否满足产品目标、需求文档和上游产品文档，不替代开发审计。

## 3A. 通用产品事项证据链

不管走哪条分流，都必须保留证据链：

```text
来源聊天记录 / 上游文档 / 方法论 / 实验结论 / 案例结论
-> 产品总纲记录背景、目标、边界和状态
-> 产品设计或产品方案 / 三大文档记录方案
-> 产品审核记录关键审核结论
-> 需求文档记录实现口径
-> 产品-开发交接记录 / 开发事项入口
-> 开发交付证据
-> 产品验收记录
-> 产品执行日志记录关键节点、产物路径和偏离
-> 产品产物审核
-> 问题修复 / 复审
-> 结论回写产品总纲和产品设计
-> 进入开发 / 实验 / 案例分析 / 暂缓
```

## 4. 产品事项类型

| 类型 | 说明 | 典型产物 |
|---|---|---|
| 产品草案 | 初步想法、策略草稿、业务口径整理 | 草案说明、待确认项 |
| 轻量需求 | 小工具、单一文档、辅助脚本需求 | 轻量需求文档 |
| 正式需求 | 多模块、长流程、正式数据链路需求 | 正式需求文档 |
| 策略说明 | 交易/业务/方法论策略口径 | 策略说明文档 |
| 规则说明 | 可被实验、案例或开发消费的规则 | 规则表、规则说明 |

## 5. 核心文档

### 5.1 产品总纲.md

记录产品事项背景、来源聊天、目标、边界、状态和结论。

### 5.2 产品设计.md

记录产品方案、需求拆解、输入输出、流程、验收方式和消费方。

产品设计不是代码设计。进入开发后，重型开发仍要按开发体系写编码方案。

### 5.3 产品方案文档

大量修改时使用，说明修改背景、修改内容、影响范围、前后口径、风险、验收和需求文档改写清单。

产品方案文档必须先经过产品审核员审核，通过后才能进入需求文档书写流程。

### 5.4 架构文档

第一版产品交付且模块较多时使用，说明产品整体结构、模块关系、上下游边界和主要数据/事项流。

### 5.5 模块说明文档

第一版产品交付且模块较多时使用，说明每个模块的大概功能、职责、输入输出、边界和消费方。

模块说明文档不是代码级设计，不要求写到类、函数或实现细节。

### 5.6 核心流程文档

第一版产品交付且流程较复杂时使用，说明主流程、关键分支、异常路径、下游交接和产品验收链路。

### 5.7 产品执行日志.md

记录产品事项实际执行过程，包括关键判断、产物路径、偏离、当前状态和自检。

### 5.8 产品审计报告.md

记录产品设计审核、产物审核和复审结论。

产品审核员发现的问题主记录写在产品审计报告；非审计来源问题写入产品问题记录。

### 5.9 产品问题记录.md

记录非审计来源产品问题、影响、修复建议和复验状态。

### 5.10 需求规范.md

约束正式需求文档的写法、边界和审核方式。产品体系产出需求文档时必须遵守。

## 6. 与其他体系的关系

| 下游体系 | 触发条件 | 交接方式 |
|---|---|---|
| 开发体系 | 产品产物需要代码实现 | 产品审计通过后，在开发体系创建开发事项 |
| 实验体系 | 产品规则需要数据验证 | 产品审计通过后，在实验体系创建实验事项 |
| 案例分析体系 | 产品规则需要逐案分析 | 产品审计通过后，在案例分析体系创建案例事项 |
| 项目体系 | 产品事项影响项目目标、边界、角色或体系启用 | 同步项目事项和项目变更 |

## 7. 审核边界

产品审核重点看：

1. 目标是否清楚。
2. 是否对齐来源聊天和上游文档。
3. 方案是否能满足目标。
4. 输入、输出、消费方是否清楚。
5. 边界和不做事项是否清楚。
6. 验收方式是否够用但不过重。
7. 是否适合进入开发、实验、案例分析或暂缓。

不应把非关键措辞、变量命名、格式偏好当作阻断问题。

## 8. 完成标准

产品事项完成必须按流程类型判断，不得把轻量事项强行套进重型产品设计审核。

通用完成标准：

1. 产品总纲有来源、目标、边界和结论。
2. 产品执行日志记录关键节点、产物路径、偏离和自检。
3. 如有问题，已修复并复审。
4. 如进入开发，必须完成产品-开发交接，并在开发回交后完成产品验收。

分流完成标准：

| 流程类型 | 必须满足 |
|---|---|
| 产品大量修改 | 产品方案文档审核通过；需求文档完成一致性检查；如进入开发，产品验收通过 |
| 产品少量修改 | 需求文档审核通过；修改背景、范围和一致性检查已记录；不强制产品方案或产品设计审核 |
| 第一版复杂产品 | 架构文档、模块说明文档、核心流程文档审核通过；需求文档完成一致性检查；如进入开发，产品验收通过 |
| 第一版轻量产品 | 需求文档审核通过；目标、边界、验收口径清楚；不强制三大文档或产品设计审核 |

## 9. 禁止事项

禁止：

1. 未记录来源聊天就创建正式需求。
2. 未审核通过就交给开发。
3. 把产品草案当正式需求。
4. 把实验结论或案例结论未经产品整理直接变成开发需求。
5. 为了严谨把小需求写成重型系统。
6. 用产品设计替代编码方案。

## 10. 一句话

产品体系负责把想法、方法论、实验/案例结论整理成清楚、可审计、可交接的产品或需求产物；它不替代开发、实验和案例分析。