案例 07 · 企业研发转型

文字由原PDF提取，阅读顺序和表格请以原页为准。

步调整研发角色和流程，但这些理念到底怎么落到自己的团队里，并没有现成答案。
这也是我理解FDE和普通技术培训最大的区别：面对这种问题，不能只回答“这个工具
怎么用”，而要先判断企业真正要解决的是什么。
Q2：在你参与之前，这个问题过去是怎么解决的？
之前就是产品经理按照原来的方式写PRD，开发人员根据文档进行开发，不同角色按照
原来的分工推进。后来AI Coding工具出现了，研发人员开始自己尝试各种工具，于是
最早出现的是一种非常自然的“个人提效”。
有人发现某个工具好用，就自己用；有人掌握了新的方法，就自己实践。这个阶段其实
没有什么问题，因为个人只需要对自己的效率负责。
但当企业希望从“个人提效”进一步走向“团队提效”时，原来的方式就开始出现限制
了。
比如，原来大家习惯使用飞书文档写PRD。后来AI Coding的工作方式发生变化，很多
内容开始转向Markdown、TXT等文件。原来一个人维护一份文档没有太大问题，但当
整个团队开始围绕这些文件协作时，新的问题马上出现了：十几份文档到底应该怎么
拆？
产品经理写什么？前端写什么？后端写什么？测试和运维又分别负责什么？如果大家同
时修改Markdown，怎么避免冲突？原来的角色边界还能不能继续沿用？
这些都不是单纯学会一个AI工具之后自然就会解决的问题。
所以，我没有把过去的方法定义成“错误”。恰恰相反，它是适应原来研发模式的一套
成熟方法。只是当AI Coding改变了研发方式之后，原来的流程、文档和角色分工也需
要重新调整。
这也是我后来越来越明显的一个感受：AI真正进入企业之后，很多时候改变的不只是工
69/243