AI-Wiki

定义

可组合能力单元设计 是一种 AI 工作流设计方法：把单个能力封装成可复用的独立单元，每个单元既能在用户直接提供所需输入时单独运行，也能在更复杂任务中与其他能力串联或并联调用。

核心要求不是“把提示词写长”，而是把能力边界写清楚：什么时候触发、接收什么输入、产出什么输出、需要哪些规则、在哪些情况下应与其他能力协作。

它要解决的问题，是传统“单体式超长提示词”只能在某一次对话里勉强跑通，但一旦场景变化、上下文缺失或步骤需要重排，就会出现格式漂移、环节遗漏、维护困难等问题。

在本文档中的语境

在本文语境中，这个概念来自 Anthropic 的 Skills 设计思路：不要把工作流理解成“一段万能提示词”，而应理解成“多个可按需调用的能力单元”。

一个能力不应假设自己是系统里唯一可用的能力。

这意味着一个能力单元在设计时就要考虑两类运行方式：

独立运行：用户已经提供了完成该能力所需的输入，能力可以直接产出结果。
组合运行：当前能力只是更长链路中的一个步骤，需要承接上游输出，或为下游提供结构化结果。

文中用“抓取新闻”和“写稿”举例说明：

用户直接说“帮我写今天的新闻稿”，系统可能需要先调用抓取能力，再调用写稿能力。
用户已经手动准备好素材，再说“根据这个写稿”，这时只需要调用写稿能力。

因此，写稿能力不能把“抓取新闻”硬编码为自己的前置步骤；同样，抓取能力也不应假设自己一定负责后续写作。

为什么需要这种设计

避免单体式超长提示词

单体式提示词通常把角色、步骤、规则、样例、审核要求、格式规范全部塞进一次输入里。这样做短期看似省事，但问题很多：

每次执行都要重新解释整套流程。
不同任务只想复用其中一部分时，很难拆开。
规则一旦修改，往往要整段提示词重写。
模型可能在长上下文中忽略某些关键约束。
工作流一旦变动，就容易出现“上次能跑、这次失效”的情况。

可组合能力单元设计的做法，是把重复动作拆成稳定模块，把变化留给编排层或调用层处理。

支持复用与维护

当能力被拆成独立单元后，工作流的演化方式会发生变化：

新流程上线时，不必从零写一条新提示词，而是组合现有能力。
某个环节规则变化时，只需修改对应能力单元。
同一能力可以服务多个场景，而不是绑死在某一条固定流程里。
不同人或不同 Agent 可以共享同一套能力规范。

原文明确指出，这样做的结果是：

新流程上线更快，因为能力可复用；
维护成本更低，因为改一个能力不影响全局；
稳定性更高，因为依赖规则化能力而不是临时拼凑。

关键机制或组成

1. 明确触发条件

每个能力单元都必须写清楚“什么时候应该被使用”，而不仅仅是“它能做什么”。

这是因为系统需要先判断某个能力是否相关，再决定是否加载其详细规范。若只写“生成新闻文章”这类功能描述，而不写“当用户说写稿、二创、提供新闻链接或上传 markdown 文件时使用”，就会出现两个极端：

要么系统每次都加载它，浪费上下文和 token；
要么系统缺乏判断依据，根本不调用它。

因此，触发条件不是可选注释，而是能力能否被正确调度的入口元数据。

2. 明确输入与输出

可组合的前提，是上游和下游之间能稳定交接。为此，每个能力都要定义最小必要输入和可复用输出。

原文给出的能力清单示例非常典型：

能力	触发条件	输入	输出
抓取新闻	用户说“抓新闻”	日期 + 关键词	Markdown 新闻列表
写稿	用户说“写稿”或提供素材	素材文件路径	草稿 Markdown
审校	用户说“审稿”	草稿路径	终稿 + 修改建议
配图	用户说“配图”	文章路径	插入图片的文章
发布	用户说“发布”	终稿路径	发布状态

这个表说明了两件事：

输入输出要具体到可交接的数据形态，而不是抽象写“给我一些内容”“输出结果”。
输出最好天然能成为下一个能力的输入，例如“草稿 Markdown”可被审校能力继续消费。

3. 独立规范文件而不是一条总提示词

原文建议把每个能力写成独立规范文件，而不是继续堆叠到一个总提示词中。其核心思路是：主入口只做能力目录与路由，具体能力各自维护。

这种组织方式与渐进式披露式能力组织是一致的：

第一层只暴露能力名称、简要描述和触发条件，用于判断是否调用；
第二层进入能力正文，包含完整步骤、执行规则和最佳实践；
第三层再按需引用模板、案例、参考资料等深度上下文。

这意味着能力单元本身既是执行模块，也是知识组织模块。它不要求所有细节始终加载，而是支持按需展开。

4. 能力内部要有自检，而不是把审查都留给人

虽然“可组合能力单元设计”的重点是模块化，但原文把它和自检机制紧密联系在一起。原因是：如果每个能力都必须靠人工校验后才能进入下游，组合链路会迅速被人为阻塞。

因此，一个成熟的能力单元不只定义“怎么做”，还应定义“做完后如何自检”。例如写作能力可以在内部附带检查项：

标题是否在 30 字以内；
导语是否在 100 字以内；
是否包含 3 到 5 个小节；
每个小节是否有小标题；
结尾是否有行动建议。

原文特别强调：如果自检发现不符合，不要询问用户，而是自动修正后再输出。

这使能力单元更像一个可独立闭环的执行模块，而不只是“生成半成品等人工返工”的片段。它与自检驱动的AI工作流直接相关。

细节与边界

细节 1：可组合不等于必须拆得无限细

可组合能力单元设计强调模块化，但并不意味着每个动作都要拆成极细颗粒。拆分是否合理，要看触发条件、输入输出和协作边界是否清晰。

如果两个步骤高度耦合、共享大量上下文、几乎从不单独调用，强行拆开只会增加交接成本。反过来，如果某一步经常被单独复用，或会被不同上游触发，那它就适合抽成独立能力。

这一点也与上下文边界驱动的多智能体设计的判断原则一致：是否拆分，不按表面角色划分，而要看上下文边界与状态依赖。

细节 2：能力单元不能偷偷依赖隐藏前提

一个能力如果标称“可独立运行”，就不能默认某些前置步骤已经做完，除非这些前置条件被明确写进输入要求。

例如“写稿”能力如果需要新闻素材，就应明确输入是素材文件、链接或 Markdown 列表；而不是在正文里隐含要求“系统先帮我抓完新闻”。否则它在组合场景中看似可用，独立运行时却会失效。