AI 写代码越来越快，但你的代码库准备好了吗？
今天 Hacker News 上一篇 165 分的文章引发了热议：Be intentional about how AI changes your codebase。标题很克制，内容却切中了一个很多团队正在痛苦面对的问题 —— AI 帮你写代码的速度越来越快，但代码库的质量在下降。
这不是 AI 的问题。是我们的问题。
快不等于好
Cursor、Claude Code、Copilot 这些工具确实让写代码变得更快了。一个函数几秒就生成，一个模块几分钟搭好。但速度带来了一个隐性成本：当生成代码的边际成本趋近于零时，我们会不自觉地降低对代码结构的要求。
想想你上一次用 AI 生成代码的场景。你检查了函数命名是否语义化吗？你确认了数据模型是否让「非法状态不可表达」吗？还是觉得「能跑就行，回头再改」？
那个「回头」，大概率不会来。
两类函数，一个原则
原文提出了一个简洁有力的分类：语义函数（Semantic Functions） 和 务实函数（Pragmatic Functions）。
语义函数是代码库的积木。它接收所有需要的输入，返回所有必要的输出，不搞副作用。好的语义函数不需要注释 —— 函数名就是文档。retry_with_exponential_backoff() 比一段注释「这里做了指数退避重试」强一百倍。
务实函数是业务流程的组装器。handle_user_signup_webhook() 这种函数天然是复杂的，允许混乱，但应该由一系列语义函数组合而成。务实函数可以写注释，但不要复述函数名，而是记录意外行为 —— 比如「余额低于 10 时提前失败」。
这个分类的核心思想是：让 AI 生成语义函数，让人类设计务实函数的组合方式。
数据模型是第一道防线
原文中另一个值得深思的观点：好的数据模型应该让错误状态不可能存在。
每一个 optional 字段都是代码库里的一颗定时炸弹 —— 其他所有碰到这个字段的代码都要回答「它是 null 怎么办？」。UnverifiedEmail 和 VerifiedEmail 是两个类型，而不是一个 Email 加一个 isVerified 布尔值。
AI 生成代码时特别喜欢加 optional 字段，因为这是最「安全」的选择。但安全和正确是两回事。作为架构师，你的职责是定义数据边界，然后让 AI 在这个边界内填充实现。
实践建议
如果你的团队正在大规模使用 AI 编码工具，这几件事值得现在就做：
- 建立
CLAUDE.md或类似的项目规范文件 —— 把代码风格、命名约定、架构原则写进去，AI 工具会遵守 - Code review 的重心从「实现是否正确」转向「抽象是否合理」 —— 实现层面 AI 已经很少犯错，但抽象层面它还需要人类把关
- 定期做「架构体检」 —— 看看最近一个月新增了多少 optional 字段，多少函数超过 50 行，多少模块的职责在悄悄膨胀
在像 OfoxAI（ofox.ai）这样的多模型平台上，你可以用不同模型做交叉 review —— Claude 擅长架构分析，GPT 擅长发现边界情况，Gemini 擅长理解上下文。模型之间的「分歧」往往就是设计盲区。
写在最后
AI 编码工具的进化速度远超我们调整工作方式的速度。这不是要抵制 AI —— 那没意义。但需要有意识地建立新的纪律：AI 负责速度，你负责方向。
代码库是一个活的有机体。让它在 AI 时代保持健康，需要的不是更多代码，而是更好的骨架。
参考：Be intentional about how AI changes your codebase — HN 165 points