今年作为工程师你将做出的最重要决定

Source: Dev.to

请提供您希望翻译的正文内容，我将按照要求进行简体中文翻译并保留原始的格式、Markdown 语法以及技术术语。

工程师的二元选择

Option A: 继续逐行审查代码，好像是人写的一样。这条路径保证你成为瓶颈，抑制团队的吞吐量。

Option B: 演进你的审查策略，将低层实现的控制权交给 AI，以释放高层架构的速度。

如果你选择 Option A，本文不适合你。你很可能会继续在日益增长的 PR 浪潮中沉沦，直到外部指标迫使改变。

如果你选择 Option B，你已经准备好进行范式转变。然而，盲目“让 AI 编码”而没有治理体系会招致混乱。你需要强有力的策略，在不审查每一行实现的前提下保持系统质量。以下是让 Option B 成为现实的五大策略。

速度陷阱：为何选项 A 在数学上不可能

此决定受制于硬性的数学现实。

• 一名有经验的工程师大约能在 每小时审阅 200 行复杂代码。
• 一个 AI 代理可以 每秒生成 200 行代码。

如果你选择 选项 A，就是把线性的人类处理速度与指数级的 AI 生成速度相对抗。随着团队采用更多 AI 工具，代码产出量将呈数量级增长。如果你的审查政策仍是“每行代码都必须有人眼审阅”，你的积压将无限增长，开发速度将趋近于零。

你无法比机器阅读得更快，必须在思考上超越它。

Source: …

策略 1：攀登抽象阶梯

第一步是重新定义你对软件的理解。

在过去，“了解代码库”意味着知道特定函数内部的 if 语句是如何工作的。在 AI 时代，这种做法不可持续。将你的思维模型划分为层级结构：

Product → System → Modules → Functions

转变： 停止审查最低层级（本例中的函数）。

如果一个产品集成了 Stripe，你不需要关心代码是使用三元运算符还是 if‑else 块。你应该关注的是存在一个 计费系统，其中包含一个遵循特定合同的 Stripe 模块。

你的任务是保持对更高层级（产品和系统）的清晰思维模型。这与 合同专化原则 相一致。通过保持边界的刚性，你可以让 AI 处理这些边界内的实现细节。正如 编码已成为商品 中所指出的，价值已经从“砖块”（函数）转移到“蓝图”（系统架构）。

策略 2：审查指令，而非代码

当你发现架构或逻辑中的缺陷时，你的本能会去修复代码。请克制这种冲动。

如果 AI 生成的代码违背了你的架构，这就是一次指导失误。与其重写代码，不如重写生成该代码的指令或系统提示。

这会把你从代码审查者转变为代理的架构师。正如在**From Scripter to Architect**中讨论的那样，你不再是流程的作者；你是边界的架构师。修正指令可以保持将来编写下 100 项功能的“员工”，而手动修正代码既不教会任何东西，也只解决单一实例。

Strategy 3: Automated Verification as the Safety Net

对不审查低层代码的担忧是合理的：“如果出现 bug 会怎样？”

于是出现了第三种策略：Aggressive Automated Testing（积极的自动化测试）。

当你停止审查函数时，就失去了肉眼捕捉细微逻辑错误的能力。用 Automated Verification 来取代这种手动的警觉。

• 测试保证你可以对细节“保持无知”。
• 当工程师（或 AI）需要修复他们并不完全理解的低层模块中的 bug 时，测试套件充当护栏，确保修复 Stripe 集成不会破坏 User Auth 流程。

这实现了 The Principle of Intrinsic Verification。你用编写健壮测试的前期成本，换取手动审查的高摩擦成本，从而逃离 AI Verification Trap，并将注意力聚焦在系统层面的约束上，而不是语法细节。

策略 4：强化模式至上

你无法验证所有内容，但你可以验证边界。

在 AI 编写任何逻辑代码之前，严格定义输入和输出模式（Types、Interfaces、Zod schemas）。这就是 Schema Supremacy。

• 控制进入和离开模块的数据形状，使你不必过多关心内部的数据转换方式。
• 你审查的是契约的严格性，而不是转换逻辑。
• 如果 AI 遵守模式，坏代码的影响范围就会被限制。

策略 5：可观测性即利息支付

• 将关注点从“这段代码干净吗？”转移到“系统健康吗？”
• 确保你拥有日志、度量和警报，一旦生产环境出现边缘情况就会大声报警。

这与 [Observability as …]（链接待补）相吻合。

[Interest Payments](https://ttoss.dev/docs/engineering/guidelines/technical-debt#4-observability-as-interest-payments).  
If you can't see it fail, you can't afford to let the AI write it without review.

结论

从审查员转变为架构师的决定关乎相关性和影响力。

你可以继续做守门人，捕捉每一个缺失的分号，骄傲地 owning 每一行代码，同时每月只交付一个功能。或者，你可以进化为定义系统、编写指令并强制执行验证循环的架构师——赋能 AI 劳动力以计算速度交付。

第一条路径通向传统工程。第二条路径定义工程的未来。做出你的选择。