simonkoson
9.5 KiB
跨 project 协作 — 制片人随身提示单
用途：每次想在主项目之外单开子 project 讨论某个模块时，照此提示单走一遍，避免漏环节、避免版本错位、避免子项目设计违反主项目宪法。 适用：刘通在 Claude 网页版多 project 工作流下的所有"主项目 + 子项目"场景。 维护人：刘通 + 主 project 顾问 (Claude Opus 4.7) 首版日期：2026-06-11
〇、什么是 PRD？
PRD = Product Requirements Document，产品需求文档。
把"我想要个东西"翻译成"工程师可以照着做的具体规格"。一份合格的 PRD 回答：
- 为什么做：解决谁的什么痛点
- 做什么：功能边界、必做/不做
- 怎么用：用户走完流程的样子
- 数据形态：输入什么、输出什么、字段怎样
- 不做什么：明确划红线，防止范围蔓延
子项目立项时，请那边的 Claude 写一份 PRD 跟主项目对接——这就是工程界的标准操作。
一、先判断：这事适不适合分子 project？
分之前先想三个问题。三条都满足才适合分：
- 这个模块与主项目耦合深不深？ 耦合深的（改用户体系、改权限）就别分，分了沟通成本比省下的还高。
- 这个模块边界清不清？ 输入输出明确的（如分钟收视回放）分得开；边界模糊的（如"优化整体视觉风格"）分不开。
- 工作量够不够大？ 特别小的事（改个字段名）直接在主项目谈完即可。三五次对话讨论不完的，才值得分。
反例：未来想做"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 文档是跨项目通信的唯一介质；版本号 + 元信息块永远不省。
七、复盘提示（每次子项目结束后回看一次）
子项目结束，回过头来问自己：
- 这次分子项目是不是真的提高了效率？还是反而增加了沟通成本？
- 主项目顾问审查时发现了多少个违规设计？说明子项目立项时给的"开局材料"够不够？
- 五份交付物齐了吗？哪份最有用？哪份没人看？
- 这次的经验，要不要加进本提示单的下一版？
本提示单本身也按版本管理。每次复盘有沉淀就出 v2。
v1 由主 project 顾问 (Claude Opus 4.7) 协助刘通于 2026-06-11 整理成稿。下次修订时机：第一次完整跑完一个子项目（分钟收视回放）之后。