1. 为什么大模型总是“胡乱输出”？

很多人都有类似经历：
明明费尽心思写了一个自认为完美的提示词（Prompt），结果 AI 输出：

不准确
不稳定
风格不一致
甚至彻底“跑偏”

即使套用了大量技巧：“请充当…”、“请用正式语气…”，结果仍然不稳定。
根本原因是：我们把提示词当成一个孤立的句子，而不是一个工程系统。
随着模型能力增强，这个问题反而更明显：

模型更强 → 生成空间更大 → 更容易“想多了”
模型参数更多 → Prompt 投机性更强
模型更会联想 → 模糊输入会被自动脑补 → 输出更不可控
结论：
不是写得更漂亮，而是写得更“可控、可复现、可管理”。

2. 为什么大模型会跑偏？（来自 Google Prompt Engineering 2025 白皮书）

Google 《Prompt Engineering》https://www.promptingguide.ai/zh
白皮书里有一句非常核心的技术结论：

LLM 的本质是：基于输入上下文 + 之前生成的 token，预测最可能的下一个 token。

这句话衍生出三个重要事实：

事实 1：模型不会“理解你的意图”，只会做“最可能预测”

你问得不明确，模型就会从训练数据中猜，并且这种猜测与你真实需求无关。

事实 2：Prompt 的作用 = 控制“输入空间

你给的信息越少，模型越会自由发挥。
你把任务结构化，模型就会按轨道行驶。

事实 3：配置参数 = Prompt 文本一样重要

白皮书整整一章讲 Sampling 参数：

参数	作用	错配后果	测试推荐值	结论
Temperature	随机性	输出不一致	0.1 ~ 0.3	测试不需要创意
Top-p	候选词空间	发散	0.7 ~ 0.85	限制极端 token
Presence Penalty(存在惩罚)	引入新话题	字段名被换	0（必须）	测试禁用
Frequency Penalty(频率惩罚)	减少重复	key 被“优化”	0 ~ 0.3（推荐 0）	不要惩罚字段
Max Tokens	最大输出	JSON 截断	≥ 字段数 × 200	不够必失败

Prompt 写得再好，温度错了也没用。
Prompt 工程本质 = Prompt 文本 + 配置工程

3. 实战框架：五段式 Prompt 工程模型（真正可落地）

比 COSTAR 或 PRIMO 更适合执行任务的结构：

Role → Goal → Input → Process → Output

① Role：给模型一个稳定人格

示例：

你是一名资深测试开发工程师，擅长用结构化方式分析需求和输出测试步骤。

角色一旦固定，模型的语言风格与行为会稳定非常多。

② Goal：明确这次任务的最终目标（必须量化）

坏例子：

帮我写一下测试用例。

问题：

没有范围
没有输入材料
没有格式要求
不可量化，模型无法判断输出完成条件
容易跑偏（写成测试理论 / 无关内容）

好例子：
目标：基于提供的需求文档内容生成。每条测试用例必须包含以下字段：

用例标题（必填）：必须清晰反映测试点
前置条件（必填）：环境/用户状态必须具体可执行
测试步骤（必填）：动作需拆分为可执行步骤，数量 ≥ 3
预期结果（必填）：必须量化，如页面展示字段、DB 字段变化、接口输入输出
优先级（必填）：P1 P2 P3
适用版本（必填）：如 v5.2.8
备注（可选）：补充测试数据或接口说明

产出要求：

最少生成 8 条以上 测试用例
输出格式严格遵守 JSON 数组格式，可被自动化脚本解析
不得输出解释性文案

对应的 Prompt Goal（可直接复制使用）

目标：基于输入的业务需求文档，生成可导入 TestLink 的完整测试用例集。
每条用例必须包含字段：
- title（必填）
- preconditions（必填）
- steps（必填，步骤数量 ≥ 3）
- expected_result（必填，必须可被验证、可量化）
- priority（必填：P1/P2/P3）
- version（必填）
- remark（可选）

