01 — 概述
CVSM
02 — 问题
规格和它以下的各层
agent 会改动对比需要固定的设置
编码 agent 写代码、启动运行、贴出结果的速度，已经快过人能读完的速度。
为了修一次崩溃改了学习率，为了塞进显存把有效 batch 减半。每一处单看都合理，合在一起，对比就成了猜测。而你通常只看到 agent 的总结。
研究规格是你能完整读懂的那一层，所以 CVSM 按每个 run 自己的记录，对照规格核对。
03 — 状态机
四个关口 · 每一步都在 GitHub 上
研究是GitHub 上的状态机
研究依次经过计划、实现、审查、合并、运行、分析，每一步都记在 GitHub 上。每条指令就是一个目标状态。agent 一直推进，到达目标状态、碰到关口或遇到卡点时才停；一切顺利也要在四个关口停下。
继续阅读01 计划
Issue
- study #10
- code #11
- run #12
- Decision:
02 实现
PR
- Closes #11
- guard · test
- Decision:
03 审查
审查
- Verdict: pass
- @ 3f9c2a1
04 合并
main
- squash 合并
- 就是那个 head
- Decision:
05 运行
MLflow run
- cvsm.* cfg.*
- artifacts
- Decision:
06 分析
结果
- 单个 issue 的表
- 规格核对
- 研究总表
- Decision:
01发布
- 什么时候
- 新增或改变已批准的工作：发布计划；改任务的 Goal、Scope、Acceptance 或 Merge，或研究的 Arms、Controlled、Adaptable；改受保护路径。
- 你说
- “发布”，或批准这处改动
- 记下什么
- 按波次建好的父 issue 和子 issue，以及父 issue 上的一条 Decision: 评论。
卡点
- 什么时候
- 同一个失败连续 3 次；审查连续 3 次给出 changes；目标有歧义且会影响交付物；某个 Controlled 设置不改变对比就满足不了。
- 你说
- 最多 3 个选项里的一个，例如“选 2”
- 记下什么
- 你不在时：needs-decision 标签和一条四行评论（Blocked:、Evidence:、Options:、Recommend:）；你答复后记一条 Decision:。
02合并
- 什么时候
- PR 待合并：guard 和 test 全绿，当前 head 有 Verdict: pass。任务写了 Merge: agent 时，agent 自己用 merge.py 合并；碰了受保护路径或没审查过的 head，merge.py 会拒绝。
- 你说
- “合并”，或“合并 #15”
- 记下什么
- merge.py --human squash 合并那个 head；任务随之关闭，并记一条 Decision: 评论。
03预算
- 什么时候
- 下一步会超出预算：token、时间或 GPU 小时。
- 你说
- “继续”，也可以给个新预算
- 记下什么
- 一条写明新预算的 Decision: 评论。
04下结论
- 什么时候
- 研究的子 issue 全部关闭，进入待分析。
- 你说
- 你的结论，例如“#10 下结论：……”
- 记下什么
- 研究带着你的结论关闭，结论记成一条 Decision: 评论。
把鼠标移到关口上，或用 Tab 聚焦
04 — 规格核对
研究规格与运行记录
每个 run 都对照研究规格核对
你在关口 01 批准研究规格：各组（arm）之间的不同、固定不变的设置（各带理由）、可以调整的设置。每个 run 都记下解析后的配置，结果命令拿这些记录对照规格核对：启动后马上核一次，每条结果评论里再核一次。
继续阅读### Arms各组之间仅有的不同full: model.adapter=nonelora: model.adapter=lora model.lora.rank=8### Controlled固定不变，各带理由optim.lr=3e-4# 论文 X 表 2train.effective_batch=256# 论文 X 表 2seed in 1,2,3# 同论文 X，用 3 个 seed### Adaptable可以不同，守住各自的规则train.per_device_batch# 按显存调整，有效 batch 固定为 256train.accum# 跟随 per_device_batch
规格核对：
- ≠
train.effective_batch=256不成立：1 个 run，0330bc8a…（128） - ≠未声明的差异
train.precision：bf16（5 个 run）、fp16（1 个 run） - ·Adaptable
train.per_device_batch：full 取 64（3 个 run）；lora 取 64（2 个 run）、32（1 个 run） - ·Adaptable
train.accum：full 取 4（3 个 run）；lora 取 4（3 个 run）
scripts/results.py 的输出
它按事实列出
- 规格本身的问题：读不懂的行、没写理由的 Controlled 行、缺少的节、出现在多节的键
- 不满足某条 Controlled 的 run，或配置里没记录这个键的 run（未记录）
- 不属于任何 arm、或属于多个 arm 的 run
- 缺了某条 in 中某些取值的 arm
- 不在任何一节、取值却不同的键（未声明的差异）
- 没有 run 的 arm
- 每个 Adaptable 键在各 arm 取过的值
CVSM 只报告记录里有什么。这些 run 还能不能比，由你判断。
05 — 决定
Claude Code 或 Codex
- 你
我们计划一个研究：LoRA 能不能追上全量微调？
- Agent
和你讨论规格，然后起草研究 #10，以及代码任务 #11 和运行任务 #12。
- 你
发布
关口 01 - Agent
Done:已发布 #10 及 #11、#12；Decision 记在 #10
Waiting for you:无
Next:#11 已就绪
- 你
做 #11
- Agent
Done:PR #13 待合并，Verdict: pass @ 3f9c2a1
Waiting for you:合并 PR #13
Next:运行 #12
- 你
合并
关口 02 - Agent
Done:用 merge.py --human 合并了 PR #13；#11 已关闭；Decision 记在 #11
Waiting for you:无
Next:运行 #12
- 你
把 #10 推到待分析
- Agent
Done:#12 已关闭，附结果和规格核对；研究总表贴在 #10
Waiting for you:#10 下结论（关口 04）
Next:等你决定
Done:Waiting for you:Next:06 — 组成
六个数字
协议由什么组成
- 0个要安装的服务
- 80行规则，有测试卡住上限
- 4个 skill，每个最多 120 行
- 4个人的关口，是仅有的计划内停点
- 1个 agent 的合并入口：merge.py
- 2种 agent 命令行工具（Claude Code 和 Codex）共用一套 skill