关于 AI 编程的一些浅思

近期，主流 AI 纷纷发布了自家的命令行界面（CLI）编程助手，如 OpenAI Codex CLI^[1]、Anthropic Claude Code^[2] 以及 Google Gemini CLI^[3]。将先进的 AI 推理模型引入开发者终端（Terminal），或许又是软件开发领域的一次重大更新。

面对层出不穷的 AI 编程工具，身为程序员的我早已麻木（完全跟不上节奏）！像极了 AI 刚出现的前两年，每天睁开眼都有新玩意出现。为了重新对 AI 编程建立宏观认知，我收集整理了目前比较主流的一些框架或工具（这篇文章只是对大脑印象的即兴整理，可能会有所遗漏，仅供参考）。

Agent

Agent AI 是指能够自主感知环境、做出决策并采取行动以实现特定目标的 AI 系统。它们常以框架或库的形式存在，开源代表有：

• LangChain^[4] & LangGraph^[5]：
• LangChain 是一个用于构建大语言模型（LLM）驱动应用的框架，能够帮助你串联可互操作的组件与第三方集成，简化 AI 应用的开发流程，同时在底层技术不断演进的过程中保持架构的前瞻性和可持续性。
• LangGraph 是一个低层级的编排框架，专为构建、管理和部署长时间运行、具有状态的智能代理而设计，已被 Klarna、Replit、Elastic 等推动代理未来的公司所采用。
• AutoGen^[6]：是一个用于创建可自主行动或与人类协同工作的多智能体 AI 应用程序的框架。
• CrewAI^[7]：是一个轻量级、极速的 Python 框架，完全从零构建，不依赖于 LangChain 或其他代理框架。它兼具高级简洁性与底层精细控制，适合开发适用于各种场景的自主 AI 代理。
• LlamaIndex^[8]：是使用 LLM 和工作流为你的数据构建 LLM 驱动代理的领先框架。
• Agno^[9]：是一个专为构建多 Agent 系统而设计的 Python 框架，其核心优势在于支持 Agent 间共享记忆、知识和推理能力。工程师和研究人员使用 Agno 来构建不同级别的 Agent 系统：
• 一级：具备工具和指令。
• 二级：拥有知识和存储功能。
• 三级：配备记忆和推理能力。
• 四级：能够进行推理和协作的 Agent 团队。
• 五级：具备状态和确定性的 Agent 工作流。
• GPT Researcher^[10]：是一个智能体代理，专为各种任务的综合在线研究而设计。代理可以生成详细、正式且客观的研究报告，并提供自定义选项，专注于相关资源、结构框架和经验报告。
• ...

过去，多数 Agent 框架侧重于任务编排和流程控制，虽简化了开发，但仍需代码。随后，Browser Use^[11] 等 AI 浏览器代理的出现，让普通用户无需编码就能自动化在线任务。更进一步，OpenAI 的 CUA（Computer-Using Agent)^[12] 将这一理念推向新高，使 AI 能像人一样操作真实计算机界面，跨网页、文件和应用执行复杂指令，实现从单一任务到多代理协同。从对话式到 AI 浏览器（如 Dia^[13]）再到系统级代理，AI 与操作系统的融合正加速。

还有基于 Agent 诞生出的定制工作流：

• n8n^[14]：是一个工作流自动化平台，为技术团队提供代码灵活性与无代码便捷性的结合。它支持超过 400 种集成，具备原生 AI 能力（可基于 LangChain 构建 AI Agent 工作流，并接入自有数据和模型），并允许用户全面掌控数据和部署。n8n 提供自托管或云服务选项，并支持高级权限、SSO 等企业级功能。此外，它还拥有活跃的社区和大量现成模板。
• dify^[15]：是一个开源的 LLM 应用开发平台。其直观的界面融合了 Agentic AI 工作流、RAG 流水线、代理功能、模型管理、可观察性功能等，让你能够快速从原型开发过渡到生产环境。
• ...

编程助手

主要分为 IDE 集成、Online 生成式和 CLI 等：

