Tony Dinh (@tdinh_me) :
My product codebase would have been so much different if I had started it today instead of in 2023.
I'm a solo founder so I used a lot of "trade-offs" to cut dev time and optimize for delivery speed. Most of that no longer makes sense today.
So tempted for a rewrite.
Solo founder 们，该回头看一眼那些排队等着重构的旧代码了。
很多等着重构的旧代码在当时其实不算错误，反而是合理选择。那时候你一个人做产品，要验证需求，要赶上线，要接支付，要做登录，要写后台，要修 bug，还得发内容、做增长、回用户消息。你当然会做 trade-off，也当然会先把一些东西写死，先用自己最熟的技术栈，再告诉自己一句：先跑起来，以后再优化。欠的技术债越来越多
问题是，到了 2026 年，“以后” 真的来了。
Tony Dinh 最近提到，如果他今天才开始写自己的产品代码，整个架构会和 2023 年完全不同。当年那些为了缩短开发时间做出的折衷，放到今天，很多已经不再成立了。
这里真正变掉的，其实是 AI Coding 工具把重构这件事的成本打下来了。
过去你不敢动旧代码，很多时候不是你没看见问题，是你很清楚，重构太贵了。
贵在你要先读懂旧代码。
贵在你要拆模块。
贵在你要补类型。
贵在你要迁移数据。
贵在你要写测试。
贵在你既是 CTO，也是客服、产品、增长和运营……
所以很多 solo founder 的真实状态其实都差不多。
你知道代码库越来越脏，但产品还在赚钱，就先忍着。 你也知道某个模块已经没人敢碰，但用户还没投诉，就先绕过去。 你还知道当年的架构撑不住下一阶段，但今天功能还能上线，就先假装没看见。这不是懒，是资源约束下很正常的选择。
但 AI 出来之后，情况已经不太一样了。以前，重构更像一项高成本工程。现在，它开始有点像一种低成本的维护动作。
以前一个类型系统迁移，可能会让你难受几周；现在，AI 可以帮你逐步补类型、拆文件、生成测试、解释依赖、标记风险点。以前清理一个历史模块，得先花两天把上下文读明白；现在，你可以先让 AI 画出数据流、调用链、模块边界和潜在副作用。
它没有替你做决定，但它确实把很多过去最贵、最烦、最容易拖着不做的脏活累活，往下压了一截。
以前你重构，像在黑夜里拆炸弹。现在至少有人给你递了手电筒。
别把 “重构” 做成 “重写”
这也是很多人最容易犯的第一个错。
重写很爽。尤其对 founder 来说，重写特别容易制造一种危险的 “生产力幻觉”。
你会觉得自己终于在做一件重要的事，会觉得新的技术栈更优雅，觉得这次总算能把架构设计干净。
“等我重写完，产品就能进入下一个阶段了”。
但用户不会因为你的代码从 JavaScript 变成 TypeScript 就多付钱。客户也不会因为你的目录结构更符合 Clean Architecture 就少流失一些。
如果一次重写没有减少真实维护成本，没有提升交付速度，没有降低线上故障，也没有解锁关键功能，那它就不是重构。它更像是程序员版的整理桌面：看上去很忙，实际上是在逃避增长。
所以真正该问的问题不是：“我该不该重写？” 而是：“哪些技术债，已经在真实拖慢我的业务？” 这才是 AI 时代的 solo founder 更该问的问题。
不是所有技术债都该清，先找那些一直在收税的地方
你不需要把整个系统翻新一遍。你真正需要动的，是那些正在持续收税的模块。什么叫持续收税？
每次加功能都要绕一圈的模块。
每次上线都担心炸的模块。
每次用户投诉都查不清原因的模块。
每次改一点东西就连着牵动三处的模块。
没有类型、没有测试、没有边界，但已经在核心业务路径上的模块。
这些地方，才是应该优先清理的技术债。
反过来，那些 “看起来不优雅，但已经稳定跑了半年” 的代码，未必是现在最该处理的问题。
对 solo founder 来说，最危险的其实是你分不清两类债：一类只是审美问题，一类已经开始消耗现金流。前者可以先忍。后者一定别拖着。
过去很多人把技术债放进 “以后再说” 这一栏，不是他们不知道问题在哪，主要还是因为清理成本太高。现在 AI 把这个成本打下来了，接下来很现实的变化就是：越来越多的 solo founder，会在产品验证跑通之后，更愿意尽快回头把核心路径修到可持续状态。
2023 年常见的打法是，先粗糙上线，能卖再说。 而现在更合理的打法，可能会变成：先粗糙上线，验证之后立刻借助 AI 把核心路径修到能长期维护的状态。
代码库不是作品集，它就是你的生产系统
很多人做独立产品时，嘴上会说一句很对的话：“用户不关心技术。” 这句话本身没错，但它经常被用来掩盖另外一些事：用户确实不关心你用什么框架，不关心你的架构漂不漂亮，也不关心你的代码是不是符合某种工程审美。但用户关心速度和稳定，关心你能不能更快响应需求。
技术债最后一定会绕一圈，回到用户体验上。它不会穿着 “技术债” 的衣服出现，它通常会伪装成几种更具体的东西：功能交付越来越慢、bug 越修越多、新需求评估越来越保守、你越来越不敢碰自己的核心代码。这才是最糟糕的信号。
一个 Solo founder，如果开始害怕自己的代码库，产品基本就进入慢性死亡了。
AI 不会让所有人都变成顶级工程师，但它确实会让 “我没时间清技术债” 这个借口越来越站不住。以前不清，很多时候是真的贵。现在还完全不清，很多时候只是你不想面对自己当初留下来的坑。更准确一点说，AI 没有消灭技术债，它消灭的是技术债的借口。
真正务实的做法，是先给代码库做一次体检
但重构也不能变成新的拖延症。
最好的策略从来都不是 “全盘重写”。更稳妥的做法，是先做一次代码库体检，然后按业务价值和维护痛苦程度，把问题分开看。
第一类：高价值、高痛苦 —— 立刻重构。
这是核心业务路径，也是你每天被它折磨的地方。比如支付、权限、订单、用户数据、核心生成流程。
第二类：高价值、低痛苦 —— 保持稳定，只补测试和监控。
它已经在赚钱，别为了 “更优雅” 乱动。
第三类：低价值、高痛苦 —— 砍掉，或者彻底隔离。
这类功能最坑人。用户不怎么用，你却要一直维护，删掉往往比美化更值。
第四类：低价值、低痛苦 —— 先放着。
别把人生和 Token 浪费在整理那些不会影响业务的角落。
真正成熟的 Solo founder，不会一看到旧代码就想重写。他知道哪些地方必须动，哪些地方现在绝对不能碰。
最后
Tony Dinh 这条推文指出的，不只是 “他想重写代码” 这件事本身，更是它提醒了我们一个已经发生的变化：AI Coding 正在给过去那些工程折衷重新定价。
2023 年，一个 solo founder 为了速度牺牲架构，很合理。
2026 年，如果你还拿同一套理由拒绝清理核心系统，那未必还是理性，很多时候只是惯性。
可能是懒，也可能是你对自己的产品已经失去掌控感，只是不愿意承认。
别浪漫化技术债。也别浪漫化重写。
更务实的做法其实很简单：用 MVP 的速度验证市场，用 AI 的能力偿还关键技术债，用产品收入决定重构优先级，用用户痛点判断工程动作值不值得做。
代码不是越新越好，架构也不是越漂亮越好。对 solo founder 来说，最重要的始终只有一件事：你的代码库，能不能继续支撑你更快地赚钱、更稳地交付、更低成本地迭代。
如果不能，那就别再骗自己了，立刻审查自己的项目，然后开始动手结清技术债。因为现在清它，真的便宜多了。
如果对您有所帮助，欢迎添加本站到收藏夹，也欢迎微信搜索公众号 半山数字札记 ，我会持续更新新的内容。
如果你也在做个人项目、优化工作流，或者只是想找一群折腾工具和内容的人交流，可以添加我的微信，备注「半山」，我会邀请你进群，欢迎一起探讨，一起交流。