产出要求：
- 至少输出 8 条测试用例
- 严格以 JSON 数组格式输出
- 禁止输出任何解释性内容

③ Input：告诉模型“你要处理的原始材料”

一定要显式包裹内容：

以下是原始材料：
———
（内容）
———

④ Process：给模型步骤，让它按流程执行

非常关键！

请按以下流程执行：
1. 阅读输入内容
2. 提取关键实体（需求、角色、接口）
3. 生成结构化测试点
4. 输出为 JSON

白皮书强调：

LLM 不擅长一次性完成复杂任务，拆步骤效果显著更好。

⑤ Output：必须明确格式（最好给示例）

最稳定方式：JSON、表格、明确结构。

请严格按以下 JSON 结构输出：
{
  
}
禁止添加任何额外说明。

4. JSON 输出为什么最稳？如何写得更稳？

JSON = 限制模型自由度，使输出结构稳定。

三个技巧让 JSON 输出几乎不会跑偏：

永远给模板
明确禁止输出以外内容
使用强约束词汇（必须、严格、不可缺失）

示例：

请严格输出 JSON。字段不可缺失，不得添加注释或额外文本。

5. Prompt 工程的关键：上下文（Context Engineering）

Prompt 只是“命令”。
真正影响模型表现的是“上下文”（Context）：

任务背景（Background）
输入材料（Input）
历史对话（Memory）
规则 & 限制（Rules）
示例（Few-shot Example）
环境信息（API Schema / 数据结构）

一句话：

Prompt 不如 Context
Context 不如 Example（示例最强）

6. 实战示例：从劣质 Prompt 到工程化 Prompt

❌ 劣质 Prompt

帮我编写自动化测试用例

完全不可能稳定。

✅ 工程化 Prompt（五段式）

Role:
你是一名金融行业测试专家，擅长从输入内容中识别测试点与边界场景。

Goal:
从输入需求中提取完整的功能测试用例，结构化输出。

Input:
（放需求）

Process:
## Rules
- 必须确保输出的JSON格式正确无误。

## Workflow
1.接收用户输入，提取测试计划ID和测试用例场景，分析用户意图

## 用户意图列表
1. 生成自动化工具（auto_tool）
2. 其它（other）



Output:
请严格输出 JSON：
{
  
}

跑一次就能看到巨大差异。

7. Prompt 版本管理（Versioning）——团队落地的关键能力

随着提示词变多，问题出现：

版本混乱：团队不知道哪个 Prompt 是最新版
不可复现：今天生成正常，明天又乱了
无法协作：不同人写 Prompt 风格不同
无法回溯：不知道为什么某次结果更好

因此，Prompt 必须“工程化版本管理”。

⭐ 推荐团队采用的 Prompt 版本管理体系

1) Prompt 文件化（强烈建议）

一个 Prompt = 一个独立文件，例如：

/prompts/
   test_case_generator/
      v1.0.mdc
      v1.1.mdc
      change_log.md

2) 使用语义化版本（SemVer）

例：

v1.0.0（初始上线）
v1.1.0（新增异常流程逻辑）

- v2.0.0（结构升级，JSON 重构）

3) 给 Prompt 配 changelog

示例 CHANGELOG.md：

## v1.2.0 - 2024-10-03
- 新增异常流程识别步骤
- 修复部分场景下 summary 字段过长的问题
- 增强 JSON 校验规则

4) 使用评价指标（Metrics）回归验证

自动优化前后，需保留以下指标：

相关性（Relevance）
正确率（Accuracy）
一致性（Consistency）
响应长度（Length Control）
结构完整性（Structure Integrity）

用于对比不同版本输出质量。

5) 在 AI 工作流中加入 Prompt 版本号

避免因缓存导致模型输出变化：

使用 Prompt Version: v1.5.0

Prompt Versioning 的价值

可追踪
可度量
可协作
可回溯
可持续优化

这比“写一个好 Prompt”更关键。

Prompt工程