产研协作体系
从链式传递到点式推进

摘要：30 秒看懂这件事

我们花了大半天时间，把 Hi Tutor 2.0 的 PRD 协作体系重新做了一遍。一句话总结：

最终交付物：

你可以从这份文档跳到任何一份 L1 总纲读细节，但读完这一份就能讲清楚"我们怎么做事、为什么这么做"。

为什么要做这件事

1.1 我们曾经的痛点

写到第 8 份 PRD 的时候，我们发现几个问题：

问题 1：信息漂移

推荐策略 PRD 改了挡位命名（轻松 / 标准 / 深度），但 账户系统 PRD 还用着旧命名（高强度 / 中等 / 轻松）。同一个东西在两份文档里叫法不一样——研发拿到不同 PRD 时一头雾水，要回头问 PM"到底哪个是对的？"。

问题 2：PM 是知识瓶颈

每份 PRD 都依赖"PM 脑子里的隐性共识"——比如"弱网时 AI 怎么降级"这种规则，在数轴 PRD 里说一遍、在日常练习 PRD 里又说一遍、Novi 框架里再说一遍。规则散落各处，研发问"这个降级方案是不是有项目级的统一标准？"——答案是"问 PM"。

问题 3：AI 协作低效

我们越来越多用 AI 写 PRD。但 AI 每次开新会话都不知道"这个项目的铁律是什么、规则在哪查、写过哪些反面案例"，每次都要从头讲一遍上下文，效率低、还容易出错。

问题 4：新人上手陡峭

新来的同事翻 8 份散落 PRD，看不出哪些是项目级硬规则、哪些是模块共享决定、哪些是单功能局部规则。所有信息都在同一层，没有结构。

1.2 行业趋势：链式协作 → 点式协作

这是我们做这套体系背后的一个判断。

PM 写 PRD → 设计画稿 → 研发开发 → 测试验证 → 发布
   ↓           ↓           ↓           ↓          ↓
 信息只往一个方向流动；任何一环卡住整条链停止

         ┌─── 共享上下文（L1 + L2）───┐
    PM ──┤                              ├── 设计
    AI ──┤                              ├── 研发
  测试──┤                              ├── 运营
         └──────────────────────────────┘

1.3 实现点式协作必须做到的 4 件事

要让点式协作真的跑起来，项目记忆必须满足：

1. 结构化：信息分层、分模块，每份文档有清晰定位
2. 单一信息源：每条规则只在一处展开，避免改一处忘一处
3. 自描述：每份文档头部说明自己是什么、什么时候用
4. 主动驱动：AI 不等人指令也能按规则跑（不只是被动响应）

我们今天做的所有事，本质都是在为这 4 件事建基础设施。

核心设计思路

2.1 单一信息源（Single Source of Truth）

问题：同一条规则在 5 个地方写过，改一处其他四处不同步。

做法：每条规则只在一份文档的一个章节里展开，其他地方都是"指针"指向它。

举例：

• "弱网时学生看到什么、AI 怎么降级"——只在《自检与边界规则总纲》§3.1 写
• "组件类 PRD 用 6 章骨架"——只在《PRD 章节骨架与模板套装》§3.2 写
• 各 PRD 模板里、CLAUDE.md 里、MEMORY 里出现这些规则时不重复展开，只写"详见 XX §X"

好处：未来任何规则演进，只改 1 份文档；所有依赖它的下游自动跟随。

2.2 中心化记忆（L2 模块中心）

问题：写 5 份组件 PRD，每份都要重复说一遍"组件和题目页面之间的协作机制"。

做法：把"多份 PRD 共享的决定"抽到 L2 模块中心——每个模块一份背景说明，所有该模块下的 PRD 都读它、引用它，不在每份 PRD 里反复抄。

举例：「首页与学习计划」L2 写：拓展 Event 总数封顶规则、必须联网+登录的边界、Daily Load 的计入逻辑。日常练习 Event PRD、单词卡 PRD、听力 PRD 都引用这份 L2，不重复写。

好处：L2 是"项目的活记忆"——某个模块的所有共识集中在一处；PRD 数量增加时不会信息爆炸。

2.3 双向流动（PRD 既吃 L2 也回填 L2）

问题：传统的 PRD 单向"读 L2 → 写完交付"——L2 永远是 PM 一开始定的版本，会随时间腐烂。

做法：PRD 写作过程中主动回填 L2——发现新决定 / 新待决项 / 新术语就停下问 PM 是否回写到 L2。

   ┌─── 写之前：读 L2（拿共识）
