工作流
发布时间 2026.04.16
从PRD到md的协作方式
从 PRD 到 md，本质上不是换文件格式，而是把协作拆回角色责任，再由 AI Agent 串起来执行。难点随之转向流转、版本和权限边界。
Thesis
从 PRD 到 md，不是在把文档变轻，而是在把需求协作重新对齐到角色责任上，再交给 AI Agent 串联和执行。
这几个月，PRD 经常会在中途变成 md。不是有人专门推动，而是大家改着改着，就不太再回那份大文档了。
这不只是格式变轻。多看几轮协作就会发现，真正变化的不是文件，而是协作接口。
角色没变，资产没变，但文件怎么被维护、怎么被流转、最后又怎么被执行，已经开始换了一套逻辑。
Argument
如果只看业务对象，这套协作并没有新角色。产品、设计、开发还在，各自的物料也还在。
真正变化的是，PRD 这份中心文档不再天然成立。md 更容易拆分、引用、版本化，也更适合被 AI Agent 读取和执行。
历史上更稳定的做法一直很朴素：谁对某类物料负责，谁就有最终决定权。产品维护产品侧 md，设计维护设计侧 md，开发维护实现侧 md。
这意味着真正应该共享的，不是一份谁都能改的源文档，而是同一个 demo、同一套变更记录，以及清楚的审核回流。
部分团队会尝试维护同一份文档。问题不在共享本身，而在权限范围没有先定义。权限一旦模糊，大家就会慢慢从执行者变成审核者：能改，但不愿拍板；都参与，但没人真正拥有。
当前最大的痛点不是 md 本身，而是文档流转、版本控制和权限边界。这些后续可以交给协作平台解决，但前提是责任先被画清楚。
Model
权限边界
产品 md
产品 owner 维护与拍板
设计 md
设计 owner 维护与拍板
开发 md
开发 owner 维护与拍板
执行汇总
AI Agent 读取并串联
汇总多份 md，生成同一个 demo 与变更记录
审核回流
产品审核
确认需求与范围
设计审核
确认交互与视觉
开发审核
确认实现与约束
共享的应该是同一个 demo 和清楚的变更回流，而不是在没有权限边界的前提下，让所有人共同改写同一份源文档。
Implications
- ·如果角色方对自己的物料有最终决定权，那么 md 的组织方式就应该先尊重责任边界，再考虑怎么汇总。
- ·AI Agent 更适合负责读取、串联、执行和记录变更，而不是替代角色方做最终拍板。
- ·真正需要被平台化解决的，不是“大家能不能一起写”，而是版本关系、流转规则和审核责任能不能被托管清楚。
Closing
从 PRD 到 md，改变的不是角色分工，而是协作接口。文件可以变轻，但责任边界只会变得更重要。