潘锦的空间 » CTO

作为 CTO，应该如何看待 AI 编程

admin — Sun, 10 Aug 2025 01:09:38 +0000

前段时间和几个技术圈的朋友吃饭，聊到最近很火的 AI 编程工具（Cursor 估值近百亿），大家的深入程度都各不相同。有人已经把 Cursor 当成标配，离了它写代码都不太行；有人还在观望，觉得这玩意儿不太靠谱；有人在团队内小范围试点，看一看；有人怕有风险，不敢在团队内推广（不仅仅是安全风险，还有组织内部的一些问题）。

作为技术负责人，面对 AI 编程这个话题，确实挺纠结的。一方面，这东西确实能提效（但不能只盯着提效这个逻辑），另一方面，各种担心也不是空穴来风。今天想聊聊，站在 CTO 的角度，到底该怎么看待和处理这个事。

先说说目前我观察到的几种典型态度。

四种常见的应对策略

第一种是ALL IN 派。这一派通常有几个特征：要么是连续创业者出身，习惯了快速试错；要么是 AI 的忠实信徒。在性格上，他们会偏向冒险一些，相信「天下武功唯快不破」。

从公司规模来看，这种策略多见于 50-200 人的成长期公司。为什么？因为这个阶段的公司正处在生死时速，既有一定的资源去尝试新东西，又还没有大公司那么多条条框框。CTO 往往直接向 CEO 汇报，有较大的决策权。他们的逻辑很简单：如果 AI 真能让研发效率翻倍，那就是弯道超车的机会。

但这种激进往往源于一种可能被时代抛弃的焦虑。刚经历过移动互联网时代的洗礼，深知错过风口的代价。所以看到 AI 编程工具，第一反应就是不能再错过了。

第二种是坚决抵制派。这一派往往技术功底深厚，可能是从程序员一路做上来的。他们可能写过操作系统，造过各种轮子，对代码有种近乎偏执的掌控欲。在他们眼里，让 AI 写代码就像让机器人替你谈恋爱，总觉得少了点什么，没有灵魂。

并且这种策略常见于两类公司：一是金融、医疗等强监管行业的大公司，动辄上千人的技术团队，任何技术决策都如履薄冰；二是某些技术驱动的独角兽，公司文化中有很强的工程师自豪感，「我们的代码都是艺术品」。

换个角度看，这种抵制其实是一种保护。保护什么？保护既得利益，保护现有体系，更重要的是保护自己的价值认同。当你花了二十年时间成为编程高手，突然有人告诉你 AI 十秒钟就能写出差不多的代码，这种冲击是巨大的。抵制，某种程度上是在对抗这种价值崩塌。

第三种是建立预期后科学推广。这一派通常是职业经理人出身，可能有 MBA 背景，擅长做 PPT 和汇报。他们的特点是理性、谨慎、程序正义。什么事都要有方法论，有流程，有数据支撑。

这种策略在 500-2000 人规模的成熟公司可能会比较常见。为什么？

因为船大难掉头。这个体量的公司，往往已经有了完整的研发流程、质量体系、安全规范。任何新工具的引入都需要考虑对现有体系的影响。CTO 的 KPI 里，「稳定」的权重往往大于「创新」。

但问题在于，「科学」有时候会变成「科学主义」。制定了详尽的试点方案，设计了完美的评估指标，组织了多轮评审会议，最后发现三个月过去了，还在讨论试点范围。等到真正推广的时候，市场上已经有更新的工具了。这种「理性」背后，其实是一种精致的不作为。

第四种是躬身入局派。这一派有个特点：有比较强的好奇心。他们是一些爱折腾的技术。看到新工具，第一反应不是评估风险或收益，而是「让我试试看」。

这种人通常出现在两种场景：一是 20-50 人的初创公司，CTO 还在一线写代码，甚至就是技术合伙人；二是某些特别重视技术文化的中型公司（200-500人），虽然 CTO 不用写生产代码了，但还保持着 hands-on 的习惯。

其实，这一派的逻辑很朴素：没有调查就没有发言权。与其听别人说，不如自己试。这种实用主义的背后，往往是对技术的真正热爱和对未知的好奇。他们不会被各种宏大叙事忽悠，也不会因为恐惧而止步不前。

无论采取哪种策略，团队里总有人在用 AI 写代码。就像当年公司禁用 QQ，大家就用网页版；禁用网页版，就用手机。技术的渗透往往是自下而上的，任何自上而下的管控都可能流于形式。

