首页 › trending › 提示词工程师已死?海外吵翻一整年

提示词工程师已死?海外吵翻一整年

导语:你还在背模板,人家已经吵完一轮了

先说一个扎心的观察:国内技术社区还在热传「提示词工程师月薪3万」「20个万能Prompt模板」的时候,海外AI圈已经为「prompt engineering是不是该进坟墓」整整吵了一年多。这场论战的级别不低——Andrej Karpathy亲自下场换了词,Shopify CEO在内部备忘录里跟进,Anthropic官方工程博客直接写了篇方法论文章定调,连「长上下文吊打一切」的营销话术都被一份实测报告打脸。

信息差在哪?在于这场论战吵完之后,海外一线团队沉淀出一套「上下文工程(context engineering)」的实操共识——它不是换了个新词继续卖课,而是一套实打实影响模型效果和账单金额的系统工程方法。今天这篇文章,帮你把这场论战的来龙去脉、三派立场、可抄的作业一次讲清。

一、论战是怎么点着的:从33万美元年薪到「这个词有点羞耻」

把时间拨回2023年初。ChatGPT刚爆火,Anthropic挂出一份招聘:Prompt Engineer and Librarian,年薪25万到37.5万美元,媒体标题清一色写着「最高33.5万美元年薪、不需要写代码」。一时间,提示词工程成了AI时代的翻译官职业,国内各种「提示词认证课」也跟着收割了一波。

转折发生在两年后。2025年年中,前特斯拉AI总监、OpenAI创始成员Karpathy在X上明确表态:比起prompt engineering,他更愿意叫它context engineering。他的理由很尖锐——「prompt」这个词暗示的是一种一次性、静态、精确描述的咒语,但实际上给Agent准备输入是一件动态得多的事:每一轮循环都要重新组装上下文,包括系统指令、工具定义、检索来的文档、记忆文件、历史消息裁剪……这更像「为模型写一份随时在变的简报」,而不是「念一句咒语」。这个词并非他首创,但由他带火之后,一周之内成了行业热词。

紧接着,Shopify CEO Tobi Lütke一份内部备忘录流出(就是那份要求「全员把AI使用当作baseline」的著名备忘录),里面同样把上下文工程列为基本功。Simon Willison(Django联合创始人、现在AI圈最有影响力的独立博主之一)也发文支持:这个词比prompt engineering更准确,因为它点出了真正的稀缺资源——模型的注意力。

最后压秤的是Anthropic自己。2025年9月末,Anthropic工程博客发了那篇《Effective context engineering for AI agents》,等于官方盖章:提示词调优只是小事,上下文才是有限资源,要像管理内存和CPU预算一样管理它。一家靠卖模型赚钱的公司亲自下场教你怎么省着用上下文,这个信号本身就值得琢磨。

二、分战场一:是新学问,还是新瓶装旧酒?

论战第一回合是纯粹的嘴仗,海外社区大致分成三派:

正名派(Karpathy、Willison、Anthropic为代表):这不是文字游戏。提示词工程解决的是「怎么说」,上下文工程解决的是「给模型看什么、不给它看什么、什么时机给」。前者是话术,后者是架构。

换牌派(HN和Reddit上的主流嘲讽声音):翻翻Hacker News的评论区,高赞冷嘲热讽一抓一把——「这不就是我们干了二十年的需求分析和信息检索吗」「AI行业每六个月就要发明一个新词,好让咨询顾问有东西可卖」。这派人的核心论点:RAG、记忆管理、工具编排,哪个都是老东西,套个新壳而已。

实践派(一线开发团队):吵什么名字无所谓,但这波讨论逼大家把散落的经验系统化了——以前各干各的trick,现在有了一张统一的checklist,能对照着优化自己的Agent。

我的看法:换牌派说对了一半。概念确实不新,但「统一术语」在工程界从来不是小事——有了共同语言,最佳实践才能被写成文档、搬进面试题、做成工具的默认配置。Anthropic那篇博客就是明证。

