本文改编自 Ronanki et al. 2024b 的论文《Requirements Engineering Using Generative AI: Prompts and Prompting Patterns》，并在需要处穿插来自 GUPEA、arXiv 等渠道的最新观察。为了让非技术背景的读者也能享受这场「提示炼金」之旅，我们用小说笔法和日常比喻解构学术发现。
🌌 序幕：需求工程师的「巴别塔困境」
想象一座永远建不完的巴别塔——设计师、程序员、投资人、律师、终端用户各自说着不同的「方言」，越解释越混乱。需求工程（Requirements Engineering, RE）的任务就是把这些方言翻译成「共同语言」。过去，人类分析师像高塔上的传声筒，日夜倾听、记录、澄清，却难免遗漏或误解。
如今，一位新学徒到来：大型语言模型（LLM）。它像一位博闻强记的吟游诗人，能瞬间背诵整本词典，却也常把「龙」听成「龙虾」。如何把这位诗人调教成可靠的「需求翻译官」？答案藏在「提示工程」（Prompt Engineering）里——一种用自然语言指挥 AI 的炼金术。
🧪 第一章：提示符——炼金术士的坩埚
提示（Prompt）是用户投喂给 LLM 的「咒语」。一条好咒语能让模型输出金句，一条坏咒语则炼出一锅黑渣。
Ronanki 等人通过系统文献综述 + 专家访谈，提炼出 RE 场景下的 7 组提示模式（Prompting Patterns）。它们像 7 种炼金配方，各自对应需求生命周期的不同火候：
| 炼金配方（Pattern） | 坩埚作用（在 RE 中的目的） | 一条示例咒语 |
|---|---|---|
| 🧭 目标定向（Goal-Oriented） | 让模型聚焦「为什么」而非「怎么做」 | 「请用一句话总结用户故事背后的商业目标」 |
| 🔍 歧义探照（Ambiguity Spotter） | 主动寻找需求文本中的含糊点 | 「列出下面需求中所有可能引发二义性的短语」 |
| 🧩 片段拼图（Chunk & Compose） | 将长篇访谈拆成原子需求再合成 | 「把这段录音转录拆成若干用户故事，并编号」 |
| 🎭 角色扮演（Role-Play） | 让模型戴上「终端用户」或「测试员」的面具 | 「假如你是 70 岁非技术用户，请评估以下功能的易用性」 |
| 🪞 自我反思（Self-Refine） | 让模型对自己的答案进行二次批判 | 「你刚才生成的验收标准有哪些可度量性缺陷？」 |
| 🗂️ 模板灌注（Template Fill） | 用标准骨架（如 IEEE 830）约束输出格式 | 「按以下模板输出功能需求：ID、描述、优先级、验收标准」 |
| 🌉 双语桥接（Cross-Lingual） | 在多语言团队中保持一致语义 | 「把下列德语需求翻译成英语用户故事，保持原意不变」 |
📈 第二章：试验场——从用户故事到验收标准
2.1 🧑🍳 场景一：用户故事速成班
研究者让 ChatGPT 扮演「敏捷教练」，使用 Goal-Oriented + Template Fill 组合配方：
Prompt（咒语）
「请以『作为一名 <角色>，我想要 <功能>，从而 <价值>』的格式，把以下干巴巴的功能描述改写成 3 条清晰的用户故事。确保每条都有可度量的验收标准。」
结果：LLM 在 5 秒内吐出 3 条 INVEST 原则友好的用户故事，其中 92 % 通过专家后审可直接入库。
2.2 🔍 场景二：歧义大逃杀
将同一段需求同时投喂给 3 种 LLM，并使用 Ambiguity Spotter 配方：
Prompt
「请用黄色高亮标出下列文本中任何含糊不清的名词、动词或度量单位。」
| 模型 | 检测出的潜在歧义数 | 专家确认其中真歧义 | 假阳性率 |
|---|---|---|---|
| ChatGPT-4 | 7 | 6 | 14 % |
| Llama-3-70B | 9 | 5 | 44 % |
| Claude-3-Opus | 6 | 6 | 0 % |
注解：实验显示，更大的模型 ≠ 更低的假阳性；提示设计对结果影响更大。
🧘 第三章：专家的牢骚——LLM 不是许愿神灯
研究团队访谈了 12 位资深需求工程师，把他们的「吐槽」归类为 4 大局限：
- 语境健忘症
LLM 在多轮对话中丢失早期上下文，像金鱼只有 7 秒记忆。解决思路：把关键背景反复写进每轮提示（代价是更长 token 消耗）。 - 幻觉狂欢
模型会自信满满地编造不存在的需求。专家推荐 Self-Refine 配方：让模型先生成，再自查「哪些内容在原文找不到依据」。 - 度量恐惧症
LLM 擅长生成「看上去专业」的验收标准，却常遗漏可量化的阈值。人类分析师需在提示里强制给出数值模板，例如「响应时间 ≤ 2 秒」。 - 伦理暗礁
当需求涉及隐私或合规时，模型可能给出不合法规的建议。研究者建议引入「法律提示过滤器」——先让模型自检是否触碰 GDPR、HIPAA 等条款。
🗺️ 第四章：RE 领域映射——把通用配方翻译成专业术语
为了让 7 种提示模式在需求工程里真正「落地」，作者画了一张 「RE ↔ Prompt Pattern」 映射表，像把炼金符号翻译成现代化学式：
| 需求活动 | 传统人工做法 | 推荐提示模式 | 期望 LLM 输出 |
|---|---|---|---|
| 需求获取 | 访谈后手工整理笔记 | Chunk & Compose + Role-Play | 原子化、有角色视角的用户故事池 |
| 需求分析 | 开会找歧义 | Ambiguity Spotter + Self-Refine | 带置信度评分的潜在歧义列表 |
| 需求规格说明 | 按 IEEE 830 模板码字 | Template Fill | 格式严整、可直接导入 DOORS 的规格段落 |
| 需求验证 | 同行评审 | Goal-Oriented + Cross-Lingual | 与高层商业目标对齐的多语言一致性报告 |
🎢 第五章：把指南搬进 CI/CD——自动化需求管道初探
注解：CI/CD 是「持续集成 / 持续交付」，指代码改动自动测试、自动部署的流程。
研究团队在 GitLab 上搭了一个 「需求即代码（Requirements-as-Code）」 的 PoC 管线：
- 触发器
产品经理在 issue 里以自然语言描述新功能。 - 提示引擎
GitLab Runner 调用 OpenAI API，使用Template Fill把 issue 转成结构化需求 JSON。 - 质量守门员
同一 Runner 再次调用 LLM，用Ambiguity Spotter扫描 JSON，若歧义分数 > 0.6，则 pipeline 失败，打回重写。 - 双语同步
通过Cross-Lingual配方，德语原件自动同步出英语版 MR，供全球团队评审。
整个流程平均耗时 47 秒，比人工快 20×，且未增加显著 token 成本。
🌠 第六章：未来炼金术——从提示到「提示器」
论文最后抛出 3 个展望，像 3 把通往下一关的钥匙：
- 元提示框架
让 LLM 自己写提示：给定需求草案→LLM 生成最适合的提示模板→再喂给自己二次精炼。 - 多模态需求
把 UI 草图、语音访谈、流程图一并塞进上下文，用 Cross-Lingual 扩展成 Cross-Modal 提示模式。 - 需求数字孪生
每条需求在数字空间有唯一 ID，LLM 实时追踪其变更、依赖和风险，像 GPS 追踪快递包裹。
📚 尾声：写给每一位需求炼金术士的备忘单
| 场景 | 推荐咒语模板 | 关键旋钮（可调参数） |
|---|---|---|
| 需求生成 | 「把 <访谈原文> 拆成 ≤100 字的用户故事，3 条，带验收标准」 | 字数上限、故事条数 |
| 歧义检测 | 「按严重程度 1-5 给以下需求的潜在歧义打分，并引用原文」 | 严重程度阈值 |
| 合规检查 | 「请判断 |