---
name: enterprise-fde-识别AI节点
slug: enterprise-fde-识别AI节点
description: >
  当 FDE 需要对工作流节点做 AI 分类判定时用这个 Skill——
  不是"它是干什么的"，是"什么时候用"。
  写错 description = Skill 永远不会被触发。
version: 1.2.5
tags: [企业专属, FDE, 节点判定]
image: skill-template.png
note: >
  ⚠️ 这是给客户企业 AI 节点用的 Skill 模板（以 sofagent 自身为案例），
  不是 FDE Harness 自己的 Skill。FDE 自己的 Skill 主入口在 SKILL/SKILL.md。
---

# 企业专属 Skill · 识别 AI 节点（sofagent 自案例 · 模板）

> 📋 **这是模板文件**——给客户企业每个 AI 节点定制的 Skill 格式参考。
> 不是 FDE Harness 自己的 Skill（那个主入口在 `SKILL/SKILL.md`，阶段指引在 `SKILL/skills/01-05`）。
>
> FDE 在 §7-§8 定制。每个 AI 节点一个专属 Skill，注入企业的行业术语 / 业务规则 / 历史案例。
> 实际产出路径：`skills/fde-识别AI节点/SKILL.md`（每个节点一个目录，SKILL.md 是入口）。
> 初始版本由 FDE 写，运行后基于 eval.md 评分自动迭代——不需要 FDE 手动调。

## 行业术语

这个节点所在领域的专有词汇和缩写：

| 术语 | 含义 | 用在哪 |
|------|------|--------|
| 🔄 自动执行 | 规则明确、高频重复、输入输出可结构化的节点 | 分类判定结果 |
| ⚡ 强化岗位 | 需要判断但规则可描述，AI 做领航员的节点 | 分类判定结果 |
| 👤 暂时不动 | 依赖直觉经验或数据不可达的节点 | 分类判定结果 |
| 五要素 | 输入/输出/负责人/耗时/痛点 | 节点完整性判断 |
| 三问判定法 | 输入能自动取？规则能写清？输出能自动推？ | 分类核心规则 |

## 业务规则

这个节点必须遵守的规则。Agent 会严格执行：

1. 输入必须是完整的五要素——缺任何一项先标记"不完整"，不强行判定
2. 三问判定法的答案必须基于事实（"有 API"≠"API 能用"），不能猜
3. 边界情况（两问 yes 一问 no）判为 ⚡，不是 🔄
4. 判定理由必须一句话写清楚，不能只填"符合 🔄 特征"
5. 任何人都可以 override 判定结果，但 override 必须记录理由

## 历史案例

这个节点跑过的典型案例，Agent 做决策时参考：

### 案例 1：数据拉取 → 🔄
- 输入：ERP API（有接口，能自动取）
- 规则：拉昨日销售数据（新人照着文档能做）
- 输出：写入飞书表格（API 可推）
- 判定：三 yes → 🔄

### 案例 2：设计稿审核 → ⚡
- 输入：Figma 设计稿（能自动取）
- 规则：审核是否符合设计规范（规范可描述，但需要审美判断）
- 输出：审核意见推给设计师（能自动推）
- 判定：两 yes 一 no（规则需判断）→ ⚡

### 案例 3：战略决策 → 👤
- 输入：市场数据 + 老板直觉（直觉不可自动取）
- 规则：没有固定规则
- 输出：决策结果
- 判定：零 yes → 👤

## 约束

这个节点的 Skill 不准做什么：

- 不准在五要素不全时强行判定
- 不准跳过三问直接凭经验分类
- 不准把"理论上能做到"当成"实际能做到"（"有 API"但"API 没开权限"= 不能自动取）
- 不准修改工作流节点图（只读输入，只写分类清单）

## 迭代记录

Skill 优化分析自动维护，FDE 不用手动写：

| 版本 | 日期 | 改了什么 | 触发原因 |
|------|------|----------|----------|
| 1.0 | 2026-07 | FDE 创建初始版本 | — |