Claude 这篇分享，让我重新理解了 AI 原生团队 #AI #大模型 #gpt #claude #AI新星计划

Hello 朋友们，今天来分享一篇文章，是来自Cloud团队最近发出的一份他们内部的方法论，我看完之后感触很深。 因为这篇文章对我来说，不只是看一家AI公司怎么用AI，而是让我重新思考了一个问题。 当AI真的进入工程团队之后，团队最需要改变的到底是什么？ 我觉得这里面最关键的一个判断就是瓶颈转移。 过去很多年，软件工程里的大部分流程本质上都是围绕一个前提建立的，就是写代码很贵。 工程师的时间贵，代码产出慢，所以我们要提前规划，要写设计文档，拆需求，做排期，排评审，还要尽量避免返工。 这些流程并不是没有意义，它们在过去确实解决过很多问题。 但是当进入到了AI编程时代，尤其是到了Cloud Code这类工具已经深度参与研发之后，这个前提开始发生变化了。 Cloud团队提到，现在真正拖慢他们的已经不再是写代码、写测试或者构建了。 现在瓶颈变成了验证、Code Review、安全，以及团队能不能跟上代码的产出速度。 这个判断我觉得非常正确，因为很多人聊AI编程，还停留在它能不能帮我多写几行代码这一层。 但如果站在团队视角来看，问题已经不是代码能不能写出来，而是代码写得太快之后，我们有没有能力去判断它是对的。 以前卖的是生产，现在卖的是验证，这是变化的核心。 所以Cloud团队做的第一件事就是重新来规划。 他们以前也做过很完整的长期Roadmap，但很快发现AI工具和工程效率变化太快了。 几个月前写下来的计划，现在可能已经跟不上真实的情况了。 所以他们现在更强调just in time planning，也就是在真正需要的时候做恰好足够的规划。 这不是说不要规划，而是不要迷信那种一开始就把所有事情都写死的规划。 在AI时代，很多事情与其写一大堆文档，不如先做一个可以验证的东西。 因为当构建成本变低之后，讨论的方式也应该发生变化。 以前我们可能为了一个方案吵很久，写PPT、开评审、反复对齐。 但现在更好的方式可能是先把它做出来，看真实的效果，再决定要不要继续做。 我很喜欢这里面的一个思路，就是做东西变便宜了，争论反而变贵了。 这句话其实很适合我现在自己的团队。 因为很多时候，团队真正浪费的不是写代码的时间，而是在没有实物之前反复争论想象中的问题。 接下来的变化就是自动化。 文章里面有一个我很认同的习惯，他们每遇到一个重复的问题都会继续追问一句。 这件事情能不能自动化？ 我觉得这可能是AI原生团队和普通团队最大的区别之一。 不是说大家都买了Cloud会员，也不是每个人都开始用AI写代码，就叫AI原生了。 真正的AI原生是你开始用AI重新审视整套的工作流。 过去是因为自动化的成本非常高，所以只有高频、稳定、明确的事情才值得做自动化。 但现在不一样了，AI把很多小型自动化的成本打下来了。 对于过去很多懒得做自动化的事情，现在都值得重新看一遍。 我自己也越来越觉得，以后团队里面不应该只问这个问题谁来处理， 而是应该多问一句，这个问题下次能不能不用人来处理。 这个习惯一旦养成，团队的工作方式就会慢慢变了。 不是一下子搭一个特别宏大的系统，而是从一个个重复动作开始，把那些不消耗人的事情一点点拿掉。 第四个变化是Code Review。 Cloud Code团队提到一个原则，叫Trust But Verify，信任但是要验证。 这个原则我觉得非常准确，AI可以承担更多标准化的Review工作， 比如说代码风格、明显的Bug、测试补充、问题反馈。 这些事情以前会消耗大量的人力，但本质上并不需要人的高级判断。 但是人类Review并不是消失了，而是位置变化了。 人真正要看的是业务逻辑是不是成立，安全边界是不是合理，系统设计能不能长期维护，产品体验是不是符合预期。 所以AI不是替你省掉了Review，而是逼你重新定义Review。 以前Review更像是在看代码有没有写好，以后Review更像是在判断这个结果到底是不是对的。 而且这里还有一个很现实的问题，这个边界不是固定的。 比如说今天必须要人来判断的事情，可能下一个模型的版本就能做一部分了。 所以团队要持续地重新评估，哪些判断必须由人来做，哪些事情可以交给AI来先做。 第五个变化是团队角色开始模糊。 文章里面提到，在Cloud团队里，PM也会写代码做原型，工程师也会参与内容设计和产品判断。 我觉得这件事情不是说每个人都要变成全能的选手，而是说AI把很多执行层的门槛降低之后，团队对人的要求变了。 以前一个人的价值可能更多的体现在我能不能把这块任务完成，但以后更重要的可能是你能不能围绕一个问题快速地把想法变成可验证的结果。 所以他们提到，未来更稀缺的不是打字速度，也不是单纯的代码产出，而是产品感、判断力、系统理解能力和品位。 这个观点我非常认同，因为当AI能把执行速度提高很多倍之后，真正拉开差距的不是你写代码有多快，而是你知道该做什么，知道什么样的结果才算好，也知道哪里可能会发生错误。 第六个变化，是主动删除旧流程，这点我觉得特别重要，因为很多团队的问题不是没有新的工具，而是旧流程一直没有被拿掉。 我们很容易在旧流程上面继续叠新流程，以前有周会，现在加AI周报；以前有评审，现在加AI总结；以前有文档，现在再加一层自动生成文档。 看起来是非常智能的，但团队反而更累了，因为真正的问题不是工具不够，而是流程没有重新设计。 好团队有一个很好的思路：找到你最吵、最贵、最让人不想做的工作流，然后问它一句，它现在还配继续存在吗？ 我觉得这句话特别值得每个团队拿回去用，很多流程不是一开始就错的，它们可能曾经很有价值，只是环境变了，团队的工作方式变了，它们却还留在那里。 而如果没有人主动站出来说，那它就会一直消耗团队。 所以我看完这篇文章最大的感受是，AI原生组织里面不是简单的让每个人用AI，真正改变的是组织里的成本结构。 当代码生成变便宜之后，团队最贵的东西变成了判断力、上下文、验证能力、系统设计能力，以及主动改变流程的能力。 这也是我觉得很多团队接下来会遇到的分水岭，一类团队会把AI当成更快的打字机，继续塞进原来流程里面。 而另一种会重新思考规划方式、Review方式、支持共享方式，还有角色分工，甚至会主动干掉原来很多看起来理所当然的流程。 这两类团队最后差距可能会非常大。 所以说，如果你也在团队里面用AI，或者你正在尝试把AI接入自己的工作流，我建议你不要只问AI能不能帮我写代码。 你更应该问，我的团队里哪个流程已经不适合AI时代了。 是规划太重、验证太慢，还是支持同步太低效，还是有些会议和流程早就没有存在的必要了。 我觉得这可能才是Cloud团队这篇分享最有价值的地方。 它不是在告诉我们一个标准答案，而是在提醒我们，AI带来的变化不只是工具层的变化，而是整个团队工作方式的变化。 这件事情不用一步到位，但一定要开始做。 如果说你也对这种AI原生团队的工作方式感兴趣，欢迎在评论区聊聊。 我是布鲁，你的AI好搭档，我们下期视频再见。