需要考虑的核心问题

站在 CTO 的位置，引入 AI 编程工具不是简单的技术选型，而是一个系统性决策。至少要考虑这几个维度：

成本问题。表面上看，AI 工具能提高编码效率，降低人力成本。但别忘了，工具本身也要钱。Cursor 企业版每人每月 40 美元，且高级模型大概率是不够用的，全公司算下来也是笔不小的开支。更重要的是隐性成本：代码质量下降带来的维护成本、安全漏洞带来的修复成本、团队能力退化带来的长期成本。

安全问题。这可能是大家说得最多的问题。你的代码会不会被上传到 AI 服务商的服务器？会不会被用来训练模型？竞争对手会不会通过某种方式获取你的核心算法？这些都不是杞人忧天。特别是对于金融、医疗等敏感行业，数据安全是红线，碰不得。虽然类似于 Cursor 有隐私模式，但这个隐私模式真的隐私吗？或者说这里定义的隐私的边界是什么？

稳定性问题。AI 生成的代码看起来能跑，但真的稳定吗？边界条件考虑了吗？异常处理完善吗？性能优化了吗？很多时候，AI 给出的是「能用」的代码，而不是「好用」的代码。如果团队过度依赖 AI，很可能会埋下大量隐患。

技术债务问题。这是个更深层的问题。当团队习惯了「不求甚解」的开发模式，技术债务会像滚雪球一样越滚越大。代码结构混乱、命名不规范、重复代码满天飞，到最后谁都不敢动，只能推倒重来。

Jim Collins 在《从优秀到卓越》中有句话说得特别好：「轻率地依赖技术是一种债务，而不是资产。」只有当技术服务于清晰的概念和目标时，才能成为推动力。否则，就是加速灭亡的工具。

我的实际使用体验

说实话，这一年多我自己也在大量使用各种 AI 编程工具。从 Cursor 到 Trae(因为 Cursor 不让我用高级模型了)，从 ChatGPT 到 Claude，基本上市面上的工具都试了个遍。体验下来，确实有种「Vibe Coding」的感觉——写代码变快了，做项目没那么费劲了。

但慢下来思考，内心其实有点恐慌。

为什么恐慌？不是工具不好，而是我发现自己在变懒。遇到问题，第一反应不再是分析问题、设计方案，而是想着「怎么让 AI 帮我写出来」。这种思维模式的改变，其实挺可怕的。

以前写一个 API，我会仔细考虑接口设计、参数校验、异常处理、性能优化。现在呢？一句 prompt，AI 啪一下就给你生成了。代码能跑，功能也对，但总觉得哪里不对劲。等你想改的时候才发现，你压根不知道它为什么这么设计，改一个地方，可能会影响十个地方。

还有更可怕的，随着时间的流逝，这种依赖会形成惯性。你用得越多，越像在维护一份「外包」代码。只不过这个外包商是 AI，而你成了那个下需求的产品经理。

表面上看，你在主导 AI。实际上呢？你越来越依赖它，它也越来越多地接手决策。到最后你会发现，代码是它写的，架构是它设计的，你只是个「prompt 工程师」。

这让我想起一个段子：以前是「CV工程师」（复制粘贴），现在升级成「AI工程师」（AI写我调）。看似进步了，其实本质没变，都是不求甚解。

作为 CTO 的思考框架

那么，作为技术负责人，到底该怎么看待和使用 AI 编程工具？我觉得需要建立一个清晰的思考框架。

第一，明确 AI 的定位。AI 编程工具是助手，不是替代品。它应该帮助程序员更高效地实现想法，而不是替程序员思考。这个定位必须在团队内部达成共识，否则很容易走偏。

第二，建立使用边界。什么代码可以用 AI 写，什么不可以？我的建议是：

样板代码、测试用例、文档注释——可以大胆用
业务逻辑、核心算法、安全相关——谨慎用或不用
学习新技术、快速原型——可以用，但要理解原理

第三，强调代码审查。AI 生成的代码必须经过严格的 Code Review。不仅要审查功能正确性，更要审查代码质量、设计合理性、安全隐患等。千万不能因为是 AI 写的就放松标准。

