ai-mind: Skill for Codex

AI Mind 技术博客

围绕一个真实工程问题，写出 AI Mind 的版本演进、架构设计、核心流程、关键取舍、验证方式与当前边界。将可发表的工程复盘与版本流水账、框架教程区分开。

硬边界

• 只处理 AI Mind 技术博客，并独立核对源码、测试和版本资料后再写入文章。
• 只在用户明确要求创建、撰写或优化正式博客时写文件；只允许创建或修改 private-folder/blogs/ 下的 Markdown 文章。选题和大纲默认只在对话中输出。
• 不创建候选选题、内部证据、草稿副本、README、日志或其他辅助文件。优化已有文章时原地迭代，不创建“优化版”“最终版”等副本。
• 不把 private-folder/ 的草稿或历史文章当作实现事实来源；仅将 private-folder/blogs/ 用于既有文章迭代和写作风格参考。
• 不把计划、推测、未实现能力或虚构的性能/业务数据写成已完成事实。文档和代码冲突时，以最新实际源码与测试为准；若核心事实无法确认，先向用户提出该问题。

资料读取与事实判定

先界定文章的版本、主题和主要工程问题，再按最小必要范围读取资料。默认以当前工作区的最新实际实现为准；Git 变更和提交用于定位演进过程与变更边界，不以是否打 tag 或是否发布作为写作前置条件，也不向文章读者暴露内部验证状态。

按以下优先级建立事实：

1. 用户明确指定的版本、文章主题、已有文章和写作范围。
2. 与主题直接相关的最新源码、测试、运行脚本、Git diff 与提交记录。
3. 对应 specs/<version-topic>/ 中的 spec.md、plan.md、tasks.md、acceptance.md、decisions.md、research.md 与 quickstart.md；用它们理解动机、约束、Non-goals 和验证设计。
4. 相关 docs/adr/、docs/architecture/ 与 .specify/memory/constitution.md；用它们确认长期边界。
5. docs/versions/、docs/releases/、README.md；仅用于公开叙事和术语交叉检查。
6. 同主题历史博客；仅用于风格、系列衔接或原文件优化。

为每个文章核心断言在工作中确认其证据：已实现、部分实现、仅设计或未确认。内部完成这份核对即可；不要把机械检查表或内部验证状态塞进正文。只有未确认事实会改变文章中心论点时才停止并向用户说明。

动笔前建立内部“论点—证据”映射：中心论点要有对应的实现或行为证据；问题和约束要能回溯到版本资料、代码或 Git 变更；每段关键代码、图或流程只服务一个明确判断。不要让代码片段承担多个未经解释的结论，也不要用一组文件名代替证据。

模式路由

选题分析

用于“分析某个版本适合写什么博客”。不要创建文章文件。输出：

• 版本真实实现摘要，以及它解决的工程问题。
• 2 至 4 个候选选题；分别说明技术价值、可用证据、叙事风险和适合的读者。
• 一个明确推荐主题及理由。
• 是否应与相邻版本合并；能形成同一因果链才建议合并，否则建议拆为系列。
• 仅列出会影响选题判断的未确认事实。

不要把“新增了哪些功能”当作选题本身。优先选择有明确矛盾、约束、方案和取舍的主题。

大纲设计

用于“根据主题整理博客大纲”。默认只在对话输出并等待用户确认。输出：

• 2 至 3 个标题候选与文章中心论点。
• 一条从问题到边界的工程叙事主线。
• 二级或三级章节结构；每节说明要回答的问题和对应证据。
• 应展示的少量代码片段及其职责。
• 是否需要真实架构图、流程图或图片占位，以及每张图应表达什么。

标题应表达工程对象与具体问题、方案或取舍；可以使用问题式标题，但不要使用夸张标题党、泛化的“深入理解”或“本版更新了什么”。让陌生读者能在开头数段理解项目背景、当前工程问题和本文结论。不要让章节按文件列表或版本号推进；每个章节标题只承担一个主题，并尽量直接表达该节的判断。

初稿写作

用于“写博客”“生成完整初稿”或用户已给出主题/大纲的场景。主题或大纲已明确时直接写作；没有时在内部完成必要的选题与大纲判断，不要求用户依次运行前两种模式。

1. 核对主题、版本范围、真实实现、关键测试和设计约束。
2. 以一个主要工程问题组织文章：问题背景 → 原方案与现实约束 → 架构设计 → 核心流程 → 关键实现 → 设计取舍 → 验证方式 → 当前边界。
3. 读取 references/article-shell.md，在标题后插入固定开头模板，并在文章末尾插入固定结尾模板。只替换模板中的 <代码版本>；除非用户明确要求，否则不得改写其他模板文字、链接或表情。
4. 固定开头后立刻进入真实工程问题：用一个场景或矛盾切入，再在 1 至 3 句内给出全文核心判断，并预留能解释该判断的图片或结构图占位。不要重复模板中的项目介绍，也不要用泛泛行业背景拖慢正文。
5. 若用户要求创建或保存文章，先搜索 private-folder/blogs/ 是否已有相同版本和主题的文章；有则原地更新，无则按 blog-YYYY-MM-DD-vX.Y.Z-topic.md 创建。多版本文章使用 blog-YYYY-MM-DD-vX.Y.Z-vX.Y.Z-topic.md，文件名不用空格。
6. 仅在用户明确要求时将初稿写入文件；否则在对话中交付 Markdown 正文。