vibe coding 让我对代码的掌控力越来越弱了

[duhbbx1119]

Claude Code 确实猛，堆功能的速度堪称咔咔咔。
但随着功能越堆越多，代码越来越厚，对项目的掌控感却越来越薄。
以前写 Java ，功能模块、业务逻辑基本了然于胸，调试过无数遍的代码，闭着眼睛都知道走哪条路径。
现在变成了：给指令 → 看结果 → 不对再调。至于代码长什么样、逻辑怎么跑的，基本不管了。
一个人扛客户端、管理后台、后端，代码量每天在涨，看代码的时间却越来越少。
AI 越强，功能加得越快。功能加得越快，对代码就越陌生。
这是一个让人又爽又不安的循环。

现在都做不到耐心的看完一段代码逻辑，因为太多了

[houshengzi]

所以 AI 写代码那么快，后期代码堆叠得越来越多，没人工介入 review ，会不会成💩屎山

[stinkytofux]

以前一个函数名称觉得词不达意都会修改, 现在谁还会管这些.

[kulove]

大致扫一下 应该也能理解个差不多吧

[kalman03]

看不懂的时候，叫 AI 来帮忙总结看，再说代码本来是给机器看的

[codermagefox]

我反而觉得这是个好事。
原因很简单，LLM 可能每年都会强 50%，你的编码能力一定不会每年强 50%。
所以最终，你会变成阻碍它的障碍。你的架构能力和设计能力才是它缺乏的。
如果这是结局，那么我们应该为结局准备，而不是为现在准备。

[sillydaddy]

我来打消你的疑虑：只需要设想你是一个老板。

你安排手下做事，有管财务的、有管人事的、有管销售的、有管技术研发的，这些领域，你不可能都门儿清，对吧？至少，一般的老板是不懂技术的。那么你怎么授权并信任这些人去做事呢？

1 是看结果。事物是因果驱动的，种善因结善果，没有金刚钻就做不了瓷器活。看 AI 执行的结果，就知道它的功力是不是足够。一个功力不足的 AI ，靠拆东墙补西墙的底层架构，是不能让结果持续满意的。反过来就是说，如果结果持续令你满意，那它的底层实现，大概率也会让你满意。如果你觉得等待结果失败的时间太长代价太大，那还有中间过程的监督和反馈。

2 是监督和反馈。纸里包不住火，管理不善总是会有蛛丝马迹泄漏出来。可以通过利益无关甚至利益冲突的其他人的监督，也可以收集更下层的反馈。对应到 vibe coding ，其他 AI 可以审查代码，你自己也可以亲自抽检其中的某个模块，让代码说话，让你更了解你使用的 AI 是个什么水平，从而只下放对应的权力给它。其实人们也一直是这么做的，在 2025 年末之后，很多人才改变了 vibe coding 的方式，全权放手让 AI 去做。

[moudy]

@sillydaddy 类比编译器出现后写汇编的几乎消失了。不过编译器生成的代码是相当确定的，而 ai 显然还没有到这个程度。有 ai 辅助倒是应该在 test 上下功夫。各种覆盖以前手工做非常耗时，现在应该是用一个 ai 带着低温参数把 test 确定性的给生成出来，开发人员 review test 后再以 test 为指导去搞代码。

[imdong]

我也有这个问题，但想想我现在有时候接手别人的开发结果，甚至是外包的垃圾，不也是一样的情况，可能还不如 AI 写的。

[sillydaddy]

@moudy >“不过编译器生成的代码是相当确定的，而 ai 显然还没有到这个程度。”
不能这么类比吧。我上面#6 楼的回复，恰恰是把 AI 类比为人（下属），而不是编译器。

人或者 AI 做事，就是有固有的不确定性。给你一个下属，你也要接受他的不确定性，以及能否把事情做出来的不确定性，但这不影响你对他能力或可靠性的大概判断，对吧。而编译器的确定性，是因为它要处理的编程语言的语法是极其确定和有限的，不确定性为 0 。所以，不能拿编译器与 AI 类比。

[yisen123]

这个项目可以帮我们重获掌控感： https://www.v2ex.com/t/1197994

[940i3s34v4F1HW41]

show me the talk

[lanbos]

打消你的疑虑，两年内程序员岗位消失，以后不需要写程序，所有程序都是一次性脚本，代码不需要再维护，脚本带着可能会有边界情况 bug ，但是能解决用户的需求。锻炼好身体，准备转行。

[johnhuangemc2]

实际上就是管理问题. 自己从亲手写代码升级成了小组长, 要向手下成员(agent)安装任务. 这个小组成员能力强, 但都是临时工, 完成一个任务后就换人, 需要管理好项目上下文保证每个任务都向同一个方向执行.

[Greendays]

工作量上涨太多就是 Hold 不住的。我不在互联网企业上班，有时间去研究 AI 写的代码，但我估计在快节奏企业上班的人是肯定没时间这么做的。

[duhbbx1119]

感谢各位的回答，收获很多

确实，从可预见的结果来看 AI 后面掌管更多代码的编写是不可避免的

就像上面的一个老哥说的，已经到了管理层面了


本来想好好当大头兵的，结果用了 AI 愣是强行提升成小组长了

[wenruoliushui]

这玩意不出问题还好，出问题了 AI 如果解决不了，要自己去看整个代码那就头大了。

[DonaldY]

1 、逻辑怎么跑的得知道，要不然容易脱离把控。

2 、没必要看每个方法的内容，让 AI 封装好（ AI 擅长、且能足够放心），只看方法名就行。

[moudy]

@sillydaddy 理解你的意思，只是主贴描述的 ai 代码不可掌控感与编译器的确定性对比很鲜明。也许对于开发 app 或者互联网，ai 这种随机感无所吊谓，但是在很多领域（医疗，汽车，航天，金融，工业控制等），这种不确定性会千百倍的放大风险。如同智驾永远宣传 L2.9999, 不敢说自己是 L3 。都是人对智能体的不确定性的担忧。所以我才强调温度参数，这玩意至少能让 ai 在确定性的输入下，给出确定性的行为。

[moudy]

@wenruoliushui 我司有几个老哥，主打技能之一就是看三哥的 core dump ，结合发版的反汇编搞清楚到底给编译器喂了啥屎。不知道以后拿着 coredump 看 ai 代码的能力能不能当碗饭吃。

[whusnoopy]

我的感受是，不管写新功能，还是动老代码，或者是推倒原来的做重构，交给 AI 没问题，但需要他先做分析和规划，看明白他的分析和规划以及对应的理由后，再决定是不是按此方案继续，继续的过程也一步一步来，对中间关键节点做检查，这样能享受 AI 带来的效率提升，也不会失去对代码或业务的理解和控制

相比较无脑下一步让 AI 哐哐整，但后面看结果不对再去调再去改，这种一定程度的事先和事中投入并不会影响全局耗时，反倒磨刀不误砍柴工，综合效率是更高的