在 AI 写代码的时代读这本书

这本书第 2 版出版于 2021 年，书里没有任何关于大语言模型（LLM）或 AI 编程助手的内容。本页分成两种性质完全不同的材料，请注意区分：

• 蓝色左边框的"有出处的事实"：Ousterhout 公开说过的话，附链接和时间点，只转述能核实的部分。
• 虚线框的"本站看法"：本站用书中框架做的推演，不代表作者观点。

此外还有第三种：书的读者讨论组里读者自己的经历，单独放在一节里，既不是作者观点，也不是本站看法。

Ousterhout 本人说过什么

截至本页写作时（2026 年 10 月），本站能找到并核实的、Ousterhout 关于 AI 编程工具的公开表态，有两处：2025 年的一次访谈，和 2026 年在读者讨论组里的一条回帖。先说访谈：Gergely Orosz 主持的播客 The Pragmatic Engineer：The Philosophy of Software Design – with John Ousterhout（2025-04-09，YouTube 视频）。下面的转述依据节目页面提供的自动转写稿，时间点取自转写稿（与节目页面的章节标注基本对齐）。

So I think software design is going to become more and more important.— John Ousterhout，The Pragmatic Engineer 访谈，约 13:49（据节目自动转写稿）

And we shouldn't use AI tools as an excuse for people not to write comments.— John Ousterhout，同一访谈，约 1:10:33（据自动转写稿；紧接着还补了一句"至少现在还不行"）

第二处是书中给出的读者讨论组。2026 年 7 月，一位每天使用 AI 编程工具的读者问：书里说战略式投资划算，是因为以后有人要承受后果；如果以后和代码长期相处的是 AI，这个论证还成立吗？（原帖）

和 2025 年的访谈相比，有一处变化值得注意：访谈里 Ousterhout 说 AI 的产出"不一定是战术龙卷风式的东西"；一年多以后，转述的是"浅而复杂"的反馈。但两次的结论没有变：自己不知道答案，设计会变得更重要。提问的读者列了三种可能（设计更重要、不那么重要、只是换了受众），Ousterhout 没有明确选其中一个。

另外几条"没有"的事实，同样有用：

• Ousterhout 和 Robert Martin 2024–2025 年的长篇讨论（aposd-vs-clean-code，见本站专题）全文没有涉及 AI。
• Ousterhout 在 Stanford 的本书主页（本站查阅时最后更新于 2025-02）也没有相关内容。
• 讨论组里 2026 年另有一串很长的讨论，题目是 AI 是否提升了生产系统的软件质量（原帖）。Ousterhout 在其中只发了一条，内容是质疑别人贴出的一份没有署名的报告是否本身就是 AI 生成的，没有谈设计。所以那一串里的各种统计数字，本站一概不引用。
• 本站只精读了讨论组里的一部分讨论串（截至 2026-10-03），也没有查阅 Ousterhout 的社交媒体。除上述两处外，如果你找到了其他发言，以原始来源为准。

讨论组里读者的一手经验

下面两条来自讨论组里的读者，是个人经历，不是数据，也不是作者的观点。之所以收进来，是因为它们恰好用书里的词描述了自己看到的现象。

• "放手不管，它就成了战术龙卷风。"一位读者（2026-05）让 AI 助手修同一个模块里的两个 bug。第一个修得又简单又对，读者还顺便学到了框架的一个细节。第二个则跑偏了：原代码错误地使用了框架，助手没有改正用法，而是把本属于框架的一部分职责接过来自己实现，修好了原 bug，又引入至少两个新的；指出之后，它继续加代码去修新 bug，再引入更多。读者故意让它迭代了五轮，得到一大堆本不该写的代码。结论是：结果必须检查，否则只是做得更快，不是做得更好。
• "我不再读自己的代码了。"提出前面那个问题的读者（2026-07）说，自己对代码库的了解从"逐行都熟"变成了"大片没读过"，并且看到别的开发者也这样却没有察觉；工具默认的风格是"现在能跑"，而不是"以后好相处"。

代码变便宜之后，什么变稀缺

以下全部是本站看法。出发点很简单：书里几乎所有原则针对的都不是"打字"，而是决定。当打字的成本趋近于零，决定的分量就相对变重了，这也和 Ousterhout 在访谈里"设计比例会变大"的判断一致。

机器速度的战术龙卷风

书中第 3 章把"战术龙卷风"（tactical tornado）描述为写代码极快、但完全战术式工作的程序员，留下的烂摊子要别人收拾。前面说过，把 AI 比作战术龙卷风的是访谈主持人，Ousterhout 在访谈里并不同意代码一定差；讨论组里则有读者用这个词描述自己的亲身经历。

用红旗审 AI 生成的代码：清单

下表把书末的 14 个红旗翻译成审阅 AI 生成代码时的具体症状和提问（本站整理）。点击红旗名称可跳到速查页看定义。

还有两条书里有、但不在 14 个红旗之列的检查，在生成代码里特别常见：到处 try/catch 再打日志（第 10 章：异常应该被定义掉、屏蔽或聚合，而不是在每个调用点各处理一遍），以及巫毒常数（这个叫法出自 OSTEP 对 Ousterhout 的引用，书中没有用；对应第 8 章 8.2 节：重试次数、超时、阈值被做成参数，却没有人知道该设多少）。

