AI时代，平台工程团队该何去何从？

这个周末天气不太好，所以没去打高尔夫。 于是我就抽空读了几本书。我读了马丁·福勒的《六月片段》（martinfowler.com/fragments/2026-06-02.html）， 这本书里有不少精彩的帖子，其中有一篇特别能激发我的思考：杰米·赫斯特的博客文章——《jamiehurst.co.uk/2026-05-24_ai-sustainable》， 从一位首席工程师的视角出发，探讨了人工智能辅助工程这一话题。

我很喜欢他的见解，而这些观点也与我在工程领导岗位上、以及在自己团队中所见到的情况不谋而合。 在我职业生涯的二十多年里——包括目前的职位在内——我一直在平台工程领域工作， 甚至几乎一直从事平台工程相关的工作。 这让我开始思考：如今，随着各团队能够以极快的速度进行原型开发——甚至在没有真正完成开发的情况下就“造出”自己的软件——我每天都在目睹哪些影响？

什么是平台团队？

以防还有人不太清楚“平台团队”究竟是什么——当然，为了确保我们大家都能理解得清晰一点， 即使你并不完全明白——我将平台团队定义为：任何为内部客户（也就是公司内部的用户）提供服务的工程团队。 这个定义相当宽泛，而且我也知道，难免会有些“吹毛求疵”的地方。 不过，现在我们就先简单点说吧，好吗？

平台职能存在的原因在于：它负责将一些通用且可复用的能力集中化管理，而如果让每个团队都自行构建这些能力， 往往并不划算。我们所打造的能力，很多时候其实都是商品化的抽象层——所谓“商品”， 就是如今司空见惯、甚至是“理所当然”的各类服务，比如存储、计算、网络、消息系统、 构建与部署等。过去，我们常常遵循“80:20法则”：我们主要面向大多数用户和使用场景进行开发与支持， 而少数用户则可以选择走一条不同的路径，尽管他们可能会在某种程度上面临被忽视的风险。

其实还有一个更重要的原因。即便开发这些功能的成本为零，大多数产品工程师也不愿意承担起运行这些功能所需的认知负担： 版本升级、下班后的技术支持、未来路线图的规划与调整……将这些功能集中化管理， 意味着由其他人来承担这些重任。

故事时间：戴夫叔叔

我喜欢类比，也喜欢图片。我经常想起的一个比喻是：平台团队就像在通往你目的地的路上，修建了一条铺得十分平整的高速公路。我们让无数人轻松抵达目的地，全程无需费心。 当然，你仍然可以自己步行前往，甚至我们还会给你一把砍刀，好让你能一路劈开灌木丛，开辟出属于自己的小路。不过，这条路会更慢，也更难维护。 相反，如果我们发现有相当一部分用户选择走上那条荒野小径（也许是因为我们那条平坦的公路拐了个弯，或者走起来太慢，根本无法快速抵达目的地），那么我们就可以适时介入，与当初修建这条小径的人聊聊，主动提出派我们的施工人员和沥青铺设设备前来，拓宽并整修这条小径；同时，我们也会承担起后续的维护与保养工作。

然而，如今人工智能改变了这一类比。用户不再需要砍刀，而是拥有了人工智能推土机。 如果他们选择不走我们的高速公路，只需驾驶推土机穿行于荒野之中，直达目的地——留下一条依然颇为崎岖的土路， 但总比那条老旧的荒野小径要好得多。

我们正在做出的一项重要转变——也是稍后会详细说明的——是推出更低层级的 API。不妨这样想：在这一全新的“人工智能推土机”时代，我们不再像从前那样直接分发砍刀，而是转而致力于为用户提供道路铺设机器，让他们用这些机器来替代那些略显“农业化”的推土机。在项目早期就与用户紧密合作，意味着我们最终建造的将是一条铺装好的道路，而非泥泞的小路。这样的道路更容易维护，也因为我们在前期提供了机械设备和建筑材料，让道路达到了一个明确的“优质”标准；而在未来，若我们最终接管这条道路的运营权，也不会像以往那样需要进行大规模的“搬移式”改造。 “一次性开发”的理念正逐渐失去市场

我之所以说“我们曾经遵循‘80:20法则’”，是因为我认为，在人工智能时代， 这一法则正在悄然改变。软件系统的开发成本正在不断下降，因此，那些主张组建专门团队来集中管理常见软件需求的论调， 正逐渐失去市场。原因在于：既然现代模型的强大算力和并行代理执行技术已经让我们能够轻松地在一天之内自建一套全新的库， 又何必再等待我们为某个通用推理运行时库添加新功能呢？ 这的确是一个值得深思的问题。虽然任何经验丰富的工程师都会告诉你，真正的成本并不在于前期的开发投入， 而在于多年来的总拥有成本；但“干脆自己动手打造”这一想法，对许多人来说依然极具吸引力。 不过需要注意的是，仅仅依靠低成本的开发方式，只会削弱平台团队成立的首要理由——即减轻用户的认知负担。 而当更多功能得以实现时，这种“减轻认知负担”的优势反而会愈发凸显：随着功能越来越多， 你需要记住的内容也就越多，而你大脑中的信息量也随之增加。

