ce:ideate

生成改进创意

注意：当前年份是 2026 年。 为构思文档标注日期以及检查近期构思成果时，请以此为准。

ce:ideate 先于 ce:brainstorm。

• ce:ideate 回答：“哪些创意最值得探索？”
• ce:brainstorm 回答：“选定的某个创意具体意味着什么？”
• ce:plan 回答：“应该如何构建？”

此工作流会在 docs/ideation/ 中生成一份按优先级排序的构思文档。它不会生成需求、计划或代码。

交互方式

如有可用的平台阻塞式提问工具，请使用它（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）。否则，请在聊天中列出编号选项，并等待用户回复后再继续。

每次只问一个问题。存在自然选项时，优先使用简洁的单选项。

重点提示

<focus_hint> #$ARGUMENTS </focus_hint>

将提供的任何参数视为可选上下文。它可以是：

• 一个概念，例如 DX improvements
• 一个路径，例如 plugins/compound-engineering/skills/
• 一个约束，例如 low-complexity quick wins
• 一个数量提示，例如 top 3、100 ideas 或 raise the bar

如果没有提供参数，请进行开放式构思。

核心原则

1. 先基于实际情况，再进行构思——先扫描实际代码库。不要生成脱离仓库实际情况的抽象产品建议。
2. 大量生成 -> 全面批判 -> 只解释保留项——质量保障机制是明确说明淘汰理由，而非乐观排序。不要让额外流程掩盖这一模式。
3. 将后续行动引导至头脑风暴——构思用于识别有前景的方向；ce:brainstorm 会将选中的方向明确到足以制定计划的程度。不要直接从构思结果跳到规划。

执行流程

阶段 0：恢复与确定范围

0.1 检查近期构思成果

在 docs/ideation/ 中查找过去 30 天内创建的构思文档。

符合以下任一条件时，将先前的构思文档视为相关：

• 主题与请求的重点相符
• 路径或子系统与请求的重点重叠
• 请求为开放式，且存在明显相关的近期开放式构思文档
• 问题关联状态相符：如果当前参数表明用户有问题跟踪器方面的意图，就不要提出恢复非问题相关的构思，反之亦然——将二者视为不同主题

如果存在相关文档，询问用户是要：

1. 接续已有内容
2. 重新开始

如果选择接续：

• 阅读该文档
• 总结已探索的内容
• 保留已有创意的状态
• 更新现有文件，而不是创建重复文件

0.2 确定主题模式

判定构思的主题（用户想围绕什么进行构思），而非所处环境。用户可以在任意仓库中构思与该仓库无关的内容；也可以在 /tmp 中构思自己脑海中的代码。

依次进行两个二元判断，并在每一步列出反向信号：

判断 1——基于仓库 vs. 其他主题。 优先考虑提示内容，其次考虑主题与仓库的关联性；当前工作目录中是否存在仓库仅作为辅助证据。

• 基于仓库的正向信号：提示提到了仓库文件、代码、架构、模块、测试或工作流；主题明确受当前代码库范围所限。
• 负向信号（倾向于其他主题）：提示提到了仓库中不存在的内容（定价、命名、叙事、商业模式、个人决策、品牌、内容、市场定位）；主题属于创意、商业或个人领域，且没有代码层面的关联。 决策 2（仅当决策 1 = 仓库之外时触发）——软件还是非软件。 根据构思的主题是否为软件制品或系统来分类，而不是根据各个创意最终会应用到哪里。如果主题涉及产品、应用、SaaS、Web / 移动端 UI、功能、页面或服务，则属于仓库之外的软件主题——即使创意本身涉及的是该软件产品的文案、UX、CRO、定价、引导流程、视觉设计或定位。仓库之外的非软件主题仅适用于完全没有软件载体的主题：公司或品牌命名（独立于产品）、叙事和创意写作、个人决策、非数字化商业战略、实体产品设计。

分类示例：