完整示例：一段"AI 写的"会话缓存

下面是本站原创的示例，模拟一段很常见的生成结果。提示词大意是："用 C++ 写一个会话缓存，命中时直接返回，未命中从数据库加载；会话 30 分钟过期；管理员的会话不过期；数据库失败要重试。"代码能编译、能通过简单测试，单看每个函数也不算差。先自己找找红旗，再看分析。

// SessionCacheManager: manages session caching with database fallback.
// 会话缓存管理器
struct SessionCacheConfig {
    int ttlSeconds = 1800;
    int maxEntries = 10000;
    double cleanupThreshold = 0.8;
    int cleanupBatchSize = 500;
    bool enableAdminBypass = true;
    int dbRetryCount = 3;
    int dbRetryDelayMs = 100;
};

class SessionCacheManager {
public:
    SessionCacheManager(Database* db, SessionCacheConfig config);
    // 获取会话数据
    std::optional<SessionData> getSessionData(const std::string& sessionId,
                                              bool& fromCache, ErrorCode& err);
    // 从数据库加载会话
    std::optional<SessionData> loadSessionFromDatabase(const std::string& sessionId, ErrorCode& err);
    void putSessionInCache(const std::string& sessionId, const SessionData& data);
    bool isSessionExpired(const CacheEntry& entry);
    void cleanupExpiredSessions();
    std::unordered_map<std::string, CacheEntry>& getCache() { return cache_; }
    void setConfig(const SessionCacheConfig& c) { config_ = c; }
private:
    Database* db_;
    SessionCacheConfig config_;
    std::unordered_map<std::string, CacheEntry> cache_;
};

std::optional<SessionData> SessionCacheManager::getSessionData(
        const std::string& sessionId, bool& fromCache, ErrorCode& err) {
    // 检查是否需要清理
    if (cache_.size() > config_.maxEntries * config_.cleanupThreshold) cleanupExpiredSessions();
    // 在缓存中查找会话
    auto it = cache_.find(sessionId);
    if (it != cache_.end()) {
        // 检查是否为管理员
        if (config_.enableAdminBypass && it->second.data.role == "admin") {
            fromCache = true;
            return it->second.data;
        }
        // 检查会话是否过期
        auto now = std::chrono::system_clock::now();
        if (now - it->second.insertedAt < std::chrono::seconds(config_.ttlSeconds)) {
            fromCache = true;
            return it->second.data;
        }
    }
    fromCache = false;
    auto data = loadSessionFromDatabase(sessionId, err);
    if (data) putSessionInCache(sessionId, *data);
    return data;
}

bool SessionCacheManager::isSessionExpired(const CacheEntry& entry) {
    return std::chrono::system_clock::now() - entry.insertedAt > std::chrono::seconds(config_.ttlSeconds);
}

// SessionService.cpp
std::optional<SessionData> SessionService::getSession(const std::string& id, bool& fromCache, ErrorCode& err) {
    return cacheManager_->getSessionData(id, fromCache, err);
}

逐条分析

1. 巫毒常数 + 过度暴露（第 4～10 行）：七个参数，其中 cleanupThreshold、cleanupBatchSize、dbRetryDelayMs 没有任何调用者能比模块自己定得更好（第 8 章 8.2 节的检验问题）。enableAdminBypass 根本不是性能参数，而是一条安全策略。
2. 注释重复代码（第 16、19、34、36、39、44 行一类的注释）：每条都在复述下一行。真正需要说明的事却一条没写：fromCache 有什么用、err 何时被设置、失效会话返回什么、线程安全吗。
3. 过度暴露（输出参数）（第 17～18 行）：每个调用者都必须准备 bool fromCache 和 ErrorCode err，而关心"是否命中缓存"的大概只有监控代码。
4. 浅方法 + 按时间顺序分解（第 20～23 行）：loadSessionFromDatabase、putSessionInCache、cleanupExpiredSessions 是 getSessionData 内部的步骤，却被公开了，等于邀请调用者自己拼流程（拼错顺序就会读到过期数据）。
5. 信息泄漏（第 24～25 行）：getCache() 把内部的 unordered_map 以可修改引用交出去，缓存的表示方式从此成了接口的一部分；setConfig 允许运行中改 TTL，已缓存条目的语义随之变得模糊。
6. 通用与专用混杂（第 39～43 行）：提示词里的"管理员不过期"被写进了通用缓存的命中路径。后果不只是复杂：管理员被撤权或登出后，缓存里的旧会话依然永远有效。这是业务策略，不属于缓存。
7. 重复（第 46 行与第 58 行）：过期判断写了两遍，一处用 < 判断"未过期"，一处用 > 判断"已过期"，恰好在边界上两者都不成立。重复的逻辑迟早会这样悄悄分叉。
8. 代码不明显（第 35、45 行）：在 get 里顺手触发全表清理，会让某些请求的延迟突然变高，读代码的人很难从名字想到；用 system_clock 计算过期，系统时间被回拨时会话会"返老还童"。
9. 透传方法（第 62～64 行）：SessionService::getSession 签名和下层完全一样，只是转手。
10. 名字：SessionCacheManager、SessionData 里的 Manager、Data 不提供信息 ；而公开方法一多，getSessionData 和 getSession 哪个该用也成了要记的东西。

