Agent 时代的博客（二）：观点的 git 化

上一篇的调研里有个空位：社区在 llms.txt 和 MCP 上已经很热闹，但内容信任层几乎没人做。这一篇补上我们自己的答案，核心是一个转变：

修改时间不应该是你记得手填的元数据，而应该是系统自动为你说真话。

问题：三个时间，两个是假的

一篇技术博客通常有三个时间：

1. 发布时间——基本可靠，写文章那天顺手填的
2. 修改时间——AstroPaper 的 schema 里有 modDatetime 字段，但靠手填。你三个月后修正了一处错误，多半忘了更新它
3. 读者感知的时间——页面上那个”更新于”，直接读 modDatetime

假的修改时间比没有更糟：它伪装成可信的。而 Agent 引用你的内容时会带上”作者于 X 月更新”——如果这个时间是假的，你污染的是下游的答案。

改造一：让 git 替你记时间

博客本来就是 git 仓库，修改历史一直在那里，只是没人问它。改造很小：

• 构建时用 git log --follow 读每个文章文件的提交历史
• modDatetime 的解析规则变成：frontmatter 显式声明优先，否则取最后一次提交时间
• 同一份时间喂给三处消费点：排序、“更新于”显示、JSON-LD 的 dateModified

效果：修正一篇文章 → 提交 → 页面上的”更新于”、dateModified、llms.txt 里的时间全部自动变真。作者要做的只有一件事——像平常一样改文章、提交。

一个部署细节差点毁掉这一切：GitHub Actions 默认浅克隆（fetch-depth: 1），构建时根本没有历史可读。给 deploy workflow 加了 fetch-depth: 0。这是典型的”本地好好的，线上静默降级”——如果没在 CI 里盯一眼，这个功能上线即失效且无报错。

改造二：变更史

时间只有”最后修改”一个点是 coarse 的，读者值得看到过程。文章页底部现在有一节**“本文变更史”**：

2026-10-27  docs: 开篇路线图修订——调研后改为统一数据层架构

每条 = 日期 + git 提交摘要，自动隐去首次发布（发布时间在标题旁已经有了）。只提交过一次的文章不渲染这个区块——没有修订就没有记录，不制造噪音。

成本几乎为零，因为提交信息本来就是给未来的自己写的备注；现在它同时服务读者和 Agent。

改造三：修订规范（写作约定）

上面两个是自动的，这一条是人的事。当一篇文章的核心观点需要修正时，规范是：

1. 不要悄悄改掉。原判断保留，在修正位置插入显式的修订块
2. 修订块的格式：> [!IMPORTANT] 日期 修订，说明改成了什么、为什么
3. 提交信息写清这次修订的性质

第一个示范就发生在这个系列的开篇文章里：路线图原是五步，调研后修正为”统一数据层优先”的四步，原文保留，修订块说明差异和理由。你可以在那篇文章里同时看到修订块和它自动生成的变更史。

这个规范像什么？像论文的勘误，也像 git 的 commit 而不是 force push。观点可以变，但演变必须可追溯——这正是上一篇文章说的”观点的 git 化”：博客天然该是一个公开的、带时间戳的思想版本库。

对 Agent 意味着什么

做完这三件事，一个 Agent 引用本站内容时可以做出这样的回答：

作者在开篇主张五步路线图，后于 10 月 27 日修订为统一数据层架构（变更史可查）。

对比现在大多数博客能提供的：“某文章说……（可能已过时）“。引用质量天差地别，而实现只用了几十行代码加一个写作习惯。

下一步

路线图第三步：Agent 入口。站点已经是结构化的了（统一索引 + 纯文本端点），下一步是让 Agent 不用”爬”，而是”问”——一个零依赖的 MCP server，暴露检索和读取两个工具。做完它，任何 MCP 客户端配置一行就能查询这个博客。