 |
jarytom3 days ago
1
好好想想另一份出路就行
|
 |
2
不太理解这个问题的店在哪。
张一鸣知道抖音程序的细节吗？那你说他为什么就不怕手下的人兜不住呢？ 同理。 |
 |
HeyWeGo3 days ago
3
人至少会兜底，AI 改到后来改不动真就撂挑子不干的反复重复回答。不过最终也得看使用的人是否合理规划。
|
 |
4
@sentinelK 可能会堆一个数量级，以前可能 5 年爆一次大雷，今后可能一年一次？那么监管之类的又得提门槛了。但我还是拥抱 ai 的，反正 claude 写的比我好。
|
|
5
@HeyWeGo
@irvinglove 本质上就是，如果你的决策导致无法避免一个负面的发生，那本质上其实并不是生产工艺的问题，是组织结构的问题。 LLM 和古法编程之间，只是 coding 的工艺变了，属于技术革新，但并不应该动摇既有的组织架构。 换句话说，不管是碳基编程、硅基编程还是羟基编程，只要最终能过 QC ，那就一样。 |
|
sentinelK3 days ago
6
换言之，如果一个代码能过 QC 但引发了负面，那其实不是 coding 的问题，是 QC 的问题。
|
 |
kaixin3 days ago
7
AI 写代码会不会暴雷？答案是肯定的
|
 |
8
AI 已经比绝大多数人 coding 水平更高，为什么还有些人这么自信？人要管控的是需求、架构、最终测试与验收步骤，在执行层面早可以被替代。
|
 |
9
之前新人入职第一件事就是先让熟悉代码了解业务，现在是怎样的
|
 |
kerwin18743 days ago
10
做好设计-计划-实现-review 这一轮大部份代码都没啥问题，要说暴雷，一天要我出一个模块的接口的时候就应该想到这个问题了，等爆或者别人接盘的时候我早跑路了，我死后哪管洪水滔天
|
 |
richard0013 days ago
11
新项目没啥问题架构、设计、文档该有都有，古法时代留下来的老项目，特别是跨多服务调用的，现在还是不好处理，无文档、无规则、还要求，尽量不跨服务改动，跨服务很多都是黑盒，只能自己摸索。
|
 |
12
放心，当别人问这个功能怎么实现的话？你讲的肯定没有 agent 讲得好
|
|
irvinglove3 days ago
13
@sentinelK 是的，但数量级问题依旧存在，压力给到 QC ，QC 负荷更大了，QC 也全靠 AI 的话，又变成黑盒问题。量变引起质变还是有一定道理的。当然世界本来就是草台班子，也没多大关系
|
 |
athershu2 days ago
14
「别人问这个功能怎么实现的」这个，我们的办法是让每次 AI 改动都留下能回答这个问题的东西：一个任务一个分支，交付时附一段说明（改了什么、为什么这么改、怎么验证的、哪里不确定），人对照任务描述审过才合并。之后有人问，翻的是任务记录和那段说明，而不是回去问 agent 。
另外 review 时踩到的坑、老项目里只有老员工知道的约束（比如楼上说的跨服务调用哪些不能动），都写进仓库里给 AI 读的规则文件，下个任务自动带上。知识留在仓库里，不在某个人脑子里，也不在某一次对话里，人走了也还在。 |
 |
JadeUTC2 days ago
15
AI 本身可能会暴雷，但是人类靠 AI 写的代码不会。
|
 |
ffalex2 days ago
16
除非测试不到位
|
 |
himawari82 days ago
17
嗯哼，AI 被操纵植入木马也是分分钟的事，反正你没时间看～
|
 |
davidoff5672 days ago
19
人和代码有一个能跑就行
|
 |
V2Try2 days ago via iPhone
20
暴雷了，我让 Claude 配置了个 crowdsec ，把我关外面了。
|
 |
myfate2 days ago
21
要相信后来 AI 的智慧
|
 |
isnullstring2 days ago
22
裁员和暴雷，二选一
|
 |
samtofor2 days ago
23
和前端对接的时候改一波 bug. 测试的时候在提一堆 bug. 结论.全靠测试兜底
|
 |
iApp2 days ago
24
爆了再说,车到山前必有路,又不是你一个,你怕什么
|
 |
Sir8142 days ago
25
代码看不完，功能测试和跑测试用例
|
 |
labubu2 days ago via Android
26
人写的才是，现在漏洞越来越多，都是很多老代码的
|
 |
