AI 落地卡住的不是模型，是没人先花四周验证一个流程

20 位 PE 运营合伙人的同一句抱怨

2026 年 9 月 3 日，私募股权顾问 Mark Ajzenstadt（LimestoneHQ 创始人）在 X 上发了一篇长文。过去六周他和 20 位 PE 运营合伙人聊过被投公司的 AI 使用情况，具体项目保密，但他说模式高度一致：多数被投公司用 AI 写邮件草稿、记会议纪要，再往下是什么，多数合伙人答不上来。少数往理赔、承保或营收运营这些环节推进的公司，撞上的是同一堵墙：做一个演示只要一周，但要证明它够格上生产，得花六个月。

调查数据讲的是同一件事。盖洛普（Gallup）2026 年 5 月调查了 22,573 名美国员工，问他们把 AI 用在哪里：写作与编辑 51%、搜索或研究 49%、通用问答 39%，编程辅助和自动化各 16%。准确的说法是「编程辅助和自动化各 16%」；这两项都不高，常被转述成「自动化一个流程 16%」。

哈佛商业评论分析服务（HBR Analytic Services）2026 年 3 月的调查（385 名业务决策者，由 Appian 赞助）从另一个角度给出同一幅画面：只有 18% 的受访者说 AI 主要集成在工作流里，另有 34% 仍把 AI 当独立工具、与流程并行。换句话说，主流还没把 AI 接进流程；把剩下那部分一概说成「都在起草邮件」，是把调查读窄了。

模型能力早就超过了写邮件，那公司到底卡在哪里？

卡住的不是模型，是没人被要求为 AI 腾出时间

作者给的答案很朴素：运营一家被投公司的人，在 AI 出现之前就在运营它。他们有客户要服务、有关系要维护，而客户没有要求下个季度用上 AI，所以这一周看起来和上一周一样，团队没有理由停下来。你向他要一份 AI 用例清单，得到的多半是一个耸肩——你让他停下正在经营的业务来回答你。

外部调查指向同一处，而且都落在组织这一侧。Accordion 2026 年基准调查访问了 150 位 PE 运营合伙人：只有 17% 的被投公司 CFO（首席财务官）把 AI 列为有专项预算、上董事会的战略任务，而 41% 的合伙人承认自己在没有操作手册的情况下就往多个被投公司铺 AI。作者还列了一组障碍占比（数据基础设施 71%、人才 63%、遗留技术 58%），这三个数字在 Accordion 页面上查不到，只能按「作者转述、未经核实」处理——页面只给出障碍排序，其中的 63% 指的是「63% 的被投公司没有正式的 AI 组织架构」。

微软 2026 工作趋势指数（20,000 名 AI 使用者、10 个国家）把 AI 影响的 67% 归因于文化、管理者支持和人才实践这类组织因素，个人心态与行为只占 32%；只有 26% 的使用者认为领导层在 AI 战略上清晰一致。Gartner 2026 年 4 月调查的 782 位基础设施与运营领导者里，只有 28% 的 AI 用例完全成功并达到 ROI（投资回报率）预期；在至少交付过一个成功用例的领导者中，77% 提到的成功原因有两项：把 AI 集成进现有工作流，以及业务高管的全力支持。

几组数字放在一起，指向的是同一件事：没有人被要求对「用 AI 改一个工作流」负责，也没有人敢先证明一小步。

既然问题出在组织，该从哪里下手？

18 个月的大工程，输给一个四周循环

把 AI 当咨询项目做的公司，路径高度相似：先做长诊断，画一张目标架构图，在假设之上推算 ROI，再花 18 个月做集成——全程没有量过一美元。这条路线图的最后一步是一场汇报。

跑通的公司跑的是循环：挑一个有真实用户、真实数据、业务本来就在追踪其结果的工作流，在两到四周内验证最小的有用切片；判断它好不好的标准，要在 AI Agent（智能体）出现之前就建好。

分歧不在技术能力，而在什么时候承诺。项目式把承诺推到集成之后；循环式要求你在什么都还没有的时候先写下成败标准，所以第一周就可能得出「不值得做」的结论。作者说这恰恰是循环划算的地方：四周拿到一个决定，而不是四个月拿到一份材料。

类比循环式交付像健身先测体脂再开练：练之前把测量方式定下来，八周后同一个动作的重量有没有涨，不需要教练替你解释。

同样是做 AI，项目式和循环式差在哪一步

要跑循环，第一步是挑对工作流。

五只镜片：从客户往里走，把工作流筛到只剩一个

挑选的起点不在成本，也不在效率，而在客户。作者观察到，运营者通常从两种念头出发：砍掉慢的人的成本，或者让聪明的人更快。两种念头都只在公司内部打转，都不会告诉你从哪里开始。他的办法是先看最外面——客户在哪里等待、抱怨或者离开。

这一层有外部数据托底。Encompass 2026 年 4 月对 250 名企业资金主管的调查里，96% 曾在某个时点放弃过某次银行申请，97% 因 KYC（客户身份识别）摩擦在考虑换银行；OnRamp 2026 入职报告的 161 名客户成功负责人里，57% 说入职摩擦直接影响收入，已经把入职流程数字化的团队，价值实现时间平均缩短 25% 以上。

