让AI当同事不等人派活

有一位身为工程师的人, 做了一项极为大胆的实验, 其内容是让AI把自家App的日常维护工作给接管过来, 最近呢传来了相关消息, 看起来这条路好像确实是能够走得通的。Tag每天都会自动去运行例行的任务, 此任务覆盖了iOS、桌面端、Web、CLI以及Agent SDK这六个环境, 并且每条线都是独立去运行的, 其进展会自动汇总到频道顶层的一个线程当中。

它并非如同传统工具那般, 需你借助手动开展触发操作, 反而恰似一位名副其实的同事, 在到达规定时间之际, 自行开启上班模式, 主动寻觅问题所在、着手更改代码内容、提交PR申请, 然后悄然静候他人前来实施审查。按固定周期去发觉问题、递交通知做出修改、接纳反馈意见、再次进行调整规则, 如此这般的一个闭环流程, 已然在内部持续运行了数周时间。

崩溃App写修复PR

Tag的具体工作极为琐碎, 工程师要先于模拟器中将App打开, 而后进行一通杂乱无章的点击操作, 直至其崩溃方才停止, 接着需对崩溃原因予以定位, 再撰写修复代码, 随后提交PR, 并且每个PR都要附带复现步骤以及一张真值表。Boris在原始指令中特意着重强调, 运行起来的务必是真实的App, 绝不容许用假替身蒙混过关。

它除了要进行崩溃测试, 还得负责扫描代码库中那些模样相像但又并非完全相同的实现, 提出合并请求将它们合并为一个。最能考验功力的是处理“疑似跑不到的代码”, 对于静态分析能够确定跑不到的代码直接删除, 对于怀疑跑不到的代码先埋下日志观察一天, 确认真的没人走过之后再删除, 这可是只有老工程师才具备的手感。

全是没人愿干的脏活

清单上残留的活儿涵盖了清理各类随便怎么运作都顺利通过的测试, 找出那些时而正常时而出现问题的测试根源, 将全量上线开关在代码之中予以移除, 并且依据使用量来判定内部功能究竟是保留还是去除。这十一项工作, 任何一项都并非是去开展全新事物, 全部都是平日里最不乐意去做的, 做完之后也不会产生绩效, 即使拖到下个季度也不会有人催促的那类。

今年3月, Code公告给出过一个数字, 在过去的一年当中, 公司人均代码产出增长了二百个百分点, 代码审查因而成为了瓶颈。Faros AI于2026年发布报告, 在这两年里, 遥测覆盖了二万二千名开发者以及四千多个团队, 发现当AI采用度较高时, 人均epic完成量增长了六十六点二个百分点, 但是每周部署数却下降了十一点七个百分点。

产出涨了部署反而降

源于真实工作情形的数据显示, 其中人均所完成的epic数增长幅度为66.2%, 任务吞吐的增长幅度为33.7%, PR合并率的增长幅度为16.2%, 然而等待一个人进行审查的中位时长增长了441.5%, 并且存在31%的PR在未经过一次审查的情况下被合并进了主分支。这些数据所堆砌起来的便是开发者相应的一天, 即按一下按钮在五分钟内便可生成上千行代码, 写代码的那部分已然被AI予以取代, 而查看代码的部分依旧得靠开发者去完成。

Code是针对这个问题而构建的, 公开的数据表明在上线之前仅有16%的PR能够获取到具有实质意义的审查意见, 上线之后这一数据变为了54%。被工程师标记为找错了的发现比例不到1%, 审查一个PR平均需要花费跑20分钟的时间, 还要消耗掉15到25美元的token成本。

批准权永远在人手里

具有清晰边界的这套系统, AI能够主动找寻问题, 能够修改代码, 能够开启PR, 全程无需由人进行批准, 然而每一处的变更皆停留在PR之中, 是否合并进入主分支, 是否上线, 最后进行确认的必定是人。Boris于帖子里面写下了下一步的计划, 要设法降低机械性改动的合并成本, 卡点已然不在生成的那一端了。

系统搭建起来分成三个部分, Tag挂在Slack频道里, 当被@的时候会做出响应, 并且在权限以及指令允许的范围之内会主动接活, 8月13日刚进行过一次升级, 让它结合整个频道的上下文來判断何时该行动、何时该保持不动, 4月14日推出的功能支持在一次性配好提示词、代码仓库以及连接器之后按照时间表自动运行。