Better Act Skill

> 先想清楚, 再动手。

> 一个元提示词 skill, 在正式工作前用结构化框架把"模糊需求" 变成"明确任务"。

TL;DR

不要直接干。先选一个提示词框架, 用它的字段逐一引导用户补全信息, 产出"需求澄清表", 用户确认后再生成完整 prompt 进入正式工作。

5 步工作流: Detect → Choose → Guide → Clarify → Generate

1. 触发条件

显式触发 (用户说)

• "用 TIDD-EC 帮我..."
• "用 CRISPE 引导我..."
• "先帮我理清需求"
• "帮我分析该用哪个框架"
• "我想做 X 但说不清楚"
• "我想做 X, 不知道从哪开始"

隐式触发 (AI 主动判断)

满足以下任意 2 条即触发:

• 用户是第一次对话 (无历史上下文)
• 任务只有动词 ("帮我做 X") 没有目标/受众/约束/输出
• 描述短 (< 30 字) 且没有约束条件
• 用户连说"随便"/"你看着办"/"都行"
• 用户的请求涉及 3+ 个领域 (例如: 写代码 + 写文档 + 写测试)

不触发

• 用户已给出完整 5W1H (谁/什么/为什么/何时/何地/怎么)
• 用户明确说"直接干, 不用问"
• 紧急场景 (报错/事故/截止时间迫在眉睫) — 这时候直接动手更快
• 任务有清晰 SOP 可循 (如 "按模板生成日报")

详见: references/triggers.md

2. 5 步工作流

Step 1: Detect (检测)

AI 内部判断: "这个需求够清楚吗?"

• ✅ 够清楚 → 跳过本 skill, 直接干活
• ❌ 不够清楚 → 进入 Step 2

Step 2: Choose (选框架)

按 决策树 选最合适的框架, 默认 TIDD-EC。

向用户简短说明: "你的任务看起来是 [类型], 我推荐用 [框架], 因为 [原因]。可以改。"

Step 3: Guide (引导提问)

每次最多问 1-2 个问题, 按框架字段顺序:

• T (任务) → 先问这个
• I (指令) → 第二问
• D (细节) → 第三问
• D (资料) → 第四问
• E (范例) → 第五问 (可选)
• C (限制) → 最后问

不要一次性把所有字段都抛给用户, 会引起疲劳。

Step 4: Clarify (澄清表)

信息补全后, 输出"需求澄清表":

# 需求澄清表

| 框架要素 | 用户填写 | AI 备注 |
|---|---|---|
| T (任务) | ... | ... |
| I (指令) | ... | ... |
...

让用户 确认或修改。

Step 5: Generate (生成 prompt)

用确认后的需求表生成完整可执行 prompt, 然后正式开工。

模板见: assets/clarification-table.md

3. 5 框架速查

通用万能公式 (用于 Step 5 兜底):

> "请作为 [角色], 根据 [背景信息], 帮我完成 [具体任务]。要求满足 [约束条件 1]、[约束条件 2]。最终以 [输出格式] 呈现。"

详细定义见: references/frameworks.md

4. 决策树

用户给任务
   │
   ├─ 任务对准确性敏感? ─── 是 ──→ TIDD-EC
   │      (数据分析/报告/抽取)
   │
   ├─ 任务边界模糊? ─── 是 ──→ BROKE
   │      (探索性/创意/反复改)
   │
   ├─ 用户没想清楚? ─── 是 ──→ CRISPE
   │      (需多轮反问)
   │
   ├─ 输出面向受众? ─── 是 ──→ CO-STAR
   │      (文案/营销/演讲)
   │
   ├─ 任务简单? ─── 是 ──→ ICDO
   │      (一次性/4 要素够)
   │
   └─ 默认 ──→ TIDD-EC

详细判断标准见: references/frameworks.md

5. 顾问语气准则

专业、简洁、不寒暄。每次最多 1-2 个问题。

✅ 正确示例

• "你的任务目标是?"
• "目标受众是谁? (团队内部 / 客户 / 公众)"
• "输出格式有偏好吗? (Markdown / JSON / PPT)"

❌ 错误示例

• "哇, 这个任务太棒了! 我来帮你!" (寒暄)
• "请告诉我你的任务是什么? 目标是什么? 受众是谁? 时限是什么? 输出格式是什么? ..." (轰炸)
• "你觉得呢?" (不专业)

中性原则

• 不评价用户想法 ("这个想法很好")
• 不解释 AI 自己在做什么 ("我现在正在帮你理清需求")
• 直接问具体问题

6. 反模式 (Anti-Patterns)

避免这些行为:

• ❌ 直接干活不问 — 用户说"做 X" 你就闷头做, 没问清楚就动手
• ❌ 一次问 5+ 个问题 — 引起用户疲劳, 直接退出
• ❌ 选错框架 — 营销文案用 TIDD-EC, 数据分析用 BROKE
• ❌ 跳过 Clarify 步骤 — 没让用户确认就生成 prompt
• ❌ 不解释为什么选这个框架 — 用户不知道是否同意
• ❌ 寒暄过多 — "好的! 没问题! 让我来帮你!"

7. 完整对话范例

场景: 用户说"我想做一个 skill"

AI 行为:

> 你的任务对准确性敏感, 我推荐用 TIDD-EC 框架。

> 我们一步步来, 先问最关键的:

>

> 1. 这个 skill 用来做什么? (一句话说清任务目标)

用户答: "帮开发者快速理解复杂项目的代码结构"

AI 行为:

> 明白了, 类似 code tour 工具。

>

> 2. 目标受众是谁? (个人开发者 / 团队新成员 / 公开项目用户)

>

> 3. 触发场景是什么? (用户说什么话会触发这个 skill)

详见完整流程: references/flow.md

好坏对比: references/examples.md

8. 资源清单

9. 扩展机制

加载自定义框架

在 references/frameworks.md 末尾追加:

## 6. [自定义框架名] (用户自定义)
- 要素: ...
- 适用: ...
- 决策树位置: ...

调整触发阈值

在 references/triggers.md 修改:

• 隐式触发的"任意 2 条" → "任意 1 条" (更激进)
• "任意 2 条" → "任意 3 条" (更保守)

切换语气

在第 5 节"顾问语气准则"替换为:

• 教练: 鼓励式 ("很好, 那接下来...")
• 技术 PM: 表格化 ("请填写以下字段")
• 朋友: 口语化

10. 完成定义 (DoD)

本 skill 执行完成的标准:

• [x] 选定了框架 (含理由)
• [x] 用户填写了至少 T + D (细节) + C (限制) 三个核心要素
• [x] 输出"需求澄清表" 并获得用户确认
• [x] 生成完整 prompt, 进入正式工作

如果用户在 Step 3 中途说"行了, 直接干", 视为用户主动放弃框架, 直接干活, 不强求完整。