AgentSkillsCN

CLEAR

AM(Augmented Mission)五要素定义框架。用于任务启动前的完整性检查,确保 Context、Limit、Eval、Augment、Result 五要素齐备。

中文原作
SKILL.md
--- frontmatter
name: CLEAR
description: AM(Augmented Mission)五要素定义框架。用于任务启动前的完整性检查,确保 Context、Limit、Eval、Augment、Result 五要素齐备。

CLEAR 任务定义框架

CLEAR = 清晰:任务定义必须清清楚楚才能启动。

AM = Augmented Mission:能被 AI 托举的任务才值得启动。

💡 口诀:任务要 CLEAR,执行像 ICE 🧊


框架定位

code
TAES(组织能力)
    ↓
  CLEAR(任务定义)← 本技能
    ↓
  ICE(执行追踪)
    ↓
  Scale(飞轮增长)

核心原则:CLEAR 五要素缺一,则任务不可启动;缺 A,则不是 AM。


五要素详解

字母英文中文核心问题落地位置映射 TAES
CContext明确输入任务描述与上下文清晰吗?MISSION.mdT (资源)
LLimit边界明确"不做什么"了吗?MISSION.md 边界章节T (资源)
EEval验收标准Pass/Fail 可判定吗?MISSION.md AC 列表S (增长)
AAugmentAI可托举产出类型在 AI 能力范围内吗?托举效应分析A (托举)
RResult价值结果产出物对接收方有价值吗?Teams/ 归档E (执行)

何时使用此技能

场景典型任务
🎯 新任务启动检查 AM 定义是否完整可启动
📋 MISSION.md 编写按 CLEAR 结构撰写任务定义
启动评审团队确认五要素是否齐备
🔄 范围变更更新 Limit 边界,重新验证
📊 验收准备确认 Eval 标准可判定

C — Context(明确输入)

定义

任务的起点:描述"要做什么"以及"为什么做"。

必须包含

维度说明示例
任务描述一句话说明任务目标"为酒店 120 间客房提供智能化改造"
客户背景任务发起方的基本信息四星级商务酒店,城市核心商圈
核心需求3-5 条关键需求WiFi 升级、智能客控、App 控制
痛点分析当前问题是什么网络老旧、系统分散、运维成本高
预期效果可量化的改善目标满意度提升 20%,能耗降低 15%

检查清单

  • MISSION.md 文件存在
  • 任务描述清晰、无歧义
  • 客户背景已记录
  • 核心需求已列出(3-5 条)
  • 痛点和预期效果已说明

模板

markdown
### C — Context(明确输入)✅

**任务描述**:{{一句话描述任务目标}}

| 维度 | 内容 |
|------|------|
| **客户背景** | {{客户基本信息}} |
| **改造规模** | {{范围大小}} |
| **核心需求** | {{需求列表}} |
| **客户痛点** | {{当前问题}} |
| **预期效果** | {{量化目标}} |

L — Limit(边界)

定义

明确"不做什么",防止范围蔓延(Scope Creep)。

必须包含

维度说明示例
范围边界✅ 范围内 vs ❌ 范围外120 间客房 ✅ / 其他楼层 ❌
时间边界交付日期、里程碑90 天内交付
资源边界人力/预算/算力配额3 人 × 3 月,≤$50 AI 成本/月
技术边界技术栈/工具限制使用成熟方案,不自研 App

检查清单

  • 范围内/范围外对比表已列出
  • 排除项至少 3 条
  • 资源预算已明确(人力/设备/算力)
  • 时间边界已确定

模板

markdown
### L — Limit(边界)✅

> **明确"不做什么",防止范围蔓延。**

| ✅ 范围内 | ❌ 范围外 |
|----------|----------|
| {{做什么}} | {{不做什么}} |

**资源边界**:

| 资源类型 | 预算/配额 | 说明 |
|----------|----------|------|
| **人力** | {{人月}} | {{团队构成}} |
| **预算** | {{金额}} | {{费用模式}} |
| **算力** | {{配额}} | {{AI 用量}} |
| **工期** | {{天数}} | {{交付日期}} |

E — Eval(验收标准)

定义

Pass/Fail 可判定的验收清单,让"完成"有明确定义。

必须包含

维度说明示例
验收项具体的验收点网络覆盖、App 可用
Pass 条件量化的通过标准WiFi 信号 ≥ -65dBm
权重各项的重要程度20%
状态当前验收状态⏳ 待验收 / ✅ 通过

检查清单

  • 至少 3 项验收标准
  • 每项都有量化的 Pass 条件
  • 权重分配合计 100%
  • 综合评定规则已定义(如 ≥90% 为 Pass)

模板

markdown
### E — Eval(验收标准)✅

> **Pass/Fail 可判定的验收清单。**

| # | 验收项 | Pass 条件 | 权重 | 状态 |
|---|--------|-----------|:----:|:----:|
| 1 | {{验收项}} | {{量化条件}} | {{%}} | ⏳ |

**综合评定**:⏳ **待验收**(权重加总 ≥ 90% 为 Pass)

A — Augment(AI 可托举)

定义