第四，投资团队成长。这点特别重要。AI 工具的普及，对程序员的要求不是降低了，而是提高了。以前你只需要会写代码，现在你需要会判断代码好坏、会设计系统架构、会解决复杂问题。这些能力不是 AI 能替代的，反而因为 AI 的存在变得更加稀缺和重要。

具体的实施建议

如果你决定在团队中引入 AI 编程工具，这里有一些具体的建议：

1. 先试点，后推广

不要一上来就全员推广。选择一两个小团队或项目先行试点，收集使用数据和反馈。试点期至少 3-6 个月，要关注这些指标：

编码效率是否真的提升了？
代码质量有没有下降？
团队成员的接受度如何？
有没有安全或合规问题？

2. 制定明确的使用规范

规范不需要太复杂，但一定要明确。比如：

哪些代码库可以使用 AI 工具
敏感代码和数据的处理原则
AI 生成代码的标记和审查流程
工具选型和采购流程

3. 加强技术培训

不是培训怎么用 AI 工具，而是培训如何在 AI 时代保持竞争力。包括：

系统设计能力
代码审查能力
问题分析和解决能力
对 AI 生成代码的判断能力

4. 建立反馈机制

定期收集团队使用 AI 工具的反馈，及时发现和解决问题。可以通过：

月度问卷调查
定期的分享会
1 对 1 沟通
代码质量数据分析

5. 保持技术敏感度

AI 技术发展很快，作为 CTO 要保持对新技术的敏感度。但也不要被各种营销话术忽悠，要基于实际效果做决策。

更深层的思考

站在更高的角度看，AI 编程工具的出现，其实是在重新定义程序员这个职业。

以前，程序员的核心技能是「把想法转化为代码」。现在，这个转化过程很大程度上可以由 AI 完成。那程序员的价值在哪里？

我觉得在于三个方面：

第一，定义正确的问题。爱因斯坦说过，提出问题比解决问题更重要。在 AI 时代，知道要解决什么问题、如何定义问题，变得更加关键。

第二，设计优雅的方案。AI 可以写代码，但很难设计出优雅、可扩展、高性能的系统架构。这需要经验、品味和全局思维。

第三，处理复杂的情况。现实世界的问题往往不是非黑即白的。如何在各种约束条件下找到最优解，如何处理各种边界情况和异常，这些都需要人的判断。

从这个角度看，AI 编程工具不是程序员的终结者，而是一次职业升级的机会。那些只会写代码的程序员可能会被淘汰，但那些会思考、会设计、会解决复杂问题的程序员，会变得更有价值。

对团队文化的影响

引入 AI 编程工具，不仅仅是技术决策，也会深刻影响团队文化。

学习文化的改变。以前遇到不会的，查文档、看源码、问同事。现在呢？直接问 AI。这种便利性是好事，但也可能导致浅尝辄止，不求甚解。作为 CTO，要引导团队保持深度学习的习惯。

协作模式的改变。当每个人都有 AI 助手时，pair programming 还有必要吗？code review 的重点是什么？这些都需要重新思考和定义。

价值认同的改变。什么样的程序员是优秀的？是 prompt 写得好的，还是系统设计得好的？团队的价值导向必须明确，否则容易迷失方向。

风险管理

作为 CTO，风险管理始终是重要职责。在 AI 编程工具的使用上，需要特别关注这些风险：

知识产权风险。AI 生成的代码可能包含其他项目的代码片段，存在版权风险。团队需要有意识地审查和规避。

依赖风险。如果团队过度依赖某个 AI 工具，一旦工具不可用或政策变化，可能会严重影响开发进度。

能力退化风险。这是最隐蔽也最危险的。当团队习惯了 AI 代劳，自主解决问题的能力可能会逐渐退化。等到真正需要的时候，才发现已经力不从心。

安全合规风险。特别是在金融、医疗、政府等行业，数据安全和合规要求很高。使用 AI 工具可能会触碰红线，需要特别谨慎。

一些实用的建议

最后，给正在纠结是否引入 AI 编程工具的 CTO 们一些实用建议：

1. 自己先用起来。不要只看网上别人的视频或他人分享的文章，自己深度使用至少一个月，持续的跟进更新，形成自己的判断和手感。

2. 小步快跑。不要想着一步到位，先从风险较小的场景开始，比如单元测试、文档生成等。

3. 数据说话。建立量化指标，用数据来评估效果，而不是凭感觉。

4. 保持开放。技术在快速发展，保持学习和调整的心态。今天的最佳实践，可能明天就过时了。