• IDE 集成：VSCode^[16]、Cursor^[17]、Windsurf^[18]、Zed (基于 Rust 实现)^[19]、Trae^[20] 等。
• VSCode 插件：Cline^[21]、GitHub Copilot^[22]、Gemini Code Assist^[23]、Claude Code for VSCode^[24]、Windsurf Plugin^[25]、Tabnine^[26]、Cody^[27]、Qodo Gen^[28]、Roo Code^[29]、Augment^[30]、Lingma (通义灵码-国产)^[31]、Trae AI (豆包-国产)^[32] 等。
• Online 生成式：v0.dev^[33]、bolt.new^[34]、jules^[35]、Replit AI^[36] 等。
• CLI：除 Codex、Claude Code、Gemini CLI 外，还有 aider^[37]、codename goose^[38]、Open Interpreter^[39] 等。

我个人认为 GitHub Copilot 算是比较特殊的存在，既有 VSCode 插件，也有网页版 Copilot Web^[40]、同时还与 GitHub 进行了深度集成，支持仓库代码分析、Issues、PR 处理等。

IDE 集成通常支持 Chat 侧栏对话、代码行对话、Agent、MCP 等多种模式，辅助编程应该是 Agent、MCP 最为重要的落地场景了。Cursor 或许是目前体验最好的 AI IDE，但 VSCode 的持续更新也不容小觑（updates log^[41]），毕竟目前大部分 AI IDE 都是其 Fork 版（在插件支持度上有所限制，不如原版 VSCode）。

📌 插件禁用风波

Cursor 是基于 VSCode 套壳的，目的是复用其庞大的插件生态。但前段时间 VSCode 开始限制其核心插件（微软自研）只能用于微软产品，套壳类 IDE 不再支持。影响的主流插件有 C/C++、 Remote-SSH、Pylance 等。禁用核心插件大概率是因为 VSCode 被社区 Fork 后，出现了大量 AI IDE，与微软自家的 GitHub Copilot 形成竞争，过度依赖套壳编辑器的朋友需要评估一下插件影响范围。

相关 issues：Has the VSCode C/C++ Extension been blocked?^[42]、Microsoft C/C++ Extension appears to no longer support unofficial forks of VS Code^[43]。

Terminal 终端

各类 CLI 的运行离都不开 Terminal，目前体验最好的 AI 终端非 Warp^[44] 莫属，支持 agent、mcp 等功能。starship^[45] 是一款基于 Rust 实现的终端美化，编程字体 Nerd Fonts^[46] 针对开发者添加了大量字形（图标）的字体。

AI 开发

据我观察，目前 AI 应用、MCP 或 CLI 用到的编程语言有 JS、Python、Go、Rust 等。JS 简单易上手，多数情况下都是首选。而 Python 称得上 AI 编程一等公民了，很多 AI 类框架或库都使用 Python 开发。Go 和 Rust 常见于服务或命令行开发，往往侧重于性能。

比较有意思的是 Codex CLI 原本使用 TypeScript 开发，但目前正在实现 Rust 版，最终将取代 TypeScript 版。用 Rust 重写，性能只是很小一部分原因，最主要是将应用原生化，减少对外部环境的依赖（相关 issues：Rust CLI Cutover (Burndown List)^[47]）。

注：TS 版最终会被编译为 JS，要运行 JS 需要 Node.js 环境（用户需在系统中安装 Node.js）。而通过 Rust 原生化后，用户可以直接执行二进制 CLI 文件，无需安装 Rust 环境。

大模型协议

关于 MCP、A2A 之类的东西，其实之前写过文章，这里就不再赘述了（深度解析：Anthropic MCP 协议、浅谈 Agent、MCP、OpenAI Responses API、 Google A2A：多智能体通信协议）。简单概括就是：MCP（Modal Context Protocol^[48]）是一个开放标准，用于规范如何向大语言模型（LLM）提供上下文信息。你可以把它想象成 USB-C 接口 —— 一个统一标准的接口，允许应用程序将工具、数据、用户偏好或环境线索等内容整洁地传递给模型。

