一步步设计
用任务动词和输出物定义需求
虚构请求：“根据材料新建一份产品介绍 PPT。”新建与修改已有 PPT 是不同任务。state 包含用户目标、已存在的文件类型、期望输出和限制；只看到 PPT 关键词不能判断应该加载编辑还是创作技能。
为目录写可辨认的能力边界
技能卡保存 ID、描述、输入输出、前置条件和不适用项。目录由应用维护，路径与版本受控。若把全部描述截成一句“处理 PPT”，后续选择缺乏事实；先改索引质量，不要指望评分补回被删掉的差异。
先召回，再按完整描述复核
官方技能配方先排序候选，再读较完整信息复核。本例最多选三个候选作教学预算。第二阶段核对是否支持新建、当前文件是否可用、是否需要外部权限；第一阶段高排名只是阅读优先级。
明确允许 none 与继续补问
如果候选都要求已存在文件，而用户要从零创作，选择 none 或扩大检索。若用户说“处理这个 PPT”而文件缺失，先补充任务；不要因为必须返回一个名称而随意加载。技能推荐也不等于获准安装新插件。
检查最终任务，而不是只算选中率
记录候选召回、错误加载、无需求却加载以及任务完成情况。即使选对技能，执行仍可能失败；保留所选技能版本与运行结果。测试创建/编辑、格式转换、无技能需求、目录过期及多语言描述。
完整走查 · 本站虚构样本
| 观察到什么 | 如何判断 | 代码怎么处理 |
|---|---|---|
| 从零新建 PPT | 创作技能更符合任务 | 读完整条件后加载允许的技能 |
| 已有 PPT，仅替换一段文字 | 编辑能力更符合 | 避免重建整个文件 |
| 候选均不支持请求 | 没有适用项 | none，扩大检索或补问 |
可复制的设计草案
以下为本站原创示例。JSON 展示请求或输入形状；Python 仅计算虚构分数，不调用 API。真实接入仍需核对官方接口及任务策略。
# Invented candidate contract.
{
"task": "create a new deck from notes",
"available_inputs": ["plain_text"],
"candidates": [
{"id": "deck-author", "inputs": ["plain_text"], "creates_new": true},
{"id": "deck-editor", "inputs": ["pptx"], "creates_new": false}
],
"none_allowed": true
}容易踩的坑
- 只按文件扩展名挑技能。
- 把首阶段排名当适用性确认。
- 为了返回结果总强选一个。
TRY / THINK / COMPARE
先想一想，再看解析
候选技能排名第一，但要求现成文件，而用户只有文字材料，怎么办？
展开解析
检查它是否明确支持从文字新建；不支持就拒绝该候选，寻找创作能力或返回 none，不能把材料当作已有演示文件。
交付前检查
- 技能描述保留输入输出与限制。
- 候选 ID 和版本可追溯。
- 第二阶段可以拒绝全部候选。
- 选择结果与任务完成分别评价。
常见问题
推荐就是加载命令吗？
应视作建议；应用仍检查可用性与权限。
候选数量越多越好吗？
更多候选增加输入与歧义，按召回质量与成本验证预算。
资料与延伸阅读
参考官方架构模式与 Datawhale 实战主题，本站独立编写讲解、案例与练习。示例为教学设计，未调用 API，不代表性能测试。