5. 关注人。技术只是工具，人才是核心。如何让团队在 AI 时代保持成长和价值，这是最重要的课题。

写在最后

作为 CTO，我们已经站在技术变革的前沿。AI 编程工具的出现，既是机遇，也是挑战。

机遇在于，它确实能提升效率，降低门槛，让我们能够更快地实现想法。挑战在于，如何在使用工具的同时，不失去核心竞争力，不积累技术债务，不触碰安全红线。

这需要智慧，需要平衡，更需要不断的思考和调整。

如果你已经在使用 AI 编程工具，不妨问问自己和团队：

我们是在利用 AI，还是在依赖 AI？
团队的核心能力是在增强，还是在弱化？
面对没有 AI 的场景，我们还能高效工作吗？

如果你还在观望，也不妨思考：

竞争对手都在用 AI 提效，我们不用会不会落后？
如何在保证安全的前提下，适度引入 AI 工具？
团队对 AI 工具的态度如何，有没有抵触或过度期待？

无论如何，保持清醒的头脑，做出适合自己团队的选择。

以 Jim Collins 在《从优秀到卓越》中话结尾：

轻率地依赖技术是一种债务，而不是资产。是的，只有合理地使用技术，让这种技术服务于一个简单、清晰、连贯并且已经被深刻理解的概念时，技术才会成为加速发展的根本推动力。相反，当技术没有被合理使用，只是被当作一个简单的解决办法，也没有被深刻地认识到它是如何与一个清晰连贯的概念联系在一起的时候，技术就是加速你灭亡的工具。

为什么90%的空降技术管理者都在做同一件事？

admin — Thu, 03 Jul 2025 01:50:30 +0000

最近和几个做技术管理的朋友小聚，聊到曾经各自入职后的第一个月在干什么，答案出奇的一致。

「盘家底。」

「梳理资产。」

「摸排现状。」

说法不同，但干的都是同一件事——技术资产盘点。

这些朋友有从大厂跳到创业公司的，有从创业公司到大厂的，有接手十几人团队的，也有管上百号人的。按理说，不同规模、不同阶段的公司，管理重点应该不一样吧？

但为什么大家不约而同都在做技术资产盘点？

这事儿其实跟公司大小没关系，跟一个更本质的东西有关——手感。

什么是手感

做技术管理，手感是个很玄妙的东西。

举个例子：团队和你汇报一个系统改造方案，说要花 3 个月，投入 10 个人。你如果此时心里犯嘀咕：这个时间是长还是短？人力是多还是少？如果你没有手感，你大概率会说：”方案不错，但能不能再优化一下时间？”

如果团队回复：”已经是最优方案了。”

然后呢？然后就只能批准了。或者再想其它办法来核实，但心里始终不踏实或者耗费时间。

这就是没有手感的典型表现。

手感是什么？是一种基于深度理解的直觉判断力。

有手感的状态大概这样的：

听到「数据库 CPU 占用 80%」，马上能判断是 SQL 问题还是数据量问题
看到「服务器 500 台」，立刻知道是不是合理规模
团队说「这个需求要一个月」，心里有数是真需要还是在放水
出现故障时，能快速圈定问题范围，而不是干着急

而没有手感的管理者呢？就像在迷雾中开车，处处都是未知，步步都要小心。

有手感的管理者，心里有地图，走到哪里都知道车怎么开。

当一个技术团队的管理者没有手感，你的每一个决策都依赖下属的汇报，而你提不出实质性的意见，这样，你的管理权威就会一点点流失，团队也就不好带了。

这也就是为什么空降管理者都急着做技术资产盘点——不是为了显得自己在做事，而是真的需要通过这个过程快速建立手感。

没有手感，你就不是在管理，而是在被管理

手感从哪里来

手感不是天上掉下来的，也不是靠看几本书、听几次汇报就能有的。

我曾经见过太多空降管理者犯同一个错误：急于证明自己。

刚到一个新环境，看到这也不合理，那也不规范，马上就想大刀阔斧地改革。结果呢？不是改革受阻，就是改出更大的问题。

为什么会这样？因为我们所看到的「不合理」可能是合理的。

听说过一个案例。一个朋友刚接手一个团队时，发现新团队的部署流程特别繁琐，一个简单的上线要过五六道关卡。他当时就想，这也太低效了，必须优化。