PRD ─┤
   └─── 写之中 / 之后：发现新决定 → 回写 L2（贡献共识）

好处：L2 持续生长，不会腐烂；PRD 是 L2 的"接收方"也是"贡献方"。

2.4 AI 主动驱动（不等人提醒）

问题：写 PRD 时 AI 经常忘了跑边界检查、忘了同步关联 PRD——除非用户每次都手动提醒。

做法：通过 MEMORY 触发器系统让 AI 在特定场景下自动想起该跑什么动作。

AI 写 PRD →（场景出现）→ MEMORY 触发器激活 → 提醒去翻 L1 → 按规则跑动作

示例：写到一段拗口的话时...
  "组件具备权限维度和身份维度..."
          ↓
  MEMORY: feedback_prd_avoid_ai_style 激活
          ↓
  "避免抽象词清单见风格手册 §3.2"
          ↓
  AI 去翻风格手册 → 改写成:
  "组件每种对象有两个属性：能不能被学生操作 / 是谁画上去的"

每条 feedback 触发器都很短（5~10 行），只保留触发条件、L1 指针、反面案例、应用方式。具体规则细节全部在 L1 里，MEMORY 不重复展开——这样未来改 L1 时不用同步改 MEMORY。

好处：AI 从"被动工具"变成"主动协作者"，不再依赖用户每次提醒。

整体架构

3.1 五层文档分层

┌─────────────────────────────────────────────┐
│ L0  项目宪法（CLAUDE.md）                    │
│      • 项目身份 + MVP 范围                   │
│      • 三大铁律标题                          │
│      • 4 份 L1 索引                          │
│      • 文档分层说明                          │
└──────────────────┬──────────────────────────┘
                   ▼
┌─────────────────────────────────────────────┐
│ L1  项目级共享规则（4 份总纲）                │
│      • 自检与边界规则总纲                    │
│      • 协作与文档体系机制                    │
│      • PRD 章节骨架与模板套装                │
│      • PRD 写作风格手册                      │
└──────────────────┬──────────────────────────┘
                   ▼
┌─────────────────────────────────────────────┐
│ L2  模块中心（一个模块一份）                  │
│      • 首页与学习计划_背景说明               │
│      • 组件库_背景说明（待建）               │
│      • Novi 对话_背景说明（待建）            │
│      • 账户系统_背景说明（待建）             │
└──────────────────┬──────────────────────────┘
                   ▼
┌─────────────────────────────────────────────┐
│ L3  局部规格（每个功能一份 PRD）              │
│      • 数轴组件 PRD / 坐标轴组件 PRD ...     │
│      • 日常练习 Event PRD                   │
│      • Novi 对话交互框架 PRD                 │
│      • 账户系统数据结构 PRD                  │
└──────────────────┬──────────────────────────┘
                   ▼
┌─────────────────────────────────────────────┐
│ L4  形态产物（实现层）                        │
│      • design-ref/ 设计稿、原型              │
│      • 代码                                  │
└─────────────────────────────────────────────┘

3.2 4 份 L1 共享规则总纲

L1 的核心思想：按场景分工，每份只管一件事，不重叠。

3.3 L2 模块中心

每个模块对应一份 L2，存放在 eduprd/docs/module-hubs/。

L2 里写什么：

• 该模块的术语表（如 Lesson / Event / Novi 这些专属概念）
• 跨多份 PRD 共享的决定（如 Daily Load 挡位定义、拓展 Event 总数封顶规则）
• 模块级的待决项（哪些规则还没拍板，等讨论）
• 决定变更日志（每次 L2 被回写都留一行：日期 + 触发原因 + 影响范围）

L2 不写什么：单功能的具体规则（这是 L3 PRD 的事）；跨模块的项目级规则（这是 L1 的事）。

3.4 L3 PRD 与模板套装

关键约束：每份 PRD 必须自包含；唯一允许的引用是 L1 总纲 + 所属模块 L2；不允许 L3 之间互相引用。

3.5 MEMORY 系统

MEMORY 是 AI 的持久记忆系统。每次开新会话，CLAUDE.md + MEMORY 索引会自动加载到 AI 的上下文。

MEMORY 里有什么（共 24 条）：

• project 类（1 条）：产品背景
• reference 类（8 条）：4 份 L1 总纲位置 + 4 份其他参考资料位置
• feedback 类（15 条）：行为触发器（写到对应场景时提醒 AI 做某事）

