新人AI —— STAR 任务结构化（starskill）
> 专为 AI 新手设计：想到哪说到哪，AI 也能听懂
目的与效能逻辑
非熟练 AI 用户的输入往往高度碎片化：背景、抱怨、需求、限制条件分散在多条消息里，甚至分好几天才说完。如果不加处理直接执行，最常见的后果是方向跑偏 → 返工重来，一次返工消耗的 token 和时间，远超一次确认。
本技能在正式执行前插入一道低成本确认环节：先用 STAR 框架把碎片整理成任务简报，再给出分项执行计划逐项确认，然后才动手。
核心理念：慢一步确认，换来不返工。
> 注：此处的 STAR 不是简历/面试中的行为面试法，而是借用同一套逻辑（背景→目标→行动→结果）来对齐"我们到底要做什么"。
何时触发
- 用户的消息由多条零散描述拼成，没有一句话式的明确任务陈述
- 用户讲了很多背景/吐槽/需求，但没说清"最终要交付什么"
- 新任务开始时，用户以碎片形式抛出上下文（而非一条完整指令）
- 用户明确要求"帮我理一下"、"结构化一下这个任务"、"用 STAR 整理"
- 用户点名要求使用本技能
无需触发的情形：任务本身极其简单，一句话即可说清且无歧义（例如"把这个文件重命名为 a.txt"）。
核心流程
第一步：提取信息，映射到 STAR
把用户到目前为止说的内容（可能跨多轮消息）归类到四个字段：
| 字段 | 对应问题 | 从用户描述里找什么 |
|---|---|---|
| S Situation 背景 | 现在是什么情况？ | 项目背景、已有条件、上下文、现状、之前的尝试 |
| T Task 目标 | 要解决/达成什么？ | 目标、痛点、"我想要……"、"希望以后……"类表述 |
| A Action 行动 | 需要做哪些具体动作？ | 用户提到的步骤、方法、偏好做法、限制条件（"别用 xxx"、"要用 xxx 格式"） |
| R Result 交付 | 交付物长什么样？怎么判断做完了？ | 输出格式、验收标准、"最后要给我一个……" |
第二步：识别缺口
四个字段里，T（目标）和 R（交付/验收标准）最容易被非熟练用户漏掉——碎片化描述往往只谈背景和过程细节，缺少明确的终点。
处理原则：
- T 或 R 缺失或模糊时，不要瞎猜然后直接开工
- 只用一句话提出最关键的缺口问题（一次只问一个，不甩问题清单）
- 如果缺口不影响启动（例如可以先出初稿再迭代），就声明假设后直接开始，不要卡在提问上
- 向非熟练用户提问时，给选择题而不是开放题："你希望要 A（自动更新的表格）还是 B（可重复运行的脚本）？"
第三步：输出结构化简报
先用简短的 STAR 摘要复述一遍，让用户确认或纠正。格式要简洁，用自然语言，不要写成正式报告：
我理解的任务是这样的：
- 背景：[S，一两句]
- 目标：[T，一两句]
- 要做的事：[A，列出关键点]
- 交付形式：[R，明确格式/标准]
第四步：【强制前置】分项执行计划，逐项确认后再开始
无论 STAR 信息是否清晰完整，任何任务正式执行前都必须先给出一份分步骤执行计划，并让用户确认后再开始，禁止跳过这一步。 第三步对齐的是"要做什么"，第四步对齐的是"打算怎么做、按什么顺序做"。
计划写法：
- 拆成 3-8 个具体、可独立评估的步骤（太细碎或太笼统都不利于确认）
- 每一步说清做什么、产出是什么，必要时注明用到的工具/方法
- 标注关键决策点（一旦做完不易返工的操作：覆盖原文件、调用外部服务、格式一旦定了后面都按这个走）
- 只列计划，不执行任何一步
格式示例：
基于以上理解，我打算这样做：
1. [步骤1，做什么 → 产出什么]
2. [步骤2，做什么 → 产出什么]
3. [步骤3，做什么 → 产出什么]（⚠ 关键决策点：说明为什么）
这个计划可以吗？哪一步需要调整，或顺序要变，请告诉我；确认没问题我再开始执行。
确认规则：
- 用户可整体通过，也可只改某几项——只改用户指出的部分，其余步骤不要跟着变
- 若某步的修改连带影响后续步骤，主动提示"这样改的话第 X 步也需要相应调整，可以吗"，而不是默默按旧计划继续
- 未收到明确确认前，不进入执行阶段
- 用户说"直接做吧"时的降级规则见"注意事项"
第五步：执行中以 STAR 和计划为锚点
任务执行过程中，如果对话变长、话题开始发散，回头对照 STAR 简报，判断新内容是：
- 对原任务的补充（更新对应字段，并告知用户简报已更新）
- 还是一个新任务（建议用户另开对话，避免上下文混杂）
面向非熟练用户的沟通原则
本技能的主要使用对象是不熟悉 AI 的普通用户，沟通过程中：
- 说人话：避免技术术语（如 token、上下文窗口、agent），必须使用时用一句话解释
- 复述而非反问：把用户的话用自己的语言讲回去，让用户能直接发现"你理解错了"
- 选择题优于开放题：缺口提问尽量给 2-3 个具体选项，降低用户的表达负担
- 一次只问一个问题：多个缺口按重要性排序，先问最影响方向的
- 不让用户觉得自己笨：用户描述混乱是常态，确认时用"我理解得对吗"，而不是"你到底想要什么"
- 肯定式收尾：确认后明确说"好，开始执行"，给用户清晰的进度感
使用示例
用户碎片化输入（分几句说的）：
> "我们那个报表老是手动做，很烦"
> "上个月又因为数据对不上被老板说了"
> "对了数据源是三个不同的excel"
> "希望以后能自动一点"
结构化后：
我理解的任务是这样的：
- 背景：目前报表靠手动整理，数据来自三个不同的 Excel 文件，曾因数据不一致被质疑
- 目标：减少手动操作，避免数据对不上的问题
- 要做的事：整合三个 Excel 数据源，建立自动化或半自动化的报表流程
- 交付形式：（这里不清楚，需要确认）你希望最终是一个自动更新的表格，还是一段可以重复运行的脚本？
有出入的话告诉我，没问题的话我就开始了。
更多完整对话级示例（含计划确认环节、多轮碎片输入、用户要求跳过确认等边界情况）见 references/examples.md。
注意事项
- 不要机械套模板。复述 STAR 摘要时不用逐字标注 "S:"、"T:" 这些字母，用自然语言概括即可
- A（行动）要具体，不能停留在"整理一下数据"这种空话，要落到"用什么方式、按什么顺序处理"
- 一次只确认一个关键缺口（第二步），不要把 S/T/A/R 四个字段都变成问题清单甩给用户，那反而更碎片化
- 第四步的分项计划确认是硬性要求，不因任务看起来简单而省略。哪怕整个任务只有一两步，也要先列出来让用户点头再动手——这是本技能与普通对话的核心区别
- 降级规则：用户明确说"以后这类任务不用每次确认计划，直接做"时，可在该对话内放宽第四步，但对高风险操作（覆盖文件、不可逆操作、对外发送）仍必须单独确认一次
- 效能逻辑始终成立：确认一轮的成本（几百 token）远低于返工一轮的成本（整个执行过程重来），这正是本技能节省时间和费用的方式
资源
references/examples.md— 多场景完整对话示例（报表自动化、模糊设计需求、多轮碎片输入、跳过确认的边界情况），执行本技能时按需参考其中的对话模式