还好当时忍住了，先做了技术资产盘点。这一盘点才发现，这个「繁琐」的流程背后是血的教训——两年前因为上线流程太简单，出过一次重大故障，损失上千万。从那之后，团队宁可效率低一点，也要确保稳定性。

如果当时贸然「优化」，很可能会重蹈覆梯，当然，也可能不会，至少不要那么急着做事，先缓一缓，看清局势。

手感这个东西，来自于对系统的深度理解。而这种理解，对于一个新接手的管理者来说，可以通过技术资产盘点一点点建立起来。

技术资产盘点就像考古，我们得一层层挖掘：

这个服务为什么会存在？解决什么问题？
这个架构为什么这么设计？有什么历史原因？
这个配置为什么是这个值？踩过什么坑？
这些技术债是怎么欠下的？为什么一直没还？

每个不合理的背后，都可能有一个合理的故事。每个奇怪的设计，都可能是特定时期的最优解。

只有当我们了解了这些前因后果，才能真正理解这个系统，才能培养出那种「一眼就能看出问题」的手感。

这就是为什么技术资产盘点如此重要——它不仅仅是在清点家底，更是在建立我们对整个技术体系的认知地图。有了这张地图，我们才知道哪里能动，哪里不能动；哪里需要改进，哪里需要保持。

手感，就是这样一点一点积累起来的。

掌控感是管理的基础

做管理，最重要的是什么？是掌控感。

什么是掌控？不是说我们要事事插手，而是当出现问题时，能快速定位；当需要决策时，有充分的信息；当团队需要支持时，知道资源在哪里。

没有掌控感的管理者是什么样的？

技术评审时，只能听团队汇报，提不出实质性意见
出现故障时，只能在旁边干着急，帮不上忙
做预算时，不知道哪些该花哪些不该花
定目标时，不知道什么是合理的预期

这样的管理者，很难获得团队的信任和尊重。

而手感，正是掌控感的基础。

有了手感，才能在关键时刻做出正确判断。有了手感，管理才不是空中楼阁，而是脚踏实地。

这就回到了我们的核心问题：为什么空降管理者都要做技术资产盘点？

因为这是建立手感的最快途径，是获得掌控感的必经之路。我们可以慢慢熟悉团队，慢慢了解业务，但技术资产是实实在在摆在那里的，是可以快速盘点和掌握的。

当我们知道每一分钱花在哪里，每一个系统如何运转，每一个瓶颈在什么地方，我们就有了管理的抓手，有了改进的方向，有了说话的底气。

这，才是技术资产盘点的真正价值。

技术资产到底包括什么

很多人以为技术资产就是服务器、数据库这些硬件资源。其实远不止于此。

我把技术资产分为几个层次：

入口层：掌控用户的入口

域名是最容易被忽视的资产。

以今年 6 月初的阿里核心域名 aliyuncs.com 故障为例：6 月 6 日凌晨，阿里云核心域名 aliyuncs.com 遭遇罕见的域名劫持事件，导致其对象存储服务（OSS）、内容分发网络（CDN）以及云解析 DNS 等多项核心云服务出现大范围故障，波及众多依赖阿里云服务的网站和应用。

除此之外，各企业网站、学校网站等等都出现过域名导致的线上故障。

还有 SSL 证书，很多公司的证书管理一团糟，快过期了才想起来续，结果用户访问时浏览器报警，体验极差。

为什么要盘点入口？因为这是用户接触我们的第一步。域名解析慢了，用户可能就走了；证书有问题，用户可能就不信任了。这些看似小事，实则关乎生死。

接入层：了解流量的来龙去脉

负载均衡怎么配的？有没有做 DDoS 防护？WAF 有没有？规则合不合理？

我在上一家公司，一个月 CDN 账单接近百万，我在做技术成本优化的时候发现，是其接入策略有问题，使用的是 OSS 的流量计费，并且当月受到一些图床攻击。这种浪费，比比皆是。不盘不知道，一盘吓一跳。

还有一些业务上线了，基本的安全策略都没有，直接服务器裸奔在线上，最终被黑客侵入，变成「肉鸡」或矿机。

计算层：服务器不只是数量

“我们有 500 台服务器”——这个信息对管理者来说几乎没有价值。

真正有价值的是：

这些服务器的利用率如何？
是否存在资源闲置？
扩缩容策略是否合理？
有没有僵尸服务器在白白烧钱？