重构后

// 已登录会话的缓存，位于 SessionStore（数据库）之前。
// 会话从加载起 ttl 时间内有效；条目数超过 capacity 时淘汰最久未访问的条目。
// 线程安全。时间一律用 steady_clock，不受系统时间调整影响。
// 数据库的瞬时故障由 SessionStore 内部重试；仍然失败时 find 抛 StoreUnavailable，
// 由请求分发层统一转成 503（不需要每个调用点处理）。
class SessionCache {
public:
    explicit SessionCache(SessionStore& store,
                          std::chrono::seconds ttl = std::chrono::minutes(30),
                          size_t capacity = 10'000);

    // 返回 id 对应的有效会话；会话不存在或已过期时返回 std::nullopt。
    std::optional<Session> find(std::string_view id);

    // 让 id 的缓存条目立即失效。登出、改密码、权限变更后必须调用。
    // id 不在缓存中时什么也不做。
    void invalidate(std::string_view id);

    CacheStats stats() const;   // 命中数、未命中数、淘汰数，供监控使用
};

• 接口从 7 个公开方法缩到 3 个（不算构造函数），没有输出参数，没有配置结构；两个真正可能需要调整的值（ttl、capacity）是带默认值的构造参数。
• "是否命中缓存"从每次调用的输出参数，变成了供少数监控代码使用的 stats()（第 4、5 章：让常见用法简单，罕见需求另开入口）。
• 错误：重试被推到真正知道如何重试的 SessionStore 里（屏蔽，10.6 节）；剩下的不可恢复错误在请求层统一处理（聚合，10.7 节）。
• 管理员特例从缓存里删掉了。如果确实需要"管理员会话更长"，那是会话签发时决定的过期时间，应该存在 Session 里，由业务层设置；缓存只认过期时间，不认角色。审阅 AI 代码时，提示词里的特例是最该追问"它属于哪一层"的地方。
• 新增的 invalidate 是原版缺失的重要功能，原版根本没法让一个会话提前失效。书中 21.4 节说，没认出重要的东西也是一种错误；这一点往往要靠人来想到，因为提示词里没写。
• 代价：实现会比原版长（LRU 链表、互斥锁、统计），但这些复杂性被关在一个类里。这正是 的意思。

把书里的方法接进 AI 工作流

以下是本站建议的做法，每一条都对应书中的某个原则：

1. 接口和接口注释自己写（第 15 章"先写注释"）。写下类注释、公开方法的签名和注释，再让模型生成实现。如果注释怎么写都很长，先停下来： 说明设计本身需要再想。
2. 让模型提供备选方案，而不是直接要答案（第 11 章"设计两次"）。例如："给出三种差异很大的接口设计，各写出公开方法和一段使用示例，不要实现。"然后用书里的标准（调用方是否最简单、接口是否深）来挑。
3. 按上面的清单审阅每一次生成，尤其盯住公开接口的变化：新增了哪些公开成员？每一个都值得存在吗？
4. 每次改动都顺手改善一点设计（第 3 章、16.1 节）。生成的代码合入后，别让"以后再整理"变成永远不整理。
5. 把 AI 给你的解释沉淀成注释。如果你像 Ousterhout 读 Linux 内核那样，靠模型才搞懂了一段代码，核实之后把关键结论写成注释，下一个读者（人或模型）就不用再猜一次。

示例：用接口注释当提示词

下面是第 1 步的一个具体样子（本站示例）。注意提示词的主体就是将来要留在头文件里的接口注释，额外的要求只有几行，而且都在约束不要扩大接口：

// ===== 交给模型的内容：头文件草稿 + 要求 =====
// 按固定窗口统计每个 key 的请求次数，用于限流判断。
// 窗口长度在构造时给定；计数在窗口结束时整体清零（不是滑动窗口）。
// 线程安全；内存占用与"当前窗口内出现过的 key 数"成正比，窗口切换时释放。
class WindowCounter {
public:
    explicit WindowCounter(std::chrono::milliseconds window);

    // 把 key 在当前窗口的计数加 1，返回加 1 之后的值。
    // now 必须来自 steady_clock；早于上次调用的 now 按上次的时间处理。
    uint64_t hit(std::string_view key, std::chrono::steady_clock::time_point now);
};
// 要求：
// 1. 只实现上面的公开接口，不要新增公开方法、配置项或输出参数。
// 2. 不要在实现里写复述代码的注释；只在不明显的地方说明"为什么"。
// 3. 如果你认为接口本身有问题（例如某个约束无法高效实现），先指出来，不要自行修改接口。

第 3 条要求很关键：它把"发现设计问题"留给对话，而不是让模型悄悄绕过去。模型的反馈有时正是书里说的"难以描述""名字难起"一类的信号。

练习