工良吐槽篇：万字长文细说 AI 落地之笑谈

这两年 AI 的变化非常快，各种 AI 产品也在不断融入到我们的生活和工作中，无论你是程序员、产品经理，还是办公室白领，甚至是平时不怎么关注技术的人，多少都已经感受到了 AI 带来的便利。

这段时间，我常常在地铁或者公交车上看到一些大爷大妈也在使用豆包、元宝这些 AI 软件，通用 AI 确实已经进入了很多普通人的日常生活，不再只是互联网圈子里自娱自乐的新鲜玩意。很多老百姓日常都使用这些 AI 产品去获得我们平时很难学习和接触的知识，解决我们日常中的各类困惑。

不过，AI 用得热闹，不代表 AI 就真的落地了。个人拿 AI 查资料、写文案、改代码，和一家公司把 AI 真正接进研发、产品、测试、运营这些环节，完全不是一回事。前者更多是个人工具，后者考验的是资源、流程、管理判断，以及公司内部到底有没有一套能跑起来的东西。

这段时间，我在公司里和互联网圈子里，也听到了不少关于 AI 使用和 AI 落地的讨论。有人确实在认真做事，也有人只是把 AI 当成新口号、新包装，顺便制造出不少段子和笑话。

恰好今天生病休息，闲下来，就把这些所见所闻整理一下，写一篇批评文，聊一聊企业里那些关于 AI 落地的现象、问题和笑料。

我的人工智能基金为什么是亏的，今天周二又绿了。。。

特意说明，笔者本文仅做批判性思考，不表示具体的人、也不是阴阳谁，请勿对号入座，请勿应激。

落不了地的 AI

很多公司一聊 AI，气势都很足，仿佛第二天就要完成智能化转型。群里转几篇大厂发布会，开会提几次 AI 战略、AI 提效、AI 重构研发流程，再让几个人试试 Codex、Claude Code、豆包，整个部门的空气都显得先进了不少。

数字化战略？AI 高效企业建设？嘻嘻，PPT 先飞起来再说！

我们常常可以在技术社区看到阿里巴巴、字节等公司又发布了什么模型、发布了新的 AI Vibe Coding 工具，进行了什么样的 Spec 研发流程探索，给每个人分了多少额度的 tokens，而你，我的朋友，恐怕你的公司对 AI 编程和在研发流程的落地，估计还没有动静，或者只能自己买 Coding Plan 做付费上班。
很多 AI 落地，最先卡住的根本不是模型能力，而是资源和政策。技术社区里天天都在讨论新的模型、Vibe Coding、Spec 驱动研发、Agent，你们领导懂这些吗？既然不懂，又怎么落地 AI ？
再看看不少中小公司，别说给团队按月配套餐，连让员工稳定地用上付费工具都舍不得。上面一边喊着要拥抱 AI，一边默认大家自己想办法，最好是自带账号、自带额度、自带热情，顺便把效率也一起交上来。

这不就是公司负责喊口号，员工负责自行发电。

再说 AI 落地，绝不是装个 Codex、Claude Code，使用豆包问答这么简单。

真要往下走，产品怎么提需求，文档怎么整理，需求怎么变成适合模型理解的材料，代码生成之后怎么做规范约束、安全检查、测试验收，这些都要有配套。你的研发体系里，产研测是不是已经能围着同一套 Spec 和物料协作？团队内部有没有统一的模板、Skill、工具链？如果这些东西都没有，只是让程序员先把 AI 用起来，那么所谓的流程升级，很多时候不过是把原来的问题原封不动地喂给 AI。

大家表面上都在用 AI，实际上每个环节都还在重复翻译、重复适配、重复补锅。链路没有打通，只是把原来的人工折腾，升级成了带 AI 的人工折腾。看上去像一条智能流水线，走进去才发现，每个人都在手动搬运上下文。

