从 Codex 访谈转述看工程判断：代码审查与架构设计该练什么

代码能够运行，并不意味着需求选对了、模块边界划清了，或失败时的行为已经得到团队认可。练习 AI 编程能力时，这些问题值得单独拿出来训练。

本文以一篇围绕 Codex 的访谈转述为讨论材料，尚未核对原始录音或文字稿。下文会区分转述中的观点、作者解释与本文的训练建议，不据此判断工具的实际能力，也不预测哪些岗位会被替代。

按转述文章的呈现，受访者对维护自动化持积极判断，同时强调代码审查还承担信息交换、理解工作目的和讨论架构意图的作用。架构部分则关注抽象、模块边界、接口契约与不变量。

这里有两层不同的问题：

这是本文对转述框架的整理，不是原访谈的逐字结论。两者也并非互斥：读懂代码、调试失败和验证实现，本身就会影响判断质量。

转述文还谈到好奇心、理解新系统和联系用户，并对 taste 作了判断力方面的解释。阅读时应保留作者阐释这一层，不能把整篇文章都当成受访者原话。

本文的编辑判断是：可以沿着这套框架设计练习，但不能由此推出编程基础、测试或人工审查已经不重要。 关于维护自动化程度、审查效果和重构成本的描述，其适用条件仍需独立验证。下面三项练习，重点是让决策过程留下可检查的记录。

可以用一个面向美国校园的活动报名服务做练习。以下均为假设场景，不是实际项目案例。

先不要急着设计数据库。找一位可能使用它的同学，让对方描述报名过程：什么时候才算成功？没收到确认时会不会再次提交？组织者如何判断活动是否满员？

把回答整理成一页需求说明：

这份说明的价值，在于让团队提前看到尚未作出的决定。例如，“暂不支持候补”是范围取舍；“不能超额报名”则是实现必须满足的要求，不能因开发方便而取消。

随后要求自己比较两个方案：同步返回最终结果，还是先受理、再查询结果？各自会让用户承担什么等待和理解成本？不必为了练架构而加入复杂组件，先说明当前需求为什么需要它。

若使用编程代理，把目标、约束和验收场景一并交给它。完成后逐条核对，不接受一句“功能已实现”作为验证结果。即使完全手写代码，这一步也一样适用。

代码审查能力不能只看发现了多少格式问题。更有训练价值的是：能否沿着改动目的，找到实现与约定之间的缺口。

为报名功能提交一个 PR（Pull Request），请审查者先读需求说明，再看代码。可以使用下面这组问题：

审查意见也需要分清轻重。“变量名可以更清楚”与“并发请求可能造成超额报名”不应得到相同处理。前者可能是建议，后者若违反已确认约束，就应在合并前解决。

一条可执行的意见应指出位置、风险和依据。例如：

> 这里先读取剩余名额，再写入报名记录。两个请求可能同时读到最后一个名额。请说明当前实现如何保证不超额，并补充并发场景的验证。

这比“线程安全吗”更容易推动讨论。提交者的答复也应指向具体实现和验证结果，不能只说已经修改。

练习时可以交换角色：一人写实现，一人审查，再共同记录哪条意见改变了设计。如果使用 AI 协助列出风险候选，仍要逐项复现或核查；同一工具生成的实现和解释，不能互相充当充分证据。

接口契约是模块向调用方作出的约定，不只是函数签名；不变量则是操作前后都必须成立的条件。

继续使用报名服务，把约定写清楚：

这些都是练习中的设计选择，需要团队确认，不能因为写进文档就自动成立。

接下来做一次受控替换：先实现内存存储版本，再改为持久化存储版本。重点不是比较代码量，而是检查调用方能否继续依赖原有约定。

建议按以下顺序推进：

测试通过也不等于所有风险都已消失。应同时记录尚未覆盖的并发条件、故障场景和验证限制，避免把未知情况默认为安全。

下一次课程项目、开源贡献或团队开发，可以只选一个小功能，完整留下需求说明、PR 审查记录和接口约束这三份产物。检查它们能否回答同一个问题：为什么这样改，有什么证据表明它满足目标，又有哪些边界不能破坏。答不清楚的地方，就是下一轮最具体的练习任务。