实践 1
先把输出契约固定下来
先约定 JSON 字段的消费方式：final_response 用于展示、changed_files 用于范围判断、tokens 用于成本统计、elapsed_ms 用于时延告警。
解决方案指南 · CLI 自动化
用 run --json 打通 CI 自动化的实战指南
把 Hajimi Code 从“问答工具”升级为“流水线节点”：有结构化输出、有质量门禁、有成本追踪。
实践 2
把一次大任务拆成多个小检查
不要只跑一条“综合审查”。可拆成风格检查、风险检测、回归计划三个任务，各自输出 JSON，方便在 CI 里单独失败、单独重试。
实践 3
用 changed_files 做增量门禁
读取 changed_files 后只对相关目录执行后续动作，例如只在 backend 变更时跑后端检查，避免流水线被全量流程拖慢。
实践 4
把 tokens 与 elapsed_ms 纳入周报
将 tokens.total 与 elapsed_ms 汇总到流水线报表，持续观察模型成本与时延趋势，及时调整模型角色或提示词长度。
实践 5
准备失败兜底路径
当 API 超时或输出为空时，回退到基础静态检查并提示人工复核。自动化目标是提高稳定性，不是把发布流程绑死在单点服务上。
可直接套用的流水线命令
hajimi run --json --output reports/review.json 审查本次 PR 的风险点
hajimi run --json --output reports/test-plan.json 为本次改动生成回归测试清单- 优先在非阻断 Job 中试运行 1-2 周，确认误报率后再转为阻断。
- 将 JSON 文件作为 CI Artifact 保存，便于后续追溯和复盘。
- 固定任务指令版本，避免不同分支之间输出口径漂移。