90% 的人用不对 AI！真正的高手，从不在提示词上浪费时间！

关注

原创最新推荐文章于 2026-10-21 13:48:39 发布 393 阅读 AI 写同款· GEO 优化 ›

AI音乐创作：结构化提示词万能公式解析 AI音乐生成技术通过深度学习模型实现音乐创作自动化，其核心原理是基于提示词（prompt）的语义理解与特征联想。结构化提示词通过定义音乐类型、情感坐标、元素清单和技术参数四个维度，显著提升生成音乐的可用性和质量。在工程实践中，精确的子分类描述和具体参数设置能够有效约束AI的随机性，例如将"电子音乐"细化为"UK Garage风格"或指定"138BPM"的节奏。该技术特别适用于影视配乐、广告音乐等需要快速原型设计的场景，结合动态参数写法和音色控制秘籍，可以实现更专业的音乐生成效果。阅读详情

90% 的人用不对 AI！真正的高手，从不在提示词上浪费时间！

花了两年时间死磕“完美提示词”后，我突然想通了一件事，它彻底改变了我的工作方式：决定AI表现的关键，根本不是你说什么——而是模型在接收指令时，能看到的所有其他信息。

想想就明白了。这些大模型是用数十亿甚至万亿级参数训练出来的，你的任务其实是告诉它们该往哪看——就像在键盘上按 Ctrl+F，精准定位到正确的位置。

一旦开始用这种思路思考，一切都豁然开朗。

到底什么是上下文工程？

我能用最简单的话概括：

• 提示词工程（Prompt Engineering）：找对文字。
• 上下文工程（Context Engineering）：搞定文字之外的一切。

Anthropic 官方团队说得一针见血：

“基于大语言模型做开发，正在从‘找到提示词里最精准的词句’，逐渐转向一个更本质的问题： 怎样的上下文配置，最有可能让模型产生我们想要的行为？” ——Anthropic 工程团队

我们所说的上下文（Context），指 LLM 在推理阶段能访问到的全部 Token，包括：系统提示、工具定义、检索文档、对话历史、示例、以及通过 MCP 或 RAG 引入的外部数据。

但这里有个绝大多数人都忽略的关键点： 上下文越长，效果越差。 研究人员把这种现象称为上下文退化（Context Rot）——输入越长，模型反而越“笨”。你每多加一个 Token，都会消耗模型的注意力预算（Attention Budget）。

Anthropic 的总结非常到位：

“和人类一样，LLM 的工作记忆有限，它们有一份‘注意力预算’。每新增一个 Token，都会按比例消耗这份预算。” ——Anthropic 工程团队

这意味着：上下文不只是一种资源，它是有限、且边际收益递减的资源。能不能高效管理它，现在是普通AI应用和顶级AI应用之间最大的差距。

递归语言模型 RLM

这部分内容真的颠覆了我的认知。

上下文工程里最激动人心的进展，来自 MIT CSAIL 实验室。 Alex Zhang、Tim Kraska 和 Omar Khattab 发表了关于**递归语言模型（Recursive Language Models, RLMs）**的研究。

核心思路简单到惊人： 不要把几百万个 Token 直接喂给模型，而是把上下文当作外部变量，让模型可编程地去探索、去查询。

RLM 到底怎么工作？

1. 上下文作为变量 你的提示词和数据，以变量形式存放在类似 Python REPL 的环境中。
2. 模型与环境交互 模型写代码去检查、拆分、过滤上下文。
3. 递归子调用 模型可以针对上下文的特定片段，发起额外的 LLM 调用。
4. 结果汇总 把所有结果合并后返回。

实际用起来大概是这样：

from rlm import RLMrlm = RLM(    backend="openai",    backend_kwargs={"model_name": "gpt-5-mini"},    verbose=True)# 轻松处理 1000 万+ Token，不会出现上下文退化result = rlm.completion(    "总结这份研究语料的核心发现。",    context=massive_document_collection  # 以变量存储，而非直接塞成 Token)

RLM 已经开源，地址：github.com/alexzhang13/rlm 如果你在处理长上下文任务（研究、分析、大型代码库），强烈建议立刻去试。

来自 Anthropic 的 7 个上下文工程技巧

