| name | enterprise-fde-识别AI节点 |
| slug | enterprise-fde-识别AI节点 |
| description | 当 FDE 需要对工作流节点做 AI 分类判定时用这个 Skill—— 不是"它是干什么的",是"什么时候用"。 写错 description = Skill 永远不会被触发。
|
| version | 1.1.9 |
| tags | ["企业专属","FDE","节点判定"] |
| image | skill-template.png |
| note | ⚠️ 这是给客户企业 AI 节点用的 Skill 模板(以 sofagent 自身为案例), 不是 FDE Agent 自己的 Skill。FDE 自己的 Skill 在 FDE/SKILL.md。
|
企业专属 Skill · 识别 AI 节点(sofagent 自案例 · 模板)
📋 这是模板文件——给客户企业每个 AI 节点定制的 Skill 格式参考。
不是 FDE Agent 自己的 Skill(那个在 FDE/SKILL.md)。
FDE 在 §7-§8 定制。每个 AI 节点一个专属 Skill,注入企业的行业术语 / 业务规则 / 历史案例。
实际产出路径:skills/fde-识别AI节点/SKILL.md(每个节点一个目录,SKILL.md 是入口)。
初始版本由 FDE 写,运行后基于 eval.md 评分自动迭代——不需要 FDE 手动调。
行业术语
这个节点所在领域的专有词汇和缩写:
| 术语 | 含义 | 用在哪 |
|---|
| 🔄 自动执行 | 规则明确、高频重复、输入输出可结构化的节点 | 分类判定结果 |
| ⚡ 强化岗位 | 需要判断但规则可描述,AI 做领航员的节点 | 分类判定结果 |
| 👤 暂时不动 | 依赖直觉经验或数据不可达的节点 | 分类判定结果 |
| 五要素 | 输入/输出/负责人/耗时/痛点 | 节点完整性判断 |
| 三问判定法 | 输入能自动取?规则能写清?输出能自动推? | 分类核心规则 |
业务规则
这个节点必须遵守的规则。Agent 会严格执行:
- 输入必须是完整的五要素——缺任何一项先标记"不完整",不强行判定
- 三问判定法的答案必须基于事实("有 API"≠"API 能用"),不能猜
- 边界情况(两问 yes 一问 no)判为 ⚡,不是 🔄
- 判定理由必须一句话写清楚,不能只填"符合 🔄 特征"
- 任何人都可以 override 判定结果,但 override 必须记录理由
历史案例
这个节点跑过的典型案例,Agent 做决策时参考:
案例 1:数据拉取 → 🔄
- 输入:ERP API(有接口,能自动取)
- 规则:拉昨日销售数据(新人照着文档能做)
- 输出:写入飞书表格(API 可推)
- 判定:三 yes → 🔄
案例 2:设计稿审核 → ⚡
- 输入:Figma 设计稿(能自动取)
- 规则:审核是否符合设计规范(规范可描述,但需要审美判断)
- 输出:审核意见推给设计师(能自动推)
- 判定:两 yes 一 no(规则需判断)→ ⚡
案例 3:战略决策 → 👤
- 输入:市场数据 + 老板直觉(直觉不可自动取)
- 规则:没有固定规则
- 输出:决策结果
- 判定:零 yes → 👤
约束
这个节点的 Skill 不准做什么:
- 不准在五要素不全时强行判定
- 不准跳过三问直接凭经验分类
- 不准把"理论上能做到"当成"实际能做到"("有 API"但"API 没开权限"= 不能自动取)
- 不准修改工作流节点图(只读输入,只写分类清单)
迭代记录
Skill 优化分析自动维护,FDE 不用手动写:
| 版本 | 日期 | 改了什么 | 触发原因 |
|---|
| 1.0 | 2026-07 | FDE 创建初始版本 | — |