用定时任务让AI每晚自动生成Changelog

免费 AI 服务器最高效的用法，既不是聊天窗口，也不是代码审查助手。它是一个定时任务，读取 git 历史记录，生成一份你一直拖延到发布当天才会写的变更日志。本文认为，变更日志生成是免费模型访问的理想工作负载，因为它是异步的、风险低、易于验证。文章还提供了一个极简脚本，每天夜里将仓库的提交记录转成发布说明。

为什么变更日志是理想的免费 AI 工作负载

写变更日志是大多数开发者避之不及的苦差事，直到发布日才匆匆凭记忆补上。这个过程既慢、又不完整，而且会不自觉地偏向最后几个你想得起来的提交。免费模型可以读取完整 git 日志，在几秒钟内生成结构化的摘要，这是人类不花大力气就做不到的。输出不需要完美，因为变更日志本质上是一种沟通产物，而非关键正确性的系统。

这个任务天然是异步的，意味着它能容忍免费模型访问的波动。如果请求超时或模型返回了格式错误的响应，下一次运行重试就好了。没有开发者在干等着结果，缺失一条记录也不是生产事故。这使得它成为免费服务器上后台作业的完美候选者，你可以放心地安排它每天夜间运行，无需担心可用性或成本。

设计：夜间任务三阶段工作流

我推荐的工作流分三个阶段，每个阶段对应一个简单的脚本步骤。第一，用 git log --oneline 提取自上一个发布标签以来的所有提交。第二，按 conventional commit 类型对这些提交分组，将 feature、fix 和 breaking change 分开。第三，将每个分组发送给免费模型，并附上要求生成简洁列表摘要的 prompt，然后把结果写入 CHANGELOG.md。

这正是 MonkeyCode 的免费模型访问和免费服务器选项真正派上用场的地方，因为你可以完整运行整条流水线，而无需自备 GPU 或按 token 付费。声明：本文作为 MonkeyCode 产品推广的一部分而撰写。免费服务器充当 cron 作业的可靠执行器，而免费模型负责语言生成，两者对这项低风险任务都绰绰有余。

脚本：极简变更日志编译器

以下 Python 脚本以约六十行代码实现了三个阶段。假设你有一个使用 conventional commits 的仓库，且系统中有 git 可执行文件。将 ENDPOINT 和 MODEL 常量替换为你的审查工具提供的值，并将 REPO_PATH 设为你的仓库路径。

import json
import subprocess
import requests
from datetime import datetime, timedelta

REPO_PATH = "/path/to/your/repo"
ENDPOINT = "https://your-free-model-endpoint/v1/chat/completions"
MODEL = "free-tier-model"
PROMPT = "Summarize these git commits into concise changelog bullets. Preserve the meaning, do not invent details."

def git_log(since: str) -> str:
    result = subprocess.run(
        ["git", "-C", REPO_PATH, "log", "--oneline", "--since", since],
        capture_output=True, text=True, check=True
    )
    return result.stdout

def summarize(commits: str, group: str) -> str:
    payload = {
        "model": MODEL,
        "messages": [
            {"role": "system", "content": PROMPT},
            {"role": "user", "content": f"Group: {group}\nCommits:\n{commits}"},
        ],
        "temperature": 0.3,
    }
    resp = requests.post(ENDPOINT, json=payload, timeout=60).json()
    return resp["choices"][0]["message"]["content"].strip()

def main():
    since = (datetime.now() - timedelta(days=7)).isoformat()
    log = git_log(since)
    # A real implementation would group by conventional commit prefix.
    groups = {"feat": [], "fix": [], "docs": [], "other": []}
    for line in log.splitlines():
        prefix = line.split(":")[0] if ":" in line else "other"
        groups.setdefault(prefix, []).append(line)
    output = ["# Changelog", ""]
    for group, lines in groups.items():
        if not lines:
            continue
        summary = summarize("\n".join(lines), group)
        output.append(f"## {group.title()}")
        output.append(summary)
        output.append("")
    with open("CHANGELOG.md", "w") as f:
        f.write("\n".join(output))

if __name__ == "__main__":
    main()

这个脚本刻意保持极简，你应该将它视为起点而非生产级工具。分组逻辑比较 naive，prompt 也没有针对你仓库的风格做优化。不过它演示了核心思路：免费模型可以把原始 git 历史变成结构化文档，全程无需人工干预。

如何评估输出

你不应该在快速审查之前直接合并生成的变更日志，因为免费模型可能产生幻觉或遗漏重要上下文。一个简单的评判标准是：检查每个 breaking change 是否都出现了、没有提交信息被捏造、以及语气是否中立客观。将输出与同期的实际 git 日志做对比，丢弃任何无法追溯到真实提交的条目。

举例来说，一条好的条目可能是"Add pagination to the user list endpoint"，而一条坏的条目则是"Fix all performance issues in the API"——如果仓库中根本没有这样的提交的话。评估耗时不到一分钟，远比从头写变更日志快。随着时间推移，你可以调整 prompt 和分组逻辑，逐步减少需要修改的次数。

局限性与适用边界

这个工作流并非适合每个仓库。如果你的团队不使用 conventional commits，分组步骤会产生一个混乱的"other"桶，模型也很难找到结构来辅助生成。如果你维护的是一个每天有几十个不相关变更的大型 monorepo，单一的摘要会太浅而无用。另外，如果你的变更日志必须满足法律或监管要求，你就不能依赖随机模型来生成精确措辞。

此外，如果你的仓库每周提交数少于十条，也应该跳过这个方案，因为设置 cron 任务和审查输出的开销会超过你节省的时间。这个方法真正发挥的场景是：仓库足够活跃，发布说明足够长，以至于人类宁愿不去写它。对于小型项目，手动列一个要点清单仍然是更好的选择。

免费层在夜间赚回它的价值

免费 AI 服务器的真正价值，不在于白天那些巧妙的对话，而在于你睡觉时它能完成的那些枯燥任务。变更日志编译器就是这样的任务，它易于构建、易于验证、如果输出不够好也易于丢弃。今晚就把 cron 任务搭起来，让免费层物尽其用。最坏的情况不过是一份需要你编辑的变更日志；最好的情况则是清单上又少了一件苦差事。