最近"vibe coding"这个词很火------大意是你不用一行行手写代码，跟 AI 说清楚想要什么，它就能帮你把代码写出来。很多以前觉得"太麻烦，算了，用现成的吧"的东西，现在写一写好像也没那么费劲了。
这就带出一个老问题的新版本：以前我们默认"能用现成的开源框架就别自己造轮子"，现在造轮子的成本降了这么多，这个默认选项还成立吗？
我最近正好在做一个类似的判断，想把想清楚的部分写下来。
一个几乎每个人都遇到过的例子
假设你所在的公司要做一套内部审批系统------请假要审批，报销要审批，用章要审批。摆在技术团队面前通常是两条路：
第一条路：用现成的开源"工作流引擎"。 这类工具已经被无数公司用过很多年，它们把"审批"这件事抽象成一套通用模型：一个申请是一个"流程"，流程里有一个个"节点"，节点和节点之间怎么走由"规则"决定，最后交给谁审批是"候选人"。你只要照着它的规则去配置，剩下的------记录、查询、追溯、并发处理------它都替你想好了。
第二条路：自己写一套。 你完全按照公司自己的组织架构、审批习惯，量身定制一套流转逻辑，想怎么设计就怎么设计。
这两条路各有各的坑，而且坑长得很不一样。
用现成框架的坑：你的业务规则和它的"通用语言"对不上
开源框架为了能服务成千上万家风格迥异的公司，必然要用一套很"通用"的语言去描述审批这件事。但现实中，"这份请假到底该给谁审"这种问题，往往藏着大量非常具体、而且经常变化的规则：换了部门领导怎么办、组织架构调整了怎么办、某些特殊审批需要好几个人一起签字怎么办。
这些具体规则很难原封不动地塞进框架的通用抽象里，于是团队往往会在框架外面再包一层"翻译代码"，专门负责把"我们公司的规则"转换成"框架能听懂的话"。这层翻译代码看起来只是个小补丁，实际上是最容易出 bug 的地方------因为它每天都要面对两种语言互相"言不达意"的摩擦，业务规则一变，翻译就得跟着改，改多了就容易顾此失彼。
自己写的坑：那些你看不见、但别人替你踩过的坑
自己写一套，规则想怎么定就怎么定，短期内确实爽快。但一个"流转系统"背后，藏着很多不那么显眼、却极其要命的问题：两个人同时点了审批按钮会不会出错？系统要升级了，那些正在流转中、还没审批完的单子怎么办？审批记录要留存好几年用来审计，中途出了故障怎么保证不丢数据？
这些问题不是靠"写代码写得快"就能绕开的。它们是那种只有在系统真实运行了很多年、被很多不同公司的真实场景反复捶打过之后，才会一个一个暴露出来、被修好的"暗礁"。自己新写的系统,一开始八成能顺利跑起来，但遇到这些极端情况会不会翻车，是完全没有被时间验证过的。而 AI 帮你把代码写得更快，并不会让"两个人同时点审批按钮"这种问题自动消失------它只是让你更快地写出一个还没被验证过的东西。
一个简单的判断框架
想清楚这两条路各自的坑之后，其实可以提炼出几个问题，用来判断具体该走哪条路。
先问三个问题，符合任何一条，就优先考虑用现成的：
1、这是一个"全世界都要解决"的标准问题，而且需要和外部系统对话吗？
比如登录认证、支付、文件格式这一类。这类问题的价值不在于"代码写起来快不快"，而在于标准本身：全世界都用同一套规则，工具链是现成的，出了问题网上一搜就有答案，招人也好招。自己另起一套,等于把自己隔离在"通用语言"体系之外，以后想和别的系统对接，还得再造一次翻译层。
2、它的难点是不是那种"看不见的系统级风险"------高并发、数据一致性、长期稳定运行？
如果是，优先用现成的。这类正确性问题的解决靠的是时间和真实场景的积累，不会因为写代码的速度变快而变得容易。
3、未来要不要开放给别人自由折腾、你完全没法预判会被怎么用？
如果要，优先用现成的、有理论基础的通用方案。你猜不到所有的用法，但成熟的标准方案经过多年打磨，覆盖面早就比你能想到的多得多。
反过来，如果符合下面这些情况，自己写往往是更划算的选择：
1、真正的难点是"我们自己独有的规则"，这套规则本身不是什么行业共识，套用现成框架反而要一直在两种语言之间来回翻译，翻译本身就是长期负担；
2、需求边界清楚、场景可以数得过来，不追求"能表达任何可能性"；
3、这部分东西本来就会被频繁修改------业务规则天生易变的地方，自己写改起来没有"这是别人的框架，改动要小心"的心理负担。
AI 真正改变的是什么
这里有个容易被忽略、但我觉得挺关键的点：AI 辅助编程改变的，不是"该不该用现成框架"这个判断标准本身，而是"自己写一套"的成本曲线。
过去，自己写一套东西成本很高------要花很多时间写代码，还要长期维护，所以哪怕现成框架不太贴合自己的业务，团队往往也会捏着鼻子将就用，因为自己重新写一遍的代价更大。现在,AI 把"把代码写出来"这一步的成本压得很低了,于是对上面说的"业务规则强相关、经常变化"这一类场景,"自己写"这个选项的性价比比过去明显提高了，值得被认真放到台面上比较，而不是想都不想就默认用现成的。
但对于"标准协议"和"系统级正确性问题"这两类场景，结论并没有变。AI 帮你省下的是写代码的力气，省不掉的是别人过去很多年、在真实世界里踩过的那些坑。这些经验积累，不会因为你的代码写得更快，就自动出现在你新写的系统里。
一句话总结
选现成的，还是自己写，问题从来不是"我现在写代码快不快"，而是"这个难点，到底是需要时间和规模验证的正确性问题，还是需要贴合我自己业务的定制问题"。前者交给专业的现成方案，后者现在可以更放心地自己动手了。