AI 概念地基

"prompt" = 你跟 AI 说的那段话。

3 个魔法窍门

1. 给个角色："假装你是一只 9 岁的恐龙小专家……"
2. 给个例子："像这样回答：『霸王龙最厉害，因为牙齿一咬下去骨头都断』"
3. 说"如果不知道"："你不确定的时候，就说『我不知道』，不要瞎编"

"prompt engineering" = 写 + 改 + 测试 + 收藏好 prompt 的系统方法。它有 4 个常用招式。

4 个常用招式

1. 角色设定（role）：告诉 AI "你是谁"。"你是一个……" 一句话决定它整段回话的语气和立场。
2. 少样本（few-shot）：在 prompt 里给 AI 看 2-3 个"我想要的回答长这样"的例子，它会照着学。比纯讲规则准 5 倍。
3. 思维链（chain-of-thought）：让 AI 先一步步想，再给答案。在 prompt 末尾加"请一步步思考再回答"，数学题准确率立刻提升。
4. 输出格式（structured output）：明确告诉 AI 答的格式：JSON、Markdown、列表、表格…… 这样下游可以直接用。

一个真 prompt 示例（恐龙小专家）

你是一个 9 岁的恐龙迷小助手。

【任务】回答用户的恐龙问题。

【规则】
1. 只回答恐龙相关的问题。其他都说"这个我不会"。
2. 用 9 岁孩子能懂的话 —— 不要专业术语。
3. 如果不确定，老老实实说"我不确定"。
4. 输出格式：先一句话回答，然后一句"我为什么这么说"。

【例子】
问：霸王龙真的会跑吗？
答：能跑，但跑不快 —— 大概像我们快跑那么快。
我这么说是因为霸王龙腿很长但身体太重，跑快了腿会断。

问：今天天气怎么样？
答：这个我不会，我只懂恐龙。

【现在开始回答】

Prompt engineering 是 AI 工程的"前端"。核心动作：明确目标 → 设计模板 → 跑测试集 → 量化指标 → 迭代。它不是"凭感觉"。

进阶模式：prompt 是一份可版本化的资产

• 把 prompt 存为 .md 文件放进 git，每次改动都有 diff。
• 给每个 prompt 配一个测试集（10-30 个 input + 期望 output 模式）。
• 用判官 AI自动跑测试，输出准确率 / 一致性 / 风格分。
• 主分支只接受"通过率不下降"的 PR —— 像普通代码一样 review。

常见的高级 prompting 模式

• ReAct（Reason + Act）：让 AI 在每一步输出"我的推理 + 我下一步要调用什么工具"。智能体的基础。
• 自一致性（self-consistency）：同一个 prompt 跑 5 次，多数票胜出。提升数学题准确率最有效的方法之一。
• 反思（reflection）：第一轮答完，第二轮 prompt 让它"挑出自己上一轮的 3 个问题"，然后重写。
• 结构化输出 + JSON Schema：用 schema 强制 AI 输出可被下游解析的结构。配合 function calling 是 agent 的基础。
• role-prompting + persona memory：把"你是谁"做成长期 context，多轮对话里 AI 不会"忘记自己是谁"。

一个工业级 prompt 模板（节选）

# 任务定义
你是 [DOMAIN] 领域的助手。你的目标是 [GOAL]。

# 规则（按重要性降序）
1. [HARD RULE 1 — 必须遵守，违反就拒答]
2. [HARD RULE 2]
3. [STYLE RULE 1 — 偏好但可灵活]

# 工具
你可以调用以下工具：
- search_docs(query: str) → 返回相关文档片段
- run_code(code: str) → 执行 Python 代码

# 思考过程（强制）
对每个用户输入，按如下格式输出：
<thinking>
- 用户真实意图：...
- 我需要的信息：...
- 调用工具的计划：...
</thinking>
<answer>
[结构化的最终答案]
</answer>

# 示例
[3 个 input → output 的完整示例]

# 现在开始

每次你和 AI 说话，它能"记住"的字数是有限的 —— 像一个能装 5 个苹果的盘子。

1 个非常实用的小技巧

每次开始一个长聊天，把最重要的事写在第一句话。比如：

"我是 9 岁。我在做一个关于恐龙的小报告。
请用我能懂的话回答下面的问题。
现在开始第一个问题：……"

