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

推荐订阅源

Google DeepMind News
Google DeepMind News
罗磊的独立博客
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Last Week in AI
Last Week in AI
云风的 BLOG
云风的 BLOG
T
The Blog of Author Tim Ferriss
Y
Y Combinator Blog
A
About on SuperTechFans
WordPress大学
WordPress大学
B
Blog
Martin Fowler
Martin Fowler
Jina AI
Jina AI
I
InfoQ
P
Proofpoint News Feed
小众软件
小众软件
S
SegmentFault 最新的问题
V
V2EX
B
Blog RSS Feed
量子位
大猫的无限游戏
大猫的无限游戏
aimingoo的专栏
aimingoo的专栏
博客园 - 三生石上(FineUI控件)
MongoDB | Blog
MongoDB | Blog
美团技术团队

☕Vibe Coding🤖

给 AI 安排好任务,让它操作浏览器,修改域名解析,帮我把一个网站上线。然后我去厨房削苹果。削着削着就在想, MD 为什么是我在这削苹果,而不是我去上线网站。 AI 把我调教了,从 0 消费,到月消费 1200 元。 有卖 GPT-IMAGE-2 的中转站吗? 来轰炸我吧,想找一个 让 ai 加班一夜烧了 7 亿 token🙈 ccswitch 如何同步 wsl 和 windows 的配置? 有用 Taro 真的做出来成品 App 的人吗 有使用 aliyun 的 token plan 的吗?两小时用了 30%左右 怪不得老板喜欢压迫员工,原来这么爽 感觉有点 ai 阳痿了,话说你们都用 ai 做了啥 你们用 opus 和 gpt 的时候 effort 开的是 medium 还是 extra high Xiaomi MiMo 随心用 请问大家没有用 AI 开发的流程规范文档 写了一个让 claude code 等工具 hit limit 后到时间继续执行的工具,且在 tmux 中运行 ssh 断了也没事 Vibe Coding 了一个项目, 2 周基本已全部完成,感慨一下我已经基本上可以下岗了。 大家觉得 OpenCode 和 Claude Code 哪个更好用呢 日常 vibe coding 总有一两天极易暴躁 真心问: 国内几家 coding plan 哪家体验最好? 好奇大家 vibe coding 等待的时候在做什么 大项目百万行代码如何减少 AI 读取代码消耗 Token 不要在 520 当天晚上 vibe coding 老板对员工的态度是不是 就像程序员对 agent 的态度? Gemini CLI 今天不知道为什么一直认证失败无法使用,网页已经明确提示 “Success! You can close this window now.”,但终端里却在最后依然甩出 fail 需求写得太细效果反而更差的原因是什么?有没有改善的方法? 请教一下, codex app 怎么设置自定义的后台地址和模型? 有没有好的 skills 推荐,适合全局安装的,主要是开发用 codex plus + cursor pro 你们一个月够用吗 用了半天 Claude Code 2.1.139 新增的 agent view 和 backgroud session,有用但还是有不少问题 咨询个问题,关于大家的公司是如何使用 claude 模型的? Vibe Coding 不仅耗 token, 也挺耗流量的 马上 claude 的订阅要到期,有必要换成 gpt 吗
关于 Vibe coding 的一点想法
kenshinhu · 2026-03-27 · via ☕Vibe Coding🤖

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

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

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

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

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