人机融合式软件开发系列 · 2 / 6 · 需求工程
需求工程：AI 加速但受限于可解释性
需求工程（RE，Requirements Engineering）是人机融合起步最慢的阶段——AI（Artificial Intelligence，人工智能）在 backlog / tender / 理解 / 文档 4 类用例上已成熟，但 988 篇 LLM4SE（LLM for Software Engineering，大语言模型用于软件工程）综述显示，RE 占整体研究 <10%。 关键问题：可解释性即采用壁垒——受监管行业仅 16.1% 组织把 AI 推进到试点之外。本页讲清 4 类用例 + 三步 AI 辅助 RE 工作流 + 3 个挑战。
概览
4
AI 用例
15
XITASO 实例
85%
AI vs 专家一致率
16.1%
超试点的组织
第一篇 · 4 类用例 + 三步工作流
第 2 讲 · 4 用例 + 1 流程
4 类高频 AI 用例（Steghöfer 2026）
德国中型企业 XITASO 的纵向研究（内部聊天机器人 + 7 个商用 AI 工具 + 8 位产品负责人 PO）识别出 15 个用例，可归为 4 大类：
4 大类用例
| # | 用例 | 典型场景 | 典型工作流 |
|---|---|---|---|
| 1 | Backlog 管理 | 产品待办列表的整理、归类、补全 | PO 描述模糊意图 → AI 生成条目 → 人修订 |
| 2 | 招投标（tender）管理 | 招标文件初稿、需求抽取、应答辅助 | 历史 tender 输入 → AI 抽取关键约束 → 人补充 |
| 3 | 需求与领域理解 | 跨文档归纳、非结构化文本转结构化 | 用户故事 + 业务文档 → AI 综合 → 人确认 |
| 4 | 文档与制品生成 | 验收标准、用例、规格说明初稿 | 需求条目 → AI 展开为用户故事 + 验收标准 |
关键发现（Steghöfer 2026）：当 AI 接入既有工具链（如通过 MCP 协议接入 Jira）时，时间节省显著；反之如果 AI 工具是孤立的"另一片 UI"，节省时间几乎归零。瓶颈不是工具能力，是工具集成——这跟很多企业的"买 AI = 解决问题"误区相悖。
第 2 讲 · 1 工作流 + 1 评估 + 1 数据
图 1 · Levy 三步 AI 辅助 RE 工作流：AI 初筛 → 人处理 → 人机协同
三步 AI 辅助 RE 工作流（Levy et al. 2026）
Levy 等（2026, arXiv:2604.15222）以 INCOSE "good requirement" 准则（一致性、完整性、清晰性、可测试性）为基准，对比 AI 评估工具与资深系统工程师的判断。
3 步工作流
| 步骤 | 谁做 | 做什么 |
|---|---|---|
| 1 | AI 初筛 | 结构性 / 语法性缺陷识别（一致性、清晰性、可测试性） |
| 2 | 人类处理 | 语境解释 + 业务权衡 + 不可自动化判断 |
| 3 | 人机协同 | 形成可追溯的需求基线与决策记录 |
flowchart LR
subgraph S1["Step 1 · AI 主导"]
A["AI 初筛
结构性 / 语法性缺陷识别
一致性 · 清晰性 · 可测试性"] end subgraph S2["Step 2 · 人主导"] B["人类处理
语境解释 + 业务权衡
不可自动化判断（最后 15% 决策位）"] end subgraph S3["Step 3 · 人机协同"] C["人机协同
形成可追溯的需求基线
与决策记录"] end A --> B --> C
结构性 / 语法性缺陷识别
一致性 · 清晰性 · 可测试性"] end subgraph S2["Step 2 · 人主导"] B["人类处理
语境解释 + 业务权衡
不可自动化判断（最后 15% 决策位）"] end subgraph S3["Step 3 · 人机协同"] C["人机协同
形成可追溯的需求基线
与决策记录"] end A --> B --> C
关键数据：AI vs 专家一致率
- 85% 一致率（Claude 3.5 Sonnet vs 个体工程师，质量准则上）
- 85% 准确率（功能 / 非功能分类）
- 85% 速度提升（同一批需求，AI 秒级，工程师小时级）
对比的关键不是"AI 能不能做"，是"AI 做的对不对得上专家"。85% 一致看似高，但漏掉 15% 在受监管行业（医疗 / 航空 / 金融）= 灾难。人必须永远在"最后 15%"决策位——这跟 §1 的"战略层人类管"完全一致。
第二篇 · 3 个挑战
第 2 讲 · 3 挑战 + 4 数据点
3 个核心挑战（实证数据）
挑战 1 · 可解释性即采用壁垒（IST 2026 调查，N=124）
- 可解释性缺陷 ↔ 验证负担：Spearman ρ = 0.74（强正相关）
- 验证负担 ↔ 信任：ρ = −0.81（强负相关）
- 仅 16.1% 组织把 AI 设计制品生成推进到试点/孤立项目之外
- 受监管领域"高可解释性负担"占 92.5%（非受监管 67.7%）；安全攸关遗漏 57.3% + 合规阻断 48.4% 是常见事故
挑战 2 · 组织滞后（Steghöfer 2026）
- AI 推进速度快于周边组织系统（流程 / 客户 / 团队）
- 收益归集于个别 PO，团队流程成为瓶颈
- 单一用户交互模式甚至可能替代协作对话——开发者未必欢迎 AI 生成制品
挑战 3 · 模型偏见（按任务选模型）
| 模型 | 系统偏差 | 建议用途 |
|---|---|---|
| Claude | 高估非功能属性（质量、安全性） | 适合 NFR 需求抽取 |
| GPT-4 | 偏非功能 | NFR 倾向 |
| Llama | 偏功能 | 功能需求抽取 |
RE 阶段的"未解"问题：可解释性是 AI 设计制品在受监管行业落地的直接元凶——Spearman 0.74 强正相关说明"AI 设计出黑箱需求"几乎必然导致"人类验证重到不愿用"。这道题不只是技术题（更好的 XAI），是组织 + 流程 + 合规的复合题。