大家都在说工作流，那我们到底是用开源的呢，还是定制自己的呢？

做团队 AI 工作流，第一个把我卡住的问题，不是技术。

而是——到底该用开源的，还是自己造一套？

说实话，我一开始也很犹豫。

毕竟"自己造轮子"这四个字，听着就不太聪明。

所以动手之前，我特意花了不少时间，认真研究了一圈现成的方案：BMAD、OpenSpec、SuperPowers、SpecKit……

一个个看下来，我的第一感受是：真优雅。 👏

设计思路清晰，工程化也讲究，看得出背后都是高手。

可越往深里看，我越发现：它们再好，也不是为我们这种团队设计的。

所以，最终我还是决定做我们自己的工作流。

三个绕不过去的坎

具体说，是三个坎，每一个都硌得慌。

第一个，它们几乎都是冲着"单个项目"设计的。

而我们是微服务架构。

前后端服务加在一起，一百五十多个仓库。

这些工作流，拿来套任何一个单仓库都顺，可一摊开到我们这么一大片服务上，立马就力不从心。

第二个，它们都是通用方案。

通用，意味着不带任何"我们家"的东西。

可真实的开发流程，得跟一堆自有平台打通——需求管理平台、代码库、部署平台、文档系统……

想接上这些，就得自己再补一堆 skill 和规则。

补着补着，整套东西到处是缝、到处是补丁，看着就割裂。

第三个，它们各有各的好，也各有各的不好。

这个的需求拆解做得漂亮，那个的测试环节更扎实。

于是我就陷进去了：想改其中一个的逻辑？别扭。想把几个拼起来用？更别扭。

东拼西凑出来的，永远是个缝合怪。

所以，我决定自己做

这三个坎摆在面前，我想了又想，最后还是决定——自己来。

自己做最大的好处，就俩字：灵活。

业务是我们自己的，架构是我们自己的，团队的使用习惯也是我们自己的。

那就照着这些，量身定制。

哪个环节该重，哪个环节该轻，哪里要跟哪个平台打通，全自己说了算。

这样跑起来，才叫一个丝滑。

"自己做，不会很难吗？"

这是被问得最多的一句。

我的答案是：真没那么难。

原因有两个。

一是，前面那一圈开源项目，不是白看的。

它们的思想，全是现成的养料。 我不用从零开始想，站在这些肩膀上就行。

二是，没有人比你自己更懂你们的业务、架构和工具平台。

把"别人的思路"和"自己的熟悉"这两样一叠加，设计一套贴合自己的工作流，其实容易得很。

一个原则：先有，再好

但有一条原则，我想重点说说——先有，再好。

别一上来就追求大而全、追求优雅。

先把主流程跑通。

那第一刀切在哪？

切在开发流程里最繁琐、大家最不想干的那段活上。

先把这块硬骨头解决掉，正向反馈来得最快——大家一用，"哎，这玩意是真省事"，事情就成了一半。

我们的第一版工作流，我就花了一天半。

没等它完美，先让大家用起来。

剩下的，全在使用里慢慢磨：哪儿别扭了补一刀，哪个环节卡了优化一下。

而且最妙的是——大家用顺了手，自己就开始主动来改了。 🙌

从"逼着用"，到"抢着改"，这个转变一旦发生，工作流就活了。

难的从来不是技术，是那个平衡点

说了这么多"不难"，我还想往深里补一句。

真要说难，难的从来不是技术。

你看我们这一整套——工作流、知识库、工作台、云端执行器，听着挺唬人。

可拆开来看，没有一样是新技术。 全是一年前就摆在那儿的能力，谁都能用。

它真正的价值，不在于我发明了什么，而在于——我找到了那个平衡点。

什么平衡点？

我发现，大多数人对 AI 的判断，不是太高，就是太低。

要么把它想得太强，恨不得什么都甩给它；要么把它想得太弱，缩手缩脚只敢让它打打杂。

给多了，它扛不住，质量崩；给少了，又没意义，纯属浪费。

那条"刚刚好"的线，特别难找。

我也是某一天，脑子里"咔"地一下——突然就想通了。

想明白了 AI 现在到底该干到哪一步，也想明白了它未来该长成什么样，更想明白了：我该走一条什么样的路，把它从现在一步步带到那个未来。

现在回头看这几个月走过的路，跟我当初画的那张图，基本一致。

这种踏实，比做出什么炫技的东西，舒服多了。

最后

开源还是自研，其实没有标准答案。

如果你的场景够标准，拿开源的直接用，没毛病。

但如果你也像我们一样——一堆仓库、一堆自有平台、一堆自己的""，那自己做，反而是更省心的那条路。

别被"造轮子"三个字吓住。

你要的从来不是那套最优雅的工作流。

而是最合你们脚的那一套。

合脚，比好看重要得多。