坤霆@全栈技术研究室

什么是 AI Native

过去两年，大多数公司做的事情是"AI+"——在已有产品上叠加一层 AI 能力。搜索加个对话框，客服加个机器人，IDE 加个 Copilot。本质上，产品架构没变，AI 只是一个插件。

AI Native 完全不同。它不是"给产品加 AI"，而是"用 AI 重新定义产品"。

区别在哪里？

• AI+ 产品：传统搜索引擎 + AI 摘要 = 还是搜索引擎
• AI Native 产品：Perplexity = 答案引擎，搜索这个概念本身被重新定义了

前者是增量优化，后者是范式转移。

AI Native 的三个核心特征

1. 交互范式的重构

传统软件的交互模型是命令式的：用户点击按钮、填写表单、执行操作。每一步都需要用户理解系统的抽象模型。

AI Native 产品的交互模型是意图式的：用户表达目标，系统理解意图并执行。用户不需要知道系统内部有多少模块、多少步骤。

你有没有遇到过这种场景

技术方案评审会，你提出了一个架构升级方案。CTO 点头，后端 Leader 说"可以试试"，产品负责人说"方向没问题"。

看起来所有人都同意了。你信心满满地开始推进。

三周后，后端说"这个改动影响太大，我们排不了期"。产品说"Q3 的业务目标更重要，这个能不能缓缓"。CTO 问"为什么进展这么慢"。

你觉得被背叛了。但其实，问题从一开始就埋下了——他们从来没有真正"同意"过。

表面共识是最贵的坑

这是我这几年反复踩的一个坑，也是很多技术管理者最容易忽略的问题。

我们习惯于追求"达成一致"。评审会上，所有人点头，纪要写上"结论：通过"，你觉得事情就这样了。但你仔细看，有的人点头是因为真的认同，有的人是因为不想在会上争论，有的人根本没理解你的方案意味着什么。

这种"假对齐"比公开反对更危险。公开反对至少能让你知道风险在哪里，你可以当场辩论、调整方案、寻找替代路径。但表面共识会让你误判形势，直到执行阶段才发现，原来那些你以为的"盟友"，一直在用各自的方式拖后腿。

这不是人品问题，这是组织行为学中的一个经典陷阱。

三种常见的"假对齐"

根据我的观察，技术团队中的假对齐大致可以分为三类。

加州大学尔湾分校做过一个跟踪了20年的调查，记录人们盯着电脑屏幕时每次切换注意力的时间间隔。结果是这样的：

2004年，150秒。2012年，75秒。2016年，47秒。2025年，还是47秒。

更有意思的是另一组数据：一旦注意力断了，重新回到专注状态，平均需要25分26秒。

也就是说，一个工程师一天能进入心流状态的次数大概就那么五六次，每次被打断后要浪费近半小时才能重新进入状态。那么问题来了——每天早上那个雷打不动的站会，打断了几次？

大部分站会已经变了味。

站会最初的设想很好：快速同步，暴露阻塞，15分钟搞定。但现实中，大多数团队的站会已经退化成了一场轮流汇报。

每个人说三句话——昨天做了什么、今天打算做什么、有没有阻塞。说完了，其他人该摸手机摸手机，该走神走神。轮到Leader问"还有什么问题吗"的时候，全场沉默。

这不是同步，这是仪式。一种管理者用来确认"大家都在"的仪式。

如果信息不通，该修的是管道，不是开会。

飞猪上周发了新一代 AI 产品 V10，定位是"消费 Agent"。大部分报道的标题集中在"AI 帮你订机票"上，但我觉得真正值得技术管理者关注的，不是这个产品本身，而是飞猪 CTO 陈烨在评测会上抛出的一个判断：当前 AI 行业的价值高度集中在模型和算力层，应用层还没有出现足够多能承接价值的产品。

翻译成大白话就是：模型越来越强，但能用模型把事真正办完的产品，还是太少了。

这个问题我在金融科技领域也反复遇到。不少团队做智能客服、智能投顾，Demo 做出来很漂亮，聊天界面里 AI 对答如流。但用户真正需要的不是"被回答"，而是"被解决"。从"问答"到"交易"之间，隔着一条远比想象中宽的鸿沟。

Coding Agent 为什么先跑通了

陈烨提到一个观点，我觉得说到了问题的本质：Coding Agent 之所以率先找到产品市场匹配，不是因为写代码比做业务简单，而是因为代码世界有一个天然的验证闭环——代码能不能跑、测试通不通得过，答案是确定的、即时的。