后来社区还出了个 AG-UI^[49] 协议（The Agent-User Interaction Protocol，代理-用户交互协议）。协议虽多，如果从讨论和使用情况来看，似乎只有 MCP 是热门（尤其在编程领域）。

AI 文档

• Context7^[50]：LLM 在生成代码建议时，常因依赖过时或通用信息而导致问题，例如提供基于旧训练数据的过时代码示例、生成不存在的“幻觉” API，以及针对旧软件包给出过于笼统的答案。而 Context7 通过其 MCP (Model Context Protocol) 机制，能直接从源头获取最新、针对特定版本的文档和代码示例，并将其直接整合到用户的提示中，从而确保 LLM 输出的建议准确、及时且高度相关。
• DeepWiki^[51]：基于 GitHub Repo 源代码生成最新版可对话式文档，由 Devin^[52] 驱动。访问链接 https://deepwiki.com/<owner>/<repo>
  （DeepWiki：GitHub 源码阅读神器）。
• Gitingest^[53]：将任意 GitHub 代码库转换为适合大语言模型（LLM）提示的文本摘要。访问链接 https://gitingest.com/<owner>/<repo>
• ...

在使用 Context7 MCP 编程时，还可以配合 Sequential Thinking MCP Server^[54] 来进一步提高输出代码准确性。如果想了解更多 MCP 服务，可以使用 mcp.so^[55] 之类的网站进行检索。

AI SDK

• AI SDK^[56]：是一个基于 TypeScript 的工具包，它能帮助你利用 Next.js、React、Svelte、Vue 等主流前端框架以及 Node.js 等运行时环境，轻松构建由 AI 驱动的应用程序。其核心模块提供了统一的 API 接口，让你能与 OpenAI、Anthropic、Google、自定义等多种模型提供商无缝交互。
• Google Gen AI SDK^[57]：是一款专为 TypeScript 和 JavaScript 开发者设计的工具包，旨在帮助他们构建由 Gemini 提供支持的应用程序。该 SDK 同时支持 Gemini Developer API 和 Vertex AI，并完全兼容 Gemini 2.0 的各项功能。
• OpenAI SDK^[58]：提供了从 TypeScript 或 JavaScript 方便地访问 OpenAI REST API。
• Anthropic SDK^[59]：该库提供了从服务器端 TypeScript 或 JavaScript 方便地访问 Anthropic REST API。
• ...

这里推荐使用由 Vercel 维护的 AI SDK，几乎可以满足大部分 LLM API 调用需求。

AI 代码生成

目前 Next.js、React、Tailwind CSS 之类的框架对 AI 代码生成比较友好，很容易生成美观大方的网页，如果想构建动画或 3D 效果，可以使用 p5.js^[60]、three.js^[61] 等。尤其是使用 shadcn/ui^[62] 之类的组件，可以快速生成风格统一的界面，如果对 shadcn/ui 产生了审美疲劳，还可以用 tweakcn^[63] 可视化主题编辑器进行换肤（支持自定义颜色、字体、布局或随机生成），可一键导出 shadcn 配置代码。

小知识：shadcn 是基于 radix^[64] + tailwind^[65] 实现组件美化，而 tweakcn 又是 shadcn 的美化器。就像搭积木一样，蛮有趣的！

开源 Chat UI

如果对本地部署 AI Chat 感兴趣，或者想自己开发一个类似 ChatGPT 的应用，以下项目可供参考：

