技能介绍

它解决什么问题

聊天记录里的灵感和需求清单是两回事。前者多为碎片、混合语言、时间敏感，后者需要明确字段和状态。如果直接写进知识库，很容易出现三类故障：原始输入被改写、AI 推断被当成用户确认、写入其实失败了但回复里已经「报喜」。

IdeaLab 的做法是把已配置的 Markdown 仓库当作唯一事实源（only source of truth），在落库前保留原始文本，把用户陈述的事实和模型推断分开存放，并且只在 MCP 返回 ok: true 时才宣布写入成功。

核心流程

进入任何写操作之前，技能会先做路由：新想法走完整捕获，类似「先记下来」「稍后再展开」的请求走 Quick capture，已存在的想法先 idea_search 或 idea_get 再讨论，状态、决策、产物则走各自的专用工具。

完整捕获的固定顺序是：确认这是 Idea 而不是普通开发任务、推断类型（generic 或 product）、生成临时标题、立刻用完整原文调用 idea_create——这一步发生在任何追问之前。若返回 ok: false 则中止并报错，不输出「已保存」。随后用 idea_find_similar 找相似项，只提示不合并；最多追问三个问题，把答案映射为事实、假设、AI 建议和下一步动作，再通过 idea_update 写回同一个 ID。

安全更新靠职责分离：普通字段用 idea_update，状态用 idea_set_status，决策用 idea_append_decision，关联仓库和文档用 idea_link_artifact。id、created_at、decisions、status 不允许被覆盖，进入 committed、released、completed、rejected 之前必须拿到用户的明确意图。

适用边界

这套逻辑依赖 runtime-setup.md 中描述的 IdeaLab MCP 工具。工具不可用时，技能不会用文件系统或 shell 模拟写入，也不会声称想法已保存，只会提示运行时尚未连接。写入前还需读取 interaction-rules.md，产品类想法读 product-template.md，构造 payload 或排查错误时查 schema.md。

此外，模型建议一律进 ai_advice，假设字段必须标注未验证；礼貌性夸奖和好奇心既不构成购买意向，也不构成需求证据。