最近调 UI 逻辑时感受很明显。现在很多营销讲出来的 Vibe coding ，做出来的大多还是简单应用工种，就是页面、表单、展示这些，先把轮廓很快铺出来，看上去像是完成得很快。
但一但真的进到工业化细节，问题就会开始隐僻出来。比如交互状态怎么流转、异常怎么处理、相近逻辑怎么复用、模块之间会不会越来越散，这些都不是把页面画出来就算完。
如果是一些没那么重要的应用，用 90% 以下的 vibe coding ，我觉得的确没什么问题，够快，够省事，也够交差。但如果想把 vibe coding 拉到 90% 以上，那就不是一句“能不能生成”这么简单了。
假设一个功能要拆成 10 个关键节点，想让整体成功率达到 90%，那每个节点的平均准确率其实要去到 98.95% 左右，不是 90%，也不是 95%。因为 0.9895 的 10 次方，才勉强接近 0.9 。
问题就在这里。LLM 生成出来的代码，很多问题是藏着的，不是马上能看到。你想把每个节点从“看起来差不多能用”，一路拉到接近 99% 的稳定度，后面就要花很大的力气去补测、去收口、去反复校正。省下来的开发量，很多时候最后又会从验证和修补上全部还回去。
还有一个很明显的点，LLM 比较容易做局部补全，不太会主动帮你做全局收敛。A 、B 两个模块有接近的方法，它很多时候就是各写一份，先让你跑起来，后面再把冗余和混乱留给人处理。
不过反过来看，如果工作本身就只是为了拿一份薪水，老板也只是以结果导向，只看你有没有按时把东西交出来，那上面这些批判很多时候其实也没什么意义。因为在这种语境下，代码是不是冗余，结构是不是发散，后面是不是难维护，都不是第一优先。先交付，先能跑，先把结果摆出来，反而才是最实际的。
就现有的环境来看，大概就是，工作嘛～
能跑就先算赢了，至于后面是不是一地鸡毛，那是下个版本的 福报 ！！
表面上效率很高，实际上只是把复杂度打包寄给未来。
 |
1
izzzz 1 天前
太对了，某个功能前脚刚写，然后另一个模块要用的时候又重新写一遍
|
 |
2
molvqingtai 1 天前
未来也交给 AI 维护，AI 编写人类友好的代码可能会变成一个伪命题
|
 |
3
JYii 1 天前
大家都在等，等某天线上 vibe coding 生成的代码出事故，回归强制人工 review 。
|
 |
4
weixind 1 天前
AI 的产出和校验要有闭环，要让 AI 能够自查结果错误还是正确，自反馈。
你说的“交互状态怎么流转、异常怎么处理、相近逻辑怎么复用、模块之间会不会越来越散” 问题其实出现在给 AI 的 “需求” 上，不是 vibe coding 的问题。 多试试，用最好的工具和最好的模型。 反正最近几周我写代码的道心已经破了。心态已经崩了。 human in the loop 的比例已经越来越低了。 |
 |
6
kenshinhu OP @weixind 这个我就不是十分认同，AI 又不会自己长出需求，最后还是人来提需求、补约束、做验收。这些问题都出在“需求”上，可需求本来就是工程里最难被一次性说清的东西，不然也轮不到后面一直返工。
我觉得 human in the loop 没少，只是从“手写代码”迁到了“用语言定义问题、约束边界、验收结果”这一层。代码层面参与感是低了，但责任并没有少。 说白了，人的角色還在场上进行决定。 |
 |
7
Dorathea 1 天前  1
"实际上只是把复杂度打包寄给未来"
这个某种程度上我认为是可行/合理的. 听起来是不负责, 但未来或许会有更好的技术去解决这个问题 我有这个观点一部分是受飞出个未来第一季第 8 集《大块垃圾》影响 AI 的发展不会因为 AI 造成的问题而停下脚步. 人类只会让 AI 自我迭代, 让它在未来能解决这个问题 |
 |
8
vfs 1 天前
"LLM 比较容易做局部补全，不太会主动帮你做全局收敛" 赞成。 还有一点，会糊弄个人： 前两天用 codex 开发一个 web 页面。 然后页面上有一块 UI 不要了，让它删掉，完了它的输出中显示 js 中有引用这些 UI 的地方，因此选择把它隐藏掉，而不是删掉。。。
|
 |
9
sillydaddy 1 天前
这个只要看 OpenAI 做的就可以了： https://openai.com/zh-Hans-CN/index/harness-engineering/
首先是完全由 Agent 编码百万行代码： 「我们用了几周的时间来交付最终达到一百万行代码的项目。」 「每一行代码 — 从应用逻辑、测试、CI 配置、文档、可观察性到内部工具 — 全都是由 Codex 编写的。」 然后是针对架构漂移的处理： 「完全自主的智能体也引入了新的问题。Codex 会复现代码仓库中已存在的模式 — 甚至包括那些不均衡或不够理想的模式。随着时间的推移，这不可避免地导致漂移。」 「最初，人类是手动处理这个问题的。我们的团队过去每周五（占一周的 20%）都要花时间清理“AI 残渣”。不出所料，那并不具备可扩展性。」 「相反，我们开始将我们称为“黄金原则”的内容直接编码到代码仓库中，并建立了一个循环清理流程。这些原则是带有主观意见的机械规则，旨在保持代码库的可读性和一致性，以便将来运行智能体。例如：(1) 我们更倾向于使用共享的实用程序包，而不是手工编写的辅助工具，以便将不变式集中管理；(2) 我们不会使用“YOLO 式”探测数据 — 我们会验证边界，或依赖类型化的 SDK ，这样智能体就不会意外地基于猜测的结构进行构建。我们会定期运行一组后台 Codex 任务，扫描偏差、更新质量等级，并发起有针对性的重构 Pull Request 。其中大多数都可以在一分钟内完成审查并自动合并。」 「其功能类似于垃圾回收。技术债务就像一笔高息贷款：不断地以小额贷款的方式偿还债务，总比让债务不断累积，再痛苦地一次解决要好得多。人类的品味一旦被捕捉，就会持续应用于每一行代码。这也使我们能够每天发现并解决不良模式，而不是让它们在代码库中传播数天或数周。」 |
 |
10
usVexMownCzar 1 天前 via iPhone
|
|
11
JYii 1 天前
@usVexMownCzar #10 我所谓的"幻想"，Amazon 现在正在实施，强制双人 codereview 。
|
Select Language