Fuck-u-code：你的 AI 流水线遗忘的确定性质量关卡
你已经有类型检查、代码风格审查和架构规则。但你的确定性栈对复杂度、重复代码和命名灾难视而不见。以下是零成本的解决方案。
老实说，现在大多数 AI 代码流水线到底是什么样子。 你用 Cursor 或 Claude Code 生成代码。你运行 ，因为 TypeScript 严格模式能捕获类型不匹配。你运行 ESLint，因为没人想在合并请求里争论分号问题。也许你还会运行…
想法与洞见
探索 AI 优先开发、编码护栏和可处置架构。
Rust 中的 property-based tests 能找到单元测试漏掉的 bug
基于示例的测试只覆盖你想得到的输入。property-based testing 生成随机数据，检查 invariants，并将失败 shrink 到最小反例。
你写了一个 函数。你用 和 测了它。测试通过。你发布了。 用户传入了一个单元素切片。你的函数把它漏掉了。他们提了 issue。你盯着测试文件，想不通这么明显的问题自己是怎么漏掉的。 你漏掉它，是因为 example-based testing 只能抓住你提前预料到的 bug。测试套件里的每一个…
为什么第一版从来不是问题：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…