---
name: F14_JTBO_result_oriented_task
version: 2.0
framework: 智能体管理学 · 模块三 · 框架14
type: 决策型
description: >
  当用户需要定义Agent任务的「成功结果」而非「要做什么功能」时激活。
  触发词：JTBO、结果导向、什么叫成功、任务定义、需求定义、
  Agent要做什么、结果标准、所有权归属、端到端结果、业务成功率。
  凡涉及「Agent应该交付什么结果、怎么算做对了」的问题均适用。
governance_nerves:
  - "⚡ 神经① 意图管理（结果意图是意图管理的第一步）"
upstream_frameworks: 框架13（APS定位，决定结果定义深度）
downstream_frameworks: 框架15（Context-First Design）、框架16（Reliability-PMF）
---

# 结果导向任务框架 SKILL
## 框架 14 · 决策型 · 智能体管理学模块三

---

## SKILL 定位

这个SKILL将「JTBO结果导向任务框架」从方法论文档转化为可执行的需求定义引擎。

它不定义Agent"做什么功能"，它定义Agent"交付什么结果"。

核心判断：**技术层面的任务完成（Agent按指令做完了所有步骤）和业务层面的结果达成（用户在意的事情真的发生了）之间，存在一个系统性鸿沟。JTBO的任务是消除这个鸿沟。**

---

## 第一步：信息采集

### 必填输入

**INPUT-1：任务描述**
```
Agent要承担的任务（一句话）：
服务的业务环节：
目标用户/受益方：
```

**INPUT-2：APS定位上下文（来自框架13）**
```
产品象限：[工具型/助理型/同事型/数字员工型]
  → 工具型：关注任务完成
  → 同事型/数字员工型：需要端到端结果交付+完整所有权归属
```

**INPUT-3：当前状态（如适用）**
```
当前是否有KPI：[是/否，列出]
当前KPI是否追踪业务结果：[是/否]
当前结果无人负责的情况：[是/否，描述]
```

---

## 第二步：执行分析引擎

### S1 · JTBO三层结构定义

**第一层：任务层（用户委托什么）**

```
任务定义模板：
  用户角色：[谁在委托这个任务]
  任务描述：[用户用自然语言怎么表达这个需求]
  触发条件：[什么情况下这个任务被启动]
  交付物：[任务完成后产出什么]
```

**第二层：结果层（什么叫成功）— 最核心**

```
结果定义四要素：

要素① 结果指标
  什么算成功？（具体、可衡量的指标）
  ❌ 错误示范：「提升客户满意度」
  ✅ 正确示范：「客户NPS评分从35提升至50」

要素② 验证方式
  如何确认结果达成？（数据源、验证流程）
  ❌ 错误示范：「感觉客户更满意了」
  ✅ 正确示范：「月度NPS调查数据，来源：CRM系统」

要素③ 时间窗口
  在什么时间范围内衡量？
  ❌ 错误示范：「持续提升」
  ✅ 正确示范：「90天内达成，之后持续保持」

要素④ 阈值标准
  什么水平算达标？什么水平算优秀？
  达标线：[具体数值]
  优秀线：[具体数值]
  预警线：[低于此值需立即干预]
```

**第三层：所有权层（谁对结果端到端负责）**

```
所有权地图：

结果责任人（Accountable）：[具名人类，必填]
  → 对结果最终负责的人，不可是Agent

执行主体（Agent）：[Agent名称]
  → 负责执行，不负责承担结果责任

监督者（Responsible）：[具名人类]
  → 监督Agent执行质量

结果未达成时的响应机制：
  □ 谁第一个发现？[责任人/系统自动检测]
  □ 谁启动复盘？[责任人]
  □ 复盘后谁决定优化方向？[责任人]
```

---

### S2 · JTBD vs JTBO 对比（已有需求时适用）