有个场景你一定不陌生：一个技术很强的Leader，手下的活几乎都过他的手。白天开会，晚上写代码，周末review。团队成员反而很闲，等着他分配任务，等着他把方案定好。

这个人累得半死，团队成长停滞，业务推进缓慢。但他自己觉得挺充实——"至少事情没掉地上。"

这种场景太常见了。而且有个规律：越是优秀的IC（个人贡献者），转型管理者时越容易掉进这个坑。

优秀为什么会变成陷阱

做IC的时候，你的价值等于你解决问题的能力。代码写得好、架构设计得巧、线上问题处理得快——这些是你被认可的原因。

转成管理者后，评价体系变了。你的价值不再是"你做了什么"，而是"你的团队产出了什么"。之前让你闪光的能力，现在可能正在拖你的后腿。

因为太擅长解决问题，你会本能地冲上去："算了，我来吧。"每一次"我来"，你就少了一次观察团队、思考方向的机会。更糟的是，团队会习惯等你兜底，主动性和成长空间都被你"优秀"地压死了。

说白了，做IC时，优秀是你的加速器；做管理者后，同样的优秀可能变成团队的限速器。

真正的转变不是做更多，而是学会不做

我观察过一些转型比较成功的技术管理者，发现他们有一个共同点：不是技术变差了，而是对"成就感来源"做了迁移。

团队全面接入AI编码工具三个月了。表面上看，大家都在用Copilot、Cursor，代码产出量几乎翻倍。但最近我开始有一种不安：这种繁荣是真的吗？

事情起因是上周的代码审查。一个资深同事的代码，风格和架构都挺好，但AI生成的痕迹很重。另一个年轻同事，产出数字不太好看，但每段代码都看得出是思考过的。

我突然意识到，自己犯了一个管理错误：把工具使用量当成了能力指标。

用得最多，不等于用得最好

大部分团队在推广AI工具时，管理者都会看一个数字：采纳率。多少人用了？用了多少次？代码生成占比多少？

这些指标容易量化，向上汇报也好听。但它们掩盖了一个事实：用得多不代表用得好。

我的观察是，团队在使用AI工具时，大致分成了三类人：

第一类：喂料型。把需求描述扔给AI，拿到结果复制粘贴。代码能跑就行，不深究实现逻辑。这类人看起来产出很高，但代码质量和架构一致性埋了不少隐患。

第二类：对话型。会反复调整prompt，审查AI的每一行输出，根据自己的理解做修改和取舍。产出速度不一定最快，但代码质量稳定，出了问题能自己排查。

8月6日，一则不算高调但值得细看的消息在投资圈传开：马云旗下的云锋基金（Yunfeng Capital）向美国旧金山AI保险初创公司Corgi投入约3000万美元（约2.34亿港元），完成了该基金已知的首笔美国交易。

这笔投资之所以值得关注，不仅因为金额本身，更因为它释放了几个不寻常的信号。

反常之处：云锋为什么现在出手美国？

云锋基金过往的投资组合高度集中在中国市场。这不是偶然，而是基因决定的——它由马老师和虞锋联合创立，核心资源圈在中国，投资逻辑也围绕中国消费升级和科技创新展开。

在当前中美科技脱钩的大背景下，一家与中国企业家深度绑定的基金，选择在此时投资美国AI公司，至少说明两件事：

第一，Corgi这家公司的技术壁垒足够高，高到值得云锋冒地缘政治的不确定性去布局。第二，马老师对AI赛道的判断，已经从"观望"转向了"下注"。

Corgi是谁？AI保险凭什么拿3000万美元？

Corgi是一家总部位于旧金山的AI保险初创公司。所谓"AI保险"，可以从两个维度理解：一是用AI技术重构保险行业的核保、定价、理赔等核心流程；二是为AI系统本身提供风险保障——当AI决策出错时，谁来兜底？

过去一年，AI编码工具的进步速度超出了大多数人的预期。Meta刚发布了Muse Code，又一个CLI编码智能体加入了战场。Cursor、Windsurf、Copilot、Claude Code……工具越来越多，代码越来越便宜。

便宜到什么程度？一个中级工程师用AI，一天能产出过去一周的代码量。这不是夸张，是很多团队正在经历的现实。

但代码便宜了，一个问题就浮上来了：如果代码不值钱了，那什么值钱？

产量不是瓶颈，判断力才是

我观察到一个现象：AI让代码产出速度翻了好几倍，但项目交付周期并没有同比缩短。

