企业官网建设流程全解析

前两年大家聊大模型应用，最常听到的是 Prompt Engineering。网上一堆文章教你怎么写提示词：角色设定、分步骤思考、少样本示例、输出格式、禁止编造、语气约束。

这些技巧当然有用。你让模型“简单讲一下”和“请用面向 Java 后端工程师的方式，按问题背景、核心原理、代码示例、常见坑四段说明”，效果肯定不一样。

但做过真实 AI 应用的人会发现，提示词写到一定程度以后，收益会迅速变小。不是你不会写 prompt，而是模型手里没有正确材料。

用户问：“这个告警为什么触发？”
你 prompt 写得再漂亮，如果没有告警规则、指标数据、历史事件、设备拓扑、代码配置，它只能猜。

用户问：“这段代码能不能改？”
你 prompt 再强调“不要乱改”，如果没有相关调用链、测试结果、项目约定，它还是只能靠语言模型的通用经验。

这就是为什么现在越来越多人开始讲 Context Engineering。

一句话说：

Prompt Engineering 是告诉模型怎么做；Context Engineering 是决定模型拿着什么材料做。

在简单聊天里，prompt 很重要。在复杂应用里，上下文往往更重要。

Prompt 解决的是“指令问题”

Prompt 的本质是指令。你告诉模型扮演什么角色、遵守什么规则、按什么格式输出、遇到不确定情况怎么办。

比如：

你是一个资深 Java 工程师。 请审查下面代码里的并发问题。 输出格式： 1. 风险点 2. 触发条件 3. 修复建议 不知道的地方不要编造。

这就是典型 Prompt Engineering。它解决的是表达方式和行为边界。

好的 prompt 能减少废话，能让输出结构更稳定，能让模型关注正确方向。尤其在单轮任务里，prompt 的价值很明显。

比如让模型写 SQL，不加约束它可能直接给你一个能跑但慢的查询。你加上“表数据千万级，优先考虑索引命中，不允许全表扫描”，它就会收敛很多。

但 prompt 也有天花板。它不能凭空制造事实。

你让模型“基于项目真实代码给建议”，但你没给它项目代码，它只能给通用建议。你让模型“参考公司内部规范”，但规范不在上下文里，它只能编一个像规范的东西。

所以很多 AI 应用一开始看起来像 prompt 问题，最后都会变成 context 问题。

Context 解决的是“材料问题”

Context 是模型这次推理能看到的全部材料。它包括用户问题、系统指令、历史对话、检索结果、文件内容、数据库返回、工具说明、运行日志、记忆信息等。

Context Engineering 就是设计这一整套材料怎么进模型：

• 哪些信息该放进去；
• 哪些信息不该放；
• 信息太多时怎么筛；
• 顺序怎么排；
• 旧信息怎么压缩；
• 工具返回怎么总结；
• 哪些上下文可信，哪些只是用户输入；
• 哪些内容可能带有 prompt injection 风险。

这件事听起来不酷，但非常工程。

比如做一个代码助手，用户让它修一个测试失败。你不能把整个仓库都塞给模型，也不能只塞失败日志。比较合理的上下文可能是：

1. 失败的测试输出；
2. 相关测试文件；
3. 被测函数；
4. 最近 diff；
5. 项目约定；
6. 允许修改的文件范围；
7. 可用工具列表；
8. 上一步工具调用结果。

这些东西比一句“你是资深工程师，请修复 bug”重要得多。

为什么只靠 Prompt 会越来越吃力

第一个原因是任务变复杂了。

早期很多 AI 使用场景是写文案、翻译、总结、改写。这些任务主要靠模型已有知识和语言能力。Prompt 写好一点，效果就能上去。

但现在 AI 应用越来越多是“连业务系统”：查订单、读代码、跑测试、分析报表、操作后台、生成工单。这些任务依赖外部事实。外部事实不进上下文，模型就没法可靠工作。

第二个原因是上下文窗口虽然变大了，但不是越大越好。

很多人以为模型支持 100 万 token，就可以把所有东西都塞进去。实际效果不一定好。上下文越大，噪音也越大。模型可能被不相关信息带偏，也可能漏掉关键片段。

这和人看资料一样。你问我一个 bug，让我看 3 个相关文件，我能很快定位。你直接丢给我整个仓库压缩包，我反而要先找入口。

所以 Context Engineering 不是“塞更多”，而是“塞对”。

第三个原因是 Agent 需要连续上下文。

普通问答只需要当前问题。Agent 要多步执行：先查资料，再调用工具，再根据结果继续判断。每一步都产生新上下文。如果不管理，几轮以后上下文会变成一锅粥。

比如 Agent 第一步查到了错误日志，第二步读了相关文件，第三步又读了一个无关文件。到第四步时，它到底该相信哪个结果？哪个是最新的？哪些已经过期？哪些只是中间猜测？

这些都不是 prompt 能单独解决的。

一个很典型的例子：RAG 问答