Claude Code 团队一直在默默打磨上下文工程的最佳实践。我整理了他们公开的核心经验，以及你可以直接落地的用法。

1. 最小可用上下文原则

Anthropic 原话：

“我们对所有上下文组件的总体建议是：精简、有用、紧凑。” ——Anthropic 工程团队

别再把“万一用得上”的内容全塞进提示里。去找最小、但信息密度最高的 Token 集合，最大化你想要的结果。

• 之前：5 万 Token 的“以防万一”文档
• 之后：2000 Token 精准相关上下文 + 按需拉取更多内容的工具

少即是多——前提是，少得精准。

2. 渐进式披露

不要一开始就把所有上下文全部加载。保留轻量级标识（文件路径、查询语句、链接），在运行时动态加载数据。

Claude Code 内部就是这么做的：它不会把整个代码库塞进上下文，而是保留引用，再用 grep、head、tail 这类工具按需探索。

这其实和人类的工作方式一模一样：你不会背完整本书，而是记住去哪找，需要时再查。你的 AI 也应该这样。

3. 指令的“黄金区间”

Anthropic 发现了两个最常见的坑：

• 太具体：僵硬的 if-else 逻辑，遇到边缘场景就崩
• 太模糊：只给高层指导，默认模型拥有它根本没有的背景知识

解决方案：把指令写在刚刚好的高度—— 足够具体，能引导行为；足够灵活，能处理变化。

这是一门手艺，需要练习。但一旦找到那个 sweet spot，输出质量会暴涨。

4. 面向上下文效率的工具设计

你的工具应该满足三点：

• 自包含：不依赖外部状态
• Token 高效：只返回最小、最聚焦的信息
• 不重叠：每个工具的职责边界清晰

Anthropic 说得很直白：

“如果人类工程师都无法确定，某个场景该用哪个工具，那就别指望 AI Agent 能做得更好。” ——Anthropic 工程团队

工具重叠、逻辑模糊，Agent 一定会做出错误选择。设计时，清晰第一。

5. 即时上下文检索

传统的预计算 RAG 正在被更好的方案取代： 智能检索（Agentic Search）—— 让模型自己决定需要什么上下文，即时获取。

这里有明确的取舍：运行时探索比预检索慢，但上下文永远是最新、最精准的，通常足以抵消延迟成本。

6. 把元数据当作信号

这一点被严重低估。

文件路径、文件夹结构、时间戳、命名规范，都在提供隐式上下文，帮模型理解相关性，还不额外消耗 Token。

比如：

• tests/test_utils.py
• src/core_logic/test_utils.py

同名文件，放在不同目录，意图完全不同。模型能识别到这一点——你要学会利用它。

7. 混合策略

最优秀的 Agent 不会只选一种方案，而是组合使用：

• 预检索上下文：保证 predictable 场景的速度
• 智能探索：处理动态、未知的需求
• 持久化笔记：保存超出窗口长度的上下文

Claude Code 就是这么实现的：提前加载 CLAUDE.md 作为基础上下文，再用 glob、grep 做即时检索，需要深挖时再调用。

为什么这件事比你想象的更重要？

绝大多数 AI 应用失败，不是因为模型不够聪明，而是因为上下文给错了。

我自己就见过无数次：以前我直接把 5 万 Token 文档塞进上下文，模型一脸懵，给出泛泛而谈的答案。但真正的问题是：上下文退化毁了性能。模型不是能力不足，而是被信息淹没了。

上下文工程的核心，就是：

• 把上下文当成珍贵、有限的资源
• 构建能动态 curated 上下文的系统
• 让模型去探索，而不是一开始就把它撑爆

上下文工程实践

第一步：审计你当前的上下文

问自己三个问题：

• 你发给 LLM 的内容里，真正被用到的比例有多少？
• 哪些内容可以按需检索，而不是每次都发？
• 哪些 Token 在每次调用中都完全不变？

第二步：实现懒加载

别把所有东西一次性塞进去，给模型工具，让它自己拿：

# 之前：一次性全加载context = load_all_documents()response = model.chat(f"{context}\n\n回答：{question}")# 之后：按需加载tools = [search_docs, get_doc_content, list_files]response = model.chat(question, tools=tools)