如何消除 vibe code 产生的技术债？

[Tilie]

最近 vibe code 很爽，但是很明显的是产生了不少技术债？
感觉每次都像新入职了一个公司，接手一堆史山代码。
请问各位现在还会读 ai 产生的代码么？还是 ai 拉 ai 吃？

补充下，本人跟车规行业有关。
vibe code 如果产生了技术债，不是事后道歉那么简单。
而是主机厂会抓着一行一行要求解释原因。
甚至部分代码会更人命有关，比如某某新能源车，打不开门。

[tf2]

vibe review

vibe refactor

[sentinelK]

正向编程，AI 生成的方案你都过一遍，不是自己熟悉或者预期的技术选型，就都否决让他去改。或者你给个建议。

btw：其实目前 Agent 的模式很类似团队管理。要用管理的思维去驱动 Agent 。

[lujiaosama]

粗犷一点就是 TDD 驱动，只要能过测试，写成啥都不管。否则最好就是限定 AI 使用的技术方案，就算丑一点臃肿一点也绝不为了所谓的优雅引进一堆自己都看不懂的东西。

[niubilewodev]

让 AI 重写。

[beyondstars]

技术债不是技术问题，技术债是管理问题。

[qxmqh]

你要这样想：人就不会写屎山代码了吗。 有 AI 还能给你说明白至少，之前没有 AI 的时候，不都是一点一点硬啃的吗

[maskerTUI]

AI 能看懂 AI 的代码就行了，人类能不能看懂不重要，有问题让 AI 重新写。
按照现在的大模型迭代速度，大不了明年让更好的 AI 重写现在写出来的屎山即可。

[v2gba]

每天几千行 还不算同事发来的 咋读

即使我不想要这些 tech debt

但是历史的车轮已经碾过

我也被车轮带着走了

[lwep]

相信 AI 的发展
AI 欠的债 AI 来还

[erwin985211]

主要是大部分公司的生存时间都不足以产生技术债

[malusama]

大部分代码需求时间都只有几年而已， 债不债的到时候业务都不存在了。 代码都没用了就没有债了

[NerbraskaGuy]

程序员可以承受 AI 浪潮带来的淘汰，那公司也得可以承受 AI 带来的巨量屎山，大家都有“美好”的未来

[nettest]

类似于在问如何消除 高级语言 产生的技术债

[wsseo]

如果是测试驱动会埋很多雷。研发想绕过测试埋雷太容易了。测试很多情况根本覆盖不到。

[Rever4433]

等到代码即时生成时代来临的时候就没有技术债了

[teaguexiao]

现在的做法是每隔一段时间让 Claude Code 自己做一次‘代码回顾’，把高复杂模块重构掌。关键是 CLAUDE.md 要把架构决策和禁止事项写清楚，不然下一轮 AI 也会重蹈覆辙。

[lscho]

人写就没有技术债了吗？你接手别人写的代码，一样是屎山

放下心里包袱，只要能过测试，有文档，它就是好代码

[chenluo0429]

AI 生成
AI 分析
AI 消除
AI 提交
AI review

[sharpy]

根本 review 不过来啊

让 ai 来吧

[youyouzi]

ai 的技术栈不应该让 ai 消除吗？

比如你现在用 cc4.5 产生的技术栈，让 4.7 去解决啊，你操 AI 的心干啥呢？相信后人的智慧就行了。

[quake0day]

AI 时代就要遵循 KISS 原则，尽量把大系统拆成小块，然后都让 AI 来开发，再让 AI 组合。 这样后续维护会简单许多。

[johnkyle]

只能让 AI 来还这个债了

[thedog]

让 ai 重写。 千万不要想着重构。ai 只会重写。

[someonesnone]

如果是个小头目, 手下的人就不会写屎山代码吗, 需要亲自都审查一遍吗

[zomco]

无法消除的。

[lonelykid]

跟人命有关的代码还敢完全交给 AI 写？不人工 review 几遍？

[yjiefl]

graphify

[unusualcat]

那就一个公司干半年就跑路，然后找下一个工作