还有一种情况也很常见。有些领导平时对技术不怎么关心，对新工具也不怎么研究，自己最多拿豆包聊几句，就觉得已经把 AI 摸透了。既不下场实验，也不持续学习，更不清楚不同工具的边界和成本，但是做起 AI 决策来却非常自信。毕竟 AI 这个词现在足够时髦，只要会在会上说几句 Agent、工作流、自动化，好像公司离全面升级就只差大家动手干活了。领导定了规划，干不好，都是你们的问题，你们背锅！
所以很多公司不是不会谈 AI，而是太会谈 AI 了。如果你碰到的是这种只会表面，知识认知都落后、没有技术判断力、不舍得付出成本的领导，AI 落地就很容易停留在一个很熟悉的阶段：领导觉得公司已经走在时代前沿，员工知道大家只是换了一种方式继续凑合。

话外题，笔者写过两篇 spec 落地的文章，关于团队建设 AI 研发流程需要一系列的生态链工具和 Spec 落地尝试：

• 工具与流程适配：选择支持规范定制、多场景协作的 AI 工具，避免工具功能与团队流程脱节；
• 重视规范落地：将团队规则转化为可执行的钩子、Spec 模板，借助 AI 强制落地，而非仅停留在文档层面；
• 构建协作文化：鼓励成员主动共享 AI 使用经验、参与流程优化，避免 “单兵作战” 思维；
• 平衡自动化与人工：AI 负责标准化、重复性工作（如测试、规范检查），人类聚焦核心架构与创意决策，实现人机协同增效。

通过 OpenSpec + OpenCode 实践 AI Specs：https://www.cnblogs.com/whuanle/p/19581835

万字长文讲解：团队落地 AI 辅助编程和 AI Specs 实战：https://www.cnblogs.com/whuanle/p/19469026

现在解决不了过去的问题，未来 AI 也解决不了现在的问题

笔者的观点是，现在解决不了过去的问题，将来使用 AI 也解决不了现在的问题。

很多公司过去就有很多老毛病。流程混乱，职责不清，文档稀烂，技术债一堆，管理层瞎指挥，出了问题就喜欢补规定、补流程、补表格，今天加一个审批，明天加一个规范，后天再来一个统一标准。看起来很忙，实际上问题并没有解决，只是问题的表现形式变了，大家痛苦的姿势也变了。
所以，实际上，过去的问题是很多原因造成的，这些领导现在要解决过去的问题，然而现在产生了新的问题和遗留着过去的问题，因为其知识认知水平和技术、管理能力，无法解决现在和过去的问题，所以内部存在多多少少的矛盾和问题。
然后 AI 出现了。

这下好了，以前解决不了的流程问题，准备让 AI 解决；以前解决不了的管理问题，准备让 AI 解决；以前做不好的研发协作，准备让 AI 解决；以前积累下来的一堆技术债、文档债、沟通债，也准备让 AI 一把梭哈全部解决。

仿佛只要使用 AI、制定战略，企业就能脱胎换骨。至于过去为什么会烂成这样，哪些问题是组织造成的，哪些问题是管理层自己造成的，这些先不谈，先把 AI 这面大旗举起来再说。毕竟这玩意现在很时髦，既能向上汇报，也能向下施压，怎么想都不亏。

领导制定了目标、大纲、规划，最后做不出来？那肯定是员工水平不行、不积极、态度消极！

AI 也是很多中层领导的业绩工具，有些中层领导，本身就需要新的汇报材料、新的成绩点、新的管理抓手，忽悠股东和大老板。AI 正好来了，简直像天降 KPI。现在总算有东西写了，今天调研 Agent，明天建设知识库，后天推动 AI 赋能研发，再配几张流程图，整个故事立刻就新起来了。企业数字化战略也不是有切入口了，AI 赋能也有接入点了，要带头搞 AI，更加受大老板信赖了。至于有没有效果？这个问题可以往后放一放。反正 PPT 里看起来已经很有效果了。
某些人，他们是想借 AI 这个新东西，重新包装旧问题，顺便包装一下自己。过去那套东西搞砸了，没关系，现在可以说是因为以前没有 AI；现在这套东西还搞不定，也没关系，可以继续说是 AI 还没全面接入、员工还不够拥抱、执行层还没有理解战略意图。

