Vibe Coding 时代，到底什么时候该用现成框架，什么时候该自己写？ - 编程一生
内容提要
在Vibe Coding时代，是否使用现成框架取决于问题性质。若涉及标准协议、系统级风险或不可预知的使用场景，应优先用现成方案；若难点在于独特且易变的业务规则，自己写更划算。AI降低了编码成本，但无法替代时间验证的积累，判断标准不变。
延伸解读
判断框架的适用边界
文章提出的三个“优先用现成”的条件（标准协议、系统级风险、不可预知的使用场景）和三个“自己写”的条件（独有规则、边界清晰、频繁修改）并非绝对，而是基于对两类坑的权衡。实际决策时，还需结合团队维护能力、项目周期和长期演进需求，不能仅凭单一条件下结论。
AI 降低的是实现成本，而非验证成本
AI 辅助编程显著降低了“把代码写出来”的成本，但并未降低“验证系统正确性”的成本。对于高并发、数据一致性等系统级问题，其正确性依赖长期真实场景的检验，AI 无法替代这种时间积累。因此，在涉及此类风险的场景，现成框架的成熟度仍是关键考量。
翻译层的隐性维护负担
使用现成框架时，业务规则与框架通用抽象之间的“翻译层”常被低估。它看似小补丁，却因频繁应对业务变化而成为 bug 高发区。若业务规则独特且多变，翻译层的长期维护成本可能超过自研成本，这正是“自己写”在特定场景下性价比提升的原因。
Q&A
在Vibe Coding时代，什么时候应该优先使用现成的开源框架？
当问题涉及标准协议（如登录认证、支付、文件格式）、系统级风险（如高并发、数据一致性、长期稳定运行）或不可预知的使用场景时，应优先使用现成框架。这些问题的解决依赖于时间和真实场景的积累，AI降低编码成本并不能替代这种积累。
在Vibe Coding时代，什么时候自己写代码更划算？
当真正的难点是公司独有的、易变的业务规则，需求边界清楚、场景可数，且这部分代码会被频繁修改时，自己写更划算。因为套用现成框架需要不断在业务规则和框架通用语言之间翻译，长期负担重；而自己写则没有修改他人框架的心理负担。
用现成工作流引擎做审批系统的主要坑是什么？
主要坑是业务规则与框架的通用语言对不上。开源框架为了通用性，使用抽象模型描述审批，但公司内部的具体规则（如换领导、组织调整、多人会签）难以直接映射，需要额外编写翻译代码，这部分代码容易出bug，且业务规则变化时需频繁修改。
自己写审批流转系统有哪些看不见的坑？
自己写系统可能遇到并发问题（如两人同时点击审批）、系统升级时未完成流程的处理、长期审计记录的数据可靠性等。这些问题需要长时间和真实场景的验证才能暴露和修复，新写的系统缺乏这种验证，AI加速编码并不能解决这些系统级风险。
AI辅助编程改变了什么？没有改变什么？
AI辅助编程改变了“自己写一套”的成本曲线，使得业务规则强相关、经常变化的场景下自己写的性价比提高。但没有改变判断标准本身，对于标准协议和系统级正确性问题，结论不变，因为AI省不掉别人过去多年在真实世界踩坑积累的经验。
选现成框架还是自己写，核心判断标准是什么？
核心判断标准是：难点是需要时间和规模验证的正确性问题，还是需要贴合自身业务的定制问题。前者应交给专业的现成方案，后者可以更放心地自己动手。
