分支名里写着由模型参与：AI 进底层代码库要先改的是提交规矩
一、看点不在谁写了代码
据公开报道，有开发者在刷新上游官方仓库时注意到一条新分支，分支名后缀里写着有模型参与，相关报道提到这次改动在读路径上带来了性能提升。分支名、当事人身份、代码行数与最终有没有被合进去，都不在我们能核实的范围里，我们也不打算拿它推断任何项目的走向，更不会得出”底层库已被模型接管”这类说法。
值得工程同行停下来看的是另一件事：标注开始出现在分支名里。这意味着维护者在处理这类提交时，需要知道”这段代码不是人一行行敲出来的”这件事，而且认为这个信息要放在能被检索到的位置。换句话说，模型参与的代价不是靠”审核得严一点”来消化的，是靠改提交规矩来消化的。
底层库是企业软件的地板。我们的客户里做工业软件、做嵌入式、做基础组件的，都同时是上游的贡献者和下游的分发者。地板上的准入规矩怎么变，会直接决定他们自家公共库的规矩怎么定。
二、能被接受的四个条件，以及模型参与怎样破坏它们
第一条是单一目的。一个提交只做一件事，说明里写清这件事是什么，出问题时能直接定位到意图。模型参与最常见的破坏方式是顺手重构：让它改一个读路径，它把周边命名、辅助函数和注释一起收拾了一遍，改动面积膨胀，评审要判断的东西从一处变成十处。
第二条是可独立回滚。回滚这个提交之后，代码树要还能编译、还能通过测试。模型倾向把无关修复打包在一起——它看到了旁边一个明显的小问题，出于”帮你修好”的倾向改了，于是这个提交和那个提交在语义上被绑死，一个出问题就得连带回滚另一个。
第三条是有性能或行为的证据。底层库不接受”我觉得这样更快”，也不接受只有一张截图。第四条是不掺格式改动，格式变更要单独成提交，否则真正的逻辑改动会被淹没在差异里，diff 的可读性归零。
这四条本来就不是给”人的能力”设的门槛，是给”事后的可归因性”设的。模型参与并没有让这四条变得不适用，只是让它们更难自然满足，所以要靠规矩补。
三、标注模型参与的三种做法与各自的收益
第一种是写在分支名或提交主题里，就像那条被报道的分支那样。收益是评审预期：维护者一进列表就知道要用什么强度去读，读法会从”确认逻辑”偏向”确认边界与假设”。风险是信息量太薄，容易变成一种立场表达。
第二种是写在提交说明的正文里，按段落交代哪些部分由模型生成、人改了什么、验证由谁做的。收益是责任归属：出了问题能找到”是哪一步的判断失误”，而不是停在”这段是 AI 写的”这种没法追责的描述上。这是我们最推荐的形式，因为它和现有的提交规范兼容，不需要新工具。
第三种是写在结构化标记里，比如固定的页脚字段或 trailers，便于事后批量检索。收益是后续可统计：能回答”这个仓库里有多少性能类改动是模型参与的、它们的回滚率如何”。这一种需要仓库自己定字段，落地成本最高，适合已经有内部度量体系的团队。
三种做法不冲突，可以叠加。要注意的是别把标注写成免责声明——“由模型生成、未经充分验证”这类表述，在评审眼里等于”请不要接受这个提交”。
四、性能类改动的证据底线与 bisect 友好性
模型参与的改动最容易出问题的地方是性能声明，因为模型既能生成代码也能生成一段看着合理的性能描述。我们把性能证据的最低要求写成四项，缺一项就退回补充，不做”下次给”。
其一，基准集与工况要写全：测试用的负载形状、输入分布、并发或队列设置、硬件与内核侧的配置项。换一句工况描述，同一个改动的结论可以翻转。其二，多次采样与波动区间：单次运行的差值不能作为证据，要报告重复次数与离散程度，并说明差值是否落在波动之外。其三，回归对照：不只报告变快的场景，也报告可能变慢的场景，尤其是被牺牲掉的那条路径。其四，可复现脚本：给一条命令和预期产物，让评审方能自己跑一遍。
bisect 友好性要单独检查，它的判定标准很机械：
- 每个提交在检出后都能独立编译、独立跑过相关测试；
- 单个提交的改动面积有上限，超过就要拆分或者说明为何不能拆；
- 功能改动与格式改动、机械重命名不在同一提交里；
- 提交顺序不依赖后续提交才成立的中间状态，也就是不留”下一版修好”的窗口；
- 说明里写清这个提交如果被回滚，需要连带回滚哪些提交。
这几条对企业内部同样成立，而且比上游更容易满足，因为编译与测试环境是自己控的。
五、搬到企业内部：权限矩阵
底层库和公共组件的准入，在企业里不是靠自觉，是靠矩阵。我们给客户梳理这类规矩时，通常定四个问题。
谁能合入底层库：把”能合”与”能提”分开，模型产出的改动一律走提交流程，不因为生成快就走捷径。模型产出是否需二人评审：按影响半径分档，涉及并发、内存生命周期、外部接口与性能声明的改动要求二人评审，第二个人要明确对”这段改动为什么成立”负责，而不是点一个通过。性能声明由谁签字：性能数字必须是提交者以外的人复现过的，签字人写下自己用的工况。改动被回滚时由谁复盘：回滚不是终点，要回填一条”这个提交当初违反了四条里的哪一条”。
这张矩阵的关键在于它不问”这段代码是不是 AI 写的”，它问”这个提交能不能被 bisect、能不能被回滚、出了问题能不能归因”。三个问题答得上来，来源是什么都能被接受；答不上来，是人写的也接不住。
六、核心交付物：提交规范与证据清单
下面这张表是我们建议直接抄进团队规范的版本，左列是提交形态，右列是合入前必须具备的证据。
| 改动类型 | 提交粒度要求 | 模型参与的标注位置 | 必交证据 | 合入前动作 |
|---|---|---|---|---|
| 缺陷修复 | 一个缺陷一个提交，禁止合并无关修复 | 提交说明正文 | 复现用例、修复前后行为对照 | 单人评审，用例须可跑 |
| 性能改动 | 只改目标路径，格式改动另起提交 | 提交说明正文加结构化字段 | 基准集与工况、采样次数与波动、回归对照、可复现脚本 | 二人评审，第二人复现性能 |
| 接口与数据结构变更 | 变更点与调用方适配分列两个提交 | 提交说明正文，写清人改动的部分 | 兼容性说明、回滚顺序、受影响调用方清单 | 二人评审加负责人签字 |
| 机械重构 | 单次改动面积有上限 | 结构化字段，便于事后统计 | 编译与测试结果、无行为变化的判定依据 | 单人评审，抽查若干处 |
| 混合改动 | 未拆分不受理 | 不适用 | 不适用 | 退回拆分 |
标注位置那一列解决”知道该用什么强度读”，必交证据那一列解决”读完能判”。两列缺一，规矩就退化成一条道德要求。
洹拓这两年替客户改内部代码规范时，发现这套东西最难的地方不是写不出来，而是第一次执行时会拖慢合入速度，团队容易在压力下把它悄悄取消。所以我们建议先在性能类改动上强制，因为那一类的失败代价最高、证据要求最清晰，跑顺了再铺到其他类型。一个能被 bisect、能被回滚、能被归因的提交，才是模型参与底层代码的前提条件——顺序不能反过来，先有规矩，再谈参与。