拒绝Vibe Coding，回归Craft Coding
AI Coding Without the Vibes
面对AI编程的浪潮，我们不应完全排斥，也不该盲目依赖。让AI替你写代码的“Vibe Coding”模式，看似轻松，实则让你失去对代码的掌控，甚至自我欺骗以为掌握了技能。真正的出路是“Craft Coding”：由你亲手编写代码，将AI视为严格的代码审查者。这种方式既能利用AI发现那些你难以察觉的Bug，又能确保你深入理解每一行代码的逻辑。正如科学实验需要精确无误的代码支撑，只有亲自编码并让AI检查，才能在享受技术便利的同时，保持对技艺的敬畏与精进。
认知技能就像肌肉一样：很难获得，却很容易失去。
HN 评论区
55- lubujackson
在我看来，这错过了 AI 最大的用途，那就是增进理解。这段代码在做什么？这里是否有数据泄露的风险？该函数下游的权限是否得到了执行？
如果你利用 AI 激进地攻击一个 PR，并结合人类的洞察力，代码审查可以深入得多。规划功能时也是如此：
我能将这些逻辑合并到一个共享函数中吗？错误表面是否暴露给了用户，是否存在任何漏洞？这个 PR 会影响哪些现有功能？这个查询能否更高效？
LLM 在处理聚焦的问题时表现出色，无论是向上还是向下的抽象层，还是各种各样的关注点。将这些聚焦的关注点层层堆叠，就能形成对你正在做或正在写的内容的深刻理解。
理解才是真正的产出，代码只是副产品。
- conception
“但这就像告诉 70 年代的学生假装计算器或计算机不存在一样。”
如果 70 年代或今天的学生在需要它们来推进工作（比如生物信息学之类的领域）之前，都假装它们不存在，那么他们肯定会过得更好。有很多研究表明，将思考过程外包会导致对材料的理解变差——例如，边规则（side rules）比计算器能带来更好的理解。
- ripe
很有见地：
> “vibe-coding”这个词暗示了一种放任自流的态度，你并不真正关心结果，只是图个乐子。这就是这个词刚被造出来时的含义，但世界已经变了。在许多公司，专业程序员使用 AI 的方式让人无法想象他们还会仔细阅读生成的代码。这就是现代版的 vibe-coding。将决定权交给 AI，不纠结于每一行代码，只盯着代码是否通过测试，以及在生产环境中是否抛出问题。
这种工作方式才是唯一能证明对 AI 行业投入千亿美元押注合理性的理由。我同意，这种方法应该被称为 vibe-coding。
- conqrr
这篇文章非常切中我自己的想法，看到其他人也有同样的思路真好。
核心模块：我自己编写，AI 审查，并借助 AI 来发现/学习。
我不太在乎“工匠精神”的部分：API 层、CLI 层、冒烟测试、集成测试——这些部分重度依赖 AI，相应地减轻人工审查的力度。
显然这需要极大的耐心，也很容易犯错，但在状态好的时候，这是可行的。
- andai
我从纯手动编码，到用 LLM 做“手术式修改”，再到“哇，AGI（通用人工智能）来了！”，再到“哈哈，搞错了，还差得远”，再到纯手动编码（我的脑子还能用！），最后又回到了“手术式修改”。
我目前的方法是“请求非常小的 diff”加上“极其仔细地审查它们”。
不过我不是在上班，而是在开发一款多人游戏。
主要发现：前沿模型无法可靠地修改 Pong 游戏而不搞坏它，所以它们的技能似乎具有很强的领域特异性。（好吧，公平地说，我有一半时间也做不到！）这可能是因为它们“对时间盲目”。我曾有一个模型试图通过以每秒 0.1 帧的速度运行游戏，并将每一帧塞进视觉 API 来测试游戏……
如果你给它们留下任何误解的空间，它们就会死盯着这个点，做出最蠢的事情。如果你不仔细检查一切，你以后会发现这一点，然后你会哭出来的。
奇怪的是，形式化证明并不能改善这种情况：它们只会从数学上证明，那个荒谬、毫无意义且背道而驰的实现完全没有缺陷。（当然，在实现内部它确实有帮助。）
它们无法形式化地证明当你告诉它们构建某物时，你到底是什么意思。这项工作仍然令人沮丧地需要人类来完成！
当前的不满：(1) 现有的工具是为超级臃肿的代码库设计的（即旨在加载尽可能少的上下文），这使得它们对于小型仓库和小型修改来说相当笨拙。（我有一个手术式编辑工具，我需要 […]）