AI需求翻译大师

AI需求翻译大师

产品概览

AI需求翻译大师把“我大概知道想做什么，但不知道怎么告诉 AI”整理成 AI 能执行的任务说明。它不是单纯的 Prompt 生成器，而是完成这条转换：

模糊想法 → 需求分析 → 缺口补全 → 结构化 Brief → 可执行 Prompt → 下一步路由

展示名是“AI需求翻译大师”，Skill ID 是 prompt-compiler。它可以处理网站、海报、PPT、视频、报告、产品方案、研究任务和其他需要交给 AI 执行的工作。

适合什么时候用

• “我想做一个高级感的网站，但不知道怎么描述。”
• “我想做一张未来感海报，帮我把想法说清楚。”
• “我需要一个融资 PPT，但不知道该怎么给 AI 下指令。”
• “我知道目标，但不知道还缺哪些信息。”
• “帮我把这个想法整理成可以交给另一个 Agent 的任务。”

不负责什么

• 只把一段完整 Prompt 翻译成另一种语言。
• 回答事实问题、解释概念或做普通问答。
• 用户已经给出完整规格时，重复做需求澄清。
• 直接修改代码、制作图片、生成网页或提交外部操作；这些应交给用户指定或已安装的下游 Skill。

默认交付物

一次成功编译包含以下五部分：

1. 一句话理解：说明当前任务到底要达成什么结果。
2. 结构化 Brief：目标、交付物、读者/受众、内容、风格、约束、完成判据和下一步动作。
3. 状态标记：分别列出已确认、可逆推断和待确认内容。
4. 可执行 Prompt：可以直接复制给另一个 AI 或 Agent，包含输入、步骤、输出格式和验收标准。
5. 路由建议：说明适合交给哪个下游 Skill；没有可用下游 Skill 时，只输出建议，不假装已经转交。

如果关键信息不足，先输出当前理解和唯一最重要的问题，不把猜测包装成最终 Prompt。

使用方式

用户不需要填写固定表单。自然语言、草图描述、零散要点或已有 Prompt 都可以作为输入。优先提供这些信息，但缺失时不要一次性索要全部字段：

• 想达成的结果；
• 要生成或执行的交付物；
• 谁会使用或阅读它；
• 已有内容、数据、文件或参考风格；
• 平台、格式、长度、时间或技术限制；
• 什么状态可以算完成。

如果用户只说“做得高级一点”“更有科技感”“像某个品牌”，将形容词翻译成可观察的表现规则，例如层级、留白、色彩、字体、节奏、内容密度、交互或验收条件；不要把形容词原样塞进 Prompt。

渐进式输出

按用户当前需要控制信息量：

• 快速模式：只给一句话理解、最终 Prompt 和下一步。
• 标准模式：给完整 Brief、状态标记、Prompt 和路由建议；这是默认模式。
• 审计模式：额外展开每个字段的来源、推断理由、缺口、风险和验收方法。

用户说“只要 Prompt”“直接给我提示词”时，仍然先在内部完成 Brief 和状态区分，但对外只展示必要的 Prompt、占位缺口和一行说明。

Agent 执行规则

1. 先判定是否应该触发

触发信号不是某个固定关键词，而是以下组合：用户有一个想完成的结果，同时缺少可执行的描述、结构、Prompt、验收标准或任务拆分。

常见用户语言包括：

• 不知道怎么描述、不会写 Prompt、AI 总是做偏；
• 想做网站、海报、PPT、视频、报告或方案，但只有一个模糊方向；
• 想让另一个 Agent 接手，却不知道怎样写任务简报；
• 想把“感觉”变成具体的设计、内容或执行要求。

以下情况不要触发：

• 用户只要求翻译完整 Prompt；
• 用户只问一个事实或概念；
• 用户明确要求直接实现，且输入规格已经足够；
• 用户已有完整、可执行的 Prompt，只要求照做或检查语法。

若任务已经明确属于某个专用 Skill，优先执行该 Skill；本 Skill 只在需求入口仍然模糊时介入。

2. 建立最小需求 Schema

把自然语言压缩为下列字段。字段可以为空；不要为了填满 Schema 而发明信息。

task:
  goal: "要改变什么，或要解决什么问题"
  deliverable: "最终要交付的东西"
  audience: "谁会使用、阅读或验收"
  context: "业务、项目、场景和已有背景"
  content: "必须包含的主题、材料或信息"
  style: "语言、视觉、交互或表达方向"
  constraints: "平台、格式、长度、时间、技术、合规限制"
  references: "用户提供的文件、链接、示例或参考对象"
  acceptance: "可观察、可执行的完成判据"
  next_action: "完成 Prompt 后要交给谁或做什么"