[ragnaroks]

大型项目基本不具备人类可维护性，项目稳定长期维护的话可以参考 AI 代码人类重写一个

[WispZhan]

你把 AI 当成一个同事，难道不会 review 他代码然后让它改么？

真有人把 AI 当替代思考的工具，弥补自己认知上的差距，而不自知吗？

现在 AI 写代码，其实和十几年前聊软件工程和过程管理一摸一样

[GeminiPro]

实际上，就是都奔着用一段时间就废掉的想法，对于基础架构，vibe coding 可能带来大问题。

[reavid]

大家对都 AI 有迷之自信。

[Lin0936]

https://github.com/mattpocock/skills/tree/main/skills/engineering/improve-codebase-architecture

[Kevin2]

AI 拉的也比人类拉的好，拉的优雅

[walkon]

你们团队没有 Review 机制吗？ AI 写得代码也可以做得更好 Review 的，人的 Review 压力其实没那么大。

[gkiwi]

vibe 出来的自动驾驶么。。

[fennu2333]

我做了几个月的 Harness 之后最大的感受就是要左移，技术债是消除不完的，在对齐需求和规划阶段尽量遏制额外引入技术债比较现实。我通过自己写工具 https://github.com/Chorus-AIDLC/chorus 把 vibe 时候的大部分精力放在前期对齐和规划，等到编码阶段你已经很难去控制 AI 的行为了

[gogozs]

都 vibe coding 了，还需要管技术债么，那越 vibe coding ，效率越低？

[niubiman]

@tf2 完美, 一键三连了属于是

[connor123]

看起来上面的各位都不 review ai 写的代码，测试能过即可？就我观察下来，ai 好像基本都是 api 调用相关的 test plan ，跟业务基本没啥关系啊

[Skifary]

楼上一堆 AI 的债 AI 还，那 AI 还不了咋办，跟主机厂解释这是 AI 的问题，让主机厂去找 AI ？

[kapaseker]

哪管身后洪水滔天

[cando]

以后就炒嘘头，全手工打磨项目，每一行代码都能追溯，项目中的劳斯莱斯

[misaka20]

真的有那么多人代码写的很牛逼吗？动不动就屎山的，觉得哪里有问题，让 AI 重构一下就行了，整体来说比大部分人好多了。

[haonanaaaaaa]

@cando 以后穷人都有 vibe code 的工具，富人才能用纯手工代码工具。

[Hudiebbk]

@beyondstars 同感

[msg7086]

爆论，活人写的代码不一定技术债比 AI 少。
上面 @teaguexiao #16 说的就很好，一个是做项目之前要加好门禁，一个是阶段性回顾架构上的问题然后重构。
有些东西你不做到一定程序是没法说要不要重构了。

举个例子，我在做一个反编译器，起手设计的时候，IR/CFG/Surface 三阶段开始写代码。等你写了几百个提交了你就会发现 CFG 和 Surface 臃肿不堪需要开始重构了，那么这时候再考虑架构拆分，比如增加辅助数据，CFG 判断部分单独拉出来一个包，Surface 拆分，添加调试工具，等等。

难道你让活人来做，他就能一开始就预料到半年一年以后架构上出现的问题吗？
更大的可能是要么项目没做大就死掉了，要是没死那就常年在屎山架构上堆。技术债？你见过多少大公司把做了上千个提交十万行以上的项目从架构级别推倒重构的。

[msg7086]

> vibe code 如果产生了技术债，不是事后道歉那么简单。
那人写的代码出了问题呢，难道事后道歉就行了？

如果 AI 产生了技术债，难道不是让 AI 立刻开始重构修复然后补强测试用例吗。
反倒是人写出了 bug ，等你发现 bug 多了然后你就根本改不过来了。

[msg7086]

@Skifary
AI 还不了那就是管 AI 的项目经理的问题。

本来程序员的债程序员还，那程序员还不了咋办，主机厂难道还能把程序员枪毙了不成？难道不是在上面把关的 PM TL VP CTO 的锅吗。
怎么到 AI 时代了，就把 PM TL VP CTO 全扔了呢。

