需求协作升级方案

怎么写需求 · 怎么流转 · 谁负责 · 上线后怎么复盘

① 为什么要升级我们的产研协作

AI 时代，把需求翻译成代码已经接近零成本。产研的价值重心不再是"谁写代码"，而是"谁把需求闭环跑通"。

为什么要继续优化产研协作（5 个信号）

SIGNAL 1
AI 写代码已经很快
实现侧的瓶颈基本消失，瓶颈前移到「需求怎么写、边界怎么定」。AI 越快，前端把关越要紧。
SIGNAL 2
产品侧承压（含测试工作）
写需求 + 高保真原型 + 自测验收，都堆在产品一个人头上，回流变慢、漏 case 风险变高。
SIGNAL 3
没有明确复盘机制
需求做完就过去了，好不好、用户真实反应、踩了什么坑都没沉淀，下一个需求又踩同样的坑。
SIGNAL 4
缺「全链路负责人」设计
现在分段交接（产品写 → 研发写 → 上线丢出去），没人对一个需求从想法到上线效果端到端负责，问题悬在中间。
SIGNAL 5
顶级团队已经朝全员工程师演进
Claude Code / Vercel / Linear 等团队都在朝「每个人都是工程师 + 全链路 Owner」走，分工越来越扁。我们要跟上。

现状：传统分工 + AI 加速 + 产品超载（要升级）

产品 ⚠ 写文档 ⚠ 研发 + AI ⚠ 测试 ⚠ 上线 ✗ 没人复盘 三大痛点： ① 开发变快，需求侧没变快 — AI 让"写代码"压缩了，但调研 / 写文档 / 评审还是传统节奏，瓶颈前移到"想清楚 + 写清楚" ② 流程切换味重 + 产品超载 — 分阶段切换跑，每段交接有损耗，端到端推动多由产品一人扛，整体效率上不去 ③ 开发完就算完事 — 需求 / bug 进飞书池 → 开发完 → 流程结束，没人系统看用户用没用、问题真不真解决 → 传统分工严重拖慢 AI 工具速度，没跑在飞轮上

标杆：Anthropic Claude Code 团队怎么协作（参考样本）

1 位工程师 Owner 端到端跑通（不分阶段交接） ① 想法 ② 交互设计 ③ 编码 ④ 部署上线 ⑤ 数据复盘 同 1 人 关键数据： 15 人 · 仅 1 PM 每天 1 公开版本 90% 代码 AI 起草 70-80% 团队即用户 5 min 一键回滚 如何驱动 Owner 能端到端 — 4 个机制： ① 愿景驱动 每个工程师都清楚团队愿景"做 AI 时代最好用的编码工具" — 端到端决策有底气，不用逐个签批；知道往哪走，自然知道做什么、不做什么 ② 使用闭环 70-80% 团队即用户 — bug 和需求第一手来源是自己（不依赖外部反馈），问题感知极快，做的就是自己想要的 ③ AI 杠杆 90% 代码 AI 起草，工程师转向评审 + 架构 + 微调；一人产能 ≈ 以前整支团队，端到端跑得动 ④ 极简流程 PM 仅 1 人（不写需求文档 / 不分配任务 / 不开长会）；不写传统 PRD，需求全在 Slack + GitHub Issue；分歧直接 ship + 5 min 一键回滚 — 让数据说话

对标：我们要往哪走（路径 + 第一步现在就能动）

三阶段路径：从产品先主导 → 全员 Owner（目标走到阶段 2，前置见 ②③） ▼ 我们在这（1.5：跑通后给开发挂 Owner） 阶段 1 产品先主导 产品定围栏 / 推动落地 / 跟进上线效果 阶段 2 开发挂 Owner 开发自己提需求 / 自己发版 / 自己复盘 阶段 3 全员 Owner 每人端到端 / 互相协作

② 每个需求都要写清楚这几件事 — 三层围栏 + 必备补充

背景：为什么要规范需求文档？
承接 § ① 的 5 个信号 — 既然 AI 实现侧已经很快、瓶颈前移到需求侧，就要把需求文档本身改造成面向 AI 编写的格式。
需求文档应该面向 AI 编写 — 围栏内（必填）只写下方绿图四块；围栏外（代码 / 组件 / API / 边界异常 / 实现细节）全部交给 AI，写多反限制 AI 发挥。
  • 愿景驱动（最重要） — 第一段必须非常清楚"为什么做 / 给谁解决"；对标 Claude Code 团队人人清楚愿景，才能端到端 Owner
  • 评审只对短文档 — 文档不长 → 评审快 → 流转效率上去
  • 砍掉高保真原型 — 低保真线框够用；重前端 Owner 直接 vibe 改项目代码出 demo
  • 颗粒度按复杂度走 — 简单需求不用写 trade-off；越复杂越把围栏边界写细给 AI
