起点：一次颗粒度上的错配
我们对外说「能力库」，一位企业侧负责人看完之后提了一个很直接的问题：你们说这是个库，但我看到的是九个已经做好的产品——库应该是积木，你给我的是货架上的成品。
这句话戳中了真实的问题。成品软件是按「谁来用、怎么用」组织的：它有自己的界面、自己的账号体系、自己的完整流程， 适合直接采购、直接使用。但企业要建自己的智能体时，需要的不是再多一个独立入口，而是能被嵌进现有流程的一段段动作。 把成品整体推过去，对方拿到的是一个不好拆的整块，只能选择「全用」或「不用」。
于是我们做了一次视角上的重构：不改产品，也不新造功能，而是换一个坐标系重新描述已有的东西—— 从「我们有哪些产品」改成「我们能提供哪些可以被单独取用、单独验证、单独嵌入的能力」。 重构的结果，是 70+ 项可组装的 AI 原子能力。
什么才算一条「原子能力」
重构最先要解决的是定义问题。如果没有判据，「能力」很容易写成另一种形式的宣传语—— 「智能内容生成」「高效流程优化」这类词看起来像能力，实际上无法验证、无法组装、也无法比较。我们最终采用了三条硬判据：
第三条是自我约束里最重要的一条。能力清单一旦脱离实际实现，就会变成一份好看但危险的材料—— 销售阶段答应的事情，交付阶段兑现不了。为此我们在数据层做了强制关联：产品侧的每一条能力都绑定到具体产品， 任何指向不存在产品的条目都会在构建阶段被拦下来。
还有一条容易被忽略的检验标准：把能力名单独念给业务方听，对方要能立刻判断「这能不能用在我这儿」。需要追问三句才能明白的，说明抽象层级不对，要么太大，要么太模糊。
怎么拆：从一个产品到若干条能力
拆解的过程不神秘，但需要克制。我们按四步走，每一步都有明确的产物：
第一步：列出产品真实做过的事
不看宣传页，看功能实现与实际使用记录。这一步要回答的是「这个产品到底在替用户完成哪些动作」， 而不是「我们希望它被理解成什么」。
第二步：按输入输出切分
同一个产品里，输入形态或输出形态不同的动作要拆开。比如「输入一段文字、产出图像」和「输入一张图、产出改写后的图」， 虽然在同一个界面里，但对企业来说是两条可以分别取用的能力，接入方式与评测方式都不一样。
第三步：按稳定性归层
切出来的条目按 Skill · 技能、Workflow · 工作流、Agent · 智能体 三层归位： 单点动作归 Skill，串起多个动作且保留人工审核节点的归 Workflow，需要自主规划与工具调用的归 Agent。 归层不是打标签，它直接决定了交付周期的量级与验收方式。
第四步：补齐行业侧的通用场景
产品线覆盖不到的部分，来自我们在具体行业里反复遇到的通用场景。这部分条目只作通用表述， 不指向任何一家企业的系统、流程或数据——这是重构过程中一条不可让步的纪律。
拆完之后，清单长成了什么样
最终形成的清单有两个可以交叉筛选的维度：层级与行业。
按层级看
条目在 Skill 层最密集，向 Workflow、Agent 逐层收窄。这个形状是真实的：单点动作容易被做稳， 越往上越依赖具体业务上下文，能预先沉淀为通用条目的就越少。
按行业看
覆盖金融科技、教育、物流供应链、内容 / 零售、餐饮连锁五个方向。其中金融科技、教育、物流供应链 是我们已建过系统的行业；内容 / 零售与餐饮连锁列出的是能力直击的场景，不作系统层面的资质声明。
这里有一个刻意的设计：标记为「跨行业通用」的能力，不会在按行业筛选时自动出现。听起来反直觉，但如果让通用能力命中每一个行业，筛「餐饮」时会混进几十条与餐饮无关的通用条目， 把这个行业真正相关的能力冲淡，筛选也就失去了意义。
完整清单是公开的，支持按层级与行业两个维度交叉筛选：查看 70+ 项能力清单。
这次重构改变了三件事
一、选型对话的起点变了
以前的对话是「你们这个产品能不能满足我们的需求」，答案往往是含糊的「可以定制」。 现在的对话是「我这段流程需要这三条、那两条」，双方讨论的对象从产品变成了动作，含糊空间大幅收窄。
二、工作量估算有了拆分依据
一个需求可以被拆成「已有能力若干 + 新增能力若干」。已有部分的实现路径是清楚的，新增部分才需要为不确定性留缓冲。 这让「这个要做多久」第一次有了可讨论的结构，而不是一个凭经验给出的整数。
三、复用第一次变得可见
同一条能力被两个部门用到时，第二次接入不需要重新开发。在产品视角下这件事是模糊的—— 两个部门看到的是两套系统；在能力视角下它是显式的——两个场景引用了同一个条目。
能力视角带来的实际差别
- 可以只取用其中一部分，不必整套采购。
- 每条能力单独验证，失败范围被限制在这一条上。
- 数据边界逐条设定，敏感度不同的能力可以采用不同的部署形态。
- 组合方式由业务决定，我们提供积木而不是规定拼法。
怎么用这份清单做自己的方案
清单本身只是原料，真正有用的是取用方法。我们建议按三步来：
筛 · 组 · 验
- 筛：先按行业筛一轮，再按层级过一遍，圈出与你当前流程直接相关的条目，控制在十条以内。
- 组：把圈出的条目按你实际的业务顺序串起来，看看中间缺哪几段——缺口就是需要新增开发的部分。
- 验：为串起来的第一段流程准备一份评测样本，先验证最前面那一条 Skill，再逐段往后推。
这个方法有一个副产品：你会很快发现自己真正的瓶颈在哪一层。 如果十条里有八条是 Skill 层，说明当前阶段该做的是把基础动作做稳； 如果缺口集中在串联环节，说明问题在流程设计而不在模型能力。 这类判断在成品视角下很难得出，因为成品把所有环节都包在里面看不见。
重构过程中守住的几条纪律
一份对外的能力清单，写错的成本远高于写少的成本。整个过程我们守了四条纪律，写在这里也是一种自我约束：
最后一条看起来是工程细节，其实是内容诚信问题。一个硬编码在页面上的数字，在清单增删之后就变成了一句不准确的话， 而没有人会记得回来改它。让它由数据算出来，是让描述与事实保持同步的最省力办法。
常见问题解答
Q: 拆成原子能力之后，原来的产品还能整套用吗？
A: 可以。能力视角是对同一批实现的另一种描述方式，不是替换。想要开箱即用的团队仍然可以整套使用产品， 想要嵌入自有流程的团队则按能力取用，两条路径并存。
Q: 能力清单会变吗？变了怎么办？
A: 会变，而且应该变。清单跟随实际能力增删，页面上的统计由数据计算得出，因此新增条目之后展示会自动同步。 这也是我们不在文案里写死精确数字的原因。
Q: 我们只需要其中两三条，也可以吗？
A: 可以，这正是能力视角要解决的问题。取用范围由业务需要决定，不需要为了用到其中一部分而整体接入。
Q: 涉及敏感数据的能力怎么处理？
A: 按条设定数据边界，敏感度高的能力可以优先在企业自有环境内运行，我们支持完整的私有化部署形态； 面向公众提供服务的生成式能力，还需要把国家算法备案等合规要求纳入设计阶段一并考虑。