feedback 触发器的作用机制：

AI 写 PRD →（场景出现）→ MEMORY 触发器激活 → 提醒去翻 L1 → 按规则跑动作

每条触发器只保留：
  • 触发条件（什么时候激活）
  • 指针（指向哪份 L1 哪一节）
  • Why（历史反面案例，防止 AI 不当回事）
  • How to apply（一句话怎么用）

规则细节全部在 L1 里，MEMORY 不重复展开。

完整目录结构

Hi Tutor 2.0/                                  ← 项目根目录
│
├── CLAUDE.md                                  ← L0 项目宪法
│
└── eduprd/
    ├── docs/
    │   ├── shared-rules/                      ← L1 项目级共享规则（4 份）
    │   │   ├── Hi Tutor 2.0_自检与边界规则总纲.md
    │   │   ├── Hi Tutor 2.0_协作与文档体系机制.md
    │   │   ├── Hi Tutor 2.0_PRD章节骨架与模板套装.md
    │   │   └── Hi Tutor 2.0_PRD写作风格手册.md
    │   │
    │   ├── module-hubs/                       ← L2 模块中心
    │   │   └── Hi Tutor 2.0_首页与学习计划_背景说明.md
    │   │
    │   ├── prds/                              ← L3 PRD（按模块二级分组）
    │   │   ├── home-and-study-plan/           （首页与学习计划）
    │   │   │   ├── Hi Tutor 2.0_日常练习Event_PRD.md
    │   │   │   └── Hi Tutor 2.0_每日学习推荐策略_PRD.md
    │   │   ├── components/                    （组件库）
    │   │   │   ├── Hi Tutor 2.0_数轴组件_PRD.md
    │   │   │   ├── Hi Tutor 2.0_坐标轴组件_PRD.md
    │   │   │   ├── Hi Tutor 2.0_写作组件_PRD.md
    │   │   │   └── Hi Tutor 2.0_英文写作组件_PRD.md
    │   │   ├── novi-chat/                     （Novi 对话）
    │   │   │   └── Hi Tutor 2.0_Novi对话交互框架_PRD.md
    │   │   ├── account-system/                （账户系统）
    │   │   │   └── Hi Tutor 2.0_账户系统数据结构_PRD.md
    │   │   └── unclassified/                  （还没确定模块归属的 PRD）
    │   │
    │   ├── templates/                         ← PRD 模板套装
    │   │   └── Hi Tutor 2.0_PRD模板（通用版）.md
    │   │
    │   ├── references/                        ← 项目级参考资料
    │   │   └── Hi Tutor 2.0_组件事件模板优先级.md
    │   │
    │   └── Hi Tutor 2.0_产研协作体系说明.md   ← 本文档
    │
    └── design-ref/                            ← L4 设计稿、原型

4.1 命名规则

• PRD：Hi Tutor 2.0_<需求名>_PRD.md
• L2 模块中心：Hi Tutor 2.0_<模块名>_背景说明.md
• L1 总纲：Hi Tutor 2.0_<规则类>.md

4.2 新建文件保存规则

• 新写 PRD → 找归属模块存到 eduprd/docs/prds/<模块>/；模块未定时存 unclassified/
• 新建 L2 模块中心 → 存到 eduprd/docs/module-hubs/
• 修订 L1 总纲 → 文件已在 eduprd/docs/shared-rules/，原地改

PRD 写作完整流程

5.1 流程全景图

5.2 写之前

Step 1：识别归属模块、读 L2

• 识别该 PRD 归哪个模块（首页与学习计划 / 组件库 / Novi / 账户系统 / 待归类）
• 读对应 L2 背景说明
• L2 不存在 → 停下来和 PM 对齐归属或新建一份 L2

Step 2：先列 MVP 候选清单（新组件 / 新模块必做）

写新组件 / 新模块 PRD 前，不要凭直觉划分 MVP。先列一份候选功能清单主动问 PM：每条标"MVP 内 / MVP 外 / 待议"。

Step 3：先讨论再落笔

不要拿到需求就埋头写完整 PRD。先用以下两种方式之一：关键决策点列举、或苏格拉底式追问。

5.3 写之中：每章节循环

每写一节，按这个顺序跑：

