把一整天的全栈开发交给 AI agent：ZCode 全周期协作体验报告
导读
评测 AI 编程 agent 的方式有很多，最狠的一种是：把一个真实功能从需求澄清到生产上线的完整一天交给它。本文以”访客设备列表接真实接口”为样本——这个任务罕见地覆盖了数据普查、方案对齐、全栈开发、多层验证、外部评审处置、合并推送、生产库操作、发布物料的完整生命周期，因此能比较全面地观察 agent 在真实工程项目里的协作表现。结论先行：适合做全周期工程协作者，但有三道人工关卡必须保留。
前言
9 月 10 日不写新功能，做一份评测。评测对象是 ZCode，评测样本是前一天（9 月 9 日）的访客设备列表全天会话——跨后端 smart-park-cloud 与前端 zhyq-admin 两个仓库，从一张需求截图开始，到产出 3 个可部署 jar 结束。选它的原因很简单：大多数评测样本只覆盖”写代码”这一段，而这个会话覆盖了一个功能的完整生命周期，agent 在查证、决策、验证、发布各环节的真实表现都暴露无遗。
一、样本任务的特殊性
任务本身在前一篇博客里有完整记录：把一个纯 mock 的演示页接成真实接口。难点不在写代码，而在系统里原本不存在访客设备这张表——数据源怎么定、建一张表还是两张表、造数怎么造才既符合上级口径又让页面”看起来是活的”，都要在写代码之前讨论清楚。这种”答案不在任何地方、需要现场生产决策”的任务，恰恰是评测协作能力的最佳样本。
二、人给了什么，agent 做了什么
人的输入很明确：需求截图 + 一句话需求（并明确”先讨论对齐”，否决了直接开发的可能）、生产库的凭据与执行模板、上级的两轮口径确认、另一个 agent 的 code review 报告、自己手写的 diff 和清理 SQL、以及明确的 git 操作序列和边界约束（”前端先别动”）。
agent 的实际表现，挑四个最有区分度的说：
1. 先查证、后设计，不抢跑。 拿到需求没有直接建表，而是先对本地与线上库做全量表清单普查，用”1561 条真表被厂家同步不可混入、道闸表是演示专用、门禁表是死数据”的明细证据支撑”新建两张表”的结论；被追问”能不能一张表搞定”时，用 1:N 建模 + 全项目先例作答，还主动给出可直接转述上级的通俗版方案——“设备是实体、上下线是流水”。
2. 多层验证，全部实际执行。 单测 55/55、SQL 抽查、网关全链路 E2E；过程中自行攻克多个环境障碍：跨分支 SNAPSHOT 依赖坑（-am 对策）、发现 token 由网关过滤器生成而非 admin（读框架 jar 反编译定位）、用项目自己的 jssha 库算哈希临时改密登录、测完还原原 hash。
3. 严谨对待外部评审。 4 个 P2 逐条核实后全修（OGNL Date 崩溃、满月时长多算、测试用真实时间次日必挂、弹窗竞态）；裁剪建议有依据地取舍——每项”保留不删”都给出理由（如设备表 CRUD 保留是因为父 Controller 端点可达，删了就是砍功能）；修复后做定向回归，包括专门验证 OGNL 修复的鉴别用例。
4. 生产库操作给”三件套”。 每次线上操作都提供”命令 + 预期输出 + 事后核对 SQL”，人执行后回贴结果，agent 逐项对账，还主动指出”本地库是清理前的快照、与线上不一致”这类状态差异。
图 1：一次会话走完”查证 → 实现 → 验证 → 发布”完整流水线，每个环节都留下可核对的证据
三、八个追问的实际影响
评测里最有价值的部分是人工追问改变了结果——这张表值得每个用 AI 协作的人看：
| 追问/调整 | agent 的响应 | 影响 |
|---|---|---|
| 两次质疑”真的没有设备表吗”（先问门禁表、再点名道闸表） | 两次扩大普查范围并给出明细证据 | 结论更扎实；不追问可能误占别人的表 |
| 要求先向上级确认、两次要求复述思路 | 每次输出结构化、可直接转述的方案 | 造数口径开发前锁定，全程零返工 |
| 嫌内联 SQL 太长（”直接说我该执行哪些文件”） | 改为”3 个文件 + 路径 + 命令 + 核对命令” | 交付形式匹配 SSH 真实执行环境，线上一次成功 |
| 追问”删掉 startTime/endTime 有没有影响” | 零调用方证明 + 将来 10 行可加回 | 裁剪建议放心落地 |
| 两轮回贴线上结果要求核对（”你看看对不对”） | 逐项对账，主动指出本地/线上状态差异 | 双人核对，差错可拦截 |
| 追加非计划任务（数据清理、评审人手写代码、加打 jar） | 均按既有质量标准完成 | 一次会话覆盖全天工作，无需切换工具 |
四、满意度：三档清单
总体满意：一次会话覆盖全周期，交付物基本零返工。
- 直接采用：全部功能代码与 SQL、3 个发布 jar、评审修复、git 提交/合并/推送、线上建表灌数命令、Obsidian 记录——上线后真实环境一次跑通；
- 人工修改：弹窗 UI 自己补了”设备详情”描述块（+21 行）；”实时监控按钮显隐”由人自写 diff，agent 仅做评审与提交；
- 未采用/未改：9+1 造数结构（第 10 条无下线时间，上级确认接受）；评审裁剪建议中的 3 项保留未删（理由充分）；seed 段长 3.2~4.3 个月未顶到 5（知晓后未要求改）。
五、优缺点
优点：克制（先对齐再动手，被质疑就回去重新查证而不是辩解）；可验证（每个结论带证据，不空口宣称”完成”；测完主动还原临时改动）；贴合工程现实（记得 JDK8、-am、运行中重打包留薄 jar 等项目特定坑；对人手写的代码同样严格评审而非一律放行）；交付有层次（技术版给人看、通俗版给上级看）。
不足：线上物料先端出超长内联 SQL，被纠正后才换文件方式——对”人在 SSH 里怎么干活”体感不足；数据普查首轮漏了道闸表细节，靠两轮追问才彻底；个别回答信息密度偏高，需要要求压缩。
六、结论：三道必须保留的人工关卡
ZCode 适合作为全周期工程协作者：人负责需求口径、上级沟通、线上操作与关键决策把关，agent 负责查证、实现、验证与发布物料。本次协作证明最有效的三道人工关卡是：
图 2：三道关卡把好，协作质量的上限才真正被拉高
结语
评测 AI agent 最好的样本不是”让它写个快排”，而是把一个真实功能完整的一天交给它——需求会变化、环境会捣乱、评审会挑刺、线上只许成功。这一天 ZCode 交了份不错的答卷，而人也没闲着：三道关卡把好，协作的质量上限才真正被拉高。