企业官网建设流程全解析

最近我们组正式把 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 生成迁移 PR，CI 全绿，人工抽查通过，直接合入。整个过程不需要人改一行代码，但它依然在我的视野范围内运行。这让我相信存量工作是最容易无人管的，因为它的“正确”标准最客观。

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 下任务，最重要的一定是验收标准的边界。我后来把任务描述规范改成下面这种格式：

有了这样一张表之后，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 年之前单独放它上生产的。但那个方向，我相信。