Simon-zj1 optimize-prompt
用户不一定知道怎么写好的提示词，但对同一个问题，好提示词能得到明显更好的回答。本 skill 让 AI 在回答前先做一次"提示词优化"——用 AI 自己认为最能激发高质量回答的方式重述用户的问题，把改写版本展示给用户，然后基于改写版回答。
何时使用
主动使用（用户的问题符合以下情况时）：
- 问题较开放、目标不明确（"帮我看看这个"、"这怎么办"、"帮我写个 X"）
- 问题涉及多个可能的解读方向
- 问题涉及非平凡任务：写作、分析、调试、方案设计、学习解释、创意创作、决策比较
- 问题里省略了明显重要的信息（目标读者、语气、长度、语言、预算、约束等）
用户明确触发时：
- "帮我优化提示词 / 用优化的方式回答 / 帮我把这个问得更好"
- 使用
/optimize-prompt或调用本 skill 名
不要使用（会增加噪音）：
- 简单事实性问答（"2+2=?"、"Python 里怎么把字符串转小写？"）
- 简短闲聊、打招呼
- 已经非常具体、约束齐全的问题（用户已经写好了详细提示词）
- 连续多轮对话时，第一轮已优化过、后续在同一话题下推进——不要每轮都重复优化
输出格式
> **优化后的提示词**
> [改写后的完整提示词——包含明确目标、必要背景、输出格式、约束条件]
>
> *（如做了非平凡假设：已假设 xxx，如不对请告诉我）*
---
[基于改写版的实际回答]
改写版长度：一般 2–6 句为宜。不是越长越好——目标是让 AI 精准命中，不是塞满关键词。
优化流程
1. 理解原始意图
- 用户最想解决什么问题（不是字面问题，是背后的目标）
- 判断问题类型：写作 / 代码调试 / 分析决策 / 学习解释 / 方案设计 / 创意 / 其他
2. 识别缺失维度
针对识别出的问题类型，检查关键维度是否缺失（见下方"各类型关键维度清单"）。
3. 改写提示词
- 能从上下文合理推断的维度直接补上（用户角色、项目背景、之前对话内容都是线索——特别是 memory 里已经记录的用户偏好和项目上下文）
- 无法推断但对结果影响很大的关键点，用"假设 xxx，如不对请告知"标注
- 明确目标和成功标准
- 指定输出结构和格式
- 必要时加"分步推理"、"考虑对立视角"、"给出验证方式"这类指令
4. 展示改写版本（关键步骤，不要跳过）
用引用块 > 展示改写后的提示词。这样做的价值：
- 用户能验证方向是否正确（如果 AI 猜错了意图，早发现比整篇跑偏后再改代价小）
- 用户逐渐学到"好的提示词长什么样"
- 若假设不成立，用户能立刻指出
5. 基于改写版回答
- 遵循改写版里的所有约束和格式
- 别机械按模板输出——改写版是自我指引，答案才是重点
各类型问题的关键维度
写作类（文章、邮件、报告、文档）
- 目标读者、语气（正式/口语/技术）、长度、结构、示例风格、必须包含 / 避免的点
代码 / 调试类
- 语言 + 版本、运行环境、已尝试方案、错误信息完整版、期望行为 vs 实际行为、约束（不能改哪些文件、性能要求）
分析 / 决策类
- 决策标准、可选方案、权重、时间预算、风险容忍度、对比基线
学习 / 解释类
- 用户当前知识水平、学习目的（应付考试 / 深入理解 / 实操）、比喻偏好、深度期望
方案设计类
- 硬约束（预算、时间、技术栈）、软偏好、成功指标、失败情形、迭代节奏
创意类
- 风格参考、受众情绪目标、长度、必须元素、禁止元素、变体数量
撰写守则
- 不要问回用户：优化的意义就是替用户想清楚。除非缺失的维度真的无法从上下文合理假设（比如需要知道具体报错信息才能诊断代码），否则直接补上并标"假设"
- 假设要合理：从对话历史、memory 里的项目背景与角色偏好里推断，不要瞎猜
- 不要过度设计：一个 20 字的问题不需要改成 200 字的提示词。改写的复杂度应与问题复杂度成比例
- 保留用户原意：改写是澄清和补全，不是替换用户想问的问题。如果改写偏离了用户明显的意图，说明你猜错了
- 展示改写版本：不能偷偷优化不给用户看——用户学不到东西，也无法在你猜错时纠正
示例
示例 1：开放写作请求
用户原始：帮我写个关于 AI 的文章
优化并回答：
优化后的提示词 请写一篇约 800 字的中文文章，主题是"AI 在 2026 年对普通开发者日常工作的实际影响"。目标读者是有 1–3 年经验的软件工程师，语气偏理性、有具体例子（工具名、场景、代码），避免"AI 会改变一切"式的空泛表达。结构：引子 + 3 个具体影响 + 一个务实的结论。
（已假设主题聚焦到"对开发者的影响"、约 800 字；若需其他角度或长度请告诉我）
（此处开始写文章正文）
示例 2：调试问题但信息不足
用户原始：我这个代码为什么跑不起来
优化后（此时"优化"的结论是要用户补信息，而不是硬编）：
优化后的提示词 帮我诊断代码报错。分析报错信息里最可能的根因（不要一上来列 10 个可能性），说明为什么这么改 + 给出最小改动方案 + 一句话的验证方式。
需要补充：完整报错信息、语言/版本、相关代码片段。请贴上来，否则只能凭猜测
（此时不硬回答，而是引导用户提供信息）
示例 3：不需要优化
用户原始：Python 里 datetime.now() 返回什么类型？
→ 直接答：datetime.datetime 对象。不做优化。
示例 4：项目上下文里的问题（从 memory 推断）
用户原始：帮我看下这个报错（memory 里已有 [[fw-mid-pro-bridge-project]] 项目背景）
优化并回答：
优化后的提示词 基于当前 FW-mid-pro ROS1↔ROS2 桥接项目（Docker 方案）的上下文，诊断刚贴出的报错。请先判断报错发生在桥接层还是原生节点，给出最可能的一个根因（不要罗列多种可能）+ 具体修复动作 + 验证命令。
（已假设报错和桥接相关，如果是别的模块请告诉我）
（然后基于用户实际贴出的报错做诊断）
与其他 skill 的关系
- 用户想"复盘调试全过程"→ 该用
debug-journey-recap，不是本 skill - 用户想"刷新长对话上下文"→ 该用
refresh-debug-context，不是本 skill - 用户明确说"不要优化直接答"→ 立即停用本 skill，本轮及之后按用户直接问的回答