一、问题为什么 AI 写完了代码结果却不符合预期在使用 AI 辅助开发的过程中我逐渐发现一个问题有时候AI 并不是没有完成开发任务而是从一开始就没有完全理解我们真正想要的东西。我们通常习惯直接向 AI 描述需求然后让它按照要求实现。但实际开发中的需求往往没有那么完整即使已经明确了大致目标也可能遗漏页面交互、业务规则、特殊字段以及各种边界情况。面对这些没有明确说明的部分AI 往往会根据现有信息自行推断并选择一种它认为合理的方式继续开发。问题在于AI 能够合理地补全信息并不意味着它补全的内容符合真实业务需求。例如我们要求 AI 开发一个功能却没有明确某些字段是否参与判断、不同业务状态应该如何处理。AI 可能会按照自己的理解完成代码但等到实际测试时才发现这些细节与预期不符最终不得不修改方案甚至重新实现。因此我认为除了优化需求描述和提示词之外还有一个值得尝试的方向在正式开发之前增加一个让 AI 主动反问的环节。二、思路让 AI 从需求执行者变成需求讨论的参与者这里需要先明确一个前提对于正式的业务需求还是应该优先与需求提出者进行沟通确认真正要解决的问题和业务口径。本文讨论的主要是个人开发场景或者已经与需求方完成初步对齐但在具体实现过程中仍然存在许多细节尚未明确的情况。在这种情况下我们不必急着让 AI 开始编码而是可以先让它站在需求分析者的角度审查当前需求并主动提出需要确认的问题。具体来说可以让 AI 从三个方面展开分析1. 找出需求中尚未明确的细节例如页面需要支持哪些交互某个字段为空时应该如何处理用户执行操作之后数据和页面状态应该如何变化这些问题看起来很细但它们往往直接决定了最终实现是否符合预期。2. 主动识别业务边界和异常情况除了正常流程还需要考虑特殊场景。例如哪些字段发生变化后应该被视为一条新记录重复操作是否需要拦截不同业务状态下功能的判断规则是否一致开发者未必能够在第一次描述需求时考虑周全而 AI 可以通过系统性地检查规则帮助我们发现遗漏。3. 针对不同实现方案进行比较有些需求并不是只有一种实现方式。这时可以让 AI 提供几个候选方案说明各自的实现逻辑、优缺点、潜在风险和适用场景再由开发者根据实际业务情况进行判断。需要注意的是AI 不应该为了提问而提问也不应该把所有不确定的事情都抛给开发者。对于能够通过阅读现有代码、检查接口调用链路等方式确认的信息应该优先自行调查只有真正影响业务逻辑或实现结果的问题才需要进一步反问。三、案例之前在开发一个涉及多个模块的防止重复录单功能时我对这一点的感受比较明显。由于我进入公司时间还不长对部分业务链路的理解还不够深入再加上 AI 提效后页面和业务细节可能随着开发推进而不断调整因此仅凭最初的需求描述很难一次性考虑周全。在开发前我尝试让 AI 主动审查需求并针对不明确的地方向我提问。其中一个重要问题就是如何判断两条记录是否重复。由于需要综合多个业务字段生成重复指纹因此必须明确哪些字段应该参与计算以及不同字段的变化是否意味着一条新的记录。在这个过程中AI 提出了几个值得讨论的问题某些特定字段是否应该参与重复指纹的计算不同业务场景下哪些字段发生变化后应该被视为新的记录对于当前需求采用方案 A 还是方案 B 更合适这些问题看似细小但实际上可能直接影响重复判断的准确性。如果一开始没有考虑到这些情况AI 仍然可能按照已有信息完成代码但真正进入测试阶段后才会暴露出规则遗漏或判断不准确的问题。通过提前讨论我能够进一步明确自己的需求也可以结合真实业务对不同方案作出选择。所以我意识到AI 的价值不只是更快地实现已经明确的需求还在于帮助我们发现那些自己尚未意识到的需求缺口。尤其对于业务经验不足、进入公司时间不长或者面对陌生业务模块的开发者来说这种辅助分析的作用可能更加明显。四、实践如何把需求反问真正融入开发流程结合自己的使用体验我认为可以将这一环节整理成一套相对简单的流程。第一步明确初始需求先描述要解决的问题、预期目标和大致改动范围。如果涉及真实业务优先与需求提出者对齐关键口径。此时不必追求一次性描述所有细节但应该明确当前已经知道什么以及哪些地方仍然存在疑问。第二步分析优先要求 AI 检查需求中的模糊点、潜在边界情况以及可能存在的多种实现方案。同时让它区分三类信息已经明确的需求和业务规则。可以通过阅读现有代码或调查项目自行确认的信息。需要开发者或需求方作出判断的问题。这样可以避免 AI 把本来能够自行查明的信息反复拿来询问。第三步逐项讨论关键问题让 AI 优先提出真正影响实现结果的问题并说明为什么需要确认。对于技术实现问题可以让 AI 提供多个方案并进行对比对于业务规则问题则需要由了解业务的人作出判断。没有必要把所有细节一次性讨论完也没有必要为了流程完整而反复确认一些显而易见的内容。重点是解决那些可能导致返工的问题。第四步整理并确认最终方案当关键问题得到解决后让 AI 将讨论结果整理成一份明确的需求说明包括本次需求的目标和改动范围。已确认的业务规则和边界情况。关键实现方案及选择理由。验收标准和仍需验证的事项。确认无误后再进入正式开发。通过这一过程原本模糊的需求就能够逐步转化为相对清晰、可执行、可验收的开发任务。五、可复用的提示词为了让这个环节更容易应用到实际项目中可以使用下面这段提示词作为起点。在开始开发之前请先不要编写代码。 请你扮演一名有经验的需求分析师和业务测试人员 审查我提供的需求尽可能发现需求理解偏差、 业务规则遗漏和潜在的边界问题。 请按以下步骤执行 1. 复述你对需求目标、业务流程和改动范围的理解。 2. 找出尚未明确的细节包括业务规则、 字段判断、状态变化、异常处理和边界情况。 3. 区分哪些信息可以通过阅读现有代码自行确认 哪些问题确实需要我作出判断。 4. 对存在多种实现方式的部分提供候选方案 说明优缺点、适用场景和潜在风险。 5. 优先提出最重要的问题说明每个问题的原因 不要一次性罗列大量低价值问题。 6. 不要擅自决定尚未明确的关键业务规则 也不要在需求未确认前开始编码。 待关键问题讨论完成后请整理出 - 最终确认的需求 - 明确的改动范围 - 已确认的业务规则和边界情况 - 推荐的实现方案及选择理由 - 验收标准和待验证事项 在最终方案得到确认后再进入开发阶段。这段提示词并不是一套必须严格遵守的固定流程而是一个可以根据需求复杂度调整的模板。对于简单需求可以只检查关键歧义对于涉及多个业务模块、复杂状态流转或重要数据判断的需求则值得投入更多时间进行讨论。六、局限并不是所有问题都应该交给 AI 反问当然AI 提出的疑问和给出的方案也不一定正确。有些问题可能是因为它没有充分阅读现有代码而不是需求本身存在缺陷有些看似合理的方案也可能与实际业务规则冲突。因此不能因为 AI 提出了问题就要求开发者逐一回答也不能因为 AI 给出了推荐方案就默认它的判断一定合理。更合理的方式是让 AI 先调查能够确认的事实再针对真正影响实现结果的问题提出疑问最后由开发者结合业务情况作出判断。此外反问环节也有成本。对于改动范围明确、风险较低的简单任务没有必要进行复杂的需求分析。只有当需求存在较多不确定性或者遗漏细节可能导致较大返工时前期讨论才更有价值。反问的目的不是让 AI 问出更多问题而是用尽可能少的沟通提前发现真正重要的问题。七、总结我认为一个值得尝试的改变是不再把正式编码作为与 AI 对话的第一步。与其直接通过几轮的简单对话就要求 AI 实现需求不如先让它帮助我们检查需求、发现遗漏、分析方案并通过讨论逐步明确实现边界。这不仅有助于减少需求理解偏差也能够帮助开发经验不足的人补充业务分析视角。归根结底AI 辅助开发的关键不仅在于如何准确地向 AI 提问也在于如何让 AI 反过来向我们提问。好的 AI 辅助开发不应该只是“我提出需求AI 负责实现”应该是我与 AI 共同梳理需求、发现问题由人确认关键决策再让 AI 完成实现。