Idea to Prompt

想法 → 结构化提示词

这个 skill 的作用：接收用户杂乱、语序不清、可能重复或者自相矛盾的原始想法，先判断信息够不够，不够就精准地问，够了就直接产出一份结构清晰、AI（或者人）能直接照着执行的提示词。

核心原则：宁可多问一句关键的，不要瞎猜着往下做；但也不要为了"显得谨慎"而每次都问一堆无关痛痒的问题。

第一步：先判断这是什么类型的想法

读完用户的原始输入，先判断属于哪一类，因为不同类型输出的结构不一样：

• A. 开发/代码任务：想改项目里的某个功能、修复某个问题、加个东西
• B. 内容创作任务：想写脚本、文案、产品描述之类
• C. 决策/规划类：想理清楚一个决定该怎么做、一件事该怎么规划
• D. 其他：不属于以上几类的通用请求

判断依据主要看用户提到的关键词和上下文（比如提到文件名、项目名、功能模块，大概率是 A；提到平台、受众、风格，大概率是 B）。

第二步：拆解原始输入，检查这几件事

不管属于哪一类，都按这个清单过一遍：

1. 核心目标是什么——用户到底想要什么结果，能不能用一句话说清楚
2. 有没有把多件事混在一起说——如果原始输入里其实包含了两三个不同的诉求揉在一起，要在输出里明确拆开，并且告诉用户"你这里其实说的是两件事，我拆开处理了"
3. 有没有自相矛盾的地方——比如前面说"要简洁"后面又列了一堆细节要求
4. 有没有隐含但没说出口的假设——用户可能觉得"这不是显而易见的吗"但其实没写出来
5. 范围边界在哪——尤其是开发任务，"只改这一个地方"还是"顺带把相关的也理一理"，这个不确定的话很容易做超出预期的范围

第三步：决定要不要先问

只有当模糊点会导致输出方向根本性跑偏时才问，不要为了显得严谨而每次都问。

需要问的典型情况：

• 目标本身有两种完全不同的理解方式（比如"优化一下"可能是"改样式"也可能是"改性能"）
• 缺了一个关键约束，一旦猜错会导致做的东西用不上（比如开发任务不知道该改哪个文件/哪个环境）
• 用户自己在原始输入里表现出不确定（比如"我也不知道该叫什么"、"具体细节我还没想好"）

问的时候：

• 控制在 1-3 个问题以内，别一次甩一堆
• 能用选择题就不用开放式问题，比如"你是想要 A（偏技术细节）还是 B（偏结果导向）"，比"你具体想要什么"更容易回答
• 问完之后再产出最终提示词，不要一边问一边先写一半

不需要问的情况：直接在最终产出的提示词里，用一行**"假设说明"**列出你做了哪些合理假设，让用户一眼看到、方便他快速纠正，而不需要打断流程。

第四步：按类型产出结构化提示词

类型 A（开发任务）——参考项目已有的 pm-requirement-to-code-sop 三分类逻辑：

【目标】一句话说清楚要做什么

【涉及范围】具体文件/模块（不确定的话让 Claude Code 先只读定位，
不要自己瞎猜路径）

【风险分类】
- 如果是纯UI/文案调整 → 标注"可直接改"
- 如果涉及计算逻辑/金额/权限 → 标注"需要先排查影响面，不要直接改"
- 如果范围本身不确定 → 标注"需要先确认范围"

【约束】明确哪些不要动（比如"不要碰XX逻辑"）

【假设说明】（如果没有先问用户，这里列出做了什么假设）

类型 B（内容创作）：

【目标】做什么内容，给谁看

【风格/语气】参考什么调性

【必须包含】哪些要点/信息不能漏

【避免】不希望出现的内容/表达方式

【格式】长度、平台、结构要求

【假设说明】

类型 C（决策/规划）：

【要决定的事情】

【已知的约束条件】

【用户目前的倾向/顾虑】（如果原始输入里透露了）

【希望AI提供什么】是给选项对比，还是直接建议，还是帮忙拆解步骤

【假设说明】

类型 D：按类型 B 的结构简化处理，去掉不适用的字段。

输出之后

产出结构化提示词后，直接问用户一句"这份提示词准确吗，需要调整就告诉我"，不要自动接着往下执行——这个 skill 的职责到"产出清晰的提示词"为止，除非用户明确说"直接照这个做"。

一个重要的边界

如果识别出这是类型 A 且信息完整、无歧义，可以直接建议用户"这个可以直接执行了，要不要我现在就做"，不需要多此一举地先输出一份提示词再让用户复制粘贴一遍——避免为了走流程而走流程，本末倒置。