是否先完成需求澄清与计划文档
1️⃣ 考察意图
面试官想看你是否具备“工程化思维”，而非只会写代码。这道题表面是问流程，实则考察：在 Agent 开发这种高不确定性场景下，你如何平衡“快速迭代”与“避免返工”。刁钻点在于：很多人会直接回答“必须写文档”，但忽略了 Agent 项目需求天然模糊（用户意图不可穷举、工具调用边界动态变化）。答好了能展示：需求管理能力、风险预判、以及用文档驱动团队对齐的软技能，这是 P7+ 候选人的硬门槛。
2️⃣ 标准答
核心结论：必须完成，但形式要轻量、迭代式，而非传统瀑布式文档。
为什么不能跳过？
- Agent 开发的高不确定性：用户意图可能超出预设范围（如客服 Agent 突然被问“帮我订机票”），没有需求澄清会导致工具调用边界模糊，最终模型幻觉率飙升。
- 范围蔓延的代价：一个典型 RAG 项目，若未定义 FAQ 覆盖范围，后期可能被要求支持多轮对话、情感分析，导致架构重写。据【通用知识】，无计划的项目返工成本占总开发时间 40%-60%。
怎么做？三步法
- 需求澄清：聚焦“用户意图-工具-边界”三角
- 用户意图分类：用 5W1H 法（Who/What/When/Where/Why/How）穷举高频场景。例如客服 Agent，列出“查订单状态”“退换货”“投诉”等 10 个核心意图。
- 工具调用边界：明确 Agent 能调用的 API（如订单系统、库存系统），并标注“不可调用”的敏感接口（如用户密码修改）。坑：忽略边界会导致 Agent 在模糊意图下调用错误 API，引发安全风险。解法：在 prompt 中硬编码“拒绝列表”，并用规则引擎兜底。
- 优先级排序：用 MoSCoW 法（Must/Should/Could/Won't）区分。例如 Must 是意图识别准确率 > 90%，Should 是延迟 < 2s。
- 计划文档：轻量级“一页纸”
- 里程碑定义：分 3 个阶段——Phase 1（意图识别 + 检索，2 周）、Phase 2（生成 + 验证，2 周）、Phase 3（边界 case 打磨，1 周）。
- 任务分解：用 WBS 拆到 2-3 人天粒度。例如 Phase 1 包含：数据标注（5 天）、模型微调（3 天）、检索链路搭建（2 天）。
- 验收标准：量化指标，如“意图识别准确率 > 85%”“检索召回率 > 90%”“端到端延迟 < 3s”。trade-off：指标定太高（如 99%）会导致过度优化，定太低则无法上线。建议用 80/20 法则，先覆盖 80% 高频场景。
- 风险预案：列出 Top 3 风险（如标注数据不足、模型过拟合），并给出回退方案（如用规则引擎兜底）。
- 迭代式更新
- 文档不是一次性产物。每 2 周复盘一次，根据用户反馈调整意图分类和优先级。例如发现“查物流”意图占比从 30% 涨到 60%，则将其从 Should 提升到 Must。
实际落地的坑 + 解法
- 坑：需求澄清时，业务方说“都做”，导致计划文档变成“万能清单”，无法执行。解法：用“成本-收益”矩阵可视化，让业务方在“高收益低成本”和“低收益高成本”之间二选一。
- 坑：计划文档太详细，团队花 1 周写文档，开发时间被压缩。解法：用“一页纸”模板，只包含里程碑、验收标准、风险，不超过 500 字。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，需求澄清必须做，但聚焦‘用户意图-工具-边界’三角，避免范围蔓延；第二，计划文档要轻量级，用一页纸定义里程碑、验收标准和风险预案，而非传统瀑布式；第三，文档要迭代更新，每 2 周复盘一次。总结一句：先完成轻量级澄清和计划，但保持敏捷，用 80/20 法则覆盖核心场景。”
4️⃣ 高频追问 & 应对
追问 1：如果业务方坚持要 2 周上线，没时间写文档怎么办？
用“最小可行文档”策略：只写 3 点——① 核心意图列表（不超过 5 个）；② 验收标准（1-2 个量化指标，如准确率 > 80%）；③ 风险清单（Top 2 风险 + 回退方案）。花 2 小时完成，然后承诺 2 周后根据结果调整。关键：用数据说话，比如“无文档的项目返工率 40%，有文档的降到 10%”，说服业务方。
追问 2：你如何确保需求澄清的结果是准确的？
用“用户故事 + 原型验证”双保险。先写 3-5 个用户故事（如“作为客服，我想让 Agent 自动查订单状态”），然后快速搭建一个最小原型（用 LangChain + 简单 prompt），让业务方试用。坑：业务方可能口头同意，但实际使用后才发现问题。解法：在原型中埋点，收集真实交互数据，对比需求文档，发现偏差后立即调整。
追问 3：计划文档中的验收标准，如何避免被团队“刷指标”？
用“多维度指标”而非单一指标。例如不只看准确率，还要看召回率、延迟、用户满意度。具体做法：定义“综合得分 = 0.4准确率 + 0.3召回率 + 0.2延迟 + 0.1用户反馈”，并设置最低阈值（如综合得分 > 0.8）。同时，在测试集中加入对抗样本（如模糊意图、噪声输入），防止过拟合。
5️⃣ 避坑 · 常见错误答法
- ❌ “必须写详细的 PRD 和计划文档，否则项目会失败。” → ✅ “文档要轻量级，聚焦核心场景和验收标准，避免过度设计。在 Agent 项目中，需求是动态的，文档需要迭代更新。”
- ❌ “需求澄清就是问业务方要什么，然后写下来。” → ✅ “需求澄清要主动引导，用 5W1H 法穷举场景，并用 MoSCoW 法排序。同时，要明确工具调用边界，避免 Agent 越权。”
- ❌ “计划文档写一次就够了，后面按计划执行。” → ✅ “计划文档要每 2 周复盘一次，根据用户反馈和实际数据调整优先级和里程碑。例如发现某个意图占比下降，就降低其优先级。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“需求澄清如何避免检索范围蔓延”切入，举例你如何定义 FAQ 覆盖边界，并用验收标准（如召回率 > 90%）驱动开发。
- 如果你只做过传统 NLP：用“传统 NLP 项目的需求管理”类比，比如意图分类项目如何定义标签体系，然后迁移到 Agent 场景，强调“工具调用边界”是新挑战。
- 如果你是校招无项目：聚焦“最小可行文档”概念，用论文《Agile Requirements Engineering》中的案例，说明在不确定性高的场景下如何用轻量级文档驱动迭代。
- 《User Stories Applied: For Agile Software Development》—— Mike Cohn 的用户故事实践
- 《The Lean Startup》—— Eric Ries 的最小可行产品（MVP）方法论
- 《Requirements Engineering for Software Product Lines》—— Klaus Pohl 的需求工程框架
- 《Agile Estimating and Planning》—— Mike Cohn 的敏捷计划技术
- 《Building LLM-Powered Agents: A Practical Guide》—— 关于 Agent 开发中需求管理的博客系列