关键认知：需求文档不是写完就结束 — 而是活文档，持续吸纳评审 / 开发 / 复盘上下文 → 沉淀成项目知识库
① Owner 写初稿 按下方格式写 围栏 + 指标 + 原型 ② 评审过程回写 讨论 / 决策 被推翻方案 + 边界补充 ③ 开发过程回写 动态维护围栏 测试用例 ④ 复盘上下文回写 做得好不好 用户真实反应 + 踩坑 项目上下文 知识库 团队 + AI 共享 需求文档不是写完就死 = 活文档持续吸纳上下文 → 后续需求站前面肩膀上 → 团队迭代越走越快
所以需求文档只写下面这几样 ↓
必填（三层围栏 + 指标埋点 — 写不全 AI 走偏）： L1 愿景（粗） L2 范围（中） L3 产品业务测试逻辑（细） 指标 + 埋点 按需补充： 不做什么（trade-off — 想清楚再写） 原型（低保真线框 / 重前端直接 vibe 改代码） 必填四块写齐 → AI 直接动手；按需两块看场景判断要不要写

举例：选号虾真实需求「达人卡片新增 A3 + 看后搜字段」该怎么填 ↓

L1 愿景

来源 + 做出来为了什么

来源：4-27/28 商务用户调研里梁家欣、詹鸿盈、林美莹 3 位商务都明确提过「A3 看后搜必加」；商务日常筛号要专门切到星图查这两个数据再切回选号虾对比，每天反复多次；调研结论里这是 P0 第一档。
做出来为了什么：商务在选号虾达人卡片直接看到 A3 + 看后搜，不用再切到星图二次查询；让选号虾真正成为「比星图更顺手的媒介工作台」，提高商务自助筛号比例。

L2 范围

粗的需求简述

在选号虾 AI 推荐结果页的每个达人卡片数据区，新增 2 个字段：「A3」+ 「看后搜」。
数据源：优先复用现有星图 API；如未覆盖则接巨量官方接口。展示位置固定，不可关闭。

L3 产品业务测试逻辑

最细围栏 — 产品写到能直接当业务用例测

打开 AI 推荐结果页 → 任一达人卡片数据区出现「A3」「看后搜」两个新字段；非空时显示具体数字带单位（万 / %）；空值统一显示「-」（不留白也不显示 NA）；位置固定在 CPM 后、完播率前；卡片其他字段位置 / 间距 / 字号不变；筛选结果页 / 收藏页 / 历史页都要显示，行为与 CPM 字段保持一致。
→ 产品写得越细 AI 越能 get。软件层用例（边界 / 性能 / 异常）由开发自己补，不归产品写。

不做什么

trade-off 思考产物

不重做卡片整体布局（这次只新增 2 字段）；不在筛选器里加 A3 / 看后搜筛选条件（先看展示，下版再加）；不让用户自定义字段顺序（统一规则插入）。
不接非官方数据源（防数据失真造成商务误判）；不顺手"优化"卡片其他字段。

指标 + 埋点

必填 — 支撑开发埋点 + 上线复盘

指标：① 商务从选号虾切换到星图查 A3 / 看后搜的频次（目标下降 80%）② 老商务自助筛号比例（vs 让实习生初筛，目标 +20%）③ 下次商务调研里"看后搜"被提次数（目标归零）。
埋点：A3 / 看后搜字段曝光（新增）+ 商务从选号虾跳转到星图的事件（新增）+ 商务自助筛号 vs 委派给实习生的标签（沿用）。没埋点 = 不能上线。
复盘：上线后 2 周内 Owner 自己看埋点数据 + 找 2 个商务做用户访谈 + 找运营协助收反馈，出复盘结论（保留 / 加固 / 改 / 砍 / 回滚）；带着结论上产研周会归档反哺团队上下文。

原型

线框为主 — 重前端体验产品 vibe