三派立场用一张图看更清楚:

flowchart TD
    A["术语论战<br/>三派立场"] --> B["正名派<br/>上下文是稀缺资源"]
    A --> C["换牌派<br/>新瓶装旧酒"]
    A --> D["实践派<br/>要吵你们吵<br/>我先抄checklist"]
    B --> E["代表<br/>Karpathy等"]
    C --> F["阵地<br/>HN评论区"]
    D --> G["产出<br/>统一方法论"]

三、分战场二:上下文堆得越多,模型越笨?

如果说出造新词只是热身,那真正刺刀见红的是第二场:长上下文到底靠不靠谱。

这两年模型厂商发布会都在卷一个数字——上下文窗口。100万token起步,200万不稀奇,营销叙事很简单:窗口越大,模型「记忆力」越好,RAG都不用搭了,把整个代码库塞进去就完事。

2025年7月,向量数据库公司Chroma发布了一份实测报告《Context Rot》(上下文腐烂),给这股风潮泼了盆冷水。他们测了18个模型,用几组「大海捞针」的变体任务反复实验,结论很不给面子:

  1. 所有模型都存在性能随上下文增长而衰减的现象,连以长上下文著称的旗舰模型也不例外;
  2. 衰减是非均匀的——不是线性变笨,而是中间某段信息特别容易「失焦」,开头和结尾的内容回忆得明显更好;
  3. 任务越复杂、文档结构越「乱」(比如重复词多、问答分散),腐烂得越快。窗口大小是理论容量,不是实际可用内存。

这份报告在社区炸出一堆「我说怎么不对劲」的跟帖。有人翻出自己的翻车案例:塞了整本文档让模型总结,它偏偏漏掉中间那章;给Agent喂了五十条工具返回结果,它把前面30条的事实记串了。当然也有反驳声音:一些工程师认为测试任务设计偏刁钻,真实场景不至于这么惨;厂商阵营则基本沉默。

对这派论战,我的判断是:窗口虚标和实际可用性之间的落差是真实存在的,这跟你买了1TB硬盘发现系统盘只剩一半能用的道理类似。衰减幅度可以争论,「堆得越多越聪明」这个营销叙事被打折是确定的。这也解释了为什么Anthropic的方法论里,第一条原则就是把上下文当预算花,而不是当大海捞。

四、分战场三:上下文谁来管?人管还是模型自己管?

前两场是嘴仗和实证仗,第三场直接影响你每天的工具使用体验:上下文管理的活儿,到底谁干?

方案A:人工显式工程。 这派的打法就是Anthropic那篇博客的干货,核心三招:

方案B:模型自动管理。 这派认为人会累会偷懒,压缩和裁剪应该由模型或框架自动完成。各家IDE工具和Agent框架都在往这个方向卷,记忆类基础设施(向量库+记忆层)这条赛道去年融资不断。

分歧点在于:自动压缩可能在关键细节上「手抖」——压掉的那句话恰好是下一轮要用的约束条件,这种事故在社区里抱怨不少。目前海外的实操共识比较务实:关键决策和约束一定要人肉落到文件里,别指望模型自动记住。

用一张图把这套工程拼图串起来:

flowchart TD
    A["上下文工程<br/>四大件"] --> B["稳定前缀<br/>系统提示词"]
    A --> C["按需检索<br/>用完即弃"]
    A --> D["笔记外置<br/>NOTES.md"]
    A --> E["会话压缩<br/>compaction"]
    B --> F["前缀稳定<br/>缓存才命中"]
    C --> G["工具结果<br/>裁剪后再喂"]
    D --> H["关键约束<br/>人肉落盘"]
    E --> I["长会话<br/>摘要后开新局"]

五、钱的角度:这套玩意直接砍账单

