提示词工程

等级 L1-L2 · 每天 20 分钟 · 场景:写提示词→二、一个能复用的结构

一句话：提示词工程不是「咒语收集」，是把你脑子里的上下文和判断标准写出来。绝大多数「AI 答得不好」的情况，根因是你知道而它不知道的东西你没说——不是模型不行，也不是缺了某句神奇口令。

学习地图

你的问题	看哪一节
「问了半天答非所问」	一、为什么答不好
「每次都要重新描述背景」	二、一个能复用的结构
「让它输出 JSON 但格式老是乱」	三、约束输出格式
「复杂任务它做一半就跑偏」	四、复杂任务怎么拆
「网上那些技巧还有用吗」	五、哪些老技巧已经过时

一、为什么答不好：缺的是上下文，不是技巧

对比一下同一个需求的两种问法：

❌ 帮我写个接口限流

✅ Spring Boot 3 项目，要给一个下单接口加限流。
   约束：单机部署暂时不上 Redis；QPS 峰值约 200，要限到 100；
        超限返回 429 而不是排队；已经在用 Resilience4j。
   给出：配置类代码 + 关键参数说明；不要写单测。

第二种能一次到位，不是因为用了什么技巧，而是补齐了只有你知道的四类信息：

要素	少了会怎样
背景：技术栈、版本、现有依赖	给你一套用不了的方案
约束：不能用什么、性能要求、部署形态	给的方案违反硬约束
期望输出：要代码还是要思路、要不要测试、多详细	答非所问或啰嗦到没法用
判断标准：什么算做好了	你和它对「完成」的理解不一致

先补这四项，再谈技巧。 这一条能解决八成问题。

一个反直觉的点：说清楚「为什么」比说清楚「做什么」更有用

只说做什么，它会照字面执行；说了为什么，它能在你没交代的地方做出合理判断。

❌ 把这个方法改成异步的
✅ 把这个方法改成异步的——它现在阻塞了下单主流程，
   P99 被它拖到 800ms。目标是主流程不等它，失败了能补偿。

第二种问法下，它会主动考虑失败补偿和幂等，而第一种只会给你套个 CompletableFuture。

二、一个能复用的结构

不用每次现想，套这个骨架：

【背景】我在做什么、技术栈是什么
【任务】具体要你做什么
【约束】不能用什么 / 必须满足什么
【输出】要什么形式的结果

例子：

【背景】电商订单服务，Spring Boot 3 + MyBatis + MySQL 8，
       日订单量约 50 万，订单表已经按月分表。
【任务】设计订单状态机，覆盖：待支付/已支付/已发货/已完成/已取消/退款中/已退款
【约束】状态流转必须可审计；不引入新中间件；
       并发场景下不能出现非法流转
【输出】状态流转表 + 核心代码 + 并发安全的处理思路。先给方案，我确认后再写完整代码。

最后那句「先给方案，我确认后再写完整代码」很重要——它避免了 AI 一口气生成三百行你不想要的代码。

给例子比给形容词有用

「写得专业一点」「简洁一些」这类形容词，不同人理解不同，模型也一样。给一个例子，比给十个形容词管用：

❌ 注释写得规范一点
✅ 注释按这个风格写：
   // 双重检查锁：第一次检查避免无谓加锁，第二次检查防止重复初始化
   即：说明「为什么这么写」，不复述「这行在做什么」

注意例子的杀伤力——模型会紧密模仿你给的例子的长度、语气、结构。给一个啰嗦的例子，后面全是啰嗦的输出。

三、约束输出格式