stucom2 days ago
27
暴雷就爆雷呗，人写的也会爆雷。需求上线之前，让 QA 多测测重要的流程就好了
|
 |
BlueSkyXN2 days ago
28
暴雷是公司的事
|
 |
29
今天看了一个抖音很有道理。
如果你 ai 写的代码没有埋雷，说明公司降本增效不到位 程序员还有时间去搞那些提升质量的事儿，还可以再裁一半。 |
 |
wfg2 days ago via iPhone
30
不会的，你放心
|
 |
cslive2 days ago
31
大部分人的水平不如 ai ，随着模型越来越先进，这个数字还会提高
|
 |
TerranceL2 days ago
33
只有我一个人看成了：AI 写代码会不会暴富？
|
 |
goumadantui2 days ago
34
谁去管这么多，能跑通业务不就行了，以前手写也有 bug 啊
|
 |
YYDC2 days ago
35
前几个月还能看到 ai 误删库的，删源码的，现在都看不到了，是不是 ai 进步了
|
 |
terrysnake2 days ago
36
一个有责任心的程序员在 AI 写完代码后，至少会问下 AI 是怎么实现功能和架构的。
|
 |
ooppstef2 days ago
37
|
 |
7gugu2 days ago
38
老板根本不是这样子的思考方式啊。我之前思考过这个问题，老板根本就不会在意工程师的技术细节是啥，他只会关注你的产出是否符合预期而已。同理，程序员使用 AI 的时候，也是不需要去过度关注细节的，只要保证最后的结果是正确的即可。
|
 |
vmuu2 days ago
39
什么样的项目会暴雷，就比如我们公司的现状：代码全部 AI 写，然后很多东西都没搞懂，很多地方都不知道该怎么设计怎么规划，这种需要长期维护迭代的项目，一旦逻辑复杂，后续用户需求量上来，那包暴雷的呀，前两天数据库就被流量打穿了，今天还在进行项目复盘
|
 |
xue777hua2 days ago via iPhone
41
|
 |
phrack2 days ago
42
我自己写的炒股炒期权的代码我是真看，一行一行的看
别的嘛，能跑就行 |
|
sentinelK2 days ago
43
@xue777hua 软件工程是工程学，说的简单粗暴点就是流水线思维。
终端生产者是人，是 AI ，还是三体人其实在整个组织架构中根本就不重要。 所有的软件公司的顶层设计本质上就是需求 > 方案 > 实现 > 验收上线 > 改进需求 的循环。 如果“实现”满足了“方案”，那么理论上，就不会有暴雷，否则是方案不合格，不是实现不合格。 同理，“实现”未满足“方案”，那么理论上他就不应该验收上线。 无论哪种情况，都跟“实现”本身的工艺无关。 这是工程学的最基本原理。在其他条件不变的前提下，工艺，仅仅决定成本。 软件工程诞生 30 年了，人比 AI 难管多了。 架构大佬绞尽脑汁设计出 vue 和 React ，就是怕基层程序员脑洞大开，想试图通过程序结构把程序员束缚成机器人。 现在机器人的时代来了，反而还担心代码暴雷了…… 我是真的没想通。 |
|
xue777hua2 days ago via iPhone
44
@sentinelK
1. 科幻小说就别当论据了。 2. 你对暴雷的理解，仅仅停留在外包公司的水平。你没有 ownership ，在没有 ownership 的情况下，不存在暴雷。但仅限你自己定义的场景，现实业务中并非如此。外包公司也不只是交付就跑路。乙方不爆雷，但甲方会爆雷，逐渐就会传导道乙方。 至于管理，pua skill 对 agent 没用，但对猪和猴子都有用。 |
|
sentinelK2 days ago
45
|
|
sentinelK2 days ago
46
@xue777hua 我不理解你说的“外包公司水平”，
你的公司不存在 QC 吗？不存在架构评审吗？你自己愿意击穿一切防火墙，然后把所有责任都依赖于一线生产者的自觉与职业操守，这是一个正常的软件公司的行径？ |
 |
