一个诱人的设想：AI把每个人都变成工具制造者——让模型生成所需软件，应用便消亡。但这误解了多数人的想法与软件的来源，也不是改变公司运作的路径。美国大公司通常有几百甚至几千套软件，从核心系统到部门里10MB的表格，重复乏味的工作仍随处可见。工程师的旧笑话里，为十分钟的活儿花一小时造工具；AI时代五分钟即成，不必写码，只需开口。

AI、工具与转型

人们很容易想象，AI 会让每个人都变成工具制造者——现在谁都可以让模型做出自己需要的软件，App 这种形态就死了。我认为这种想法误解了大多数人的思维方式，也误解了软件真正的来源；更重要的是，它并不是改变企业运作方式的路径。

今天一家典型的大公司有几百甚至上千种软件：SAP、Workday 这类大型横向记录系统，几百个垂直 SaaS 应用，还有几百个更底层的工作流、脚本、自动化和数据库，一直到某个部门靠它运转的 10 兆电子表格。公司往往自己都不清楚到底有多少软件、哪些在真正使用、在为什么付费。可就算有了这么多软件，公司里仍然满是无聊、重复的杂活。

于是很容易觉得 AI 会把这一切一扫而空。有个老笑话：工程师会花一小时造工具来自动化一件十分钟就能做完的事。但有了 AI，你五分钟就能造出那个工具，而且不需要是工程师，不需要写代码。你可以直接让模型造工具，或者更根本地，让模型直接把任务做了。软件不必一个个手工创建，它可以变成动态的、生成式的、随心所欲的、即兴的。可以用少得多的软件自动化多得多的任务。

如果你是工具制造者——硅谷人人都是工具制造者——这太令人兴奋了。但我觉得它误解了软件从哪来、人们怎么用软件，也忽略了公司如何变化。

首先，大多数人不是工具制造者，也不会本能地琢磨自己的工作能不能换个做法。如果你一直待在硅谷的小圈子里，很容易忘了这点，因为你的整个世界就是创造改变做事方式的工具。但如果你是一位非常出色的婚姻法律师，你整天想的是案件和客户，不是多好的法律检索软件能做什么；如果你是一位出色的企业销售，你整天想的是产品、客户和竞争对手，不是多好的销售赋能软件能让你更高效。

Excel 这类产品试图用新手引导、助手和模板来弥合这个问题——“文件/新建”里看到的一切都是“你可以拿这个做什么”的提示。但那些模板每一个都最终变成了一家公司。Claude for X 这类东西也一样：它有用，但不是答案。

狭义地说，这意味着需要自动化的任务可能明摆着，但做这些任务的人看不见。于是就有了“前部署工程师”的概念——一个本身是建造者、又知道 AI 能造什么的人，可以走进律所或建筑事务所，“随便”转转就能看见律师或建筑师看不见的机会。

更深层的问题是，过去几十年我们自动化的大部分东西，就算你是工具制造者，也很难一眼看出来，而且也没有显而易见的解决方案。我们今天每天用的很多东西，我们的第一反应都是“我为什么要用这个？”问题常常并不明显，而且往往嵌在、裹在别的什么东西里面。即使你能看见问题，恰当的解法也常常不清楚——解法往往是重新定义问题或把问题拆开，而想明白这一点很难。很多成功的软件公司之前都有过五六次失败尝试，没找到真正对路的方法或问题。

让写代码变得更容易、让造工具变得更容易，并不能解决这些。难的是首先要知道你需要一个工具，然后要知道工具该做什么。

但就算到了这一步，你还得让其他所有人都用。许多想自动化的问题、工作流和任务牵涉五个不同部门、三个不同记录系统、四种不同监管体制里的五十或五百人。你可能有很棒的想法要改变应付账款的做法，但你自己没法改变全公司每个人的做法。那必须是一次采购、一次决策、一个十八个月的销售流程。

第二，所有这些意味着，软件的购买、选择或创建处在一个自上而下到自下而上的光谱上——公司买 SAP，用户自己做电子表格——我认为这也是一条从“制度化”到“即兴”的光谱。

有些任务用好现有专用工具就能完成，比如 SAP、Carta 或 Rippling。这些任务和工作流已经被制度化了——那些公司和你公司里的一大群人花了大量时间琢磨出做这件事的正确方式，重要的是所有人都用同样的工具、以同样的方式做。但总有边缘情况、例外和一次性问题，在那些工具里很难甚至无法完成。你的用户自下而上地创造自己的解决方案，在 Excel、邮件、共享文件夹、Tableau、PowerPoint、CSV、截屏、PDF 和电话会议构成的模糊即兴空间里处理它们。

