AI时代的名词焦虑

层出不穷的新术语，构成了 AI 时代的主要焦虑。

先按时间顺序列举一下。

2015 年，Karpathy 的《循环神经网络的惊人有效性》一文将生成式人工智能的概念推向大众视野。

2017 年，软件 2.0（Software 2.0）概念出现，模型权重本身被视为“程序”。

2022 年底到 2023 年，ChatGPT 将提示词工程（Prompt Engineering）推上风口，甚至出现了“最火的编程语言是英语”的说法。

到了 2025 年，新词继续涌现。首先是上下文工程（Context Engineering），接着是氛围编程（Vibe Coding），然后是更工程化的智能体工程（Agentic Engineering）。

再往后到 2026 年，又出现了软件 3.0（Software 3.0）、约束工程（Harness Engineering）、模型上下文协议（MCP）、智能体通信协议（ACP）、技能（Skill）等新词汇。

这几年来，行业几乎每隔一段时间都会换一组关键词来描述“人与人工智能如何协作”。

这些新概念，很多时候只是一种过渡性的包装。

先说软件 2.0。

这是 Karpathy 在 2017 年提出的一个概念。意思是，程序不再仅限于人手写的代码，神经网络的权重本身也可以被视为程序。

提示词工程（Prompt Engineering），重点在于如何准确地表达一句话，使模型在单轮对话中给出更接近目标的回答。

上下文工程（Context Engineering），则是将重点从“这句话怎么写”前移一步，更关注提供给模型的背景资料、项目上下文和边界条件。

氛围编程（Vibe Coding），是 Karpathy 在 2025 年提出的概念。意思不是严谨开发，而是快速试错，先把东西跑出来再说。

智能体工程（Agentic Engineering），可以理解为氛围编程的工程化版本。重点不仅是生成内容，还包括让模型自行调用工具、运行、测试和修复，而人类主要负责监督和把关。

软件 3.0（Software 3.0），则是在软件 2.0 之后更进一步的说法。它强调自然语言正在成为新的入口，人类描述意图，系统自动拼接代码、模型调用和自动流程。

约束工程（Harness Engineering），是 OpenAI 近期强调的一个词。重点不再是打磨提示词，而是搭建文档、目录、测试、规则和反馈回路等环境，使智能体更稳定地工作。

模型上下文协议（MCP），可以理解为模型连接工具和数据的标准接口。

智能体通信协议（ACP），可以理解为智能体之间协作的标准接口。

技能（Skill），可以理解为将常见任务打包成可复用的能力包，通常包含说明、资源，有时还会带脚本。

把这些术语放在一起看，会发现它们虽然名字不同，但大多都在回答同一个问题：如何将模型从一个只会聊天的东西变成一个能稳定工作的系统。

解释这些术语并不难。

更重要的是，它们背后到底在解决什么问题。

第一，如何清晰地表达需求。

第二，如何提供完整的上下文。

第三，如何减少系统出错。

第四，如何让不同模块稳定协作。

第五，如何将能力拆分，使其可复用、可验证、可维护。

这些问题本来就是软件工程、工具工程和测试工程一直在处理的事情。

只是随着模型的引入，行业给它们换了一套更新的名字。

这更像是对一些原本就不错的工程实践进行重新命名和重新包装。

问题在于，新名词的传播速度常常超过人们的理解速度。

有些词听起来很新，讲的其实还是工程常识。

有些词的边界并不清楚，不同人使用同一个词，心里想的却不是同一件事。

在人工智能世界里，更稀缺的能力可能是看清这些术语到底在解决什么老问题，而不是会说更多的术语。

信息一多，人们不一定会停下来思考。

更常见的情况是，事情做了不少，但方向一直在变。

是继续纠结提示词工程（Prompt Engineering）这种已经过时的话题，还是先把自己的工作流理顺？

是继续手工堆上下文工程（Context Engineering），还是先把现有场景跑通、把验证机制补齐？

是先上智能体（Agent），还是先把测试、文档、知识库这些基础补齐？

很多团队的状态就是这样。

今天讨论要不要全面上智能体（Agent），明天讨论要不要先做检索增强生成（RAG），后天又被一个全自动演示带偏方向。

Claude Code 的最佳实践中提到，如果上下文跑偏了就尽快纠正；如果同一个问题反复纠正几次，不如清掉上下文重新开始。

OpenAI 在讲约束工程（Harness Engineering）时也提到，给智能体的最好是一张地图，而不是一大堆堆在一起的说明书。

这些建议其实都在指向同一件事：先确认当前问题是什么，再决定下一步做什么。

信息过载带来的麻烦，往往不是没有动作，而是动作很多，方向却一直在晃。

当下最热的词之一，其实是技能（Skill）。

它的吸引力很直接：将经验写进 SKILL.md 或一套流程里，智能体（Agent）就能反复调用，不用每次从零解释。

但 Skill 系统的问题也很直接。

太泛的 Skill，最后只是一段更长的提示词，听起来正确，实际帮助不大。

太具体的 Skill，又会被项目结构、工具版本、团队习惯绑死，环境一变就失效。

更大的问题是，它很容易制造一种错觉：好像流程被打包了，能力也就跟着到手了。

但实际上，流程可以复用，判断力、调试能力和边界意识并不会一起被安装进去。

这也是为什么 Skill 这个词越热，越需要回到一个更基本的判断：人工智能能提升效率，但不能代替你理解问题。

它可以帮你更快生成、更快整理、更快调用，但你为什么这样做、这样做对不对、出了错怎么追，最后还是自己的功课。

所以真正该问的不是“有没有 Skill”，而是这个 Skill 对应哪个具体约束，出了错能不能追，换个环境还能不能用。

Skill 系统最有价值的地方，是帮人复用流程；它最容易制造的错觉，是让人以为流程复用等于能力到手。

你最近最看不懂、但又总被人反复提起的人工智能术语是什么？

评论区聊聊，我想看看大家现在最真实的困惑到底卡在哪。