iyaozhen2 days ago
47
@sentinelK #6 我就是 QA ，一方面压力都给到 QA ，代码细节都说不清楚，用例评审那不是形同虚设。提测质量变差，用例质量也变差，怎么不出问题
另外 QA 也有提效要求。研发本来开发 5 天，我测 1 天，这样比例合适，但现在开发 1 天，我还测一天，那不等着被骂。而且提测 5 个需求，整个组织来看，全卡在了 QA 这里，你说咋办。 |
|
sentinelK2 days ago
48
@iyaozhen 所以这就是公司的策略问题，跟上文讨论的一致。就是这种公司思维本质上不是 AI Coding ，而是组织架构扁平化，相当于人为把所有纠错节点都交给 AI 生产者，试图靠生产者当圣人来解决一切，那最终一定是会出问题的。
AI 只能上生产成本降低，从而生产前置，降低决策成本。过去靠猜，靠直觉的决策，现在可以直接摸到，甚至市场实验了。 Deepseek 的 SuperAgent 架构也是这个概念。 |
|
xue777hua2 days ago via iPhone
49
@sentinelK 组织结构只是结果。技术才是根本。
你这论证的，本末倒置了。 如果技术发展 或 底层执行的好，很多组织部门就没有必要了。 所以某种组织结构 不是目标 不是手段 只是结果。 当然 没有思考能力的管理者，会无脑用一个组织结构，也就是典型的“抄作业”，也是本末倒置的管理水平。 比如 有的公司 就因为 agile 硬生生诞生了 scrum master 这种职位。但很多公司也没有这种职位，但依然 很 agile 。 |
 |
ccyixia2 days ago
50
普通人驾驶会不会翻车？会。但在绝对的效率面前，这些都是可以忍受的容错率。
|
 |
Arrowing2 days ago
51
标题看成了“暴富”...
|
 |
wsseo2 days ago
52
测试也不能兜底，流程能跑通，在不该的地方埋雷，谁也测不出来。
|
 |
msg70862 days ago
55
一切恐惧都源于测试用例不足？
一个软件如果能做到百分之百测试覆盖，包括穿透测试也覆盖足够，那就不可能暴雷。 实际软件开发中当然不可能那么理想化，但是 AI 辅助开发更容易得到高覆盖。 所以老板更应该担心人类员工写的代码会不会暴雷。 |
 |
longniao2 days ago
57
暴雷之前，程序员们都失业了
|
 |
txican2 days ago
58
现在问你, 这个程序 是怎么用 汇编实现的?
你也回答不上来, 你会说 这个程序 用 python 是怎么写的 同样的, 以后 问 这个程序是怎么用 python 写的? 也不需要回答上来, 只需要回答 这个 程序 要满足怎样的需求文档/设计文档 就够了. |
 |
lplusk2 days ago
60
@sentinelK 你也觉得需要质量管理和架构评审，这里讨论的就是 ai coding 时代怎么做好这些事的问题，你一副我是代码生产者这两件事跟我无关的样子，这是你对软件工程的理解吗？
|
 |
VeteranCat2 days ago
61
真的是，互联网大儒们没有管过钱么？ 并不是什么信息系统都是小玩具，坏了没什么责任和代价的。
你是打算让 GLM 还是远在大洋彼岸的 Claude 给你背锅？ 你自己背瓷实吧。 |
 |
MIUIOS2 days ago
62
我觉得会，一个系统的具体实现细节，连开发人员都不知道，出了问题，还是只能去问 ai ，ai 如果自己都回答不上来，那就真的死穴了， 现在我们就遇到这个问题了。
|
 |
heybwei2 days ago
63
AI 写代码肯定不会暴雷，会暴雷的是领导、老板盲目相信 AI 万能的场景，需求迭代效率膨胀下，在整个迭代中无法做到功能有效验收。
|
 |
Geon972 days ago
64
已经有的公司开始暴雷了
|
 |
Felldeadbird2 days ago
65
会，也不会。
规则约束好 AI ，那么 AI 写代码其实和人写没太大区别。 人不 review 的话，AI 会不会暴雷，按模型智力。智力正常下，代码最多绕一点，烧一点。智力有问题下，就容易出问题了。 |
 |
Twnysta2 days ago
66
描述好写的比大多数程序员还好，你要是许愿式的编程，谁来都是雷。抠极致的性能还是得看人，普通业务肯定是 AI 写的好。
|
|
sentinelK2 days ago
67
@lplusk 你这个话就很奇怪，AI Coding 指的只是 Coding ，QC 和架构评审和 Coding 其实一点关系也没有。
IEEE 对于软件工程的定义是：“将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中” 软件工程解决的就是如何工程化的解决软件问题。本质就是如何束缚一线开发的能力让其稳定产出。我认为这点在 AI 时代并没有变化。 变化的是人的心态。 决策者让 AI 做出远超过安全界限的动作（自动合并 PR ，自动上生产，cc 的 sourcemap 都上开源社区了），然后非要说是 AI 导致的暴雷。这我就不太理解这样的逻辑立脚点是什么。 |
 |
