本篇判断：企业AI能力的最小单位，不是「会用AI的人」，是放进公共载体、有人负责的方法。人人都会用，不是能力达标，恰恰是坎的起点——从个人提效到组织能力隔着三道坎：工具归属、需求形态、角色结构，没有一道是技能，没有一道能靠培训给。
本篇解决读者的什么问题：给管理层换一把评估尺。评估自己团队的AI能力，别数「几个人会用」，改查三问：方法和工具放在谁的电脑里？需求以什么形态流动？谁负责让所有人用好？三问全空，人人都会用也只是个人提效，企业层面的AI能力为零；培训预算降格为入场券，管理层立项的目标从「让员工会用」改成「建公共载体＋定角色职责」。
适用边界：案例出自2026年9月发布的《FDE案例100》首批24案，那是同一个访谈编选工程的访谈整理，不是24个独立因果实验；本篇单案纵切NO-07，它是组织转型实践，不是生产系统上线型案例——组织变化为当事人自述「比较明确」，无ROI披露，全篇唯一量化数据属另一制造业客户的短期内部统计。三问查的是家底，不是成绩单。
先看一个人人都会用AI的现场
所有人都怕员工不会用AI。
一家基金公司的现场，恰恰相反：人人都会用。
这家企业偏基金投研，内部是一支需求变化非常快的研发团队，和传统意义上几个月做一个大型软件项目的团队很不一样（NO-07 L17-19，p69）。需求零散且高频，内部产品经理或者业务部门「一天可能就会提出好几个需求」（NO-07 L20-21，p69）。按材料的说法，AI在这里的价值期待，是把研发人员每天能完成的功能点「从三个提高到十个」——先把口径钉死：这是材料写的价值期待，不是前后测量（NO-07 L21-22，p69）。原话还带了一个对照：「和『原来一年做完的项目，现在半年做完』的传统想象并不相同」（NO-07 L22，p69）。这不是一家在等传统提速的企业。
先交代材料底座。这是《FDE案例100》首批24案中的一案（NO-07，企业研发转型），案例集2026年9月发布，24案全是FDE——进客户现场把AI落进业务的交付角色——亲手做出来的项目访谈整理；同一个编选工程，不是24个独立因果实验，下面所有效果，只说到「当事人自述」为止。讲述者本人就是一名FDE（这个交付角色自己的生意经，《FDE驻进客户现场以后，怎样避免永远出不来？》专讲过，本篇不展开）。
讲述者进场之前，这家团队「其实已经在用AI了，而且有些人用得还挺深」——有人用Codex，有人用Claude Code，也有人使用其他AI Coding工具（NO-07 L23-24，p69）。
按流行的剧本，这种现场该直接收官了：工具齐了，人会用了，坐等提效数字。
现场走向刚好相反。「大家都会用，但企业很难让大家一起用。」（NO-07 L24-25，p69）
为什么难？「每个人都觉得自己的工具最好。」（NO-07 L26，p69）原案里录了一句现场原话：「我用这个工具效率高，你让我换另一个，我反而不会干活。」（NO-07 L26-27，p69，说话人原文未明示，受访者转引）讲述者接着说：「当个人习惯越来越成熟以后，企业如果想统一工具，反而会遇到新的阻力。」（NO-07 L27，p69）
培训造得出会用的个人，造不出他们的共同载体。（我们的拆解）
而管理层的诉求在另一层：老板要的是整个研发团队的转型，「希望AI能够成为一种组织能力，而不再只是散落在员工电脑里的个人工具」（NO-07 L28-30，p69）。
讲述者自己把面对的问题拆成了三层（NO-07 L31-32，p69）。
第一层，认知没有统一。大家都在用AI，「但对AI Coding到底能做到什么程度、自己的能力处于什么水平，并没有统一标准」（NO-07 L34-35，p69）。注意缺的是什么：是标准，不是技能。
第二层，工具和方法没有统一。不同的人用不同的工具、有不同的工作习惯，「原来的研发协作方式也没有随着AI Coding的出现发生变化」（NO-07 L37-38，p69）。
第三层，组织方式开始出现新的变化。管理层看到新的研发理念，想调整研发角色和流程，「但这些理念到底怎么落到自己的团队里，并没有现成答案」（NO-07 L40-43，p69-70）。
三层没有一层在讲「谁不会用」。
「组织能力」这个大词，拆开是可检查的东西（我们的拆解，非原案表述）：企业AI能力的最小单位，不是「会用AI的人」，是放进公共载体、有人负责的方法。
从个人提效到组织能力，中间隔着三道坎：工具归属、需求形态、角色结构。没有一道是技能，没有一道能靠培训给。人人都会用，不是能力达标，恰恰是坎的起点。
第一道坎：方法和工具放在谁的电脑里
空的样子，现场给得整整齐齐。有人发现某个工具好用，就自己用；有人掌握了新的方法，就自己实践（NO-07 L50-51，p70）。讲述者说得公道：「这个阶段其实没有什么问题，因为个人只需要对自己的效率负责。」（NO-07 L51-52，p70）个人提效期，能力长在自己身上，天经地义。
但这道坎的判断尺只有一条（我们的拆解）：方法和工具放在谁名下。散在某台个人电脑里的用法、提示词和心得，人一走就跟着走，人一换工具就归零——它从来不是公司的。
《出海业务的AI现场》那篇讲过这个问题的一半：图和视频很可能散在员工个人电脑里，账断成三截、老板在系统里看不见，文件全在公司手里却一张也找不回来。本篇补上另一半：作业方法不归公司。数据加方法，才是组织资产的完整拼图。
还有一个反证，藏在采购动作里。进场时，客户「已经确定采用阿里的相关能力，但『买了之后具体怎么做』其实并没有特别清晰的答案」（NO-07 L72-73，p71）。发票抬头是公司的，用法不是——买，解决的是「有没有」；归属坎问的是「算谁的」（我们的拆解）。
跨过去的样子，原文写得很朴素：「后来企业开始统一工具，并进一步统一研发协作方式」（NO-07 L128，p73，自述的组织动作），AI由此「不再只是『某个开发人员会不会用』的问题，而开始进入团队共同的研发流程」（NO-07 L128-129，p73）。
这一跨不是说服来的（我们的解读：原文记下了「统一工具」这个组织动作，没记它是怎么拍板的）。把工具选择权从个人手里收上来是组织决定——只有管理层能拍，培训师拍不了。
第二道坎：需求以什么形态流动
第二道坎藏在协作载体里，最容易被漏掉。
旧世界运转得好好的：产品经理按老方式写PRD，开发按文档开发，各角色按原分工推进（NO-07 L48-49，p70）。个人用上AI之后，各自提效，前面引过，相安无事。
断裂发生在从个人提效往团队提效走的那一步（NO-07 L53-54，p70）。原来全团队围绕一份飞书PRD协作；AI Coding把工作内容转向Markdown、TXT文件之后，一个人维护一份文档没问题，整个团队围着十几份文件转，新问题马上冒出来：「十几份文档到底应该怎么拆？」（NO-07 L55-58，p70）「产品经理写什么？前端写什么？后端写什么？测试和运维又分别负责什么？」「如果大家同时修改Markdown，怎么避免冲突？原来的角色边界还能不能继续沿用？」（NO-07 L59-60，p70）
「这些都不是单纯学会一个AI工具之后自然就会解决的问题。」（NO-07 L61，p70）
讲述者补了句公道话，原样保留：「我没有把过去的方法定义成『错误』。恰恰相反，它是适应原来研发模式的一套成熟方法。」（NO-07 L62-63，p70）PRD分工没有错——它适配旧的生产方式；方式变了，流程、文档和角色分工也需要重新调整（NO-07 L63-64，p70）。原案里还有一句定调的话：「AI真正进入企业之后，很多时候改变的不只是工具，还有工具背后的工作方式。」（NO-07 L65-68，p70-71）
到了动手定制那一步，他讲得更直接：原来的研发协作围绕一份PRD展开，现在转向多份文档协作，「角色分工就不一定还能直接套用」（NO-07 L102-103，p72）。
跨过去的样子，是本案最值钱的交付物：一套Spec文档体系。当时行业里「没有一个特别成熟、统一的标准可以照搬」（NO-07 L104-105，p72）——讲述者自己也把边界挑明了：AI发展太快，「行业标准还没有跟上」，很多方法「还没有经过足够长时间的大规模验证」（NO-07 L145-147，p74）。所以他没有一开始就把它当标准答案扔给客户，而是「不断拆解、逐步抛出、跟客户确认，再根据反馈继续调整」（NO-07 L106-107，p72），最终「从0到1整理出了一套Spec文档。客户一开始甚至以为这是阿里内部已经提炼好的文档」（NO-07 L108-110，p72）。成色有一条硬判据：「它不再依赖某一个人现场演示，能够在企业内部继续复用。」（NO-07 L130-131，p73）
需求散在聊天里，跟着人走；落进Spec的需求，跟着组织走。（我们的拆解）
第三道坎：谁负责让所有人用好
第三道坎是人：从「谁会用」，变成「谁负责让所有人用好」。
空的样子：没人负责，也没现成标准。四类角色各想各的——讲述者进场第一件事不是备课，是把需求拆开：老板关注企业整体转型到底能不能发生，研发关注工具能不能真正提高自己的效率，产品经理关注原来的研发流程怎么变化，HR关注培训过程中每一天能够获得什么（NO-07 L75-77，p71）。
跨过去的样子，藏在这个案例最容易看错的地方。交付形式是一次五天半的线下培训，讲述者却「始终把它当成一次完整的企业AI转型实践来做」（NO-07 L78-79，p71）。他说「我当时做了几件事情」（NO-07 L80，p71），串起来正好是一条转型动作线：
第一件，把问题边界摸清楚。企业自己汇报的能力不作数，用真实操作、快速原型和现场交流去验证（NO-07 L82-87，p71）。
第二件，把培训排成一条完整的业务故事线：为什么企业要转型、研发人员为什么要使用、工具应该怎么进入原有流程、角色怎么变化、最终又怎么沉淀成企业自己的方法（NO-07 L95-96，p72）。
第三件，针对真实研发流程做定制——就是第二道坎那套Spec（NO-07 L100-103，p72）。
第四件，让方案跟着现场反馈走。「这五天半里，我既是在讲，也是在观察；既是在培训，也是在咨询。」（NO-07 L97，p72）「现场发现的问题，我会继续往后调整。」（NO-07 L98，p72）
然后是三期：第一期的价值，「是让我真正看到企业现场到底是什么样」（NO-07 L114，p72）；第二期按一期经验调整；到后续阶段，「客户的业务人员、产品经理也逐渐进入进来，整个项目从单纯研发培训变成了更完整的组织转型」（NO-07 L113-116，p72）。
业务人员和产品经理逐期进入，是当事人自述的现场信号：培训变转型，先发生在人员构成的变化上。他给这套做法的注脚是：「先把整个链路跑起来，再根据真实反馈不断迭代，第一次不必追求100分。」（NO-07 L120-121，p73）
但有一句诚实的边界要钉（我们的核对）：本案的「有人负责」只交出了一半——新角色的最终职责、考核是否随之调整、Spec由谁批准生效、AI写出的代码质量责任归谁，原文全部没有披露。角色进入是事实，责任机制是否闭环，原文没说。
效果怎么讲
这个案例的效果，原文自己先把冷水泼了：「这个项目的效果，不能简单理解成『用了AI之后公司多赚了多少钱』。这家基金公司没有向我开放可以对外披露的完整ROI数据。」（NO-07 L124-125，p73）
能支持的说法，止于当事人自述：从组织变化看，「效果是比较明确的」（NO-07 L125-126，p73，自述，无数字）。具体是三件已发生的组织动作：统一工具、统一研发协作方式、把Spec文档和方法沉淀下来内部复用（NO-07 L127-131，p73）。
全篇唯一的量化数据，不属于本案：「后续在另一个制造业客户的实践中」，三个小组使用这套Spec Coding方法和模板后，客户在短期几天内做的内部统计——写代码时间省约1/3，写文档省一半多，测试基本持平（NO-07 L132-134，p73）。当事人自己警告：它「不应该被理解成长期、完整的ROI结论」，「真正有价值的效果评估，还是需要持续两周、一个月甚至更长时间」（NO-07 L135-137，p73）。它是方法可复用的信号，不是本案的成绩单。
讲述者给这类项目定的位倒稳：最重要的结果，「是完成了一个变化：从『大家各自使用AI』，走向『企业开始形成一套共同使用AI的方法』」（NO-07 L138-139，p73）。
用三问之前，先钉四颗钉子
评估尺在下一节。这把尺自己的适用边界，先用之前钉死（我们的拆解）。
第一颗：技能是必要条件，不是充分条件，也不是本案暴露的瓶颈。「三道坎没有一道是技能」说的是本案这种人人已会用的现场。团队若连入场券都没拿到，先补技能，再谈三道坎——顺序换不得，但别把入场券当交付物。
第二颗：三问要到现场问，不能用问卷问。「企业自己描述的能力水平，经常不等于现场真实能力水平」（NO-07 L84-85，p71）；讲述者的工作纪律是「不要完全相信前期调研，一定要尽可能通过真实操作、快速原型和现场交流去验证」（NO-07 L86-87，p71）。三问的答案是看出来的，不是问出来的。
第三颗：目标不清，坎就没法跨。「我要做AI转型」这句话本身没有办法指导落地——到底是个人提效、团队提效，还是研发流程重构？「不同目标对应完全不同的方案」（NO-07 L181-182，p75）。本案客户要的在第三层（角色和流程调整），采购形式却停在第一层（培训）——这个错位正是进场先要补的那一跳（我们的核对）。也别用大投入跨坎：一上来就买模型一体机、做模型微调、强行推翻原有全部工作流，原案认为这些方式比较危险（NO-07 L168-169，p75）；「投入应该由轻到重，先把业务价值验证出来，再逐步加深」（NO-07 L173，p75）。
第四颗：答案是跑出来的，不是讨论出来的。「AI的使用水平很难通过问卷准确判断」（NO-07 L185，p75）；「哪怕第一次只有七八十分，也比坐在那里把方案讨论到100分再开始更有价值」（NO-07 L186-187，p75）——「真正跑起来之后，背景、痛点、方案和限制条件都会变得更清楚」（NO-07 L188，p75）。三问别在会议室里答：挑一条真实需求流跑一遍，三问才有得答（我们的拆解）。
三问判断尺：三问全空，组织能力为零
评估一个团队的AI能力，别数「几个人会用」。问三件事（我们的拆解）：
| 三问 | 空的样子（还没跨坎） | 跨过去的样子 |
|---|---|---|
| ① 方法和工具放在谁的电脑里？ | 各用各的，个人锁死，统一工具反遇阻力 | 统一工具＋统一协作方式，企业侧可管理 |
| ② 需求以什么形态流动？ | 散在聊天和口头，协作靠个人现场演示 | Spec化成文档，多人接手、可交接、可复用 |
| ③ 谁负责让所有人用好？ | 各凭本事，没人负责 | 业务与产品经理逐期进入（职责机制原文未披露） |
三问全空，人人都会用也只是个人提效——企业层面的AI能力为零。
三问有答案，才谈得上「组织能力」这四个字。
最后把证据边界交代干净：本篇的三问来自一个组织转型实践现场，不是成绩单现场——五天半、三期是交付事实；组织变化是当事人自述「比较明确」，无数字；本案没有可对外披露的ROI；全篇唯一的量化数字属于另一家制造业客户三个小组的短期内部统计，当事人自己警告，不应被理解成长期、完整的ROI结论。三问查的是家底，案例本身没有交出战绩。
附：直引行号锚点表
| 引文 | 锚点 | 印刷页 | 说话人 |
|---|---|---|---|
| 「一天可能就会提出好几个需求」 | NO-07 L20-21 | p69 | 讲述者（受访FDE本人） |
| 「从三个提高到十个」 | NO-07 L21-22 | p69 | 同上（材料写的价值期待，非前后测量） |
| 「和『原来一年做完的项目，现在半年做完』的传统想象并不相同」 | NO-07 L22 | p69 | 同上 |
| 「其实已经在用AI了，而且有些人用得还挺深」 | NO-07 L23 | p69 | 同上 |
| 「有人用Codex，有人用Claude Code，也有人使用其他AI Coding工具」 | NO-07 L23-24 | p69 | 同上 |
| 「大家都会用，但企业很难让大家一起用」 | NO-07 L24-25 | p69 | 同上 |
| 「每个人都觉得自己的工具最好」 | NO-07 L26 | p69 | 讲述者（现场概括） |
| 「我用这个工具效率高，你让我换另一个，我反而不会干活」 | NO-07 L26-27 | p69 | 现场原话，说话人原文未明示（受访者转引） |
| 「当个人习惯越来越成熟以后，企业如果想统一工具，反而会遇到新的阻力」 | NO-07 L27 | p69 | 讲述者 |
| 「希望AI能够成为一种组织能力，而不再只是散落在员工电脑里的个人工具」 | NO-07 L28-30 | p69 | 同上（管理层诉求转述） |
| 「对AI Coding到底能做到什么程度、自己的能力处于什么水平，并没有统一标准」 | NO-07 L34-35 | p69 | 同上 |
| 「原来的研发协作方式也没有随着AI Coding的出现发生变化」 | NO-07 L37-38 | p69 | 同上 |
| 「但这些理念到底怎么落到自己的团队里，并没有现成答案」 | NO-07 L40-43 | p69-70 | 同上（引文跨页脚标记） |
| 「有人发现某个工具好用，就自己用；有人掌握了新的方法，就自己实践」 | NO-07 L50-51 | p70 | 同上 |
| 「这个阶段其实没有什么问题，因为个人只需要对自己的效率负责」 | NO-07 L51-52 | p70 | 同上 |
| 「十几份文档到底应该怎么拆」 | NO-07 L55-58 | p70 | 同上 |
| 「产品经理写什么？前端写什么？后端写什么？测试和运维又分别负责什么？」 | NO-07 L59 | p70 | 同上 |
| 「如果大家同时修改Markdown，怎么避免冲突？原来的角色边界还能不能继续沿用？」 | NO-07 L59-60 | p70 | 同上 |
| 「这些都不是单纯学会一个AI工具之后自然就会解决的问题」 | NO-07 L61 | p70 | 同上 |
| 「我没有把过去的方法定义成『错误』。恰恰相反，它是适应原来研发模式的一套成熟方法」 | NO-07 L62-63 | p70 | 同上（引文自原句中段起头，省略句首「所以，」） |
| 「AI真正进入企业之后，很多时候改变的不只是工具，还有工具背后的工作方式」 | NO-07 L65-68 | p70-71 | 同上（引文跨页脚标记，L67空行、L68行首换页符） |
| 「已经确定采用阿里的相关能力，但『买了之后具体怎么做』其实并没有特别清晰的答案」 | NO-07 L72-73 | p71 | 同上 |
| 「老板关注的是企业整体转型到底能不能发生……HR又需要关注培训过程中每一天能够获得什么」 | NO-07 L75-77 | p71 | 同上（正文为缩写转述，非逐字引） |
| 「始终把它当成一次完整的企业AI转型实践来做」 | NO-07 L78-79 | p71 | 同上 |
| 「我当时做了几件事情」 | NO-07 L80 | p71 | 同上 |
| 「企业自己描述的能力水平，经常不等于现场真实能力水平」 | NO-07 L84-85 | p71 | 同上 |
| 「不要完全相信前期调研，一定要尽可能通过真实操作、快速原型和现场交流去验证」 | NO-07 L86-87 | p71 | 同上 |
| 「为什么企业要转型、研发人员为什么要使用、工具应该怎么进入原有流程、角色怎么变化、最终又怎么沉淀成企业自己的方法」 | NO-07 L95-96 | p72 | 同上（「原有流」断行跨 L95/L96） |
| 「我既是在讲，也是在观察；既是在培训，也是在咨询」 | NO-07 L97 | p72 | 同上 |
| 「现场发现的问题，我会继续往后调整」 | NO-07 L98 | p72 | 同上 |
| 「原来的研发协作围绕一份PRD展开，现在转向多份文档协作，角色分工就不一定还能直接套用」 | NO-07 L102-103 | p72 | 同上（前半句为缩写转述，「角色分工……」为逐字） |
| 「没有一个特别成熟、统一的标准可以照搬」 | NO-07 L104-105 | p72 | 同上 |
| 「不断拆解、逐步抛出、跟客户确认，再根据反馈继续调整」 | NO-07 L106-107 | p72 | 同上 |
| 「我从0到1整理出了一套Spec文档。客户一开始甚至以为这是阿里内部已经提炼好的文档」 | NO-07 L108-110 | p72 | 同上 |
| 「客户的业务人员、产品经理也逐渐进入进来，整个项目从单纯研发培训变成了更完整的组织转型」 | NO-07 L113-116 | p72 | 同上 |
| 「第一期最重要的价值之一，是让我真正看到企业现场到底是什么样」 | NO-07 L114 | p72 | 同上 |
| 「先把整个链路跑起来，再根据真实反馈不断迭代，第一次不必追求100分」 | NO-07 L120-121 | p73 | 同上 |
| 「这个项目的效果，不能简单理解成『用了AI之后公司多赚了多少钱』。这家基金公司没有向我开放可以对外披露的完整ROI数据」 | NO-07 L124-125 | p73 | 同上 |
| 「效果是比较明确的」 | NO-07 L125-126 | p73 | 同上（自述，无数字） |
| 「后来企业开始统一工具，并进一步统一研发协作方式」 | NO-07 L128 | p73 | 同上 |
| 「AI不再只是『某个开发人员会不会用』的问题，而开始进入团队共同的研发流程」 | NO-07 L128-129 | p73 | 同上 |
| 「它不再依赖某一个人现场演示，能够在企业内部继续复用」 | NO-07 L130-131 | p73 | 同上 |
| 「写代码的时间节省了约1/3，写文档的时间节省了一半多，测试时间则基本持平」 | NO-07 L132-134 | p73 | 同上（另一制造业客户短期内部统计，非本案） |
| 「不应该被理解成长期、完整的ROI结论」「真正有价值的效果评估，还是需要持续两周、一个月甚至更长时间」 | NO-07 L135-137 | p73 | 同上（当事人自警） |
| 「是完成了一个变化：从『大家各自使用AI』，走向『企业开始形成一套共同使用AI的方法』」 | NO-07 L138-139 | p73 | 同上 |
| 「AI发展太快，而行业标准还没有跟上」「还没有经过足够长时间的大规模验证」 | NO-07 L145-147 | p74 | 同上 |
| 「比如一上来就买模型一体机、做模型微调，或者强行推翻原有全部工作流」 | NO-07 L168-169 | p75 | 同上（自述判断） |
| 「投入应该由轻到重，先把业务价值验证出来，再逐步加深」 | NO-07 L173 | p75 | 同上 |
| 「这句话本身没有办法指导落地」「不同目标对应完全不同的方案」 | NO-07 L181-182 | p75 | 同上 |
| 「AI的使用水平很难通过问卷准确判断」 | NO-07 L185 | p75 | 同上 |
| 「哪怕第一次只有七八十分，也比坐在那里把方案讨论到100分再开始更有价值」 | NO-07 L186-187 | p75 | 同上 |
| 「真正跑起来之后，背景、痛点、方案和限制条件都会变得更清楚」 | NO-07 L188 | p75 | 同上 |
页码口径：印刷页＝引文其后最近「M/245」标记（印刷页＝PDF物理页−1）；行号＝
12-Meta_J/战役档案/2026-05-21-AI组织OS升级手册/05-idea-pipeline/sources/fde-cases/pdf-text/NO-07-企业研发转型.txt提取件物理行（页脚标记实测：L13=67、L41=69、L66=70、L92=71、L118=72、L141=73、L166=74、L193=75）。案例效果全部为当事人自述，未经独立验证。他案数字（NO-01/06/09/13/24 等）一律未入稿。
来源与口径备注
- 案例来源：Datawhale《FDE案例100》首批24案，2026年9月发布，访谈整理稿（同一编选工程，非24个独立因果实验）；本篇只用NO-07单案，各处事实只从本案源文本与拆解卡取，不跨案挪用；未涉任何客户撤权情节。
- 数字口径随文标注：「从三个提高到十个」＝材料写的价值期待，非前后测量；本案无ROI＝原文明示未开放披露（NO-07 L124-125）；组织变化「比较明确」＝当事人自述、无数字（L125-126）；约1/3、一半多、基本持平＝另一制造业客户三个小组短期几天的内部统计（L132-134），当事人自警不作长期、完整ROI结论（L135-137）；「两周、一个月甚至更长时间」＝当事人自述的效果评估建议口径；五天半、三期＝交付事实；「七八十分／100分」＝当事人的方法比喻，非测量数字。
- 「三道坎」「三问判断尺」「最小单位是放进公共载体、有人负责的方法」「培训造得出会用的个人，造不出他们的共同载体」「需求散在聊天里跟着人走，落进Spec跟着组织走」「数据加方法才是组织资产的完整拼图」「买解决有没有、归属坎问算谁的」「目标层与采购形式的错位」「有人负责只交出了一半」「培训变转型先发生在人员构成的变化上」「三问的答案是看出来的不是问出来的」「答案是跑出来的不是讨论出来的」，均为我们的拆解，非原案自述、非客户验证结果。
- 地域口径：原文「一家基金公司」，国别未述即不述；另一制造业客户同，未统一说成中国企业。全稿无「研究表明／数据证明」式表述，效果只说到当事人自述为止。
- 时间锚：写作日2026-10-12；稿内年份仅「2026年9月」（案例集发布时间，具体锚），无「今年／去年」类漂移词。
组织能力这四个字，我熟。做了多年组织与人才工作，我见过的「能力证明」，出现最多的一直是培训签到表——人到齐、签到交，能力就算留下了；人一走，公司剩下的只有表。AI把这题换了张卷子重考，考的还是老内容：方法记在谁名下、需求进没进载体、责任有没有人认领。三问尺不是给AI出的，是给组织设计出的——本行手艺，换了材料。
相关阅读：《出海业务的AI现场：卡点不在模型，在资产不属于公司》讲资产归公司的另一半——数据与素材怎么归公司，本篇补的是作业方法这一半，两篇合起来才是完整拼图；《AI落地分六档》是同一批案例里的另一把评估尺——那把量AI落地落到了哪一档，这把量能力记在谁名下，两把尺各查各的。