为什么？因为真正的瓶颈从来不在写代码这个环节。

想想看，一个需求从提出到落地，写代码占多少时间？通常不到三分之一。更多的时间花在：理解需求到底要什么、设计方案选型、审查代码、修bug、协调依赖、灰度验证。

AI把"写"的时间压缩了，但前后那些环节一点没少。甚至因为代码产出太快，后面的环节压力更大了——代码审查的人跟不上生成的速度，测试资源更加紧张，技术债务以更快的速度累积。

值钱的三件事

我认为在代码贬值的时代，真正值钱的是三件事：

一个让人疲惫的循环

每个技术团队大概都经历过这样的场景：季度复盘的时候，技术负责人拿出一份"技术债清单"，上面列着十几二十个待处理项——某个模块耦合太紧、某处缺少自动化测试、某个依赖版本太老、某段代码没有错误处理……

业务方看了看，礼貌地点头，然后问："这些还完之后，下个季度的需求还能按时上吗？"

气氛就微妙了。

很多团队开始搞"还债专项"——每个迭代拨20%的排期专门还技术债。听起来很科学，但执行起来总是走样：要么被紧急需求挤占，要么还了两周发现清单没变短，要么业务方忍不住问"你们到底在还什么债，能不能先停一停"。

我越来越觉得，问题可能不在于"技术债太多"，而在于"技术债"这个框架，从根子上就有问题。

一个有问题的比喻

"技术债"之所以流行，是因为它给业务方和管理层提供了一个好懂的类比：我们现在欠着技术上的钱，以后要还，利息会越滚越多。

但这个比喻有一个致命缺陷：它把技术团队放到了道德上的被动位置。

既然是"债"，就意味着你当时做了一个不够好的决定，现在你欠了东西，你得还。但事实是，大部分所谓的技术债，在当时那个时间点，可能是最合理的选择。

上周看到一个热搜话题：一个人用AI做出了过去需要一个团队才能做的产品。评论区一片焦虑，有人说"技术管理者要失业了"。

我觉得这话说反了。AI越能干，越需要有人决定让它干什么、不干什么。真正该焦虑的，是那些还在用"做得好"来定义自己价值的技术管理者。

做得太好，是一种甜蜜的陷阱

我见过不少技术leader，包括我自己，刚做管理时的第一反应是——代码review我得上，架构设计我得参与，关键技术选型我得拍板。

原因很简单：这是我们最擅长的事，也是最有安全感的事。写出一段精巧的代码、解决一个棘手的bug，那种成就感是开会、写文档、做1on1给不了的。

但问题是，如果你的时间都花在review代码上，谁来做技术规划？谁来协调跨团队的需求冲突？谁来处理团队里那个能力强但态度差的人？

没人做。因为这些事"不急"。或者更准确地说，我们下意识觉得这些事没有"亲手写出一个漂亮的函数"来得有成就感。

身份认同才是真正的瓶颈

我在金融科技团队里见过一个典型场景。新业务要上线，技术方案讨论时，CTO问了一个架构层面的问题。整个会议室沉默了十秒，所有人看向那个最强的工程师。

他答得很好。但我在想：如果这个团队继续发展，他还是那个被提问的人，还是那个回答问题的人？

做了这么多年技术面试，回头看，最贵的成本不是招错一个人，而是你根本不知道自己错在哪里。

早期我面试有个执念：能把算法题写出来的人，工程能力不会差。这个信念让我错过了一些人，也让我招错了一些人。直到有次被现实教育——一个面试表现非常出色的候选人，入职三个月就让我开始怀疑自己的判断力。

第一次看走眼

那个候选人来的时候，我们聊了两个小时。从系统设计到编码细节，他都能接住。我问他一个并发场景怎么处理，他几乎是脱口而出地给了三种方案，还主动比较了优劣。

面试结束我就跟团队说，这个人我要了。

入职后呢？代码确实写得不错，Review也能过。但慢慢地问题浮出来了：跟产品对需求理解有偏差时，他不会主动澄清，而是按自己的理解做完再说。跟后端联调遇到接口不一致，他倾向于等别人改而不是沟通解决。分配任务时，他永远选技术最有趣的那个，而不是业务最紧急的那个。

三个月后我开始反思：我在面试里到底看到了什么？

答案是：我看到了一个"面试能力强"的人，但没看到一个"工程能力强"的人。这两个东西，重叠度远没有我想象的高。

"流畅"的陷阱

你有没有遇到过这种场景——

