过去几年，我经常被问同一个问题。
企业做 AI，到底应该交给既有 IT 团队，还是单独成立一支队伍？
这个问题表面看是组织分工，底层其实是一个判断：你把 AI 当成确定性交付，还是把它当成一场高密度探索。
如果你把 AI 当成普通系统建设，那放在 IT 里似乎合理。需求来了，排期开发，测试上线，运维保障。
可问题是，今天大多数企业 AI 项目不是这样运行的。
它一开始往往说不清边界。业务不知道模型能做到什么，技术不知道场景里哪些环节最值钱，管理者也不知道到底该先改流程，还是先买平台。
所以我的判断很明确：企业要做 AI，必须先有一支独立的尖刀队。
这不是反 IT，而是两套机制不同
很多人听到“单独团队”，第一反应是：是不是不信任 IT？
不是。
传统 IT 的价值很大。稳定性、准确性、安全性、权限、审计、数据治理，这些能力缺一块，企业 AI 都走不远。
但传统 IT 的职责，也决定了它天然更偏向确定性交付。
它要保证系统不出错。它要控制变更风险。它要照顾历史系统和组织秩序。它也会被大量常规需求、例行运维和项目排期牵住。
这些事情都重要。
可 AI 早期落地要的是另一种节奏。
它需要快速试。快速错。快速听业务反馈。快速把一段流程拆开，再重新拼起来。
这和传统 IT 的管理逻辑天然有张力。
McKinsey 在讨论 agentic organization 时提到，AI 时代更需要小型、跨职能、结果导向的团队，围绕端到端业务结果来组织工作。BCG 的 10/20/70 经验也提醒我们，AI 成功的大头不在算法，而在人和流程。
这两条经验放在一起，结论很朴素。
AI 落地不是工具采购项目。它是组织机制重建。
AI 团队必须能完整自闭环
我说的尖刀队，不是一个只做研究的小组。
也不是挂一个“AI 创新中心”的牌子，然后到处开会、做培训、写方案。
它必须能完整自闭环。
这个闭环至少包括五类能力。
1 产品能力。 能把业务痛点翻译成 AI 产品形态，而不是只收集需求。
2 开发能力。 能快速做应用、做 Agent、写 Skill、接平台、接业务系统。
3 运营能力。 能让人真的用起来，能看数据，能促活，能持续迭代。
4 变革管理能力。 能处理组织阻力，能培训业务，能重构流程责任。
5 项目能力。 能从机会识别、方案验证、交付上线一路推进到结果复盘。
少了任何一环，这支队伍都会变形。
只有产品，没有开发，就会变成方案部门。只有开发，没有运营，就会做出一堆没人用的工具。只有项目，没有变革，就会把 AI 做成又一套审批流程。
尖刀队必须是一个小型组织，而不是一个技术岗位集合。
为什么不能一边交付需求，一边探索前沿
这个地方很多管理者容易想简单。
他们会说：让 IT 团队抽几个人研究 AI，不就行了吗？
现实里很难。
人是会被目标牵引的。一个团队如果背着稳定系统、交付排期、服务承诺、绩效考核，就很难心无旁骛做前沿探索。
AI 探索经常没有立刻可见的确定收益。
今天试一个 Agent 流程，明天发现业务表单不对。后天换一个模型，结果评测又不稳定。再往后，发现原来的流程根本不该自动化，而应该先重构。
这不是低效。
这是 AI 项目的正常呼吸。
我三年前做 AI 时，感受非常强。很多人不是不聪明，也不是不认可方向。他们只是觉得不靠谱，或者觉得自己搞不定。
更现实一点说，他们有自己的 OKR。
稳定交付会给人确定回报。前沿探索会让人承担失败风险。大多数组织又没有给探索者足够的保护和激励。
所以最后大家都很焦虑，但行动很慢。
AI 要的是高密度试错。没有独立空间，就没有高密度。
最好的参考，是 FDE 模式
很多人担心，精兵强将自己做出来的东西，业务不一定能用。
这个担心对，但解法不是把队伍放回传统需求流程里。
更好的方式，是参考 FDE 模式。
FDE 的关键不是“驻场开发”。
它真正有价值的地方，是把问题理解、产品实现、现场反馈、上线运营放到同一个闭环里。
Palantir 最近的 AI FDE 文档，也把自然语言、工具调用、权限控制、闭环验证放在同一个工作模型里。这个方向很能说明问题：AI 不是只回答问题，它必须进入真实工具链，观察结果，再继续行动。
企业内部做 AI，也应该这样。
不要先把需求写成厚厚的文档，再交给另一个团队排期。
要让尖刀队进入现场，听业务怎么说，看流程怎么跑，判断哪一段可以 AI 化，哪一段必须先改规则。
在企业内部，做和卖应该是一体的。
这里的“卖”，不是向外部客户销售，而是让内部业务真的愿意用，持续用，并且把流程交给 AI 重新改造。
做不出来，卖不了。卖不动，说明你没有真正做对。
这群人从哪里来
我不认为今天所有人都要从外部招聘。
当然，核心开发能力必须有。如果内部没有懂 AI 的开发人员，就要请外援，或者用外部平台先把能力补起来。
但尖刀队不应该只有技术人。
它还需要一批对 AI 有强烈热情的业务人员。
他们可能原来在财务、法务、人力、流程、运营、供应链，也可能在一线业务。只要他们愿意学，愿意试，愿意把业务问题拆开，就很适合进入这支队伍。
在有平台的情况下，很多场景不需要很高深的开发。
用 Agent 加 Skill 的方式，也能交付大量业务需求。
真正重要的是三件事。
1 能不能听懂业务问题。
2 能不能把问题变成可运行的 AI 流程。
3 能不能通过评测和运营持续提高质量。
如果没有自建平台，就先用第三方平台。不要在底座还没想清楚时，就把全部精力耗在大平台建设上。
先做出场景价值，再反推平台能力。
这条路更现实。
不能乱做项目，要有项目组合
成立尖刀队，不代表哪里热闹就冲哪里。
AI 项目最怕两种状态。
一种是完全自上而下，做出来的东西离现场很远。
另一种是完全自下而上，各部门都提一点小需求，最后变成碎片化工具集。
更稳的办法，是建立一个简单的项目入口。
各部门可以提报 AI 项目，也可以派业务人员进入共创。尖刀队负责筛选、诊断、共创、交付和复盘。
筛选标准不要复杂。
我会看四个维度。
1 战略价值。 是不是和公司当前最重要的增长、效率、风控目标相关。
2 流程密度。 是不是存在大量重复判断、文本处理、信息流转和跨系统动作。
3 业务痛感。 是不是业务负责人真的愿意投入时间，而不是只想要一个演示。
4 复用价值。 是不是能沉淀成平台能力、通用 Skill、行业模板或流程资产。
这样中心就能形成两条线。
一条线看前沿能力、平台架构、治理规则和共用资产。
另一条线深入业务场景，和部门一起交付一个个可见结果。
前者保证不散，后者保证不空。
管理者要给的，不只是口号
AI 变革很难。
难，才说明它有价值。
如果所有部门自己都能顺手做完，AI 早就不是问题了。
真正考验管理者的地方，是能不能给这支队伍资源和授权。
不能只让它背指标，又不给人。不能只要求创新，又不允许失败。不能只让它推广，又不给它进入业务现场的权力。
一个没有授权的 AI 团队，只会变成会写 PPT 的技术小组。
一支真正的尖刀队，需要三个条件。
第一，有独立预算和优先级。
AI 探索不能永远靠挤时间。它需要模型、平台、数据、外部专家，也需要业务人员投入。
第二，有进入业务现场的权力。
尖刀队不能只听二手需求。它必须看真实流程，接触真实用户，理解真实阻力。
第三，有快速失败的保护。
AI 项目的失败，不应该都算成负分。只要失败能产生有效学习，它就是组织资产。
第四，有评测和运营机制。
不要只看上线。要看使用率、准确率、复用率、节省时间、流程改变和业务结果。
最后，怎么把这套能力迁移到组织里
尖刀队不是永远替所有部门干活。
它的最终价值，是把 AI 能力从中心迁移到业务。
第一阶段，中心团队自己做，快速证明可行性。这个阶段要挑最痛的流程，做出能让业务负责人眼睛一亮的结果。
第二阶段，中心团队带着业务做。业务人员开始学习写 Skill、做评测、拆流程、配运营动作。中心团队负责架构、工具链、质量和安全。
第三阶段，业务部门自己能做一部分。中心团队不再承接所有小需求，而是提供平台、模板、训练营、评测框架和专家会诊。
第四阶段，组织形成 AI 资产库。每做完一个场景，都沉淀成可复用的流程包、Skill 包、Agent 模板和治理规则。
这条路径的现实意义很大。
它能避免企业把 AI 做成一堆孤立试点，也能避免中心团队被需求淹没。它让 AI 从“少数人会用的工具”，变成“组织可以持续生产能力的机制”。
具体方法也不复杂。
先定一个尖刀队。再定一组高价值流程。每个流程用四周到八周做一个可运行版本。上线后立刻看使用数据和业务反馈。有效的沉淀成资产，无效的快速关停。每个月做一次项目组合复盘，决定哪些加码，哪些迁移，哪些放弃。
这件事最难的地方，不是技术路线。
是管理者能不能承认：AI 变革需要一套和传统 IT 不同的组织发动机。
传统 IT 守住底盘，尖刀队突破前沿。两者配合起来，企业 AI 才有机会真正落地。
资料参考
1. McKinsey, The agentic organization: A new operating model for AI
2. McKinsey, Seizing the agentic AI advantage
3. BCG, The Leader’s Guide to Transforming with AI
4. Palantir, AI FDE Overview