为什么第一版从来不是问题：AI 编程与长期维护
AI 编程工具擅长生成第一版。真正的工程挑战始于第四版——当团队需要改动某些东西而不破坏其他一切时。
每个 AI 编程演示都遵循相同的套路。有人向模型发出提示。一个能工作的应用凭空出现。观众印象深刻。 他们理应如此。速度是真实的。能力是真实的。有 AI 参与时，第一版确实发布得更快。 问题在于，第一版从来不是难点。 软件工程的成本不集中在初始创建阶段。它集中在第四、第五、第六次迭代：…
想法与洞见
探索 AI 优先开发、编码护栏和可处置架构。
AI 生成代码与可替换性原则
衡量 AI 生成代码质量的真正标准不是它在第一天能否运行，而是在第三十天你能否在不 rewrite 其他所有内容的情况下替换它。
关于 AI 生成代码质量的大多数讨论都聚焦于生成时的正确性。输出能编译吗？能通过测试吗？符合规格说明吗？ 这些只是基本门槛。它们无法告诉你真正的成本。 真正的衡量标准是可替换性：当需求变化时，你能以多低的成本删除这个 module 并在相同的 contract 背后重新实现它？ 如果答案是"轻而易举"，那么 AI…
AI Codebase 的确定性护栏
人工审查不一致，AI 审查更不可靠。AI 生成 codebase 唯一可扩展的防线是确定性 enforcement：让构建失败的规则，而非被忽视的建议。
对 AI 生成代码的标准建议是"仔细审查"。 这个建议正确但在规模化时毫无用处。 开发者审查 AI 输出时，在精力充沛、熟悉领域且没有时间压力的情况下能发现问题。在其他所有条件下——而这是大多数情况——问题会漏过。 用 AI 审查者来发现 AI…
你的单元测试通过了，但生产代码仍然是坏的
代码覆盖率指标制造了一种虚假的安全感。以下是单元测试为何漏掉那些让你夜不能寐的 bug，以及你应该测什么。
你有 90% 的代码覆盖率，却仍在凌晨两点被告警吵醒。 单元测试通过了。CI 是绿的。bug 还是溜进了生产环境。覆盖率没有撒谎，但它也没有说出真相。它衡量的是哪些行被执行了，而不是哪些行为真正被验证了。…
Rust 的 Runtime Contracts 可以在 Release 构建中零开销，但编译器不会替你实现
Rust 会自动剥离 debug assertions，但真正的 design-by-contract 需要的远不止 debug_assert!。本文介绍如何在 Release 二进制文件中实现零成本的 runtime contracts，并让它们彻底消失。
Rust 可以在开发阶段强制执行 runtime contracts，并在 release 构建中将其完全抹除。前提是这门语言并没有把 contracts 当作一等公民。你会拿到所有积木，但得自己把它们拼起来。 是最显而易见的起点。它在 debug 构建中执行，在 release 构建中编译为空。这对简单的…
零个、一个还是十二个：生产函数到底需要多少个断言
开发者要么像撒彩纸一样到处抛撒断言，要么完全避之不及。这个决策框架能帮你区分有用的 invariants 和生产环境崩溃的触发器。
大多数 production codebases 都会分成两派。A 派把 当成装饰性调料，每隔一行就撒一点，直到函数读起来像个偏执律师写的法律合同。B 派把断言当作只在开发阶段使用的辅助轮，构建时全部剥离，然后祈祷代码能在生产环境跑起来，因为测试曾经通过过一次。…
你的验证层比业务逻辑还庞大
手动验证会让 codebase 膨胀不堪，却依然遗漏边界情况。下面介绍如何通过声明式 schemas 强制执行 runtime contracts，同时让它们不碍你的事。
每次 API 收到请求，你都要验证。每次函数收到来自外部系统的参数，你都要检查。如果手动完成这些工作，单个端点积累的验证代码就可能超过业务逻辑本身。 这是 runtime contracts 的隐性成本。你需要它们，因为 type system 会撒谎：通过 HTTP 传输的…
TypeScript strictNullChecks 是编译时守卫，而非运行时盾牌
严格模式能捕获你写出来的 null，却无法捕获来自 API、DOM 查询和 JSON.parse 在运行时抵达的 null。类型系统止步之处，正是你的防御开始之时。
你在 里启用了 ，修掉了每一个红色波浪线，满怀信心地把代码发布到生产环境，以为 和 已经是过去式。 随后后端响应变了结构，一次 DOM 查询返回了空值， 在 TypeScript 曾信誓旦旦保证安全的代码里抛出了 。到底发生了什么？ TypeScript…
在 AI 时代，代码评审会变成规格评审
当 AI 能从规格生成实现、测试和 contracts 时，人类最有杠杆效应的工作会前移到上游。最需要被严格审视的，是规格本身。
如果你已经用 AI 连续交付了几周以上，你大概认识这种感觉。 你打开一个 PR。代码够干净，命名也还过得去，测试也有。表面上看不出哪里明显坏了。可你还是会觉得哪里不太对。 也许 boundary 有点发虚。也许 contract 只是被默认存在，却没有被明确写出来。也许 happy path…
AI 安全栈: types、contracts、property tests 与 mutation gates
如果你想让 AI-generated code 能在生产环境里站得住，光靠 code review 不够。你需要一套从 type constraints 到 mutation testing 与 runtime containment 的分层安全栈。
AI-generated code 最大的危险，不是它总是错的。 真正危险的是，它经常“看起来已经对得足够可以 merge”。 这正是风险所在。明显有问题的 code 往往会被挡住。真正会进生产的是那种看起来合理、能过几个 happy-path tests、却悄悄削弱关键 boundary 的实现。…