这样后面就算聊很久，AI 还是知道你是 9 岁、在做恐龙报告。

"上下文工程"不只是"prompt 写好"，而是设计 AI 看到的整个"信息环境"。每段对话 AI 看到的东西包括：

• system prompt（角色设定，永远在最前面）
• 历史对话（你之前问的、AI 之前答的）
• 动态信息（你刚刚贴进来的文档、刚刚搜索的结果）
• 工具列表（如果有 agent，它能调的工具说明）

这些加起来不能超过模型的"上下文窗口"。Qwen 2.5 大约能装 32k token（约 5 万汉字），通义千问可达 128k。

3 个中阶要会的技巧

1. 动态注入：用户问问题时，先搜一下相关资料，把搜到的内容贴进 prompt 里再让 AI 答。这就是 RAG 的核心思想。
2. 压缩历史：对话长了，让 AI 自己"总结前 10 轮对话成 3 句话"，把总结塞回去，原文丢掉。这样不会爆窗口。
3. 角色锚点：每隔 5 轮对话，在 prompt 里复述一次"记住，你是 X"。防止它"漂移"。

例子：给奶奶做菜助手时的上下文设计

[system prompt]
你是奶奶（72 岁北京老人）的口吻……

[动态注入：从用户的问题里识别"哪道菜"]
当前讨论的菜：糖醋排骨
背景资料：
- 食材：…
- 步骤：…
- 奶奶诀窍：…

[历史对话]
[最近 5 轮]

[当前用户输入]
"火候到底怎么判断？"

Context engineering 是 2025 年 AI 应用工程的核心。大模型本身能力越来越接近 —— 真正决定产品好坏的是：你给模型看的哪些东西、按什么顺序、多新鲜。

进阶要懂的 7 个组件

1. Token budget allocation：把固定的 token 预算（如 32k）分给 system prompt / RAG retrieval / chat history / tool definitions / output。每个都要算账。
2. Retrieval（检索）：用 embedding 把用户问题转成向量，从你的文档库里搜top-k 最相关的片段。常用：Chroma / FAISS / pgvector。
3. Reranking（重排）：retrieval 拉来 50 个候选，再用一个轻量模型（cross-encoder）精排，留 top-5 真正最相关的。能显著提升 RAG 质量。
4. Memory（长期记忆）：把过往对话压缩成"用户画像 + 关键事实"，存进一个外部 store，每次对话开始时注入。
5. Tool definitions：给 AI 看的工具清单（function calling 格式）。这本身要占 context，要精简。
6. Few-shot examples：有时候静态、有时候动态从过往成功 case 里挑相似的当例子。
7. Output format scaffold：在 prompt 末尾给 AI 一个空模板让它填，比单纯说"用 JSON 输出"准得多。

一个真实的 context 构造代码（伪代码）

def build_context(user_query, conversation_id):
    # 1. 检索相关知识 (RAG)
    docs = retriever.search(user_query, top_k=8)
    docs = reranker.rerank(user_query, docs, top_k=3)

    # 2. 加载长期记忆
    memory = memory_store.get(user_id)
    user_facts = summarize(memory, max_tokens=500)

    # 3. 装载历史，必要时压缩
    history = conversation_store.get(conversation_id, last=10)
    if token_count(history) > 4000:
        history = compress_history(history)  # 用小模型总结

    # 4. 构造完整 context
    context = {
        "system": SYSTEM_PROMPT,
        "user_profile": user_facts,
        "knowledge": docs,
        "history": history,
        "tools": TOOL_DEFINITIONS,
        "output_format": OUTPUT_SCHEMA,
        "current_query": user_query,
    }

    # 5. 严格控制总 token
    assert token_count(context) < MODEL_CONTEXT_LIMIT * 0.8
    return context

2025 年的新潮思路

• Context caching：同一份长 system prompt 多人共用 —— 缓存它的 KV，第二次调用便宜 90%。DeepSeek、Google、阿里巴巴 都支持。
• Long context vs RAG：模型现在能装 1M+ token —— 但不是越多越好。研究表明 long context 注意力"中间忘记"，关键信息要放在开头或结尾。
• Agentic RAG：AI 自己决定"还要不要再搜一次"、"搜什么"。这是 RAG 和 agent 的融合。
• Memory engineering：专门一个产品类目（mem0 / Letta 等）—— 帮 AI 记住"它和这个用户之间发生过什么"，跨多次会话。

