别再靠运气写 Prompt，上下文工程实战手册！

“上下文工程”（Context Engineering）是当下的新热词，自从 Andrej Karpathy 在推特上推广它后，大家都为之疯狂。类似的情形以前也发生过，比如他推广“vibe coding”时，这个概念一夜之间风靡网络。不过我觉得，“上下文工程”的基础更扎实一些。

1. 什么是上下文工程？

img

img

可以这样理解：

• Prompting（提示词）：是你直接让模型去做某件事。
• Context Engineering（上下文工程）：是在提问之前，把模型可能需要的一切都准备好。

这不是要加更多文字，而是要加正确的文字。

你要给模型一个正确的角色去扮演，一个正确的受众去交流，以及一个清晰的“好”的标准。如果你不这样做，模型就会自己猜——而它通常会选择安全、通用的答案。

2. 实际运作方式

这不是一个完美的逐步方法，但下面是一个在实践中效果不错的大致流程。

2.1. 先弄清楚你真正想要什么

在问模型任何问题之前，先明确你期待的结果。不要这样：

“写一个食谱。”

试试这样：

“写一个素食菠萝蜜食谱，要像朋友在周日早上 11 点给你发消息那样的语气。”

明确语气、目的和受众，有助于模型更好地贴合你的预期。

2.2. 提供正确的信息

img

img

想想模型需要知道哪些信息，才能做得好。

• 模型要假装成谁？
• 它要对谁说话？
• 有什么规则吗？（字数限制、时间、语言类型？）
• 有可供参考的示例吗？

如果你不告诉它“控制在 30 分钟内完成”，它可能会给你一个需要几个小时的食谱；如果你不说“用初学者的语气”，它可能会用很复杂的词。

2.3. 合理安排输入顺序

顺序很重要。一个简单有效的结构是：

[角色或人设]
[事实或规则 — 必须包含的内容]
[示例 — 简短的语气或风格样本]
[最终任务 — Prompt]

最重要的内容应放在靠近末尾的位置——尤其是任务部分，因为 GPT 对接近结尾的内容更敏感。

2.4. 保持简洁

img

img

你没有无限空间，有token 限制，而且很容易用完。所以去掉没必要的东西：

• 不要重复解释
• 避免无关的问候或开场白
• 删掉对完成任务没帮助的内容

每一行都应该帮助模型理解说什么以及怎么说。

2.5. 直接且明确

大语言模型不会读空气。如果你想要某种语气或细节，就直接写出来。把 GPT 当作一个聪明但刚入职的实习生——如果你含糊，它会保守行事；如果你明确，它就能做对。

3. 两个真实示例

img

img

3.1 菠萝蜜食谱

目标：一个有趣、快速的素食菠萝蜜食谱。

• Prompt 版本：

“给我一个菠萝蜜食谱。”

结果：安全、无聊、毫无个性。

• 上下文工程版本：

[角色]
你是一名语气轻松的素食美食博主。

[细节]
主要食材：菠萝蜜
时长：30 分钟以内
受众：初学者
风格：像给朋友发消息

[语气示例]
“把菠萝蜜沥干。真的，那个盐水味太冲了。像撕掉没写完的作业那样把它撕碎，丢进芥末籽、蒜和任何辣的东西里。如果闻起来像街头 Dosa 小摊，那就对了。”

[任务]
用这种语气和格式写一个完整的食谱。

输出：更有人情味，不遗漏关键步骤，还有幽默感。

3.2 自动化风险博客

目标：写一篇面向工程师的文章，提醒不要在无人监督的情况下用 AI 部署代码。

• Prompt 版本：

“写一篇关于 AI 与自动化风险的博客。”

结果：套话满满、没观点。

• 上下文工程版本：

[角色]
你是一名中年软件工程师，给同行写博客。

[受众]
有经验但对 LLM 持谨慎态度的开发者。

[语气示例]
“是啊，Copilot 会写测试。但因为 CI 通过就让 GPT 合并代码？那就是等着计费系统悄悄出 bug。不会崩溃——只是安静地制造混乱。”

[任务]
写一篇 700 字的博客文章，包含一个关于机器人报税的轻松玩笑。

输出：更贴近读者，少了官腔，不说教但信息传达得很到位。

4. 我是怎么想出这些上下文的？

没有什么工具或模板，就是普通思考、反复试验，然后问自己：“如果我要自己写，会先需要知道什么？”

4.1 食谱案例

我不是先想“GPT 会理解什么 Prompt”，而是先想“我自己会喜欢读什么样的食谱”。我想要的：友好、快速、不太完美——像朋友做饭时发的消息。然后反推：

• 语气：轻松，稍微有点乱。
• 受众：可能是素食新手。
• 常见错误：GPT 会忘记提到沥干菠萝蜜，所以我提前写进去。

我还写了一句能抓住氛围的示例，比长篇解释更有用。

4.2 博客案例

我设想的读者：不是高管，不是新人，而是那种被 LinkedIn 上“AI 革命”吹得耳朵起茧的老开发。所以我让模型像一个有经验的工程师对另一个人聊天一样去写——带点怀疑但保留好奇。 我提供了：

• 明确的角色：幽默的中年开发者
• 真实的语气样本：一句带有特定讽刺的示例
• 一个具体的玩笑要求：不是真的为了笑话，而是让模型写得不那么正式

5. 那么，该怎么做？

其实你可能已经在做上下文工程了，如果你曾经：

给提示词加过示例 改写提示词以调整语气 描述过目标受众 删除过多余文字以节省空间

——那你就在做上下文工程。

译者注：所以我觉得所谓的上下文工程，如果只是本文来看的话，和提示词工程有什么区别呢？和我之前高赞原创的似乎没什么区别？ 那么你的看法是什么呢？评论区留下你的见解。

敲黑板！吴恩达LLM Agent工作流Prompt精华全解析

想做得更好：

像给新人写说明书一样思考 不只说“让它有趣”——要示范什么叫“有趣” 永远假设模型需要明确的指导

6. 最后的想法

当 GPT 给出好答案时，不只是因为它聪明，而是因为你给了它正确的设定。上下文工程，就是给模型一个公平发挥的机会。希望你也能在自己的提示词中试试！

本文译自 Medium 好文《How to do Context Engineering? Step by Step Guide》，作者 Mehul Gupta，可点击原文查看。

记得关注呦