惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

小众软件
小众软件
博客园_首页
M
MIT News - Artificial intelligence
雷峰网
雷峰网
GbyAI
GbyAI
博客园 - 叶小钗
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
S
SegmentFault 最新的问题
H
Help Net Security
Apple Machine Learning Research
Apple Machine Learning Research
H
Hackread – Cybersecurity News, Data Breaches, AI and More
博客园 - 【当耐特】
V
Visual Studio Blog
月光博客
月光博客
G
Google Developers Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
腾讯CDC
云风的 BLOG
云风的 BLOG
美团技术团队
Microsoft Azure Blog
Microsoft Azure Blog
A
About on SuperTechFans
有赞技术团队
有赞技术团队

V2EX

我用 AI 写代码,但终端管理反而成了累赘——于是我做了 codux [调研] 各位在公司都用什么 ide 和 agent 写代码? 老运维 share 一个运维平台 新电脑 brew install node 之后,一个小设置可以提升对供应链投毒的防御 GLM-Coding 调用持续报错: z.ai 的 Lite 套餐几乎无法使用,官方 Pro/Max 是否稳定? 上海漕河泾内推,本组有 2 个 hc,一个后端,一个前端,预算都是 20k 左右,不打卡,氛围好 如果 V2EX 上有一组不永久保存聊天记录(比如只保存 7 天或者 24 小时)的聊天室,那么会开启哪些有用或者有趣的可能? gemini cli 貌似挂了,一直返回 403 第一次在自媒体上赚到钱 收集了最近在使用的低价 GPT, Gemini,邮箱等 AI 会员的小店合集 讨论个大实话:现在企业还在说 AI 编程提效 20%, 30%的,真的太落后,没用懂 AI。因为包括很多前沿公司,已经狂奔到提效 200%-500%的情况 [招聘][远程][币安] 前端/后端/QA/iOS/Android 至少 3 年以上经验 目前有大量 HC 欢迎投递 Chatgpt Pro 用量用不完的可以开这些设置 面试的时候好像遇到钓鱼了,给各位避个坑 cursor 年续费 22 号到期, 自动续费是否还是老的计次套餐呢 被两件破事毁掉的一下午,琐碎的内耗消磨人的精力 使用 Planet 存储 Codex 的会话或者重要信息 如果业务部门领导不要你开发功能,而是要求你教会它用 claude code 开发功能,你会怎么做? 分享一个 MacOS 接绿联 CM818 USB 转 DP 转接器使用感受 我的 HR 朋友 10 年老 Java ,非全大专,大家帮忙看看简历 开源了一个 AI 口语练习工具,音素级发音评分,完全免费可自部署 V2EX 上有哪些你觉得很有趣、印象深刻的妹纸? 字节为啥不出个国内版 Vercel? 有在大马的朋友吗? 问个运营商问题 你们在有领导的公司大群发过的最大胆的消息是什么 公司裁员,目前没有工作。想试试摆摊,做一个移动鲜啤打酒车 我的硬盘 Memblaze Pblaze 5 Linux 下不识别,给 Linux 内核提交了补丁, AI 说有望被合并 只有我一个人觉得 codex 不好用? 做了个 AI + 真人专家监督的广告投放平台 Auxora, 7 个品牌跑出 6x ROAS
关于 Vibe coding 的一点想法
kenshinhu · 2026-03-27 · via V2EX

最近调 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 两个模块有接近的方法,它很多时候就是各写一份,先让你跑起来,后面再把冗余和混乱留给人处理。

不过反过来看,如果工作本身就只是为了拿一份薪水,老板也只是以结果导向,只看你有没有按时把东西交出来,那上面这些批判很多时候其实也没什么意义。因为在这种语境下,代码是不是冗余,结构是不是发散,后面是不是难维护,都不是第一优先。先交付,先能跑,先把结果摆出来,反而才是最实际的。

就现有的环境来看,大概就是,工作嘛~

能跑就先算赢了,至于后面是不是一地鸡毛,那是下个版本的 福报 !!

表面上效率很高,实际上只是把复杂度打包寄给未来。