构建自动化的 Build in Public 工作流

日常工作本身就有值得沉淀的技术内容，问题在于”额外抽时间整理”这件事的门槛太高。本文记录如何通过 opencode 的三层机制——AGENTS.md（约束）、Skill（流程）、自定义脚本（工具）——将编码工作直接转化为博客内容，实现零摩擦的 build in public。

配置思路

整个工作流围绕三个逻辑层构建，每一层解决一个核心问题：

行为约束层（AGENTS.md）：定义 AI 在项目中的行为边界，如 git 操作规则、项目上下文，确保生成的内容符合项目规范。
自动化流程层（Skill）：将重复的例行任务封装为可复用的步骤模板，包括日报生成和博客发布两个核心 Skill。
工具执行层（Shell Script）：将具体的操作落地为可执行的脚本，如 git 安全代理、会话选择器等。

三层之间单向依赖：工具层被流程层调用，流程层在约束层的规则框架内运行。

关键实现

1. 行为约束：AGENTS.md 的层级管理

opencode 支持多级 AGENTS.md，从当前目录向上遍历，最近的一个生效。利用这一特性，将规则分为三层：

全局级（~/.config/opencode/AGENTS.md）：各项目通用的后备规则
工作空间级（workspace/AGENTS.md）：目录布局、网络规则等基础设施
项目级（projects/*/AGENTS.md）：各项目独有的上下文，如 git root 路径、技术栈限制

发布流程相关的规则写入项目级 AGENTS.md，确保只在进入该项目时生效：

# changhorizon AGENTS.md
- Git root: source/changhorizon.com/
- 博客文章目录: src/data/blog/
- 使用 publish-to-blog skill 生成草稿
- 默认 draft: true

2. 自动化流程：Skill 的定义与触发

Skill 是可复用的步骤模板，通过 skill 工具按需加载。不需要切换 AI 角色，也不需要改动配置，在对话中自然触发即可。

日报生成

聚合 git log、git diff 和 opencode session 记录，写入 ops/daily/logs/YYYY-MM-DD.md。数据源覆盖已提交、未提交和对话上下文三个维度：

工作记录 = git log（已提交）
        + git diff（未提交）
        + opencode session（任务上下文）
        + ops/meetings/（会议记录）

博客发布

支持两种触发模式：

会话模式：“把这次会话发成博客”——将当前对话内容提炼为文章
工作模式：“发一篇今天工作的博客”——扫描 projects/ 下所有 git 仓库，汇总当日记录生成文章

发布前执行三步检查：价值评估（匹配度/独特性/半衰期）→ 风格学习（读 2-3 篇已有文章）→ 预览确认（对话中展示全文，确认后才写入）。写入默认为 draft: true，不急于公开。

3. 工具执行：自定义 Shell 脚本

在 tools/bin/ 下维护一组轻量脚本，作为流程的最终执行层：

git-proxy：git 操作的安全代理，限制 commit 只能在特性分支执行，禁止 push 操作
git-commit-proxy / git-push-blocker：前述代理的便捷入口
opencode-session：基于 fzf 的交互式会话选择器

这些脚本不依赖特定框架，唯一约束是 PATH 中包含 tools/bin/。

4. 完整的发布管线

当一天的工作结束后，整个管线的执行路径如下：

日常编码 → 调用 daily-report skill 生成日报（ops/daily/logs/）

当某个主题值得公开发布时：

在对话中说”发一篇今天工作的博客”
AI 收集今日 git 记录和会话记录
评估发布价值，展示评估结论
读已有文章学习风格
生成全文，在对话中展示（dry-run）
确认后写入 src/data/blog/<slug>.md（draft: true）

从产生内容到生成草稿，全程不需要离开 opencode 会话。

总结与洞察

Conclusion: build in public 的核心挑战不是写作能力，而是”从工作中分离出可公开内容”的转换成本。通过 opencode 的三层机制——AGENTS.md 定义规则、Skill 封装流程、脚本落地执行——将这一转换成本降到接近于零。关键在于让编码工作本身就产出结构化记录，而非在编码完成后额外制造内容。