统一只做低保真线框图（粗框 + 文字标注），10 分钟出，不精修；让开发知道大致布局即可。本例 A3 / 看后搜：在 CPM 之后、完播率之前的位置画两个字段框 + 标注就够。
重前端体验需求：Owner 拿着线框直接 vibe 改项目代码 — 一步到位，不做 hi-fi 设计稿、不做独立 demo，省掉"中间产物 → 转交开发还原"那一道。
→ 不做 hi-fi 静态稿、不做独立 demo，太耗时间；要么低保真线框够用，要么 Owner 直接 vibe 改项目代码。
③ 一个需求从想法到上线，完整流转 5 步 1 提出 + 判断风险 主导 产品提出 / 产研共定档 动作 飞书新建卡片 → 按风险分档（小/中/大） 产出 卡片 + 风险档位 2 三层围栏 + 补充 主导 产品主写 + 研发评审 动作 L1愿景 / L2范围 / L3业务 + 不做 / 指标埋点 / 原型 产出 薄文档（围栏清楚就开发） 3 开发 + 埋点 + 双轨测全 主导 研发 + AI 协助 动作 编码 + 埋点 + 测产品用例 + 补软件用例 + 全测过 产出 全测通过 才流转下一步 4 发版 + 用户触达 主导 Owner（必要时找技术协助） 动作 推全量 + 红点 / 群公告 / 运营协作宣传 产出 上线 + 用户真的用上 5 复盘 + 反哺团队 主导 Owner（自己搞定） 动作 用户访谈 + 运营协助 + 看数据 → 周会反哺 产出 保留/改/砍 + 团队上下文 下一版迭代
如何评审：Owner 写完需求文档 → 团队评审通过 → 才进入开发（不通过 = 回炉补全，不是开发脑补）
  1. 谁评审：团队全体 Owner 一起评 — 都全员 Owner 化了，没有主评副评，没有谁专属管哪块；每个 Owner 都从自己视角挑围栏漏洞、指标盲点、原型 trade-off，谁先看到问题谁先提
  2. 什么时候评：写好直接发群里，不等周会 — Owner 文档写完立刻丢飞书群 / 卡片，24h 内全员回复通过或打回；不攒批、不等周会，越快流转越好
  3. 评审标准（缺一不可）
    • 三层围栏写齐 — L1 愿景 / L2 范围 / L3 产品业务测试逻辑 都有，不是只写一段
    • 指标 + 埋点写清 — 埋点位置具体到事件名，不是"埋个点"
    • 不做什么明确 — trade-off 想清楚，不只是抄场景
    • 原型有低保真线框 — 重前端体验有 Owner 的 vibe 预览链接
  4. 评审过程同步回写到需求文档 — 评审里的讨论、决策、被推翻的方案、补充的边界，都要回写到对应围栏（L1/L2/L3 或 trade-off 段）；AI 实现时能看到完整上下文，做得更精细，知道"为什么这么定 / 哪些方案已被排除"
核心：评审不是流程主义 — 是把"AI 写不好"的风险前置到围栏阶段，避免实现后才发现需求没想清楚。
如何开发：Owner 起草围栏 → 团队评审通过后的 3 步（Owner = 需求负责人，谁提的谁接，不限角色）
  1. 完成实现（自己 vibe 或拜托技术） — Owner 不一定自己写代码：可以自己 vibe（把三层围栏当 prompt 喂给 AI 起草 + 评审微调），或拜托技术负责人协助实现；但 Owner 始终对实现结果负责
  2. review 业务逻辑 — 对照"L3 产品业务测试逻辑"那段，逐条核对功能是否到位
  3. 代码测试用例 + 实现者自己 review — 谁写代码谁补测试：Owner 自己 vibe 时 = Owner 自己写；拜托技术负责人时 = 技术负责人写。流程：AI 起草粗版 → 实现者按完成情况补全 → 实现者自己 review 业务用例 + 软件用例。业务 + 软件用例全部测完 OK 才算完成开发
如何发版：Owner 自己推动 + 自己发版，让需求更早面对用户
  1. Owner 自己推动发版 — 不等技术团队排期，开发完 + 双轨用例全过 → 主动发；Owner 不会发版可以拜托技术协助，但发版的决策和节奏始终 Owner 主导
  2. 自测没问题 → 直接全量推 — 当前对外用户量小，不搞灰度策略，自测过就全量上；后续用户量起来再考虑灰度 / 分批 / 回滚预案，现阶段不提前优化
  3. 设计用户触达 — 红点提醒 / 飞书群公告 / 运营协作宣传 / 站内消息推送，至少选一种，确保用户真的知道
  4. 飞书发上线通知 + 标注 2 周复盘期 — 同步告知团队该需求已上线，引导团队关注后续数据，2 周后进入「如何复盘」环节
