15 posts
LLM 对话包含意图、被拒绝的替代方案以及可运行的代码。这正是文档应该包含的内容。以下是将 ephemeral chat 转换为持久、可搜索的文档，同时不丢失叙事的方法。
你花了 45 分钟和 Claude 设计一个 retry circuit。你解释了 failure modes，因为 exponential backoff 会掩盖 cascading pressure 而拒绝了它，确定了 token-bucket rate limiting with…
费根审查需要四到六个人、两小时才能审完250行代码。大语言模型可以通过承担准备工作和检查清单的执行来削减这部分成本，但它无法取代人类角色去发现最昂贵的缺陷。
一次完整的费根审查需要一名主持人、一名朗读员、两到四名审查员，以及作者本人。团队以每小时125行的速度，花费两小时审查大约250行代码。这意味着一次小小的改动就要消耗八到十二人时。 大语言模型可以在不到一秒内读完250行代码。它可以执行检查清单、标记可疑模式，并在任何人打开文件之前就生成一份结构化的缺陷记录。…
N-version programming 听起来很简单：运行多种实现，然后挑出最佳答案。但在实践中，'最佳'远比'最常见'更难定义。
你有同一个函数的五种实现。三种返回相同结果。一种略有不同。一种抛出异常。哪个才是对的？ 大多数团队默认采用多数投票。当输出完全一致、错误显而易见时，这招确实管用。但一旦各实现在细微之处产生分歧，或者每个变体都给出不同答案时，这套机制就会崩解。N-version programming…
基于 LLM 的 N 版本编程不需要多个模型。通过变化提示词、角色设定和推理约束，你可以从单个模型中提取多样化且正确的实现。
N 版本编程默认多样性来自不同的作者。对 LLM 来说，这意味着不同的模型、不同的提供商，甚至不同的训练批次。但这个假设是错的。你可以通过改变提问的方式，而不是提问的内容，从同一个模型中获得有意义的多样性。 问题在于：把 temperature 调到 1.0…
AI 编码遵循一条验证梯度：后端在毫秒内确定性地验证，Web 需要分钟级的视觉回归，移动端受限于物理现实需要数小时。验证速度和确定性沿着这条光谱递减，反馈循环直接决定了 AI 编码在哪里能发挥作用、在哪里会碰壁，决定了AI编码的可行边界。
AI 模型自己写代码并不是最有趣的部分。有趣的是它生成代码之后发生的事情。模型能以多快的速度知道代码是否正确？生成与验证之间的反馈循环有多紧密？ 这个循环决定了一切。它决定了模型能否对自己的输出进行迭代。它决定了人类是否可以在不经手动检查的情况下信任输出。它决定了 AI 编码在哪些领域真正有效。…
AI 编程对能够从任何混乱中恢复的精英团队有效。其他人则只能面对恐惧、失败的 CI 和被放弃的实验。差距不在模型本身。
观察两个团队使用同一个 AI 模型，你会看到两种完全不同的结果。 第一个团队让模型构建一个界面。输出接近但不够准确。样式偏离了 Figma 文件。状态管理触及了不该碰的文件。构建在本地通过但在 CI…
大多数团队尝试 AI 编程，代码上线后被 QA 驳回，然后放弃。问题不在于模型——而在于缺少让 AI 输出变得可信任的护栏。
大多数尝试 AI 编程的团队都遵循相同的轨迹。 他们一开始充满热情。模型在几分钟内生成了功能，他们把它发布了。QA 发现了一个 bug，于是他们发布了修复。QA 又发现了一个 bug，这次在一个本应毫无关联的 module 里。修复涉及十四个文件，QA 又发现了三个新问题。…
你已经有类型检查、代码风格审查和架构规则。但你的确定性栈对复杂度、重复代码和命名灾难视而不见。以下是零成本的解决方案。
老实说，现在大多数 AI 代码流水线到底是什么样子。 你用 Cursor 或 Claude Code 生成代码。你运行 ，因为 TypeScript 严格模式能捕获类型不匹配。你运行 ESLint，因为没人想在合并请求里争论分号问题。也许你还会运行…
AI 编程工具擅长生成第一版。真正的工程挑战始于第四版——当团队需要改动某些东西而不破坏其他一切时。
每个 AI 编程演示都遵循相同的套路。有人向模型发出提示。一个能工作的应用凭空出现。观众印象深刻。 他们理应如此。速度是真实的。能力是真实的。有 AI 参与时，第一版确实发布得更快。 问题在于，第一版从来不是难点。 软件工程的成本不集中在初始创建阶段。它集中在第四、第五、第六次迭代：…
衡量 AI 生成代码质量的真正标准不是它在第一天能否运行，而是在第三十天你能否在不 rewrite 其他所有内容的情况下替换它。
关于 AI 生成代码质量的大多数讨论都聚焦于生成时的正确性。输出能编译吗？能通过测试吗？符合规格说明吗？ 这些只是基本门槛。它们无法告诉你真正的成本。 真正的衡量标准是可替换性：当需求变化时，你能以多低的成本删除这个 module 并在相同的 contract 背后重新实现它？ 如果答案是"轻而易举"，那么 AI…
人工审查不一致，AI 审查更不可靠。AI 生成 codebase 唯一可扩展的防线是确定性 enforcement：让构建失败的规则，而非被忽视的建议。
对 AI 生成代码的标准建议是"仔细审查"。 这个建议正确但在规模化时毫无用处。 开发者审查 AI 输出时，在精力充沛、熟悉领域且没有时间压力的情况下能发现问题。在其他所有条件下——而这是大多数情况——问题会漏过。 用 AI 审查者来发现 AI…
当 AI 能从规格生成实现、测试和 contracts 时，人类最有杠杆效应的工作会前移到上游。最需要被严格审视的，是规格本身。
如果你已经用 AI 连续交付了几周以上，你大概认识这种感觉。 你打开一个 PR。代码够干净，命名也还过得去，测试也有。表面上看不出哪里明显坏了。可你还是会觉得哪里不太对。 也许 boundary 有点发虚。也许 contract 只是被默认存在，却没有被明确写出来。也许 happy path…
如果你想让 AI-generated code 能在生产环境里站得住，光靠 code review 不够。你需要一套从 type constraints 到 mutation testing 与 runtime containment 的分层安全栈。
AI-generated code 最大的危险，不是它总是错的。 真正危险的是，它经常“看起来已经对得足够可以 merge”。 这正是风险所在。明显有问题的 code 往往会被挡住。真正会进生产的是那种看起来合理、能过几个 happy-path tests、却悄悄削弱关键 boundary 的实现。…
这篇对 Stanford CS146S 的评析认为，它准确看到了 AI coding 的转向，但真正决定长期质量的仍是 AI architecture：系统是否可替换、可约束、可持续演进。
Stanford 的课程代码 ，课程全名是 The Modern Software Developer，由 Mihail Eric 授课，是一门在 2025 年秋季首次开设的课程。想看课程的官方概览和 syllabus 细节，可以直接访问官方课程站点…
Design by contract、property-based testing、mutation testing、model checking 从来不是坏思路。真正的问题是它们长期需要太多专业判断才能维持，而 AI 正在改变这笔账。
软件工程里有很多方法，你一读就会觉得“这当然应该这么做”。 当然应该用 contracts 明确 function 能接收什么、必须返回什么。当然 tests 不该只写几个人工挑选的例子，而应该验证 properties。当然团队不该把 coverage 当成质量代理，而应该真的去判断 tests 能不能抓到…