AI Skills
ce-ideate

ce-ideate

热门

生成并评估切合实际的创意点子。当用户想要获取点子、改进方案、让人眼前一亮的备选项或 AI 生成的发展方向，并在确定具体开发方向前进行筛选时使用；若用户已有明确想法需要进一步细化，请使用 ce-brainstorm。

2.4万Star
1881Fork
更新于 2026/7/31
获取 Skill源代码

相关 Skills

blucli38万recsys-pipeline-architect24万academy-guide17万
SKILL.md
只读
名称
ce-ideate
描述

生成并评估切合实际的创意点子。当用户想要获取点子、改进方案、让人眼前一亮的备选项或 AI 生成的发展方向，并在确定具体开发方向前进行筛选时使用；若用户已有明确想法需要进一步细化，请使用 ce-brainstorm。

生成改进构想

注意：当前年份为 2026 年。 在标注构想文档日期和检查近期构想产物时，请以此年份为准。

ce-ideate 执行于 ce-brainstorm 之前。

  • ce-ideate 解决的问题是：“有哪些最值得探索的高价值构想？”
  • ce-brainstorm 解决的问题是：“选定的某个构想具体意味着什么？”并在 <root>/plans/ 下生成仅包含需求的统一规划文档。
  • ce-plan 解决的问题是：“具体应该如何构建？”

该工作流会生成一份带梯队排序的构想产物文档 —— 存在代码库时写入 <root>/ideation/，否则写入 CE 临时路径（参见 Phase 4）。它不会直接生成需求文档、开发计划或代码。

初始化配置 (Setup)

在本次调用的最开始（任何子 Agent 调度之前）运行一次以下脚本，并遵循其打印的指令 —— 除非其中某些指令与本 Skill 关于向用户提问的规则存在冲突。无论这些规则是仅适用于非交互模式还是全局适用，一律以本 Skill 的规则为准，不发起阻塞式提问。请勿在同一次调用中重复运行；后续若调用本 Skill 或其它 Skill 会各自运行。若当前环境未安装 Node 运行时，Skill 将按常规流程继续执行。

SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
NODE="$(for c in node nodejs; do command -v "$c" >/dev/null 2>&1 && "$c" -e '' >/dev/null 2>&1 && { echo "$c"; break; }; done)";
if [ -n "$NODE" ]; then
"$NODE" "$SKILL_DIR/scripts/context.mjs" || echo "context script failed; continue with the skill's normal behavior";
else
echo "no Node runtime; continue with the skill's normal behavior";
fi

交互方式 (Interaction Method)

请优先使用平台原生提供的阻塞式提问工具：Claude Code 中的 AskUserQuestion（若未加载 schema，需先通过 select:AskUserQuestion 调用 ToolSearch）、Codex 中的 request_user_input、Antigravity CLI (agy) 中的 ask_question，以及 Pi 中的 ask_user（需安装 pi-ask-user 插件）。只有在运行环境中不存在阻塞式提问工具或工具调用报错时（例如 Codex 的编辑模式中），才降级回退到在 Chat 中输出带编号的选项 —— 切勿因需要加载 schema 就直接放弃工具。绝不允许悄无声息地跳过提问。

每次仅提出一个问题。存在自然选项时，优先使用简明的单选形式。

焦点提示 (Focus Hint)

焦点提示 (focus hint) 是指调用本 Skill 时传入的任何可选上下文 —— 可能存在于当前 Prompt 或对话上下文中，无论是由用户直接输入还是上游 Skill 传递过来的。在本 Skill 后续说明中统一记为 {focus_hint}（若未提供则为空）。

传入的任何参数均应视作可选上下文。它可以是：

  • 某个概念，例如 DX improvements（开发者体验提升）
  • 某个路径，例如 skills/
  • 可供参考的研究产物 —— 存放在仓库内外任意路径下的调研证据文件（如社交媒体研究报告、问卷导出数据、分析日志 dump 等，在 Phase 1 的用户提供研究子章节中处理）
  • 某个约束条件，例如 low-complexity quick wins（低复杂度速赢项）
  • 数量提示，例如 top 3、100 ideas 或 raise the bar（提高标准）

若未提供任何参数，则直接按开放式构想流程推进。

产物根目录 (Artifact Root)

本 Skill 在仓库模式下会将构想产物写入 <root>/ideation/，并从 <root>/solutions/ 读取历史经验。请仅在拼接此类路径时解析 <root>（按下方规则执行）—— 非仓库 / 其它路径流程会写入临时目录，完全不需要该根目录，因此在完成模式分类前切勿提前解析或创建根目录。解析成功后，请将解析后的路径传递给各个子 Agent，而不是直接传递配置文件。

