
1 qi1 3 天前 在这里不得不提一句,马斯克到底几几年上火星 |
3 fox0001 3 天前 via Android 用 AI 去 review ,是不是等于没人 review ? |
4 cincout 3 天前 不是很认同, 编译器输出二进制可以看作一个确定的转换, 现阶段 vibe 的代码是有一定不确定性的 |
5 kapr1k0rn 3 天前 编译输出不 review 是因为输入经过 review,输出是稳定的,什么时候同样 prompt 能固定生成同样代码就可以只 review prompt 了 |
6 orrinex 3 天前 ai 的输出是不确定的 |
7 xe2vherd 3 天前 普通人不需要关心发动机是如何工作的,但工程师需要。 老板不需要关心 vibe coding 质量如何,但程序眼需要。 |
8 Vaspike 3 天前 这不能类比 |
9 sillydaddy 3 天前 其实我最好奇的是,为什么现在还没有 AI 能自主 debug ? |
10 notwaste 3 天前 能跟大模型对齐业务需求逻辑才是最难的,现在不管 spec 还是 skill 都还差点意思 |
11 94 3 天前 其实现在也有很多开发已经完全不看 AI 输出的结果,先无脑 Accept All 了再说。 |
12 Test22 3 天前 @sillydaddy AI 自主生成测试用例,自动运行测试,与预期不符修改代码重新执行,这又何尝不是一种 debug 呢 |
13 4ever911 3 天前 via iPad 不要高估 ai 一年能做到的,也不要低估 ai 十年可能改变的 |
14 nkidgm 3 天前 这个肯定的,楼上说的 AI 编译产物不确定(稳定),其实这个问题利用多个 AI 协同合作保证正确率,一个 AI 负责 compile 自然语言输出,另一个 AI 负责 review ,再由各种各种的 agent 验证,即使还有一定概率出现问题,但已经是小概率事件了。 |
15 sagnitude 3 天前 编译器是翻译不是改写,是稳定的,是幂等的,同样的程序总给出同样的输出,所以才只需要看高等语言,而可以不关心机器码,只要维护编译器的人去看,世界上其他所有人都可以不看 但每个程序的需求、输入、输出、边界、功能都是不同的,就是需要人去看,至少短时间 |
16 alamaya 3 天前 说实话现阶段的 ai 无法分辨对错,代码这种一出问题就有可能呢造成重大损失的,说不用 review 的出了事儿替 ai 背锅就行了 |
17 Esec 3 天前 via Android 编译结果可以写测试覆盖,设计时约束输入来减少异常输出的可能,现在 ai 缺个固定部分网络只推理输入的功能 |
18 sillydaddy 3 天前 |
19 cat9life OP 暴论:我们都天然的相信编译器,可能只是因为“所有在我出生之前发明出来的东西都是理所当然的;所有在我 1535 岁之间发明的东西注定是要改变世界的;所有在我 35 岁之后的发明都是反人类的”。 |
20 shakukansp 3 天前 @nkidgm 大概率事件 |
22 chendy 3 天前 编译器是稳定的,你让他 c = a + b 他就是 c = a + b AI 可能第一下 c = a + b ,然后脑子一抽就 c = a = a + b 去了 |
23 HojiOShi 3 天前 用编译器做这样的类比,除了狂妄我想不到第二个词。 |
24 tfdetang 3 天前 @sillydaddy 其实还是上下文窗口的问题;目前的上下文窗口还没法支撑一整个大项目整体的集成测试;但是基于模块与测试用例的自主开发与 debug 已经非常成熟了,基本不需要人去 review |
25 tonytonychopper 3 天前 偷换概念了 |
26 coderluan 3 天前 我感觉原文编译器输出的结果是指汇编结果,而不是二进制。 因为二进制从始至终都没人关注,并不是技术进步导致的,而汇编语言确实是随着编程语言的发展越来越少人关注的。 |
28 labubu 2 天前 @sillydaddy #9 #9 能,GitHub Copilot 在 vscode 里面和 Visual Studio 能自动写自动编译,编译不过或者生成的代码质量差能改了再编译 |
29 purringpal 2 天前 @cat9life 你这个确实挺暴论的,要么不了解编译原理、要么不了解 LLM 原理,要么两者都不了解一点。 |
30 94 2 天前 @JShen #27 ,想多了,就是 run 一下跑通了就敢提交。AI 吐出来的代码他都不一定能看明白,怎么去 review 。 那验证?我代码跑通了啊,验证那是测试该干的活,不是开发的事。我已经看到很多这样的案例了。 |
32 greygoo 2 天前 其实不是没有人会 review 编译器的输出结果,只是这个东西系统性的被外包给别人了,是不是 vibe coding 的这个过程也会被外包给别人,软件开发是不是以后是要写 specification 就可以,然后其他精通 vibe coding 的工程师来实现自动化的开发 |
33 IndexOutOfBounds 2 天前 如果把 AI 类比人,你把需求外部出去,结果肯定是需要 review 的,不仅因为 LLM&人&自然语言有模糊不确定性,更是因为从需求 -> 结果,不是类比编译器的 100% 确定性翻译 当然如果 “结果” 指的值是代码,而不是产品,那可能确实不需要 review |
34 twofox 2 天前 cursor 已经可以自动 review 了。并指出了我在合并代码产生的一个逻辑错误。 |
35 IndexOutOfBounds 2 天前 @greygoo 其实我一直不太理解,对于原本懂需求会写技术文档的工程师,vibe coding 这个事情有啥好精通的 |
36 Alias4ck 2 天前 什么暴论,否定编译器 一个确定性的事情怎么和一个概率论的东西相提并论 |
37 greygoo 2 天前 @IndexOutOfBounds #35 现在 vibe coding 还不是要一个人累死累活地去看,否则没有办法确定成果质量。但是懂 vibe coding 的工程师可以通过流程解决这部分的问题。 |
38 usn PRO 机器语言和自然语言还是有区别的 |
39 usn PRO 能看懂的情况下一定还是会去理解的 |
40 Maboroshii 2 天前 快进到产品经理输出原型,就不用测试了 |
41 livib 2 天前 从趋势上来说这可能很快就成为现实,AI 其实只需要做出实现方案的详细描述就可以了,这也不是黑盒,只不过将代码实现进一步抽象 |
42 adgfr32 2 天前 via Android 编译器产生的内容是稳定的,准确的,可复现的 大模型可以做到吗?先把版本号生成准确再说吧 |
43 foryou2023 2 天前 自己的实践经验来说,全程全自动,自己从来不 review 但是有大坑,就是遇到 bug 的时候 |
45 adgfr32 2 天前 via Android 如果大模型已经达到编译器的水平,他应该直接调操作系统把事情干了,而不是生成 code 再过一遍编译器。 |
46 bbbblue 2 天前 这个没有因果吧 没人去 review 编译器输出是因为这个输出得到了广泛的验证 很可靠 不合格的编译器也不会有人去用,并且输出结果也是确定性的程序和测试集可以验证的 但 vibe coding...你先解决小白不小心删库/删文件的问题再说吧 |
47 jjwjiang 2 天前 我们组现在的 UT 基本上全权交付 LLM 编写,我们负责 review 的内容是 UT 的标题,UT 的 assertion 部分是否合理,最终的 code 覆盖率是否覆盖了需要的逻辑分支。 确实是在这个部分已经不去 review 它生成的代码了。 所以我是认同这个趋势的。 |
48 akakidz 2 天前 有没有字节的朋友讲一下目前内部的 AI 使用,模式是什么样的 |
49 abelmakihara 2 天前 偷换概念 大老板也不会 review 程序员的代码 为什么?因为下面的人会对这段代码 review 你不 review AI 谁来负责并保证正确? |
50 vfs 2 天前 编译器会在必要时候报错, 而你的 AI 永远不会告诉你,这个问题他不会,他总是自信的给你生成代码 |
51 chingyat 2 天前 编译器的作者对编译器的输出结果是很清楚的,但 AI 的作者根本不知道 AI 会输出什么样的代码! |
52 YanSeven 2 天前 目前来说,编译器是确定性的基于形式化规则的,AI 的生成它不是啊。除非能把 AI 的输出搞一套形式化的测试验证逻辑来兜底。 |
53 YanSeven 2 天前 @cat9life 难道不是因为原理吗,编译器的原理从根儿上值得信任,然后现行的编译器经过全球无数产品的验证同样值得信任。原理+实证确保了编译器为大多数底层码农可以无脑信任。大模型呢。原理一半儿明白一半儿黑盒。落地最广的代码生成大多还是要和人进行结对。本质上就跟人一样,一个自动化流水线和一个熟练工,这个熟练工就算是再无敌,也碰瓷不了自动化机器。 |
54 Enivel 2 天前 快进到所有应用运行在大模型生成的实时视频中, 就算想 review 也不可能了. |
55 ty29022 2 天前 一个是基于概率的, 一个是基于有限规则的 一个是根据自然语言生成形式语言, 一个是把形式语言“编译”成另一种表达形式 两者能一样吗,要么太乐观了,要么瞎球不懂 |
56 nicewa 2 天前 那么程序员是真的 gg 了 |
57 darksword21 PRO 什么傻篮子狗屎言论都搬是吧 |
58 woodfizky 2 天前 标题整句话都是错的。 没人 review 编译器的输出?错。那那些看编译之后汇编的人算什么?那些做逆向的人算什么? 没人 review vibe coding 的代码?错,除非以后没有 vibe coding 了。 某件事很少人做,且频率很低,不代表它不重要,不代表可以没人懂这件事。 |
59 noyidoit 2 天前 如果整个团队甚至整个社会都能接受甚至拥抱不确定性,那这个结论可以成立。但目前看上去这个 soon 还处于∞的阶段 |
60 yellowsky 2 天前 现在你会发现大模型每次发布的版本进步都很有限,甚至感知不到进步,只能在工具链上做竞争。这表现出来的就是大模型的发展已经到了瓶颈,只能往应用层发展,底层很难再有重大的突破。 |
61 jujusama 2 天前 没学过编译原理? |
62 Hilong 2 天前 我现在就不怎么 review AI 的代码了.就测试驱动,碰到 bug 再反馈给 cursor 让他去修. |
63 uds9u32br 2 天前 不见得,现阶段 AI 生成的代码大多数时候比人写的容易读懂,你不愿意去 review ai 代码,可能人的代码你也会嫌麻烦。 |
64 air1314 2 天前 我基本不怎么 review 了,AI 比我写得好,更多的还是测试保证,然后尽量拆分任务,保证每次的输出都是可测试的,结果对就行 |
65 msg7086 2 天前 谁告诉你没人 review 二进制的……你猜 godbolt 是干什么的。 做底层项目的人 review 二进制汇编代码的可多了去了。 比如你写个视频处理滤镜,你得大量手写很多 SIMD 代码吧,然后这些代码转换成了什么样的 CPU 指令,这你不得让编译器编译完以后反汇编回来检查? 你不关注编译出来的代码,不代表别人也不关注啊。 |
66 Chuckle 2 天前 能信任编译器的输出结果,那是前人从二进制驱动机器以来的智慧和努力啊 前面的一切都是数学和形式化方法的结果,别人已经关心过了,现在也有人持续的在关心,输入输出的无数可能都已经覆盖完了,多少测试覆盖支撑着这份信任。而大模型底下是概率抽样,让它写代码,说白了,就是赌风险和收益嘛,还发明个 vibe coding 名词来掩盖放下点责任心想轻松点的人之常情。当然,业务代码里随手写的工具函数,正常来说也不会去做充足的测试、校验、错误处理,反正要字符串不会来个对象就行了,炸了再热修也行。 当然我是觉得,业务代码不可能人不看的,不看那就是用户替你去看了,出了问题特别是像钱算错了,背锅的只能是人啊。现实点,ai 总是接手现有的项目的迭代吧,一个 id 字段在不同对象里几十种意思,ai 啥时候能自己去问 git 历史提交的人?当然,有些面向司内的东西,已经是 ai 开发了,反正没风险。 |
67 moudy 2 天前 太好了,现在能看懂汇编的才算大牛,以后能看懂程序就是大牛了。 |
68 moudy 2 天前 @msg7086 上个月我们还有个项目,C++写完的,大规模压测会崩。项目组自己查来查去没头绪,呼叫专家组来支援。然后我们让他们把代码全抛开,反编译的汇编发过来。发现有个锁的实现有问题,特定情况下程序里呼叫了锁,底下汇编里根本就没出现锁相关的代码。这也是为啥我觉得 C++那堆隐式类型转换,重载等一堆说不清道不明的代码障眼法及其恶心。估计以后大模型出来的程序坑人的例子也少不了。 |
69 siweipancc 2 天前 via iPhone 近几年的大厂事故就是这么来的 |
70 wnpllrzodiac 2 天前 via Android @sillydaddy 全自动选手出来了,我们这些个人还要了干嘛?老板一句话,第二天就上线的系统,还需要程序员,架构师,cto ? |
71 wnpllrzodiac 2 天前 via Android @94 就不怕 accept 多了最后发现烂代码 ai 都修不好,一个星期 accept 白点了? |
72 wnpllrzodiac 2 天前 via Android @alamaya 所以人的作用就是背锅,ai 不用考虑道德和犯错的问题,尽力输出就好 |
73 wnpllrzodiac 2 天前 via Android @sillydaddy cursor 可以调用 gdb 收集日志分析,感觉比调用 vs2022 好用。如果 vs2026 能像 cursor 一样,调试 cpp 代码又简单了.虽然现在写 cpp 代码几乎已经没人了。 |
74 wnpllrzodiac 2 天前 via Android @94 能跑不崩就算完成开发任务,那所有函数直接返回 0 不就好了。 |
75 MossFox 2 天前 有点偏题,但是我遇到过编译器优化影响某些画图函数逻辑导致开关优化画出图有差异的。 因为赶时间就没去仔细排查原因,但是也是教会了我不要无脑相信编译器。 只不过编译器至少是保证设置一样,产物也一样。愿意细究的话不会是个无法排查的黑盒。 |
76 WuSiYu 2 天前 感觉纯瞎扯,正经项目里人的 code 都得 review ,更何况是 AI 的 LLM 这东西跟编译器完全不是一个概念,谁家编译器判断输出啥是靠概率的?并且每次还会不一样?(开了 sampling ) |
78 newtype0092 2 天前 现在需要一个正经团队的切切实实的靠谱的项目,来验证 Vibe Coding 在复杂工程实践里全面代替手动编码的可行性,而不是造出 N+1 个套皮 chatbot 或者半天工作量的 web tools 来推销概念。。。 |
79 bytesfold 2 天前 via iPhone 怎么说呢,最近两天做了一个硬件模拟,刚才把代码 vibe 完,好几千行代码确实是只看了大概。没有逐行 review 。 如果有价值,梳理重构也不是难事; 没有就是没有,有就是真的有了。 |
80 xuanwu 2 天前 用过即弃的也许可以。 Who is Adam Wolff btw? Anthropic 的?股价半年翻三倍。。。 |
81 ButcherHu 1 天前 我认为编译器的出现是一种分层,在具体的架构和指令上的优化其实是确定的,所以这两者是不能类比的。但是从 vibe coding 的角度来说,review 代码确实很痛苦,至少有了 agent 一些冷门语言也能跑起来了。 |
82 nightwitch 1 天前 2025 年了我经常在 godbolt 看一段代码各个编译器编译出来的汇编指令,gpu ir 更是每天都读... /td> |
83 L4Linux 1 天前 via Android 呃,俺的工作就包括 review 编译后的代码。 |
84 xsen 1 天前 楼中一堆古法编程的拥鳖,不能与时俱进唯有扫入垃圾堆 如果代码 review 有用的话,就不会有测试的存在 而且这一堆人对测试怕是一丁点概念都没有 |
85 cvbnt 1 天前 我现在严重怀疑 cloudflare 内部没有 review |
86 94 1 天前 @wnpllrzodiac #72 ,#74 ,不要着急,我只是在说现在日常管理中看到的现象。至于我的观点可以在另外一篇帖子中看到 /t/1176989#r_17062875 ----- 对于无脑 Accept 的人来说,代码改烂掉了就重开会话/换个模型继续改,如果快要 DDL 还是没搞定,就求助现实里或者网络上高资历的开发。 至于功能函数返回的结果肯定是有验证的,但只会返回在功能说明文档中描述场景,并不会考虑边界情况,自然也不会有好好自测。 所以交付的内容基本上在测试环节会出现各种 bug 被打回,然后继续 AI 修复。如果没有在测试环节出现问题就由用户去发现(这时候就真的是测试来背锅了)。 ----- 能抱着我产出的功能模块要尽量少 BUG 、覆盖尽量多 Edge Case 想法、有“责任心”的开发者现在已经越来越少了。 Accept All 这种现象在初中级开发中已经很常见了,以后也只会越来越多。并且这种现象在高级、资深开发者中也在出现(但是他们能够去给 AI 擦屁股或者有自己的一套 AI 使用方法论)。 可初中级开发可能并不一定能够去擦屁股,所以之前我激烈吐槽过 #VibeCodingCleanupSpecialists# 这种岗位的出现。 虽然我觉得 IC 没有 review 自己的代码很大程度上是管理上的问题,但是如果 Leader/Manager 去盯着 IC 有没有去 review ,或者去仔细 review 提交上来的 MR/PR 。那么每天上工就可以不用做别的事情了。 所以应该由 Manager/Leader 按照当前大量使用 AI 的现象去调整现在的项目开发工作流,而不是仅仅去强制要求 IC review 通过 AI 产出的代码。 |