🧠 卡帕西视角：提示词工程已死，上下文工程才是未来
从“写好Prompt”到“设计系统”，LLM应用的范式转移
如果你还在花大量时间雕琢提示词——尝试不同的措辞、调整Few-shot的数量、纠结于用“请”还是用“必须”——那么我要告诉你一个可能不太舒服的事实：这条路正在走向尽头。
我是Andrej Karpathy。作为曾经在OpenAI见证GPT诞生、在特斯拉带着AI解决自动驾驶问题、如今又创办Eureka Labs亲自投入AI教育的人，我越来越清晰地看到：Prompt工程是软件2.5时代的产物，而软件3.0需要的是上下文工程和Agentic Engineering。
这篇文章不是要否定吴恩达老师的工作——他的原则依然有效，但就像马车夫的技巧在汽车时代仍有部分可借鉴一样——我们已经站在了新的范式门口。
📌 目录
- 软件的三次范式转移
- 为什么“提示词工程”正在过时
- 上下文工程：新的杠杆点
- Agentic Engineering：从调用到编排
- 我的三层AI编程武器库
- 智能体的十年，而不是智能体之年
- 对开发者的行动建议
1. 软件的三次范式转移
整个软件开发史，可以粗暴地划分为三个阶段：
软件1.0：人类写代码
你用C++、Python、Java一条条写下if-else、for循环、函数调用。编译器或解释器忠实地执行。你告诉机器每一步怎么做。 这统治了大概60年。
软件2.0：人类提供数据，机器学习权重
你用TensorFlow或PyTorch搭建一个神经网络架构，然后喂给它成千上万个标注样本。模型自己学习参数。你不再写“如何识别猫”，而是写“让模型自己学如何识别猫”。你提供目标，机器探索路径。 这是过去十年。
软件3.0：自然语言作为编程接口
现在，你可以对模型说：“写一个函数，输入用户名列表，输出按字母排序后的字符串，首字母大写。” 模型直接生成代码、运行、甚至帮你调试。你说目标，模型自己决定怎么做。 这就是我们现在进入的范式。
在这个新范式下，代码的单位不再是“行”，而是“宏观动作”。一个Prompt可能替代几百行样板代码。而更关键的是，你可以把完整的任务交给Agent： “重构这个模块，并补充单元测试。”
但你注意到问题了吗？Prompt本身正在贬值。 因为模型的推理能力越来越强，你不需要再手把手教它每一步。你只需要给它足够的上下文，它自己就会推导出正确的路径。
2. 为什么“提示词工程”正在过时
吴恩达老师在课程中强调的那些技巧——用分隔符标出文本、要求JSON输出、提供Few-shot示例——在GPT-3.5时代是金科玉律。但在GPT-4、Claude 3.5乃至更新模型的测试中，很多所谓“最佳实践”的效果已经显著衰减。
为什么？
因为模型在训练过程中已经内化了推理能力。RLVR（基于可验证奖励的强化学习）正在取代RLHF成为新的训练范式：模型的奖励信号不再是“人觉得这个回答好不好”，而是“这个代码能不能跑通”、“这个JSON是否符合格式”、“这个数学题的答案是否正确”。
别听人的，听结果的。 编译器说了算，测试套件说了算。
这意味着：当你给模型一个复杂任务时，它不再需要你拆解成10个步骤。它可以自己规划、自己试错、自己修正。你给的步骤越多，反而可能限制了它的探索空间。
一个真实的对比
| 任务 | GPT-3.5时代的Prompt | GPT-4时代的Prompt |
|---|---|---|
| 从文本中提取日期 | “请找到所有日期，格式为YYYY-MM-DD，输出JSON数组…” | “提取所有日期。”（模型自动推断格式） |
| 情感分析 | 提供5个示例 + 标签定义 | “判断情感。”（模型已内化） |
| 代码生成 | 详细描述函数签名、边界条件、异常处理 | “写一个函数，实现XX功能。”（模型自己会考虑边界） |
当然，这并不意味着你可以随便写一句“帮我做个网站”。上下文的质量仍然决定一切，但“上下文”的内涵已经远远超出了“提示词”。
3. 上下文工程：新的杠杆点
我在2026年的一次演讲中提出过一个观点：提示词工程已死，上下文工程崛起。
什么是上下文工程？它不是“怎么写好一个Prompt”，而是如何为LLM构建一个高信息密度、低噪音、可检索、可更新的上下文环境。
上下文窗口现在可以容纳几十万甚至上百万token。这是巨大的杠杆——你可以把整个代码库、一整本书、一整年的聊天记录塞进去。但问题也随之而来：如何填充这个窗口才最有效？
上下文工程的五层架构
| 层级 | 内容 | 说明 |
|---|---|---|
| 系统指令 | 角色、边界、输出格式 | 最稳定的控制层 |
| 任务描述 | 当前要做什么 | 一句话概括，不要啰嗦 |
| Few-shot / 示例 | 2-5个范例 | 帮助模型理解“风格”而非“逻辑” |
| RAG检索结果 | 从知识库中召回的相关片段 | 动态注入，解决长尾知识 |
| 对话/工具历史 | 之前的交互、工具调用结果 | 维持状态，实现多步推理 |
关键洞察：你不再需要把每个细节都写进提示词。比如，模型需要知道公司的API文档，你不应该把它写死在Prompt里，而应该在运行时通过RAG（检索增强生成）动态拉取相关片段。这样可以避免上下文过载，也能保证信息更新。
上下文工程的典型代码结构
# 伪代码示意
def build_context(user_query, user_id):
context = []
# 1. 系统指令：固定
context.append({"role": "system", "content": SYSTEM_PROMPT})
# 2. 任务描述：简单重述
context.append({"role": "user", "content": f"任务：{user_query}"})
# 3. RAG：从用户的知识库中检索
docs = retrieve_similar_docs(user_query, user_id, top_k=5)
context.append({"role": "system", "content": f"相关资料：\n{docs}"})
# 4. 历史对话：最近10轮
history = get_conversation_history(user_id, limit=10)
context.extend(history)
return context
所以，别再纠结于“该不该在Prompt里加‘请’字”了。真正重要的是：哪些信息应该进入上下文？如何排序？如何压缩？如何更新？
4. Agentic Engineering：从调用到编排
如果说上下文工程是“喂好数据”，那么Agentic Engineering就是“让模型自己干活”。
一个Agent不只做一次LLM调用，而是循环执行：思考 → 调用工具 → 观察结果 → 再思考 → 完成。它可以读文件、写代码、跑测试、上网搜索、调用API。
我经常把Agent比作一个实习生：你给他一个大任务，他不会一次就做完美，但你能看到他一步步的思考过程，他会在不确定时停下来问你，他会从错误中学习。
Agent的四步循环
+-----------------+
| 1. 规划(Plan) | ← 将大任务拆解成子任务
+--------+--------+
↓
+-----------------+
| 2. 调用工具(Call)| ← 执行代码、搜索、读文件
+--------+--------+
↓
+-----------------+
| 3. 观察(Observe)| ← 收集工具返回的结果
+--------+--------+
↓
+-----------------+
| 4. 反思(Reflect)| ← 判断是否完成，若无则返回步骤1
+-----------------+
一个成熟的Agent框架（比如我参与过的AutoGPT、LangChain等）就是在代码层面实现这个循环，并处理好长期记忆和任务中断恢复等工程问题。
Agent vs 非Agent的对比
| 维度 | 普通API调用 | Agent |
|---|---|---|
| 单次vs多步 | 单次调用，一步到位 | 多步循环，逐步逼近 |
| 工具使用 | 无，或预先指定 | 动态选择，按需调用 |
| 错误恢复 | 失败即停止 | 可重试、换方案 |
| 适用任务 | 翻译、摘要、分类 | 编程、研究、自动化运营 |
但请注意：Agent不是魔法。今天的Agent还很笨，它们会陷入死循环、会忘记之前的决定、会调用不必要的工具。所以……
5. 我的三层AI编程武器库
既然聊到Agent，我分享一下我现在是怎么用AI编程的。不是理论，是每日实战。
第一层：Cursor的Tab补全（75%的代码）
日常写代码时，Cursor的自动补全能预测我要写的下一行。它不聪明，但反应快、准确率高。这相当于智能版IDE补全。
第二层：Claude Code / Codex（20%的代码）
当需要写一个完整函数、一个模块、或者重构一段逻辑时，我会切换到Claude Code或GitHub Copilot Chat。给它足够的上下文（相关文件和函数签名），它能在几秒内生成靠谱的实现。我会review一下，可能改几行，然后提交。这部分替代了我曾经的“查Stack Overflow”和“写样板代码”时间。
第三层：GPT-5 Pro / 最新模型（5%的代码）
只有遇到顽固bug、复杂的算法设计、或者跨多个文件的重构时，我才会用最顶级的模型（比如GPT-5 Pro或Claude Opus）。它贵、速度慢，但推理能力最强。我会把整个项目的关键文件都塞进上下文，然后问：“为什么这个并发测试偶尔会死锁？” 它有时能找出我都没注意到的竞态条件。
四条铁律
我给自己定了四条规则，你也可以参考：
- Think Before Coding：让AI写代码之前，先想清楚你要什么。模糊的要求只会得到垃圾。
- Simplicity First：不要一上来就让AI写一个庞大架构。先从最简单的版本开始，再迭代。
- Surgical Changes：一次只改一个地方。让AI生成diff而不是整个文件。
- Goal-Driven Execution：告诉AI“目标是什么”，而不是“每一步怎么做”。让它自己规划路径。
最后这条，其实就是从Prompt Engineering到Goal Engineering。
6. 智能体的十年，而不是智能体之年
媒体喜欢说“今年是Agent元年”。但每次有人问我“Agent什么时候才能真正成熟？”，我的回答都让他们失望：
智能体的十年，而不是智能体之年。
为什么？因为今天的Agent还有三个致命短板：
① 无法持续学习
一个Agent执行完任务后，你不会看到它的“能力”变强。它没有长期记忆，没有在线学习机制。下次遇到类似任务，它还是从零开始。
② 缺乏可靠的长期记忆
上下文窗口再大，也塞不下一整年的交互历史。我们需要的是外部向量数据库 + 高效检索 + 自动总结。这个组合今天还远未成熟。
③ 没有真正的“认知结构”
人类做事有目标层次、有优先级、有中断恢复机制。Agent只是基于当前上下文的next-token预测，它没有“我想完成这个任务”的内在驱动。它只是在模仿完成任务的文本模式。
要突破这些，需要的是架构创新，而不仅仅是更大的模型或更多的数据。乐观估计，这需要五年到十年。
7. 对开发者的行动建议
如果你现在就想让自己的AI应用更可靠、更强大，以下是我最直接的建议：
① 升级你的认知
从“我写代码”切换到“我描述目标”。每次接到一个新功能，先问自己：如果我把这个任务完整地丢给一个高级实习生，他会怎么理解？我需要补充什么信息？ 然后把这些信息组织成上下文，而不是写成一堆if-else。
② 建立你的“AI编程武器库”
不要迷信任何一个工具。Cursor、Copilot、Codex、Claude、GPT-4/5——每个都有自己的优势和适用场景。学会在不同粒度上切换：Tab补全用快的，大块任务用中等的，最难bug用最强的。
③ 验收先行：先定义“什么算对”
无论你是写Prompt还是编排Agent，在让模型干活之前，先想清楚如何验证输出。代码能不能通过已有测试？JSON是否符合schema？答案是否能在文档中找到引用？有了自动化的验收信号，AI的可靠性会提升一个数量级。
④ 开始构建“第二大脑”
不要只依赖上下文窗口。用RAG把公司的知识库、你的笔记、历史对话都索引起来。让AI能够“记住”以前讨论过的内容。你的目标是让AI从“临时工”变成“长期员工”。
写在最后
吴恩达老师的Prompt工程原则，在GPT-3.5时代是通往可靠LLM应用的金钥匙。我也曾反复练习那些技巧。但现在，模型进化得太快了。
我们正在进入一个更令人兴奋、也更挑战认知的新阶段。在这个阶段，AI不再是一个需要你手把手教的笨孩子，而是一个有点灵性、但也有点不可预测的数字同事。
你的任务不再是“写好提示词”，而是设计好上下文、编排好Agent、定义好验收标准。你要从程序员变成指挥家、变成教练、变成系统架构师。
这不是提示词的末日，而是提示词超越自身的开始。
关于AI，我最喜欢的一个比喻来自我自己的反思：AI不是一种新的动物，而是一个“幽灵”——锯齿状的、统计性的、被召唤出来的能力集合。驾驭它需要全新的品味和判断力。而这，才是我们这个时代真正的工程挑战。
如果你已经在实践上下文工程或Agent编排，欢迎在评论区分享你的故事。我们一起，在软件3.0的浪潮里，把不可靠的智能，变成可靠的生产力。
本文核心观点源自Andrej Karpathy在YC AI Startup School（2025）、红杉AI大会（2026）及个人博客/推文的公开分享。由AI辅助整理成文。