要真是把员工全扔了，就公司老总一个人坐在电脑前开着 AI 搞 vibe ，那确实老总全责。

[poxiaohy]

你这样想，如果你是技术 Leader 管着 N 个开发，你也不可能每个开发的逐行代码去 review 。
就像 Karpathy 说的，都 2026 了，Vibe Coding 思路要转变为 Agentic Engineering 。制定好开发规范，做好架构师和技术管理工作。
至于类似制动系统、转向控制、车门解锁等人命相关代码，还是需要人工 review ，甚至要单独拉出来开技术讨论会的。

[wwtest]

细化颗粒度呗 一个函数一个函数得写 每一行都自己 review

[Leeeeex]

前期头脑风暴的时候讨论清楚，细致到数据流动是怎么做的，方法功能怎么实现。落地成文件。
写完之后人工 review 一遍，我的做法就是看代码写注释，不懂的地方就在注释里面问。然后让 AI 看我注释的理解对不对，回答一下问题。
就算这样我也只能保证自己懂了 AI 是怎么写的，但是不能保证自己能写出来同样的代码。

[Leeeeex]

但是讲道理，我这 vibe 出来的垃圾代码，最多服务器爆炸。
你那 vibe 出来的代码，真可能出人命啊，真得做好人工兜底吧。

[sn0wdr1am]

vibe 出来的问题，vibe 负责解决。

[haha1903]

/simple

[Plutooo]

写完不人工 review 吗？

[ximaoyang]

很多人 vibe code 就是让野生 AI 开始自己乱写。这样只会把自己搞死。

通俗版：
其实 vibe coding 是一个养猫的过程。它是一只猫🐱。一开始它生成一点点代码你就要一行一行的看，单元测试也是一行一行的看，然后把规则加到 CLAUDE.md 里面。你也是一个铲屎官。每天铲它拉出来的屎山代码。
这个过程要持续很久。等养了一段时间之后，它写的代码就可以比较放心了。但是最好也别让他直接推 PR 上去。尽量还是自己看一下。

专业版：
用 Human in the loop 来控制智能体必然会产生的架构偏移，减缓软件熵的增长，从而做出可维护的系统。

[rainescain]

既然 AI 是 LLM 大模型，也就是说有概率性的，那么有时候肯定是有更好的版本，测试迭代优化，不断筛选最好的版本，最终的效果会不会比人类平均值高的多。

[nofishing]

AI 写的所有代码和文档，再不济我都会肉眼扫一遍，经常闲着没事干时候我会盯着 AI 思考和代码输出。有点保守了

[msg7086]

@rainescain
正常做项目，已经是 PRD 起手，TDD 测试先行，然后前期把 memory-bank 建起来以后，就差不多到顶了。概率性无非也是在这个框架下的概率，写成什么样都不会差太远的，你会发现不同的概率下无非就是回字的不同写法而已。

[beimenjun]

我觉得多数人用的都不对。

LLM 写的代码，是应该多模型多角度多轮的 LLM Review 来支持的。

就是大水漫灌。

LLM 有点像那么一种东西：在你熟悉的领域，你可以很轻松靠它提升效率，在你不熟悉的领域，你企图驾驭它其实是进入一种过载的状态。

有这个问题其实就是进入过载状态了，那你就不该试着驾驭它。

[NoKey]

如果是全 ai ，那么 ai 写，ai 检视，ai 改 bug ，理论上就不应该要求人去理解
如果是半 ai ，那么，它产生的代码是不是需要人工检视再合入？人员是不是要去理解 ai 到底怎么写的？
我觉得，很多公司还没搞清楚这个事情
然后呢，管理向上汇报，我们用 ai 啦，巴拉巴拉，kpi 到手
底层开发测呢，还战战兢兢的用着，就怕哪天堆个大的
看最后砸在谁手里~

[tengxun]

这么严重,你 d 还敢用 ai?

[Tilie]

@tengxun 结构性问题，不是你不想用就不用的。

[chinni]

套娃就可以了 vibe vibe coding, vibe vibe vibe coding....