泥潭日报 uscardforum · 每日精选

Vibe Coding对航空工业安全性会有影响吗

内容摘要

讨论Vibe Coding对航空安全的影响,多数认为严苛验证下影响有限。

1. 关键信息

  • MCAS事故源于设计规范问题,非代码问题(#16)
  • 航空业代码需PEng签名,加拿大软件工程师不能自称engineer(#17)
  • 波音曾将软件开发外包印度,MCAS后收回测试验证(#35)
  • 严苛coding style(几百页)可能适合vibe coding(#10)
  • 自动驾驶FSD无法形式化验证(#23)
  • 波音为降本不写unit test,纯手动regression(#25)
  • AI测试不过会直接删测试(#32)
  • 飞机bug很多,MAX最大问题是隐瞒MCAS及培训缺失(#37)

2. 羊毛/优惠信息

3. 最新动态

4. 争议或不同意见

  • 有人认为vibe coding更安全(#2),有人反对(#5)
  • 严苛coding style利于vibe(#10),但几百页规则LLM难稳定遵守(#22)
  • 形式化验证有效性有争议:必须做(#16)vs 真空球形spec(#34)
  • 波音外包印度 vs vibe coding:认为vibe比阿三靠谱(#36)
  • 成本对比:opus vs 印度SWE谁贵(#44)

5. 行动建议

  • 航空业应保持严格验证流程,vibe coding只能辅助,不能替代人工验证(#8, #29)
  • 需自动化测试enforce规则(#28)
  • 使用者水平决定代码质量(#26)
  • 注意系统级集成测试风险(#29)
原始内容
--- 第 1 楼来自 收束观测者 的回复 (2026-04-21 08:52:58 PDT) ---

众所周知麦道737MAX坠机的罪魁祸首MCAS是麦道的印度软件开发中心写的 如果麦道的数豆人们进一步降本增效让印度开发中心用上vibe coding

--- 第 2 楼来自 gin_m 的回复 (2026-04-21 08:55:55 PDT) ---

vibe coding 其实比人工写更安全吧。

--- 第 3 楼来自 AmericanExpress 的回复 (2026-04-21 08:57:42 PDT) ---

vide coding如果是黑箱,通过极为严苛的测试验证应该也能保证安全吧。 最大的坑是出了问题找bug要烧不知道多少token。

--- 第 4 楼来自 popeyes228 的回复 (2026-04-21 09:00:59 PDT) ---

要是测试都是ai写的呢

--- 第 5 楼来自 Keiour 的回复 (2026-04-21 09:07:16 PDT) ---

航空业应该…不敢用vibe coding吧,大部分时间烧在设计和验证上,而且还有严苛的coding style要求(以前看过LMT还是哪家的代码要求那叫一个厚啊),那拿LLM搓代码相比手搓没啥收益徒增风险。 不过一想到是波音,那我也不那么确定了

--- 第 6 楼来自 zzr215 的回复 (2026-04-21 09:08:38 PDT) ---

我觉得还好,工业上这方面的转向远没有CS领域快,等真正掉过头了,那时候AI啥水平还不好说呢。而且都有bug,只缺一个背锅的而已。 我个人认为AI的升级好像珠算/笔算到电脑的升级,总不能说电脑因为会出bug,就没有手算的准吧

--- 第 7 楼来自 gin_m 的回复 (2026-04-21 09:09:04 PDT) ---

跟人工不写测试有区别吗。。。

--- 第 8 楼来自 Forlorner 的回复 (2026-04-21 09:09:58 PDT) ---

但凡涉及到安全这俩字的 那都是一堆规章制度 就算可以用vibe coding,也是一堆人在那检查又检查 结论就是没影响,除非人出了问题

--- 第 9 楼来自 popeyes228 的回复 (2026-04-21 09:10:10 PDT) ---

用同一个agent写的等于没写 换个不同模型的agent应该能好点

--- 第 10 楼来自 收束观测者 的回复 (2026-04-21 09:11:59 PDT) ---

Keiour: 而且还有严苛的coding style要求(以前看过LMT还是哪家的代码要求那叫一个厚啊),那拿LLM搓代码相比手搓没啥收益徒增风险 有没有可能越是coding style严苛越适合vibe

--- 第 11 楼来自 Ss004 的回复 (2026-04-21 09:14:33 PDT) ---

我觉得也是,就是八股文啊,把要求直接做成skill.md

--- 第 12 楼来自 gin_m 的回复 (2026-04-21 09:15:27 PDT) ---

TDD啊 不然下次reviewer问我我就要 狡辩 同一个程序员写的等于没写了

--- 第 13 楼来自 camh 的回复 (2026-04-21 09:16:42 PDT) ---

这种行业是需要 P Eng sign off 的 真的是有工程师执照,有eng学历和apprenticeship,考试拿牌照的 engineer,不是码农这种自称engineer

--- 第 14 楼来自 QuinnB 的回复 (2026-04-21 09:18:16 PDT) ---

是不是觉着那么多字儿白打了

--- 第 15 楼来自 收束观测者 的回复 (2026-04-21 09:18:20 PDT) ---

camh: 真的是有工程师执照 我记得这种的一般出了事 camh: sign off 的那个好像要坐牢的? MCAS没人坐牢说明也没人sign off?

--- 第 16 楼来自 NeuralTangentKernel 的回复 (2026-04-21 09:19:40 PDT) ---

MCAS是design specification有问题不是code有问题,high-stake的系统都会经过formal verification

--- 第 17 楼来自 camh 的回复 (2026-04-21 09:20:03 PDT) ---

MCAS有没有人坐牢我真不知道,但是航空业写码要PEng是我曾经突发奇想考eng执照知道的,除了涉及安全的行业,基本不会要求码农有PEng执照 所以码农在加拿大不叫 software engineer,比如 Google 在加拿大的职位叫 software developer,因为engineer要执照所以法律上不能叫engineer

--- 第 18 楼来自 收束观测者 的回复 (2026-04-21 09:21:57 PDT) ---

NeuralTangentKernel: high-stake的系统都会经过formal verification 这个是基于common sense还是确实了解行业内幕 至少我知道很多家自动驾驶的代码是没做形式化验证的

--- 第 19 楼来自 QuinnB 的回复 (2026-04-21 09:24:30 PDT) ---

有被冒犯到 明明好多谭友是拿了PhD的Scientist /uploads/short-url/byKCQHIMWHQBGH6mzZJpXgQgMS.jpeg?dl=1

--- 第 20 楼来自 折木奉太郎 的回复 (2026-04-21 09:26:21 PDT) ---

朋友问我有没有戒指,我说我是scientist

--- 第 21 楼来自 yyyy 的回复 (2026-04-21 09:27:10 PDT) ---

码农又没有执照,波音的码农和泥潭摸鱼楼的码农没啥区别

--- 第 22 楼来自 Keiour 的回复 (2026-04-21 09:27:22 PDT) ---

做linter倒也行,但我记得那玩意几百页 我自己写的几段agents.md LLM都不一定能稳定遵守

--- 第 23 楼来自 NeuralTangentKernel 的回复 (2026-04-21 09:27:53 PDT) ---

FSD这种炼丹炼出来的东西也没法做formal verification不是

--- 第 24 楼来自 QuinnB 的回复 (2026-04-21 09:30:38 PDT) ---

哈哈哈,是的。coding agent特别像一堆engineer在那干活,你开个会说了一堆guideline,他们的态度就是先交差了再说

--- 第 25 楼来自 zzfdafw 的回复 (2026-04-21 09:31:35 PDT) ---

vibe coding别说和印度外包比了 肯定比波音自己的码农都安全 当初在波音时为了cost saving是不写unit test的 跑regression是纯手动的

--- 第 26 楼来自 BigCongming 的回复 (2026-04-21 09:32:33 PDT) ---

看情况,目前用过的所有model单靠自身在稍大一点的codebase里都一定会犯错 产出的code质量很看使用者的水平

--- 第 27 楼来自 AmericanExpress 的回复 (2026-04-21 09:51:13 PDT) ---

vibe code到该测什么都不知道那就真成了俄罗斯轮盘赌了。

--- 第 28 楼来自 收束观测者 的回复 (2026-04-21 10:01:16 PDT) ---

Keiour: 做linter倒也行,但我记得那玩意几百页 我自己写的几段agents.md LLM都不一定能稳定遵守 只要有自动化测试enforce,LLM迭代肯定比人快 NeuralTangentKernel: FSD这种炼丹炼出来的东西也没法做formal verification不是 CV只做环境感知,和飞机上雷达回波信号处理的算法没区别,决策全是传统代码在做,并不是一个读完了交规的LLM在开车 所以跟MCAS的构架是一致的 CNN的输出等价攻角传感器的输出 剩下的是传统决策代码

--- 第 29 楼来自 xnxk 的回复 (2026-04-21 10:03:10 PDT) ---

搞安全的都知道safety 和security的区别,像飞机上的组件都需要过严苛的functional safety和 cyber security 的要求。理论上AI 可以缩短整个开发周期,比如代码哪怕都是通过vibe coding 比如把所有的coding style 喂给ai, 让他生成对应的代码,但是验证端 你还是正常通过人去做验证比如形式化验证。唯一我觉得问题是,因为飞机是个超级庞大的系统,你哪怕对每个组件做了好多测试,但是不能证明这个验证好的组件跟另外一个验证好的组件在同一个系统里不会出现问题。

--- 第 30 楼来自 kaion 的回复 (2026-04-21 10:31:44 PDT) ---

反正一般人都弄不了飞机而且飞机估计零件才是门槛 会不会放个open source的软件出来给大家audit比较好

--- 第 31 楼来自 Keiour 的回复 (2026-04-21 10:39:56 PDT) ---

收束观测者: 只要有自动化测试enforce,LLM迭代肯定比人快 其实写这种代码主要时间就是花在设计,测试,验证上吧,我的观点主要是加速写码/修改这个过程对整体开发时间的缩减是很有限的。 kaion: 会不会放个open source的软件出来给大家audit比较好 无人机还真有一堆开源的飞控

--- 第 32 楼来自 老娘舅 的回复 (2026-04-21 10:54:06 PDT) ---

AI 有的时候太聪明了,test写不过就直接给我删掉了,说这个测试不过不要了,这样可以过build,你说它多有能耐

--- 第 33 楼来自 收束观测者 的回复 (2026-04-21 11:20:48 PDT) ---

Keiour: 加速写码/修改这个过程对整体开发时间的缩减是很有限的 那为什么波音把软件开发放印度去了呢

--- 第 34 楼来自 Yangff 的回复 (2026-04-21 11:37:50 PDT) ---

你看飞机上还放着俩没有formal verification过的 人工 智能在那摇操纵杆呢 FSD好歹还能repro,放俩人今天皮质醇高了你都不一定知道,更别提还有某国美美喝酒开飞机的 另外,FSD没法formal不代表控制层的代码没法formal,但是formal这玩意有多大用的话波音那玩意也不至于有这么蠢的spec 我是觉得做过formal就知道这玩意真没必要看太高,基本上就是真空里的球形spec

--- 第 35 楼来自 Keiour 的回复 (2026-04-21 12:20:39 PDT) ---

说明波音为了短期财报好看什么都干的出来 不过我记得他们MCAS出事之前是整体外包的吧,把规范丢给印度consulting firm 然后让他们自己迭代 ,包括测试,然后MCAS出了大事件之后才把测试+verification逐渐收回一点

--- 第 36 楼来自 Carlos 的回复 (2026-04-21 15:18:10 PDT) ---

收束观测者: 进一步降本增效让印度开发中心用上vibe coding vibe coding比阿三 coding更靠谱

--- 第 37 楼来自 767-400ERX 的回复 (2026-04-21 15:36:28 PDT) ---

飞机的bug比你想象的多的多 MAX最大的问题还是在于隐瞒MCAS 很多公司没去dig也没去培训 它本质上是个trim runaway的问题 国内和美国航司没少遇到MCAS发癫 你只需要抓住trim然后关闭自动配平电门就可以了 该怎么飞怎么飞 最大的问题还是人家完全不知道这个东西 反应也慢了半拍(配平声音是很大的 不可能察觉不到runaway现象

--- 第 38 楼来自 N589AS 的回复 (2026-04-21 15:41:16 PDT) ---

收束观测者: 麦道737MAX 你是懂反向收购的

--- 第 39 楼来自 mayu899 的回复 (2026-04-21 19:32:41 PDT) ---

我觉得用的对的话只会更安全,LLM写的只会比人更符合规范,关键是项目要设计好,彻底明确问题和路径,再有详细明确的test cases

--- 第 40 楼来自 ApplePay 的回复 (2026-04-21 20:48:32 PDT) ---

我觉得核心问题还是谁来vibe 不同人vibe code的验收水平天差地别

--- 第 41 楼来自 收束观测者 的回复 (2026-04-21 20:51:56 PDT) ---

ApplePay: 核心问题还是谁来vibe 那当然是 收束观测者: 麦道的印度软件开发中心 来vibe

--- 第 42 楼来自 gedeepege 的回复 (2026-04-21 20:52:02 PDT) ---

目前的几个版本 opus 4.7, codex 5.4 pro 感觉比人写的靠谱多了 我觉得关键是 prompt 质量和边界条件

--- 第 43 楼来自 Airmiles 的回复 (2026-04-21 20:55:30 PDT) ---

我真觉得没有 反正目前没有

--- 第 44 楼来自 收束观测者 的回复 (2026-04-21 20:58:10 PDT) ---

另外opus和印度SWE谁更贵还真不好说 我觉得麦道数豆人应该不会给用opus的