用Agent评测思路管理AI Coding —— 31万行代码AI重构的实践
编译摘要
1. 浓缩
核心结论1 : 管理 AI Coding 的底层逻辑与评测 Agent 相同：先完成人与人的标准对齐，再把标准固化为 AI 可执行的 Rule、Skill 和 SOP。
关键证据: 团队有 90%+ 代码由 AI 生成，成员背景差异又大；如果每个人各自用 AI Coding，系统会被不同风格、不同抽象、不同边界判断快速拉散。团队先确定分层、领域模型、repository 层等共识，再把这些共识写入 always-loaded AI Rules 和领域边界 Skill，避免把“未对齐的人类判断”放大成“自动化混乱”。
核心结论2 : AI 改写了工程经验的价值边界：经验不再主要是“能看全代码”，而是“能判断哪些问题重要、哪些风险必须先处理”。
关键证据: 作者团队在 31 万行复杂 Agent 评测系统中，借助 AI 很快扫出 10 个隐藏较深的性能问题；过去这种全局代码感需要长期维护经验。真正不能外包的是 P0/P1 风险分级、是否值得改、如何嵌入业务节奏等优先级判断。
核心结论3 : 技术债不是只能靠专项重构偿还，也可以被嵌入业务迭代，在需求交付中持续消化。
关键证据: 该系统从 2025 年 6 月不到 5 万行增长到 31 万行，同时承载平均每月 16 个需求、6 类多模态评测、任务视图与质检协作机制。团队没有申请专门重构排期，而是让主 R 先迁移最难的包，把过程沉淀为 AI 可执行 SOP，再由团队在后续需求中并行迁移。
核心结论4 : AI-assisted review 的有效形态不是让人重新读每一行 AI 代码，而是建立多轮机器自审、跨模型审查和人类约束审查的分层机制。
关键证据: 文章建议 PR 前先让 AI 自审多轮，再由高阶模型审查低阶模型、跨厂商模型互相挑错；人类 reviewer 重点转向“是否在正确约束下解决正确问题”。测试用例也采用 HITL SOP：AI 从流量监控和代码 diff 推断影响范围、风险等级、分支与兼容性，人类确认边界后再生成步骤和覆盖矩阵。
2. 质疑
关于“工程规范可形式化”的质疑 : 文章把 Agent 评测的“标准对齐”迁移到工程治理，前提是团队能把架构边界、领域建模、测试策略等隐性判断转成 AI 可执行规则。但许多工程取舍依赖业务节奏、历史包袱和人际协作，不一定能完全写成 Rule。关于“渐进式重构”的质疑 : 借需求消化技术债需要足够强的主 R 和足够稳定的架构方向。若系统债务已经影响交付、业务需求不断打断、或团队缺少共同标准，这种方式可能变成“每次顺手改一点，但总体继续变坏”。关于“90%+ AI 代码”的质疑 : 文章没有说明统计口径，是按提交行数、文件行数、生成草稿还是最终合并代码计算；也没有给出 AI 生成代码的缺陷率、返工率或 review 成本，因此不能直接推导“高 AI 占比等于高生产率”。关于案例可迁移性的质疑 : 该案例来自内部 Agent 评测系统，本身就有数据生产、质量控制、workflow orchestration 和多人协作机制，天然适合把工程治理类比成评测治理。普通业务系统或 legacy 系统未必具备同样清晰的评估接口。
3. 对标
跨域关联1：Agent 评测与工程治理 : “人人对齐→人机对齐”补强了 Agentic-Engineering ：AI Coding 不是单人效率工具，而是把团队标准放大为执行系统。没有人类共识，AI Rule 只是格式化的愿望清单。跨域关联2：经验的重新分工 : 文章与 Knowledge-Work 、Judgment 形成互补。AI 降低“看全代码”和“枚举问题”的成本，但把瓶颈推向判断：哪些问题值得修、风险优先级是什么、何时必须停下来重构。跨域关联3：技术债治理 : “借需求消化债”比 Technical-Debt-Avoidance 更主动。它不是只避免新债，而是把旧债偿还做成业务迭代的默认动作；但这要求债务项可以被拆成小块，并且每次业务改动都能顺手降低复杂度。跨域关联4：Review 分层 : AI 自审、跨模型审查、人类约束审查的组合可以并入 Agent-PR-Review 和 Verifiable-Agent-Engineering 。关键不是让模型替代 reviewer，而是把 reviewer 从“逐行找 bug”上移到“验证目标、约束和风险模型”。迁移判断 : 这篇文章最值得沉淀的不是“31 万行代码被 AI 重构”，而是一个组织模式：先把工程判断显性化，再让 AI 扩展执行半径，最后用 review 和测试矩阵兜住风险。
关联概念