从写代码到上线，一套保证产品质量的全流程 最近，Anthropic 发了一篇文章，介绍了 Claude Code 团队是怎么审核 AI 写的代码的。因为代码审核和整个发布流程是紧密关联的，所以文章其实把他们从写代码到上线的整个流程都讲了一遍。本期视频，我会结合自己的理解，带大家把这个流程从头到尾走一遍。看完之后，你不仅能了解该怎么审核 AI 写的代码，还能知道怎样搭建一套可靠的流程，保证 AI 写出来的产品的质量。 本期视频的具体内容包括： - 传统的代码发布流程，以及 PR 前、PR 中、合并时、合并后四个阶段 - PR 前：让 AI 自己验证产品能否正常运行，用全新的 agent 检查代码质量 - PR 中：CI、AI 审核、安全审核和按风险审批，以及 Anthropic 是怎么优化 AI 审核的 - 合并时与合并后：合并队列、功能开关、逐步上线和回滚 - 在 AI 写代码的时代，人最需要做的到底是什么 - 我对未来 AI 开发方向的一些判断 #AI #ClaudeCode #Anthropic #代码审核#vibecoding

今天我们来聊聊如何审核AI写代码。现在用AI写代码越来越普遍了，可到底怎么审，大家一直都还没有一个统一的说法。一行行看吧，根本看不过来，AI分分钟就可以给你写出几千行代码，全部看完要花费大量的时间；不看吧，又不放心，谁知道AI写的东西是不是跟你想象的一样呢。那既然两个极端都不行，要不就走个中庸之道，只审重要的部分。听起来好像可行的样子，可问题就在于，谁知道哪部分重要，哪部分不重要呢。很多时候，问题恰恰就出现在那些看起来不起眼的地方。所以到底该怎么审核AI写代码，这个问题到现在也没有一个定论。最近Anthropic发了一篇文章，叫做How the Claude Code team does code review，介绍了Claude Code团队是怎么做代码审核的。文章一开头就提到，Claude自身大概90%的代码都是用AI写的。那这问题就来了，AI写了这么多代码，他们是怎么保证代码质量的呢？这个就是这篇文章需要回答的问题。不过需要留意的一点是，虽然文章标题讲的是代码审核，但它介绍的内容其实远远不止代码审核这么简单，因为代码审核不是一个孤立的环节，它和整个发布流程都是紧密地联系在一起的。所以Anthropic在介绍他们怎么做代码审核的时候 也把整个发布流程都介绍了一遍。下面我就结合我自己的理解，带大家把这个流程从头到尾走一遍，看看 Cloud Code 团队到底是怎么做的。不过在这之前，我们先稍微回顾一下，通常一段代码是怎么发布上线的。首先我们要写代码，写完之后呢，要把代码合并到主分支，也就是 main 或者是 master 分支。不过呢，这个合并并不是一步到位的，一般呢我们需要先提交一个 PR。你可以把 PR 理解成这段代码合并到主分支的一个申请。提交到 PR 之后呢，一般情况下呢，后面还会做两类检查：一个是自动检查，比如说是运行一些相关的测试，看看代码有没有问题；另外一个呢，是审核，这一步呢，一般是让其他的开发者看一下代码写得对不对，有没有些简单的风险。等这些检查都通过了之后，代码就可以合并到主分支了。不过合并到主分支呢，也并不代表用户马上就能够用到这些代码。通常情况下呢，还需要发布这个环节，发布了之后，代码对应的功能才会真正被用户使用到。这个就是传统软件开发过程中，一段代码从编写到发布上线的大致流程。我们可以把这个流程大体分为四个阶段：第一个是 PR 前，也就是提交 PR 之前所发生的事情；第二个呢，是 PR 中，这个呢是指提交 PR 之后到合并代码之前所发生的事情；第三个是合并时，这个呢是指合并的时候所发生的事情；第四个呢，是合并后。 这个当然是指合并完成之后所发生的事情了。克拉扣团队流程呢，同样是这四个阶段，大框架没什么变化，变的呢是每个阶段里面具体做的事情，好适应现在 AI 写代码的情况。接下来我们就按照这四个阶段，一个一个来看一下每个阶段里面他们具体是做了什么事情。 我们先看第一个阶段：PR 前。PR 前这个阶段呢，大致可以分成两个步骤。第一步是确保产品能够正常运行。这一部分我们可以交给 AI 来处理。既然交给 AI，我们就必须要给 AI 一些方法，让它能够自己来验证产品是否真的能够正常运行。比如说啊，我们可以给 AI 相关的工具，像是什么运行程序啊、查看网页啊、截图啊、操作电脑之类的。这样 AI 写完代码之后，就可以自己把产品运行起来，并且用相关的工具来检查产品的运转是否正常。所以这一步最重要的地方就在于，要让 AI 具备能够验证产品效果的能力。 确保能够正常运行之后，第二步就是要检查代码质量了，也就是确认代码本身的编写没有问题，比如说是是否符合规范、架构是否合理等等。这一步我们也可以让 AI 来检查。那具体该怎么做呢？有些小伙伴可能就在想了，我们原来不就是在用 AI 写代码吗？我们当初把要完成的需求发给他，是他呢根据需求写完了相关代码，他的上下文里面还存着之前的思考和相关的对话记录。这样的话 这个 agent 应该是对这个代码知根知底的，那让他检查就再合适不过了。这个想法听起来很自然的样子，不过实际操作下来，你就会发现，他会遗漏很多问题。你想啊，这个 AI 本来就知道自己是怎么想的，那他回头检查的时候还是会顺着原来的思路走，这样就很容易以为自己已经写对了，那这样的话，很多问题就查不出来了呀。所以 Anthropic 采取的办法呢，就是在创建一个全新的 AI agent，并且只把目标和相关的代码改动发给他，让这个新的 agent 来判断这些代码能不能完成既定目标，有没有什么潜在的风险。这么做的好处在于啊，这个 agent 有着一个全新的上下文，他不知道之前写代码的时候发生了什么。这听起来像是一个缺陷，但恰恰就是这种缺陷，能够让这个 agent 保持客观，不容易遗漏问题。所以啊，检查代码质量这一步的重点就在于要使用一个新的 agent，因为啊它有着全新的上下文，不包含原来的各种思考和实现过程，这样呢反而更适合审核代码。好，这个就是 PR 前的两个步骤了。一个呢是确保产品的更正常运行，这一步的重点是让 AI 具备验证产品效果的能力。第二点是检查代码质量，这一步的重点在于使用一个全新的 AI 检测来检查代码。接下来是第二个阶段 PR 中，在这个阶段。 一个 PR 要先后经过 CI、AI 审核、安全审核和按风险审批这四个环节。其中前三个环节都是机器检查，最后一个是人工检查。下面我们来一个一个看。 先看第一个，CI。CI 就是每次提交代码之后自动运行的一整套检查。比如说，我们可以在这个环节里面做 lint 检查、类型检查、多平台测试，或者是尝试构建一下项目，看看有没有什么问题。当然这里面只是举了几个例子，除了这几项之外，这个阶段还可以有其他非常多的检查。基本上，那些不需要 AI 而且能够自动跑的检查都可以放到这里面。 CI 检查过了之后，下一步要做的就是 AI 审核了。AI 审核的过程大致可以分成三个步骤，分别是发现问题、筛选问题和处理问题。 第一步是发现问题。在这一步，AI 会从三个方面来检查 PR：有没有达到目标、跟现有系统合不合得来、会不会影响别的地方。这样查起来就比较全面了。 发现了问题之后，第二步就是筛选问题。简单来说，这一步就是筛选掉无关紧要的问题，比如说是代码风格不一致，或者是存在冗余代码之类的。这类问题一般不太会影响程序的正常运行。如果大部分的开发者都觉得无所谓、不需要改的话，那就可以把它们写成一个筛选规则，交给这一步对应筛选的 AI。这样的话，这个 AI 就可以根据给定的规则，把这些无关紧要的问题去掉。 这样这些问题在这一步就会被过滤掉，开发者也就不用在他们身上浪费时间了。做完了筛选问题之后，第三步自然而然就是处理问题。留下来的问题呢，会被分成三类，分别是重要问题、小问题和已有问题。所谓的已有问题，就是说这个问题并不是这次改动所带来的，它原来具有。不管是哪一类问题，每一条问题呢，都必须要回应，要么改掉，要么写明理由关掉。只要是还有问题没有处理，这个 PR 就不能够继续走下去。好，这个呢，就是 AI 审核的三个步骤了。这三步合在一起，其实就是在做一件事情：找出 PR 的问题，并且处理掉。没错，就是这么简单。给 AI 审核的具体流程呢，我们就讲完了。除了介绍这个流程之外，SRP 还讲了他们对这个流程的优化方案。我稍微总结了一下，他们优化呢，主要是围绕三点展开的：第一，要找出真正的问题；第二，要少提没用的意见；第三，审核要能正常结束。下面我们就来挨个看一下。首先来看第一点，要找出真正的问题。既然要找出真正的问题，那最好的办法就是拿真正出过的问题来考一考它。所以啊，AnSarp 的做法就是用线上问题来做评测，然后呢，再用这个评测来优化审核流程的效果。具体来说，就是把每一次出现的线上问题都收集起来，然后记下两样东西，分别是出现了什么问题，以及是哪一个 PR 引入的。这两样东西结合起来，就可以作为一个完整的案例。 那好几个案例放在一起，就组成了一个评测集。下面我们要做的就是使用这个评测集，给当前的这个审核流程打个分。比如说，我们可以先把案例一里面的 PR 拿出来过一遍 AI 审核，让 AI 审核找找这个 PR 的问题。然后呢，我们再把这个案例里面的真实问题拿过来，跟 AI 审核找到的问题对比一下，看看审核流程有没有找到真正的问题。如果找到了，那就得一分；没找到的话呢，就得零分。之后我们可以使用这个方法，给每一个案例打一个分，加起来的总分呢，我们可以把它叫做基准分。 接下来我们对 AI 审核做一些调整，比如说是改改提示词啊、改改工具啊，甚至改改模型之类的。然后呢，用同一个评测集再打一次分。如果分数提升了，就说明这次调整是有效的，那对应的修改呢，就可以留下来。这样有了可以量化的分数，用的又都是真实的线上案例，我们就能够一步一步稳定地提升 AI 审核的效果。 再来看第二题啊，要少提没用的意见。前面的评测只看 AI 审核有没有把真的问题给找出来，至于它还报了多少别的问题，其实是不怎么管的。这样一来，AI 审核报得越多，就越容易得分。不过报的问题越多，没用的意见往往也会越多。这样的话，开发者就需要花大量的时间一条一条地去看，非常浪费时间。所以啊，想要全面提升 AI 审核的效果，我们还得确保 AI 审核尽量少提没用的意见。那想让它少提意见的话。 首先就得知道他提的意见里面哪一些是没用的，占的比例呢，大概是多少。所以，Sopic围绕这一点着重做的一件事情就是识别无效意见。文章里面提到了两种识别无效意见的方法。 第一种呢，是看PR的作者是怎么处理每条审核意见的。Sopic会根据PR作者的反馈，把AI审核给出的每条意见分成四类，分别是作者改了、作者说他错了、作者说他是故意这么写的，还有一些是作者觉得无所谓。第一类呢，是说明意见是有用的，不过后面三类呢，就是无效意见了。这样一统计，就知道AI审核的意见里面有多少比例是无效的。 第二种呢，是拿没有问题的PR去测。他们会专门挑一些确认没有问题的PR拿去做一遍AI审核。既然这些PR本来就没有问题，那AI审核所提出的意见呢，基本上也都是无效的。Sopic就用这两种方法来统计AI审核的无效意见比例。有了这个数字以后，每次调整AI审核的时候呢，就不光要看评测分数有没有提升，还要看无效意见有没有变少。这样才能够全面提升AI审核流程的可靠性。 最后来看第三点，审核要能正常结束。你可能会比较奇怪，审核怎么会结束不了呢？其实有些时候啊，AI审核可能会没完没了地提意见。比如说AI审核先提了一些意见交给写代码的AI，写代码的AI就根据这些意见去修改代码。 然后把修改好的代码再交回给 AI 审核。这呢是第一轮，接下来第二轮呢，AI 审核又提了一些新的意见，写代码的 AI 呢又改了一遍，再交回，就这样来来回回，没完没了。文章里面有个例子，有一个 PR，一晚上来回改了五十多轮。为什么会这样呢？一般情况下，原因无非是两种：要么是审核流程本身有问题，每一轮都能挑出一些新的毛病；要么是写代码的 AI 有问题，怎么改都改不对。为了解决这个问题，Anthropic 的做法呢是控制审核轮数。具体来说啊，它是对审核流程做了几点调整，我们一起来看一下。第一个调整啊，是超过三轮就需要停下来想一想思路。具体来说，如果一个 PR 来回改了三轮还没有通过，就需要提醒 PR 的作者先停一停，不要再一点点改了，要好好想一想是不是整体思路有问题。第二点是前几轮之后只改新改动的部分。这条可能有点难理解，我来稍微解释一下。PR 提交了之后，AI 审核会结合整个项目去看这个 PR 会带来什么影响。比如说啊，我们假设一个 PR 改了一个函数，第一轮审核的时候，AI 审核流程不仅会去看这个改动本身有没有问题，还会去看项目里面有哪些地方用到了这个函数，并且检查这些地方会不会也受到影响，然后呢做一个综合的评估。这样做虽然比较花时间，但是检查得非常全面，相关的地方都能够查到，不容易有疏漏。就这么审核完了之后。 AI审核会给出他的意见，然后写代码的AI就会根据这些意见去修改代码。比如可能在原文件里面多修改一部分内容，改完了之后会再交给审核流程，下面第二轮审核就开始了。在这一轮审核流程还是会用相同的方式，把PR的改动和被影响的地方都整体看一遍，并且给出新的审核意见。这个过程可能会重复个好几轮。不过几轮之后，审核的方式就发生变化了。这个时候写代码的AI再改几行，审核流程就会只看这几行了，他不会再去整体看一遍了，之前已有的改动也会忽略掉。那为什么后面就只看改动的那几行了呢？因为如果每一轮都从头看的话，几乎每一轮都能够挑出一些新问题，但是这些问题大多数并不是这次改出来的，而是第一轮的时候就已经在那里了，只是因为看的范围大，所以每一轮就会又多翻出几个。这样一来，每一轮都有新的意见，审核就会一直停不下来。所以要想让审核停下来的话，我们就必须要把范围收窄，后面那几轮只看新改的那几行就行。不过这样的话会不会漏掉一些问题呢？其实基本不太会，因为前几轮已经把PR的改动和它影响到的地方看过好几遍了，这样的话大部分的问题都已经找出来了，所以不太有可能会漏掉问题。这个就是第二天的具体做法了。这个做法稍微有些复杂，所以我们在这里简单总结一下。前几轮的时候 审核流程会把 PR 的改动和它影响到的地方都看一遍。等到后面几轮的时候，审核流程就会只看新改的那几行。这样的话，既不容易漏掉问题，审核也能停得下来。 好，第二点讲完了，我们再来看看第三点。第三点是同类问题依次全部指出。比如同类错误在代码里面出现了好几次，AI 审核不会只标出其中的一处，而是把这几处依次全部指出来。这样后面就能够依次全部改掉，不会改完这一处，下轮又被挑出另外一处。 第四点是不提重复意见。已经提过的意见，后面几轮就不要重复再提了。不然同一条意见每一轮都出现一次，作者就得一遍一遍地去回应。 好，这就是控制审核轮数的四条规则了。那效果怎么样呢？答案是很有效。根据 Astrapic 文章给出的数据，在用上了上面这四条规则之后，他们只需要审一轮就能够通过的 PR 比例从 65% 涨到了 78%。 好，按 Srafik 的优化方案，我们就先讲到这里。现在我们回头来看一下，整个 AI 审核我们一共讲了两块内容：一块是具体的流程，另一块是优化方案。那 AI 审核就这些内容了。 下面我们来看第三个环节：安全审核。安全审核是单独的一轮自动审核，专门去检查代码里面有没有安全问题。跟 AI 审核一样，它找到的问题只要还有一条没有处理，PR 就不能合并。原文对这块写得也不是很多。 所以呢，我们就不展开了。大家知道这里面有这么一道关卡就行。然后我们再看最后一个环节，按风险审批。呃，大家想一下，就是改一个文档里面的错别字和改计费相关的功能，那风险显然是不一样的，需要的审批策略呢，也不一样。所以呢，astropic 按风险把改动分成了三档。第一档是低风险，比如说是改文档、改文案，或者是修改一些只有内部员工才能够用到的功能。对于这类改动，只要是前面的自动审查通过了，就不需要人去批准了。第二档呢，是中风险，比如说是普通的产品改动，或者是涉及缓存自动更新这些比较敏感的地方。这类改动呢，需要一个人来批准。第三档呢，是高风险，也就是风险最高的那些代码。这些代码呢，需要两个人来批准，以便能够保障稳定性。好，PR 中这个阶段呢，就讲到这里了。整体回忆一下，PR 中有四个环节，分别是 CI、AI 审核、安全审核和按风险审批。一个 PR 经过了这四个环节之后，就可以准备合进主分支了。这样的话，我们就来到了第三个阶段，合并时。在这个阶段，有两个东西比较重要。第一个是主分支，一般就是 main 或者是 master 分支，这个大家应该都比较熟悉了。第二个呢，是合并队列。准备合并的 PR 一般不会直接合进主分支，而是会先进入到合并队列里面排好队。每次轮到一个 PR 的时候，系统就会把它和最新的主分支合在一起，再跑一遍测试。 如果说测试通过，这个 PR 才会真正合进主分支里。下一个 PR 也是一样，只不过这一次跟它合在一起的是已经包含了上一个 PR 的那个主分支。测试通过之后，第二个 PR 也合了进去。这样做的好处就是每个 PR 都是在最新的主分支上测过的。有些时候，一个 PR 单独测试没有问题，但是一旦和最新的主分支合在一起，就会出现测试未通过的情况。我们现在所展示的这种合并方法，就可以把这些有问题的 PR 拦下来，退回给作者，从而保证主分支始终都能够正常运行。 那合并时讲完了，最后一个阶段就是合并后代码进入到了主分支。那接下来要做的就是让它能够安全地到达用户的手里。这里一共是有三件事情要做，分别是设置功能开关、逐步上线，还有观察和回滚。 先说设置功能开关。新功能的代码虽然已经发出去了，但会先藏在一个功能开关的后面。这个开关一开始只对 Anthropic 自己的员工打开，普通用户还用不了。等内部员工用了一段时间，确认没有问题了，才会把开关对所有的用户打开。那为什么先给内部员工使用呢？因为 Anthropic 的员工每天都在大量地使用 Claude Code，很多问题在普通用户碰到之前就已经被他们发现并解决了。所以说等功能真正到了用户手里的时候，就已经是一个比较稳定的状态了。 再说逐步上线。 Cloud Code 有两个发布渠道：latest 是最新版，stable 是稳定版。新版本会先发到 latest，让喜欢尝鲜的用户用起来。然后过一段时间，一般是一个周左右的时候，Cloud Code 团队确认这个版本没有什么大问题了，才会把它推送到 stable 渠道上。 最后是观察和回滚，也就是尽快发现，尽快撤回。如果上线之后出了问题，一般有两种处理方法。一种是关闭开关。前面说过，新功能上线的时候，大多数是带着功能开关的，所以如果出现了问题，我们可以直接远程关闭开关，这个是最快的修复方案。第二种是重新发布。当开关解决不了的时候，我们就需要重新构建一个没有问题的版本，然后发布上线。 好，四个阶段讲完了，我们回头看一下：PR 前有确保正常运行、检查代码质量；PR 中有 CI、AI 审核、安全审核和按风险审批；合并时有合并队列；合并后有设置功能开关、逐步上线，还有观察和回滚这几个功能。 我们来做个假设：假如一个改动里面藏着个 bug，我们看一看他要闯过多少道关，才能够真正跑到用户手里。首先是在 PR 前这个阶段，AI 会先跑一遍测试，确保产品能够正常运行，然后再开一个全新的 agent 检查代码质量。如果这两步都没有发现的话，那到了 PR 中这个阶段，CI 会把几十项检查跑一遍。如果 CI 没有拦住的话 还有 AI 审核。AI 审核也没有发现的话，后面还有安全审核。接着呢，还要按风险审批。如果改的是重要代码，那还得有人亲自来看一看。就算这些都过了，到了合并时，合并队列还会在最新的主分支上再测一遍，把那些和别人改动合在一起才会出现的 bug 给拦下来。要是这一步也没有拦下来的话，到了合并后，首先会设置功能开关，先对每天大量使用 Cloud Code 的内部员工开放。很多问题呢，在这个阶段就会被暴露出来。如果内部使用也没有发现的话，接下来还会逐步上线，先发布到 latest 渠道，用一段时间确认没有问题之后，再推送给 stable 渠道的用户。哪怕这个 bug 一路落到了用户手里，最后呢还有观察和回滚。团队呢会持续观察运行情况，一旦发现问题，马上就能够关掉功能开关。如果开关解决不了的话，我们还可以通过回滚来处理。走完这一圈，你会发现，在这些关卡里面，其实没有哪一道是绝对完美的。单看任何一步的话，都有可能会漏掉问题。但是把它们串在一起，层层把关，一个 bug 想一路混到用户的手里，就非常难了。而且你看啊，这些关卡里面，除了重要代码需要人来审批之外，其他几乎都是机器和 AI 在自动完成。所以看完全文，我的感受就是，他们设计的这一整套流程，其实都是围绕同一个目标，那就是在保证产品质量的前提下，尽量减少人的参与。 毕竟无论怎样，人的时间和注意力才是最宝贵的东西。好，既然人的时间和注意力如此宝贵，那它们花在哪里才最合适呢？换句话说，在整个流程里面，人最需要做的到底是什么呢？这篇文章里面列举了五点，我们来挨个看一下。 第一点，判断哪些事该做。像是产品的方向、品味，还有功能的范围，这些东西都是机器判断不了的，还是得人来做决策。 第二点，审核高风险代码。比如计费、自动更新，还有一些 CI 的配置，这些地方一旦出现问题，影响就非常大了，所以还是得有人亲自盯一下才行。 第三点，把关架构设计。架构这个东西一旦定下来，就像是给后面的代码立了一个样板，以后不管是人还是 AI，在写类似的功能的时候，都会照着它来写。如果这个样板本身就定错了，那这个错误就会被照抄到一处又一处，很快就能蔓延开来。所以这种会被别人照着写的架构改动，必须由人来把关。 第四点，阅读相关的证据。以前审核的时候，人要看的是每一行代码，但是现在主要看的是相关的证据，比如测试的输出、运行的命令、返回的结果、产品的截图，还有 AI 的发现之类的。人要做的就是看这些证据够不够充分，然后再根据这些证据决定下一步要做什么。 第五点，为结果负责。现在代码虽然都是 AI 写的，但是不管代码是谁写的，一旦发布上线，肯定都是要有一个人为它负责的。 AI肯定不能帮人来比过嘛。好，到这里，整套流程呢，我们就讲完了。最后啊，我再随便聊几句。 我记得去年的时候啊，很多人还在讨论AI写代码到底靠不靠谱。很多人当时还觉得AI写出来的代码呢，基本都是垃圾，真正代码还是得靠人来写。但是到了今年，这样的声音已经少很多了，因为AI写代码的能力确实一天比一天强。如果你还在坚持用古法编程的话，你是很难跟那些用AI写代码的人竞争的。 在这种情况下，大家发现写代码不难了，真正让人头疼的变成了另外一个问题，那就是该如何审核AI写代码，如何能够保证AI写出来的产品质量是符合预期的。SRFP的这篇文章呢，我感觉是给出了一个比较实在的答案，而且从结果上来看，这套流程确实还是挺靠谱的。 克劳蔻团队呢提供了一组数字，他们是说啊，六月到九月的这段时间里面，他们合并的PR呢，翻了一倍还多，但是呢需要回滚的比例呢，反而是下降了百分之四十以上。换句话说，就是代码合得更多了，但出问题的比例却更少了。 我们仔细想想，虽然这篇文章讲了很多，不过呢我感觉它最核心的一个方向呢，就是重新划清人和AI的分工。AI呢是负责大量的执行工作，比如说是什么写代码呀、跑检查呀、找问题呀之类的，而人呢只负责最关键的决策，比如说是这个需求该不该做、要用什么架构，或者是出了问题谁来负责等等。 这个让我想起了我之前出的一个讲harness engineering的视频。在那个视频里面，我给大家详细解释了OpenAI写的那个harness engineering的文章。这篇文章里面有一句话说得特别好，我当时也给大家着重强调了一下。这句话就是human steer agents，翻译过来就是人来掌舵，AI来执行。你看啊，不管是SoloPic还是OpenAI，最后走的都是同一个方向。所以再回到开头的那个问题，如何审核AI写代码。表面上它好像是在问审核的方法，但是往深了一层想，它真正想问的可能是怎么把人有限的注意力用在最关键的地方。SRP给出这条流程，可能不是最终答案。随着大模型越来越强，流程可能还会发生一些变化，但是我觉得总体的方向应该是不会变，那就是能交给AI的尽量交给AI，人呢就把时间花在那些最重要的决策上。这或许不光是代码审核的答案，也是整个软件开发接下来的方向。好，本期视频到这里就结束了，我是马克，我们下期再见，拜拜。