可一旦某个任务变成你一直在做、每次都同样做、而且很多人都在做的事，变得重要、牵涉收入和风险，到了一定程度，公司就必须把它制度化。你需要审计、安全、维护和问责。你铺平“欲望路径”，花钱把它砌成石头路。你可能没意识到那条路存在——没意识到几百人每天在这事上浪费一小时——也可能很难想出正确的修法，但正是这个过程让公司有了几百个应用。

SaaS 转型时我们经历过很多类似情况。那是软件数量又一次数量级变化，伴随新的运作模式和新的周期，杀死了许多跳不过去的在位者。这是一个持续不断的捆绑与解绑的有机流动。那些 SaaS 应用做的都是你本可以用 SAP、Excel 或邮件做的事——Carta 是一家 40 亿美元的公司，专门替你管 CFO 的一张电子表格。有时任务也会移回去。几年前一个顾问告诉我，他们一半的工作是劝用 Excel 的人改用数据库，另一半是反过来。

所以，如果普华永道每年招三四千毕业生，它用专门的“制度化”软件来管。如果你是小公司、招五到十个人，你用邮件、共享文件夹和 Google Sheets。小公司长大后，某个时点就不够用了，也许搬到 Notion，或搬到面向中小企业的 SaaS HCM。但普华永道内部的一个小团队也可能用 Google Sheets 跟踪候选人，因为 Workday 太不灵活了——解绑又开始了。

如今 AI 横跨这一切。AI 会扩展所有既有应用，也会催生许多新的垂直应用；Excel、Tableau、Google Sheets、邮件以及所有其他用于即兴解决方案的自由空间都会获得新能力。在这个循环中，聊天机器人本身就是一个新的自由空间，与 Excel 和邮件并列，从它们那里接走任务，也把任务让给那些应用。

那家招十个人的小公司可能会在 Google Sheets 里多撑很久，因为 AI 让它变得更有扩展性；或者你把它当 Gemini 的数据仓库，然后问“要不要让 Claude 做点东西，还是把这个搬到 Notion？”接着你发现正好有个新 SaaS 应用瞄准你，解决这个问题外加你没想到的另一个问题。AI 没有改变问题本身：它创造了新选择，移动了阈值。

过去三年企业部署 AI 的经验里都能看到这些。每家大公司都给所有人装了 Copilot（或 ChatGPT、Claude），一小部分人用得很多（其中有些人确实提高了生产率），稍多的人每周用几次，还有很大一部分人基本没用。这有一部分是变更管理和培训问题，但主要还是那个问题——如果你在 1983 年给全公司每人一台 PC 和 Lotus 1-2-3，或在 1997 年给每人一根网线和浏览器，你也会遇到同样的问题。这到底怎么对应到每个人的任务、对应到他们这周真正遇到的问题？你是给了每人 PC 和 Lotus，但那不是你把发票处理效率转型的方式。你是给了每人浏览器，但那不是你围绕互联网重建供应链管理的方式，当然也不是零售商做电子商务的方式。

公司思考如何改变这类结构性流程的办法是做试点。你试用那些利用 AI 新能力自动化以前无法自动化的流程的产品（外购的和自建的都有）。现在有各种数据说试点有多少、成功的大概一半（这很正常——所以才叫“试点”）、会出什么问题。

但这又是围绕用例、灯塔项目、试点、英雄、速赢和可衡量结果的古老 CIO 对话。与此同时，CEO 和董事会挠头说：“等等，我们有几百个工作流，才做了五到十个试点。这看起来没法规模化？”给全公司 ChatGPT 在理论上是规模化的，只是大多数人并没真正找到用法。

回到那个 1980 年代给每人发电子表格的银行、或 1990 年代给每人浏览器的零售商——当然你该这么做，当然你需要考虑培训和变更管理，所有这些 KPMG 都能告诉你。但那不是你在一个划时代的新技术上思考如何转型公司运作方式的方法。

退一步看，每次新的变革性技术到来，每家公司都要问三类问题。第一，如何购买、构建和部署？要不要做试点？用微软/谷歌/Oracle 捆绑的产品、自己建、花钱找人造，还是买创业公司的新东西？第二，这会在多大程度上改变运营？它意味着什么？电子邮件对我们意味着什么？电子表格对我们意味着什么？如果你是保险公司或律所，答案可能截然不同。第三，这是否给商业模式带来新挑战、新竞争压力，或者某种生存威胁。

