L2 · 提示工程

定位：AI 应用工程师的第一门"显学"，也是面试题库的第一分册。核心不是背技巧，而是建立工程化思维：prompt 是代码，不是咒语——可变量化、可版本化、可评测、可迭代。 预计投入：5-7 天（每天 ≤2h），与 S1 demo 同步进行。

面试怎么考这一层

高频，且是初级岗的「第一道分水岭」。典型考法：

• 「怎么保证模型输出的 JSON 格式稳定？」（考你有没有真踩过解析失败的坑）
• 「few-shot 什么时候会失效？」（考理解深度，不是背诵）
• 「prompt 改了之后怎么验证变好了？」（考评测思维，90% 的候选人答不上来）

核心概念清单

概念	一句话
prompt 五要素	角色 / 任务 / 上下文 / 约束 / 输出格式。缺任何一个，输出方差都会变大
few-shot	给 2-5 个输入输出样例。样例的格式一致性比数量重要；样例分布会锚定输出分布
CoT（思维链）	让模型先推理再给结论，提升复杂推理正确率。代价：token 翻倍、延迟变长
结构化输出	JSON mode / response_format / schema 约束。工程上必须配解析失败重试兜底
prompt 变量化	把可变部分抽成模板变量（如 {user_input}），像写函数一样写 prompt
评测集	20-50 条代表性输入 + 预期输出标准。改 prompt 后跑一遍，用数据说话
prompt 注入	用户输入里藏指令（"忽略之前的指令"）。防御：输入隔离、输出校验、权限最小化

学到什么程度算过（自测判据）

1. 能写出一个稳定输出合法 JSON 的 prompt（连跑 20 次无解析失败），并讲清每一部分为什么存在。
2. 有一个自己的 prompt 迭代记录：v1 → v2 → v3，每版改了什么、为什么、效果怎么验证的。
3. 能讲清 CoT 的适用边界：什么任务该用，什么任务用了反而浪费钱。
4. 能给 few-shot 失效举出至少两个具体场景（样例过拟合、任务边界模糊、样例顺序偏差）。

学习路径（5-7 天）

• Day 1-2：按五要素改写 3 个日常 prompt，对比改写前后输出质量，记录观察。
• Day 3-4：攻结构化输出——让一个 prompt 稳定输出指定 schema 的 JSON，故意构造刁钻输入让它失败，加上重试逻辑。
• Day 5：CoT 实验：同一批推理题，直答 vs CoT 各跑一遍，对比正确率和 token 消耗。
• Day 6-7：建一个 20 条的小评测集，把 Day 3-4 的 prompt 迭代一版，用评测集验证提升。

常见误区

• 收藏咒语。网上"神级 prompt"脱离了任务上下文就是废文本；可迁移的是结构，不是措辞。
• 改 prompt 凭感觉。没有评测集的迭代等于闭眼调参——这是面试里最能拉开差距的认知点。
• 过度工程。给"帮我润色一句话"也上五要素模板，是另一种形式主义。复杂度跟着任务风险走。

通往 L3

prompt 能控制输出内容，但模型本身不会"做事"。L3 的 Function Calling 让模型能请求调用你的函数——从"会说"到"会做"的桥梁。