
Hello,大家好,我是人月聊IT。这个周末我刚好有时间,整理了一下我原来涉及到的AI编程项目——里面就包括知识工程、个人知识管理大模型知识库,以及基于我的本体建模规范构建的本体建模平台,还有基于本体驱动的平台开发、智能数据分析等等。所有内容我已经上传到了我个人的GitHub库,名称和profile是sharptoolbox,地址是 https://github.com/sharptoolbox 。大家感兴趣的话,也可以上去浏览一下,看看有没有你感兴趣的项目。
但是今天,我重点不是想讲这些开源项目本身,我还是想讲一讲AI编程这件事——我们怎么样去提高自己的AI编程效率?经过最近两三年我个人的AI编程和Vibe Coding实践,我总结出了几个关键理念,希望这些点对大家有所帮助。

第一个关键点:一定要先把需求和业务想清楚,不要在自己都没想明白之前,就贸然驱动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完全可以用工程化的方式,把后续所有工作一并推进。

第三个关键点:前期在团队里,我也推广和试验过很多工程级的软件开发方法论,比如传统的SDD,也用过像OpenSpec、SuperPowers这类工程化技能框架。但整个下来,我个人的强烈建议是:刚启动一个项目时,千万别急着用这些复杂的工程化框架。第一,它们会消耗大量tokens;第二,它们内置了很多治理、管控、质量安全方面的能力,导致跑一次非常耗时,而且生成的东西不一定是你真正需要的。所以刚开始,我建议一定用轻量级框架——只要需求明确、设计方案明确,就足够了。先让AI把整个应用跑起来,核心功能点全部出来后,再逐步引入这些“治理层”的能力和质量管控措施。这样不仅能节省tokens费用,更重要的是能真正提升开发效率。
另外,关于测试策略,也要注意优化:功能变更或优化时,每次只针对当前变更进行测试即可,没必要每次修改都跑全量E2E测试。手工触发AI每半天左右跑一次全量E2E测试,就足够了。这样既不遗漏全局质量,又避免了频繁等待。
还有一个小技巧:可以主动让AI总结对话日志,总结当前已经完成的工作和输出物。这样,下次发起新对话时,先让AI阅读这个总结文件,就能快速了解项目整体概况,大大方便后续工作的衔接。
我一直强调一个核心理念:驱动AI编程时,人永远是最了解业务和需求的,这些核心职责千万不要放给AI。但我发现很多开发人员还是习惯自己没想清楚就一股脑丢给AI,觉得AI具备工程自动化能力,能搞定一切。结果呢?AI输出的东西达不到预期,又得反反复复修改、优化、调整,所有时间成本都花在了折腾上——这样怎么可能提高编程效率和质量呢?
好了,今天关于AI编程的几个简单思考,就分享到这里。再见。