AI时代如何高效率的进行需求探索和AI编程-给你三个关键的建议和改进点

先想清楚需求，再驱动AI写代码

一定要先把需求和业务想清楚，不要在自己都没想明白之前，就贸然驱动AI开始写代码。否则你会和AI之间产生大量往复、来回迭代和修改，所有时间都耗费在反反复复的调整上。我发现很多开发人员习惯性地“想到一点做一点”——查看团队成员的AI编程对话日志时，我就看到不少这样的现象：某个按钮加个校验，来一次对话；把某个控件位置调整一下，又来一次对话；增加一个字段，来一次对话；等字段加完了再实现字段功能，又得来一次对话。这些对话相当零散，而每一次AI执行就要花5到10分钟，执行完还得运行单元测试。

更严重的是，大量开发人员连需求和规则都没想清楚，就让AI去写代码，AI做出来不对，又反复调整，时间全浪费了。这再次说明：AI可以辅助你梳理需求，但无法替你“想”需求，需求的主控权一定要牢牢把握在你自己手里。所以，在我开源的项目里，有一个叫“本体驱动的开发”的项目，即使你不打算用它来驱动整个应用平台开发，我也在里面提供了一个“AI需求探索”的提示词。这个提示词基于传统的面向对象分析设计和本体建模思路，分成了8个阶段（或9个阶段），分步骤帮你进行需求探索。通过这个探索，你基本可以把任何一个需求涉及的业务流程、场景、核心业务域、业务对象、业务规则、业务能力与行为，包括组织、权限、角色等全部梳理清楚。

梳理完之后，它会整理出一份完整的软件需求规格说明书，这份说明书可以接入我的本体模型；但就算你不接入，直接拿它去驱动AI做后续开发也完全没问题。因为这时候的需求是完整、成体系的，它能最大程度减少后续的迭代返工。

提供完整的需求加设计方案再启动编码

当我驱动AI编程时，尽量给出一份完整的需求加设计方案。我不只是需求列完就完事，而是要求AI先输出一份“需求+设计方案”的综合文档，里面既包含核心需求，也包含数据库设计、接口设计、组件划分、技术框架和开发语言选型等内容。等这份方案确认无误后，再启动后续的AI编程实施。对于稍微复杂一点的内容，一定要分阶段、分步骤——先让AI输出需求+设计方案，你确认没问题了再动手，而不是一上来就写代码。

有了这样一份完整的方案，AI如果真正理解到位，完全可以启动后续的“静默式开发”，你甚至可以在白天整理需求和方案，晚上把所有事情交给AI。如果再加上常说的“循环工程”（Loop Engineering），AI自己跑个三四个小时，就能把全部代码输出出来。这样一来，AI编程的效率才能最大化，而不是像我们原来那样——做一步就让AI输出一步，自己再想下一步需求，再让AI接着做。这是我们以前人与人团队协同的惯用模式，但在AI时代一定要改变。AI没办法替你想需求，但它一定能帮你把设计和实现做得更高效。过去人之所以要开发一步再想下一步，是因为人的认知能力有限，往往要把当前功能做出来，才能想清楚后续怎么做。但现在不一样了，只要你的需求是完整的，AI完全可以用工程化的方式，把后续所有工作一并推进。

从轻量框架起步，再逐步叠加治理能力

刚启动一个项目时，千万别急着用复杂的工程化框架。第一，它们会消耗大量tokens；第二，它们内置了很多治理、管控、质量安全方面的能力，导致跑一次非常耗时，而且生成的东西不一定是你真正需要的。所以刚开始，我建议一定用轻量级框架——只要需求明确、设计方案明确，就足够了。先让AI把整个应用跑起来，核心功能点全部出来后，再逐步引入这些“治理层”的能力和质量管控措施。这样不仅能节省tokens费用，更重要的是能真正提升开发效率。

另外，关于测试策略，也要注意优化：功能变更或优化时，每次只针对当前变更进行测试即可，没必要每次修改都跑全量E2E测试。手工触发AI每半天左右跑一次全量E2E测试，就足够了。这样既不遗漏全局质量，又避免了频繁等待。

还有一个小技巧：可以主动让AI总结对话日志，总结当前已经完成的工作和输出物。这样，下次发起新对话时，先让AI阅读这个总结文件，就能快速了解项目整体概况，大大方便后续工作的衔接。

人始终是需求与业务的最终责任人

我一直强调一个核心理念：驱动AI编程时，人永远是最了解业务和需求的，这些核心职责千万不要放给AI。但我发现很多开发人员还是习惯自己没想清楚就一股脑丢给AI，觉得AI具备工程自动化能力，能搞定一切。结果呢？AI输出的东西达不到预期，又得反反复复修改、优化、调整，所有时间成本都花在了折腾上——这样怎么可能提高编程效率和质量呢？