【AI辅助开发使用体验】当需求不明确时，我是如何踩坑、再学会正确使用 AI 辅助编程的

这篇文章不是在教你怎么写 Prompt，而是记录一次在需求高度不确定的项目中，AI 辅助编程给我带来的真实反馈。

一、一个很真实的起点：AI 在“文档清楚时”确实很好用

​ 最早在团队里引入 AI 辅助编程时，大家的体验其实是非常正面的。

• 在一些 需求已经相对明确 的任务中，比如：

  • 已有清晰接口定义
  • 输入输出边界固定
  • 优化目标明确（性能 / 可读性 / 可维护性）

• 只要把这些信息写进文档，再让 AI 按文档生成代码，效果往往非常稳定：

  • 结构合理
  • 命名一致
  • 改动成本低

• 那段时间我们一度形成一个共识：只要文档写清楚，AI 写代码几乎不会出大问题。

二、问题出现在：我们把这种体验，错误地推广到了所有项目

​ 真正的问题，是后来遇到的典型客户项目。

• 在这种项目里：

  • 客户并不能一次性说清楚需求
  • 很多功能是“先做一个大概看看”
  • 关键约束是在开发过程中才逐渐暴露的

• 但当时我们依然沿用了同样的 AI 使用方式：把当前理解写成文档 → 让 AI 直接生成核心代码。

• 代码本身没有明显 bug，甚至在 review 时看起来“写得还不错”。真正的问题，是在需求第一次变更之后才暴露出来的。

三、第一次踩坑：AI 把“暂时的理解”固化成了结构

• 需求一改，问题就来了：

  • 一些原本“看起来合理”的抽象突然不适用了
  • 核心结构需要整体调整
  • 修改往往牵一发动全身

• 我们一开始的直觉是：是不是模型不够聪明？是不是 prompt 写得还不够详细？

• 但随着改动次数增多，一个现象变得越来越明显：**AI 并没有帮我们解决需求不确定性，它只是把我们当下模糊的理解，快速固化成了代码结构。**而一旦结构被固化，后续的每一次需求变化，都会变得异常痛苦。

四、后来才意识到：AI 放大的不是“能力”，而是设计状态

​ 回头复盘时，我们才慢慢意识到一个关键问题：AI 并不是在判断设计对不对，它只是在高效执行当前设计。

​ 当设计状态是边界清楚、假设明确、变化空间可控，AI 就会表现得非常“靠谱”。

​ 但当设计状态是边界模糊、假设尚未验证、哪些地方会变还不清楚，AI 反而会把这些不确定性快速、系统性地放大。

​ 问题不在于代码写得对不对，而在于我们过早地让 AI 参与了“结构性决策”。

五、需求不明确时，AI 最容易被“用错”的地方

​ 后来我们总结，AI 在需求不明确阶段，最容易被用错在两件事上：

5.1 过早生成“看起来像最终形态”的代码

​ 这些代码往往结构完整、抽象合理、但对需求变化极其敏感，一旦客户方向调整，推翻成本非常高。

5.2 把探索阶段，当成执行阶段

​ 在需求还没收敛时，我们却要求 AI写完整实现、做性能优化、提前设计复杂抽象，这本身就是对阶段的误判。

六、后来我们调整了用法：不让 AI 决定结构

​ 真正的转折点，是我们刻意限制了 AI 在早期阶段能做的事情。

• 在需求尚未明确时，我们更多让 AI 参与：

  • 拆解当前需求中隐含的假设
  • 枚举可能出现的边界情况
  • 对比多种实现思路的 trade-off
  • 快速生成一次性原型，用于验证方向

  但不让它直接决定最终结构。

• 这时，AI 的角色更像是：

  一个帮你快速看清问题空间的工具，而不是替你做设计决策的工程师

七、一个重要认知：把问题前置，本身就是设计能力

​ 需求不明确，并不意味着什么都不能设计。

• 我们后来在文档里，哪怕在早期，也会刻意写清楚：

  • 哪些是已知假设
  • 哪些是明确未知
  • 哪些模块允许频繁变动
  • 哪些地方一旦变化，需要整体重构

• 这些“阶段性、不完整”的设计文档，反而非常适合 AI 协作。

  因为它们没有假装自己已经是最终答案。

八、结语：别让 AI 为需求不确定性背锅

• AI 并不会替你：

  • 判断客户真正想要什么
  • 决定系统最终形态
  • 为模糊目标负责

• 但在需求逐步收敛之后，它可以：

  • 大幅降低实现成本
  • 保持代码风格一致
  • 加速迭代节奏

​ 所以现在我更常问自己一句话：**我们现在是在探索需求，还是在执行需求？**只有把这件事想清楚，AI 才会成为放大器，而不是混乱的加速器。