宝玉谈Vibe Coding：模块应按“什么会变”划分

如今 Vibe Coding 盛行，然而就算是用 AI 写代码，也少不了要考虑如何划分好模块、保障低模块之间耦合以及系统的拓展性。 如何划分好模块这些事是传统软件工程和架构设计范畴，但你做好了的话，AI 生成的代码质量更高系统也更稳定。 很多新手对于如何划分模块并没有什么概念，甚至很多编程老手也只是直觉知道怎么分，但也讲不出个所以然。 一句话：模块按“什么会变”来分，不是按“先做什么后做什么”来分 新手容易犯的一个错误是按照流程来划分模块。 拿电商网站来说，购物流程是：用户下单，先收到请求，再算钱，再扣款，再存库，再发邮件。 如果你把每个步骤拆成一个模块，当然可以，但是这其实并不利于后续的维护。 顺着步骤分，改动会顺着步骤一路扩散。举个例子，你想给订单加一个“预计送达时间”，收到请求要处理这个字段、算运费要用到它、存库要存下来、发邮件要显示它，四个步骤都会受影响，如果不小心漏掉一个地方还会出问题。 好的做法是：先列出将来最可能变的东西，然后把每一个会变的东西放到一个模块里，外面的人看不到它是怎么实现的，把信息隐藏起来。 比如说前面那个购物的例子，电商网站里会变的东西有： - 支付渠道（今天支付宝，明天加微信，后天做海外要接 Stripe） - 优惠规则（运营隔三差五改一次） - 通知方式（邮件、短信、App 推送） - 数据存哪里（MySQL 换 PostgreSQL）。 这么分下来，支付、优惠、通知这些都可以单独做成模块，各自的变化都只影响自己的模块，不会影响其他地方。比如说你要给数据库加一层缓存，只要改数据存储模块就好了，其他模块都不受影响。 要是你觉得太复杂，也可以简单的按业务功能分，因为会一起变的东西通常就属于同一个功能，所以按功能分一般不算错。 但不要按步骤分模块，这样会把本来应该放在一起的生生按照顺序拆开了。 判断标准很简单：一个需求改动来了，你需要动几个模块？理想情况是一个。 要是运营改个优惠规则要同时动好几个文件，说明模块分错了。 按照这种“什么会变”的方式拆分模块对 AI 来说也是最友好的，因为 AI 本来就受限于上下文窗口长度，如果一个变更只要在一个模块内部就能解决，那么需要的上下文会少很多。