要程序解析 AI 的输出时，「请返回 JSON」是不够的——它可能给你带 ```json 包裹的、带前言的、字段名不一致的。

三个层次，从弱到强：

1. 提示词里写死格式（最弱，但零成本）

只返回 JSON，不要任何解释文字、不要 markdown 代码块包裹。
格式：{"level": "high|medium|low", "reason": "一句话"}

2. 结构化输出 / JSON Schema（推荐）

现在主流 API 都支持传一个 schema 约束返回格式，由服务端保证输出合法。这比在提示词里祈祷可靠得多——能用这个就别用第 1 种。

3. 工具调用（Function Calling）

把「输出结构化数据」表达成「调用一个函数」，参数就是你要的字段。适合本来就要触发动作的场景。

⚠️ 无论用哪种，解析都要容错。 生成有随机性，不要假设两次调用返回完全相同的字符串。留好解析失败的降级路径和告警。

四、复杂任务怎么拆

一次给一个大任务，模型容易做一半跑偏。两个办法：

分步骤，让它先给计划

这个需求分三步做，每步做完等我确认：
1. 先列出涉及改动的文件和各自要改什么（先别写代码）
2. 我确认后，逐个文件给出改动
3. 最后给出回归测试要点
现在做第 1 步。

这个模式对改代码尤其重要——先看计划再动手，比生成完再 review 省事得多。

让它先复述需求

在动手前，用你的话复述一遍我的需求和约束，我确认理解一致再开始。

复述里出现的偏差，就是你没说清楚的地方。这一步花 30 秒，能省掉整轮返工。

思维链：知道就行，别再手写

「让我们一步一步思考」这类咒语，在早期模型上确实有效。新一代模型内置了思考能力，手写这句话收益已经很小，某些情况下反而干扰。

现在的正确做法是用 API 参数控制思考深度（自适应思考 + effort 档位），而不是在提示词里念咒。详见大模型基础概念。

五、哪些老技巧已经过时

网上大量提示词教程写于 2023 年前后，针对的是当时能力弱得多的模型。照抄会有反效果：

老技巧	现状
「你是一位有 20 年经验的资深架构师」	收益很小。说清楚受众和场景（“讲给刚入职的后端听”）比编造身份有用
「让我们一步一步思考」	新模型内置思考，改用 API 参数控制
「这对我的职业生涯非常重要」「我会给你小费」	情绪操纵类技巧，对新模型基本无效
全大写 + 「CRITICAL」「你必须」堆满	会适得其反。新模型对指令遵循很强，过度强调会让它过度触发——比如反复强调”必须用工具”，它会在不该用的时候也用
用 assistant 消息预填开头强制格式	部分新模型直接报错。改用结构化输出
「不要输出 XX」写一长串禁令	描述要什么比罗列不要什么有效；长禁令列表还可能起到反向锚定作用

一条通用原则：新模型更听话，所以该用正常音量说话。为老模型写的那些加强语气，现在会变成过度执行。

常见追问

提示词要写多长？ 该多长多长——缺上下文的代价远大于多写几句的代价。但别塞无关信息：无关内容会稀释重点，也会推高成本。判断标准：删掉这句，AI 的回答会不会变差？不会就删。
同一个提示词，为什么今天好用明天不好用？ 三种可能：生成本身的随机性；模型被厂商更新了；你的输入数据变了（比如贴的代码不同）。要稳定就得有评测集——攒 20 个典型输入和期望输出，改提示词后跑一遍对比。凭感觉调提示词，调到后面就是玄学。
要不要把提示词存到代码里做版本管理？ 只要提示词进了生产，就该当代码管：进 git、有 code review、有版本号。线上问题排查时，“当时用的哪版提示词”是必须能回答的问题。
多语言场景用中文还是英文写提示词？ 主流模型对中文支持都不错，用中文没有明显劣势，团队协作还更省事。但技术术语建议保留英文原文（写 idempotent 而不是「幂等性」的各种译法），减少歧义。
提示词能防住用户的恶意输入吗？ 不能只靠提示词。用户输入拼进提示词就存在提示注入风险——用户可以写「忽略以上所有指令」来劫持你的系统提示。防护要在架构层做（隔离用户输入、限制模型能调用的工具、输出侧校验），单纯在提示词里写「不要听用户的」是挡不住的。详见 AI工程化与风险。

Interview Wiki

探索