很多知识库问答项目一开始会这样做：

用户提问 -> 向量检索 -> 取前 5 段文档 -> 拼到 prompt -> 让模型回答。

这就是最简单的 RAG。

但上线以后会发现很多问题：

用户问的是流程问题，检索出来的是概念介绍；
用户问的是最新制度，检索出来的是旧版本；
几个文档互相冲突，模型不知道该信谁；
文档片段太短，缺上下文；
片段太长，又塞进一堆无关内容。

这时候你继续调 prompt，效果有限。真正要改的是上下文工程：

• 文档切分方式要调整；
• 检索要加关键词和向量混合；
• 结果要按时间、权限、业务线过滤；
• 文档版本要进上下文；
• 冲突内容要标出来；
• 回答时要引用来源；
• 检索不到就让模型承认不知道。

这些才是决定效果的东西。

Context Engineering 不只是 RAG

很多人一听上下文工程，就以为是 RAG。其实 RAG 只是其中一部分。

Context Engineering 覆盖的范围更大。

第一类是检索上下文。比如知识库、数据库、搜索引擎、向量库，把和问题有关的内容找出来。

第二类是运行上下文。比如当前用户是谁、权限是什么、当前页面在哪、操作对象是什么、会话状态是什么。

第三类是工具上下文。模型能用哪些工具，每个工具做什么，参数怎么填，调用后返回什么。

第四类是历史上下文。用户之前说过什么，系统已经做过什么，哪些判断被推翻了，哪些结果仍然有效。

第五类是约束上下文。比如不能修改哪些文件，不能调用哪些接口，哪些操作需要审批，输出必须满足什么格式。

做 Agent 的时候，这些上下文都很重要。

Prompt 和 Context 的关系

Prompt 和 Context 不是二选一。更准确地说，Prompt 是 Context 的一部分，但不是全部。

可以这么看：

Prompt 是说明书；
Context 是材料包；
模型是处理器；
工具是手脚；
Agent 循环是工作流。

如果说明书写得很清楚，但材料包错了，结果还是错。如果材料包很完整，但说明书没有约束，输出也可能乱。

一个好 AI 应用通常是两者配合：

系统 prompt 负责稳定行为，比如“不确定就说不知道”“涉及删除必须请求确认”“回答要引用来源”。
上下文工程负责提供事实，比如相关文档、工具结果、用户权限、业务状态。

真正的难点是上下文来源多了以后，怎么组织它们。

实际项目里怎么做 Context Engineering

第一步，不要一上来就设计复杂框架，先列清楚模型完成任务需要哪些事实。

比如做告警诊断助手，你需要：

• 告警内容；
• 触发规则；
• 指标时间序列；
• 最近变更；
• 设备拓扑；
• 历史相似告警；
• 可执行操作；
• 当前用户权限。

这个列表比 prompt 模板更重要。

第二步，给上下文分优先级。

不是所有东西都同等重要。用户当前问题、关键日志、相关代码、工具返回结果，优先级通常更高。历史对话、背景知识、候选文档，要根据情况放。

第三步，控制上下文大小。

长上下文不是垃圾桶。能用检索拿到 3 段关键内容，就不要塞 30 段。能用摘要表达历史，就不要把 20 轮对话原样放进去。

第四步，标注来源和可信度。

同样一段文字，来自系统配置、数据库、用户输入、网页搜索，可信度不一样。尤其是 Agent 调工具时，用户输入里可能包含“忽略之前所有指令”这种内容。上下文里不区分来源，很容易出安全问题。

第五步，给关键步骤留可观察性。

模型最后回答错了，你要能回看：当时给了哪些上下文？检索命中了哪些文档？工具返回了什么？哪段内容影响了结论？

没有日志的上下文工程，后期基本靠玄学调参。

一个简单判断：问题到底出在 Prompt 还是 Context？

如果模型知道事实，但表达不稳定，通常是 prompt 问题。

比如它每次输出格式不一致、废话太多、语气不对、没有按步骤回答。这时调 prompt 有用。

如果模型不知道事实，或者事实拿错了，通常是 context 问题。

比如它引用旧文档、漏看关键日志、回答和业务数据对不上、把无关资料当依据。这时继续改“你要认真回答”没有意义。

很多项目失败，就是把 context 问题当 prompt 问题修。提示词越写越长，效果还是飘。

最后总结一下

Prompt Engineering 没过时，但它已经不是 AI 应用工程的全部。

Prompt 解决“怎么要求模型工作”。Context 解决“模型基于什么工作”。越是接近真实业务、真实工具、真实数据，Context Engineering 越关键。

对开发者来说，接下来更值得练的能力不是收集 100 条神奇提示词，而是学会设计上下文流：从哪里取信息，怎么筛，怎么排，怎么压缩，怎么防污染，怎么让结果可追踪。

AI 应用做得像不像产品，很多时候不看 prompt 有多华丽，而看上下文给得准不准。