开发自动化：代码审查到部署
13 开发自动化：代码审查到部署
Dev Automation: From Code Review to Deployment
Claude Code写代码，Hermes看守流水线。两个工具不是二选一，而是各管一段。
一个开发者的早晨
早上9点打开电脑，Telegram弹出三条消息。不是同事发的，是Hermes发的：
「昨晚23:17，main分支有一个PR合并，新增387行代码。审查了一下有两个问题：auth模块的token过期逻辑没处理边
界情况，测试覆盖率从82%掉到76%。详细报告已存到项目Skill里。」
「凌晨2:40，CI流水线跑了一轮回归测试，3个用例失败。2个是昨天那个PR引入的，1个是已知的flaky test。」
「今天的日报初稿已生成，基于昨天的4个commit和2个PR。需要你确认后发送。」
这不是假想场景。Hermes的cron调度 + GitHub MCP + 记忆系统，可以让它在你睡觉时持续工作。
代码审查自动化
传统代码审查有两个痛点：延迟，提了PR得等reviewer有空；一致性，不同reviewer关注点不同，有人看架构有人看格
式。
用Hermes做自动代码审查的配置很简单：
1 接入GitHub MCP
在config.yaml中配置GitHub MCP Server，Hermes就能读取仓库的PR、diff、issue。
设置cron调度
2
用自然语言告诉Hermes：「每6小时检查一次main分支的新PR，做代码审查」。它会自动创建cron任务。
3 定义审查标准
把你的代码规范写成一个Skill。比如「函数不超过50行」「错误处理必须用自定义类型」「所有API端点必须有测
试」。Hermes按这个标准审查每个PR。
关键在第三步。审查标准是Skill，它会随着你的反馈自动演进。你标记了某个Hermes没发现的问题，下次它就会注意同
类模式。传统的lint规则是静态的，Hermes的审查标准是活的。
测试生成和执行
Hermes做测试和Claude Code做测试有个根本区别：Claude Code是你告诉它「给这个函数写测试」，它写完你验收。
Hermes是自己发现哪些函数没测试，自己写，自己跑，跑不过自己修，最后给你一个报告。
这个能力来自几个工具的组合：
工具 作用
file 扫描代码目录，找到缺少测试的模块
code_execution 在沙箱中运行测试
terminal 执行覆盖率报告生成
memory 记住哪些模块已审查、哪些测试是flaky的
可以配合cron做周度覆盖率检查。每周一早上自动扫描，覆盖率低于阈值就发通知提醒。
日报和周报自动汇总
这个功能听起来简单，但用起来会上瘾。
Hermes通过GitHub MCP拿到当天的commit记录、PR状态、issue变化，结合会话记忆中你讨论的内容，生成一份你自
己都不需要回忆就能确认的日报。
周报更有意思。因为有跨会话记忆，Hermes能看到整周的脉络：周一修了什么bug，周三为什么改了架构方案，周五的
PR为什么被打回。不是简单的commit列表，而是有因果关系的叙述。
实用建议：让Hermes生成日报时，同时更新一个项目Skill记录本周的技术决策。下周做周报时它能直接引用决策记录，
不用从commit message里猜你当时在想什么。
Claude Code和Hermes的分工
这两个工具不是竞争关系。它们擅长的东西完全不同：
维度 Claude Code Hermes Agent
交互模式 你在旁边，实时对话 后台运行，定时汇报
擅长 写代码、重构、调试 巡检、监控、汇总、调度
时间维度 一个session内完成 跨天、跨周持续运行
触发方式 你主动发起 cron自动触发或事件驱动
一句话总结：Claude Code是工匠，Hermes是管家。工匠负责做东西，管家负责确保一切都在正轨上。你不会让管家去
砌墙，也不会让工匠去巡夜。
→ → →
Claude Code 写代码提PR Hermes 自动审查PR Hermes 跑测试验证
Hermes 生成日报汇总
这条流水线跑起来之后，工作重心从「写代码+看代码+跑测试+写日报」变成「写代码+确认结果」。中间环节全部自动
化。
注意
Hermes的代码审查是辅助而非替代。它擅长发现模式化的问题（命名不规范、缺少测试、边界条件遗漏），但架构层面
的判断仍需人工。别因为自动化了就跳过人工review，至少核心模块要保留人工环节。
Dev Automation: From Code Review to Deployment
Claude Code写代码，Hermes看守流水线。两个工具不是二选一，而是各管一段。
一个开发者的早晨
早上9点打开电脑，Telegram弹出三条消息。不是同事发的，是Hermes发的：
「昨晚23:17，main分支有一个PR合并，新增387行代码。审查了一下有两个问题：auth模块的token过期逻辑没处理边
界情况，测试覆盖率从82%掉到76%。详细报告已存到项目Skill里。」
「凌晨2:40，CI流水线跑了一轮回归测试，3个用例失败。2个是昨天那个PR引入的，1个是已知的flaky test。」
「今天的日报初稿已生成，基于昨天的4个commit和2个PR。需要你确认后发送。」
这不是假想场景。Hermes的cron调度 + GitHub MCP + 记忆系统，可以让它在你睡觉时持续工作。
代码审查自动化
传统代码审查有两个痛点：延迟，提了PR得等reviewer有空；一致性，不同reviewer关注点不同，有人看架构有人看格
式。
用Hermes做自动代码审查的配置很简单：
1 接入GitHub MCP
在config.yaml中配置GitHub MCP Server，Hermes就能读取仓库的PR、diff、issue。
设置cron调度
2
用自然语言告诉Hermes：「每6小时检查一次main分支的新PR，做代码审查」。它会自动创建cron任务。
3 定义审查标准
把你的代码规范写成一个Skill。比如「函数不超过50行」「错误处理必须用自定义类型」「所有API端点必须有测
试」。Hermes按这个标准审查每个PR。
关键在第三步。审查标准是Skill，它会随着你的反馈自动演进。你标记了某个Hermes没发现的问题，下次它就会注意同
类模式。传统的lint规则是静态的，Hermes的审查标准是活的。
测试生成和执行
Hermes做测试和Claude Code做测试有个根本区别：Claude Code是你告诉它「给这个函数写测试」，它写完你验收。
Hermes是自己发现哪些函数没测试，自己写，自己跑，跑不过自己修，最后给你一个报告。
这个能力来自几个工具的组合：
工具 作用
file 扫描代码目录，找到缺少测试的模块
code_execution 在沙箱中运行测试
terminal 执行覆盖率报告生成
memory 记住哪些模块已审查、哪些测试是flaky的
可以配合cron做周度覆盖率检查。每周一早上自动扫描，覆盖率低于阈值就发通知提醒。
日报和周报自动汇总
这个功能听起来简单，但用起来会上瘾。
Hermes通过GitHub MCP拿到当天的commit记录、PR状态、issue变化，结合会话记忆中你讨论的内容，生成一份你自
己都不需要回忆就能确认的日报。
周报更有意思。因为有跨会话记忆，Hermes能看到整周的脉络：周一修了什么bug，周三为什么改了架构方案，周五的
PR为什么被打回。不是简单的commit列表，而是有因果关系的叙述。
实用建议：让Hermes生成日报时，同时更新一个项目Skill记录本周的技术决策。下周做周报时它能直接引用决策记录，
不用从commit message里猜你当时在想什么。
Claude Code和Hermes的分工
这两个工具不是竞争关系。它们擅长的东西完全不同：
维度 Claude Code Hermes Agent
交互模式 你在旁边，实时对话 后台运行，定时汇报
擅长 写代码、重构、调试 巡检、监控、汇总、调度
时间维度 一个session内完成 跨天、跨周持续运行
触发方式 你主动发起 cron自动触发或事件驱动
一句话总结：Claude Code是工匠，Hermes是管家。工匠负责做东西，管家负责确保一切都在正轨上。你不会让管家去
砌墙，也不会让工匠去巡夜。
→ → →
Claude Code 写代码提PR Hermes 自动审查PR Hermes 跑测试验证
Hermes 生成日报汇总
这条流水线跑起来之后，工作重心从「写代码+看代码+跑测试+写日报」变成「写代码+确认结果」。中间环节全部自动
化。
注意
Hermes的代码审查是辅助而非替代。它擅长发现模式化的问题（命名不规范、缺少测试、边界条件遗漏），但架构层面
的判断仍需人工。别因为自动化了就跳过人工review，至少核心模块要保留人工环节。