nicegoing2 days ago
68
大部分代码的生命周期 1-3 年，出不来结果生命结束。ai 非常适合降低试错成本，快速上市，获得市场了，不论是重写还是重构，完全来得及。
ai 最强的是快速出原型，验证思路。别人一个月 ai 肝出来了，害怕暴雷的半年才肝出来，黄花菜都凉了。 |
 |
klos2 days ago
71
怎么说呢 用了半年 claude 以后感觉他比我想的还细 除了业务方向 跟资金流向方面 他因为不知道三方支付的规则 所以需要我来辅助 其他方面 写的真好
后来 claude 号没了 用 codex 质量下降 感觉从一个有灵性的程序员 变成了 刻板程序员 干啥都拆层 拆类 过度 打个比方 你说我要做盘菜 不要红烧肉 他最后菜名后面会是 鱼香油丝(不是红烧肉) 但也能吃 至于国产模型 一直也在用 等国内崛起 但是实话实说 现在代码层面 还是差的不少 codex 修个问题 可能要卡好几轮对话 几个小时 还是解决不了 然后我找中转用 claude 5 分钟解决了 国产模型跟 codex 类似 但是交付产物真的一言难尽 |
 |
JerningChan2 days ago
73
人写的时候，人还会因为感情，金钱，家庭很多因素被迫按照老板们的要求，硬着头皮弄一下也不是不行，正规的 ai ，触碰到底线，他说不干就是不干。。。
|
 |
xz4102360562 days ago
75
1 、人类写代码会不会爆雷？你太高看人类的 CR 能力了。
2 、以前的用户、PM 关心你内部怎么实现的吗？他们只关心数据正不正常、显示正不正常。都正常那就是正常的，你内部绕来绕去的根本没人关心，现在你充当了项目经理的角色。 |
|
lplusk2 days ago
77
@sentinelK 你还是会像古法编程年代那样认真评审方案，认真写代码、审代码，仔细想测试场景吗？
就算你可以做到，每天用 AI 产出的代码和文档都是古法编程年代的很多倍了，现在你审的过来吗？你怎么保证你不会想偷懒？ 就算你不偷懒，你怎么让整个项目里不同模块的负责人不偷懒？你怎么判断他们是否偷懒？如果业务需求要的很急呢？ 如果文档和代码都审不过来，你准备怎么保证质量？ 如果一个架构方案很复杂，你自己设计不出来，但是 AI 可以设计出来一个看起来能用的，你觉得你有评估这套方案的质量风险的能力吗？ vibe coding 引入大量的不可控和复杂性，很可能会超出一个人的能力范畴，而且这个人未必能意识到，但显然质量保证的方法跟古法编程年代并不一样。 |
|
sentinelK2 days ago
78
@lplusk 我们讨论的是 AI 编程是否暴雷，如何规避暴雷。结果你非要说用 AI 就要击穿一切安全流程。
那还有什么讨论空间呢？古法编程不存在这样的问题吗？ 就是你作为决策者，非要让公司业务跑在一个无法掌控的情景之下，然后把这一切怪罪到生产技术上，这真的有意义吗？ 还是那句话，古法编程时代，你是怎么判断这个人是否偷懒，是否认真 code review ，测试用例是否覆盖完备的？ |
|
sentinelK2 days ago
79
|
 |
levn2 days ago
80
claude 不代表全部模型
|
 |