话总是有得说，责任总是有地方甩。

很多人对 AI 的期待，本质上就有问题。

现在解决不了过去的问题，凭什么 AI 就可以给你解决现在的问题？更何况，AI 本身还会带来新的问题。工具怎么选，流程怎么接，数据怎么管，安全怎么控，产出怎么验证，责任怎么算，这些都需要人来判断。你连原来的问题都搞不明白，现在再叠一层 AI，只会让系统变得更复杂，让责任链条变得更混乱。

所以，现在解决不了过去的问题，将来使用 AI 也解决不了现在的问题。

不要用豆包指着我

看图猜 AI：

很多领导用了豆包、千问这些工具之后，便以为自己已经掌握了 AI。再加上有些管理者本身就喜欢拍脑袋、喜欢指导别人，用上 AI 之后，更是觉得自己如虎添翼。以前是凭经验教你做事，现在是拿着 AI 回答教你做人，语气都比以前硬了不少，仿佛自己背后站着一个数字军师。
这不是段子，而是很常见的现象。很多人和豆包聊几轮头脑风暴，就开始觉得自己不仅懂 AI，还顺便懂产品、懂研发、懂运营、懂管理。以前是不怎么听别人建议，现在是更加不听了。毕竟以前你还能说他只是个人意见，现在他会告诉你：这不是我说的，这是 AI 说的。
豆包应该是国内最恭维用户的 AI 了吧。

很多人跟豆包头脑风暴，问着问着，就会越来越觉得自己正确。但是，AI 的局限他们根本不懂，而豆包这类工具又很会顺着提问者往下说。你怎么问，它就怎么接；你想听什么，它就很容易往那个方向组织答案。提问的人如果本身没有基础知识、没有判断力，拿什么判断 AI 说的是对的？又拿什么判断这些建议到底能不能落地？

然而很多人特别喜欢让豆包为自己的决策背书，证明自己的方向无比正确，证明自己的判断领先行业。实际上，定的东西狗屁不通。

对 AI 的回复没有正确的判断力和相关使用知识，只能被 AI 牵着走，被动接受 AI 瞎扯淡的信息。

于是就会出现一些很魔幻的场景。有些领导本身技术水平和认知水平都比较落后，又喜欢到处出瞎主意、指导别人干活。有了豆包这些 AI 之后，更喜欢指指点点了。员工说这个事情复杂，他先去问一下 AI；AI 说不难，于是结论也出来了，不是事情难，是你执行有问题。项目需要多少人、多少时间、多少资源，不看历史包袱，不看依赖条件，不看团队现状，他不懂评估，也不需要评估，而是先看豆包怎么说。
很多管理者过于信赖 AI，认为 AI 说的都对，有了 AI 之后，变本加厉去插手、“指导” 员工干活。以前他只是喜欢拍脑袋，现在是喜欢带着 AI 一起拍脑袋，以前只是个人强势，现在还多了一层 “AI 认证”。拿 AI 生成公司运营政策、生成公司规范、生成各种细苛条例，然后要求所有人严格执行，看上去好像很科学、很先进，实际上只是把原来那套瞎折腾，升级成了更有科技感的瞎折腾。
说到底，一个本来就缺乏判断力的人，手里多了一个会说话的工具，往往不会变得更专业，只会变得更自信。AI 说什么他就信什么，甚至觉得自己比专业人员更懂，只需要问豆包就行，自己就已经站在了专业人士的上方。比如拿一个项目去问 AI，AI 回一句“不难”，他就真觉得不难了。至于难点在哪里，需要多少人力和资源，中间有哪些约束和风险，他根本没有能力判断。
不过，问题从来都不只是豆包。

问题是，有些人本来就喜欢指人，只不过现在手里多了一根更时髦的棍子。

很多人喜欢聊 AI 提效，装很懂 AI，对外输出 AI 能提效，鼓励大家多用 AI。可是他只会豆包，无非在豆包提问几句，然后把豆包回复的 “真理” 粘贴到群里，或把自己的文档放到豆包生成新的内容。
不可置否，某一程度来说，豆包这样确实可以帮助解决一些问题。但是，不要觉得自己会用豆包就会 AI 了。程序员群体，没有这么菜，只会豆包的程序员根本上不了桌。