你没法靠给所有人装 Claude for X 来回答这些问题。这一切意味着大量面向专业服务公司的新生意——考虑到 AI 对它们自身商业模式提出了多少问题，这很有讽刺意味。你想在呼叫中心部署一个基于 LLM 的语音分析工具？你大概会找埃森哲。厂商自己一直很乐意帮忙，现在大实验室也有了自己的“部署公司”——我们以前开玩笑说“机器学习科学家”是住在旧金山的统计学家，那么“前部署工程师”也许就是 OpenAI 从系统集成商挖来的任何人。另一边，你的创业公司做出了很棒的新工具、想快速上市？你大概会找四大会计师事务所。你觉得很难把 AI 软件卖给律所或会计所？那就去开一家“AI 赋能”的律所，看看它能否成为关键杠杆（还是说这就像 1980 年代开“PC 赋能律所”）。当然，如果你是董事会成员，想弄清这是生存威胁还是巨大收入机会，你会想找贝恩、BCG 和麦肯锡——它们做的就是这个。

再退一步，还有一个更简单的看法。每一项新技术，我们都是先把它用在我们已有的工作上，只是做得更多、更快。但随着时间的推移，你会做出全新的东西。我们会用 AI 在既有工作流和既有公司内自动化一大批事务（尽管如我前面所说，这会比给每个人发个模型麻烦得多、费劲得多）。但在每一次平台迁移中，真正要紧的从来都是那些以前根本不可能做、没人想象过的东西。

多数评论对“AI 让人人都能打造自己的工具”持保留态度：即便写代码可以由 AI 代劳，审计、安全与真实的工程兜底仍是绕不过去的环节；少数派则认为 AI 恰恰会压平现有的抽象层和组织层级，让工具制造不再是工程师特权。

“非工程师几分钟就能造工具”低估了工程兜底

• 一位工程师用身边案例反驳：伴侣让 AI 写脚本分析 Excel，结果只处理了第一个工作表，若不是懂行的人审代码就会得出错误结论；同事用 vibe coding 做出的网站部署在 CloudFront/Lambda 上，没人理解底层，投入上百小时仍不如原来的 Excel。结论是，没有工程师在场，这类“自建工具”经常既不可靠也无效率。（认可度：较多人）

不，非工程师并不能自己造出能用的工具。（@iLoveOncall）

AI 能放开手脚的只有沙盒；安全、审计和问责必须留给人

• AI 在可验证的封闭任务里可以很强，但在把模糊业务问题变成软件规格上仍是短板；一旦碰到真实系统，就可能误解目标，出现误删邮箱、被用来协调操控公共维基这类后果。评论区普遍认可，未来软件要在安全性、持久性和可用性上给 AI 设下不可逾越的约束，而 SaaS 的护城河会从“功能清单”变成“审计与合规能力”。领域专家用约束框架引导 AI 是更可行的模式，但法律等靠人为规则维持权力的领域会拖得更久。（认可度：较多人）

问责是无法真正外包给 AI 的。（@ryuuseijin）

层级和抽象层会随 AI 一起坍缩，“人人自造”不是幻想

• 过去为一个函数就要引入一个库、想覆盖多平台就要学框架，这类抽象层存在的理由正在被 LLM 消除——AI 可以直接生成所需实现。软件里服务于“弥补能力差距”的层级变薄，社会里类似的中间阶层也会跟着受冲击。支持者承认工具质量仍取决于使用者的判断力，但 AI 至少把构建过程缩短了一个数量级。（认可度：少数人）

软件里的抽象层和社会里的层级都会因此变平并坍缩。（@zacksiri）

Google Wave 式的魔咒：功能上无所不能，使用上一事无成

• 有评论提醒，给所有人一个可以协作万物的平台，结果往往不会催生任何真实工作流；AI 普及也可能重蹈覆辙。公司里的真实协作方式、职责边界和信任关系，不会因为工具变得更聪明就自动改变。（认可度：少数人）

给人人发 AI，就像给人人发 Google Wave——看似什么都能做，最后什么也没做成。（@thelastgallon）

有价值的补充

• 文章里“AI 没有改变问题，只是创造了新选择、移动了阈值”这类句子已经让读者产生“大语言模型腔”的警觉；随着 AI 写作普及，作者可能需要刻意规避这种被反感的文本指纹。
• 一种更锋利的观察是，AI 与以往工具的关键差异在于它“会说话”；一旦拥有能动性，它就像那个告诉父亲“还有另一种做法”的 15 岁少年，能自己在公司基础设施里走动、说服、推动事情发生，而不只是被动等人使用。
• 组织内部容易忽视的阻力来自中间管理层：如果理想模式是领域专家为 AI 制作约束框架，那么那些作为“信息缓冲层”存在的管理者会最先恐慌，并可能用流程和审批拖延落地。