PRD 描述不清楚时，Agent 开发流程如何处理？

核心回答

PRD不清楚时，先把已知目标、关键歧义、可查事实和可逆假设分开。Agent先读现有代码、接口、设计稿和业务资料，能独立确认的内容直接确认；只有影响目标、数据语义、权限或重要行为的歧义才交给相关人决定。不能边猜边扩大实现，也不需要把每个小细节都变成阻塞问题。

主线是：补足上下文 → 聚焦关键问题 → 用例或原型对齐 → 形成足够实施的约定 → 增量实现与验证。流程重量与改动风险相称，简单修改可以边确认边完成独立部分。

先判断缺的是什么

“增加导出”可能缺少导出对象、筛选范围、字段、格式和权限；“提升体验”可能连目标用户和成功标准都不明确。也可能PRD已经写清，只是Agent没找到已有实现，因此要先查项目事实，避免把代码探索问题都转交产品。

将不确定项按影响排序：决定功能含义和架构的条件优先；颜色、局部文案等容易修改的细节，按现有产品模式做合理假设并标明。涉及历史数据兼容、金额口径、跨系统行为等条件，错误成本更高，需要明确依据。

怎样提问和对齐

问题围绕具体分歧及其影响，一次集中少量关键项，给出已有证据与可选方案。例如“导出当前筛选结果还是全部记录？前者与列表一致，后者需要另一个数据范围”，比反复问“你到底想要什么”更容易获得答案。

对交互需求可先给低成本原型；对业务逻辑用正反例、状态变化和输入输出说明。比如“取消后是否能恢复”“重复点击是否产生两条记录”，往往能暴露一句话需求隐藏的条件。

确需业务裁决时由有相应职责的人决定，研发负责解释技术限制和后果。没有必要每轮都把完整PRD重新审核，也不必固定进行十几轮澄清才能开始。

实施过程中怎样保持一致

把已确认目标、约束、假设和验收现象留在任务状态或简短说明中，避免上下文变长后重新猜测。简单任务几句话就够；跨模块功能再补数据模型、接口和重要场景。

可以先实现不依赖答案的部分，但不要在关键语义未知时提交不可逆数据变更。新信息到来后检查受影响代码、测试与旧假设，做局部更新；目标改变时显式调整计划，而不是继续执行失效路线。

验证不仅看代码能运行，还要用已确认的用户场景检查行为。测试可由Agent起草，预期结果应来自需求与业务规则，不能让实现代码反过来定义正确答案。

例子与技术亮点

假设需求只有“加一个导出按钮”。先查现有列表与导出模式，确认数据范围和权限；复用已有字段与筛选条件，实现下载，再检查空结果、中文字段及失败提示。若只是已有导出能力的入口调整，就直接做小范围修改，无需另建完整规范体系。

技术亮点是让澄清服务于关键决策，同时利用已有事实和可逆实现持续推进，并将已确认条件传递到实现与验证。

对应教程

参考资料