墨七老照片修复专家
116.19M · 2026-04-19
最近和几个做 AI 产品的朋友聊天，发现大家对"怎么用好大模型"这件事，认知差距非常大。
有人还停留在"多加几个词就能让 GPT 听话"的阶段；有人开始系统地管理上下文窗口、设计信息流；还有人已经在构建整套测试框架，把 AI 调用当成工程系统来对待。
这三种状态，其实对应着目前 AI 工程领域正在发生的三次认知跃迁：
本文想认真捋一下这三层的本质区别，以及它们在实际工程中的意义。如果你正在用大模型做产品或工具，这篇文章应该对你有帮助。
Prompt Engineering（提示词工程）是目前最广为人知的概念。简单说，就是通过精心设计输入文本，引导语言模型输出你想要的结果。
但很多人对它的理解是错的——以为只是"换几个词"或者"加一句 you are an expert in..."。
实际上，成熟的 Prompt Engineering 包含以下几个核心维度：
角色设定（Persona）
You are a senior backend engineer with 10 years of experience in distributed systems.
Your responses should be concise, technical, and assume the reader is familiar with CS fundamentals.
任务拆解（Task Decomposition）
把复杂任务拆成子任务，让模型一步步完成，而不是期待它一次到位。
Step 1: Analyze the requirements
Step 2: Identify potential edge cases
Step 3: Propose a solution
Step 4: Write the implementation
少样本示例（Few-shot Examples）
给模型看几个"正确答案长什么样"，比说一百遍"请输出 JSON 格式"都管用。
Input: "用户无法登录"
Output: {"category": "auth", "priority": "high", "assignee": "backend-team"}
Input: "首页加载很慢"
Output: {"category": "performance", "priority": "medium", "assignee": "frontend-team"}
Input: "{{user_issue}}"
Output:
思维链（Chain of Thought）
在提示词里加上 Let's think step by step，或者显式要求模型在回答前先推理。
这不是玄学，而是有实验支撑的：CoT 能显著提升模型在推理、数学、逻辑类任务上的准确率。
Prompt Engineering 的核心假设是：模型是固定的，我们通过调整输入来控制输出。
这个假设在简单场景下没问题。但当你的应用变复杂之后，你会遇到几个绕不过去的墙：
这就引出了下一层：Context Engineering。
如果说 Prompt Engineering 关注的是"怎么说话"，那么 Context Engineering 关注的是**"在对话里放什么信息，以什么结构放，放多少"**。
一个现代 LLM 应用的上下文窗口，远不止是 system prompt + user message，它可能包含：
┌─────────────────────────────────────┐
│ Context Window │
├──────────────┬──────────────────────┤
│ System │ 角色定义、行为约束 │
│ Prompt │ 输出格式要求 │
├──────────────┼──────────────────────┤
│ Retrieved │ RAG 检索到的相关文档 │
│ Documents │ 数据库查询结果 │
├──────────────┼──────────────────────┤
│ Tool Results │ 已执行工具的返回结果 │
│ │ API 调用输出 │
├──────────────┼──────────────────────┤
│ Memory │ 用户历史偏好 │
│ │ 上一轮关键信息摘要 │
├──────────────┼──────────────────────┤
│ Conversation │ 多轮对话历史 │
│ History │ （经过筛选和压缩的） │
├──────────────┼──────────────────────┤
│ Current │ 用户当前输入 │
│ Input │ 附件、截图等 │
└──────────────┴──────────────────────┘
你要做的不只是写提示词，而是精心设计这整个信息架构。
挑战一：相关性过滤
不是所有信息都该进上下文。把无关内容塞进去不仅浪费 token，还可能干扰模型的注意力（这不是比喻，Attention 机制就是字面意义上的"注意力"）。
好的 Context Engineering 需要回答：这条信息，现在，对当前任务，有没有用？
挑战二：信息密度优化
有时候你需要在有限的 token 预算里塞进尽可能多的信息。这就涉及到：
挑战三：信息时效性管理
模型对上下文里靠前和靠后的内容记得更清楚（这是 Lost in the Middle 现象），所以重要信息的位置也是工程变量。
挑战四：跨轮次状态管理
多轮对话中，如何在不超出 context 限制的同时，保持对话的连贯性和"记忆"？
一个经典的解法：
def compress_history(messages: list[dict], max_tokens: int) -> list[dict]:
"""
保留最近 N 轮完整对话，
对更早的对话进行摘要压缩，
始终保留 system prompt。
"""
system = [m for m in messages if m["role"] == "system"]
history = [m for m in messages if m["role"] != "system"]
recent = history[-6:] # 保留最近 3 轮
older = history[:-6]
if older:
summary = summarize_with_llm(older) # 摘要压缩
summary_msg = {"role": "assistant", "content": f"[Earlier context summary]: {summary}"}
return system + [summary_msg] + recent
return system + recent
Context Engineering 的本质是一个信息检索与筛选问题：在正确的时机，把正确的信息，以正确的格式，放到模型能看到的位置。
它要求工程师不只懂 LLM，还要懂信息架构、检索系统、数据结构。
这是比 Prompt Engineering 深一层的能力。
"Harness" 这个词来自测试工程领域，原指测试框架或测试脚手架。
在 AI 工程语境下，Harness Engineering 指的是：围绕 LLM 调用构建完整的工程基础设施，包括评估、测试、可观测性、版本管理等。
如果说前两层关注的是"怎么让模型表现好"，Harness Engineering 关注的是：我怎么知道它表现好？我怎么保证它持续表现好？
组件一：Evaluation Framework（评估框架）
LLM 的输出是自然语言，不像传统软件可以直接 assert output == expected。你需要专门的评估机制：
class LLMEvaluator:
def evaluate(self,
prompt: str,
output: str,
ground_truth: str | None = None) -> EvalResult:
scores = {}
# 1. 基于规则的评估（快速、确定性）
scores["format_valid"] = self.check_format(output)
scores["no_hallucination_markers"] = self.check_safe_phrases(output)
# 2. 基于模型的评估（慢、但能评估语义质量）
scores["relevance"] = self.llm_judge(
f"Rate the relevance of this response to the query: {prompt}nResponse: {output}"
)
# 3. 基于 ground truth 的评估（最准确，但需要标注数据）
if ground_truth:
scores["accuracy"] = self.semantic_similarity(output, ground_truth)
return EvalResult(scores=scores, passed=all(s > 0.7 for s in scores.values()))
组件二：Prompt 版本管理
提示词不应该硬编码在业务逻辑里。你需要：
# prompts/ticket_classifier/v2.yaml
version: "2.0"
author: "zhangsan"
created_at: "2025-03-15"
changelog: "增加了对中文工单的支持，优化了 priority 判断逻辑"
system: |
You are a customer support ticket classifier...
few_shot_examples:
- input: "用户无法登录"
output: '{"category": "auth", "priority": "high"}'
eval_metrics:
- name: "format_valid"
threshold: 1.0
- name: "accuracy"
threshold: 0.85
组件三：可观测性（Observability）
LLM 调用是黑盒，但你的系统不应该是黑盒。你需要追踪：
@trace_llm_call # 装饰器自动记录输入输出、耗时、token 数
async def classify_ticket(ticket: str) -> dict:
prompt = prompt_registry.get("ticket_classifier", version="latest")
response = await llm.complete(prompt.render(input=ticket))
result = parse_json(response)
metrics.record("ticket_classifier.confidence", result.get("confidence", 0))
return result
组件四：回归测试套件
每次修改 prompt 或升级模型版本，都需要跑一遍测试，确保没有引入退化：
测试套件结构：
├── golden_set/ # 核心用例，必须 100% 通过
│ ├── auth_cases.json
│ ├── billing_cases.json
│ └── edge_cases.json
├── regression_set/ # 历史 bug 的复现用例
│ └── reported_issues.json
└── stress_set/ # 边界条件和压力测试
└── adversarial.json
有一个现象我在很多团队里都见过：AI 功能上线时效果不错，但几个月后慢慢变差，大家都不知道为什么，也不知道从哪里查起。
原因可能是：
没有 Harness，你对这些变化是盲目的。有了 Harness，你才有能力持续、可信地迭代 AI 功能。
这是把 AI 功能从"玩具"做成"产品"的关键一跃。
| 维度 | Prompt Engineering | Context Engineering | Harness Engineering |
|---|---|---|---|
| 关注点 | 如何表达任务 | 如何组织信息 | 如何保证质量 |
| 核心技能 | 语言理解、认知心理学 | 信息检索、数据工程 | 测试、可观测性 |
| 主要产物 | 提示词模板 | 上下文管道 | 评估框架与测试套件 |
| 衡量指标 | 人工感知质量 | Token 效率、召回率 | 准确率趋势、回归率 |
| 迭代周期 | 快（分钟级） | 中（天级） | 慢（周级） |
| 适用阶段 | MVP 探索期 | 产品成长期 | 规模化运营期 |
这三层不是互相替代的关系，而是递进且相互依赖的：
假设你在做一个代码审查 AI 助手，让我们看看三层工程分别在做什么：
Prompt Engineering 层
设计 system prompt，明确角色是"资深工程师"，输出格式要求 Markdown，审查维度包括安全性、性能、可读性；用 few-shot 给出标准审查意见的样例。
Context Engineering 层
在用户提交代码时，动态检索：
把这些信息精心组装进上下文，确保 token 不超限，且最相关的信息排在最前面。
Harness Engineering 层
维护一个包含 200+ 历史 PR 的评估集，其中有人工标注的"好审查"和"差审查"；每次修改 prompt 后自动跑评估，报告质量分数；监控线上调用的 latency 和用户满意度打分；发现哪类代码审查质量在下降时自动告警。
大模型应用工程正在快速成熟，三层工程代表着三种能力层次，也代表着 AI 工程师的三个成长台阶：
你现在站在哪一层？又打算往哪里走？
欢迎在评论区聊聊你的实践和踩坑经历。
如果文章对你有帮助，点个免费的赞鼓励一下吧！关注公众号:加瓦点灯， 每天推送干货知识！
