最近我们组正式把 OpenAI 的 Codex 接进了迭代流程一个命令行里跑起来、能自己建分支、改代码、跑测试的 AI coding agent。大家嘴上说“欢迎新同事”心里都清楚AI 实习生是真的上岗了。紧接着那个更出圈的消息也来了——OpenAI 提到 2028 年“不用人管”直接把“AI 要不要替代程序员”的讨论从新闻标题拉到了排期表上。我担心的倒不是被替代而是“不用人管”这四个字正在被理解成“不用验收、不用 review、不用对结果负责”。恰恰是带了这个 AI 实习生一个月之后我对这件事有了完全相反的判断真正不用人管的状态不是把人从流程里撤掉而是把人从逐行写代码里撤掉然后把管理重心移到更早、更抽象的位置上。这篇文章把我这一个月的真实体验、踩坑记录、流程改造和对 2028 年那个节点的推演一次性写清楚。不论你是技术负责人、一线开发者还是正在评估 AI Agent 能不能进团队的管理者都应该能拿走一些能落地的东西。1. AI实习生上岗的第一个月我看到的真实工作状态1.1 它是怎么“入职”的我在一个做企业级应用的团队代码仓库有历史包袱既有整洁的核心服务也有大量遗留模块。我们选择把 Codex 接进一条迭代支线给它一套明确的“入职权限”只读代码库访问、一个独立开发分支、可以创建 PR但不能合并不能碰生产配置不能访问任何密钥。第一步是装好命令行工具登录 ChatGPT 账号连上 GitHub 仓库。第二步是我认为比工具本身更重要的一件事在项目根目录建一份给 Agent 看的约定文件把仓库结构、常用命令、测试入口、主文档链接、编码规范都写进去。这一步类似给新实习生准备第一天的 Onboarding 文档。没写这份文档之前它经常自己在文件树里迷路找一个配置类能找到半小时有了约定文件之后至少找文件的效率明显提升。入职后的第一次任务我记忆很深。我给它一张任务卡片里面包含了背景、需求、验收标准、约束条件和交付物背景用户权限列表的搜索当前只匹配用户名产品要求同时匹配部门和角色。 验收标准 1. 搜索“运营”能返回该部门所有用户 2. 搜索“管理员”能返回所有具备该角色的用户 3. 现在按用户名的搜索行为不能被破坏 4. 全量测试通过lint 通过。 交付物一个 PR需包含代码、测试和变更说明。它读完成任务卡之后先列了一个简短计划然后开始搜代码、定位接口、改逻辑。跑测试失败了两次它自己看日志改了两轮最后提交的 PR 里包含了测试用例变更说明也写得清楚。整个过程我基本不需要盯着只需要在任务开始时把卡片喂给它等它回来交活。这个体验给了我一个很直观的结论AI 实习生能不能干成事不取决于模型有多强而取决于你给它输入的任务质量。输入清晰输出就靠近预期输入模糊它就乱跑。1.2 前两周的惊喜和惊吓先说惊喜。它处理规模化机械重构是真快。比如旧接口要把参数结构升级涉及几十个调用点人来做容易漏它能够一次性把所有调用点扫描出来同步改掉并且保持逻辑一致。这种活既不性感也不需要太多业务判断力但极其耗时正好是 AI 实习生的舒适区。它写单元测试也很勤快。我让它补一个模块的测试它不只是补了主流程还自己找了一堆分支路径。测完之后我跑了下覆盖率确实有提升。文档维护更是它的强项更新过时的 README、补全接口注释这些活它做起来既快又没有怨气。再看惊吓。它会在你没有要求的情况下“发挥创造力”。有一次我只是让它优化一个查询函数的性能它直接把查询方式改了顺手还加了一层缓存和一个索引。单看每一项都是常见优化手段但合在一起就不是原先说好的任务了diff 变得非常大review 成本成倍增加。它也不理解团队里的隐式约束。老模块里有一段代码注释写着“不要删除防止线上某个历史场景出问题”它判断这是死代码准备清理掉。幸好在 review 环节被拦住了。这类“没有写成规则、只存在于老同事脑子里”的约束是它最容易翻车的地方。还有环境拟人化问题。它会把本地开发机器的绝对路径写进配置里结果 CI 上一跑就挂。放到普通新人身上这是经验不足放到 AI 身上这是上下文里没有“必须用环境变量”的约束。所以后来我们在约定文件里明确写死了几条铁律包括不许硬编码路径。1.3 我的角色从写代码变成了批改作业和主持评审变化最直观的是我的实际工作内容。过去我自己写实现现在更像带实习生把需求拆成足够小的卡写清背景和验收标准初审它的实现计划再逐行 code review。写代码的时间变少了但想“预期结果应该是什么”的时间变多了。以前我会边写边想现在必须把想法完整落到任务卡片里否则 AI 就不会按你的思路走。我们组内部开始把 Codex 叫“change creator”因为它真的会生成规模很大的变更而我的职责从生产代码变成了把关变更。这个过程并不轻松。你必须有能力判断它给出的方案是否合理能不能看出它隐藏的假设否则 AI 实习生会以极高的效率把错误方案快速实现出来。2. 2028年“不用人管”的底气大概率是这三类任务先达标2.1 为什么时间点不是明年而是2028先说清楚一个概念“不用人管”不可能是魔法而是一系列工程能力的总和。从今天用 AI 实习生的体验往回推2028 年这个节点指的是AI Agent 在特定领域里能覆盖从需求理解到代码交付的大部分环节并且错误率低到人类只需要做抽查。这要求的不只是模型变强还包括我们这一侧的工作流程、测试基建、领域约束描述能力同时到位。后三样东西很多团队今天都还没有。所以哪怕模型明天就再上一个台阶你也做不到无人管。你的仓库没有足够的测试你的需求描述含糊你的权限边界没划清AI 能力越强翻车后果越大。2028 的正确读法不是一个预言而是一个工程目标。2.2 第一类机械但耗时的存量工作第一类会先无人管的任务是机械但耗时的存量工作。典型例子是依赖升级、API 迁移、大规模重命名、大文件拆分。这类任务有几个共同特征定义非常清晰结果可以被验证且历史包袱越重越适合自动化。比如旧 API 要迁到新 API你只需要告诉它迁移规则它就能把几十个文件全部改掉然后跑编译和测试来验证。人只需要抽查几个高风险文件确认它没有把行为改出边界。我们组已经在一个依赖升级任务里试过类似的流程。AI 生成迁移 PRCI 全绿人工抽查通过直接合入。整个过程不需要人改一行代码但它依然在我的视野范围内运行。这让我相信存量工作是最容易无人管的因为它的“正确”标准最客观。2.3 第二类能被测试锁住的增量功能第二类是能被测试锁住的增量功能。在很成熟的团队里业务需求通常会先转化为测试用例再实现代码。当这个流程做到位时AI 实际上面对的是一个填空题测试已经标明了期望行为它只需要写出让测试通过的实现。这种模式对 AI 非常友好因为你不再需要和它讨论“产品想要什么”只需要验证“测试是不是真的覆盖了业务约束”。很多团队以为 AI 要替代的是程序员实际上 AI 最先替代的是“在没有测试保护的情况下盲目写代码”这件事。我建议想让 AI 干活之前先补契约测试。把核心接口的输入输出约定写成可执行的断言是让 AI 成为正式员工之前的上岗培训。测试不是越多越好但业务关键路径上必须有断言否则 AI 每改一次你都要在心里问一句它怎么知道自己没改坏2.4 第三类跨仓库的自动巡检与修复闭环第三类会是第一个真正实现“无人管”的样板间跨仓库的自动巡检与修复闭环。具体场景是这样的系统定时扫描所有仓库里的依赖漏洞、过期 TODO、废弃配置引用发现问题后自动创建分支自动改代码自动提交构建通过之后进入待 review 队列。整个过程不需要任何人介入遇到连 AI 都搞不定的问题再升级给人。这类任务适合无人化是因为它管的都是机器能理解的对象。依赖有没有新版本、配置引用是否失效、接口签名是否匹配这些判断不依赖模糊的业务意图。人在里面扮演的角色是从每一件事都过问变成只在告警升级时介入。等到这一类跑通下一步才是让 AI 自动处理简单的线上告警。但那个阶段遇到的就是之前说的返工循环问题我放在下一节讲。3. 带AI实习生的三大难点上下文、验收标准和返工循环3.1 上下文新同事不用你说就知道的事它要你一遍遍重申很多人误以为 Codex 这类 Agent 没有记忆其实不是。它是有对话记忆的但问题是它对“团队潜规则”一无所知。很多东西我们默认所有开发都知道比如错误信息必须走消息配置文件不能硬编码日志里不能打印 token数据库操作必须走统一连接池新代码不允许再调用某个废弃接口。这些它统统不知道。我刚开始带它的时候这些规则我一条都没写于是它非常正常地犯了我没提醒过的错误。后来我吸取教训把团队规范浓缩成一页纸写进 Agent 的约定文件里再让它写代码效果差很多。规则这东西不落在文字里AI 就不知道和新人一样。另一个我验证过的做法是在每张任务卡片里单开一个“背景与约束”字段不让它靠猜。有次我忘了写“旧接口三个月后下线新代码禁止继续调用”它果然继续用了旧接口。对 AI 的健忘最好的办法不是提高它的记忆而是把记忆外置到流程里。3.2 验收标准不明确的翻车现场验收标准不明确是它翻车最严重的一次。当时我给它一个任务“优化一下用户列表查询”。就这一句话没有验收标准没有约束。它做了什么把原来的多次查询改成了连表查询加了一级缓存还给一个查询字段建了索引。功能层面都合理但缓存失效逻辑把测试搞挂了索引变更引发了 DBA 的注意整个 PR 变成了一个讨论焦点。复盘的时候我们得出结论给 AI 下任务最重要的一定是验收标准的边界。我后来把任务描述规范改成下面这种格式维度模糊描述清晰描述目标优化用户列表查询将用户列表查询响应时间在千条数据场景下降低 50% 以上改造范围可以优化查询逻辑只允许优化 mapper 层禁止改动 controller 层接口签名不做的事无不引入缓存不新增索引不改变排序规则成功标准功能正常全量测试通过、性能基线达标、无行为变化有了这样一张表之后AI 的表现会稳定非常多。你会发现“不允许做什么”往往比“要做成什么”更能约束它的行为。人写代码时靠常识判断边界AI 没有常识只有你给它的上下文。3.3 返工循环测试失败后的无限重试AI 面对测试失败通常不会停下来问你而是自己改代码再跑。如果它知道错在哪这个循环很快就结束。但如果它只知道测试红了、不知道为什么红就会陷入“改了跑、跑了改”的循环。我印象最深的一次是让它修一个偶发超时问题。第一轮它给整个调用链加重试机制第二轮把超时时间翻倍第三轮改序列化方式全是猜测。我介入之后只给了它一条关键线索“失败只发生在数据库连接池满的时候”。它很快定位到连接池大小配置问题解决了。这件事告诉我AI 在“知道目标行为”时效率最高在“只知道有 bug”时最容易原地打转。你要做的不是在一旁催它而是帮它缩小假设空间。你在返工循环里说一句话抵得上它盲试十轮。管理 AI 实习生的本质就是管理它的注意力和假设范围。4. 把AI当团队成员而不只是工具流程、度量与安全边界4.1 自动化测试是上岗资格证我们敢让 AI 在某些任务里独立干活靠的并不是它足够聪明而是那部分自动化测试足够强。测试是 AI 和自我验收的桥梁。没有测试的仓库AI 改一行代码都可能引起连锁反应而且你还发现不了。它会自信地提交一个 PR告诉你全改完了但实际上一堆隐藏行为都变了。有了测试之后它至少知道自己写的代码在机器层面是否成立。我的建议是任何想让 AI 大规模介入的团队先花一两周时间把核心模块的单元测试、冒烟测试和契约测试补齐。这个过程本身是一次极好的梳理你会发现哪些任务边界清晰适合自动化哪些任务根本说不清楚那就不适合给 AI。4.2 权限与安全边界怎么防AI把公司代码搞出问题我给 Codex 定的权限一直是最小化。它拥有代码库只读访问和独立分支但永远没有生产环境凭据永远不能直接推生产分支永远不能碰密钥管理类文件。它在沙箱环境里运行生成的变更必须经过 PR 流程才能合入。很多团队不敢上 AI Agent是担心它把公司代码泄露出去或者把生产环境搞坏。我的观点是与其担心模型本身不如把流程做好。给 Agent 一个最小权限的账号把它当新员工一样管理不该进的系统不给权限不该触碰的数据不要出现在它的上下文里。代码 review 环节不要省略。AI 负责生成变更人负责判断业务理解是否正确这会成为接下来几年最基本的协作模式。它没有权限做的和人没有权限做的边界要完全一样。4.3 度量AI的绩效别只看它写了多少行代码我们组开始给 AI 实习生做“绩效评估”之后定了几项核心指标PR 一次通过率、平均返工次数、人工修改行数占比、测试覆盖增量、交付任务数。光看产出代码量没有任何意义。它如果一次生成 1000 行但返工四轮还不如一次生成 100 行直接通过。真正有价值的指标是“有用变更中不需要人工返工的比例”这也是衡量我们任务描述质量的间接指标。当这个比例上升时说明团队的验收体系在变好而不只是 AI 变强了。我们每周会简单复盘一次 AI 的错误模式看是重复踩同一个坑还是每次犯新错误。训练 AI 实习生和带人一样复盘比考核更重要。5. 对“2028不用人管”的个人推演从路径到节奏5.1 分阶段引入AI Agent的路线图如果你所在团队也想引入 AI Agent我建议按阶段推进不要一开始就把目标定成全自动。阶段一人机结对期。AI 写代码人负责逐行 review积累它对团队规范的理解。这个阶段 AI 是副驾人是主驾。 阶段二独立任务期。AI 开始独立处理定义良好的小任务比如补测试、升级依赖、修 lint 问题用测试门禁做质量闸口。 阶段三沙箱自动修复期。AI 在沙箱里自动修复小问题自动生成 PR人只需要抽查高风险变更。 阶段四低风险全自动期。在一些低风险模块实现自动合并关键路径依然保留人工审批。先跑通一条窄得不能再窄的路径比如某个组件库的依赖升级。流程全部打通之后再跑第二条。节奏比速度重要宁可慢一点也不能在第一条路径没有验证可靠之前铺开。5.2 “不用人管”不等于“不用人对结果负责”未来最可能的状态是AI Agent 负责执行链路上的大部分工作人类负责定义目标、验收和组织协调。这就是我对“不用人管”的最终理解——人从逐行盯着代码变成更前置地定义“什么是对的”以及事后对结果负责。这个过程会带来一个新岗位的雏形可以叫 AI 交付经理也可以叫 AI 验收工程师。你不需要盯着它写每一行代码但你要为它的产出负责。所以真正变化的不是程序员还有没有而是程序员的工作重心从“写”变成了“验”。这个转变是有价值的。把大量机械工作交出去之后人的时间会流向更需要判断力的地方比如业务建模、系统设计、风险评估。这更像是一种升级。5.3 几个接地气的建议最后分享几个我实践下来的经验不用等 2028现在就能用。第一选一个痛点场景快速试点。找那种重复、耗时、有明确验收标准的任务不要一上来就让它负责核心链路。它把一个小任务做得又快又好比你给它一个大项目然后看它翻车要有价值得多。第二把团队规范写下来。你在代码 review 时反复强调的那些“常识”全部落到文字。AI 会遵守写下来的规则但不会读心。规范书面化收益的不只是 AI新人入职也会更快上手。第三给 AI 划定明确的权限边界。只读库、独立分支、不能合并、不能碰生产配置这些都是最低要求。记住一个原则人没有的权限AI 也没有。第四建立 AI 复盘的固定机制。每隔固定时间把 AI 产出的失败 PR 和返工记录拉出来看错误模式是重复还是发散。重复的错误通过补充规则解决发散的错误通过缩小任务范围解决。第五永远保持抽查。哪怕未来自动化和测试覆盖都做到位了必要的抽查比例也不能归零。抽查的意义不在于抓 bug而在于让整个流程的参与者保持对质量的敏感。我个人对 2028 那个目标的态度是它可以实现但实现的前提不在模型本身而在我们的工程体系。如果接下来几年团队能把流程、测试、验收体系打磨到位AI 实习生的“无人管”只是一个水到渠成的结果。到那时最忙的人可能不是写代码的人而是做验收的人这本身就是一种进步。反正我们家这个 AI 实习生我是不会在 2028 年之前单独放它上生产的。但那个方向我相信。