人工代码评审的问题缺陷
过去评审代码就像校对一本手写小说，必须逐字逐句盯住每个标点、每行缩进、每个变量命名。一个开发者写200行代码，主管可能花20到40分钟反复滚动屏幕，用Ctrl+F搜索关键词，追踪数据库字段迁移路径，确认功能开关是否被正确调用。
这种模式下，写代码和评审代码的时间比例长期维持在1:5甚至1:10。
这意味着，当开发者喝完一杯冰美式，评审者那杯热咖啡还冒着气。这种节奏在传统软件开发时代尚可接受，但当AI开始批量生成上千行跨27个文件的修改时，人类视觉系统的带宽立刻成为瓶颈。
眼睛会疲劳，注意力会漂移，逻辑链条会在第18个文件处断裂。
更致命的是，复杂系统中的错误往往藏在模块交互的缝隙里，而非单个文件内部。靠肉眼扫描diff（差异对比）根本无法捕捉这类分布式bug。
于是，一种新型评审范式悄然诞生——不再依赖人类阅读代码本身，而是通过结构化提问，迫使AI主动解释其决策逻辑。
总之：
- 早期工程评审强调逐行确认。拼写、逻辑、风格、边界条件，构成阅读关注点。
- 生成式系统加入后，代码产出速度明显跃迁，原有评审节奏形成瓶颈。
- 时间比例出现失衡，编写与评审之间的节奏差距持续扩大。
新的做法通过提问获取全局理解。变更范围、设计动机、潜在影响、风险触发点，通过语言交互直接呈现。
工程理解从阅读感知转为解释感知，架构清晰度通过结构化回答建立。
从“看代码”到“问代码”：评审方式的根本性迁移
当Claude Code提交一个涉及27个文件、超1000行变更的修复方案时，传统做法是打开GitHub界面，一行行比对AI写的代码：绿色新增与红色删除。
但新方法完全跳过这一步。
取而代之的是对AI连续抛出四个核心问题：“请逐步说明你做了哪些修改以及为什么这样改”“你基于哪些假设进行设计”“什么情况下这个方案会失效”“为何忽略kieran-reviewer的反馈”。
这些问题并非随意提问，而是精准打击AI推理链条中最脆弱的环节。
第一个问题检验变更的完整性与动机一致性；
第二个问题暴露隐藏前提，比如是否假定某个API永远返回非空值；
第三个问题测试边界条件鲁棒性；
第四个问题则引入外部监督信号。
这种问答机制本质上构建了一个反向验证通道——不是被动接收代码输出，而是主动榨取AI的内部推理过程。
结果证明，这种策略比肉眼扫描更能发现深层问题。因为人类容易陷入细节泥潭，而AI在解释自身行为时，会无意中暴露逻辑断层或矛盾点。例如，当被问及“什么会破坏此方案”时，AI可能坦白“如果用户同时启用A和B功能标志，签名格式将冲突”，而这个组合场景在原始需求文档中根本未被提及。
13个AI专家代理：打造代码评审的特种部队
单一AI模型如同全科医生，虽知识广博但深度有限。面对横跨数据库迁移、前端渲染、权限控制、性能优化的复合型变更，通用模型极易遗漏专业领域陷阱。
解决方案是组建一支由13个专用AI代理构成的评审军团。每个代理都是高度特化的“专家”：
- 安全代理紧盯认证漏洞与数据泄露风险；
- 数据库代理专注查询效率与事务一致性；
- 性能代理扫描慢操作与内存泄漏；
这些代理并非独立运行，而是通过“复合工程插件”（compound engineering plugin）协同工作。该插件本质是一组Markdown格式的工作流定义文件，存放在代码库特定目录中。
当执行终端命令/workflows:review时，系统自动激活所有预设代理，并行分析同一份代码变更。每个代理依据自身角色生成评审报告，标记潜在问题并提出修改建议。
这种架构模仿了人类专家委员会的运作模式——安全专家不会纠结于代码缩进，性能专家也不关心UI配色，各自聚焦核心职责。最终汇总的评审意见远比单一视角全面。
更重要的是，这些代理具备持续学习能力。每当人类确认某个AI发现的bug确实存在，该案例就会被纳入训练反馈环，强化未来同类问题的识别准确率。
kieran-reviewer正是这样一个个性化代理，它被训练成偏好“简单查询胜过复杂查询”“清晰代码优于聪明代码”的风格，成为开发者个人偏好的数字化身。
复合工程插件：让AI理解你的工作流语言
所谓“复合工程插件”，并非神秘黑盒，而是一套轻量级、可扩展的指令集。其核心由两类文件构成：工作流（workflow）文件和代理（agent）文件。工作流文件以Markdown编写，定义高层任务序列。例如/review工作流文件内容可能如下：
markdown
# /workflows/review.md
Execute all reviewer agents in parallel:
- security-reviewer
- db-reviewer
- performance-reviewer
- style-reviewer
- kieran-reviewer
...
Aggregate findings and present summary.
markdown
# /agents/kieran-reviewer.md
Persona: Kieran's personal code style enforcer
Focus: Simplicity over cleverness, explicit over implicit
Rules:
- Flag any query with >3 JOINs
- Prefer early returns over nested conditionals
- Reject "clever" one-liners that sacrifice readability
- Enforce consistent naming for email-related modules
整个过程无需定制开发工具，仅依赖现有代码库结构和标准化提示工程。这种设计极大降低了采用门槛——任何团队只需在项目根目录创建对应Markdown文件，即可复用这套评审体系。
更妙的是，工作流本身也可被AI优化。例如，若某次评审发现安全代理遗漏了OAuth令牌处理漏洞，可立即更新security-reviewer的规则文件，下次评审自动覆盖该场景。这种“评审即配置”的理念，使代码质量保障从静态检查转变为动态进化系统。
从恐惧到信任：架构感知的新路径
放弃手动阅读代码曾引发强烈不安——担心失去对系统整体结构的“手感”。
传统上，通过浏览代码能直观感受模块耦合度、抽象层级是否合理、技术债是否堆积。
但实践证明，这种直觉可通过更高阶的交互重建。当连续追问“为什么选择方案A而非B”“这个模块未来如何扩展”时，AI被迫展示其架构思维。若回答含糊或自相矛盾，恰恰暴露设计缺陷。
反之，清晰连贯的解释则增强对方案的信心。
更重要的是，13个代理的集体评审形成多维透视图：安全视角揭示权限边界，性能视角量化资源消耗，风格视角评估维护成本。这些维度叠加后，对系统健康度的判断反而比单一人工评审更立体。架构不再依赖模糊的“感觉”，而是建立在可验证、可追溯的专家意见集合之上。这种转变如同从肉眼观星升级为射电望远镜阵列——虽然不再直接“看见”星星，但获得的数据精度和维度呈指数级提升。
时间比例的崩塌与重构
AI生成代码的速度已压缩至分钟级，而人类评审速度仍卡在小时级。
这种不对称性迫使工程范式必须进化。过去1:5的写审时间比，在AI时代可能变成1:50甚至更糟。若坚持传统评审，将成为交付流水线的绝对瓶颈。
新方法通过三重加速破解困局：
首先，AI自解释机制将评审焦点从“看做了什么”转向“为什么这么做”，过滤掉90%的无关细节；
其次，并行代理评审将原本串行的人工检查转化为毫秒级并发计算；
最后，决策导向的提问框架（如“什么会破坏此方案”）直接定位高风险区域，避免地毯式搜索。
综合效果是，原本需数小时完成的评审，现在15分钟内即可闭环。更关键的是，质量不降反升——因为AI代理不会因疲劳跳过第20个文件，也不会因先入为主忽略反例。时间比例的重构不是牺牲质量换速度，而是用智能分工释放人类认知资源，聚焦真正需要判断力的决策点。
系统学习与持续改进
每一次修正反馈都会进入系统学习环节。评审智能体根据纠正内容调整关注重点。下一次评审中，类似问题更早被捕获。工程流程形成正向循环，质量控制逐步前移。
这种学习方式让评审能力随时间增强，团队整体认知水平同步提升。工程经验从个人记忆转化为系统资产。
工程评审的未来形态
当前实践展示一种可复制路径。无需复杂定制工具，通过文本工作流与角色设定即可启动。关键在于观念转变，评审目标从阅读代码转向理解决策。
在生成式工程环境中，效率与稳定性通过流程设计实现平衡。并行评审智能体、结构化提问、反馈学习，共同构成新的工程评审基础设施。