• Open WebUI^[66]：是一个可扩展、功能丰富且用户友好的自托管 AI 平台，旨在完全离线运行。它支持各种 LLM 运行器（例如 Ollama）和兼容 OpenAI API，并内置 RAG 推理引擎，使其成为强大的 AI 部署解决方案。
• Chat SDK^[67]：是一个免费的开源模板，使用 Next.js 和 AI SDK 构建，可帮助你快速构建强大的聊天机器人应用程序。
• LobeChat^[68]：现代化设计的开源 ChatGPT/LLMs 聊天应用与开发框架。支持语音合成、多模态、可扩展的（function call^[69]）插件系统，支持一键部署。
• Cherry Studio^[70]：是一款支持多个大语言模型（LLM）服务商的桌面客户端，兼容 Windows、Mac 和 Linux 系统。
• Text generation web UI^[71]：适用于大型语言模型的 Gradio Web UI。 其目标是成为文本生成领域的 AUTOMATIC1111/stable-diffusion-webui^[72]。
• ...

扩展阅读

从原始编程到 Vibe Coding，从提示词工程到上下文工程（深度理解：提示词工程），AI 正在颠覆行业的同时，也在不断达成新共识。比较巧合的是“氛围编程”这个概念最早也是 Andrej Karpathy 提出的（AI 进阶：从 Vibe coding 到职场必备），最近还分享了在 YC AI Startup School 的主题演讲 Software Is Changing (Again)^[73]。他结合自己在斯坦福、OpenAI 和特斯拉的经历，分析了软件发展的历史、现状与未来趋势。

📌 Vibe coding

Vibe coding（也称 vibecoding）是一种依赖大型语言模型（LLM）来生成软件的全新编程方式，由 Andrej Karpathy 于 2025 年 2 月提出，并被《韦氏词典》在次月收录为“俚语 & 热门”名词。其核心在于，开发者只需用自然语言向 LLM 提出需求或描述问题，即可让系统自动生成并修正代码。开发者更多地充当“提示提供者”和“测试者”的角色，而不是手动编写或阅读大量代码。在实践中，人们往往反复将需求或错误信息输入给 LLM，让它修复或改进代码，而不必深入理解技术细节。本质上，Vibe coding 让编程过程更偏向于“与 AI 协同对话”，甚至有时只需“看看、说说、跑一下、然后复制粘贴”，就能完成一个相对完整的项目或 Web 应用。

Software Is Changing (Again)

软件演进：三次范式变革

软件 1.0：指令式编程

Karpathy 指出，在过去 70 年里，软件的底层逻辑并未发生太大变化。我们编写代码，给计算机下达精确指令，这便是软件 1.0。这种范式构成了我们数字世界的基石，就像 GitHub 上无数代码仓库所展现的那样，那是人类智慧凝结成的数字指令。然而，近年来，软件世界迅速迎来了两次根本性的变革。

软件 2.0：数据驱动神经网络

几年前，Karpathy 观察到一种新型软件的兴起——神经网络。它不再是我们直接编写的指令代码，而是通过调整数据集，并运行优化器来自动生成神经网络的“权重”（weight）参数。这就像你不再亲手雕刻作品，而是通过调整土壤、温度等环境因素，让大自然的力量塑造出你想要的东西。当时，神经网络可能还被视为一种特殊的分类器，但 Karpathy 认为，将其视为一种新型软件的视角更为恰当。

如今，在软件 2.0 领域，已经出现了类似于 GitHub 的平台，比如 Hugging Face 和 Model Atlas^[74]，它们汇集了大量的神经网络模型，如同数字世界的基因库，供我们探索、利用。

软件 3.0：自然语言编程

而现在，我们正迎来更具颠覆性的软件 3.0 时代。如果说之前的神经网络是“固定功能”的计算机（例如图像识别器），那么大型语言模型（LLM）的出现，则让神经网络本身变得可编程！

Karpathy 将 LLM 视为一种全新的计算机，而我们的提示词（prompts），就是编程 LLM 的“程序”。更令人惊叹的是，这些程序竟然是用人类的自然语言，比如英语，来编写的。这意味着，曾经需要数年专业学习才能掌握的编程技能，如今通过日常语言就能实现。

这好比以前你需要学习复杂的机器语言来操控电脑，现在你只要用日常语言告诉它你想做什么，它就能理解并执行。例如，要进行情感分类，你可以编写 Python 代码（软件 1.0），训练一个神经网络（软件 2.0），或者，直接用几句话提示一个 LLM（软件 3.0）。这种变革不仅带来了新的编程范式，更将编程的门槛降至前所未有的低点。

