只会用 Cursor 刷代码的 Vibe-coding 真的能让人成
但对我来说，如果一个项目仅仅是“输入指令 → 生成 → 运行 → 上线”，那这种工程实践完全没有快感。真正的软件工程应该是把脑子里的想法具象化到现实世界，而不仅仅是当一个 AI 的指令转发员。
尤其是现在做机器学习（ML）的人，很多人习惯在 Jupyter Notebook 里跑个模型，损失函数降下来了，就觉得这就是一个 ML 项目。但 Notebook 里的代码永远是实验室状态，真正的工程链路应该是：数据 → 模型 → API → 后端 → 数据库 → 部署 → 生产环境。
为了不让自己变成一个只会写 Prompt 的“代码搬运工”，我最近在强迫自己把 AI 辅助开发的重心从“快速出结果”转移到“理解每一步”。比如在使用 Cursor 或 Claude Code 时，我不再满足于它直接给我一个完整的 .py 文件，而是会要求它解释架构决策。
一个具体的实践技巧是，在让 AI 写功能之前，先让它输出一个详细的 system_design.md。我会要求它包含以下具体细节：
- 数据流向： 明确定义 Request 从 API Gateway 进入后，经过哪个 Service，最后如何落库。
- 依赖关系： 必须列出所有第三方库的版本要求，而不是让 AI 随缘安装。
- 潜在瓶颈： 强制要求 AI 预测这个实现方案在并发量增加到 100 QPS 时会哪里崩溃。
这样我在接下来的代码生成阶段，就可以对着这个设计文档去核对 AI 生成的代码是否符合逻辑，而不是盲目地运行。
比如在处理一个简单的模型部署任务时，如果 AI 直接给我一个 FastAPI 的 main.py，我不会直接运行，而是会检查它的异步处理逻辑。我会对比它写的 async def 是否真的在处理 I/O 密集型任务，还是只是为了显得“专业”而加的关键字。如果发现它在异步函数里调用了同步的阻塞库（比如某些旧版的数据库驱动），我会要求它重写，并解释为什么这里会产生性能瓶颈。
我想象中的 AI 辅助开发应该是像《星际穿越》里的 TARS 或者《钢铁侠》里的 JARVIS 那样，它不仅是执行命令的工具，更应该是能理解上下文、能辅助决策的伙伴。但前提是，操作者必须具备识别“正确答案”的能力。如果开发者本身失去了对底层逻辑的掌控，那么 AI 越强大，开发者的竞争力反而越低。
所以，我的目标不是让 AI 代替我思考，而是利用 AI 把我推向更高层级的工程思考。我想弄清楚一个模型是如何从一个 .pth 权重文件变成一个支撑数万用户访问的稳定服务的。这种从 0 到 1 的构建感，才是编程真正的乐趣所在。