我曾经做技术资产盘点发现 30% 的服务器 CPU 利用率不到 10%。为什么？因为之前为了应对突发流量，扩容后就没缩回去。这一项优化，一年就省了上百万。多说一句，大家还真都是草台班子。

中间件层：那些看不见的成本大户

消息队列、搜索引擎、大数据组件……这些中间件往往是成本大户。

比如消息队列，很多团队的使用方式是「能用队列的地方都用队列」，结果消息堆积严重，不仅成本高，还影响性能。盘点时你会发现，有些场景用简单的异步调用就够了，根本不需要引入消息队列。

甚至，连异步调用都不需要，同步调用就能解决问题，当时只是为了考虑扩展性，才做的甚至队列的最终一致性。然而业务一直用不上。

再比如搜索，Elasticsearch 集群动不动就是几十个节点，但真的需要这么多吗？数据的冷热分离做了吗？索引优化了吗？

存储层：数据是核心资产

数据库的盘点要细到什么程度？要细到表、甚至字段级别。

为什么？因为：

得知道核心数据在哪里
得了解数据的流转路径
得评估存储成本是否合理
得发现那些该清理的垃圾数据

曾做过一次数据库盘点，发现数据库中有超过 20 个 copy 表，还有几个超大的日志表，占数据库 80% 的空间，而这些表根本没有人在用，只是当时备份一下。

盘点存储，本质上是在梳理数据链路。

当我们能在脑海中清晰地描绘出「用户在界面上的一个操作，数据是如何流转并最终存储的」，我们才算真正理解了这个系统。

代码资产：不只是代码仓库

代码资产包括：

有多少代码仓库？活跃度如何？
技术栈是否统一？有没有历史包袱？
代码质量如何？技术债务有多少？
文档完善吗？新人能快速上手吗？

很多团队的代码仓库就像仓库一样，堆满了各种「以后可能用得上」的东西。结果就是，真正在维护的可能只有一半，另一半都是历史遗留。

流程资产：效率的关键

CI/CD 流程顺畅吗？从代码提交到上线要多久？

我接手过一个团队，上线一个小改动要两天。为什么？因为 CI/CD 流程设计得太「完美」了，各种检查、各种审批，结果效率极低。

盘点流程，我们会发现很多「以前合理现在不合理」的设计。比如，创业初期为了快速迭代，可能没有代码审查；规模大了之后，可能审查流程又过于繁琐。

在制品管理：别让半成品成为负担

什么是在制品？就是那些做了一半的项目、POC 了但没上线的系统、试验性的功能……

这些在制品是隐形的成本黑洞：

占用服务器资源
消耗维护精力
增加系统复杂度
埋下安全隐患

盘点时会惊讶地发现，可能有 30% 的资源被这些”半成品”占用着。

制品管理：那些容易被遗忘的二进制资产

什么是制品？简单说，就是我们的代码编译打包后生成的那些可执行文件——jar 包、docker 镜像、npm 包等等。这些东西看起来不起眼，但管理不当会成为大麻烦。

我见过最混乱的场景是什么样的？一个团队，所有的jar包都扔在一个共享文件夹里，文件名是这样的：

app-1.0.jar
app-1.0-final.jar
app-1.0-final-final.jar
app-1.0-final-真的final.jar

你猜哪个是生产环境在用的？没人知道。

为什么要盘点制品？因为制品管理的混乱会带来一连串问题：

版本追踪的噩梦：出了问题要回滚，找不到上个版本的包在哪。或者找到了，不确定是不是真的上个版本。

存储成本失控：没有清理机制，历史版本堆积如山。我见过一个团队，三年积累了2TB的jar包，其中90%是没用的历史版本。

安全隐患重重：制品里可能包含敏感配置、硬编码的密码。如果管理不当，这些信息很容易泄露。

部署效率低下：每次部署都要到处找包，或者重新编译。本来 10 分钟能完成的部署，硬是搞成了 1 小时。

盘点制品资产时，我们需要搞清楚：

制品存在哪里？是 FTP、还是专业的制品仓库？
版本管理策略是什么？保留多少个历史版本？
制品的构建和发布流程是否标准化？
有没有制品安全扫描？
制品的访问权限管理是否合理？

建立规范的制品管理体系，看似是个小事，但对提升研发效率、保障系统安全都有重要作用。这也是为什么现代化的研发团队都会使用专业的制品仓库，而不是简单粗暴地用文件夹管理。