验证产出类型是否在 Allied AI 能力范围内,确保 AI 能"真干活"。

必须包含

维度说明示例
任务环节可拆分的工作项需求分析、方案设计、文档生成
AI 可执行?是否可被 AI 托举✅ / ⚠️ 部分 / ❌
托举方式具体如何使用 AICopilot 辅助代码生成
托举比效率提升倍数3× / 5× / 10×

托举效应验证

code
托举效应 = Workplane (bit可靠) × AITa (Token可用)
  • Workplane 可达:网络通道、访问权限正常
  • AITa 可用:AI 订阅有效、配额充足

检查清单

  • 主要任务环节已列出
  • 每个环节标注了 AI 可执行性
  • 整体托举比 ≥ 3× 的环节占 50%+
  • Workplane 可达性已验证
  • AITa 可用性已确认

模板

markdown
### A — Augment(AI 可托举)✅

> **产出类型在 Allied AI 能力范围内。**

| 任务环节 | AI 可执行? | 托举方式 | 托举比 |
|----------|:----------:|----------|:------:|
| {{环节}} | ✅ | {{方式}} | {{倍}} |

**托举效应验证**:
- ✅ Workplane 可达({{说明}})
- ✅ AITa 可用({{订阅状态}})

**结论**:本项目 {{百分比}} 工作可被 AI 托举,符合 AM 定义。

R — Result(价值结果)

定义

产出物对接收方有价值,并归档到 Teams/

必须包含

维度说明示例
交付物具体产出名称竣工文档、操作手册
规格交付物的详细规格网络拓扑图 + 设备清单
存放位置归档路径Teams/Artifacts/
价值对接收方的意义可维护性、可操作性

检查清单

  • 主要交付物已列出
  • 每个交付物有明确规格
  • 存放位置已规划
  • 价值说明清晰

模板

markdown
### R — Result(价值结果)⏳

> **产出物对接收方有价值,归档 Teams/。**

| 交付物 | 规格 | 存放位置 | 价值 |
|--------|------|----------|------|
| {{交付物}} | {{规格}} | `Teams/Artifacts/` | {{价值}} |

CLEAR 验收总结模板

markdown
### 📊 CLEAR 验收总结

| 字母 | 要素 | 状态 | 说明 |
|:---:|------|:----:|------|
| **C** | Context | ✅/⏳/❌ | {{说明}} |
| **L** | Limit | ✅/⏳/❌ | {{说明}} |
| **E** | Eval | ✅/⏳/❌ | {{说明}} |
| **A** | Augment | ✅/⏳/❌ | {{说明}} |
| **R** | Result | ✅/⏳/❌ | {{说明}} |

**AM 就绪评估**:{{状态}}
- ✅ **可启动**:五要素齐备
- 🟡 **待补充**:部分要素缺失
- ❌ **不可启动**:关键要素缺失

快速检查表

5 分钟 CLEAR 审查

#问题对应要素✅/❌
1MISSION.md 存在且任务描述清晰?C
2"不做什么"列出了 3 条以上?L
3验收标准可以 Pass/Fail 判定?E
450%+ 工作可被 AI 托举?A
5交付物已规划归档位置?R

评判标准

  • 5/5 ✅ → 可启动
  • 4/5 ✅ → 24h 内补齐后启动
  • 3/5 ✅ → 需重新评估
  • ≤2/5 ✅ → 任务定义不合格

常见问题

Q1: CLEAR 和 ICE 什么关系?

CLEAR 是任务定义(启动前),ICE 是执行追踪(启动后)。

口诀:任务要 CLEAR,执行像 ICE 🧊

Q2: 缺少 A(Augment)还能启动吗?

可以启动,但不是 AM

AM = Augmented Mission,缺 A 意味着 AI 无法托举,需评估是否值得投入。

Q3: Limit 边界定得太严怎么办?

边界可以在任务执行中调整,但需要:

  1. 记录变更原因
  2. 更新 MISSION.md
  3. 重新评估 Eval 标准

Q4: Eval 标准怎么定才合理?

SMART 原则

  • Specific:具体(不说"提升性能",说"响应时间 < 200ms")
  • Measurable:可测量(有数字、有工具)
  • Achievable:可达成(现有条件下可实现)
  • Relevant:相关(与任务目标直接关联)
  • Time-bound:有时限(验收日期明确)

与 ICE 的衔接

CLEAR 要素ICE 对应流转方式
C (Context)I (Intent)Context 细化为执行意图
L (Limit)C (Condition)Limit 转化为执行条件
E (Eval)E (Eval)验收标准直接沿用
A (Augment)在执行中体现为托举效应
R (Result)在完成时归档 Teams/

🔗 相关技能

技能定位使用时机
MAR战略层理解框架、设计菜单、建模对象
CLEAR任务层任务启动前的五要素检查
ICE执行层任务启动后的追踪留痕

💡 口诀:框架用 MAR,启动用 CLEAR,执行用 ICE 🧂


版本信息

属性
版本v1.0
创建日期2026-01-19
维护者@taes
关联 Agent@taes
关联 SkillMAR, ICE

任务要 CLEAR,执行像 ICE 🧊