• “提高注册页面的转化率” → 仓库之外的软件主题（主题是一个页面）
• “重新设计引导流程” → 仓库之外的软件主题（主题是一个流程）
• “定价页面的 A/B 测试创意” → 仓库之外的软件主题（主题是一个页面）
• “为我们的笔记应用添加哪些功能” → 仓库之外的软件主题
• “给我的新咖啡店起名” → 仓库之外的非软件主题（主题是一个品牌）
• “短篇故事的情节创意” → 仓库之外的非软件主题（主题是一个叙事）
• “我下一步职业发展的选择” → 仓库之外的非软件主题（主题是个人决策）

在开头用一句用户能理解的通俗语言说明推断出的处理方式。绝不要向用户显示内部分类标签（repo-grounded、elsewhere-software、elsewhere-non-software）——这些名称仅用于路由。根据实际主题调整以下模板；从主题本身选用领域词语（例如“落地页”“引导流程”“命名”“职业决策”），不要使用模式标签。

• 基于仓库：“我会把它视为此代码库中的主题，具体是关于 X。说‘其实这不属于此仓库’即可切换。”
• 仓库之外的软件主题：“我会把它视为此仓库之外的产品 / 软件主题，具体是关于 X。说‘其实这是关于此仓库的’或‘其实这完全不涉及软件’即可切换。”
• 仓库之外的非软件主题：“我会把它视为[命名｜叙事｜商业｜个人]主题，具体是关于 X。说‘其实这是关于软件产品的’或‘其实这是关于此仓库的’即可切换。”

更正提示也必须使用通俗语言（“其实这不属于此仓库”“其实这是关于此仓库的”），不得使用内部标签（“其实是仓库之外的软件主题”）。

对模糊情况主动确认（V16）。 当分类器置信度较低时——例如只有一个关键词或提示简短、且能明确对应任一模式（/ce:ideate ideas、/ce:ideate ideas for the docs），当前工作目录与提示信号冲突，或主题同时提到仓库内部和外部内容——请在分派第 1 阶段的背景信息梳理之前，通过平台的阻塞式提问工具提出一个确认问题（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）。对于明确的情况，只需用一句话说明推断出的模式；不要提问。

示例措辞（根据当前提示调整；遵循插件 AGENTS.md 中的交互式提问工具设计规则——选项标签需自成一体，最多 4 个，使用第三人称，将区分性词语放在前面，不得泄露内部模式名称）：

• 问题：“你希望 Agent 构思什么主题？”
• 选项：
  • “此代码库中的代码——功能、重构、架构”
  • “此代码库之外的主题——商业、设计、内容、个人决策”
  • “取消——让我重新表述提示”

如果用户确认或选择“其他主题”，仍要运行决策 2，在仓库之外的软件主题和非软件主题之间进行选择。 路由规则。 当 Decision 2 = 非软件时，仍要运行 Phase 1 的 Elsewhere 模式信息梳理（综合用户上下文 + 默认进行网络研究；遵循跳过短语）。此模式下默认跳过 learnings-researcher——当前工作目录的 docs/solutions/ 内容很少能迁移到命名、叙事、个人或非数字化业务主题；完整原因见 Phase 1。然后加载 references/universal-ideation.md，并用它替代 Phase 2 的软件框架分派和 Phase 6 的菜单叙述。此文件必须加载——其中包含跨领域的生成框架、评审标准和收尾菜单，用于替代此模式下的 Phase 2 和构思后的菜单；这些细节在本文主体中都没有。凭记忆临场发挥会导致非软件主题的引导方式错误。任何时候都不要运行特定于代码仓库的代码库扫描。references/post-ideation-workflow.md 中的 §6.5 Proof Failure Ladder 仍然适用——每当 Proof 保存失败（Elsewhere 模式下 Save and end 的默认操作）时，都要加载并遵循该流程，以确保非软件 Elsewhere 运行中本地保存回退路径仍可用。

如果任何扩展提示范围的步骤或接收信息步骤（下文 0.4）实质性地改变了主题，应在分派 Phase 1 前重新评估模式声明——根据要处理的范围分类，而非首次阅读时的范围。

0.3 解读焦点和数量

从参数中推断三项内容：

• 焦点上下文 - 概念、路径、约束或开放式
• 数量调整 - 任何会改变候选项或保留项数量的提示
• 问题追踪器意图 - 用户是否希望将问题/缺陷数据作为输入来源。仅限 Repo 模式——在 Elsewhere 模式下不要触发。

