AI Agent开始跑验收了:企业软件别再手动点功能清单-夜雨聆风

AI Agent开始跑验收了:企业软件别再手动点功能清单

企业软件验收，不能只看功能清单，还要看真实流程能不能跑通。

让 Codex 扮演一线员工，先把隐患闭环、材料进场、台账生成跑一遍。它卡住的地方，往往就是需求、字段、权限和验收标准要重做的地方。

想象一个很普通的现场：安全员早上 7 点发现脚手架边少了一块挡板，拍照上传，派给班组长整改。班组长补了照片，安全员复查通过，项目经理下午看大屏，发现隐患数量、整改时长、责任班组都已经同步。

如果验收只看“新增隐患”按钮能不能点，这套系统大概率能过。但真正上线以后，问题常常藏在后面：照片上传了，复查页看不到原图；责任班组没有现场真实班组；整改完成了，大屏统计第二天才更新。

AI Agent 的价值，不是替人点按钮，而是在签字前替项目跑一遍真实流程。

过去验收像对功能清单打勾。现在有了 AI Agent，企业软件应该多一个动作：让 Agent 扮演一线人员，把业务从头到尾走一遍。

让 Agent 先跑真实流程，很多卡点会比上线后更早暴露。

两个信号：AI 已经开始跑真实流程

第一个信号是 WebTestPilot。它的论文在 2026 年 2 月 12 日发布，4 月 23 日修订。简单说，它不是 Codex 的 skill，也不是成熟商业软件，而是一个研究原型：让 Agent 读取需求、用户故事、技术设计和测试计划，再到网页里按步骤执行。

论文里的例子很具体：从空购物车开始，点击继续购物，搜索 camera，进入商品详情，把商品加入购物车。普通自动化测试可能看到页面跳转成功就过了；WebTestPilot 会继续检查购物车里的商品、数量、价格、小计，是否和前面选择的一致。

它的结论也值得看：研究团队用 4 个真实 Web 应用构造了 110 个注入 bug 的基准，任务完成率达到 99%，bug 检测的 precision 和 recall 都是 96%。在一个真实无代码平台开发过程中，它还发现了 8 个 bug，类型包括数据绑定、UI 和页面导航。

真正要测的不是按钮，而是数据有没有沿着业务链条正确流转。

第二个信号来自微软。2026 年 7 月 1 日，一篇关于微软内部使用命令行 coding agent 的研究公开，观察窗口是 2026 年 1 月 5 日到 4 月 29 日，样本是数万名工程师。

这项研究不是让工程师做一次实验室任务，而是看真实工作数据：谁开始使用 Claude Code 或 GitHub Copilot CLI，谁在 14 天内至少用了 5 天，合并 PR 数有没有变化。为了避免“本来厉害的人更爱用工具”的偏差，研究还做了反事实对照和同一工程师的前后比较。

结论不能简单翻译成“人效提升 24%”，但它说明了一件事：Agent 不是只会写漂亮回答，它已经能进入真实工程链路，并带来可观察的交付变化。

微软的研究用真实 PR 数据做对照，重点不是口号，而是工程链路里有没有变化。

对企业软件验收来说，启发很直接：不要只问 AI 能不能写文档，要问它能不能按真实业务跑出证据。

企业软件验收，怎么落地？

从下一个项目开始，不需要把验收流程推倒重来。只要在正式签字前，加一轮“AI 跑流程”。这轮不替代甲方、监理、项目经理的判断，只负责提前暴露卡点。

第一步：准备真实材料包

不要只给功能清单。功能清单会让 AI 只盯着按钮；真实材料包才会让它理解业务。

先把需求、原型、账号和历史问题整理成真实材料包，再让 AI 跑验收。

材料至少包括：需求说明、原型地址、流程图、字段字典、角色权限、测试账号、几条真实业务单据、历史问题单。网页系统可以让 Codex 打开测试环境；涉及登录、桌面软件或复杂页面操作，就用更接近真实操作环境的浏览器或 Computer Use。测试账号只放测试数据，敏感账号不要丢进去。

