工作流
发布时间 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，改变的是协作接口。文件可以变轻，但责任边界会更重要。