当参数的主要意图是分析问题模式时，触发问题追踪器意图：bugs、github issues、open issues、issue patterns、what users are reporting、bug reports、issue themes。

不要因参数仅将缺陷作为焦点提及而触发：bug in auth、fix the login issue、the signup bug——这些是焦点提示，而非分析问题追踪器的请求。

组合出现时（例如，top 3 bugs in authentication）：先检测问题追踪器意图，再检测数量调整，其余部分作为焦点提示。焦点用于缩小相关问题的范围；数量调整用于控制保留项数量。

默认数量：

• 每个构思子 Agent 生成约 6-8 个创意（默认路径下 6 个框架共生成约 36-48 个原始创意；问题追踪器模式下 4 个框架共生成约 24-32 个；6 框架路径去重后约保留 25-30 个，4 框架路径则更少）
• 保留排名最高的 5-7 个

遵循明确的调整提示，例如：

• top 3
• 100 ideas
• go deep
• raise the bar

合理解读即可，无需进行形式化解析。

0.4 轻量上下文收集（仅限 Elsewhere 模式下的软件主题）

在 Repo 模式下跳过此步骤（Phase 1 的信息梳理 Agent 会完成此工作）；在非软件的 Elsewhere 模式下也跳过（通用引导参考文件规定了信息收集方式）。

提问前先应用区分测试：如果将用户所述上下文中的一项替换为相反选项，会实质性改变最终保留哪些创意吗？如果会，该上下文就是关键条件——无需提问。如果不会，则提出 1-3 个范围明确的问题，基于用户已提供的信息继续追问，而非套用模板。默认使用开放式问题；仅在答案范围较小且明确时才使用单选（例如，类型、语气）。每次收到回答后，再次应用测试，然后再决定是否继续提问。遇到敷衍的回答（“不知道，就这样吧”）时停止；将真正的“没有限制”视为有效回答。

如果用户一开始就提供了丰富的上下文（一段粘贴内容、简报或现有草稿），用一句话确认理解，然后完全跳过信息收集。

0.5 成本透明度说明

在调度 Phase 1 之前，用一行简短说明展示推断模式下的 Agent 数量，避免多 Agent 成本被忽略。根据实际调度决策计算数量：1 个上下文梳理 Agent（仓库模式下扫描代码库；其他模式下综合用户上下文）+ 1 个经验总结（其他非软件模式下跳过）+ 1 个网络研究 Agent + 6 个创意构思 Agent = 仓库模式和其他软件模式下基准数量为 9，其他非软件模式下为 8。触发 Issue 跟踪器意图时（仅限仓库模式）：增加 1 个 Issue 情报 Agent，并将创意构思 Agent 从 6 个减少到 4 个，净减 1 个（基准数量为 8）。如果用户选择了 Slack 研究，则增加 1 个。如果用户使用了跳过网络研究的短语，或将触发 V15 复用，则减少 1 个。

示例（默认情况，无跳过项、无选择加入项）：

• 仓库模式：“将调度约 9 个 Agent：代码库扫描 + 经验总结 + 网络研究 + 6 个创意构思子 Agent。跳过短语：‘no external research’、‘no slack’。”
• 仓库模式，含 Issue 跟踪器意图：“将调度约 8 个 Agent：代码库扫描 + 经验总结 + 网络研究 + Issue 情报 + 4 个创意构思子 Agent。跳过短语：‘no external research’、‘no slack’。”这反映了成功主题路径；如果 Issue 情报返回的信号不足（参见 Phase 1），创意构思将回退到 6 个子 Agent，总数变为约 9 个。
• 其他软件模式：“将调度约 9 个 Agent：上下文综合 + 经验总结 + 网络研究 + 6 个创意构思子 Agent。跳过短语：‘no external research’。”
• 其他非软件模式：“将调度约 8 个 Agent：上下文综合 + 网络研究 + 6 个创意构思子 Agent。跳过短语：‘no external research’。”

这一行仅供参考；用户无需确认。

Phase 1：根据模式梳理上下文

