Skip to content

#Spec-driven development

0 items today
6/30Tue
  1. Johnny Butler · Agentic Engineering32

    适配器模式是商业杠杆,不是整洁代码:AI 编程智能体该如何理解它

    适配器模式的价值在于把外部供应商 API 翻译成应用自身理解的接口,避免供应商决策渗透整个产品,是商业杠杆而非整洁代码装饰。作者指出,让 AI 编程智能体"使用设计模式"多半只是空想,它能生成形似适配器的代码,却难以自行判断边界是否必要、测试该保护哪些行为、哪些取舍仍需人来做决定。作者附上一个 Ruby 供应商边界示例,展示适配器如何翻译供应商 API 并把接线留在核心调用代码之外。

    Awaiting translation

6/26Fri
  1. Johnny Butler · Agentic Engineering41

    AI 编程智能体指令里的“Write Clean Code”只是愿望,不是可执行指令

    针对 AI 编程智能体指令文件中常见的“写整洁代码”“用 TDD”“遵循 SOLID”等表述,作者指出这些说法本身没错,但都不是可自我执行的指令。智能体主要复用代码库中已有的模式,在好坏混杂的真实代码库里,这类指令只是表达愿望。作者主张改为展示好与坏的具体样例,并让智能体证明自己实际遵循了哪些模式、在哪里应用、如何验证结果。

    Awaiting translation

5/22Fri
3/13Fri
  1. Ryan Lopopolo71

    别再把代码当成最终产物:Symphony 作者谈规范驱动开发

    Ryan Lopopolo 以 Symphony 为例提出,代码不应被视为最终产物,规范才是分发物。Symphony 是一个基于 issue tracker 的智能体编排系统,先以 SPEC.md 形式分发,Elixir 参考实现只是衍生产物,README 邀请读者把 SPEC.md 交给自己的编码智能体,用任意语言重建。

    Awaiting translation

    Why it matters: 作者用 Symphony 的 spec 蒸馏循环说明代码只是可替换产物,为规范驱动开发提供了一条可迁移的路径。

3/4Wed