产品规范

创建人员：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. 修改背景复杂，直接改需求文档容易漏项或冲突。

流程：

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

3.2 产品少量修改流程

适用场景：

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

流程：

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

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

3.3 第一版产品交付流程

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

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

流程：

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

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

3.4 需求文档书写流程

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

一致性检查必须参考：

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

检查重点：

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

流程：

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

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

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

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

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

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

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

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

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

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

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

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

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

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. 一句话

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