多种编程范式共存

Karpathy 在特斯拉的经历也印证了这一趋势：自动驾驶系统从大量 C++ 代码（软件 1.0）逐渐转向由神经网络（软件 2.0）主导。现在，软件 3.0 正在重演这一过程，它将“吞噬”现有软件栈。掌握这三种编程范式，对未来行业从业者至关重要。

LLM 本质：数字世界的“操作系统”

Karpathy 将 LLM 比作多种概念，以阐释其特性：

• 新型“公用事业”：LLM 的训练和运营成本高昂，服务模式类似电力公司，按使用量收费。它们提供智能服务，我们对其有低延迟、高可用性等需求。当 LLM 宕机时，全球智能也随之“停摆”。
• 高科技“晶圆厂”（半导体）：训练 LLM 所需的巨额资本支出，使其也具备“晶圆厂”的某些特质。LLM 实验室正在形成深厚的技术积累和研发秘密。然而，软件的易变性使其不像物理晶圆厂那样难以复制，这使得竞争格局更加复杂。
• 数字“操作系统”：这是最贴切的比喻。LLM 是复杂的软件生态系统，而非简单商品。
• 生态系统与竞争格局： 就像 Windows 和 macOS 等闭源操作系统与 Linux 这样的开源替代品并存一样，LLM 领域也出现了少数闭源提供商（如 OpenAI）和像 Llama 生态系统这样的开源替代者。
• 资源调度与内存管理： LLM 可以被视为新的 CPU，其上下文窗口（context window）就像内存。LLM 负责协调记忆和计算，解决问题，这与操作系统的功能高度相似。
• 应用分发： 就像我们可以在 Windows、Linux 或 Mac 上运行 VS Code 一样，基于 LLM 的应用（如 Cursor）也可以在不同的 LLM（如 GPT、Claude 或 Gemini）上运行。
• 1960 年代的计算： 当前 LLM 的计算成本高昂，导致它们集中在云端，用户通过网络作为“瘦客户端”与其交互，这与 1960 年代大型机时代的分时共享计算模式惊人相似。个人计算的革命尚未到来，但诸如 Mac mini 等设备对某些 LLM 的适配性，预示着未来个人 LLM 计算的可能性。
• 终端与 GUI： 直接与 LLM 通过文本交流，就像通过终端与操作系统对话。目前还没有通用的图形用户界面（GUI）来与 LLM 进行更直观的交互，但一些 LLM 应用正在探索这种可能性。

独特的“技术扩散”方向

与以往新技术（如电力、互联网）通常先由政府和企业采用，再逐步扩散到消费者不同，LLM 的技术扩散方向似乎是颠倒的。它首先在普通消费者中迅速普及，帮助人们解决诸如“如何煮鸡蛋”这类日常问题，而不是最初服务于军事或大型企业。这种反向扩散可能预示着 LLM 在应用层面的独特发展路径。

理解 LLM “心智”：超能力与认知缺陷并存

在利用 LLM 之前，我们必须理解它们的本质。Karpathy 将 LLM 比作“人类灵魂的随机模拟器”，它们通过自回归 Transformer 模型，从海量互联网文本数据中学习，因此呈现出类似人类的“涌现心理”。

• 超能力： LLM 拥有百科全书般的知识和记忆，远超任何个体人类，就像电影《雨人》中的自闭症天才，能轻松记住海量信息。
• 认知缺陷：
• 幻觉（Hallucination）： LLM 会凭空捏造信息，对自身的知识边界缺乏清晰认知。尽管有所改善，但尚未完美。
• 锯齿状智能（Jagged Intelligence）： 它们在某些问题解决领域表现超人，但在一些简单问题上却会犯低级错误（例如坚持 9.11 大于 9.9，或 “strawberry” 有两个 “r”）。
• 顺行性遗忘（Anterograde Amnesia）： LLM 无法像人类一样通过睡眠等方式巩固知识并随着时间积累经验。它们的上下文窗口更像是工作记忆，需要我们直接编程来维持。这就像电影《记忆碎片》和《初恋 50 次》中的主角，每天早上记忆都会被清零。
• 安全漏洞： LLM 容易受到提示注入（prompt injection）攻击，并可能泄露数据。