1. 风格遵循（贯穿写作过程）：大白话总结、配初中典型例题、PRD 自包含；去 AI 味 6 条 checklist；详见《PRD 写作风格手册》
2. 三大铁律自检（每节末尾跑一次）：弱网 / 离线；多孩家庭 / 跨设备；中低端 Android 平板；详见《自检与边界规则总纲》§1
3. 异常按四要素写透：触发条件 / 学生看到什么 / 系统行为 / 退出方式；自查：一个新来的开发读到这里，能不能不问任何人就实现出来？
4. 边界检查五件套：入口×状态矩阵；三个"如果不"（网断了 / 用户不操作 / 依赖数据没准备好）；用户旅程走查；角色切换；清单确认

决策时序（写之中的关键判断）：

5.4 写之后：3 步收尾

Step 1：PRD 内部完整性自检

• 必填章节是否都填了（元信息 / 三大铁律自检 / 异常清单）
• 三大铁律自检三条都有"非空答案"吗
• 状态说明 / 文案 / 互动表里是否还有 "xxx" 占位符
• 3.1.0 小节是否明示引用了哪些 L1 / L2

任何一项没过 → 回写之中补，不带空白交付。

Step 2：列两份外部清单

• 建议回写到 L2 的清单——按《协作与文档体系机制》§2.4 跑
• 跨 PRD 同步清单——按《协作与文档体系机制》§3 跑

Step 3：PM 一次性拍板

PM 拍板内部自检结果 + 两份外部清单后，PRD 完成。

各层级在流程中的角色

6.1 角色总览

6.2 一句话理解每个层级

• L0 / MEMORY：是 AI 的"内功"——开场就有，告诉 AI 项目长什么样、什么时候去查哪份手册
• L1（4 份总纲）：是"项目的法律"——每条具体规则只在这里展开一次
• L2（模块中心）：是"模块的活记忆"——多份 PRD 共享决定，会因为新 PRD 不断生长
• L3（PRD）：是"具体规格"——L3 吃 L1+L2 的输入，向 L4 输出实现指引
• L4（实现）：是"作品落地"——设计稿 / 代码 / 原型

预期收益

7.4 最重要的一点：路径依赖

这套体系越用越值钱——

• 每写一份 PRD，L2 被回填一次，共识更厚
• 每次冲突 / 漂移，触发审计动作，问题被记录
• 每次反面案例，进 L1 写作风格手册 §4，避免重复踩坑

团队宣贯重点

8.1 团队成员需要做出的改变

对 PM：

• 写新 PRD 前先识别模块、读 L2——不再凭脑子写
• 用 4 份 L1 总纲做 checklist——不再依赖个人经验
• 写完后主动列回写 L2 清单——不再写完就走
• 出现新场景 / 新决定主动停下问 PM 自己（即"是否回写 L2"）

对设计 / 研发 / 测试：

• 拿到 PRD 时只读这一份 + 引用的 L1 / L2——不用翻其他 PRD
• 发现 PRD 有空白 / 占位符主动反馈给 PM（内部完整性自检的兜底）
• 发现 PRD 与 L2 / 其他 PRD 不一致主动指出——这是协作机制的一部分

对所有人：所有 PRD / L1 / L2 都在 eduprd/docs/ 下分子目录管理；文档命名规则统一遵守；不在文档里堆砌技术黑话和抽象词（详见风格手册 §3）。

8.2 不能突破的红线

• L0 / L1 不允许散落到其他地方——所有项目级规则只在 shared-rules/
• L2 是模块共识的唯一来源——同一规则不允许在 L3 和 L2 重复定义（否则会漂移）
• L3 PRD 之间不允许跨引用——研发拿到 PRD 不用翻其他 PRD（允许引用 L1 + 所属 L2）
• PRD 不写技术细节（字段名 / 数据类型 / 接口签名）——那是 TDD 的事
• 超出 MVP 范围按 Coming soon 占位——不在 PRD 里假设其存在
• 教学反馈机制不直接给学生答案——错题的价值在于让学生自己想明白

8.3 出现新场景时怎么演进体系

后续规划

9.1 暂未补的能力（按需添加）

9.2 演进方向

短期：用新模板试写 1~2 份 PRD，看哪些地方不顺手再迭代；收集团队成员使用反馈，补到 L1 反面案例。

中期：把 L2 模块中心补全到 4 个核心模块；看 MEMORY 是否还能再瘦（现在 24 条，理想是 15 条以内）。

长期：探索"AI 自动审计 L2 与 L3 的漂移"——每周自动跑一次报告；探索"AI 主动建议 L2 应回填什么"——AI 看完 PRD 后主动列建议清单。