Richard Teachout // Teachout.com
← 全部文章

CTO 停止阅读 code 的那一刻——以及为什么这不再是正确的恐惧

Richard Teachout
Richard Teachout Ashley Furniture Industries 首席技术官 —— 高管级技术领导者、创业者、AI 领导者、架构师、问题解决者、前开发者。 2026 年 8 月 12 日
AI 领导力
CTO 停止阅读 code 的那一刻

有一条被反复传颂了几十年的传统 CTO 智慧:

你停止阅读 code 的那一刻,你就开始做出糟糕的技术决策。

我自己也说过这句话。

我见过许多才华横溢的工程师一步步成为总监、副总裁,最后成为 CTO。他们的日程被战略会议、董事会、供应商谈判、招聘、预算、并购和组织设计塞满。他们写的 code 越来越少,最终彻底不再阅读 code。

六个月后,他们就只能依据架构图、高管摘要和供应商演示来做平台决策了。

糟糕的技术决策就是这样产生的。这条建议之所以完全成立,是因为软件向来会惩罚与现实脱节的人。如果你看不到工程师实际在构建什么,你就会失去直觉,不再能识别出那些意外的复杂性。

你低估了技术债务。

你批准的那些架构在 PPT 里优雅动人,却在生产流量下轰然崩塌。阅读 code 不只是为了熟悉语法,而是为了与现实保持连接。在我职业生涯的大部分时间里,我都对此深信不疑。

而今天,我认为这种说法并不完整。不是因为理解系统变得不重要了,而是因为 AI 从根本上改变了我们获得这种理解的方式。

阅读 code 从来不是目标

说句实话,没有人是因为喜欢阅读四千行的类而当上 CTO 的。我们读 code,是因为它是理解一个系统唯一可靠的途径。如果你想弄清认证到底是怎么运作的……你就顺着请求往下追。

如果你想弄清为什么库存偶尔会死锁……你就去追踪执行流程。

如果你想判断某个提议的架构是否切实可行……你就亲自深入实现细节。

阅读 code 不是目的,理解才是。过去这两者其实就是一回事。直到现在。

AI 改变了理解的成本结构

大型 codebase 已经复杂到任何单一个体都无法完全掌握。现代企业日常管理着数百个代码仓库、数千个微服务、数百万行 code、多种编程语言,以及数十年累积下来的技术债务。

即便是一位出色的 CTO,也无法靠人工理解每一个重要的交互。问题不在于智力,而在于带宽。

AI 改变了这个等式。我不必再阅读成千上万个文件、寄希望于从中发现规律,而是可以提出那些原本需要团队花上好几天才能回答的问题。这不是因为 AI 取代了工程判断力,而是因为它极大地加速了技术发现。

这是一个重要的区别。AI 并不做架构决策,它帮助我更快地得出更好的决策。

我每周使用 AI 的五种方式

人们常问我这在实际中到底是什么样子。以下是我最依赖的几种模式。

1. 智能体式 code 探索。 我不必再打开几十个文件,而是交给一个 AI 智能体一项具体的调查任务——梳理每一个服务之间的认证流程,标出身份是在哪里被隐式传播的。几分钟后,我就得到了执行路径、隐藏的依赖、隐式的假设以及潜在的安全隐患。过去需要多名工程师花上好几天的事情,如今变成了一场交互式的对话。

2. 架构依赖分析。 软件中最难的问题,看似简单得出奇:如果我们改动这里,什么会坏掉?如今,AI 能把仓库分析、依赖图、API 契约、事件流、基础设施配置和集成测试,整合成一份按优先级排序的影响评估。

3. PR 分诊。 我不再假装自己会阅读每一个 PR。每一项重大改动都会经过 AI 审查——它是否违反了架构模式、引入了安全隐患、泄露了业务逻辑、增加了耦合度?那些值得高管关注的一小部分改动,会自动浮到最上面。

4. 技术债务热力图。 技术债务会形成模式,而 AI 能够识别出那些与未来生产事故相关的集群:不一致的重试策略、缺失的可观测性、循环依赖、脆弱的错误处理。我不再问"我们应该在哪里改进?",而是问"六个月后,我们最有可能在哪里尝到运营上的苦头?"

5. 架构决策模拟。 在重大迁移之前,我会让 AI 模拟可能的结果——不是为了预测未来,而是为了暴露假设、瓶颈、故障模式和组织依赖。它无法消除不确定性,但它能让不确定性变得可见。

AI 不会取代技术领导力

每当我谈到这个话题,最终总会有人说:"但 AI 会犯错啊。"没错,人也会犯错。区别在于,我从不把判断力外包出去,我外包的只是调查工作。

我仍然会质疑结论,仍然会验证假设,仍然会向工程师提出尖锐的问题,仍然要求拿出证据。最终的架构决策仍然由我来做。AI 只是确保我在起步时就拥有比我单靠自己所能合理收集到的更多的信息。这是增强,而非自动化。

CTO 的工作已经改变

我不再相信 CTO 的最高价值来自成为最优秀的程序员,而是来自提出最犀利的技术问题:风险在哪里?哪些本不该耦合的东西耦合在了一起?哪些假设被隐藏了?明年我们会在哪里陷入困境?

AI 极大地增强了我回答这些问题的能力。这并不会让工程专业知识贬值,反而让杠杆效应变得更有价值。

真正的竞争优势

十年前,最优秀的 CTO 往往比任何人都更懂 code。而明天,最优秀的 CTO 将比任何人都更懂系统。这两种并不是同一种技能。

理解系统,意味着把技术连接到运营上,意味着在规律演变成故障之前就识别出它们,意味着纵观数百个仓库而不是只成为某一个仓库的专家。AI 让这种层级的洞察成为可能。忽视它并不能保住工程纪律,只会限制领导力。

新的恐惧

多年来,我们担心的是那种不再阅读 code 的 CTO。那是一个合理的担忧。而今天,我担心的是另一件事。

我担心的是那种仍然相信手工阅读 code 是理解系统唯一途径的 CTO。

技术领导力从来都是关于提升杠杆效应。编译器取代了汇编,框架取代了样板代码,云平台取代了机房。AI 不过是这一演进中的下一步。目标从未改变:足够深入地理解你的系统,以便做出更好的决策。改变的,是我们达成这一目标的方式……

拥抱 AI 的 CTO 不会对自己的技术懂得更少,反而会懂得比以往任何时候都更多。

觉得这套论述适合你的活动吗?跟我说说那个场合—— 日程是有选择的.

开始对话
English简体中文Tiếng Việt