你是前端技术负责人，发现跨团队项目里有个架构设计有明显问题。如果按现有方案走，半年后一定踩坑。你去找后端团队负责人沟通，对方听了，点点头，然后说："嗯，我们再看看。"

然后就没有然后了。

你跟老板汇报，老板说"你自己去协调"。你没有对那个团队的考核权，没有晋升推荐权，甚至跟他不在一个BU。你唯一能依靠的，是你的"技术判断力"和——怎么说呢——某种说不清道不明的"影响力"。

这种"没权力但要把事推成"的经历，大概是技术管理者最日常的困境之一。

权力为什么不好使

先说一个反直觉的结论：在技术团队里，靠权力推事情，往往是最低效的方式。

你可能觉得，如果我是总监，我说的话别人就会听。事实上，在大厂的组织架构里，你日常需要协作的人，大概率跟你不存在汇报关系。跨团队、跨BU甚至跨公司（外部合作），你的职级对别人没有直接约束力。

而且，即使在团队内部，纯粹的权力推动也会产生副作用。团队成员会因为"你是leader"而执行你的决策，但他们不会投入额外的思考。你在的时候执行，你不在的时候走样。这不是执行力问题，是动力问题。

真正的技术影响力，是让对方觉得"这事值得做"，而不是"这人我惹不起"。

上个月，一个技术朋友跟我吐槽。

他的团队花了两周设计了一套重构方案，要把跑了五年的单体应用拆成微服务。架构设计很扎实，领域划分清晰，接口定义规范，甚至连服务间通信方案都做了三版对比。

评审会上，他讲了45分钟，从领域驱动设计讲到CAP定理，从服务网格讲到可观测性。CTO听完，问了一个问题："这个事做了之后，下个季度的大促能少出几次故障？"

他愣了一下，说："理论上会改善。"

CTO说："你们再想想。"

没有然后了。

这不是段子。我见过太多类似的场景，包括我自己。一个技术方案，技术上无懈可击，但就是过不了决策者那关。大部分技术Leader的第一反应是：他不懂技术。但如果你仔细复盘，问题往往不在技术本身。

决策者到底在听什么

技术方案被否，十有八九不是技术有问题，而是呈现方式和决策者真正关心的东西之间有错位。

技术Leader做方案评审，通常的逻辑是：先讲现状有什么问题，再讲对比了几种方案，最后讲为什么选这个。这个逻辑没毛病，但讲着讲着就容易变成技术展览——架构怎么拆、数据怎么迁移、性能数据有多好看。30分钟里25分钟在讲HOW，5分钟讲WHY，而且这个WHY还是技术视角的WHY。

上个月，一个团队的朋友跟我说，他们在内部做了一次 Agent 能力评估。方式是让 Agent 跑 50 个真实的客服场景，然后让人工逐条打分。

结果出来之后，所有人都在争论一个问题：82% 的通过率，到底算好还是不好？

没人能回答。因为"好"没有标准。

这件事让我意识到一个问题：我们在疯狂地往生产环境里塞 Agent，但我们几乎没有一套可靠的方法来评价它到底干得怎么样。传统软件测试的那套方法论——单元测试、集成测试、端到端测试——在 Agent 面前，几乎全部失效。

传统测试为什么失效了

传统测试建立在一个核心假设之上：确定性。给定输入 A，系统必须输出 B。如果输出了 C，那就是 bug。

Agent 天然不满足这个假设。同一个用户问题，Agent 可能走完全不同的推理路径，给出不同的回答——而且两个回答可能都是"对的"。你怎么写断言？你没法写 assertEqual(agent.answer, expected_answer)，因为 expected_answer 本身就不唯一。

这还只是最表面的问题。更深层的麻烦在于：

上周跟一个带前端团队的朋友聊天，他说了一句话让我印象很深："现在最痛苦的不是写代码，是看代码。"

他的团队半年前全面推了 AI 编码助手。效率确实上来了——以前一周的活，现在两天就能干完。但代码审查（Code Review）的压力也跟着翻了三倍。以前每天审查两三百行，现在动辄上千行。审查者的时间没变，代码量却暴增了。

更麻烦的是，AI 生成的代码有一个特点：看着都对，但你不一定知道它为什么这么写。

这不是个案。我最近跟几个做技术管理的朋友聊过，发现一个共同的焦虑——AI 在加速代码生产，但质量把关的那道门，还是靠人肉。这道门正在被冲垮。

审查的瓶颈不是态度，是带宽

