# Agent 一次改几十个文件，评审时架构漂了该先盯哪几层？

**URL:** <https://www.shiqidu.com/t/topic/1902>\
**Category:** 人工智能\
**Tags:** 问与答, 程序员, AICoding\
**Created:** [2026 年11 月 2 日 11:47 UTC](https://www.shiqidu.com/t/topic/1902 "2026-11-02T11:47:02Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\
发布日期： [2026 年11 月 2 日 11:47 UTC](https://www.shiqidu.com/t/topic/1902/1 "2026-11-02T11:47:02Z")

</div>

打开一个代理生成的 PR，文件列表滚半天，diff 统计好看，本地测试也绿。问一句「这回架构漂到哪了」，连提 PR 的人都说不清。风格能不能统一成次要问题。真正贵的是边界、契约和失败路径被顺手改掉，事后才在线上露出来。

下面这几层是按「对人可见的行为」排的，不是又一份风格指南。层与层之间没有官方标准顺序，你们组完全可以按自己的风险重排。下面只是按行为风险摊开的检查点。也不编造「平均评审要多长时间」这种外部文章数字。没有你们仓库的基线，抄过来也指导不了排期。

## 边界和权限有没有被顺手放开

看 diff 里有没有：鉴权中间件被删或改成可选、后台接口突然对匿名开放、文件或命令执行路径从白名单变成「能读到啥算啥」、特性开关默认值从关改成开。代理很擅长「为了跑通示例」把守卫拿掉。这类改动不一定编译失败，但行为已经变了。把改前改后的权限矩阵对着看一遍，比逐行读生成注释有用。

## 公共库和 API 签名有没有静默变样

导出函数改了参数顺序、可空性、错误码。REST 路径或字段名换了却没改调用方。内部 DTO 和对外契约混用。单测如果只断言「有返回」，签名片漂了也测不出来。评审时优先点开被改到的 `export`、路由表、proto 或 OpenAPI 描述，而不是先纠结变量命名。公共包多一个可选参数看似无害，下游若按位置传参，行为会在升级那天一起歪。

## 错误处理和重试是不是被删瘦了

生成稿常见手法：`catch` 变空、超时去掉、重试改成一次、把「可恢复错误」和「必须失败」揉成同一条分支。表面上调用链更短，故障时只剩一声「失败了」。对照改前的错误枚举和日志字段，看有没有关键上下文被抹掉。超时和退避若被删，压测绿、故障演练红的情况很常见。

## 测试是不是只改到「绿」

断言从精确值改成 truthy。集成测试改成只 mock 成功路径。快照大面积更新却没人解释。测试变绿不等于行为没变。宁可少几个用例，也要保住对权限拒绝、超时、空集合这些边界的断言。看见「删除失败用例」或「跳过 flaky」又没有复现说明，就要问一句：是真的不需要了，还是生成稿删着省事。

## 依赖和配置有没有夹带默认密钥或过宽策略

新加的 SDK 默认打开调试上报。示例配置里的 CORS 写成 `*`。环境变量示例塞了可复制的假密钥，结果有人直接贴进仓库。锁文件里多出来的传递依赖没人认领。这类东西不一定在业务代码 diff 的第一屏，要翻 `package.json`、部署清单和示例环境文件。

风格、格式化、注释语气可以放后面，或者交给工具。人审的时间有限，先盯「用户或攻击者能观察到的行为差」。规则文件（AGENTS.md 一类）能约束代理少乱动，替代不了这几层人审。

你们组现在代理改完代码，还有没有固定的人审清单？哪一层漏过以后代价最大，欢迎直接说场景。