ai-mind-technical-blog

name	ai-mind-technical-blog
description	基于 AI Mind 的真实版本资料、最新实际源码、测试与 Git 变更，分析技术博客选题、设计大纲、撰写完整初稿或优化既有文章。用于“分析 AI Mind 某版本适合写什么博客”“整理版本博客大纲”“根据 AI Mind 实现写技术博客”“优化 AI Mind 既有博客”等场景，服务 AI Mind 的版本工程复盘。

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 正文。

代码片段只保留理解方案所必需的部分。每段前说明它解决的问题，后说明关键逻辑、边界或取舍。图和流程图必须来自已核对的实现；没有现成图片时使用项目规则要求的、说明用途的图片占位，不能编造图片链接或效果。首次出现的技术术语、文件或模块使用“英文标识（中文职责）”解释，后文保持同一称呼，不在同一概念上切换多个中文译名。

文章优化

用于“优化已有 AI Mind 技术博客”。先读取原文，再用最新实际实现、测试和版本资料核对核心结论。先只读标题、章节标题和每节首段，判断文章是否仍有单一叙事主线；再核对事实、术语、代码、重复和句子。保留作者的观点、语气和已有的有效结构；原地处理：

• 事实不一致、把计划写成实现、过期的代码职责或验证说法。
• 问题、约束、方案、流程、取舍和边界之间断裂的叙事。
• 重复结论、空泛套话、过度元叙述、非必要英文和明显 AI 腔。
• 业务枝节抢占工程主题、无解释的大段代码和无依据的图示。

保留固定开头和结尾模板；仅按文章实际范围更新其中的代码版本。完成后简要说明已改善的重点，只提出真正阻塞事实准确性的确认问题。

多版本判定

仅当多个版本围绕同一工程问题形成连续演进时合并。检查它们是否共享：

• 同一个问题或稳定接口；
• 前一版本遗留的约束，及后一版本针对它的调整；
• 可以讲清楚的架构变化与取舍。

满足时以“问题如何演进”为主线，而不是逐版罗列。关联较弱、读者需要频繁切换概念或合并后不存在单一中心论点时，明确建议拆成系列。

写作与交付检查

遵循 .agents/rules/blog/writing.md 与 .agents/rules/blog/review-checklist.md，并以当前用户要求优先。交付前确认：

• 文章围绕一个主要工程问题，而不是功能清单或官方教程。
• 问题、约束、方案、流程、关键代码、取舍、验证和边界形成闭环。
• 标题与章节标题各自只表达一个主题；标题能看出工程对象和具体问题、方案或取舍。
• 每个段落只推进一个判断，优先在段首写出结论或回答，再补充证据、过程和例外；删除没有信息增量的铺垫句。
• 重要模块和文件首次出现时补充职责解释；没有项目中不存在的抽象、数据或结论。
• 术语、模块名和格式在全文保持一致；中文为主，使用“我”或“我们”的项目复盘口吻，保留必要技术术语，删除不必要英文、重复和营销腔。
• 面向第一次接触 AI Mind 的读者交代足够背景，但不展开无关框架百科。
• 不泄露本地路径、内部协作过程、env、token、cookie、敏感配置或原始运行时数据。
• 正文只使用已确认的图、流程和代码；模板中的项目入口保持完整。

向用户交付整理后的文章、选题或大纲；除非核心事实需要决定，省略内部证据过程和机械检查清单。