```
▎ 需求升级检查

当前需求定义（JTBD视角）：
  用户想完成的工作：[描述]
  当前KPI：[列出]

升级到JTBO后：
  结果指标：[从「功能使用」升级到「业务结果」]
  验证方式：[从「系统日志」升级到「业务数据」]
  所有权：[从「技术团队」升级到「业务责任人」

升级收益：
  □ 消除「任务完成率95%但业务成功率70%」的系统性误判
  □ 建立结果无人负责时的预警机制
  □ 为定价提供价值基础（结果定价 > 功能定价）
```

---

### S3 · 结果定义质量检查

对S1定义的结果，逐一检查：

```
▎ 结果定义质量检查

□ 结果指标是否可衡量？（有数据源、可量化）
□ 验证方式是否可执行？（不依赖主观判断）
□ 时间窗口是否合理？（不过长导致反馈慢，不过短导致焦虑）
□ 阈值标准是否明确？（达标/优秀/预警三线清晰）
□ 所有权是否唯一？（只有一个A责任人，非集体）
□ 所有权层是否有人类承担？（A不可是Agent）

质量评级：
  优秀 → 6项全部✅
  合格 → 5项✅，1项⚠️
  需改进 → 4项以下✅
```

---

### S4 · 结果追踪机制设计

```
▎ 结果追踪机制

追踪频率：[日/周/月]
数据源：[具体系统/报告名称]
自动检测：[是/否，触发条件]

结果未达标的响应流程：
  Level 1：指标低于预警线 → 通知责任人，48小时内响应
  Level 2：指标连续N天低于达标线 → 启动复盘，7天内输出优化方案
  Level 3：指标持续恶化 → 升级至管理层，考虑Agent替换或重构

结果达成的正向机制：
  □ 记录成功案例，纳入Golden Task Set
  □ 更新Agent的DKEP评分中E（执行轨迹）维度
  □ 评估是否可将此Agent能力对外商业化（框架06）
```

---

## 第三步：治理神经检查

```
▎ 治理神经检查

⚡ 神经① 意图管理：
  结果定义是意图管理的第一步。
  如果「什么叫成功」没有被清晰定义，
  后续所有意图传递（F15上下文设计）都会建立在模糊基础上。

⚡ 神经③ 智能体主权：
  所有权层的A必须是具名人类。
  Agent不承担道德和法律意义上的责任。
  所有权缺位 = 责任真空 = 治理风险。

建议联动使用的下一个框架：
→ 框架15「Context-First Design」——结果定义驱动上下文需求
→ 框架16「Reliability-PMF」——Re-delegation Rate验证用户是否真正信任结果
```

---

## 输出质量自检

- [ ] 任务层、结果层、所有权层三层全部定义
- [ ] 结果四要素（指标/验证/时间/阈值）全部填写
- [ ] 所有权A是具名人类（非Agent）
- [ ] 结果追踪机制有频率和响应流程
- [ ] 质量检查6项全部通过

---

## 典型误区提醒

**误区①：把任务完成率当结果达成率**
→ 技术完成（Agent做完所有步骤）≠ 业务成功（用户在意的事发生了）。必须同时追踪两类指标。

**误区②：忽视所有权层，导致结果无人负责**
→ 在产品设计阶段就建立「结果所有权地图」。这是防止责任真空的唯一有效手段。

**误区③：对创意/探索类任务强行定义精确结果**
→ JTBO适用于可明确定义「成功状态」的任务。创意类任务的结果定义应是「满足质量标准」而非「产生特定结果」。

---

## 与体系其他框架的衔接

```
上承：框架13「APS定位」→ 定位决定结果定义深度
      ↓
本框架：结果导向任务框架 → 定义什么叫成功 + 谁负责
      ↓
下启：框架15「Context-First Design」→ 结果定义驱动上下文需求
      框架16「Reliability-PMF」→ 再委托率验证结果信任度
```

---

*智能体管理学 · 模块三 产品重写 · 框架 14 · SKILL V2.0*
*决策型框架 · 输出：JTBO三层结构 + 结果追踪机制*