6 篇文章带有标签 “vibe-coding”

这四个术语是当前大模型应用开发的核心范式，从指令设计、信息管理、生成式编程到自主智能体构建，层层递进，共同构成了 AI 应用开发的技术栈。

以下是通俗易懂的拆解：

1. Prompt Engineering (提示工程)

这是最基础的技能，重点在于指令的质量。 如果把 AI 比作一个极其博学但有时听不懂人话的实习生，Prompt Engineering 就是学习如何写出完美的“任务说明书”。

• 核心逻辑：通过调整输入的文字（提示词），引导模型输出更高质量的结果。
• 常用技巧：给 AI 设定角色（“你是一个资深翻译”）、提供示例（Few-shot）、要求逻辑推演（Chain of Thought）。
• 比喻：就像是在搜索引擎里输入更精准的关键词，或者给厨师下达非常具体的菜谱要求。

2. Context Engineering (上下文工程)

随着模型处理能力增强，大家发现“怎么说”固然重要，但 “给它看什么资料” 更重要。这就是上下文工程。

• 核心逻辑：管理和优化输入给模型的信息流。AI 的记忆（上下文窗口）是有限的，你需要精准地挑选出最相关的背景知识喂给它。
• 典型应用：RAG (检索增强生成)。当你问关于公司手册的问题时，系统先去数据库里搜出相关的几段话，塞进对话框里，AI 才能据此回答。
• 比喻：开卷考试。Prompt 是考题，Context 就是那本允许你带进考场的、划满了重点的参考书。

周末买了一台新的 Mac mini，打算正儿八经地捣鼓一下 Claws。Apple Store 的店员告诉我这东西现在卖得像热交换一样火爆，而且每个人（买它时）都是一脸懵逼的样子 :)

说实话，运行 OpenClaw 让我有点心里发虚——要把我的私人数据和密钥交给一个由 400k 行代码组成、靠“氛围感编程”（vibe coded） 堆出来的巨型怪物，而且这个怪物目前正面临大规模的活跃攻击，这真的一点吸引力都没有。我已经看到有报告称出现了实例暴露、RCE（远程代码执行）漏洞、供应链污染，以及插件库里被恶意篡改的技能。这感觉完全就是一片混乱的“西部荒野”，简直是安全噩梦。但我确实非常喜欢这个概念。我认为，就像 LLM Agent（智能体）是 LLM 之上的新层级一样，Claws 现在是 LLM Agent 之上的又一新层级，它将编排、调度、上下文管理、工具调用以及某种持久性提升到了一个新的高度。

环顾四周，既然核心思路已经明确，现在已经冒出了很多轻量级的 Claws。例如，粗略扫一眼，NanoClaw 看起来就非常有意思：它的核心引擎只有大约 4000 行代码（这个体量既能装进我的脑子，也能装进 AI Agent 的脑子，所以感觉是可控、可审计且灵活的），而且默认在容器中运行所有内容。我也很喜欢他们的配置方案——不是通过配置文件，而是通过“技能”来实现！

Andrej Karpathy：氛围编程（vibe coding）

我称之为“氛围编程”（vibe coding）——这是一种全新的编程方式：你完全沉浸在感觉中，拥抱指数级的效率提升，甚至忘掉代码本身的存在。

这之所以成为可能，是因为大语言模型（比如配合 Sonnet 使用的 Cursor Composer）正变得过于强大。而且，我直接通过 SuperWhisper 和 Composer 语音对话，几乎连键盘都不碰。我会提一些极度偷懒的要求，比如“把侧边栏的间距缩减一半”，因为我根本懒得去代码里找位置。我永远点“全部接受”（Accept All），再也不看代码比对（diffs）了。遇到报错信息，我直接原样粘贴回去，一句话都不解释，通常这样就能修好。

代码库的增长速度超出了我以往的理解能力，如果真要搞懂，我得花好长一段时间去通读。有时大模型修不好某个 Bug，我就绕过去，或者要求进行随机改动，直到 Bug 消失。对于那些周末折腾的练手项目来说，这种方式还算凑合，但也确实挺离谱的。

我正在开发一个项目或 Web 应用，但这感觉并不像在编程——我只是观察、动嘴、运行、粘贴，然后它居然大部分时间都能跑通。

Andrej Karpathy：智能体工程（agentic engineering）

