最近 vibe code 很爽，但是很明显的是产生了不少技术债？
感觉每次都像新入职了一个公司，接手一堆史山代码。
请问各位现在还会读 ai 产生的代码么？还是 ai 拉 ai 吃？
第 1 条附言 · 5 月 21 日
补充下，本人跟车规行业有关。
vibe code 如果产生了技术债，不是事后道歉那么简单。
而是主机厂会抓着一行一行要求解释原因。
甚至部分代码会更人命有关，比如某某新能源车，打不开门。
 |
1 tf2 5 月 21 日vibe review vibe refactor |
 |
2 sentinelK 5 月 21 日 5
正向编程，AI 生成的方案你都过一遍，不是自己熟悉或者预期的技术选型，就都否决让他去改。或者你给个建议。 btw：其实目前 Agent 的模式很类似团队管理。要用管理的思维去驱动 Agent 。 |
 |
3 lujiaosama 5 月 21 日 3
粗犷一点就是 TDD 驱动，只要能过测试，写成啥都不管。否则最好就是限定 AI 使用的技术方案，就算丑一点臃肿一点也绝不为了所谓的优雅引进一堆自己都看不懂的东西。 |
 |
6 qxmqh 5 月 21 日你要这样想：人就不会写屎山代码了吗。 有 AI 还能给你说明白至少，之前没有 AI 的时候，不都是一点一点硬啃的吗 |
 |
7 maskerTUI 5 月 21 日AI 能看懂 AI 的代码就行了，人类能不能看懂不重要，有问题让 AI 重新写。 |
 |
8 v2gba 5 月 21 日每天几千行 还不算同事发来的 咋读 即使我不想要这些 tech debt 但是历史的车轮已经碾过 我也被车轮带着走了 |
 |
9 lwep 5 月 21 日相信 AI 的发展 |
 |
11 malusama 5 月 21 日大部分代码需求时间都只有几年而已， 债不债的到时候业务都不存在了。 代码都没用了就没有债了 |
 |
12 NerbraskaGuy 5 月 21 日程序员可以承受 AI 浪潮带来的淘汰，那公司也得可以承受 AI 带来的巨量屎山，大家都有“美好”的未来 |
 |
13 nettest 5 月 21 日类似于在问如何消除 高级语言 产生的技术债 |
 |
14 wsseo 5 月 21 日 2
如果是测试驱动会埋很多雷。研发想绕过测试埋雷太容易了。测试很多情况根本覆盖不到。 |
 |
16 teaguexiao 5 月 21 日 1
现在的做法是每隔一段时间让 Claude Code 自己做一次‘代码回顾’，把高复杂模块重构掌。关键是 CLAUDE.md 要把架构决策和禁止事项写清楚，不然下一轮 AI 也会重蹈覆辙。 |
 |
17 lscho 5 月 21 日 via Android 1
人写就没有技术债了吗？你接手别人写的代码，一样是屎山 放下心里包袱，只要能过测试，有文档，它就是好代码 |
 |
18 chenluo0429 5 月 21 日 via AndroidAI 生成 |
 |
19 sharpy 5 月 21 日根本 review 不过来啊 让 ai 来吧 |
 |
20 youyouzi 5 月 21 日ai 的技术栈不应该让 ai 消除吗？ 比如你现在用 cc4.5 产生的技术栈，让 4.7 去解决啊，你操 AI 的心干啥呢？相信后人的智慧就行了。 |
 |
21 quake0day 5 月 21 日 1
AI 时代就要遵循 KISS 原则，尽量把大系统拆成小块，然后都让 AI 来开发，再让 AI 组合。 这样后续维护会简单许多。 |
 |
23 thedog 5 月 21 日让 ai 重写。 千万不要想着重构。ai 只会重写。 |
 |
24 someonesnone 5 月 21 日 via Android如果是个小头目, 手下的人就不会写屎山代码吗, 需要亲自都审查一遍吗 |
 |
26 lonelykid 5 月 22 日 4
跟人命有关的代码还敢完全交给 AI 写？不人工 review 几遍？ |
 |
29 ragnaroks 5 月 22 日 1
大型项目基本不具备人类可维护性，项目稳定长期维护的话可以参考 AI 代码人类重写一个 |
 |
30 WispZhan 5 月 22 日 via Android 1
你把 AI 当成一个同事，难道不会 review 他代码然后让它改么？ 真有人把 AI 当替代思考的工具，弥补自己认知上的差距，而不自知吗？ 现在 AI 写代码，其实和十几年前聊软件工程和过程管理一摸一样 |
 |
31 GeminiPro 5 月 22 日实际上，就是都奔着用一段时间就废掉的想法，对于基础架构，vibe coding 可能带来大问题。 |
 |
