这篇文章能帮你搞清楚什么
- 正式进入正文前先抓住核心结论
- 这件事会怎样影响读完后的实际判断
- 下一篇最值得继续打开的相关文章
「ChatGPT（聊天机器人）的提示词，必须写得更好才行」——焦虑的人，是不是很多？
我以前也是这样。把写法指南翻来翻去，把模板集存得满满当当，拼命去记各种套路。但是啊，有一天我突然意识到：就算提示词写得再完美，AI的回答有时候还是差强人意。
原因其实很简单。问题不在于「问AI什么」，而在于「给AI看什么」不够。
这项技术，现在美国开始叫它Context Engineering（上下文工程）。我想把它翻译成**「信息生态系统设计」**。Fortune（财富）杂志在3月26日做了专题报道，但中文世界的解读还是零。所以我先来写一篇。
读完这篇文章，你就能看清「提示词之后该做什么」了。
「擅长写提示词的人」已经赢不了了
「提示词工程」这个词，从2023年前后开始一下子流行起来对吧。
就是给ChatGPT下达高明指令的技术。比如「你是〇〇领域的专家」这种角色设定，或者「请一步一步思考」这种思维诱导。我自己也钻研得很深，也教给过客户们。
但是到了2026年，情况变了。光靠提示词的功夫已经不够用了。
根据Towards AI的分析，现在AI应用中出现的错误，70%以上的原因都不是「模型能力不足」。原因更多在于「上下文（语境信息）的缺失或不当」。也就是说，AI的性能已经足够高了。真正不足的是「交给AI的信息质量」。
举个例子，我对AI说「帮我做10个下个月的社交媒体发帖方案」，只说这么多。作为提示词来说也不算差吧？但AI不知道我过去帖子的表现数据。也不掌握粉丝的反应倾向，更不了解竞品的动向。
结果就是，得到一堆「看起来像那么回事但用不了」的方案。我的客户也反复抱怨「AI的回答太一般了根本没法用」。
不是提示词写得不好。而是给AI的「前提信息」设计得不到位。意识到这个问题的人们，开始提出「Context Engineering（上下文工程）」这一概念。
CIO的解读是这样表述的：「提示词工程的时代已经结束。取而代之的，是一种更稳健、更可扩展的新规范正在崛起。」
我自己的亲身体会是这样的。直到去年，光是把「提示词模板集」交付给客户，对方就很满意。但最近开始多了一种咨询：「按照模板做，结果还是不稳定。」
明明每次都用同样的提示词，AI回答的质量却有起伏。周一收到能用的方案，周三的就差点意思。这个差别到底是什么？
往深处挖原因，最终都归结到「每次给的信息不一样」「该有的信息缺失」上。这不是提示词的问题，而是上下文的问题。
Context Engineering是什么？一项把AI的「视野」整体设计出来的技术
用我自己的话翻译过来就是**「信息生态系统设计」**。
它是一项有意识地设计「AI在工作时所看到的信息全貌」的技术。Dextralabs的对比文章给出了一个很好的比喻。提示词工程是「写一封好信」，而Context Engineering是「设计整个邮政系统」。
这个比喻让我一下子就明白了。我们以前一直在练习写信的方法，但真正需要的是设计整个系统。
那具体要设计什么呢？分成4个领域来梳理一下。
1. 选择要获取的信息
交给AI的数据库内容、参考资料、过往交互。决定什么给它看、什么不给它看，这是起点。不是全部给它看就好。如果把无关的信息大量丢过去，AI的回答精度反而会下降。
2. 信息的结构化
把要交给AI的信息用JSON（数据整理格式）或摘要文整理好。还要把「这份数据要这样读」的阅读指引一并附上。把原始数据直接扔过去，和结构化之后再交给它，AI的理解程度完全不一样。
3. 记忆管理
短期记忆和长期记忆的区分使用很关键。Weaviate的技术博客讲解得很清楚。短期记忆是「此刻需要用到的信息」。长期记忆指的是「累积在向量数据库（把信息数值化便于快速检索的机制）中的过往知识」。
用人来打比方的话，「今天会议的议题」是短期，「去年的销售数据」是长期。这种切分也要为AI设计好。
4. 工具的定义
把AI能使用的工具（搜索、计算、文件操作等）事先定义清楚。「这种情况下用这个工具」的判断标准也要一并交给它。
这里最重要的一点是：不是「每次手动思考」，而是「作为机制自动化」。设计一次，之后AI就会自动地把所需的上下文组装起来。这和每次重写提示词的根本区别就在这里。
The New Stack的解读也值得一读。你听过RAG（让AI检索外部数据来增强回答的技术）吧。Context Engineering被定位为它的进化形态。RAG是「找到所需信息并取回来」的机制。Context Engineering则更进一步。
它要设计「取回来的信息怎么排列、什么要省略」的层面。用做菜来打比方，RAG是「采购食材」。Context Engineering则是「从菜单设计到摆盘装饰一整套全餐」。
一个人年收入6.7亿日元。Polsia（波西亚）证明了「上下文设计」的威力
「道理我懂，但真的有效果吗？」你可能会这么想。我一开始也半信半疑。但是知道这个案例之后，半信半疑变成了笃定。
Fortune杂志3月26日刊登的特辑给出了答案。
Ben Broca（本·布罗卡）。Polsia公司的创始人，员工只有他自己一个人。这个人达成了ARR（年度经常性收入）$4.5M，折合日元约6.7亿元的业绩。
而且速度快得离谱。上线仅仅30天就突破了$1M ARR（约1.5亿日元）。根据Context Studios的报告，超过1,000家公司在该平台上运转。从那时起再过2周，又达到了$2M（约3亿日元）的运行速率（参见Dealroom报道）。
Polsia究竟在做什么？它提供「让AI整体经营一家公司的平台」。用户输入一个想法，AI就会帮你构建产品。修Bug。处理客服。甚至连营销活动都自动跑起来。每天晚上AI都在工作，第二天早上邮件汇报进度。睡觉的时候AI替你工作的世界，是不是有点让人羡慕？
而支撑这一切的正是Context Engineering的思路。Broca设计的不是「一条厉害的提示词」。而是把AI能理解整个业务并自主判断的「信息环境」整套设计出来。
True Ventures的分析评论道：「一人公司不再是比喻。」风险投资公司Sequoia Capital也行动起来了。他们开始把「Agentic Leverage（智能体杠杆度）」纳入投资组合的评估指标。
Broca的履历也很有意思。他原本是CloudKitchens（Travis Kalanick创办的幽灵厨房业务）的早期成员。虽然有科技行业经验，但并不是工程师里的超级明星。本人采访中令我印象深刻的一句话是：「不在硅谷、不会写代码的时代来了，AI会代替你来做。」
「年收入6.7亿日元」也许是一个极端案例。但比起金额，更值得关注的是结构性的变化。从「向AI下达指令的人」转变为「设计AI工作环境的人」的那一刻，一个人能做的事情上限就一下子被拉高了。
我能够一个人运营5家公司的社交媒体营销，虽然规模完全不能比，但我觉得本质结构是一样的。比起提示词功夫，胜负取决于AI所看到的信息质量。
提示词和上下文，3分钟搞清差异
「说白了不就是提示词工程的延伸吗？」可能有人会这么想。倒也不能说是完全两码事，但覆盖范围根本不同。我来梳理一下。
提示词工程
- 对象：一次指令文本
- 目的：准确传达「希望AI做什么」
- 技能：语言表达能力、模板制作
- 局限：在需要记忆和推理的复杂任务上薄弱
Context Engineering（信息生态系统设计）
- 对象：AI所看到的整个信息环境
- 目的：营造「AI能自主做出正确判断的状态」
- 技能：信息设计、数据管理、工作流构建
- 优势：能够应对记忆、推理、实时信息的组合
用简单的话讲，提示词工程是「会问问题的方法」。Context Engineering是「营造让AI能够聪明工作的环境的方法」。前者只是后者的一部分。
根据Gartner的预测，到2026年底，40%的企业应用预计将搭载AI智能体。2025年的数据还不足5%，所以是一口气涨到8倍。AI智能体是指「能自主判断并行动的AI」。PwC的AI智能体调查显示，79%的高管表示「已经导入」。但能广泛部署的只有35%。
为什么推进不下去？因为虽然「让AI做什么」定下来了，但是「为AI准备什么样的信息环境」却没设计出来。这正是Context Engineering的用武之地。
我在自己的客户那边也看到过同样的现象。「我们已经导入ChatGPT了！」嘴上是这么说，但用法停留在「每次都临时想提示词然后丢过去」的公司很多。如果不去设计信息环境，AI每次都处在「跟初次见面的对方对话」的状态。
这一点用人际关系来类比就很好理解。每次都从自我介绍开始的对话，没法触及深入的话题对吧？AI也是一样。
我正在实践的Context Engineering入门法
「那我们到底该从哪里开始？」
进入正题。不需要难懂的工具，也不需要编程。下面分享3个我在社交媒体营销的客户工作中实际使用的方法。
实践①：制作交给AI的「前提信息表」
不管是ChatGPT还是Claude（克劳德），最开始都要交给它一份「希望你先了解这些」的文档。我自己会放入以下这些项目。
- 自己的业务概况（行业、营收规模、目标客户）
- 过去3个月互动量最高的5条社交媒体帖子
- 3家竞品近期的发声倾向
- 本月的目标（粉丝数？销售额？品牌认知度？）
仅仅是这样，AI回答的精度体感上就提升了3倍。「问个好问题」远不如「给个好前提」来得有效。第一次把这4项交给AI时看到的回答，那种「啊？差距这么大？」的震撼我现在还记得。
要点是做成「可以反复使用的表」。不是每次从零开始写，每月更新一次就够。我自己在Notion里做了模板，按客户分别管理。
实践②：决定「不给它看什么」。减法式设计
信息不是越多越好。给了无关的信息，AI反而会混乱。
我严格执行「与本次任务无直接关系的信息一律删除」的规则。做社交媒体帖子方案的时候，不需要财务信息对吧？听起来理所当然，但「反正先全部交过去吧」却是很多人会犯的毛病。
以前我也这样。觉得「信息越多越好」，把客户资料整套地交给AI。但那样一来，AI就无法判断「该关注什么重点」。结果回答就模糊不清。
切换到「减法式设计」之后，AI的回答一下子变得锐利起来。我觉得这就是Context Engineering的核心。不只是「让AI看到什么」，还要包含「不让AI看到什么」的设计才完整。
实践③：把结果纳入反馈循环
把AI建议执行后的结果（数据和反应）记录下来，下次使用AI时一起交给它。只要告诉它「上次这个建议带来了○○的结果」，下次建议的精度自然就上来了。
做与不做之间的差距就在这里。把AI「一次性使用」的话，每次都得从零开始建立关系。好不容易积累下来的学习就没法沉淀。
我自己每周都把社交媒体帖子的反应数据记录在表格里。「这个角度互动率高」「这个时段的帖子没起来」之类的信息，下次咨询AI时一起交过去。仅仅是这样，建议的质量就完全不是一个层级。
我把这3点坚持了半年。结果是，能够一个人运营5家客户的社交媒体了。一开始觉得麻烦，但只要设计一次，之后就不用每次从零开始写指令了。
把「信息生态系统设计」从今天就落地到工作中的步骤
读到这里，如果你已经动心想试试看，我会很高兴。下面整理出你今天就能开始Context Engineering的具体步骤。
步骤1：选定一个你自己的AI使用场景（耗时：15分钟）
回复邮件、做社交媒体帖子、会议纪要总结、提案书草稿。什么都行，先定一个。想着「全部都做」的话什么都推进不了。
我最开始选的是「写给客户的周报」。每周都要做的工作，可以反复使用，最适合练手。「明明每次都做同样的活，却每次都在重写指令」——选这种工作就对了。
步骤2：列出这项任务需要的「前提信息清单」（耗时：30分钟）
把AI要完美完成所选任务所需的信息逐条列出来。
例：制作社交媒体帖子的情况下
- 品牌的调性和风格
- 目标人群的属性和痛点
- 过往高表现帖子的特征
- 本月的活动信息
- 竞品近期3条帖子的倾向
这份清单，就是你的第一份「上下文设计书」。一开始不必完美。有5项就够开始了。
步骤3：用1周时间持续改进（耗时：每天5分钟）
用做好的前提信息表请AI处理任务。结果不满意的话，就思考「缺了什么信息」，把它补充到表里。坚持1周，专属于你自己的「能让AI拿出最佳成绩的信息环境」就成型了。
把所有时间加起来，第一天45分钟。第二天之后只要5分钟。喝一杯咖啡的工夫就搞定。这点投资就能让AI协作的质量发生根本性的改变。
我的一位客户开始这3步骤的2周后就有了变化。她对我说：「思考AI指令的时间减半了。」而且AI输出的质量还上升了。
仔细想想这是理所当然的吧？人也一样，了解对方的工作和烦恼，才能提出更好的建议。AI也是同理。仅仅是把信息环境整顿好，AI就会聪明得像变了个人。
总结
对一路读到这里的你，我想坦白一件事。
「提示词写法」决定胜负的时代，正在走向终结。
下一个战场是「让AI看到什么」的设计能力。这就是Context Engineering。我命名为**「信息生态系统设计」**的这项技术，本质就在这里。
Polsia的案例证明了，只要善用这项技术，一个人也能撬动亿级业务。当然不是所有人都需要冲着那个目标去。但仅仅是脱离「每次从零开始给AI写指令」的状态，你的工作就一定会发生变化。
Fortune杂志报道这个概念是在3月26日。距今才过去4天。用中文解读这个概念的文章，这篇应该是第一篇。也就是说，现在读这篇文章的你，是中文圈最早接触这个概念的人之一。
与其犹豫不如行动。先做一张「前提信息表」试试看。我也是从那里开始的。不必完美。写出来交给AI，看结果再修改。仅仅把这个循环跑1周，你和AI的相处方式就会改变。
我花了半年时间得出的结论是：「比起怎么问AI，先把AI所看到的风景整顿好」。「先做先得」在AI时代也不变。提示词之后的武器，已经摆在你眼前。
女性だからこそ、AIを使いこなさなきゃって思ってる。仕事も、副業も、推し活も、旅行も、全部やりたい。人生一度きりなのに時間は足りないじゃん？だからAIに任せられることは全部任せる。浮いた時間で本当にやりたいことをやる。それがあたしのスタイル。ここにはあたしが実際にやったことをまとめてるだけ。誰かのためになったらいいなって思って書いてるよ。