因此，与 LLM 协作，我们需要同时兼顾它们的超能力和认知缺陷，学会如何扬长避短。

LLM 应用：从辅助到自治

像 Cursor 这样的代码编辑器是 LLM 应用的典范。它保留了传统的手动界面，同时深度集成 LLM，让人类以更大的粒度进行操作。这类 LLM 应用通常具备以下特性：

• 上下文管理： LLM 自动处理大量的上下文信息。
• 多模型协调： LLM 在底层协调多个模型（如嵌入模型、聊天模型、代码差异应用模型）。
• 应用特定 GUI： 文本并非审计 LLM 工作的最佳方式。图形界面（GUI）能够更直观地展示信息（如代码的红绿差异），并允许用户通过简单的操作（如快捷键）进行接受或拒绝，大大提升了人机协作的效率。
• 自治滑块（Autonomy Slider）： 用户可以根据任务的复杂性，调整 LLM 的自治程度，从简单的代码补全，到修改整个文件，乃至让 LLM 在整个代码仓库中自主行动。

像 Perplexity 这样的问答应用也具备类似特性：信息整合、多 LLM 协调、可审计的 GUI（引用来源）、以及可调节的自治级别（快速搜索、研究、深度研究）。

Karpathy 大胆预测，未来的软件产品和服务都将变得部分自治。这需要我们思考：LLM 能否像人类一样感知和行动？人类又如何能有效地监督和介入？以及如何设计能被 LLM 理解的软件界面和交互方式？

人机协作：加速“生成-验证”循环

在人机协作中，AI 负责“生成”，人类负责“验证”。提升效率的关键在于：

例如，在与 LLM 协作编码时，Karpathy 倾向于让 AI 每次只处理一小段具体的代码，确保每次修改都经过仔细验证。模糊的提示词会导致 AI 偏离目标，增加验证成本，因此，提供具体、清晰的提示词，能有效提升协作效率。

为“代理”而设计：新的数字信息消费者

目前，大量的数字信息（如网站、文档）是为人类 GUI 或计算机 API 设计的。但现在，我们有了新的数字信息消费者和操控者 —— AI 代理（agents）。它们是具有“人类灵魂”的计算机，需要我们为其重新构建软件基础设施。

尽管 LLM 未来可能会自主点击和浏览网页，但主动为它们提供更友好的访问方式仍然至关重要，这不仅能降低成本，还能提高效率。

“全民编程”的时代

“Vibe Coding” 这个词的意外爆红，恰好抓住了当前时代的一种普遍感受——每个人都可以成为程序员。当孩子们用自然语言与 AI 互动，创造出简单的应用时，这无疑是一种“编程入门药”，预示着编程民主化的未来。

Karpathy 也尝试了 “Vibe Coding”，仅仅通过与 LLM 对话，就用 Swift 语言构建了一个简单的 iOS 应用，这在以前是不可想象的。他甚至用这种方式开发了一个名为 “Menu Genen” 的餐馆菜单图片生成应用。尽管实际部署的繁琐（认证、支付、域名部署等）消耗了更多时间，但 “Vibe Coding” 的核心 —— 通过对话生成代码，确实大大降低了开发的门槛。

回顾自动驾驶的发展历程，从 2013 年的完美演示到如今仍未完全实现的自主驾驶，Karpathy 告诫我们，软件开发，尤其是涉及自治系统的开发，是一个漫长而复杂的过程。他认为，我们正处于“代理的十年”，而非“代理之年”。我们需要保持耐心，让人类始终参与其中，谨慎前行。

