CLEAR 任务定义框架
CLEAR = 清晰:任务定义必须清清楚楚才能启动。
AM = Augmented Mission:能被 AI 托举的任务才值得启动。
💡 口诀:任务要 CLEAR,执行像 ICE 🧊
框架定位
code
TAES(组织能力)
↓
CLEAR(任务定义)← 本技能
↓
ICE(执行追踪)
↓
Scale(飞轮增长)
核心原则:CLEAR 五要素缺一,则任务不可启动;缺 A,则不是 AM。
五要素详解
| 字母 | 英文 | 中文 | 核心问题 | 落地位置 | 映射 TAES |
|---|---|---|---|---|---|
| C | Context | 明确输入 | 任务描述与上下文清晰吗? | MISSION.md | T (资源) |
| L | Limit | 边界 | 明确"不做什么"了吗? | MISSION.md 边界章节 | T (资源) |
| E | Eval | 验收标准 | Pass/Fail 可判定吗? | MISSION.md AC 列表 | S (增长) |
| A | Augment | AI可托举 | 产出类型在 AI 能力范围内吗? | 托举效应分析 | A (托举) |
| R | Result | 价值结果 | 产出物对接收方有价值吗? | 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 托举 | ✅ / ⚠️ 部分 / ❌ |
| 托举方式 | 具体如何使用 AI | Copilot 辅助代码生成 |
| 托举比 | 效率提升倍数 | 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 审查
| # | 问题 | 对应要素 | ✅/❌ |
|---|---|---|---|
| 1 | MISSION.md 存在且任务描述清晰? | C | |
| 2 | "不做什么"列出了 3 条以上? | L | |
| 3 | 验收标准可以 Pass/Fail 判定? | E | |
| 4 | 50%+ 工作可被 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 边界定得太严怎么办?
边界可以在任务执行中调整,但需要:
- •记录变更原因
- •更新 MISSION.md
- •重新评估 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 |
| 关联 Skill | MAR, ICE |
任务要 CLEAR,执行像 ICE 🧊