核心：需求越早面对真实用户 = 越早拿到反馈数据 = 越早能优化。Owner 推动发版不是技术活，是产品判断 — 决定什么时候 ship、对哪些用户 ship、怎么 ship。
如何复盘：上线 2 周后，Owner 评估这需求做得好不好 → 沉淀成团队优质上下文，喂给团队 + AI 决定下一步迭代方向（自问三件事）
①
预期指标实际是多少？
对照前面写的"指标"，列出上线前 7 天均值 vs 上线后 2 周实际数。涨 / 降 / 没变，直接写数字。
②
有什么没预料到的？
好的（非预期用法、惊喜数据）+ 坏的（bug、滥用、阻力、运营反馈）。各 1-2 条。结合用户访谈 / 运营反馈一起整理。
③
这个需求做得好不好 → 沉淀成团队上下文
不只是给个"保留/加固/砍"的刚性结论，而是写真实评估：哪里做对了、哪里没做好、用户真实反应、踩了什么坑、当初围栏漏了啥。这部分回写到原需求文档（团队 + AI 都能看到）→ 后续相关需求该不该做、围栏怎么定、AI 怎么实现，都站在前面需求的肩膀上 = 团队迭代越走越快。
产研周会做什么（每周固定 · 团队主持）— 三件事一起过
  1. ① 同步对齐愿景 — 团队整体方向、当前阶段目标、近期重点；让每个 Owner 心里都装着同一个愿景，后续围栏才推得齐
  2. ② 需求优先级讨论 — 在做 / 待启动需求一起拉清单，团队拍板哪些先做哪些后做 / 哪些砍掉
  3. ③ 复盘需求 — Owner 把"这需求做得好不好"的真实评估带到周会，团队一起读 + 沉淀进项目知识库 → 决定后续相关需求方向
日常需求评审 ≠ 周会内容：写好直接发飞书群拉评审，随时拉会，24h 全员通过 / 打回，不攒批不等周会
归档三档（针对每个已上线需求）
a
没感知 — 用户根本不知道有这功能
真因：入口藏太深 / 没通知 / 默认折叠 · 动作：加曝光（弹窗 / Banner / 改默认）
b
不好用 — 用了但放弃 / 抱怨
真因：设计不对 / 价值不够 / 流程别扭 · 动作：改设计 / 砍掉 / 重做
c
用得好 — 主动用 / 留存高
真因：击中真痛点 · 动作：保留 + 加固 + 推广

④ 每个人的分工 — 团队成员各负责什么

原则：每人都有清晰主责 + 尽量端到端 Owner 心态。需求大小不分死档位，动态判断 — 日常小修小补谁顺手谁接、常规功能由产品 Owner、复杂设计 / 架构性大需求由技术（郑庆 / 马腾举）做 Owner、产品协助。Owner 不固定按角色划分，谁最熟悉 / 谁愿意接就由谁接。

我（产品 · 协作方式维护者 + 需求 Owner）

  • 维护本协作方式：流程 / 评审节奏 / 复盘机制 / 项目知识库的持续打磨与迭代；不是拍板者，决策由团队在产研周会一起拍
  • 主写需求文档（三层围栏 + trade-off + 指标埋点 + 原型）；重前端体验直接 vibe，不绕开发轮次。端到端 Owner 大部分需求：定围栏 / 推动落地 / 设计触达 / 数据复盘
  • 用户访谈 + 数据分析；主持产研周会（同步愿景 / 优先级讨论 / 复盘需求）
  • 复杂架构性大需求由技术 Owner 时，产品作为协助提供业务上下文、用户视角、验收用例

梦佳（产品 · bug 修复闭环 + 协助产品）

  • bug 修复 + 上线发版（与文静协作）：bug 进飞书池后梦佳推动开发修复 + 跟踪到上线闭环，文静协助测试验证；两人合力确保 bug 不积压、不遗漏
  • 协助产品：用户调研整理 / 围栏起草 / 项目跟进 / 产研协作支持

文静（南昌运营 · 运营测试 + bug 协作）

  • 日常用户调研和研究：用户反馈 / 典型场景 / 问题清单整理，给团队提供一手用户视角
  • 协助业务用例测试：每个需求上线前用例覆盖测试。Owner 必须给清晰可读的用例（自己读过、整理过的版本），不能是 AI 直接生成的原文 — 否则测的不是真实业务边界
  • bug 修复测试验证（与梦佳协作）：开发修复后协助跑测试、验证修复效果，确认无回归再上线

郑庆（vibe coding 开发 · 实现 Owner）

  • 项目所有需求的实现：vibe coding 是默认实现路径，承接 Owner 写好的围栏 + 补充
  • 发版 + 运维 + debug：项目级别的发版闭环和线上稳定性都由郑庆主导推进
  • 复杂设计 / 架构性大需求时担任技术 Owner（产品协助）

马腾举（资深开发支撑）

  • 协助架构设计：复杂功能、底层模块、跨模块协作时给设计方向 + 技术方案评估
  • 复杂功能实现：vibe 难以覆盖的复杂场景由马腾举上手实现
  • 关键代码评审 + 技术建议
把需求写清楚 · 自己跑完 · 上线后复盘 · v6