当AI遇上需求工程师：一场关于“如何正确和机器人聊天”的奇幻冒险

🌟 前言：为什么需求工程界突然开始集体“练嘴”了？

想象一下，你正站在一个巨大的魔法图书馆里，四周全是会说话的书。这些书就是今天的主角——大型语言模型（LLM）。它们能瞬间写出诗、代码、甚至一整份需求文档。但问题来了：你随口说一句“帮我写个登录功能”，它可能给你整个宇宙飞船的登录系统，也可能给你一个古代辂轪车的登录方式……
这就是2025年的真实写照：我们终于有了超级聪明的人工智能助手，却发现最难的不是让它变聪明，而是让它听懂我们在说什么。
于是，一门新武林绝学横空出世——Prompt Engineering（提示工程），中文直译就是“怎么跟AI正确说话的艺术”。而需求工程（Requirements Engineering，简称RE），作为软件项目成败的命门，正成为这门绝学的最大试验场。

🧙‍♂️ 第一章：需求工程师的“哈利波特式”困境

需求工程从来不是一件容易的事。
统计数据残酷得像伏地魔：70%的软件项目失败都源于需求问题。
我们需要从五花八门的利益相关人嘴里掏出真正的需求，把含糊不清的自然语言翻译成机器能懂的精确规格，还要一路追踪变化、验证一致性……这本身就像在跟一群会说人话但永远说半截话的精灵谈判。

现在，LLM出现了。它们承诺：“把脏活累活交给我就行！”
结果呢？
你说：“用户要一个安全的登录。”
它给你写出了一个包含量子加密、虹膜+声纹+脑电波三重验证、还自带反向黑客追踪的登录系统……
恭喜，你的需求膨胀成了“登月计划”。
这就是典型的幻觉（hallucination）——AI最爱干的“脑补”行为。

📊 第二章：科学家们做了什么？他们真的把36条“咒语”拿来试过了！

2025年，一群勇敢的研究者（来自arxiv:2507.03405的那篇神作）决定做一件前无古人的事：
他们把过去7年里所有关于Prompt Engineering的论文挖出来，硬生生整理出了36条通用提示工程指南，然后像炼金术士一样，把这些“咒语”一股脑砸到需求工程的五大核心活动上，看看哪些灵，哪些不灵。

他们还找来了三位身经百战的需求工程大佬进行访谈，相当于请了三位“邓布利多”来评判这些咒语到底能不能在RE界用。

结果如下表（已转化为更可爱的Markdown表格）：

注解：最终统计发现，整整72%的通用提示工程指南都能在需求工程里用得飞起，只有“措辞”和“Few-shot”被专家无情打入冷宫。

🎪 第三章：实战！这五招让你的LLM从“神经病”变成“神队友”

🏆 绝招一：Context is King（上下文为王）

把背景塞满！越多越好！ 坏提示： “写登录需求”

神提示：
“您现在是一位拥有15年经验的金融级系统需求工程师，我们正在开发一款面向欧洲市场的银行App，必须满足GDPR、PSD2、ISO27001要求，用户群体主要是55岁以上不太懂科技的老人，请为登录功能撰写完整需求。”

效果：AI立刻收起了量子加密脑补，开始认真考虑“大字体+语音验证+一键求助亲情号码”。

🏆 绝招二：Persona大法（角色扮演万岁）

让AI戴上面具，它就会进入角色！ “请以最苛刻的安全审计师的身份，逐条审查以下需求，找出所有潜在漏洞。” “请以5岁小孩的视角，告诉我这条需求哪里看不懂。” 专家实测：Persona技巧在验证（Validation） 阶段简直逆天，能瞬间发现成人完全忽略的痛点。

🏆 绝招三：模板狂魔（结构化输出才是正道）

永远！永远！永远不要让AI自由发挥！ 正确模板示例：

请用以下格式输出需求：
**功能名称**：  
**描述**：  
**优先级**：Must Have / Should Have / Could Have / Won't Have  
**验收标准**：
- [ ] 当用户...
- [ ] 系统应...
**非功能需求**：
- 性能：
- 安全：
- 可访问性：

AI收到这种提示后，输出整齐得像被军事训练过。

🏆 绝招四：Disambiguation + Reasoning 连招

先消除歧义，再一步步思考：

“第一步：请逐字阅读以下需求，列出所有模糊词汇或短语。
第二步：对每个模糊项提出至少3种可能解释。
第三步：根据我们之前提供的业务背景，选出最合理的解释并改写需求。”

这套连招在分析（Analysis） 阶段无敌，能把90%的歧义扼杀在摇篮里。

🏆 绝招五：永远别信AI的“验证”结果（专家警告）

访谈中三位大佬异口同声： “让LLM自己验证自己生成的需求？这是灾难！” 原因：幻觉 + 不确定性 + 自我一致性幻觉（它会自信满满地告诉你错误的需求其实是对的）。

🎭 第四章：真实世界在怎么玩？（来自X平台的偷窥报告）

• 某独角兽产品经理公开分享：他用“Context + Persona + Template”三连，直接让Claude写出了比整个团队 brainstorm 还完整的100+边缘案例。
• 某银行需求团队开发了内部“Prompt库”，里面有200+经过验证的黄金提示词，新人复制粘贴即可起飞。
• 招聘网站数据：2025年“Prompt Engineer”职位薪资已与“高级需求工程师”齐平，很多JD直接写着“会写RE专用Prompt = 年薪+50%”。

🚧 第五章：科学家们诚实的警告——这玩意儿还没完全好使

1. 大多数指南在文献里只出现过一次，共识度极低
2. LLM输出仍然不稳定，同一提示跑10次可能有3次幻觉
3. 复杂验证任务目前仍是禁区
4. 过度依赖模板可能会扼杀创造力（专家原话：“我们不是在写流水线需求”）

🛤️ 第六章：未来的路——我们需要“需求工程专属提示工程”

研究者们已经开始行动：

• 有人在尝试用RAG（检索增强生成）把公司历史需求库塞给LLM，彻底根治幻觉
• 有人在fine-tune小型模型专门做“需求歧义检测器”
• 还有人提出“两阶段提示”：先让AI生成，再让另一个AI专门挑刺

🏆 终章：写给每一个正在和AI聊需求的人

记住这五条黄金法则，你就能从“被AI牵着鼻子走”变成“牵着AI鼻子走”：

1. 永远给足够多的Context，越详细越好
2. 永远给AI一个明确的Persona
3. 永远用模板锁死输出结构
4. 永远要求“先找歧义，再一步步思考”
5. 永远！永远！不要让AI自己验证自己！

当你掌握了这些，你就不再是一个普通的需求工程师， 你将成为——Prompt Master：需求界的人工智能驯兽师。

---

参考文献

1. Ezzini, S., et al. (2025). Prompt Engineering Guidelines for Using Large Language Models in Requirements Engineering. arXiv:2507.03405
2. Prompt Engineering Guide. https://www.promptingguide.ai/
3. Zhao, L., et al. (2025). Research directions for using LLM in software requirement engineering: a systematic review. Frontiers in Computer Science.
4. Li, Y., et al. (2024). Evaluating Large Language Models for the Automated Generation of Software Requirements. Springer.
5. Pimentel, J., et al. (2025). Formal requirements engineering and large language models: A two-way roadmap. Information and Software Technology.