适配器模式是商业杠杆，不是整洁代码：AI 编程智能体该如何理解它
适配器模式的价值在于把外部供应商 API 翻译成应用自身理解的接口，避免供应商决策渗透整个产品，是商业杠杆而非整洁代码装饰。作者指出，让 AI 编程智能体"使用设计模式"多半只是空想，它能生成形似适配器的代码，却难以自行判断边界是否必要、测试该保护哪些行为、哪些取舍仍需人来做决定。作者附上一个 Ruby 供应商边界示例，展示适配器如何翻译供应商 API 并把接线留在核心调用代码之外。
#规范驱动
#规范驱动
今日 0 条Johnny Butler · Agentic EngineeringAI 评分3232
Johnny Butler · Agentic EngineeringAI 评分4141 AI 编程智能体指令里的“Write Clean Code”只是愿望，不是可执行指令
针对 AI 编程智能体指令文件中常见的“写整洁代码”“用 TDD”“遵循 SOLID”等表述，作者指出这些说法本身没错，但都不是可自我执行的指令。智能体主要复用代码库中已有的模式，在好坏混杂的真实代码库里，这类指令只是表达愿望。作者主张改为展示好与坏的具体样例，并让智能体证明自己实际遵循了哪些模式、在哪里应用、如何验证结果。
Kondasamy Jayaraman · Engineering BlogAI 评分6666 别再给产品加 AI：AI 原生设计的 10 个模式
作者结合 18 个月构建智能体系统的经历提出，AI 原生设计应先问“这块能不能删掉”，而不是“能不能加上 AI”，并称自己的技术栈随模型变强缩减了 60-70%。
Ryan Lopopolo精选AI 评分7171 别再把代码当成最终产物：Symphony 作者谈规范驱动开发
Ryan Lopopolo 以 Symphony 为例提出，代码不应被视为最终产物，规范才是分发物。Symphony 是一个基于 issue tracker 的智能体编排系统，先以 SPEC.md 形式分发，Elixir 参考实现只是衍生产物，README 邀请读者把 SPEC.md 交给自己的编码智能体，用任意语言重建。
推荐理由：作者用 Symphony 的 spec 蒸馏循环说明代码只是可替换产物，为规范驱动开发提供了一条可迁移的路径。
Drew BreunigAI 评分7171 从 whenwords 到 Plumb：规范驱动开发三角如何保持同步
Drew Breunig 在 MLOps Community 的 Coding Agents 会议上分享了他构建无代码库 whenwords 的经验，并提出规范驱动开发不是单向方程而是三角反馈循环：写代码会反过来改进规范和测试。