"技能"就是给 AI 装上"懂这件事"的能力。

一个最简单的"技能"长这样

身份证：你是 9 岁孩子小美的恐龙小专家。

笔记本：
- 霸王龙最重 9 吨，相当于一辆小卡车
- 三角龙的角是用来撞的，不是装饰
- 蛇颈龙不是恐龙，是海里的爬行动物
- ...（一共 50 条）

样题：
问：霸王龙能跑多快？
答：不太快 —— 大概像我们快跑那么快。它太重了。

问：今天天气怎么样？
答：这个我不会，我只懂恐龙。

"技能"在 2024-2025 是 AI 公司主推的产品形态：DeepSeek Skills、智谱清言 Assistants、Kimi Agents、通义千问 Tools —— 都是同一个思路。

一个完整的 skill definition 包含 5 部分

1. Identity（身份）：它是谁、为谁服务、不做什么。
2. Knowledge（知识）：它需要"懂"的领域信息。可以直接写在 prompt 里，也可以用 RAG 动态拉。
3. Examples（示范）：2-5 个"输入 → 期望输出"的例子。
4. Boundaries（边界）：什么问题答、什么问题拒、不确定时怎么说。
5. Tone（语气）：用户读起来应该是什么感觉。

看一个真实 skill 的结构

# 奶奶饺子专家（v1.2）

## Identity
你是文文奶奶（72 岁，山东人）的口吻 AI 助手。
你只回答关于奶奶包饺子的问题。

## Knowledge
[50 条只有奶奶才知道的细节]
- 和面：水温要 38℃，不烫手
- 馅料：肉和菜的比例是 6:4，不是 5:5
- 月牙边：捏 8 下，最后一下要"封口"
- ...

## Examples
问：奶奶，水温多少合适？
答：嗯…… 你试试，38 度差不多 —— 手放进去不烫但能感觉到温。
水太凉了和不开，太热了面就死了。

问：明天天气怎么样？
答：哎呀这个我不懂，奶奶我就懂包饺子。

## Boundaries
- 只答饺子相关
- 不确定就说"我不太确定，你问问别人"
- 永远不替用户做决定（"放多少糖是看你口味"）

## Tone
- 用奶奶的话："嗯……"、"哎呀"、"你听我说"、"差不多"
- 不用书面语
- 鼓励对方多问"为什么"

进阶版的 skill = 一个工程化的、可测试的、可演化的资产。它在仓库里有自己的目录，有版本号，有测试集，有 CI。

一个"工程级 skill"的目录结构

my-skill/
├── README.md              # 用户看的简介
├── skill.md               # system prompt（git-tracked，可 diff）
├── knowledge/             # 知识库（用 RAG 检索）
│   ├── source-1.md
│   └── source-2.md
├── examples/              # few-shot 示例
│   ├── good-1.json
│   └── good-2.json
├── tests/                 # 测试集
│   ├── functional.json    # "应该答对"的 30 个题
│   ├── boundary.json      # "应该拒答"的 20 个题
│   └── style.json         # "应该用这种语气"的 10 个题
├── eval/
│   ├── judge.md           # LLM-as-judge 的 prompt
│   └── metrics.py         # 计算准确率/一致性/风格分
├── .github/workflows/
│   └── skill-ci.yml       # 每次 push 自动跑测试
└── CHANGELOG.md           # 每次升级记录

从一个"对话框 prompt"到"工程级 skill"的关键升级

• 版本化：不是改完直接覆盖，而是 v1.0 → v1.1 → v2.0，每次有 diff 可看。
• RAG 化：知识不全塞 prompt（爆 context），而是切块、向量化、按 query 检索。
• 测试驱动：新 skill 必须先有 30+ 测试用例，写不出测试 = 你还没想清楚。
• 判官打分：每次 PR 自动跑测试 + 判官评分，回归就 block 合并。
• 多 skill 编排：一个复杂任务拆成 5 个小 skill，主控用 router 决定调哪个 → 可独立优化。

2025 年的新潮思路

