6600次提交听起来像是某种个人极限运动。我最近把一个开源框架项目的提交历史从头到尾翻了不止一遍越翻越觉得不对劲凌晨三点和周末反而迎来提交高峰单次改动不到五十行的小提交占比高得吓人commit message 却几乎全部遵守同一套规范。我确认之后发现这背后根本不是“一个人打字速度的极限”而是代码协作范式在发生变化。这位开发者圈内一般叫他老P长期深耕iOS底层工具链认识他的人都清楚以前他的提交习惯跟现在完全是两回事。用6600次提交作为样本去观察能看到一种很清晰的AI原生开发范式人类只负责定义意图和边界剩下的大量实现细节交给AI代理去执行、迭代、提交再由人来审查签收。这篇文章就把我从中拆出来的东西完整写一遍适合任何正在尝试或准备尝试“代理工程”的开发者。1. 从提交曲线看代理的“时间指纹”这堆提交不像人写的1.1 提交频率曲线代理不休息人也用不着硬撑把老P项目的提交记录按时间拉出来第一眼最反常的是频率曲线。普通开发者正常的提交节奏基本跟着工作作息走周一到周五活跃周末稀稀拉拉夜里偶尔灵感爆发也会留下几条。老P前期的提交记录确实是这个形态但从某一段时间开始曲线完全变了样工作日的白天反而平稳凌晨三点到六点却隔三差五蹦出一串提交周末的活跃度甚至比大多数人的工作日还高。我按UTC8时区把所有提交时间点统计了一下2024年之前周末提交占比大概18%到2025年直接跳到32%以上。高峰期单日提交次数稳定超过二十次有一阵子甚至单日逼近四十次。一个人肉开发者不可能长期保持这种节奏这也不是什么拼命的“自律程序员”能做到的。更合理的解释是提交主体变了。AI代理没有上下班概念任务拆成一步一步后它会一直执行下去每完成一个中间步骤就提交一次直到跑完整个任务、测试全绿为止。这条曲线就像代理的“时间指纹”几乎一眼就能识别出来。1.2 commit message 里的机械痕迹提交信息也很能说明问题。人写提交信息的时候难免带点随意性心情好写“fix stuff”赶时间就干脆“xx”。老P后段的提交记录完全不是这个画风几乎每条都以“feat:”“fix:”“refactor:”“perf:”之类的结构化前缀开头后面跟一句连主语带动作的完整描述再往下甚至能看到关联Issue编号和测试结果摘要。这不是人类靠自律能做到的程度老P自己以前也没这个习惯。后来他在项目文档里明确写了提交信息规范并且把规范喂给了代理。代理执行完改动之后会按照模板生成一条格式完全正确的提交信息包括改动模块、影响范围、测试结论。6600次提交里相当一部分commit message后面还带着“agent”类的自动生成标记这跟平台自动生成的PR描述结构完全对得上。对任何做提交历史分析的人来说这类标记就是代理活动的直接证据。1.3 小步提交占比剧增带来的信号传统开发里一次提交通常改动一两百行起步有的人甚至习惯把一个周末的成果攒成一个巨型提交。老P早期的提交历史也是这个形态。但后段的统计完全不同单次提交低于五十行的小改动占比接近一半而且这些提交大部分只动一个文件。这种颗粒度变化背后是代理的工作方式决定的。代理在执行任务时会把目标切成很多小步骤改完一处代码立即编译、看见编译过了就提交接着再动下一个点。于是代码库的提交历史变得非常细碎但好处也很明显——每一个提交都容易回滚diff小审查者不用一次性接收几百行改动冲突概率也低。代价是提交噪音变大项目里的哈希值数量爆炸式增长。这一趋势我建议任何准备上代理工程的人提前做好心理建设提交数量会明显上涨如果你还在用“提交少等于干活快”的老标准看问题会非常不适应。2. 代理工程一日流程一个真实重构任务从Issue到合并的完整拆解2.1 “代理”不等于“补全”任务级与行级的本质差异很多刚接触AI编程的人把“用AI写代码”理解成输入Prompt然后复制粘贴或者更轻一点在编辑器里让AI自动补全下一行。这类用法本质上还是把AI当成一个高速打字机人依旧是每次改动的决策者。代理工程不一样它的最小协作单位不是“行”而是“任务”。老P的工作流里代理拿到的不再是“帮我写一个函数”这种局部指令而是“这个模块存在一个循环引用请定位并修复要求现有单元测试全部通过禁止改动公开接口”。代理会自己读代码、定位问题、调整实现、编译、跑测试测试挂了就分析报错然后继续改直到全部通过最后创建一条Pull Request把改动递回给人。这里人和AI之间的关系从“我操作工具”变成了“我布置工作给自动化执行者”这就是代理工程和传统AI补全的分水岭也是标题里所谓“革命”最核心的部分。2.2 从Issue到合并一次代理任务的完整生命周期我在老P的提交历史里随便挑了一个重构任务对照Issue记录把它的完整路径还原了出来整个过程可以分成四步。第一步是意图定义。老P不会直接说“修一下循环引用”而是把任务拆成结构化描述目标、涉及文件、预期的行为变化、禁止改动的范围、验收标准。他会明确写“只允许动A和B两个目录不要顺手格式化别的文件”这是代理高效工作的前提。第二步是代理执行。代理在临时分支上开始干活先尝试编译现状再检索相关类然后生成第一批diff自己跑一遍相关测试。这一步经常反复第一次改完测试没过代理读报错信息定位到自己忽略的依赖关系再改再跑。第三步是生成PR。测试全绿之后代理自动填充PR模板列出变更文件、改动摘要、自测过程和影响范围。第四步是人工审查。老P打开PR看关键diff确认代理没碰禁止区域测试确实覆盖了新逻辑然后合并。这个流程里最有价值的细节是代理不会在同一个任务里无限自由发挥。它每完成一个中间步骤就提交一次方便人类审查任何一个节点也方便出问题时的定点回滚。老P在实践里验证过这种“小步代理循环”比让AI一次性生成完整重构稳定得多。2.3 工具链不一定很复杂一个最小可用的代理执行脚本很多团队一听代理工程就有畏难情绪觉得肯定要上很强的AI平台或自建编排系统。老P早期给出的方案很简单一个几百行的命令行脚本外加某对话大模型API就能把基本流程跑通。脚本核心逻辑大概是下面这个流程# 简化版代理执行脚本任务 - 分支 - 循环改 - 提交 - 建PR agent_run() { local task$1 local branchagent/task-$(date %s) git checkout -b $branch while ! verify_change $task; do propose_change $task # 调用大模型API生成改动方案 apply_and_test # 应用改动跑编译与单元测试 done git commit -m $(generate_commit_msg) git push origin $branch create_pull_request $branch # 在代码托管平台创建PR }verify_change是门禁函数里面会检查编译是否通过、测试覆盖率有没有下降、是否触碰了禁止改动列表。这个脚本在真实环境里跑得通说明代理工程的技术门槛没有想象中高。真正复杂的不是脚本本身而是你给代理定义的那套边界规则。3. 范式切换的文本证据提交信息、Pull Request与代码审查模式的变迁3.1 开发者的身份从“写代码的人”变成了“架构师和评审员”6600次提交的统计结果里老P自己直接产出的提交只占不到四分之一。但如果你以为他是在“偷懒”那就完全理解反了。他的工作量没有减少只是从“把代码写出来”转移到了“决定代理该写什么、写成什么样才算对”上。面对一个跨模块的重构任务代理可能会生成好几版方案。老P不会照单全收他会先读依赖关系判断哪一版改动对现有架构侵入最小然后让代理按这一版方向继续细化。以前亲手写代码时很多架构上的判断是在打字过程中自然发生的现在他必须把架构意图写得足够清楚代理才知道该往哪个方向走。换句话说代理工程把开发者的核心能力从“手写实现”逼到了“精确意图表达和方案取舍”上。写代码的手感当然还有用但它不再是唯一的价值出口。3.2 Review纪律反而更重了不是放手而是更细致的验收代理能自动生成非常漂亮的PR描述这给很多初学者造成一个错觉既然AI已经自测过了我合并就行。老P恰恰相反代理上线之后他的代码审查纪律比以前更严格了。6600次提交的记录里代理创建的PR被驳回的并不少驳回理由集中在改了不该改的公共API、擅自重排了模块依赖、新增了不必要的外部调用这几类。他因此专门维护了一份AGENTS.md规则文件让代理在开工之前必须读取# 代理任务规则示例 - 只允许修改 issue 指定的模块 - 禁止改动公共API签名 - 每项改动必须附带对应单元测试 - 无法在两次尝试内解决的疑问必须停止并请求人工确认 - 不允许顺手格式化无关文件人的角色从“每一行都亲自写”变成“对代理的每一步变更负责签收”。这条路绕不开一个事实代理提高了代码产出速度但代码质量的下限最终还是由人的审查质量决定的。想让代理有更好的表现先把审查纪律立住这是我看完这批提交记录后最直接的感觉。3.3 提交承载的信息结构升级了传统项目的提交信息五花八门但到老P这个项目后期提交记录呈现出非常稳定的信息结构。每一条提交都承载了四个层次的信息改动模块、改动原因、验证结果、关联任务编号。PR描述里还会自动附上“测试通过/失败”“影响文件列表”“是否触碰边界外代码”等内容。我用一张表直观对比一下传统开发与AI原生开发的提交特征差异维度传统人工提交AI原生提交提交信息常有口语化、随意性结构化前缀影响描述验证信息变更规模偶有巨型提交小步、单模块、低风险PR描述经常留白自动生成摘要、自测结果、影响范围失败回滚依赖个人记忆提交记录天然形成恢复路径这样的信息结构带来的实际收益是整个项目的可回溯性变强了。任何一次线上问题都能沿着提交记录快速定位到对应的代理任务和当时的人工审查记录。对维护期长的项目来说这个收益甚至比代码产出速度更重要。4. 让代理敢改代码的工程底座模块化、测试与CI三者缺一不可4.1 模块化是代理能下脚的前提代理再聪明也不可能一口气读完整套大型iOS工程的几十万行代码。它每次干活只能拿到和当前任务相关的局部上下文。老P项目里代理能稳定产出一个很重要的前提是前期把代码拆成了很多边界清晰的独立模块依赖关系按层收束模块之间不允许随意跨越。回头看那6600次提交最前面那几百次几乎是同一个主题模块边界整理、依赖方向调整、公共API收敛。没有这些铺垫后面几千次代理提交根本跑不起来。这给所有想复刻这条路线的人一个清晰信号模块化不只是架构洁癖而是代理工程能运转的物理条件。你给代理留的上下文越窄它犯错的概率就越低.4.2 代理敢改代码是因为测试兜住了底线老P项目里有一条硬性规则代理提交的每个改动必须伴随对应方向的单元测试。没有测试的改动直接打回。代理自己对这条规则执行得相当机械它会在每次改动后跑一遍相关测试测试没过就继续修直到全绿才进入提交阶段。这里要给个提醒把“测试通过”当成“代码绝对正确”是危险的。代理的测试是它自己写的存在质量水分。老P的做法是人工审查时必须看测试是否真能覆盖新逻辑而不是看测试有没有通过。测试真正的价值在于给代理一个低成本试错回路代理尝试一个方案测试立刻告诉它错了它就能进入自愈循环。没有这个回路代理的自由发挥就会变成灾难。4.3 CI变快代理才敢高频迭代引入代理之后提交数量成倍上涨如果每次提交都要全量编译一遍大型iOS工程等待时间会变成最可怕的效率杀手。代理和人不一样它不会因为等得无聊去刷会儿手机但等待会让整个自动循环变得极其低效。老P做了三件事增量编译缓存、测试分片、按文件变更范围触发的CI矩阵。他把一次全量编译从八九分钟压到两分钟出头代理的尝试次数立刻肉眼可见地上涨。这中间的道理很朴素反馈回路越短代理就越敢试错。如果你想上代理工程先别急着买更多模型额度优先把CI反馈速度搞上去性价比高得多。4.4 提交纪律代理没有任何权限直接触碰主分支代理能把代码改成什么样关键不在能力边界而在权限边界。老P项目里的规则很死所有代理提交必须走临时分支和PR哪怕只是改了一个README文件。主分支对代理完全只读只有人能合并。这条纪律把代理可能造成的破坏范围限制在了一个可审查、可回滚的隔离区里。他还做了另一层更细的管控代理使用的令牌只有仓库读写权限没有发布权限、没有证书权限。一旦代理生成的改动经过人工审查合并进主干后续的发布流程只能由人触发。这套最小权限原则放在代理工程里重要性比普通CI权限管理还要高一个量级。5. 自我修复与非理性繁荣提交历史里的翻车现场与边界案例5.1 代理会一本正经地调用不存在的API翻提交记录时能看到一类很典型的分支一连串提交信息里前几条都在修编译错误后一条才真正落地功能。比如代理引入了一个自己记忆中的系统调用结果编译直接报错它灰溜溜地再发一次补丁把调用换成正确版本。这个画面非常经典我称之为“代理的无知者无畏”。代理的“自愈循环”机制会让它最终走上正确路径因为它会反复调试直到测试通过。但这背后的代价是额外提交数和噪音变多。老P对这种问题的主要对策不是禁止代理犯错——那等于不用代理而是把任务范围缩到足够小让代理即便犯错也能在有限的几轮内自我纠偏。你指望代理一次写出零缺陷代码不如接受它是个需要跑几轮才能走稳的新人。5.2 上下文窗口是绕不开的天花板代理的另一个翻车高发场景是跨模块全局重构。它一次只能看到和任务相关的局部文件如果改动牵涉一个模块改了调用方却没改或者依赖链条中间断掉了就会出现改一半丢一半的状态。这类翻车的提交历史特征是功能提交之后很快跟了一条回滚提交把刚才的变更整个撤掉。老P的解法听起来甚至有点笨把全局重构拆成多个有依赖顺序的小任务一次只让代理动一块每块独立提交、独立测试、独立合并。这样代理每一轮面对的上下文控制在一个能完全覆盖的范围里虽然流程变长了但稳定性显著提升。别跟上下文窗口硬刚这是我从这条记录里学到的最大经验。5.3 隐式契约代码库里那些“不说破”的规矩大型项目里总有一些约定俗成的东西文档不会写新人要踩几次坑才知道。比如某些类不能从外部直接初始化某些目录属于历史遗留不能动某些配置项只能读不能改。代理读再多次代码也不一定能意识到这些隐式契约的存在于是擅自“改进”就是高风险行为。老P的办法是把这些约定全部显式写进AGENTS.md和禁止改动列表里。不是“建议不要改”而是“明确的禁止”。即使这样6600次提交里仍然有大约2%的提交属于补救性质的“回滚上一次代理提交”。这个比例单独看不高但放在几千次代理提交的基数上意味着团队必须保留回滚机制和人工兜底的能力绝对不能把代理的输出当作最终答案。5.4 权限最小化代理不应该被信任到能发布代理能高效地改代码也意味着它掌握了很强的代码库操作能力。如果它的权限范围过度放大一旦出现错误的任务理解损失就可能从一次糟糕的合并放大到整个发布链路出问题。老P对代理的权限设计严格遵循一条底线代理可以写分支、可以推PR、可以跑CI但绝对不持有任何发布环节涉及的凭证。这条边界被很多人忽略。我见过不少团队把AI的开发权限和发布权限混在一起管理这在人工时代都不够稳妥到了代理时代风险更高。代理工程的真谛不是把控制权全量交给AI而是通过精心设计的边界把它强大的产出能力约束在一个人类随时可以拉闸的“安全区”里。这跟“信任”没关系这是一套权限架构问题。6. 从老P的实践到普通团队代理工程的四个阶段与可复制清单6.1 渐进路线图不要上来就让代理动核心架构老P的经验很明确代理工程不适合一步到位。我基于他的实践和其他团队的落地情况整理出一条四阶段路线团队可以根据自身情况选择起点。第一阶段人写代码AI做代码审查和单测生成。这个阶段AI不直接改代码而是给人当“挑刺的同事”让团队先熟悉AI输出的规律和偏差。第二阶段让AI在独立分支上完成某个小型重构人负责审查合并。这个阶段开始建立信任感积累让代理在特定模块内干活的规则。第三阶段允许AI在受保护分支外开代理型PR并把AGENTS.md规则体系固定下来。第四阶段把代理纳入常态开发流程配上自动化门禁和权限隔离形成一个稳定的“意图-执行-审查”闭环。6.2 给代理写一份“岗位说明书”代理工程能不能跑顺很大程度上取决于你有没有把要做的事说清楚。围绕老P的经验我整理出一个可以借鉴的任务模板直接用在你自己的项目里任务目标描述代理需要达成的结果不要只写动作 影响范围允许修改的目录、文件、模块 禁止事项公共API、锁定文件、生成代码、无关格式调整 验收标准编译通过、目标测试通过、不做降级式hack 失败处理最多尝试N次无法解决则停止并等待人工介入一份好的“代理岗位说明书”能大幅降低代理犯错的概率。很多刚开始尝试的人习惯给代理甩一句话“帮我重构一下”回报往往是一堆乱七八糟的改动。把目标、范围、边界、验收标准写清楚代理的行为才能真正可控。6.3 五个最容易犯的错第一一上来就让代理动核心架构。代理工程的真前提是代码库边界足够清晰核心架构不在它的“受信范围”内。第二没有测试就让代理自由发挥。代理没有测试回路就只能靠阅读和猜出错率会高到人失去耐心。第三把多个目标混在一条指令里。代理每一步只能确认一个变化目标一多就会顾此失彼。第四取消人工Review。代理生成的代码自动合并相当于把验收责任推给了运气。第五权限开太大。越多的令牌权限意味着越大的风险面代理工程里必须坚持最小权限。6.4 一个真正务实的落地起点如果你看完这篇文章只想做一件事我建议从建立AGENTS.md开始。它不需要一开始就完美哪怕只是写清楚“这个仓库的公共API能不能动、测试怎么跑、哪些文件禁止修改”都会让后续接进来的AI代理表现完全不一样。我自己在别的项目里试过类似做法最有效的一步是要求代理在每次提交说明里附上“为什么这样改”的简述。这行字看起来琐碎但它逼着代理把思路外显出来也逼着我在审查时真正理解改动意图而不是草草点个通过。过了段时间我再翻提交记录几乎所有改动都能在几分钟内搞清楚来龙去脉。这种可回溯性是我认为代理工程除了效率之外最值得长期投入的回报。老P的6600次提交验证了这条路可行剩下的问题只是从你的项目里第一份AGENTS.md开始。