Chippy2 days ago
81
你保证 代码仍然在你的掌控中 就行了
|
|
lplusk2 days ago
82
@sentinelK 我上面说的每一条都是基于 AI 编程和古法编程的差异点来说的，所以你说的“古法编程不存在这样的问题吗”，答案就是不存在。
而且这些问题都很实在，我没有假设任何极端场景，所以如果你觉得 AI 编程时代的质量保证和之前没有差异，那不妨直接回答就好了。 你是怎么判断这个人是否偷懒，是否认真 code review ，测试用例是否覆盖完备的？ -- 我判断不了，也没有很好的办法判断，但我知道在古法编程时代，单位时间可能引入的问题和复杂性是有限的，这种有限跟现在的质量保证体系达成了某种平衡，这种平衡让大多数对可靠性要求很高的软件在现实中不会出问题。 但是 ai coding 在增加单位时间引入的问题和复杂性，那用于平衡的质量保证体系没有什么变化（至少按你的理解没有什么变化），这肯定是不合理的啊。 这跟道德滑坡没有任何关系，哪怕同样的人，“同样尽责”，每天审 10 行代码，和每天审 1000 行代码，可能引入的问题是一样的吗？是可以用一样的质量保证方法处理的吗？ 我就是因为觉得之前的质量保证有局限性，所以对引入这种复杂性之后的质量保证需要有更多的理解和方法，不是“跟之前一样”这几个字，质量问题就自动消失了的。 |
 |
gejigeji2 days ago
83
慌个 der ，有问题没问题都得走， 早晚的事
|
|
sentinelK2 days ago
84
@lplusk 根结就是，你这个推演有几个既定的前提。我认为是不成立的。
1 、你认为 AI 时代的软件开发组织架构人员配比、分工完全不变。 2 、你认为 AI 放大的生产力会 100%的释放给后续环节以及生产环境。 3 、你认为人的效率、质量与工作量线性相关。 以上我都不苟同，所以继续讨论下去也没意义了。 你可以参照下 A\发布的如何进行 code review ，以及 deepseek 发布的 superagent 开源架构的再研究看看。 |
 |
c0nstantien2 days ago
85
只有“神”才不会犯错，ai 不是神，人也不是在造神
|
 |
GalileoP2 days ago
86
以前只有总监及以上才能 vibeworking,现在下放到基层程序员了
|
 |
Sezxy2 days ago via Android
87
@sentinelK 你这个比喻就不对了，张一鸣又不写代码。
如果有天开会，张一鸣问他手下具体写代码的人这个逻辑怎么实现，难道那手下可以说，等会议结束后再问问 AI ？ |
|
lplusk2 days ago
89
@sentinelK 我没有假设任何事情，只是提出几个问题而已。而且我讨论的是如何保证软件质量，告诉我可以怎么做 code review 并不能解决这样的问题。而且我的态度是我不知道怎么做，我并没有说做不了，你觉得你能解决，那你回答我问题就好了。
另外我不知道你有没有仔细研究过你推荐我的两个例子，superagent 论文里明确说了，他们没有解决多 agent 的冲突问题，我不知道你为什么会建议一个对质量有困惑的人，去看这样的论文。 你并不用去考虑什么宏大前提，我也不想讨论这些事情。你就假设你手上有套服务链路有几百万上千万用户，出大问题你年终奖就没了，甚至可能滚蛋，所以尽量不要出问题，在这种情况下你准备怎么办就好了。 所以上面有个朋友说你对暴雷的理解停留在外包公司的水平我现在看起来并不夸张，我估计你其实没有负责过什么严肃的，不能轻易出问题的生产环境应用。 |
 |
snake3c2 days ago
90
最近为啥这么多 代码暴雷的帖子，去 b 站刷到好几个，来论坛又看到这个帖子，好奇怪，难道我被茧房了吗
|
 |
uxstone1 day ago
91
问这个问题前，先问问自己有权力决定使用或者不使用 AI 来写代码吗？
|
 |
bigtwo1 day ago
92
目前写完后用另外一个不同公司的 ai 进行审计
|
 |
dinjufen1 day ago
93
你现在写的有问题，说不定等下次模型升级了，能帮你直接重构一次更好的
|
|
94
刚刚让 qwen4 复刻了一下“几猫国产 3A 大作”，拉完了写出来像我的世界
|
|
athershu17h 53m ago
95
@qq1147 一天几万行确实没法逐行看，我们也不逐行看。几个做法：
1. 量在派活时就控住：一个任务一个分支，diff 大到一次看不完的任务先拆小再派，而不是写完了再想办法审。 2. 按风险分级：碰到接口、数据结构、权限、钱的改动必须有人看；其余交给测试和 lint 去拦，人只看说明里标了「不确定」的地方。 3. review 时踩到的坑当场写成仓库里的规则或检查，下次 AI 开工先读到，同一类问题不再靠人眼去找。 审不过来，说明产出速度已经超过了验收速度。该收的是派活的量，而不是逼人审得更快。 |
7
Select Language