让 AI 帮你写更慢、但更好的代码

预计阅读时间：9 分钟

提到 AI 编程，多数人的第一反应是"快"——快速生成骨架、快速填满函数、快速开一个巨大的 PR 然后赶紧合进去。Socket 工程师 Nolan Lawson 在他的博客"Read the Tea Leaves"里提出了一个反直觉的主张：LLM 极为灵活，它完全可以帮你写出质量更高、但速度更慢的代码。问题不在 AI，而在我们怎么用它。

"快"的陷阱

Lawson 指出了一个行业里正在固化的误解：AI 编程 = 尽快吐出代码。这种思路的后果很具体——

大而模糊的 PR，reviewer 看完只想点 approve 而不想逐行追问
生成的代码能跑，但边界条件、错误处理、可维护性全是空洞
开发者自己也不再深入理解代码逻辑，因为"AI 写的，能跑就行"

这不是 AI 的问题，是使用方式的问题。LLM 本质上是一个极度灵活的对话伙伴——你给它快的要求，它就给你快的输出；你给它深的要求，它也能陪你走一条更慢、更扎实的路。

慢下来意味着什么

"更慢"不是拖延，而是把 AI 当成一个可以反复追问、反复推敲的合作者。具体来说，Lawson 建议的工作流有几个关键动作：

先让 AI 写，然后逐段审问。 不要一次性接受整段生成结果。拿到一段代码后，追问：这里为什么用这个数据结构？这个边界条件你考虑了吗？如果输入是空会怎样？这种审问迫使你真正理解每一行，也迫使 AI 暴露它跳过的细节。

要求 AI 解释它的选择。 不是"给我写一个函数"，而是"给我写这个函数，并且逐行注释你选择这个实现方式的原因"。这会改变 AI 的输出质量——它不再只给你结果，还会给你理由，而理由本身就是一种质量保证。

让 AI 做你不想做的慢活。 有些工作慢但必要：写完整的错误处理、补齐类型注释、写有意义的测试用例、做性能基准对比。这些事人类常常跳过，但 AI 可以被要求不跳过。关键是你的 prompt 要明确说"不要省略任何边界情况"。

一个可操作的实践模板

下面是一个可以直接使用的 prompt 模板，用 Python 项目为例。假设你要让 AI 帮你写一个数据处理函数，但要求它走"慢而扎实"的路线：

# --- 你要 AI 帮你实现的函数签名 ---
def merge_user_records(
    primary: list[dict],
    secondary: list[dict],
    conflict_policy: str = "latest",  # "latest" | "primary" | "manual"
) -> list[dict]:
    """
    合并两个来源的用户记录，处理冲突字段。

    要求：
    1. 逐行注释每个实现选择的原因
    2. 不要省略任何边界情况（空输入、重复 ID、字段缺失、类型不一致）
    3. 为每个边界情况写对应的测试用例
    4. 给出性能分析：数据量 10k / 100k / 1M 时的预期耗时
    """
    ...

把这段签名连同要求一起发给 LLM，你会得到一个完全不同质量的输出。对比一下"快模式"的 prompt：

快速写一个 merge_user_records 函数，合并两个用户列表，冲突时取最新的就行。

同一个 LLM，同一个函数，两种 prompt 的输出差距是肉眼可见的。慢模式的输出会包含完整的 docstring、边界处理、注释理由和测试；快模式的输出大概率是一个能跑但经不起追问的骨架。

再看一个更具体的审问流程，用 shell 脚本模拟你和 AI 的多轮对话节奏：

# 第 1 轮：让 AI 生成初始实现
cat <<'PROMPT' | llm-chat
写 merge_user_records 的完整实现，逐行注释选择原因，不省略边界情况。
PROMPT

# 第 2 轮：审问边界条件
cat <<'PROMPT' | llm-chat
你刚才的实现里，如果 primary 和 secondary 都有同一个 user_id，
但某个字段一个是字符串一个是数字，你怎么处理的？请补上这个情况。
PROMPT

# 第 3 轮：要求测试覆盖
cat <<'PROMPT' | llm-chat
为上面所有边界情况写 pytest 测试，包括：空输入、重复 ID、
字段类型冲突、字段缺失。每个测试用例的名字要描述它测的是什么。
PROMPT

# 第 4 轮：性能追问
cat <<'PROMPT' | llm-chat
这个函数在 100k 条记录时的瓶颈在哪？如果需要优化，
你会改数据结构还是改算法？给出具体方案和预估提升幅度。
PROMPT

这里的 llm-chat 是一个占位命令——你可以替换成任何 CLI 工具（比如 aichat、llm、或者直接在 ChatGPT/Claude 界面手动操作）。关键不是工具，而是节奏：生成 → 审问 → 补测试 → 追性能，四轮下来，你对这段代码的理解远比一次性接受完整输出要深。

什么时候该快，什么时候该慢

Lawson 的观点不是"永远慢"，而是"有选择地慢"。一些判断标准：

场景	建议节奏	原因
探索性原型、一次性脚本	快	不进主分支，不需要长期维护
核心业务逻辑、公共 API	慢	错误代价高，需要审问和测试
你正在学习的领域	慢	审问本身就是学习过程
紧急 hotfix	快生成骨架，慢审问关键路径	时间紧但关键路径不能出错
重构已有代码	慢	需要理解上下文，AI 容易遗漏隐含约束

一个简单的决策规则：这段代码如果出错，修复成本有多高？ 成本高就慢下来，成本低就快出。

把慢变成习惯

最后是一个可操作的检查清单，每次用 AI 写重要代码时过一遍：

Prompt 里是否明确说了"不省略边界情况"？ 如果没说，AI 默认会省略。
是否要求 AI 解释每个实现选择？ 没有理由的代码是不可审问的代码。
是否至少做了一轮审问？ 生成后至少追问一个"为什么这样做"或"如果输入是 X 会怎样"。
是否让 AI 补了测试？ 测试是慢工作流的自然产物，不是事后补丁。
你自己能否解释这段代码的每一行？ 如果不能，你还没真正理解它，别合进去。

AI 不是加速器，是放大器。你给它快的要求，它放大快——给你一堆能跑但脆弱的代码。你给它深的要求，它放大深——陪你走一条更慢但更扎实的路。选择权一直在你手里。