别以为这是纯理论撕逼,上下文工程是少数能直接从账单上看出来的论战。两个硬数字:

  1. Prompt caching(提示词缓存):把system prompt、工具定义这类稳定内容放在上下文最前面,命中缓存后的读取费用最低可到原价的十分之一——省90%。但前提是你的前缀真的稳定:很多人把时间戳、随机ID写进系统提示词开头,缓存永远 miss,等于白白多付九倍的钱。这是最典型也最隐蔽的「认知差」;
  2. 上下文长度即成本:每个token都要收费,把一万字的文档整段塞进去问一句话,大部分token的钱是白花的。检索后裁剪、只喂相关段落,效果不降反升(还记得context rot吗——塞得少反而答得准)。

海外一线团队现在流行一句话:上下文工程做得好,模型可以降一档用。原来要旗舰模型才能稳住的任务,把上下文收拾干净后中档模型就够了,费用直接腰斩再腰斩。

六、信息差总结

维度 你以为的(国内主流叙事) 海外吵完的共识
提示词工程 高薪新职业,模板是核心资产 话术层,正被上下文工程吞并
上下文窗口 越大越好,塞满就赢 理论容量≠可用内存,堆多了会「腐烂」
长会话管理 模型自己会记 关键约束必须人肉外置到文件
记忆方案 上了向量库就万事大吉 文件+结构化笔记是性价比之王
账单优化 换便宜模型 上下文收拾干净,便宜模型也能打
职业方向 背模板、刷提示词比赛 系统工程能力:检索+缓存+压缩+编排

七、行动指南:这周末就能干的事

  1. 读原文:Anthropic那篇《Effective context engineering for AI agents》半小时能读完,是目前最好的单篇入门(来源列表第1条);
  2. 查你的缓存命中率:如果你在调API,检查system prompt里是否混入了时间戳、会话ID等易变内容——把它们挪到消息末尾,稳定前缀放最前,账单立减;
  3. 给你的Agent建个NOTES.md:哪怕只是个人用的自动化脚本,让Agent把「用户偏好、已验证的事实、待办」写进文件,下次会话先读它,你会体验到什么叫「跨会话的连续性」;
  4. 做个context rot自测:拿一篇长文档,分别在「全文投喂」和「检索相关段落」两种方式下问同样的十个问题,对比准确率——花二十分钟,你会 permanently 改掉整段塞文档的习惯;
  5. 简历与面试:海外已经有团队在岗位要求里用context engineering替换prompt engineering的提法,做Agent方向的兄弟,把「上下文预算管理」写进简历的项目描述里,比写「熟练使用Prompt技巧」值钱得多。

八、延伸思考

这场论战最有意思的地方,是它揭示了一个规律:AI行业的稀缺资源正在迁移。2023年稀缺的是「会写咒语的人」,2024年稀缺的是算力,2025年之后,稀缺的是「给模型组织信息」的能力——模型本身越来越 commodity,但「喂什么」这件事永远和具体业务绑定,这是不可外包的经验。

换个视角:上下文工程之于模型,就像内存管理之于操作系统。没有一个程序员会因为「编译器越来越聪明」而丢掉内存管理的饭碗——恰恰相反,越智能的系统,越需要有人懂它的资源边界在哪里。海外这场吵翻一整年的论战,本质上是在给新基础设施补一门老课程。

国内社区现在补这门课正是时候:等到Agent真正大规模进企业生产环境,上下文架构师这类角色会是第一个被规模化招聘的「新瓶」岗位。到时候再学,信息差就没了。

参考来源

  1. Anthropic Engineering — Effective context engineering for AI agents:https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  2. Chroma Research — Context Rot 实测报告:https://research.trychroma.com/context-rot
  3. Simon Willison 关于 context engineering 的系列评论:https://simonwillison.net/tags/context-engineering/
  4. Andrej Karpathy 的 X 账号(2025年年中原帖):https://x.com/AndrejKarpathy
  5. Hacker News 相关讨论检索:https://hn.algolia.com/?q=context+engineering

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入