过去十几年，代码审查是软件工程里最被推崇的实践之一。它有效的核心前提是：代码作者能解释自己的思路，审查者通过提问和质疑来发现潜在问题。这是一场人与人的对话，有来有回。

AI 生成的代码打破了这个前提。

审查者面对的不再是一个能解释"我为什么这么写"的同事，而是一堆看起来合理但没人能完全解释意图的代码。你问 AI 为什么这么实现，它可以给你一个事后合理化的解释，但那个解释未必反映真实的决策过程——因为它根本没有"决策过程"，它只是在做概率预测。

上个月，一个朋友在群里吐槽：他们的在线文档产品要加多人协作功能，技术负责人评估了一下，给了个方案——用 WebSocket 广播所有编辑操作，冲突了就提示用户"文档已被他人修改，请刷新后重试"。

我问他，你们打算让用户刷新多少次才能写完一段话？

这不是段子。在我见过的技术选型里，"广播 + 冲突提示"仍然是很多团队处理实时协作的第一反应。理由很简单——实现成本低，逻辑好理解。但这条路的尽头，是一个永远填不完的坑。

冲突不是边缘情况

想象一个场景：两个人同时编辑同一份文档的同一行。A 把"用户协议"改成了"服务条款"，B 在同一位置加了个逗号。两个操作几乎同时发生，网络延迟让它们到达服务器的顺序不确定。

传统做法要么让 A 的修改覆盖 B 的（后到的覆盖先到的），要么把文档锁住让 B 等 A 改完。前者丢数据，后者体验差。

CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）提供了第三条路：从数学上保证，只要操作满足交换律和结合律，无论网络传输顺序如何、延迟多长，所有客户端最终都会收敛到同一份数据。不需要中心服务器仲裁，不需要锁，不需要用户手动解决冲突。每个操作本身就是一个独立的、可传播的、可合并的单元。

从论文到产品的距离

上个月，一个朋友的公司上线了一个 AI 客服助手。上线第一周，用户满意度从 72% 飙升到 89%。所有人都觉得这是一次成功的技术落地。

第二周，满意度掉到了 61%。

没人知道为什么。日志里没有任何报错，API 响应时间正常，模型推理延迟也没变。客服主管说"AI 开始胡说了"，但没人能说清楚它从什么时候开始胡说、为什么胡说、胡说频率有多高。

这不是一个孤例。我最近跟好几个团队聊过，发现一个共同的痛点：AI Agent 跑起来之后，团队对系统的理解能力反而在下降。

传统监控的三个假设，全被 AI 打破了

过去十几年，可观测性领域建立了三大支柱：日志（Logs）、指标（Metrics）、链路追踪（Traces）。这套体系运转得非常好，但它建立在三个隐含假设之上。

第一个假设：系统的行为是确定性的。 给定相同的输入，系统会产生相同的输出。你可以通过阅读代码来理解系统的行为边界。但 AI Agent 不是这样。同样的用户问题，Agent 可能给出完全不同的回答，取决于上下文窗口的状态、之前的对话历史、甚至 prompt 里某个词的微妙变化。代码审计？你审的只是调用框架，真正的决策逻辑在模型的权重里，而那个黑箱你是看不到的。

上个月参加一个架构评审会，有个团队提出要在新加坡加一个机房。理由很充分——东南亚用户访问我们的服务，延迟大概在 250 毫秒左右，体验不够好。加一个区域，理论上能降到 30 毫秒以内。

方案看起来很完美，PPT 里的数据也很漂亮。但我问了一个问题：你们拆解过这 250 毫秒里，有多少是真的花在网络传输上的吗？

没人答得上来。

这件事让我想到一个越来越普遍的现象：很多团队在做多区域部署决策的时候，把"加机房"当成了万能解。延迟高？加机房。用户远？加机房。容灾不够？加机房。但很少有人认真算过，加一个区域的真实成本是什么，以及——有没有更便宜的方案能达到同样的效果。

250 毫秒里，真正的网络传输只占一半

这是很多人不愿意相信的事实：用户感受到的端到端延迟，有接近一半跟地理距离无关。

一个请求从用户手机出发，经过 DNS 解析、TLS 握手、TCP 连接建立，到达服务器后被处理，再把结果返回。这整个链路里，真正受光速限制、必须靠物理距离来解决的，只有网络传播那一段。其他部分——DNS 查询、TLS 协商、连接池等待、服务间调用链、数据库查询、应用层序列化——这些都可以通过架构优化来解决，不需要搬家。