--- layout: post.njk source: https://yage.ai/share/ai-same-mistake-20260615.html speaker: yage.ai title: AI 不 work，和 AI 真香，是同一个错 date: '2026-06-15' summary: 文章探讨了在评估AI能力时，应关注复杂性的来源。作者指出，AI的局限性并非技术本身不够成熟，而是其所面对的复杂度来源于组织结构和长期运转中的流程协调，而非纯粹的技术实现。建议将精力从试图让AI胜任固定工作转向通过'build in public'的方式，从小处着手实践并获取真实反馈，从而提升解决问题的能力。 area: tech-engineering category: ai-application tags: - complexity-source - organizational-knowledge - build-in-public - skill-transferability people: [] companies_orgs: [] products_models: [] media_books: [] draft: true status: evergreen --- 两个朋友对 AI 的看法截然相反。 一个说，AI 根本写不了我的代码。我维护一套跨四个团队的服务链路，光搞清楚每一步的状态机就要两周。AI 连系统的边界条件都搞不明白，写出来的东西看着像样，一跑全崩。 另一个说，AI 真好使。以前写一个接口要半天，现在跟它说两句，十分钟搞定。已经离不开它了。 两个人说的都对。但他们踩进了同一个坑。一个在论证 AI 做不了我这么复杂的事，另一个在论证 AI 让我更快地做我的事。两个人都在回答同一个问题：AI 能不能胜任我现在的工作。 没有人问另一个问题：我现在做的工作，复杂度到底从哪来。 ## 复杂度从哪来 陈然在最近一篇文章里讲了他自己的经历。他判断公司继续卖软件模块意义越来越小，更重要的是把交付价格压下去，把客户真正要的结果交出来。于是他把一个二十人左右的工程师团队解散了，项目经理也撤了，服务重新做了一遍。 重写的过程中他注意到一件事。原来很多复杂性，并不是客户需要的，而是组织在长期运转中自己产生的。流程复杂一点，系统复杂一点，接口复杂一点，项目管理也复杂一点。每一层复杂性都有自己的理由，也都能写进季度总结里。但当你从客户结果倒推，把东西重新做一遍，会发现客户要的东西常常简单得多。 这个发现在大厂里随处可见。大厂做的事情，本质上是一种社会化大分工。把一个巨大的问题切成几百个小方块，每个人负责一块。分工让生产效率上去，但代价是每个人只能看到自己的方块。你的绩效、晋升、技术深度，都绑在这个方块上。 问题是，方块里的复杂度，有多少来自技术本身，有多少来自几百个方块之间的协调？你维护的那层兼容接口，大概率是两年前另一个团队迁移时做了一次妥协才留下来的。你写的那份设计文档，核心要花时间解决的问题是怎么让三个团队达成一致。这些东西在大厂里被归入”工程深度”。但它们的本质是组织知识，不是技术知识。 你在这个环境里待得越久，就越容易把两者混为一谈。它们在大厂内部看起来完全一样：都很复杂，都需要经验，都让你变得不可替代。但有一个根本区别。技术深度跟着你走。组织复杂度离开这个组织就没了。 ## 为什么两个人都偏了 回到开头那两个朋友。 说 AI 不行的那位，他的判断在表面上是成立的。AI 确实写不了他的代码。但问题出在他从这个事实推出的结论。他以为 AI 写不了是因为 AI 还不够成熟。换个角度看，AI 写不了是因为那些代码的复杂度压根不在技术上。AI 看得见代码，看不见两年前那场会议上谁跟谁做了什么交换。这个能力缺失反映的不是 AI 的水平不够，而是 AI 的边界到了。把它当成 AI 不行的证据，等于拿大厂内部的标尺去丈量整个世界。 说 AI 好用的那位，他的判断在表面上同样成立。AI 确实让他更快了。但他隐含了一个假设：我在这个岗位上做得更快，就意味着我更有价值。这个假设在大厂内部看起来没问题，因为绩效系统就是这样奖励他的。但在组织外部，它未必成立。一个螺丝钉转得更快，不代表这台机器产出了更多东西。他优化的是一个被预先定义好的位置，而这个位置本身可能正等着被重新定义。 两个人的共同盲区在于，他们都把当前工作当成了固定参照物，然后问 AI 能不能胜任它。但这份工作本身是大厂特定组织环境的产物。环境在变，他们拿来丈量 AI 的那把尺子也在变。只是他们自己没意识到。 ## 你的复杂度值多少钱 所以在判断 AI 行不行之前，可以先想一件更基本的事。你每天花时间最多的工作，复杂度有多少来自你要解决的技术问题，有多少来自你所在的组织？ 如果来自技术问题本身，好消息是你的技能有迁移性。但技术复杂度只有在存在一个愿意为它付费的需求时才值钱。同样的数据库优化能力，在 Google 值钱，因为它的商业模式依赖大规模数据访问的速度。换到一个日活一百的产品里做同样的事，就不值钱了，因为那个生意不依赖它。技能没有变，值不值钱变了。所以更该问的问题是：我的复杂度服务于一个有人付费的东西吗。 如果大部分复杂度来自组织，前面的分析已经说清楚了。你面对的复杂度离开这个组织就会消失。 不管落在哪种情况，你都绕不开同一件事。大厂替你做了太多。找客户有人负责，定义需求有人负责，验收交付有人负责，收钱有人负责。你作为工程师接触到的只是整条链条最末端的一环。这些事你觉得跟你无关，在大厂内部也确实跟你无关。但它们恰恰是你离开这个环境后第一个需要面对的东西。 ## 从 build 开始 那怎么开始接触这些被屏蔽掉的东西？ 陈然在那篇文章里的建议是先跑通业务闭环：找一个客户，交付一个东西，收到一笔钱。这个建议本身没错。但对大厂工程师来说，跨度太大了。你没有渠道接触真实用户，没有被训练过怎么理解需求，连”谁在为什么付费”这个问题都没有信息去回答。跑闭环是一个终点，不是一个起点。 更好的起点是你已经擅长的事：build。但有一个条件，公开做。 build in public 的意思是你做的东西要拿出来给人看。不是为了营销，是为了把自己推到几个平时不碰的位置上。怎么让别人三秒钟理解你在做什么。别人用了之后的反应跟你预期差多少。你要根据这些反馈做什么调整。这些东西在大厂里有人替你做，你自己做一遍就会知道它们为什么值钱。 这不需要辞职，也不需要做出一个完整的产品。一个脚本，一个小工具，一段分析，什么都行。关键是让它离开你的电脑，让真实的人看到它，然后听他们说什么。有些项目一开始特别小，但在反馈里逐渐找到了方向。 如果你想找一个地方开始，Superlinear Academy 的社区有一个分享项目的板块。上面的人也是从类似的位置出发的，把东西做出来，公开出去，在别人的反馈里调整。你不需要等到”准备好了”再加入，因为那个状态不会自己到来。 陈然在他那篇文章里说，大厂像一艘正在驶向冰山的船，与其研究怎么升舱，不如开始练习游泳。他说的是船的命运。 我想说的是另一面。就算船不沉，你在船上练出来的技能到了水里也未必用得上。不管船沉不沉，你都需要一套不依赖特定环境的能力。build in public 就是在甲板上就能开始练的游泳。它从你已有的手感出发，但每一步都逼你往水边靠近一点。 判断你跟 AI 的关系之前，先判断你的复杂度从哪来。想清楚了，就去做一个小东西，拿出来给人看。剩下的，反馈会教你。 本文由 GLM 5.2 写作。