往下四层依次是：

流程本身：把每一步分成确定性、判断密集、异常驱动、关系依赖四类；机器拿走确定性环节，为判断型环节做好准备，人保留决策、审批和例外。

上下文：每个数据集在看 agent 之前就要有所有者、定义和敏感级别。作者说他的交付团队把上下文算作 agent 成功的 80%，这是内部经验判断，没有独立数据支撑。

证据：今天能不能测出单位工作量、周期时间、接触时间、返工率、异常率和单位成本。

负责人：流程负责人、数据负责人，以及一位能在证据面前拍板的高管赞助人。

淘汰线写得很硬：没有真实用户、没有真实数据、没有基线、没有负责人，或者诉求是「重新设计组织」，候选只要占上一条就直接跳过。软件开发和「重复到脚本就能干」的活被直接排除在五只镜片之外——前者的每一步本来就带闸门，后者没有判断空间。在剩下的候选里挑三到五个，按价值、可行性、风险和可复用性排序，只选一个。

选定之后，前四周按五个关口推进。

十步循环里，真正的决策关口只有五个

完整的十步流程，浓缩之后是五个决策关口。

关口一只选一个：一个工作流、一个赞助人、一个业务追踪的指标，并把非目标写下来——团队会在第二周开始加范围。

关口二先签基线：在动手之前，由业务双方签字确认单位工作量、周期时间、返工率、异常率和测量窗口。事后补写的基线什么都量不出来。

关口三先搭评估台：在 agent 存在之前，用客户自己的专家认可过的真实案例组成黄金集，再补上这门业务真正会踩的失败类别——数字算错、受保护数据外泄、对缺失数据假装有把握。

关口四两到四周上线最小切片：agent 只提议，指定的人做决定，先不写进任何系统记录；和旧方式并行跑，每一次运行都留下可读的痕迹。

关口五一起拍板：用证据决定继续、调整、停止还是扩大。数字过不了基线就停下来、保住预算——走到这个结果只花四周，而不是四个月。

十步的完整版依次是：

1. 选工作流与非目标； 2. 和干活的人走查流程，先访谈再盘点； 3. 签字基线； 4. 搭评估台； 5. 上最小切片； 6. 量三个数——吞吐、质量、经济性； 7. 一起拍板； 8. 加固：每次改动都做评估，加上安全审查、可观测性、回退、成本上限；不要跑在某人的笔记本上；每个知识结构加角色权限（RBAC，基于角色的访问控制），每个 agent 设寿命（TTL，生存时间）； 9. 移交：把能力嵌进工作流，培训操作者，交接 runbook，让操作者从按按钮变成做判断，每次纠正回流到黄金集； 10. 用积累下来的上下文层、评估台和托管，去挑下一个工作流。

量经济性时，把省下的工时算成现金有一个前提：有人同意这笔现金出现在哪个科目上。

四周跑完之后，什么情况该继续、什么情况该停

跑通一个工作流之后，公司站在梯子的哪一级？

七级梯子：多数公司坐在第一级，却想买第七级的技术

从「用上 AI 工具」到「组织靠 agent 输出运行」，中间隔着七级梯子。

第一级是工具采纳：工具散落在组织各处，每一步都要人动手，开发者合上笔记本，自动化就死，有人休假，工作流跟着休假。

第二级是上下文层：每个部门一个知识图谱，各在自己的 API（应用程序接口）网关后面，销售通过 API 问工程，被隔开的领域让 agent 不会跨部门边界胡编。

第三级是评估框架工程：先定评估标准、路由逻辑和质量闸门，模型最后才选；用作者的话说，换掉底层模型，系统就坏，说明你建的是依赖，不是平台。

第四级是无人值守：把每个自动化搬出笔记本，按时间表或条件自己触发，不需要有人早上九点登录。

第五级是治理：第一天就给每个知识结构上 RBAC，给每个 agent 设寿命；工具超过 100 个就要做生命周期管理，90 天没跑过的退役，评估分跌破阈值的下线。

第六级是 agent 对 agent：在一条价值链里把无人值守的实例接起来，中间坐一个 LLM（大语言模型）当质量闸门，每一次交接先判定再放行。

第七级是步骤函数：编排好的半自动或全自动工作流，agent 处理量，人处理例外。

作者的判断是图上那句被印成横幅的话：多数公司坐在第一级，却想买第七级的技术，这些公司真正缺的是第四级的纪律。需要说清楚的是，这是作者自己搭的分级，不是行业标准，也没有任何公司分布数据——把它当自查清单可以，当行业事实不行。

分级讲得再顺，也要看案例站不站得住。

三个案例都出自他自己手里

三个案例都来自 LimestoneHQ 自己交付的项目，客户名称未披露，没有第三方审计，作者同时在卖这项服务。能当证据用的，只有「他声称发生了什么」这一层。

