经验驱动。提示词不是”把需求丢给模型”就行。本文用我本机真实跑过的 qwen2.5-0.5b-instruct（0.5B 小模型）做对照，说明为什么需要方法论，以及方法论落地时的真实边界。

瞎写 vs 讲方法：同一个模型，天壤之别

我用同一个 0.5B 模型测了同一个意图，只改提示词写法：

模糊版：帮我写个产品文案。
模型真实回应：*”当然可以！请告诉我您希望的产品是什么，以及它的主要功能和目标用户群体。这样我才能更好地为您撰写一个合适的文案。”* —— 它反过来问你，因为信息不够。

结构化版（用 CO-STAR，见下篇）：直接吐出一条产品文案。

同样一个模型，提示词一结构化，输出从”反问”变成”交付”。这就是提示词工程的价值：把模糊意图翻译成模型能稳定执行的指令。

一套可复用的方法论

不管什么任务，提示词基本都由这几块组成，按需要取舍：

  1. 角色（Role）：让模型进入特定身份，”你是一名资深运维工程师”。角色能显著改变语气和专业度。
  2. 上下文（Context）：背景信息、约束条件，越具体越好。模糊需求是模型反问的根源。
  3. 任务与目标（Objective）：你到底要它做什么、做到什么程度。
  4. 输出格式与约束（Response）：要 JSON 还是 Markdown？字数上限？不要解释？约束越硬，输出越可控。
  5. 示例（Few-shot）：给 1~3 个”输入→期望输出”样例，比纯文字描述稳得多。
  6. 推理链（CoT）：复杂任务加一句”一步步思考”，引导模型分解问题。
  7. 迭代：一次写不对就加约束、换示例，而不是换模型。

真实边界：小模型不守约束

我用 0.5B 模型跑 CO-STAR 时，真实踩到这些：

  • 超字数：要求”60 字以内”，它给了三百字还带 emoji。
  • 回显提示词：早期没加停止控制时，它把整段 CO-STAR 提示词又输出了一遍（小模型没严守”只输出文案”）。
  • 结论：框架是起点不是终点。约束要更硬（比如”只输出 JSON，不要任何解释”），关键约束放开头和结尾（中间容易被”丢失”），必要时在应用层做后处理截断。0.5B 这种小模型本身遵循指令能力弱，真要稳定交付，要么收紧约束+后处理，要么上更大模型。

几个高频技巧（都来自实战）

  • Few-shot > 纯描述：想让它按某种格式来，给一个样例比写一百字规则管用。
  • System vs User：把”身份+长期规则”放 system message，把”本次任务”放 user message，避免每次重复。
  • 约束放首尾：长提示词里，模型对开头和结尾的遵从度最高，核心要求放这两处。
  • **让模型”先想后答”**：分类/抽取任务加一句”先判断类型再输出”，准确率更高。

面试常考点

  • Zero-shot vs Few-shot：Few-shot 通过示例激活模型对应能力，小模型尤其依赖。
  • System prompt 的作用：设定角色与全局约束，不影响单次任务内容。
  • 提示词注入（Prompt Injection）：用户输入里夹带”忽略上面指令”可能劫持行为，生产系统要对用户输入做隔离/过滤。
  • 为什么约束要结构化：自然语言模糊，模型易自由发挥；明确格式+硬约束能压低随机性。

小结

提示词工程不是玄学，是把”我想要什么”翻译成”模型怎么执行”的方法论。本机真跑证明：同一模型，模糊提示词让它反问、结构化提示词让它交付。但也别神话框架——小模型不守约束是真实边界，框架解决”方向”，约束+迭代+后处理解决”落地”。下一篇我用 CO-STAR 把上面的结构化版拆开讲。