某些情况，AI 可能是伪需求

公司的程序做得非常烂，重构过一次又一次，还是如此。

于是有人就觉得，问题一定出在“审得还不够严”。既然现在 AI 出现了，那就让 AI 来审代码，严格审，往死里审，最好每一行都给点评几句。仿佛只要把 AI 审查一接上，代码质量立刻就能起飞，系统也会跟着脱胎换骨。
呆过几个公司，也经历过不少 IT 负责人、总监、架构师。特点都是喜欢吹 ”代码质量“ ，势必要狠狠抓 ”代码质量“，严格遵守研发规定。Ai 出现了，那就让 AI 审查代码，那么做出的东西一定质量很高！
但是笔者觉得，在很多中小公司里，所谓 “代码质量问题”，很多时候其实是个伪需求，或者说，是个被故意放大的伪命题。

为什么这样说？

因为很多系统做得烂，根本原因往往不是某个变量名起得不够优雅，也不是某个函数多写了几十行。真正的问题可能是研发体系混乱，开发人员水平有限，基础设施不完善，架构从一开始就不合理，需求天天漂移，测试也接不住。一个项目从头到尾都是歪的，最后却把锅扣到 “代码质量不行”，这就很有意思了。

毕竟有些问题很难承认。你要承认架构设计错了，说明负责人水平有问题；你要承认流程有问题，说明管理层有问题；你要承认内部自研框架很烂，说明某些 “大牛” 在胡搞。相比之下，把一切归结成 “规范不够” 、 “代码质量不行”、”员工不配合“、”员工态度消极“，安全得多，也体面得多。
于是接下来大家就会看到很熟悉的一幕：开始制定各种 “规定”、“标准”、“统一”，试图把产品、测试、开发全部按在一条线上，认为只要流程足够严、要求足够细、审查足够狠，最后做出来的系统就一定很牛。那么代码质量怎么抓？很简单，挑语法，挑变量名，挑函数命名，挑缩进，挑细节。毕竟架构看不懂，命名总看得懂。
笔者多年开发经验认为，项目做得怎么样，语法、命名这些不能说不重要，但是确实不是决定性因素，花大量时间纠结这些细节，没有多大意义。实际上 DDD 工程都说了，允许项目直接存在一些小泥球，也就是做得不好的地方、代码耦合性比较差，都是没问题的。

真正决定系统质量的，往往是架构思路对不对，用 DDD 还是传统三层，选社区成熟框架还是内部瞎自研，边界划分合不合理，依赖关系清不清楚。你把 userInfo 改成 userProfile，换个名字，对一个烂系统的帮助，通常没有想象中那么大。

并不是每个开发都是大牛，也并不是一个团队里面所有人的水平都是一样的，所以同一个项目不同的人写的东西，有不少差异，但是基于架构、大体没问题，技术局部细节不太好，就算 ”质量有些差“，其实都不影响，不要盲目向 ”高标准“ 看齐。

按照笔者经验来看，凡是小公司喜欢把代码质量挂在嘴边，天天吹代码质量的，喊着要做代码审查会议的，实际上代码质量一样非常垃圾，没多久就坚持不下去，只会空喊口号。

即使天天用 AI 把代码鞭尸，所谓的代码质量就能好起来了吗？AI 过度抽象代码、喜欢把简单的事情复杂化，过度设计流程等问题又该如何解决呢？天天用 AI 对着员工的代码扫描吗？

