simonkoson
225 lines
9.5 KiB
Markdown
225 lines
9.5 KiB
Markdown
# 跨 project 协作 — 制片人随身提示单
|
||
|
||
> 用途：每次想在主项目之外单开子 project 讨论某个模块时，照此提示单走一遍，避免漏环节、避免版本错位、避免子项目设计违反主项目宪法。
|
||
> 适用：刘通在 Claude 网页版多 project 工作流下的所有"主项目 + 子项目"场景。
|
||
> 维护人：刘通 + 主 project 顾问 (Claude Opus 4.7)
|
||
> 首版日期：2026-06-11
|
||
|
||
---
|
||
|
||
## 〇、什么是 PRD？
|
||
|
||
**PRD = Product Requirements Document，产品需求文档**。
|
||
|
||
把"我想要个东西"翻译成"工程师可以照着做的具体规格"。一份合格的 PRD 回答：
|
||
|
||
- 为什么做：解决谁的什么痛点
|
||
- 做什么：功能边界、必做/不做
|
||
- 怎么用：用户走完流程的样子
|
||
- 数据形态：输入什么、输出什么、字段怎样
|
||
- 不做什么：明确划红线，防止范围蔓延
|
||
|
||
子项目立项时，请那边的 Claude 写一份 PRD 跟主项目对接——这就是工程界的标准操作。
|
||
|
||
---
|
||
|
||
## 一、先判断：这事适不适合分子 project？
|
||
|
||
分之前先想三个问题。三条都满足才适合分：
|
||
|
||
1. **这个模块与主项目耦合深不深？** 耦合深的（改用户体系、改权限）就别分，分了沟通成本比省下的还高。
|
||
2. **这个模块边界清不清？** 输入输出明确的（如分钟收视回放）分得开；边界模糊的（如"优化整体视觉风格"）分不开。
|
||
3. **工作量够不够大？** 特别小的事（改个字段名）直接在主项目谈完即可。三五次对话讨论不完的，才值得分。
|
||
|
||
**反例**：未来想做"AI 自动生成报题单"——这件事跟主项目的 TPS 模块、知识库、收视数据、编导画像全打通，**强耦合**，分子 project 反而割裂上下文。这种就在主项目里推进。
|
||
|
||
**正例**：分钟收视回放、本地切图工具、外拍资源管理子模块——边界清晰，可独立设计。
|
||
|
||
---
|
||
|
||
## 二、流程（四步）
|
||
|
||
### 步骤 1：在主项目立"项"——先打招呼
|
||
|
||
子项目开干**之前**，先在主项目 chat 里跟 Claude 顾问说一声：
|
||
|
||
> "我要开一个子 project 讨论 X 模块，目标是 Y。"
|
||
|
||
主项目 Claude 会做两件事：
|
||
|
||
- 检查 X 是否真的适合分出去（参照第一节三问）
|
||
- 把主项目跟 X 相关的红线、技术栈、宪法摘出来给你
|
||
|
||
**实操**：把这些"开局材料"打包好，作为子项目的 files 上传过去（至少包括 `.clinerules`、`project_plan.md`、`dev_plan.md`，必要时加相关的 phase log）。子项目 Claude 能读到这些，就能少犯错。
|
||
|
||
**这一步不能省**。子项目 Claude 看不到主项目宪法时，会本能地按自己的最佳实践设计——很可能违反主项目某条红线。
|
||
|
||
### 步骤 2：在子项目讨论、迭代、收敛
|
||
|
||
要点：
|
||
|
||
- 子项目**不写主项目的代码**，只输出文档、demo、独立小工具
|
||
- 子项目**不改主项目的 schema**，所有涉及主项目数据库结构的提议，回主项目让 Claude 顾问审
|
||
- 子项目**遇到吃不准的事，回主项目问**——以提问列表的形式（参考秒级 chat 那份 PRD 第八节的 6 问）
|
||
|
||
### 步骤 3：子项目凝结成"交付包"
|
||
|
||
讨论完不能就这么散了。要凝结成可以跨 chat、跨 project、被未来任何人接手的产物。**详见下面第四节五份交付物**。
|
||
|
||
**关键认知**：Claude 的 chat 越长，判断力越下降（上下文太满）；而且新 chat 一开就丢了。**md 文档才是真正的产物，chat 只是过程**。讨论一收敛，赶紧让子项目 Claude 凝结成 md。
|
||
|
||
### 步骤 4：回主项目整合
|
||
|
||
带着交付包回主项目：
|
||
|
||
- 主项目 Claude 顾问审一遍交付包，看跟主项目红线有没有冲突
|
||
- 没冲突 → 在主项目 workspace 里让 Cline 落代码
|
||
- 有冲突 → 标出冲突点，回子项目修，循环
|
||
|
||
**主项目顾问对子项目交付物有否决权**。听起来霸道，但必要——子项目 Claude 不知道主项目全部红线。这一步省不掉。
|
||
|
||
---
|
||
|
||
## 三、规范：跨 project 文档怎么写
|
||
|
||
做对四件事，文档传递不会乱。
|
||
|
||
### 规范 1：文件名带版本号
|
||
|
||
❌ `分钟收视需求规格.md`
|
||
✅ `分钟收视需求规格_v1.md`
|
||
|
||
下次改了就 v2。**绝对不要原地覆盖**——历史版本要留着，方便回看"我们当时为什么这么定"。
|
||
|
||
### 规范 2：文档顶部固定"元信息块"
|
||
|
||
每份跨 project 文档第一段必须有：
|
||
|
||
```
|
||
> 版本：v1
|
||
> 日期：2026-06-11
|
||
> 作者：[谁写的]
|
||
> 状态：[草稿 / 待主项目审 / 已采纳 / 已作废]
|
||
> 上一版：[v0 或"无"]
|
||
> 主要变化：[v2 才需要写]
|
||
```
|
||
|
||
这块 6 行，写起来不累，但是救命。**没有这个块的跨 project 文档，主项目这边可以拒收**。
|
||
|
||
### 规范 3：一份文档只谈一件事
|
||
|
||
不要在"分钟收视需求规格"里顺带讨论"用户管理优化"。串了就乱。
|
||
|
||
### 规范 4：主项目这边定期回收
|
||
|
||
子项目讨论完、文档传过来、整合完成后，把最终采纳的那份 md 放到主项目的 `docs/cross_project/` 目录里。这是主项目的"对外接口档案库"。
|
||
|
||
---
|
||
|
||
## 四、最终交付物：子项目结束时该产出什么（五份）
|
||
|
||
子项目结束时，告诉那边的 Claude：
|
||
|
||
> "请把所有讨论凝结成最终交付包，包含以下五份产物。"
|
||
|
||
### 产物 1：决策摘要 md
|
||
|
||
记录子项目全程的关键决策。每条三句话：
|
||
|
||
```
|
||
决策 X：[一句话决策内容]
|
||
- 背景：为什么需要这个决策
|
||
- 拍板理由：选这条不选那条的理由
|
||
- 拍板人：[制片人 / 主项目顾问 / 子项目 Claude 建议+制片人采纳]
|
||
```
|
||
|
||
不需要"我们讨论了 47 轮"的过程，只要最终结论。10-20 条就把整个子项目的"为什么这么做"讲清。
|
||
|
||
### 产物 2：接口约定 md（最技术、最精确）
|
||
|
||
把子板块与主项目接驳的所有"接口"白纸黑字写出来。"接口"是广义的，包括：
|
||
|
||
- **数据接口**：要新建哪些表、哪些字段、字段类型、约束
|
||
- **API 接口**：要新增哪些后端 endpoint、URL、方法、请求体、响应体、错误码
|
||
- **UI 接口**：要在主项目哪个页面挂载这个模块、入口在哪、路由怎么走
|
||
- **权限接口**：哪些角色可以做什么操作
|
||
- **存储接口**：文件存到哪个目录、命名规则、URL 怎么拼
|
||
|
||
每一条都要具体到"主项目的 Cline 拿着这份就能写代码"的程度。**这份是子项目给主项目的"合同"**。
|
||
|
||
### 产物 3：实物交付（独立工具、demo、设计稿）
|
||
|
||
子项目特有的产物。视模块性质不同：
|
||
|
||
- 分钟收视回放子项目 → 本地切图工具 (py + exe + 使用说明)
|
||
- 视觉重设计子项目 → 设计稿（Figma / HTML demo）
|
||
- 数据分析子项目 → 离线分析脚本 + 示例输出
|
||
|
||
这些东西**与主项目零耦合**，自己能独立运行。
|
||
|
||
### 产物 4：未尽事项 backlog
|
||
|
||
诚实写出"子项目讨论中提到但没做的事"。每条三行：
|
||
|
||
- 是什么
|
||
- 为什么没做（暂缓 / P1+ / 等条件成熟）
|
||
- 触发时机
|
||
|
||
放进主项目的 backlog 池子里，未来某个 Phase 收尾时回看，决定哪条捞进下个 Phase。
|
||
|
||
### 产物 5：给主项目 Claude 顾问的"接手提示词"
|
||
|
||
一两段话，告诉主项目顾问"如果你是接手这件事的 Claude，最重要的三件事是 X、Y、Z"。
|
||
|
||
这段相当于一份"防止主项目这边犯傻"的备忘，往往是最有价值的一份。
|
||
|
||
---
|
||
|
||
## 五、操作过程中的实操注意点
|
||
|
||
### 注意 1：永远以 md 为准，不要口头转述
|
||
|
||
❌ "那边 Claude 说 XX"，然后跟那边说"主项目这边说 YY"
|
||
✅ 所有跨项目沟通**以 md 文档为准**
|
||
|
||
口头转述会丢细节、会失真，连续转两次就跟最初的意思差很远。
|
||
|
||
### 注意 2：chat 是过程，md 是产物
|
||
|
||
子项目 chat 长了之后，Claude 自己的判断力会下降（上下文太满），换新 chat 就丢了。**讨论一收敛，赶紧让子项目 Claude 凝结成 md。chat 可以扔，md 不能扔**。
|
||
|
||
### 注意 3：主项目顾问的"审查"环节不能省
|
||
|
||
子项目 Claude 不知道主项目的全部红线，可能输出违规方案。**拿到子项目交付包后，先来主项目让顾问审一遍，再让 Cline 落实施**。这一步省不掉。
|
||
|
||
### 注意 4：每个子项目最长不要超过 3-4 周
|
||
|
||
时间越长，跟主项目脱节越严重（主项目可能在这期间已经迭代）。如果一个子项目超过 4 周还没收敛，应该停下来重新评估：是不是分得太大？要不要切成更小的子子项目？
|
||
|
||
### 注意 5：交付包归档到主项目仓库
|
||
|
||
交付完成后，五份交付物放到主项目的 `docs/cross_project/{子项目名}/` 目录里。**版本号文件全部保留**，未来回看决策史时会用到。
|
||
|
||
---
|
||
|
||
## 六、一句话总结
|
||
|
||
> **子项目专心做事不出主项目；主项目负责审查与整合，不掺合子项目讨论；md 文档是跨项目通信的唯一介质；版本号 + 元信息块永远不省。**
|
||
|
||
---
|
||
|
||
## 七、复盘提示（每次子项目结束后回看一次）
|
||
|
||
子项目结束，回过头来问自己：
|
||
|
||
1. 这次分子项目是不是真的提高了效率？还是反而增加了沟通成本？
|
||
2. 主项目顾问审查时发现了多少个违规设计？说明子项目立项时给的"开局材料"够不够？
|
||
3. 五份交付物齐了吗？哪份最有用？哪份没人看？
|
||
4. 这次的经验，要不要加进本提示单的下一版？
|
||
|
||
**本提示单本身也按版本管理**。每次复盘有沉淀就出 v2。
|
||
|
||
---
|
||
|
||
*v1 由主 project 顾问 (Claude Opus 4.7) 协助刘通于 2026-06-11 整理成稿。下次修订时机：第一次完整跑完一个子项目（分钟收视回放）之后。*
|