生成创意之前，先收集背景信息。调度集合取决于 Phase 0.2 中选择的模式。所有模式都会进行网络研究（遵循跳过短语）。仓库模式和其他软件模式会进行经验总结，其他非软件模式默认跳过——CWD 仓库中的 docs/solutions/ 几乎总是包含工程模式，这些模式无法迁移到命名、叙事、个人或非数字化商业主题。

在 Phase 1 开始时生成一次 <run-id>（8 位十六进制字符）。在 V15 缓存文件（本阶段）和 V17 检查点（Phase 2 和 4）中复用此 ID，使它们共用同一个按运行划分的临时目录。

预先解析临时目录路径。 根据仓库临时空间规范中的跨调用可复用规则，临时文件应放在 OS 临时目录中（而非 .context/）——创意构思主题很少与 CWD 仓库相关（尤其是在其他模式下），因此默认不将临时文件放在任何仓库目录树中才是正确做法。运行一条 bash 命令来创建目录，并获取其供后续所有步骤使用的绝对路径。不要将 ${TMPDIR:-/tmp} 作为字面字符串传给非 shell 工具（Write、Read、Glob）；这些工具不会执行 shell 展开。

SCRATCH_DIR="${TMPDIR:-/tmp}/compound-engineering/ce-ideate/<run-id>"
mkdir -p "$SCRATCH_DIR"
echo "$SCRATCH_DIR"

在本次运行的所有后续检查点写入和缓存读取中，使用回显的绝对路径（例如，macOS 上的 /var/folders/.../T/compound-engineering/ce-ideate/a3f7c2e1，Linux 上的 /tmp/compound-engineering/ce-ideate/a3f7c2e1）作为 <scratch-dir>。Phase 6 完成后不会删除运行目录——V15 缓存的作用域是会话，并会在不同 run-id 之间复用；检查点遵循跨调用可复用规范，会保留会话作用域的产物，供后续调用查找。

在前台并行运行上下文梳理 Agent（不要放到后台——Phase 2 开始前需要这些结果）：

仓库模式调度：