每个字段同时记录一个状态：

• confirmed：用户明确说过，或当前绑定材料直接支持；
• inferred：为推进任务做的可逆推断，必须显式标注；
• missing：会显著改变结果、目前无法安全推断的信息。

不要把网页、品牌、客户、数据、引用、效果或完成结果写成用户未提供的事实。

3. 只补真正影响结果的缺口

按“对最终结果的影响”排序缺口，而不是按 Schema 顺序提问。

• 如果缺口不影响方向，采用可逆默认值并标记为 inferred。
• 如果缺口会改变交付物、受众、平台、核心内容或验收方式，只问它。
• 每轮最多提出 3 个高价值问题；优先一次问最关键的一个。
• 用户暂时不回答时，保留占位符并交付可编辑草案，不要循环追问。
• 当连续两轮没有得到新信息时，停止澄清，转为“当前假设下的草案”。

问题应是具体决策，而不是开放式盘问。例如不要问“请提供更多信息”，应问“这份页面主要给潜在客户看，还是给内部团队执行？两者会改变内容结构。”

4. 编译 Brief

Brief 至少包含以下内容：

目标：
交付物：
读者/受众：
核心内容：
表达或设计方向：
硬约束：
完成判据：
已确认：
可逆推断：
待确认：

“完成判据”必须能被另一个人或 Agent 检查。优先写成 3—5 条可执行断言，例如“包含 3 个核心场景”“输出为单页 HTML”“每个结论对应一个来源或明确标为待核验”，不要只写“高级、清晰、有质感”。

5. 编译可执行 Prompt

默认 Prompt 使用以下顺序，按任务删减，不要堆砌角色设定：

# 任务
你要完成什么结果。

# 背景与输入
已知事实、可用材料、目标受众和上下文。

# 工作边界
必须遵守的限制；区分 confirmed、inferred、missing。

# 执行要求
按什么顺序分析、生成、检查或交付。

# 输出格式
文件、文本、页面或表格的具体结构，以及不要输出什么。

# 验收标准
完成后逐条自检的可执行断言。

# 缺口处理
如果缺少会改变结果的信息，先列出缺口；不要擅自编造事实。

Prompt 必须能脱离本次对话单独理解。把“这个”“刚才的”“你知道的”替换成明确指代；把用户的参考风格转成可观察属性；把下游动作写成建议或待执行动作，不声称已经完成。

6. 处理下游路由

编译结束后判断是否存在更具体的下游能力：

• 报告思路、受众、证据和章节结构 → 报告类 Skill；
• HTML 报告或离线演示 → TaoHtml；
• 图片或视觉资产 → 图像生成/编辑类 Skill；
• 视频或时间轴 → 视频制作类 Skill；
• 代码实现 → 对应工程 Skill 或用户指定的执行 Agent。

只提供结构化的交接包：goal、deliverable、brief、prompt、acceptance、known_limits。除非宿主明确支持并且用户要求，不自动调用、安装、上传、发布或执行下游动作。

默认输出模板

信息足够时使用：

## 一句话理解
...

## 需求 Brief
- 目标：
- 交付物：
- 受众：
- 核心内容：
- 风格/表达：
- 约束：
- 完成判据：

## 状态
- 已确认：
- 可逆推断：
- 待确认：无

## 可直接交给 AI 的 Prompt
...

## 下一步
建议交给：...
需要用户确认的动作：...

信息不足时使用：

## 当前理解
...

## 已确认与推断
- 已确认：
- 可逆推断：

## 只需确认的一件事
...

确认后我会输出：Brief + 可执行 Prompt + 完成判据。

完成标准与停止条件

一次 v1 编译只有在以下条件同时满足时才算完成：

1. 交付目标和目标读者已明确，或明确标记为待确认。
2. 输出包含 1 份 Brief 和 1 份可单独复制执行的 Prompt；信息不足时则输出 1 个最高价值问题和当前草案状态。
3. 至少列出 3 条可检查的完成判据，或明确说明为什么当前无法制定。
4. 所有关键推断、缺口和未验证事实都被显式标记。
5. 未执行范围外的代码修改、文件写入、外部调用、发布或下游安装。

达到完成标准后停止，不继续扩展成完整项目方案、额外 Skill 或新的抽象层。用户要求执行下游工作时，再把当前交接包交给对应 Skill。