审核AI生成的代码？ #AI生成代码审核 #代码审核 #软件测试 #AI编程 #单元测试 #集成测试 #端到端测试 #变异测试 #测试分层 #代码审查 #AIAgent #CICD #质量锚点 #测试覆盖率 #程序员 #技术分享 #AI工程化 #代码质量 #自动化测试 #开发效率 #悖论 #应用复杂度 #初创项目 #测试策略 #代码失控 #质量保障 #雷哥 #AI工程化落地

我们把是否应该审核AI生成代码这件事情，给大家聊清楚。 那我们知道，如果AI生成代码，我们每一行都去审的话，那你一定会成为AI生成代码的瓶颈。 那如果你不去审这些代码，再过一段时间之后，你就会失控，你不知道代码里边写的什么。 那这个是我们在做AI Coding的时候，最大的一个悖论问题。 这是作者Bob Klinko在X上发的一条信息。 他说他所有这些编码工作，其实都会用单元测试、Gabon测试、Cury测试等等，还有便宜测试、单元覆盖率等等这些东西去控制代码的质量，从而他不去看任何一行代码。当然从常理推测来讲，我们认为这些测试应该也是由AI去生成的，所以他不去看任何代码。 他说只要你把这些测试的门禁做好，那整个AI生成代码就没有问题了。 所以我们能看到Bob其实在做这件事，他的实际做法是非常激进的。 但我们并不完全认为他这件事情完全就是对的。 原因是什么？ 因为我们需要做这个测试，以及所有的测试覆盖率，团队里边对测试的要求，其实尺度都是不同的。 那为什么会有这些不同呢？ 因为我们来看这个象限图。 左上的区域，我们假设开发了一个应用，这个应用是一个特别简单的应用，是一个外部的应用，它只有一个用户。 那右边是一个非常复杂的应用，有很多很多人用。那如果这个代码里边出问题的话，很多人就会挂掉。或者你自己觉得这个应用特别重要，不能出问题。所以这个是非常复杂、很多人用的应用。这个是一个非常简单的应用，所以它整个应用开发，其实是成体系的：从简单到复杂，从单人用到多人用，这样沿着一个体系轴的应用。那我们开发的应用是什么呢？其实我们开发的应用是在这里边，我们从左侧开始往右滑，滑着滑着越来越接近，有更多的用户去用。那这个滑动的过程中，其实也是我们测试变复杂的一个过程。这个测试变复杂的过程，就是你不可能说你的应用一上来，就全部都用很复杂的测试覆盖用户，你又不可能全部都没有测试覆盖用户。那怎么办呢？我们就要把这些所有的测试进行分层，不同的分层适用于不同的项目、不同的企业，以及不同的应用服务的人数。这里边就包括单元测试也好，机能测试也好，端到端的变异测试也好，这些都是我们的一些基础测试。当然到变异测试的时候，其实就比较复杂了。那后边还有一些Code Review，Code Review就是以前我们人与人之间的这些Code Review，现在变成一个让AI去Review这样的一个方式。那这个其实也算为Workflow中的一部分，还有一块是单元测试的代码。 那所以这样的话，我们就把整个测试进行分层了。那从简单到复杂的话，我们是从这边去挑的。我们并不是说，上来做一个简单应用的话，这些所有层的测试都要有，然后也不是说我们在最开始做的时候，就没有测试。那我们的逻辑最好是这样的，就是我们选择最简单的测试，而且是最能让我们这个应用串起来的测试。那给大家推荐的话，如果是我们刚起播的话，我们一定要去做提升测试，然后加上我们的扣Review的Agent测试，以及覆盖率测试。那这三块测试的话，其实用20%的时间，你已经完成80%的验证功能。那这样的方案其实是非常棒的。那基于这个基础的方案，我们就可以从这个APP，去往右边进行一个开发了。那越开发，迭代的负担越多，我们就在这边CICD集成的过程中，我们可以去集成单元测试，集成更多单元测试，集成更多端到端测试，集成更多测试矩阵的地图，让测试矩阵成为质量的锚点，然后从而进行一个完整的测试。但是这个是随着你的用户越来越多，项目变得越来越复杂，你代码如果出问题的成本比较高的情况下，你会越来越多地集成更多的测试，并不是说上来就堆砌很多测试。那这个就是今天跟大家分享的所有内容，希望这些内容对你有收获。关注雷哥，关注AI工程化落地。