https://www.swiftmiss.fun/tags/%E6%99%BA%E8%83%BD%E4%BD%93/Recent content in 智能体 on 隔空想念Hugo -- gohugo.ioen© 2025, VanguardMon, 02 Mar 2026 00:00:00 +0000https://www.swiftmiss.fun/post/2026-03-02-agentic-engineering/Mon, 02 Mar 2026 00:00:00 +0000https://www.swiftmiss.fun/post/2026-03-02-agentic-engineering/智能体工程：AI 辅助开发的正确打开方式 2026 年 2 月 4 日 一年前，Andrej Karpathy 创造了"vibe coding"（氛围编程）这个词，用来描述一种"放飞自我"的编程方式：你写个提示词，把键盘交给 AI，不看代码差异，它输出什么你就接受什么，遇到报错就把错误信息粘贴回去让 AI 再试。这个概念精准地捕捉到了一种真实存在的现象——用纯 AI 自动驾驶模式来快速搭建原型或最小可行产品。 问题是，“vibe coding” 已经变成了一个"万能标签"。人们用它来描述从周末小项目到严谨工程流程在内的一切——后者是指在人类监督下，AI 智能体负责具体实现的专业开发模式。这两者有本质区别，把它们混为一谈正在造成真正的混乱和损害。 Vibe coding 到底是什么 Vibe coding 的核心特征是跟着感觉走，不审查代码。你写提示词、接受输出、运行看效果。不行就把错误粘回去再试，一直反复提示。在这种模式下，人扮演的是"提示词 DJ"，而不是工程师。 这种方式在以下场景确实好用： 全新项目的 MVP、原型和黑客马拉松 demo。 你需要周日之前搞出个能跑的东西，代码质量无所谓。个人脚本和一次性工具。 你是唯一的用户，坏了就重新生成。学习和探索。 新手可以借助 AI 做出原本做不出的东西，通过 AI 的输出"照葫芦画瓢"来学习。创意头脑风暴。 故意让 AI 大量生成各种方案，看看它有什么思路，然后丢掉重来、认真构建。 如果 vibe coding 能让数百万原本不会写代码的人拥有开发自定义软件的能力，那这确实是一个了不起的进步。这种技术在工具箱里有它的一席之地。 但它的失败模式已经被充分记录了。套路总是一样的：demo 效果很棒，然后现实就来了。当你想修改、扩展或加固安全性时，就会发现没人真正理解这些代码到底在干什么。正如一位工程师说的：“这不是工程，这是在碰运气。” 我们需要一个更好的术语来描述专业版本 事情是这样的：很多经验丰富的工程师现在正从 AI 中获得巨大的生产力提升——2 倍、5 倍、甚至更多——同时保持着代码质量。但他们的工作方式和 vibe coding 完全不同。他们在写提示词之前会先写需求规格文档，会逐行审查每一个代码差异（diff），会运行测试套件。他们把 AI 当成一个速度很快但不太靠谱的初级开发者，需要持续监督。我个人一直喜欢"AI 辅助工程"（AI-assisted engineering）这个说法，也讨论过它如何描述了人类始终保持参与的那一端。 Simon Willison（我非常欣赏他的工作）提出了"vibe engineering"（氛围工程）——他想保留"vibe"这个词，同时加上"engineering"来传递专业纪律的信号。但在观察了社区围绕这个话题争论数月之后，我觉得"vibe"这个词包袱太重了。它天然传达出随意感。当你告诉 CTO 你在"vibe engineering"公司的支付系统时，你能看到他脸上的担忧。 Andrej Karpathy 本周提出了"agentic engineering"（智能体工程），我觉得这个叫法很不错。