很多人转发这条推文，以此纪念“氛围编程”（vibe coding）诞生一周年。简单回顾一下：

Peter Steinberger (OpenClaw 的创造者) 分享了核心主张 “拒绝套路，直接对话”。他认为当前的 AI 智能体（尤其是 GPT-5-Codex）已足够强大，无需过度依赖 RAG、复杂的子智能体或繁琐的规格文档等“炒作”手段。

最近我在这里变得安静了许多，因为我正埋头于最新的项目。Agent 智能体工程（Agentic engineering）已经变得如此强大，以至于现在它几乎包揽了我 100% 的代码编写。然而，我看到仍有许多人在解决问题时，还在搞那些华而不实的复杂套路，而不是专注于把活干完（Getting sh*t done）。

这篇文章的灵感部分来自昨晚在伦敦参加的 Claude Code Anonymous 交流会，部分原因是从我上次更新工作流以来已经过了“AI 领域的一年”（实际才几个月，但变化巨大）。是时候同步一下进度了。

所有的基本理念仍然适用，所以我不会再提上下文管理等简单的事情。你可以阅读我的 《AI 开发最佳工作流》 作为入门。

背景与技术栈

我独立工作，当前项目是一个约 30 万行代码（LOC）的 TypeScript React 应用，包含 Chrome 扩展、CLI、基于 Tauri 的客户端以及基于 Expo 的移动端。我使用 Vercel 托管，一个 PR（拉取请求）大约在 2 分钟内就能交付新版本网页进行测试。

Peter Steinberger (OpenClaw 的创造者) 分享了他在使用 AI 智能体构建软件方面的最新经验，特别是关于如何以推理速度交付代码，以及他对模型（如 GPT 5.2 和 Opus）的看法。

自五月以来的变化

“氛围编程”（Vibe Coding）在今年取得的进步令人不可思议。大约在五月份时，我对某些提示词（prompts）能直接生成可运行的代码感到惊讶，而现在，这已经成了我的预期。我现在的代码交付速度快到不真实。从那时起，我消耗了大量的Token。是时候更新一下心得录了。

这些智能体（Agents）的工作方式很有趣。几周前有人争论说，为了感受糟糕的架构，人必须亲手写代码，使用智能体会导致脱节——我完全不同意这种观点。当你花足够多的时间与智能体合作，你就会准确地知道某件事应该花多少时间。当 codex 回来时如果未能一次性解决问题，我立刻就会产生怀疑。

我能创建的软件数量，现在主要 受限于推理时间 和 硬核思考。坦率地说——大多数软件并不需要硬核思考。大多数应用只是把数据从一个表单搬运到另一个表单，也许存进某个地方，然后以某种形式展示给用户。最简单的形式是文本，所以默认情况下，无论我想构建什么，它都始于 CLI（命令行界面）。智能体可以直接调用它（CLI）并验证输出——从而闭环。

模型转变

真正解锁像工厂一样构建软件能力的，是 GPT 5。

主要介绍了软件开发领域正在经历的重大变革，将其分为软件1.0（传统手工编码）、软件2.0（基于神经网络权重训练）和软件3.0（通过自然语言提示编程大型语言模型）。演讲者将大型语言模型（LLMs）比作新型操作系统和基础设施，指出它们既具备公用事业的性质（按量付费、集中式），也展现出类似芯片制造厂和操作系统的特征，且目前仍处于早期阶段（类似于1960年代的计算）。进一步探讨了LLMs的认知特性（如广博知识、幻觉、记忆局限），并强调了开发部分自主应用的重要性，这些应用能让人类通过图形用户界面和自主性滑块有效监督AI。最后，演讲者提出，随着自然语言编程的兴起，人人皆可编程，并呼吁开发者为智能体优化数字基础设施和文档，预示着一个由人类与AI协作构建的 “钢铁侠战衣”式未来。

Software is changing. (again)

Map of GitHub

Map of GitHub 是一个创新的数据可视化项目，旨在以交互式地图的形式展示 GitHub 上的开源项目生态。该项目由开发者 Anvaka 创建，通过复杂的算法和可视化技术，将超过 400,000 个 GitHub 仓库以节点和连接的形式呈现，帮助用户探索项目之间的关联、技术趋势以及开源社区的演变。

Software 2.0

Software 3.0

Part 1: 如何思考 LLM

LLM 具有公用事业的特性