第二步：让 Codex 扮演真实用户

任务不要写成“检查系统是否正常”。要写成一个具体角色和一条具体流程。

现场隐患闭环最怕的不是按钮少，而是责任链条断在中间。

比如这样写：请你扮演施工现场安全员，在测试系统里完成一次“发现隐患、拍照上传、派发整改、复查关闭、生成台账”的完整流程。不要只判断按钮能不能点，要记录每一步为什么犹豫、哪个字段不理解、哪个动作重复、哪个异常没有入口。

AI 可以生成隐患描述，但停工、责任和复查，仍然需要清晰流程承接。

如果 Codex 跑到这里卡住，问题通常不是系统少了一个 AI 按钮，而是责任链条没有设计清楚。好系统应该把照片、位置、历史同类隐患自动带出来，把真正需要人判断的几项亮出来。

第三步：把卡点写成证据

卡点报告不要写成“体验一般”。这种话没有人能改，也没有人愿意认。

卡点报告要写清：卡在哪一步、影响谁、证据是什么、建议怎么改。

更好的写法是五列：卡在哪一步、系统要求我做什么、我为什么不确定、这会影响谁、建议怎么改。项目经理、产品经理、开发商、业主看到这五列，才能把问题往前推。

材料进场就是典型例子。一车钢筋到现场，材料员有送货单，质检员要看规格型号，监理等着签字，塔吊还在排队卸货。如果系统让 Codex 分别在采购系统填“到货数量”、项目系统填“进场数量”、资料系统填“验收批次”，它当然可以复制粘贴，而且比人快。

但问题没有消失：同一批材料为什么要填三遍？吨、根、批之间怎么换算？炉批号识别错了以后，三个系统会不会一起错？

第四步：把卡点变成验收条款

真正有价值的验收，不是打勾，而是把卡点改成可验证的条款。

把抽象验收要求拆成可执行、可复现、可追溯的检查项。

不要再写“支持隐患新增”“支持整改闭环”这种很虚的句子。要写成可验证的任务结果：安全员在移动端新增一条隐患，拍照、定位、选择责任班组、指定期限、派发整改，常规场景 2 分钟内完成；必须字段不超过 6 个；无法确定责任班组时，必须有“待确认”入口。

对开发商来说，这件事也很有用。很多返工不是开发能力不行，而是需求签字时没有暴露真实流程。客户说要需求 A，系统做完以后，现场用了两天才发现需求 B 更合理。过去只能靠咨询顾问提前判断，现在至少可以在签字前多跑一轮：让 Codex 读需求、看原型、模拟角色、输出卡点。

最后，先别急着问能不能接 AI

以后做智慧施工、智慧交通、智慧建造，或者企业内部管理系统，都可以增加一个朴素动作：让 Codex 跑一遍真实流程。

它卡住的地方，就是需求没说清楚的地方；它反复确认的地方，就是责任没有定义好的地方；它需要复制粘贴的地方，就是系统还没有真正打通的地方；它一路跑完但台账没人敢用的地方，就是业务闭环还没有成立的地方。

下一代企业软件，不是全自动，而是让人能顺手干、AI 能接得住。

最后别急着问“我们的系统能不能接 AI”。先问一个更具体的问题：让 Codex 按一线人员的真实任务跑一遍，它能不能跑通？如果跑不通，先别怪 AI。那很可能是系统本身，还没有把业务想明白。

参考资料

WebTestPilot paper：https://arxiv.org/abs/2602.11724

Microsoft CLI Coding Agents Study：https://arxiv.org/abs/2607.01418

OpenAI Codex Overview：https://developers.openai.com/codex/overview

OpenAI Codex Browser Use：https://developers.openai.com/codex/app/browser

OpenAI Codex Computer Use：https://developers.openai.com/codex/app/computer-use