我根据需求文档,用AI完成了驾驶舱系统的开发

第一步不是写代码，而是把需求锁住

我没有拿到需求后立刻让AI开工，而是先让它根据需求给出几条设计路线，再比较信息密度、视觉效果、实现成本和后续维护。

方向确定以后，AI继续完成页面设计和交互原型。这一阶段一共形成了36张页面设计和19页交互原型。原型出来后，我又重新核对需求，于是把后续开发范围从125项缩减到109项。

这一步很重要。AI擅长按照清单往下做，但它不会天然知道哪些内容应该保留，哪些内容虽然写在需求里，却不应该重复开发。需求文档不是直接扔给AI执行的命令，还要先经过人的判断。

登录页是在这个阶段确定下来的。它不仅是一个视觉入口，也代表整个项目已经从文字需求进入了可以逐页确认的设计结果。

先决定做什么、为什么做，再让AI决定怎么做。顺序反过来，做得越快，返工可能越多。

我把“开发一个系统”拆成一串连续任务

“开发一个驾驶舱系统”对AI来说太大了。如果把设计、代码、三维模型、测试和上线一次性交给它，AI很容易在前面的结果还没确认时，就继续往后生成更多内容。最后看起来做了很多，实际问题却堆在一起，很难判断应该从哪里返工。

所以我把整个过程拆成几个连续阶段：先确认设计，再完成原型，然后进入系统开发和三维场景，接着做本地检查，最后才进入生产部署。

每个阶段都要写清四件事：上一步交过来什么，这一步具体做什么，完成后留下什么结果，什么条件满足后才能继续。这样一来，AI不是拿着一个大目标自由发挥，而是在一段一段有边界的任务里工作。

三维部分尤其明显。原型只能表达三维区域应该放在哪里，真正开发时还要解决模型制作、网页加载、镜头、点位、视觉模式和性能检查。我让AI先比较实现路线，最后确定由Blender制作三维资产，Three.js负责在网页中加载和交互，GLB作为模型交付格式。

随后，这部分又被拆成12个连续任务。工具版本没有确认，不能进入模型制作；样板场景没有通过，不能批量生成完整场景；模型不能在真实网页里稳定加载，也不能进入上线阶段。

这张三维模型图记录的是当时的开发结果。它不是最后的系统截图，而是用来确认模型结构、布局和交付格式是否能够继续往下走。

任务拆分的价值，不是把清单写得更长，而是让问题停在它应该出现的那一步。

我把最终检查拆成了四个阶段

为了避免一句“测试通过”掩盖所有问题，我把最终检查拆成了四个阶段。

第一次检查功能。每项结果都要回到需求里核对，并在真实页面中操作，不能只看代码和任务报告。

第二次检查三维场景。模型要在真实浏览器中加载，相关交互要实际操作，画面还要经过人工查看。

第三次检查上线过程。上线前先备份，再把候选版本放进隔离环境。候选版本没有通过，就不能替换正在运行的版本。

第四次检查上线后的状态。页面能不能打开，访问限制是否仍然有效，模型文件能不能加载，服务重启后能不能恢复，都要重新确认。

到最新一次复核，系统已经完成生产部署。网页端144项、后台接口41项自动检查全部通过，支撑系统运行的5个服务也保持正常。完成后的系统界面，已经把网页、三维场景和信息面板放进同一个实际运行画面里。

上线是一个阶段完成，不是从此以后再也不用检查。

这次我真正学会的，是怎样决定AI能不能进入下一步

以前我更关注提示词怎么写。现在我更关注上一步有没有留下可检查的结果。

我的工作变成了确认需求、选择方案、砍掉不必要范围、提供真实画面反馈，并决定什么时候可以继续。AI负责拆任务、实现、运行检查、整理问题和保留证据。只要结果没有通过，前面的“完成”就撤回，修完以后重新证明。

如果你也准备让AI开发系统，先别急着收集提示词。先问三个问题：需求有没有锁住，每一步拿什么结果验收，失败以后能不能回到原来的问题重新检查。

AI不是一句话自动交付。

人把目标、边界和检查方式定清楚，AI才有机会把一个真实系统一步步做出来。