Lighthouse
传统项目116
已合并 MR 数量
产品协作新范式 从 PRD 驱动到 Demo 驱动 从文档流转到 Git 协同
分享人：pablozhong2026-06
Demo
Git
Agent
Git
Agent
协作现场
一些变化
文档先行→Demo 先行
共享文档→共享代码分支
交付文档→交付 MR
产品工作流
“古法”产品工作流与 AI Native 渐行渐远
01
需求设计
产品经理输出 PRD，设计功能、流程、规则、边界和验收标准等。
02
需求评审
- 产品内部评审
- 产研评审
- 设计评审
03
需求排期
- 设计排期
- 后端排期
- 前端排期
04
设计技术方案
- 后端技术方案
- 前端技术方案
05
开发实现
- 后端开发
- 前端开发
06
验收测试
- 研发自测
- QA测试
- 设计走查
- 产品体验
07
上线运营
- 发布动态公告
- 写帮助文档
- 搭建数据看板
- 收集用户反馈
迭代效率低
流程重、链路长，跟不上 AI 时代快速试错和即时反馈的节奏。
信息传递有损耗
“文档传递 + 拉会讨论”天然会在理解、优先级和细节上层层衰减。
沉淀依赖自觉
规则、经验和复盘分散在个人文档、会议纪要和聊天记录里，难以复用。
工作流优化
AI Native 产品工作流：让 Idea 先跑起来
传统工作流固定长流程
需求设计→
需求评审→
需求排期→
技术方案→
开发实现→
测试验收→
上线运营
↓
AI 协作工作流
简单需求需求即上线
产品 Vibe 分支→
AI 验收 / MR→
上线运营
中等需求代码前置
产品 Vibe 分支 v0.1→
研发接力v1→
验收 / MR→
上线运营
复杂需求Demo先行
产品 Vibe 可运行 Demo→
需求评审→
需求排期→
开发→
验收→
上线运营
差异
先写清楚 PRD
→
把需求直接跑起来
围绕文档流转协作
→
围绕Git分支协作
按职能固定串行
→
按复杂度分流路径
项目对比
三个项目的数据对比
统计 2026-05-01 至今数据
SkillHub
AI Native 项目220
已合并 MR 数量
Commit 数量1,217
项目核心产研<10人
LightVela
AI Native 项目459
已合并 MR 数量
Commit 数量1540
项目核心产研5 人左右
需求吞吐量不是目标，核心还是更快速的验证想法
核心观点
三个核心观点
职能边界正在消融
组织内的职能边界正在消融。产品经理在大量 Vibe，研发在输出产品 Demo。
标准化 SOP 意味着慢
标准化 SOP 只能保住全局 60 分，在 AI 时代很难把整体拉到 90 分。最大的敌人是"等待"。
Vibe is cheap, Meeting is expensive
低成本 Vibe 快速形成可运行产物，高成本 Meeting 只留给关键决策和对齐共识。
团队资产
团队资产沉淀
SkillAgent知识库
S
产品 AI Skills
适合“输入输出清楚、频繁重复”的产品动作
- 产品需求单 Skill：需求澄清、TAPD单生成、验收标准
- 帮助文档 Skill：帮助文档、操作指南
- 需求评审 Skill：查漏补缺
A
产品 Agents
适合“长链路、多判断、需要持续巡检”的工作
- 产品需求分析官：需求池整理、优先级建议
- 产品动态上线官：负责上线触达全链路
- 产品体验官：负责体验走查、问题识别和复测
K
产品知识库
对 Agent 友好，形成组织记忆
- 代码就是事实来源，AI 直接从 Repo 理解产品逻辑，从 MR 自动沉淀知识
- 知识库分层：团队共识、跨项目通识、特定项目知识
1Skill、Agent、Workflow本身也是AI产品的一部分，需要随模型迭代而更新2持续沉淀对 AI 友好的业务领域知识，是团队的复利资产
新要求
对产品经理的要求和期望
J
用代码直接验证
从对人 Vibe，变成对 AI Vibe。
DogfoodingPR/MRDemo
D
提升品味和审美
当构建越来越便宜，产品经理更需要做价值判断、体验取舍和影响范围判断。
ValueTasteJudgment
A
将 AI 作为有趣的构建类游戏
从“AI 焦虑”变成正反馈的“AI 创造”。
FeedbackFlowCreation
真正稀缺的是：品味、创意、决策、决心
开放问题
还没想清楚的问题
衡量体系
职能模糊后，每个人的生产力怎么衡量？风险责任怎么分配？
效率和复用
AI coding 倾向直接独立实现，而非复用模块，如何平衡？
Harness
Harness Engineering的厚度，需要做到多厚比较合适？