@DeRonin_: 我的朋友今晚让我审阅他应用里的代码,“就看一眼,告诉我哪里不对劲。”我发现了:> 22…
摘要
一位开发者描述了他发现朋友应用中的极度臃肿——220个端点、40个密钥、30.9万行代码——然后使用Claude重写为15个端点、2个密钥、不到3万行,并认为没有工程纪律的‘氛围编程’只会导致混乱。
查看缓存全文
缓存时间: 2026/05/20 22:36
我朋友今晚让我帮忙审查他应用里的代码。
“就看一眼,告诉我哪有问题”
结果发现:
220 个 API 端点,实际只用了 20 个 环境变量里 40 多个密钥,运行项目只需要 2 个 30.9 万行代码 24 万行没人看的文档 markdown 文件里超过 100 万行的 agent 日志 单个文件超过 5000 行,毫无架构可言 测试……根本没人知道测的是什么
他还特别得意:“看看我的 agent 搭建得有多高级”
几十个 agent 角色,到处都是技能文件,知识库管理形同虚设,一个循环在构建产品根本不需要的功能。
我用 Claude 帮忙,今晚把整个东西重写了。
功能一样,架构清晰,测试规范,代码量只有零头。
结果:
220 个端点 → 15 个 40 个密钥 → 2 个 30.9 万行 → 不到 3 万行 仓库里不再有日志垃圾 每个测试都覆盖真实场景
这话没人爱听:
没有工程纪律的 vibe coding,不过是有漂亮终端输出的有序混乱。
agent 不懂你的产品需要什么。你懂。如果你说不清每个文件是干嘛的、为什么存在,那你就不是在维护代码库,你只是有个碰巧能跑的烂摊子。
干净的代码 > 聪明的代码。每次都是。
记住了。
本以为这活 20 分钟就能审完。
结果我整晚都在火车上搞这个 lol
但朋友挺高兴的。
相似文章
@mattpocockuk: 今天凭感觉糊了个应用,内部实现完全没看。现在它出了问题,我又怕又沮…
Matt Pocock 分享道,在凭感觉糊了一个应用并遇到问题后,他想起 /improve-codebase-architecture 这个技能是修复问题的好帮手。
@shugarDadddy: 在启动你的 vibe coded 项目之前,先运行这个提示:“对应用程序进行全面审计,涵盖…
一条推文线程分享了在发布前对 vibe coded 项目进行全面审计的提示,涵盖安全性、可靠性、并发性、可访问性和 UI 一致性。
@no_stp_on_snek: Grok 4.5 评测 - 我本周的令牌用完了。编写了一个名为“Hermes Go”的免费iOS/Android应用。正在提交到…
一位用户评测了Grok 4.5的代理式编码能力,详细描述了如何在32小时的会话中,通过104个提示词,最终生成了一个功能完整的Flutter应用(Hermes Go),包含33k行代码。该模型自主逆向工程了API,并根据反馈进行迭代。
我决定回归手写代码
作者在重构一个 Kubernetes 仪表盘工具时反思道,虽然借助 AI 进行“氛围编程”(vibe-coding)能加速功能开发,但在缺乏人工监督的情况下,往往会导致架构臃肿和技术债务。
@eng_khairallah1: https://x.com/eng_khairallah1/status/2055579146684936644
一份详细指南,解释了vibe编码的概念,并提供了使用Claude免费构建应用程序的分步教程,面向非程序员。