32 reavid 5 月 22 日大家对都 AI 有迷之自信。 |
 |
34 Kevin2 5 月 22 日 via AndroidAI 拉的也比人类拉的好，拉的优雅 |
 |
35 walkon 5 月 22 日你们团队没有 Review 机制吗？ AI 写得代码也可以做得更好 Review 的，人的 Review 压力其实没那么大。 |
 |
36 gkiwi 5 月 22 日 1
vibe 出来的自动驾驶么。。 |
 |
38 gogozs 5 月 22 日都 vibe coding 了，还需要管技术债么，那越 vibe coding ，效率越低？ |
 |
40 connor123 5 月 22 日 1
看起来上面的各位都不 review ai 写的代码，测试能过即可？就我观察下来，ai 好像基本都是 api 调用相关的 test plan ，跟业务基本没啥关系啊 |
 |
41 Skifary 5 月 22 日 2
楼上一堆 AI 的债 AI 还，那 AI 还不了咋办，跟主机厂解释这是 AI 的问题，让主机厂去找 AI ？ |
 |
43 cando 5 月 22 日以后就炒嘘头，全手工打磨项目，每一行代码都能追溯，项目中的劳斯莱斯 |
 |
44 misaka20 5 月 22 日真的有那么多人代码写的很牛逼吗？动不动就屎山的，觉得哪里有问题，让 AI 重构一下就行了，整体来说比大部分人好多了。 |
 |
47 msg7086 5 月 22 日 1
爆论，活人写的代码不一定技术债比 AI 少。 举个例子，我在做一个反编译器，起手设计的时候，IR/CFG/Surface 三阶段开始写代码。等你写了几百个提交了你就会发现 CFG 和 Surface 臃肿不堪需要开始重构了，那么这时候再考虑架构拆分，比如增加辅助数据，CFG 判断部分单独拉出来一个包，Surface 拆分，添加调试工具，等等。 难道你让活人来做，他就能一开始就预料到半年一年以后架构上出现的问题吗？ |
|
48 msg7086 5 月 22 日> vibe code 如果产生了技术债，不是事后道歉那么简单。 如果 AI 产生了技术债，难道不是让 AI 立刻开始重构修复然后补强测试用例吗。 |
|
49 msg7086 5 月 22 日@Skifary 本来程序员的债程序员还，那程序员还不了咋办，主机厂难道还能把程序员枪毙了不成？难道不是在上面把关的 PM TL VP CTO 的锅吗。 要真是把员工全扔了，就公司老总一个人坐在电脑前开着 AI 搞 vibe ，那确实老总全责。 |
 |
50 poxiaohy 5 月 22 日 1
你这样想，如果你是技术 Leader 管着 N 个开发，你也不可能每个开发的逐行代码去 review 。 |
 |
51 wwtest 5 月 22 日细化颗粒度呗 一个函数一个函数得写 每一行都自己 review |
 |
52 LeeeeexPRO 1
前期头脑风暴的时候讨论清楚，细致到数据流动是怎么做的，方法功能怎么实现。落地成文件。 |
|
53 LeeeeexPRO 1
但是讲道理，我这 vibe 出来的垃圾代码，最多服务器爆炸。 |
 |
56 Plutooo 5 月 22 日写完不人工 review 吗？ |
 |
57 ximaoyang 5 月 22 日 1
很多人 vibe code 就是让野生 AI 开始自己乱写。这样只会把自己搞死。 通俗版： 专业版： |
 |
58 rainescain 5 月 22 日既然 AI 是 LLM 大模型，也就是说有概率性的，那么有时候肯定是有更好的版本，测试迭代优化，不断筛选最好的版本，最终的效果会不会比人类平均值高的多。 |
 |
59 nofishing 5 月 22 日AI 写的所有代码和文档，再不济我都会肉眼扫一遍，经常闲着没事干时候我会盯着 AI 思考和代码输出。有点保守了 |
|
60 msg7086 5 月 22 日 1
@rainescain |
 |
61 beimenjunPRO 1
我觉得多数人用的都不对。 LLM 写的代码，是应该多模型多角度多轮的 LLM Review 来支持的。 就是大水漫灌。 LLM 有点像那么一种东西：在你熟悉的领域，你可以很轻松靠它提升效率，在你不熟悉的领域，你企图驾驭它其实是进入一种过载的状态。 有这个问题其实就是进入过载状态了，那你就不该试着驾驭它。 |
 |
62 NoKey 5 月 22 日如果是全 ai ，那么 ai 写，ai 检视，ai 改 bug ，理论上就不应该要求人去理解 |
 |
63 tengxun 5 月 22 日这么严重,你 d 还敢用 ai? |
 |
65 chinni 5 月 23 日套娃就可以了 vibe vibe coding, vibe vibe vibe coding.... |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