当然，这并不是说我们应该抗拒这种趋势。 如今，人们越来越常说：“一个可用的演示，胜过一千份设计文档！ ”（而且，这通常还省时不少！）确实如此——所以我们应该拥抱那些临时搭建的原型， 以及通过代码实现的“氛围感”演示。只是我们需要找到一种可持续的方式，避免陷入“影子IT”的困境。 目前，这种方式需要更多的面对面沟通——更多一对一的交流，以及与用户进行的对齐会议。 至于这种模式是否可行、是否是处理这类问题的最佳方案，我还不太确定，但至少相比几个月前， 这种方式的感觉要好得多。我想，推动这些额外一对一交流的原因之一，就在于我们过去常常免费获取这些资源。 工作是通过各种提案、对齐请求，以及需要我们签字确认的设计文档而“送到”我们面前的。 虽然过程可能更缓慢，但这也意味着我们清楚地知道接下来会发生什么。 而“先做演示”这一做法，则在很大程度上消除了这些信号。

API，无处不在 从更实际的角度来看，道路铺设机器的理念，其实就是我们将平台视为 API 提供者，而不是一味追求打磨得完美、功能齐全的产品。我们依然会为一些面向最终用户的功能进行开发与维护，但我相信，未来我们会更多地提供低层级的 API 和抽象层——也就是那些作为基础构件，供我们的客户在决定自行打造专属解决方案时加以利用。我们还可以借此机会，将安全、性能、合规性、可观测性、可靠性等诸多要求一并纳入设计之中。 “内部源码贡献”再次变得很酷 我还没有看到太多关于如何将用户新近获得的、借助人工智能加持的高效生产力，转化为直接参与我们备受珍视的解决方案的讨论——例如“黄金路径”（platformengineering.org/blog/what-are-g...来构建内部系统，以促进协作、提升交付速度，并减少因阻塞或“守门”而导致的停滞。

如今，要想做好内部源码贡献，我认为有几件事需要改变。首先，我们必须认识到：如今的变化速度（也就是向我们提交的 PR 数量）很可能远高于“旧时代”，因此我们需要想办法优化评审与合并的效率。（这其实是当今整个行业的共同难题，我并不认为它已经完全解决，而且也超出了我这些浅薄的思考范围。） 其次，也是我们能更好地掌控的一点：我们要确保我们的代码仓库能够应对“代理式攻击”——具备完整的 README 文件、AGENTS 文件、SPEC 文件以及 CONTRIBUTION Markdown 文件，也就是为机器阅读而精心编写的高质量文档。人类确实不太擅长“RTFM”（“Read The F*** Manual”），但无论你怎么评价人工智能，至少它们（大多情况下）会在被“塞进”虚拟鼻孔时，认真阅读文档。而现在，你重新获得了部分控制权；你可以告诉代理们如何组织 PR，哪些变更会被批准、哪些不会，以及这套系统的战略路线图是什么，从而确保新功能的方向正确，或者至少不会被我们这边的人工智能评审机器人直接否决。😅

我还没想通的疑问 我尚未下定决心的是：这种转变，到底是真的更快，还是只是感觉更快？另外，正如我之前所说，这种转变在长期来看是否可持续？不过，最近我确实看到了更多务实的讨论——希望我并没有只身处某个小小的回音室里。（慈善·马乔斯的新文章“AI 需要更多工程学科”中，有一句充满希望的话：“我觉得 2026 年有望回归到‘纪律’的时代。”（顺便说一句，我超爱她每一篇帖子里的贴纸艺术！） 那么，我最后想用一个问题来结束今天的分享，而不是停留在空洞的陈词滥调上。如果你的团队能在短短一个下午内，就搭建好自己的工具，并且只在之后才向你汇报进展——甚至在某些情况下根本不会向你透露具体成果——那么，你在接手这些工具之前，是如何了解它们究竟在做什么？又是如何监控它们的运行状态、保障其安全性和稳定性等等？而且，你能否做到在不让人觉得像是在窥探或追逐自己的客户的情况下完成这一切？如果你已经找到了答案，那就请随时告诉我——linkedin.com/in/dcurlewis 我非常乐意倾听你的想法！

祝好， 戴夫