从吴恩达YC 演讲谈AI4SE落地场景要“具体”

前一阵子，在 Y Combinator 举办的 AI Startup School 上，吴恩达教授做了一场主题为《Building Faster with AI》的硬核分享，全场围绕三个关键词展开：速度、具体、反馈。笔者在从浦东机场回来的地铁上看了整个演讲，感受颇多。这篇文章就吴教授提到的“具体”结合2个案例来具体讲讲。

模糊的想法，是创业最大的陷阱。

吴教授提到，一个想法，再有前景、再有远见，如果不能马上画出原型、写一行代码，那就不是好想法。比如，演讲中提到的例子，“我们想用 AI 优化医院资源调配” —— 听起来高大上，但没法立即执行。

“我们要做一个网站，让患者在线预约 MRI 机器，提升使用效率” —— 这就是一个能立马执行的、具体的产品方向。

吴恩达说：“你越模糊，就越难被证伪；但你越具体，就越容易发现真相。” 而创业的关键，不是看上去对，而是快速试错，快速找到对的方向。但是对于在企业内部做DevOps、AI4SE等降本增效、持续改进的同学来讲，这也是一种“内部创业”， 因此也要考虑吴教授的讲法。

AI4SE中的具体和模糊案例

AI赋能软件工程，使用LLM实现软件开发、测试提质增效

相信不少读者从领导那里收到过此类的要求。但是很不巧这是典型的模糊案例。作为此类任务的承接人，要做的事情就是把它翻译成”具体“的场景。

那么什么样的是具体的呢？ 用AI生成单测用例， AI生成测试用例 是不是呢？

如果只是用例的“生成”，笔者认为也不是"具体"的场景。 笔者认为能够形成闭环的才是“具体”的。

例如， 用LLM来生成单元测试，在很多IDE的场景中就是一个菜单功能，一次性的工作。而笔者之前写过一篇文章《基于LLM的单元测试生成，你在第几级？》，讲的是 如何使用LLM来生成 “可编译通过、执行通过、有断言、代码覆盖率有提升”的单元测试用例。

而顺着这个思路，一个可以闭环的场景是，“基于MR/PR的单测用例生成”，也就是识别出团队集成分支上的MR/PR中的增量代码，为这些代码来生成前述“可编译通过、执行通过、有断言、代码覆盖率有提升（可达标）”的单元测试用例，然后为这个MR/PR来补充生成一个单测的MR/PR。开发人员收到提醒之后，稍加review结合DEVOPS平台的MP/PR 扫描报告，可以决定是否接受该部分测试用例代码。这是一个具体、闭环的场景，不依赖人的参与，生成的是确保可用的代码。

当然快速反馈也是很重要的一点。在单元测试的场景中，早先也是和诸多竞品一样，（如内部购买的灵码也有此类功能），在IDE中做的单测生成场景，开发人员点击“生成”按钮后，我们的核心竞争点就变成了“如何生成可编译通过、执行通过、有断言、代码覆盖率有提升”的单元测试用例”。虽然经过”生成-验证-修复” 的几个轮次，在成功率上已经完全吊打一众IDE竞品，但是也存在着耗时过长的致命问题（多轮对话+生成代码多）。

在观测到早期产品的推广使用曲线停滞的现象之后，及时了解了用户痛点（在IDE中，开发人员就是想生成个测试用例，只要时间够快，质量低一点也可以的，反正改一改也能用），于是我们果断停止了在IDE中与灵码的竞争，转向了非时间敏感、但是能发挥我们成功率高的优势的场景，通过Agent为 MR/PR补足代码覆盖率。由于是在半夜做，LLM工作负载低，电费还便宜。

类似的，现在不少做所谓的LLM 辅助Code Review的场景。 如果只是让LLM代替SonarQube做一下代码扫描，即使是LLM能review的问题类型和角度更多，也只是做了review而已。

Code Review最佳实践 - 宝玉 - 博客园

图片来源：How to Do Code Reviews Like a Human

而在组织内推广过SonarQube的同学都知道，问题的关键 从来不只是如何把问题“扫出来”，而是如果把问题“消掉”。扫出来的问题再多再”有效“（真正关键的其实不多），如果没有形成问题解决的闭环，问题堆积在那里无人问津，对于提升质量来说，也都是没有用的。因此，笔者一直把“质量门禁带电”作为类似问题的抓手，达到”增量不增，存量消减“的效果。因此，此类的LLM + Code Review的方案其实可以与代码扫描质量门禁或者APR(自动问题修复)结合起来。尤其是后者，LLM不是已经识别出问题了嘛？ 本着“谁提出，谁解决”的光荣传统，那么就请LLM再辛苦一下，进一步把代码修改、验证通过之后，再给提交一个MR/PR，开发人员确认后接受即可。 毕竟这个时代，谁都能BB两句，但是真正愿意出手帮忙的是极少数。开发人员从来不缺在旁边BB的人不是吗。

总结一下，就是要快速+闭环。

那么测试用例生成的场景又该怎么搞才算闭环呢，欢迎读者留言讨论。