盘点的过程就是发现问题的过程

技术资产盘点最大的价值，不是得到一份资产清单，而是在这个过程中发现的问题。这些问题，往往就是我们这些空降的技术管理者的破局点。

比如：

为什么同样的功能，A 团队用 10 台服务器，B 团队要用 50 台？
为什么数据库连接数经常爆满，但 QPS 并不高？
为什么 CDN 流量忽高忽低，找不到规律？
为什么某个服务的日志特别多，一天就是几个 T？

这些问题的答案，可能是架构不合理，可能是代码有 bug，可能是产品设计有问题，也可能只是配置错误。但不管是什么原因，都是改进的机会。

如何做好技术资产盘点

说了这么多为什么，该说说怎么做了。

1. 不要贪大求全

很多人一上来就想把所有东西都盘点清楚，结果战线拉得太长，什么都没做好。

正确的做法是：先盘点最重要的，最花钱的，最容易出问题的。比如先看数据库和服务器，这通常占技术成本的大头。如果是内容业务，还有存储，如果是 AI 业务。还有算力或者外部大模型 API 等等。

2. 不要只看数字

“我们有 100 个 API”——这是数字 “我们有 100 个API，其中 30 个是僵尸接口，20 个性能有问题，10 个存在安全隐患”——这是洞察

盘点不是为了得到一个数字，而是为了理解现状，发现问题。

3. 要深入但不要钻牛角尖

盘点数据库要不要细到每个字段？大部分情况下不需要。但核心业务的核心表，我们必须了如指掌。

把握好粒度，既要有全局视角，又要有局部洞察。

4. 借助工具但不依赖工具

市面上有很多资产管理工具，可以自动发现服务器、统计资源使用率等。这些工具很有用，但不要完全依赖它们。

真正的理解来自于和团队的深入交流，来自于对业务的理解，来自于对历史的了解。工具只能告诉我们「是什么」，但只有人才能告诉你「为什么」。

5. 让团队参与进来

技术资产盘点不是管理者一个人的事。让团队参与进来，既能获得更准确的信息，又能让大家都有「当家」的感觉。

可以让每个小组负责盘点自己的模块，然后一起 review。这个过程中，我们会发现很多有意思的事情，比如 A 组和 B 组对同一个服务的理解完全不同。

盘点之后呢

完成技术资产盘点只是开始。真正的价值在于基于盘点结果的行动。

建立资产台账

别让盘点结果躺在Excel里吃灰。建立一个活的资产台账，定期更新，让它成为团队的知识库。

新人入职，先看资产台账；技术决策，先查资产台账；故障排查，资产台账能帮大忙。

制定优化计划

基于盘点发现的问题，制定优化计划。哪些是quick win，可以马上做？哪些需要长期规划？哪些需要跨团队协作？

记住，罗马不是一天建成的，技术债也不是一天能还清的。有节奏地推进，比急于求成更重要。

建立监控体系

光盘点不够，还要建立监控体系。资源使用率、成本趋势、性能指标……这些都要持续监控。

很多问题都是慢慢积累的。如果没有监控，等我们发现时可能已经很严重了。

形成资产管理文化

最高境界是形成资产管理的文化。让每个人都有成本意识，都知道自己用的资源值多少钱，都会主动优化。

这需要时间，需要机制，更需要管理者的坚持。

最后

技术管理空降，最难的不是推新技术、搞创新，而是先把现有的东西搞清楚。这就像医生看病，不把脉、不验血，上来就开药，那是江湖郎中。

技术资产盘点，就是给技术体系做一次全面体检。只有知道了哪里健康、哪里有病，才能对症下药。

这个过程可能很枯燥，可能会发现很多历史遗留问题让人头疼，但这是建立手感、获得掌控、赢得信任的必经之路。

记住，管理的本质是通过他人完成工作。而要想通过他人完成工作，我们首先得知道工作是什么、资源在哪里、问题在哪里。

技术资产盘点，就是回答这些问题的第一步。

不要急着证明自己，先把家底摸清楚。当我们真正理解了这个技术体系，知道了每一分钱花在哪里、每一个系统为什么存在、每一个问题因何而生，我们的管理才能真正落地。

毕竟，空降兵最重要的不是会打仗，而是先活下来。而活下来的第一步，就是搞清楚自己降落在哪里。