<!-- ce-docs-root:start -->
在拼接任何产物路径前，先解析 CE 产物根目录 <root>。

  • 读取 <repo-root>/.compound-engineering/config.local.yaml 中的 docs_root 字段，若无则读取 config.yaml；以第一个非空值为准（<repo-root> 通过 git rev-parse --show-toplevel 获取）。若均未设置 -> <root> 默认为 docs，与此前行为一致。
  • 校验 已设置的值：必须是相对于仓库根目录的相对路径，且其实际路径（解析软链接后）须保留在仓库内部，既不能是仓库根目录本身，也不能位于 .git/ 下。否则立即终止并抛出包含 docs_root 及该非法值的错误信息 —— 绝不能静默回退到 docs。
  • 使用 <root> 作为唯一的产物存储位置：若不存在则创建之，后续各子目录路径均按 <root>/<subdir> 格式拼接，且不再读取 docs 目录。
    <!-- ce-docs-root:end -->

核心原则 (Core Principles)

  1. 立足实际，拒绝空谈 (Ground before ideating) - 先扫描实际的代码库。切勿脱离项目仓库生成抽象空洞的产品建议。
  2. 海量生成 -> 严苛批判 -> 仅精解幸存者 (Generate many -> critique all -> explain survivors only) - 质量把控的核心机制在于“带有明确理由的淘汰剔除”，而非盲目乐观地排名。切勿让繁琐的流程掩盖这一核心模式。
  3. 将行动顺畅引入头脑风暴 (Route action into brainstorming) - 构想阶段负责找出有前景的方向；ce-brainstorm 则将选定的方向定义得足够具体，以供后续规划。切勿直接从构想输出跳过头脑风暴去制定规划。

模型分级 (Model Tiers)

子 Agent 的调度按任务形态分级，绝不硬编码具体的模型名称：

  • 提取层 (Extraction tier) — 负责证据搜集、检索及引用等工作。当当前环境支持已知覆盖配置时，使用平台最便宜但胜任的模型。“胜任”是硬性要求 —— 当仓库体量巨大或技术栈极其冷门时，应升级至生成层。
  • 生成层 (Generation tier) — 负责基于证据的构思框架构建及依据校验。当当前环境支持已知覆盖配置时，使用平台的中端模型。若模型名称未知，应省略覆盖参数继承默认模型，切勿盲目猜测。
  • 顶配层 (Ceiling tier) — 负责顶层构思框架、跨领域综合分析及最终裁定。通过省略 model 参数直接继承 Orchestration 主 Agent 的模型。

降级规则。 当平台的子 Agent 机制不支持按 Agent 独立选择模型时，所有任务统一使用继承的模型进行调度，但保持读取预算和文档上限限制 —— 此时成本控制靠结构化流程实现，而非模型分级。

以下两种覆盖情况会将全线构想 Agent 提升至顶配层：惊喜模式 (surprise-me mode，主题探索高度依赖判断力，是该模式的核心价值所在) 和 go deep 深度覆盖指令 (Phase 0.5)。

执行流程 (Execution Flow)

Phase 0: 恢复与范围确认 (Resume and Scope)

当 Prompt 中已明确主题、模式与输出格式时，一步完成本阶段的解析并继续推进 —— 下述门槛是为了解决歧义而设，并非为了走过场。

0.0 解析输出模式 (Resolve Output Mode)

确定本次运行可能持久化的构想产物格式 OUTPUT_FORMAT。输出模式具有排他性 —— 构想文档要么写为 HTML (.html)，要么写为 Markdown (.md)，绝不同时生成两种。优先级顺序：Prompt 内显式指定 > 用户先前表述的偏好 > 配置文件 > 默认值 (html)；管线模式 (pipeline-mode) 具有强制覆盖权。

与 ce-plan 和 ce-brainstorm（默认使用 md）不同，ce-ideate 默认使用 html —— 因为构想文档的主要读者是评估候选方向的人类，一个包含丰富交互、自包含且带有前排候选方案示意图的 HTML 文件能大幅提升阅读体验。

读取配置。 运行时使用 Shell 工具执行 git rev-parse --show-toplevel 解析出 <repo-root>。然后使用原生文件读取工具读取 <repo-root>/.compound-engineering/config.local.yaml。若无法解析根目录（非 Git 仓库）或文件不存在，则静默回退至下述默认逻辑。