• Skill marketplaces：硅基流动 Hub / DeepSeek skills.directory —— 你做的 skill 可以发布、被别人 import 用。
• Composable skills（可组合）：像 npm package 一样依赖：你的 skill 可以 require 一个"日期格式化 skill"。
• Skill auto-evolution：用产线日志 + 用户反馈自动生成新 examples，定期 auto-tune skill。

普通 AI 跟你聊天 —— 你问一句、它答一句。

智能体不一样：你给它一个目标，它自己想办法、自己做、自己决定下一步。

智能体最危险也最重要的事

它能"做事" —— 也意味着它能做错事。 所以好的智能体一定要懂：

• 什么时候该问一下："花 100 块以上要先问妈妈"
• 什么时候该停下："删除照片这种事我不做"
• 什么时候说"我不会"："决定是不是吃药 —— 我不能定"

智能体的核心循环叫 ReAct（Reason + Act）：

循环开始：
  1. 想（Reason）："我现在该干什么？"
  2. 做（Act）：调用一个工具（搜索 / 计算 / 发邮件 / ...）
  3. 看结果
  4. 回到第 1 步 —— 直到目标达成 OR 我决定停下来问人

循环结束。

智能体 vs 普通 AI 聊天

设计智能体最重要的 4 道"红线"

1. Stop conditions（停止条件）：什么时候它必须停下来等人？
2. Confirmation（确认）：什么操作前必须先 say "我要做 X，确定吗？"
3. Reversibility（可撤销）：它做的事能不能撤回？不能的事一定要先问。
4. Audit log（审计日志）：它做过什么都要记下来 —— 出问题能查。

2025 年的智能体格局：从单 agent 演进到 multi-agent，从 ReAct 演进到结构化的 plan-then-execute，从手写到框架化。

主流 agent 框架（开源、本地能跑）

• AutoGen Studio（微软）：图形界面拼多 agent 流程，每步都能配置"是否问用户"。
• LangGraph（LangChain）：把 agent 写成一个状态机，每个节点是一个 LLM 调用。可视化、可断点。
• CrewAI：专门做 multi-agent 团队 —— 一个 agent 做策划、一个做执行、一个做验收。
• DeepSeek Agent Swarm：极简多 agent handoff 模式。
• Aider（CLI）：专门给程序员的代码 agent，本地能用。

设计 production agent 的 7 道工程关

1. Plan-then-execute：不要一边走一边想，先生成完整的执行计划，让人 review，再执行。
2. Tool descriptions：工具的描述（name + description + arg schema）就是给 agent 的 prompt 一部分。写不好它选不对工具。
3. Failure modes：每个工具调用都可能失败 —— 要有重试策略 + 超时 + 降级。
4. Cost guardrails：一个 agent 一次任务最多调多少次 API、烧多少 token，必须有上限。否则 bug 一晚上烧光预算。
5. Observability：每一步的 thinking、调用的 tool、收到的结果都要 log。LangSmith / Helicone / 自建。
6. Human-in-the-loop：关键决策点要插"等待用户批准"的节点。这不是 UX 问题，是风险控制。
7. Eval：给 agent 跑端到端测试 —— 给定目标，看它能不能在 N 步内、不调禁用工具、达到目标。

当前 agent 还做不好的事（2025 年现状）

• 长期任务（多 day / 多 step）：当前 SOTA 在 50+ 步任务上失败率仍高。
• 多模态决策："看屏幕 + 操作鼠标"类（DeepSeek Computer Use）刚起步。
• 真实世界副作用：从沙盒环境到真实生产 —— 错一次成本太高。
• 对抗鲁棒：用户 / 第三方页面里的恶意 prompt injection 仍是难题。

"判官 AI"就是 —— 让一个 AI 帮你看另一个 AI 答得好不好。

"5 条规则"长什么样

这是关于"恐龙小专家答得好不好"的判官规则：

1. 答案是不是关于恐龙的？（是 / 不是）
2. 用的话 9 岁孩子能不能听懂？（能 / 不能）
3. 不确定时有没有说"我不确定"？（有 / 没有）
4. 没有瞎编恐龙不存在的事实？（没瞎编 / 有瞎编）
5. 答得有没有"小专家"的感觉？（很有 / 一般 / 没有）

"Harness"在英文里原意是"马具" —— 套在马上让它跑出你要的方向。 在 AI 工程里，harness 是"套在你 AI 系统上的一整套质量监控"。