很多中小公司还特别容易冒出一些所谓的大牛、技术总监，喜欢 “自研” 内部框架，搞一堆内部工具，觉得自己在打造技术壁垒，觉得外面的开源方案都不够高级。结果做出来一套狗屁不通的东西，开发效率没有提高，学习成本倒是越来越高，最后还要求所有人必须统一使用。系统越做越重，流程越搞越绕，出了问题再回头怪 “代码质量不行”、”研发同事水平不行“。
所以某些情况下，AI 可能根本不是在解决真实问题，而是在给伪需求再镀一层金。真正的问题不敢碰，真正的责任不想认，最后就挑一个最容易发力、也最容易表演的方向狠狠干，比如拿 AI 去审代码、拿 AI 去挑毛病、拿 AI 去证明团队还不够规范。看起来大家都很重视质量，实际上只是把错误的方向做得更认真了一点。
很多东西不要总想着自己瞎几把摸索，很多问题社区里早就有人踩过坑，也早就有过成熟方案。该学习就学习，该补基础就补基础，该提升技术判断力就提升技术判断力。然而有很多东西，这些领导根本不懂，也没有了解过，不能给出行之有效的方案。

搞研发的应该都知道，代码审查、代码质量这类事情，社区里早就有一堆工具了。类似 Sonarqube 这种平台很多年前就在用了，平时做静态分析、风格检查、代码格式化、CICD，也有各种成熟方案。真要抓这些东西，其实并不缺工具。所以，不要陷入伪需求中，有很多工具本身比 AI 好用、易用，效率又高。

陷入内耗

让 AI 审查代码。

很多人觉得这套流程听起来就很先进。程序员先把代码写出来，AI 再来做审查，审出问题就改，改完再审，层层把关，似乎这样一来，代码质量就一定会越来越高。

结果往往不是质量明显提升，而是陷入内耗和没有多大意义的资源消耗。
如果你把微软的 .NET Runtime 代码、Linux 内核代码丢给 AI 审查，AI 一样能告诉你很多地方写得不好。同样一段代码，换一个模型审，结论可能不一样；就算还是同一个模型，前后分两次审，意见也未必一样。你按第一轮意见改完，再送去第二轮，照样还能继续挑。只要想找毛病，AI 总能帮你找出一点毛病。
这就说明一个很现实的问题：很多所谓 AI 审查，并没有一个稳定、清晰、被团队共同定义过的质量标准。它更像是把 “找问题” 这件事自动化了，而不是把 “什么叫好代码” 这件事真正说清楚。最后程序员花了很多时间改边边角角，系统本身并没有更稳，业务价值也没有更高。
所以，试问 “代码质量” 到底是什么？只是命名规则、缩进格式、每个函数和文件的代码量不能超过多少行？

如果一个系统架构本身就是歪的，边界划分一塌糊涂，依赖关系乱成一锅粥，你把几个变量名改得再优雅，把几个函数拆得再漂亮，也救不了这个项目。可惜很多人看不到这些，只看得到语法和命名，因为这些最容易挑，也最适合拿来管人。

另外，“代码质量” 在一些团队里，本来就是卡人的工具。某些领导、架构师、组长特别喜欢拿代码这里不对、那里不规范去指指点点，看起来像是在抓质量，实际上很多时候只是在展示权威。很多公司研发的软件质量低下，最常见的就是 OA、ERP、WMS 这类内部系统，最后总结原因时又说不清到底哪里不行，于是只能继续纠结语法、命名和格式。
有了 AI 之后，这种事情只会更严重。以前还得自己亲自挑毛病，现在把代码丢给 AI，几秒钟就能生成一大堆意见，像拿到了一份带科技含量的批评清单。领导看了很满意，觉得自己抓得很细、很专业；开发看了头很大，因为里面很多东西改了也没什么意义，不改又会被说不重视质量。
而且前面说过了，代码无论是用 AI 写，还是拿 AI 审，如果真要找问题，AI 总能从不同角度给你找出各类问题。哪怕代码本身已经很成熟，它也一样能挑出不少刺。你认真改完，再让它审一遍，它还能继续说上一轮有些地方改得不够好。这样折腾下去，最后优化掉的往往不是问题，而是开发人员的时间和耐心。
所以说，如果团队对质量没有真正的认知，只是迷恋 “审查” 本身，那么 AI 进来以后，并不会让团队变得更强，只会让内耗变得更高效。人工写，AI 审，审完再改，改完再审，大家都很忙，流程也显得井井有条，最后真正增长的，可能只是无意义的返工和彼此消耗。

