慢下来：利用 AI 提升代码质量而非仅仅追求速度

关于 AI 辅助编程的主流叙事往往集中在原始速度上——即在几秒钟内生成数百行代码的能力。这种“垃圾大炮”式的方法鼓励开发者提交大量未经审查的 pull requests (PRs)，寄希望于输出量的大小等同于生产力。然而，这种对速度的追求往往以牺牲架构完整性和长期可维护性为代价。

存在一种强大的替代方案：不是利用 LLMs 来更快地编写代码，而是更慢地编写更好的代码。通过将重心从生成转向验证和完善，开发者可以使用 AI 来增强他们的工艺水平，而不是将其作为思考的外包。

AI 驱动的审查循环

利用 LLMs 最有效的方式之一是将其作为严谨的漏洞寻找工具。虽然模型在没有指导的情况下可能难以从头开始构建复杂的系统架构，但它们在发现现有代码中的边缘情况、安全漏洞和逻辑错误方面表现得非常出色。

为了最大限度地减少幻觉和误报，采用多模型“辩论”或审查策略非常有效。与其依赖单一提示词，不如实施一种结构化的工作流：

多智能体审查： 部署多个专门的智能体（例如 Claude、Codex 和专门的漏洞机器人）来分析一个 PR。
分类： 要求智能体按严重程度（Critical、High、Medium、Low）对发现的问题进行排名。
验证： 由主智能体或人类开发者审查这些发现，排除误报，并汇总出一份最终报告。
迭代修复： 首先修复 Critical 和 High 严重程度的问题，重复该循环直到代码库稳定。

这个过程通常会会揭示早于当前 PR 存在的既有漏洞，从而将开发过程转变为提升整体代码库健康度的“切线侧线任务”。虽然这可能会降低即时速度，但它能显著减轻长期的技术债务负担。

范式转移：从生成到增强

将 AI 集成到高质量的工作流中需要改变我们对工具的认知。与其将 AI 视为开发者的替代品，不如将其视为一个功能强大的协作伙伴。

快速原型设计与舍弃

AI 允许开发者快速探索多种实现路径。正如一位开发者所指出的，能够“快速 hack 出该功能的 4 种变体”允许进行一种如果手动完成则成本过高的实验。这里的价值不在于交付的代码，而在于排除的过程——在致力于最终设计之前，先找到那些不起作用的版本。

“导师”模型

对于那些正在应对陌生领域的人来说，LLMs 可以充当不知疲倦的导师。通过编写他们能写的最好的代码——即使是错误的——并要求 AI 解释为什么它不起作用，开发者可以保持其阅读理解能力和对系统的心理模型。这种紧密的反馈循环确保了开发者仍然是逻辑的主要驱动者，防止了当 AI 直接编写解决方案时所发生的“技能退化”。

组件级监督

与其采用往往导致架构“垃圾”的自上而下的生成方式，不如专注于组件级的范围，并侧重于质量控制（回归测试、基准测试和性能测试），这种方式往往能产生更优的结果。这种方法将 AI 视为实现细节的高端工具，而人类则保留对微架构决策的控制权。

“慢速” AI 编程的权衡

采用质量优先的方法涉及几个自觉的权衡：

局部效率低下 vs. 全局获益： 就像传统的代码审查一样，这个过程对单个开发者来说在局部是较慢的，但对团队和项目来说在全局是受益的。它防止了那种“白日梦”式的智能体编程，即功能交付很快，但对边缘情况的信心很低。
Token 成本 vs. 技术债务： 你可能会消耗更多的 tokens，但结果是交付了一个版本 3 的实现方案，却作为版本 1 交付。
认知负荷： 存在过度依赖 AI 的风险。一些开发者建议使用“较笨”或本地模型来强制进行更高水平的个人验证和更具描述性的任务分配方式。

结论：工艺水平的回归

随着 AI 变得无处不在，软件工程的分水岭将不再是生成代码的能力，而是在于辨别质量的能力。目前存在一个“神奇的交汇点”：经验丰富的专业人士能够手动编写代码，并能熟练地利用 AI 来放大他们的严谨性。

通过慢下来，并将 AI 视为批判、完善和探索的工具，开发者可以超越“氛围感编程 (vibe coding)”，回归到对工艺水平的关注——为下一个开发者创造更好的东西，并确保他们交付的软件是健壮、有意识的、且可维护的的。