医疗账单平台：这家平台的客户最常问的问题集中在理赔拒付（claim denials），这类问题的答案必须精确到分。作者称，从项目启动算起六周内，客户的首席产品与技术官开始对 agent 做验收测试，首次部署就在评估集上拿到 59/60，15 条拒付案例全部答对；经历一次线上 schema 迁移后仍保持 97% 正确率，旗舰问题分毫不差。黄金集来自客户自己的问题，客户自己的专家提供标准答案；agent 只提议，人做决定，不写入任何系统记录。

物流平台的账单重建：两名工程师在前 90 天合并了 122 个 PR（拉取请求），其中 104 个的评审意见少于 5 条，交付时间比客户自己的估算提前 50%。软件开发是作者眼里证据最深的场景，因为开发本身就是「每一步都有闸门」的施工过程：第一周不写代码，每个功能先有规格，每次合并前有人类闸门。

硬件制造商：对方的 CTO 把作者团队的四周试点，和一家规模约为它十倍的公司放在一起比。四周后，CTO 说作者这边做得更好，并自己定了下一阶段——先按 50/50 把自己的人嵌进去，再按 80/20 在另外十个 Scrum 团队铺开。对手方的方法和结果都没有公布，这只是客户侧的一次定性评价，不能据此得出通用的胜负结论。

案例都来自他自己，那行业的整体数字是什么样？

2026 年的回报数字，一句比一句难看

个体变快，公司没赚到钱，这是作者自己摆出来的反差。麦肯锡 2026 年 8 月的《The state of AI》（1,719 名受访者）里，80% 的人报告个人生产力提升，但只有 37% 的人报告企业层面出现了 EBIT（息税折旧摊销前利润）影响（哪怕只是一定程度），且与上一年基本持平——口径是「受访者」，不是「37% 的公司」。KPMG 2026 年 6 月的脉搏调查（2,145 名高级管理者、20 个国家）显示，49% 的组织在成本开始超过收益后推迟或缩减了 agent 部署，只有 7% 的组织能说得出正回报。

PE 那边时间更紧。Bain 2026 全球私募股权报告说，现在一笔交易要在五年里做到 2.5 倍回报，需要 10%–12% 的年 EBITDA 增长，而 2010 年代只需要 5%；退出持有期在七年上下。FTI-Andersch 2026 年 4 月对 200 名 PE 决策者的调查里，38% 预期 7–12 个月看到回报、31% 预期 13–24 个月；而在 Bain 与 StepStone 的 GP（普通合伙人）展望中，39% 的普通合伙人预期 AI 今年对其被投公司没有实质性的财务影响。把这几组预期和 KPMG 那 49% 放在一起看，按三到六个月拿回报来安排资金，这个前提本身就不成立。

软件是证据最深、代价也最清楚的地方。Faros AI 对 22,000 名开发者、4,000 多个团队的两年遥测显示：人均任务吞吐量上升 33.7%，同时每个开发者的缺陷数上升 54%，每个 pull request 的事故比例上升 242.7%。作者自己划出的边界是：出了软件和「重复到脚本就能干」的场景，就没有现成答案；要是有人向你保证十一家被投公司都能跑通，那他还没做到过。

这些数字，和一份四周的报价单放在一起看更清楚。

一个证明月的账单，和你能带走的东西

这套方法不是免费的，作者把它做成了按月卖的服务。一个证明月需要三种人：高管赞助人每周 30 分钟，并在关口上拍板继续还是停止；流程负责人每周 2 到 4 小时，参与走查和验收；数据负责人开始时投入 1 到 3 小时。团队由一名 FDE（前向部署工程师，forward deployed engineer）带 agent，加上一名兼职架构师组成，月费 1.5 万到 2 万美元。他说最近一个运营 agent 的基础设施成本是每月约 250 美元，覆盖四份客户数据集；没有尽调费，按月付费，月底不满意可以不付钱。这些都是发布方的商业条款，没有第三方核验。

可以带走的四件事几乎不花钱，而且正好对上多个独立调查反复指向的那一点：选一个有真实用户、真实数据、业务本来就在追的指标的工作流；动手之前把基线签掉；在 agent 之前把评估台建好；指定一个月底能说出继续还是停止的人。

不该带走的有三样。第一，把单方披露的 59/60 当成行业基准——它来自一个客户名称都不公开、没有第三方核验的项目。第二，把四周试点等同于转型完成。Bain 报告里 10%–12% 的年 EBITDA 增长要求，和 KPMG 那边 49% 的缩减部署，说的都是同一件事：这笔账要按年算，不是按周算。第三，把治理和所有权留到上线之后；作者自己的排法是每个知识结构从第一天就有角色权限，每个 agent 都有寿命。

判断会不会改变也很具体：如果客户内部没有人能定义字段、也没有人能提供评估用的标准答案，那么「定义字段」本身就是第一个交付物，四周的窗口往往不够。这也解释了为什么这套方法在软件场景证据最深——那里的输入、输出和闸门本来就写得清楚；一旦离开软件去碰判断密集或关系依赖的流程，作者能提供的就只剩方法，没有数字。