1. 快速上下文扫描——使用平台上能力足够且成本最低的模型（例如 Claude Code 中的 model: "haiku"），调度一个通用子 Agent，并向其提供以下提示词：

   阅读项目的 AGENTS.md（仅在兼容性回退时才读取 CLAUDE.md；如果两者都不存在，则读取 README.md），然后使用原生文件搜索／glob 工具（例如，在 Claude Code 中使用模式 * 或 */* 的 Glob）了解顶层目录布局。返回一份简明摘要（少于 30 行），涵盖：

   • 项目概况（语言、框架、顶层目录布局）
   • 值得注意的模式或惯例
   • 明显的痛点或不足
   • 可能带来改进的着力点

   保持浅层扫描——只阅读顶层文档并查看目录结构。不要分析 GitHub 问题、模板或贡献指南。不要深入搜索代码。

   重点提示：{focus_hint}

2. 经验检索 — 派发 compound-engineering:research:learnings-researcher，并附上简短的构想重点摘要。

3. 网络研究（始终启用；跳过短语和 V15 缓存处理方式见下方“网络研究”小节）。

4. 问题情报（有条件启用）— 如果在阶段 0.3 检测到问题跟踪器相关意图，则派发 compound-engineering:research:issue-intelligence-analyst，并附上重点提示。与其他 Agent 并行运行。

   如果该 Agent 返回错误（未安装 gh、没有远程仓库或身份验证失败），向用户记录警告（“问题分析不可用：{reason}。将继续进行标准构想。”），并继续其余的资料收集。

   如果该 Agent 报告的问题总数少于 5，则注明“问题信号不足，无法进行主题分析”，并在阶段 2 使用默认构想框架。

Elsewhere 模式派发（跳过代码库扫描；以用户提供的上下文为主要依据）：

1. 用户上下文综合 — 派发一个通用子 Agent（使用能力足够且成本最低的模型），读取阶段 0.4 收集的用户上下文以及任何丰富提示材料，并返回结构化的依据摘要，其结构应与代码库上下文一致（项目概况 → 主题概况；值得注意的模式 → 已说明的限制；痛点 → 用户指出的痛点；着力点 → 上下文暗示的机会切入点）。这样可让阶段 2 的子 Agent 不必关心依据的来源。

2. 经验检索 （仅限 elsewhere-software；默认在 elsewhere-non-software 中跳过） — 派发 compound-engineering:research:learnings-researcher，并附上主题摘要，以查找可能相关的内部经验（技能设计模式、类似问题的既有解决方案）。elsewhere-non-software 中跳过：CWD 的 docs/solutions/ 不太可能与非数字主题相关，运行此检索还可能让无关的工程模式干扰生成结果。

3. 网络研究 — 与 repo 模式相同（见下方小节）。

Elsewhere 模式不适用问题情报。两种模式下，Slack 研究均为可选项（见下方“Slack 上下文”）。

网络研究（V5、V15）

两种模式下均始终启用。如果用户在提示或之前的回答中说了“no external research”、“skip web research”或含义相同的话，则跳过；此时不要派发 compound-engineering:research:web-researcher，并在汇总依据摘要中注明已跳过。

通过旁路缓存，在同一会话中复用先前的网络研究 — 有关缓存文件结构、复用检查、追加行为和平台降级规则，请参阅 references/web-research-cache.md。本次运行中首次准备派发 compound-engineering:research:web-researcher 时阅读该文件；之后每次派发时，只要缓存可能适用，也要再次阅读。

派发 compound-engineering:research:web-researcher 时，提供：重点提示、简短的规划上下文摘要（一到两句话）以及模式。不要提供代码库内容 — 该 Agent 在外部开展研究。

综合背景摘要

使用以下部分将所有已分发的结果整合为简短的背景摘要（省略没有内容的部分）：

• 代码库背景 （repo 模式） 或 主题背景 （其他模式） — 项目／主题概况、显著模式或已说明的限制、痛点、可利用的优势
• 过往经验 — docs/solutions/ 中相关的组织经验
• 问题单情报 （存在时，仅限 repo 模式） — 按主题总结，包含标题、描述、问题单数量和趋势方向
• 外部背景 （运行了网络研究时） — 先前成果、相关解决方案、市场信号、跨领域类比。如果触发了 V15 复用，请注明“（从先前调度复用）”
• Slack 背景 （存在时） — 组织背景

失败处理。 背景信息收集 Agent 失败时，遵循“发出警告并继续”原则——切勿因此中止。如果 compound-engineering:research:web-researcher 失败（网络、工具不可用），记录警告（“外部研究不可用：{原因}。仅使用内部背景继续。”），然后继续。如果其他模式的输入未能产生可用背景，请在背景摘要中说明背景信息有限，以便 Phase 2 子 Agent 通过更广泛的构思来弥补。

Slack 背景（可选，两种模式均适用）——绝不自动调度。当用户要求提供 Slack 背景，且 Slack 工具可用时（检查当前环境中是否存在任何 slack-researcher Agent 或 slack MCP 工具），请并行调度 compound-engineering:research:slack-researcher，并附上关注提示，与其他 Phase 1 Agent 一起执行。若工具可用但用户未提出要求，请在背景摘要中说明该功能可用，以便用户选择启用。若用户提出了要求但无法访问 Slack 工具，请提供安装提示。

Phase 2：发散构思

在评议任何想法之前，先生成完整的候选列表。

使用继承的模型并行调度构思子 Agent（不要降级——创意构思需要编排 Agent 的推理水平）。省略 mode 参数，以应用用户配置的权限设置。调度数量根据模式决定：仅当 Phase 0.3 检测到问题跟踪器意图，且问题单情报 Agent 返回了可用主题时，才调度 4 个子 Agent（参见下方覆盖规则——从主题簇导出的构思框架最多为 4 个）；其他情况均调度 6 个子 Agent，包括 Phase 1 中触发了意图但未返回主题的“问题信号不足”回退路径。每个 Agent 的目标约为 6–8 个想法（6 个框架可产生约 36–48 个原始想法，4 个框架可产生约 24–32 个原始想法；去重后，6 框架路径约保留 25–30 个，4 框架路径则更少）。当应用数量覆盖规则时，调整每个 Agent 的目标数量（例如，“100 个想法”会提高目标数量；“前 3 个”可能只会减少最终保留的数量）。

向每个子 Agent 提供：背景摘要、关注提示、每个 Agent 的目标数量，以及仅生成原始候选项（不进行评议）的指示。每个 Agent 最初提出的几个想法往往显而易见——要推动它们继续深入。每个想法都必须以 Phase 1 的背景摘要为依据。

为每个子 Agent 分配不同的构思框架，将其作为初始倾向，而非限制。要求每个 Agent 从分配的视角出发，但可顺着任何有前景的方向继续探索——跨越多个框架的综合性想法很有价值。

框架选择（两种模式对称——repo 模式和其他模式使用相同的六个框架）：

1. 痛点与阻力 — 用户、运营人员或主题层面的痛点；哪些事情总是缓慢、出错或令人烦恼。
2. 反转、移除或自动化 — 反转某个令人痛苦的步骤、彻底移除它，或将其自动化。
3. 打破假设并重新构建 — 哪些被视为固定不变的事项其实是一种选择；向上或横向提升一个层级重新构建。
4. 杠杆效应与复利 — 一旦做出，就能让许多未来举措成本更低或效果更强的选择；二阶效应。
5. 跨领域类比 — 思考结构相似的问题在完全不同的领域中是如何解决的，以此产生创意。基础领域是用户的主题；类比领域可以是其他行业、生物学、游戏、基础设施或历史。不要止步于显而易见的类比，继续挖掘不明显的类比。
6. 翻转约束 — 将显而易见的约束反转到相反方向或极端。预算是现在的 10 倍或为 0 会怎样？团队有 100 人或 1 人会怎样？没有用户或有 100 万用户会怎样？即使这种约束翻转本身并不现实，也要将由此得出的设计作为候选方案。

问题跟踪器模式覆盖规则（仅限仓库模式）。 当问题跟踪器意图处于启用状态，且问题智能 Agent 返回了主题时：每个高／中置信度主题都成为一个构思框架。如果由聚类得出的框架少于 3 个，则按上述顺序从默认的 6 个框架池中补足。总数上限为 4 个 — 问题跟踪器模式有意采用更精简的调度。

要求每个子 Agent 针对每个创意返回一份精简结构：标题、摘要、重要性、证据／依据线索，以及可选的大胆程度或焦点契合度信号。

所有子 Agent 返回结果后：

1. 合并并去重，形成一份主候选列表。
2. 综合跨框架的组合 — 找出来自不同框架的创意，看看能否组合成更强的方案（最多预期增加 3–5 个）。
3. 如果提供了焦点，则让合并后的列表更偏向该焦点，但不要排除更强的相邻创意。
4. 在合理时，将创意分布到多个维度：工作流／开发体验、可靠性、可扩展性、缺失能力、文档／知识复利、质量／维护、对未来工作的杠杆效应。

检查点 A（V17）。 跨领域综合步骤完成且原始候选列表整合后，立即使用第 1 阶段记录的绝对路径，将完整候选列表（附带子 Agent 归属信息）写入 <scratch-dir>/raw-candidates.md。此举可在第 3 阶段的批评环节可能压缩上下文之前，保护最耗费资源的产出（6 个并行子 Agent 调度 + 去重）。尽力而为：如果写入失败（磁盘已满、权限不足），记录警告并继续；此检查点并非关键依赖。运行结束时不要清理此文件（保留运行目录，以便同一会话中的不同运行 ID 可以继续使用 V15 缓存 — 参见第 6 阶段）。

合并并综合后、展示筛选结果前，加载 references/post-ideation-workflow.md。此步骤不可省略。该文件包含对抗式筛选标准、产物模板、质量门槛，以及第 6 阶段交接菜单的标准版本（Refine、Open and iterate in Proof、Brainstorm、Save and end）— 这些选项在本文其他部分均未出现。跳过加载会悄然降低后续每一步的质量；Agent 会凭记忆临时编造菜单，而不是展示文档中规定的选项。“快速”意味着减少第 2 阶段的子 Agent 数量，而不是跳过参考资料。第 2 阶段的 Agent 调度完成前，不要加载此文件。