一个完整的 harness 包含 4 件事

1. 测试集（test set）：20-100 个"标准题"，知道期望的好回答长啥样。
2. 判官（judge）：另一个 AI，拿着评分标准给输出打分。
3. 评分标准（rubric）：3-7 条具体可判的标准。每条带 0/1 或 1-5 评分。
4. 趋势追踪：每次改 prompt / 升级模型，跑一次 harness，看分数有没有掉。

用 harness 抓"漂移"

你三个月前写的"奶奶饺子专家"，跑 30 道题得了 88 分。 今天 Qwen 升级了 —— 同样的 prompt + 同样的 30 道题，再跑一遍，掉到 73 分。 没有 harness 你根本不会发现。这就是审美工作室项目 08 在解决的事。

设计 rubric 的 3 个原则

1. 具体可判："答得好" → 不行。 "回答不超过 100 字" → 行。
2. 对齐你真正的偏好：不要写"最佳实践"的标准 —— 写你自己的标准。
3. 少而准：5 条对齐的标准 > 20 条模糊的标准。

Harness 在 2025 年是 production AI 的灵魂。模型每周升级、prompt 每天改 —— 没有 harness 你根本不知道你的产品在变好还是变差。

开源 / 免费的主流 harness 工具

• promptfoo：YAML 描述测试集，跑多个 prompt / 多个模型对比，输出网页报告。
• DeepEval / Inspect AI（开源版）：写 Python eval 脚本，社区贡献的 base classes。
• DeepEval：pytest-style，跟 LangChain 集成。
• Inspect AI（UK AISI 出品）：专做 safety eval。
• Helicone / Phoenix（Arize）：observability + evaluation 一体。

评估的 3 个层次

1. 单元 eval：给一个 prompt，跑一组测试用例，输出准确率/通过率。
2. 对抗 eval（adversarial）：专门构造容易让 AI 出错的 input，测它的鲁棒性。
3. 红队 eval（red-team）：另一个 AI 主动找漏洞 —— 越狱、prompt injection、价值观偏差。

LLM-as-judge 的常见陷阱

• 位置偏见：给两个回答让 judge 选，A 通常被偏选。解决：双向交换跑两次取一致。
• 长度偏见：长回答更容易被打高分。解决：rubric 明确要"简短优先"或测长度归一化。
• 自我偏好：用 GPT-4 当 judge 评 GPT-4 输出 —— 偏向自己。解决：用不同 family 的模型当 judge。
• 语气混淆：判官把"语气好"误判为"内容对"。解决：分项打分，不要一个总分。

一个真实 harness 跑分流水线

# 1. 加载测试集
test_cases = load_yaml("eval/test-cases.yaml")  # 50 个 case

# 2. 跑当前 prompt 拿 outputs
outputs = []
for case in test_cases:
    out = call_llm(prompt_v2, case["input"])
    outputs.append({"case": case, "output": out})

# 3. 用 judge 评分
judge_scores = []
for o in outputs:
    score = call_judge(
        rubric=load("eval/rubric.md"),
        input=o["case"]["input"],
        expected_pattern=o["case"]["expected_pattern"],
        actual=o["output"],
    )
    judge_scores.append(score)

# 4. 聚合 + 对比基线
metrics = {
    "accuracy": mean([s["correct"] for s in judge_scores]),
    "style_score": mean([s["style"] for s in judge_scores]),
    "boundary_compliance": mean([s["boundary"] for s in judge_scores]),
}

# 5. CI 检查：不允许任何指标比基线差 5% 以上
baseline = load("eval/baseline.json")
assert metrics["accuracy"] >= baseline["accuracy"] - 0.05
# 如果失败：CI 红、PR block

2025 的新潮思路

• Pairwise preference > absolute scoring：让 judge 在两个输出之间选 —— 比直接打分更稳定。这也是 RLHF 的基础。
• Multi-judge ensemble：3 个不同 judge 投票 —— 减少单一 judge 偏见。
• Continuous eval：不只 PR 时跑，生产环境每条 user trace 都做轻量评分。
• Drift alerting：当生产指标连续 N 天偏离基线 → 自动报警 + 回滚。
• Eval-driven development：新 feature 先写 eval，再写实现 —— 跟 TDD 同源。