DevLog 生成器

从人类-智能体协作编码会话的原始记录中，自动生成叙述性开发者博客文章。该博客以智能体的第一人称视角撰写——“我”指代智能体，“我的人类”指代协作的人类开发者。

工作流程

第一阶段：理解请求

从用户消息中提取以下信息：

• 项目 —— 涉及哪个代码库？（例如 eastore、filecoin、couponswap）。若未明确指定，则使用当前工作目录。
• 主题/功能 —— 具体是哪一部分？（例如 auth system、dashboard，或整个项目）。若未明确指定，则包含所有会话。
• 风格 —— 构建者日志（默认）、教程式或技术深度解析。仅当用户明确要求时才覆盖默认风格。
• 时间范围 —— 例如 last week、January sessions，或全部（默认）。

第二阶段：发现会话

确定需扫描的平台。检查 references/platforms/ 目录下支持的平台——每个子目录对应一个平台。根据当前运行环境自动检测，或依据用户请求手动判断。

仅加载相关平台的目录。每个平台目录包含一份参考文件（含存储结构定义、会话路径说明、发现指引）以及配套脚本（list-sessions.sh、read-session.sh）。切勿预先加载全部平台参考内容。

执行该平台的 list-sessions.sh 命令扫描匹配的会话；或按平台参考文件中的发现指引手动执行。

若 references/platforms/ 中不存在该平台的参考目录，则需手动发现会话——检查该平台的数据/配置目录（例如 ~/.local/share/、~/.config/、~/Library/），查找会话存储文件（JSONL、JSON、SQLite 等），并分析其结构以提取人类-智能体对话内容。后续过滤逻辑遵循第三阶段原则。

向用户提供会话索引，供其确认。

第三阶段：筛选与读取

基于会话索引，判定哪些会话与用户所提主题相关，并完整读取所选会话的原始记录。

读取过程中需进行严格过滤：

保留内容：

• 用户消息（纯文本）—— 人类开发者的意图、指令、修正意见
• 智能体消息（纯文本）—— 智能体的推理过程、方案建议、解释说明
• 工具调用名称 + 文件路径 —— 实际构建了哪些内容
• 错误信息 —— 遇到的困难与调试过程

剔除内容：

• tool_result 的主体内容（如原始文件内容、grep 输出等，占 token 总量的 80–90%）
• 系统消息、用量元数据、压缩/摘要条目
• 完整工具输入参数（仅保留调用名称 + 文件路径，不保留完整 diff 内容）

具体字段命名与解析细节，请参考第二阶段已加载的平台参考文件。

若过滤后的记录仍超出上下文长度限制，则采用分会话处理策略：先为每个会话生成摘要，再跨会话综合归纳。始终优先保留人类-智能体对话内容，而非工具调用细节。

第四阶段：撰写博客

阅读 references/blog-writing-guide.md 获取智能体叙事风格写作指南。其中涵盖语气定义、协作术语规范、对话提取模式及博客整体结构建议。

根据所需风格，查阅 examples/ 下的对应示例：

• examples/builders-log.md：构建者日志风格（默认）
• examples/tutorial.md：教程风格
• examples/technical.md：技术深度解析风格

加载 assets/devlog-template.md 作为博客骨架模板。该模板仅为起始结构，非强制格式——请根据实际会话内容灵活调整章节、重排顺序、合并或删减标题。单一会话生成的博客可完全省略阶段式标题；高度迭代的会话则可将“难点部分”（The Hard Part）拆分为多个小节。让故事本身决定结构形态。

严格依照写作指南生成博客。全文须由智能体以第一人称（“我”）叙述，并将人类开发者称为“我的人类”。当会话涉及架构设计、流程编排或多组件交互时，应嵌入 Mermaid 图表（```mermaid 代码块）以可视化系统结构——详见写作指南中的图表使用说明，了解适用场景与绘制规范。

第五阶段：输出

将生成的博客保存至当前工作目录下的 {project}-{topic}-devlog.md 文件，或用户指定的路径。

报告内容包括：标题、字数统计、涵盖的会话列表、时间跨度、关键引用文件。

第六阶段：发布

1. 询问用户是否希望将博客发布至线上平台。
2. 若用户选择发布，检查 references/publishing/ 目录下支持的发布平台。每个子目录对应一个发布平台。
3. 加载对应平台的参考文件，获取 API 接口详情与前置要求。
4. 检查必需的环境变量（例如 Hashnode 平台所需的 HASHNODE_PAT 和 HASHNODE_PUBLICATION_ID）。
5. 若任一环境变量缺失，明确告知用户需设置的变量名及其赋值方式（例如在 ~/.zshrc 或 ~/.bashrc 中添加 export HASHNODE_PAT=...），并请用户为本次会话提供具体值。
6. 封面图（可选）：若具备图像生成能力（例如接入图像生成工具或 MCP 服务），请生成一张契合博客主题的封面图。将其上传至公开可访问的 URL，并通过 --cover-image 参数传给 publish.sh 脚本。封面图应为横版（推荐尺寸 1200×630 或相近比例），视觉上与博客主题强相关，且不得包含与标题重复的文字内容。若无图像生成能力，可跳过此步骤——博客无需封面图亦可正常发布。
7. 执行对应平台的 publish.sh 脚本，传入博客文件路径、标题（如已生成封面图，还需附加 --cover-image 参数）。
8. 向用户报告已发布文章的 URL。

边界情况处理

资源

平台参考（仅加载相关的一个）

• references/platforms/claude-code/ — Claude Code 参考资料与脚本
  • claude-code.md — 会话路径、JSONL 结构定义、发现指引
  • list-sessions.sh — 扫描 Claude Code 项目中匹配的会话
  • read-session.sh — 从 Claude Code JSONL 中提取对话记录
• references/platforms/opencode/ — OpenCode 参考资料与脚本
  • opencode.md — 存储布局、JSON 层级结构、发现指引
  • list-sessions.sh — 扫描 OpenCode 项目中匹配的会话
  • read-session.sh — 从 OpenCode 的 JSON 层级结构中提取对话记录
• references/platforms/openclaw/ — OpenClaw 参考资料与脚本
  • openclaw.md — 会话路径、JSONL 结构定义、发现指引
  • list-sessions.sh — 扫描 OpenClaw 智能体中匹配的会话
  • read-session.sh — 从 OpenClaw JSONL 中提取对话记录
• references/platforms/codex/ — Codex 参考资料与脚本
  • codex.md — rollout 文件格式、JSONL 结构定义、发现指引
  • list-sessions.sh — 扫描 Codex rollout 文件中匹配的会话
  • read-session.sh — 从 Codex rollout JSONL 中提取对话记录
• references/platforms/gemini-cli/ — Gemini CLI 参考资料与脚本
  • gemini-cli.md — JSON 会话格式、SHA256 项目哈希机制、发现指引
  • list-sessions.sh — 扫描 Gemini CLI 会话文件中匹配的项目
  • read-session.sh — 从 Gemini CLI 会话 JSON 中提取对话记录
• references/blog-writing-guide.md — 语气规范、协作术语、对话提取模式、博客结构

发布平台（仅加载相关的一个）

• references/publishing/hashnode/ — Hashnode 发布参考资料与脚本
  • hashnode.md — GraphQL API 地址、认证方式、publishPost mutation 定义、必需环境变量
  • publish.sh — 将 Markdown 文件发布至 Hashnode，并输出文章 URL

示例

• examples/builders-log.md — 构建者日志风格输出样例
• examples/tutorial.md — 教程风格输出样例
• examples/technical.md — 技术深度解析风格输出样例

资源文件

• assets/devlog-template.md — 博客骨架模板