没有判断力和认识不足

前面说了很多，这些人的技术水平、认知水平的差异，在日常管理和 AI 落地里其实最后都会落到一个问题上：没有判断力。

技术判断力这东西，说到底不是背几个名词，也不是会说几个 Agent、工作流、自动化，就算懂了。真正的判断力，是你能不能看出一个方案适不适合当前团队，能不能评估它的成本、风险、依赖和边界，能不能知道它什么时候该上，什么时候不该上。没有这些东西，嘴上说得再先进，也只是热词说得熟练一点而已。

要形成判断力，需要长期的学习，要有足够的知识和经验，很多人恰好就缺这个。

AI 落地最怕的，很多时候不是工具不够强，也不是模型不够新，而是拍板的人根本不会判断。不会判断一个方案的优缺点，不会判断一件事情到底难不难，不会判断投入和收益，也不会判断什么是真问题，什么只是表面现象。自己没有做过，也没有认真拆过，甚至对里面的技术细节和实施条件都不清楚，先去问一下 AI。AI 回答得轻松一点，他也就跟着轻松起来，然后开始拍板，开始定调，开始给下面安排任务。至于这个事情到底需要多少时间、人力和资源，有哪些前置条件，有哪些历史包袱，会不会牵一发动全身，他根本没有能力评估。
反正东西定下来了，方案让豆包给出来了，后面谁做不出来，谁就是执行力不行；谁提出风险，谁就是不够拥抱 AI；谁说要时间，谁就是思想保守。反正话已经说出去了，方案也已经定下来了，最后只能让下面的人在一堆不合理的预期里硬着头皮往前顶。
问题就出在这里。AI 可以帮你补信息、给思路、列方案，但是它不能替你长出判断力。一个本来就缺乏判断力的人，问得越多，很多时候不是变得越清醒，而是变得越自信。因为 AI 很容易把一个 “理论上可行” 的回答，说得像一个 “现在就能落地” 的方案。中间那些真正决定成败的条件、代价和限制，如果提问的人自己看不出来，AI 也不会替他承担后果。
还有一种情况，就是认识不足，而且往往是过犹不及。

最麻烦的是，这两种人都很自信。前者迷信 AI，后者轻视 AI，一个想把所有问题都扔给 AI，一个压根不愿意认真学习 AI。结果就是，该用的地方用不好，不该乱用的地方又瞎用，最后不是高估它，就是低估它，总之很难把它放在一个合适的位置上。

所以说，AI 真正放大的，从来不只是效率，也会放大一个人的认知缺口。一个有判断力的人，会把 AI 当工具，用来补信息、补效率、补视角；一个没有判断力的人，会把 AI 当权杖，用来拍板、压人、甩锅，或者干脆拿来证明自己对新东西早就看透了。

说到底，不懂技术，不愿学习，又没有判断力，这才是很多问题的底层原因。AI 只是把这些问题照得更明显了一点。

我再举一个很常见的例子。

对于研发团队里出现的问题，有些领导根本不懂技术，也不懂这些方案，连学习的过程都跳过了，然后自己拿豆包、千问聊几句，看到回答像模像样，就觉得方案有了，方向也有了，自己又一次站在了时代前沿。下面的人看了，往往都知道不靠谱，只是懒得争，也懒得解释。因为这类方案很多连验证都没有验证过，更别说真正落地了。互联网里这种事情太多了，大家私下里一听就知道是怎么回事，表面上点点头，心里已经开始叹气。你说他完全不懂吧，他又会几个 AI 热词；你说他真懂吧，他连方案为什么成立、代价是什么、适不适合当前团队都判断不了。

这类事情最荒唐的地方就在这里：他们不是在用 AI 解决问题，而是在用 AI 掩盖自己看不懂问题。

如果非要掩耳盗铃，那也行。只不过旧问题不会消失，新问题还会继续产生，最后大家再开一轮会，认真研究下一轮 AI 怎么救场。

再补一句，AI 的大脑很强大，但是你不是 AI，记住，**纸上得来终觉浅，绝知此事要躬行！**