解析步骤：

  1. Prompt 内显式指定。 分析用户本次运行的 Prompt，检查是否有关于本篇文档输出格式的要求，无论表现为简写 output: 还是平实自然语言（如“把这个给我生成为 markdown”、“我要一个网页”）。若有明确格式要求，不区分大小写匹配 md/html，并在将 Prompt 余下部分解析为焦点提示时忽略 output: 简写标记。注意区分“对文档格式的要求”与“作为讨论主题的格式”：例如“针对 HTML 导出功能展开构思”属于工作内容本身，而非文档格式要求 —— 切勿因此触发切换。
    • 仅有 output:（未附带值）→ 无效操作，回退至第 2 步。
    • output:<未知值>（例如 output:pdf）→ 丢弃该标记，回退至第 2 步，并在最终解析完成后，于构想后菜单上方输出一行提示：Ignored unknown output: value '<value>' — using <resolved_format> instead.（忽略未知的 output 值 '<value>' — 转为使用 <resolved_format>），其中 <resolved_format> 为经后续步骤最终确定的 OUTPUT_FORMAT 实际值。切勿在提示中硬编码格式 —— 当配置或默认值与你的假设不符时会误导用户。
  2. 用户先前表述的偏好。 若 Prompt 中无格式要求，则尊重用户先前在本次 Session 中、记忆中或写入当前生效指令里的输出格式偏好（Markdown 对比 HTML）（不区分大小写匹配 md/html）。记忆中的偏好比极少修改的配置文件更新，因此在第 3 步中会覆盖配置文件。无需打开或搜索指令文件去专门查找 —— 仅当偏好已存在于当前上下文时才生效；若无，则回退至配置文件。
  3. 配置文件。 若第 1-2 步未完成解析，且上述读取的配置文件中包含**生效中（未被注释）**的 ideate_output: 键且其值匹配 md 或 html（不区分大小写），则采用该值。缺失、无效或被注释的值将被静默跳过。注意：以 # 开头的行属于 YAML 注释，必须忽略 —— 随附的配置模板包含 # ideate_output: md 等注释示例说明，若将其误识别为生效配置，会导致用户未主动开启时静默覆盖默认值。
  4. 默认值。 否则 OUTPUT_FORMAT=html。
  5. 管线覆盖 (Pipeline override)。 当在任何 Pipeline 或 disable-model-invocation 上下文中被调用时，无论第 1-4 步结果如何，一律强制设置 OUTPUT_FORMAT=md —— 自动化下游消费方能稳定解析 Markdown，而在管线运行中生成 HTML 会带来不必要的麻烦。

Token 解析约定： 仅带字面前缀的 flag token（如 output:，以及适用时的 mode:）会被消费并剥离。其它 <word>:<word> 格式的 token（包括可能出现在焦点提示中的常规 commit 前缀，如 feat:、fix:、chore:）均原样保留。

延迟加载格式渲染参考文档。 最终交付物是在 Phase 4（生成之后）才写入的，因此 references/ideation-sections.md 以及格式渲染参考文档（markdown-rendering.md / html-rendering.md）只需在届时加载 —— 在 Phase 0.0 就加载它们只会白白占用整个立足调查和构想调度过程的上下文。现在只需解析确定 OUTPUT_FORMAT，在写入阶段再加载章节规范和对应的渲染参考文档（参见 references/post-ideation-workflow.md §4.1）。

output: 偏好在转交（Phase 5）时不会自动传递给 ce-brainstorm —— ce-brainstorm 会独立解析自己的 brainstorm_output 配置。非对称输出（ideation.html + 统一规划的 Markdown）是完全允许的；若用户希望两者均为 HTML，可在 .compound-engineering/config.local.yaml 中同时设置这两个键。

0.1 检查近期构想工作 (Check for Recent Ideation Work)

检查 <root>/ideation/ 中是否存在过去 30 天内创建的构想文档（*.md 或 *.html）。这是仓库模式下的一个便捷检查：若不存在 Git 仓库，或解析 <root> 失败（如无效的 docs_root），直接跳过此扫描并继续 —— 切勿在 Phase 0.3 将模式分类为仓库模式还是其它/无仓库模式之前终止运行，因为其它位置或非软件构想运行会写入临时区域，绝不会触及 <root>/ideation/。

在满足以下条件时，认为先前的构想文档具有相关性：

  • 主题与要求的焦点匹配
  • 路径或子系统与要求的焦点重叠
  • 需求是开放式的，且存在明显近期未结案的构想文档
  • 问题立足状态匹配：不要提供 r