最终，Karpathy 用“钢铁侠战衣”的类比来总结：我们应该构建的，不是完全自主的“钢铁侠机器人”，而是能增强人类能力的“钢铁侠战衣”。这些“战衣”是具有定制 GUI 和 UI/UX 的部分自治产品，它们能大大加速人类的“生成-验证”循环，同时保留“自治滑块”，允许我们随着技术成熟逐步提升自治程度。

“这是一个令人惊叹的时代！” Karpathy 总结道，“大量的代码需要被重写，专业程序员和 ‘Vibe Coder’ 都将参与其中。LLM 是像操作系统一样的存在，我们正处于 1960 年代的操作系统发展初期。它们是‘有缺陷的人类灵魂’，我们需要学会与它们协作，调整我们的基础设施，并构建能快速进行‘生成-验证’循环的部分自治产品。同时，我们也需要为代理们更直接地编写代码。”

未来十年，我们将亲眼见证软件自治的程度从左向右滑动，而我们，正是这场伟大变革的参与者和建设者。

上下文工程

我非常喜欢用“上下文工程（context engineering）”这个术语来取代“提示词工程（prompt engineering）”。相比之下，它更准确地描述了核心技能的本质：为任务提供足够且恰当的上下文，使大语言模型（LLM）能够合理地完成任务。这不仅仅是写一两句提示词那么简单，而是一门融合了工程方法与直觉艺术的复杂实践。

在日常使用中，人们常将 prompt 理解为简短的任务描述，但在任何工业级的 LLM 应用中，真正关键的是上下文工程。这是一项精细的工作，其本质在于把“刚刚好”的信息填入模型的上下文窗口，为下一步推理提供最优条件。之所以说它是一门科学，是因为做好这件事通常涉及任务说明、few-shot 示例、RAG（检索增强生成）、相关数据（可能是多模态的）、工具使用、状态记录、历史追踪、上下文压缩等多个维度。提供的信息太少、太杂或形式不当，模型将无法展现最佳性能；反之，填充过多或无关信息，则会导致性能下降和推理成本上升。因此，设计合理的上下文不是一件容易的事。

与此同时，上下文工程也是一门艺术。这种艺术性体现在对语言模型“心理机制”的直觉理解与经验积累上，掌握这种直觉，往往是打造出高质量 LLM 应用的关键。

当然，上下文工程只是构建完整 LLM 应用中的一个部分。除此之外，系统还需负责任务分解与控制流设计、上下文窗口的动态封装、调用不同类型和能力的 LLM、设计生成-验证交互流程，以及构建安全机制、评估系统、并行执行与预取机制等一整套复杂的协调逻辑。这些都构成了一个厚重且不容忽视的软件层，它协调着每次模型调用，并使得整个系统可靠运行。因此，“ChatGPT 包装器（wrapper）”这种说法早已过时，甚至是完全错误的，它无法体现当前 LLM 应用背后的系统复杂性与工程价值。

结语

AI 的演进正日益深入，超越了最初的纯对话模式，开始与应用程序乃至操作系统深度融合。这种趋势的核心目标是赋予 AI 更大的操作权限，使其能够执行更复杂、更自动化的任务。

对于普通用户而言，日常需求如信息查询、内容创作等，通过对话式 AI 或 AI 浏览器（如 Dia）即可轻松满足。然而，当需要处理更加复杂的任务时，集成 AI 功能的集成开发环境（IDE）或支持任务编排的工作流将成为更高效、更强大的选择。

对于开发者来说，理解并驾驭 AI、图形用户界面（GUI）和操作系统三者之间的关系变得至关重要。未来软件开发的重心，将不仅仅在于编写代码，更在于如何巧妙地编排这些元素，构建出能与 AI 无缝协作、高效执行复杂任务的智能应用。这标志着计算范式的一次深刻转变，需要开发者重新思考人机交互的本质以及软件的构建方式。

最近还看到一个有趣的笔记应用演示，它可以通过“笔记”内容为自身生成新功能，这或许也是未来 AI 应用发展的新方向：通过与应用对话来拓展自身功能。

References