Vibe Coding 并不是问题所在，理解技术栈才是。
一款 AI 工具曾递给我这样一个配置文件：
DATABASE_URL = "postgresql://admin:SuperSecret123@db.internal:5432/app"
API_KEY = "sk-live-4f9a..."
它能运行。这就是陷阱所在。演示程序跑通了，评审员也点头认可了。但那个密钥现在永远留在你的 git 历史记录中了。任何进入你仓库的人都能看到它。
我不是开发者。我从事系统工程工作已有二十年。我构建的是应用程序运行的基石。我构建主机、网络和数据库。
当我使用 AI 工具时，我不会像其他人那样栽跟头。原因如下。
Andrej Karpathy 曾谈到针对一次性项目的“vibe coding”。有些人走得太远了。他们不再关注代码，现在，他们甚至不再关注系统。你可以忽略代码，但你不能忽略系统。系统才是真正运行的东西。
我经常会推翻 AI 的建议，因为模型缺乏运维层面的上下文：
- 操作系统：AI 可能会为安全应用建议使用 Windows。它忽略了授权许可的成本。一台免费的 Ubuntu 服务器能以更低的成本完成同样的工作。
- 数据库：AI 可能会选择 MySQL。它不知道一年后的凌晨 2 点，我还能管理哪种引擎。
- 安全性：AI 的标准止步于“登录功能正常”。真正的安全性需要条件访问和受信任设备。你无法仅凭“感觉”实现这些。
- 网络：AI 经常建议向整个互联网开放端口。而我会将访问权限限制在特定的管理网络内。
AI 把网络视为别人的问题。但事实并非如此。
解决硬编码密钥的方法很简单。使用环境变量：
import os
DATABASE_URL = os.environ["DATABASE_URL"]
除非你阻止它，否则模型会将密钥直接嵌入到你的文件中。
Vibe coders 之所以失败，是因为他们认为应用程序代码就是整个系统。事实并非如此。应用程序只是建筑的一层。如果你没有打好地基，建筑就会倒塌。
当我使用 AI 时，我不会以“帮我构建 X”作为开头。那样做出来的演示程序在生产环境中会崩溃。我会先花三十分钟讨论约束条件和权衡取舍。我会让模型基于这些逻辑编写一份规格说明书。这可以避免后续数小时的清理工作。
问题不在于工具。问题在于你在不了解改动影响范围的情况下进行变更。如果你理解了底层基础，那么跟随“感觉”也是安全的。
分界线不在于你编写了多少代码，而在于你是否理解代码所赖以生存的基础。
因为模型每次都会出错，你不得不反复进行的“覆盖（override）”操作是什么？
来源：https://dev.to/kkierii/vibe-coding-isnt-the-problem-not-understanding-the-stack-is-4kif
可选学习社区：https://t.me/GyaanSetuAi