A-ISL用可审阅规格驱动多技术栈代码生成

A-ISL 是一个实验性的 AI 编程项目：先让 coding agent 把自然语言需求写成可审阅的规格，人工确认后，再显式调用另一项技能生成代码。同一份规格可面向 React、Blazor、WinForms 等技术栈，核心设计是把需求确认与代码生成分开。

目前能确认什么

流程分两步：a-isl-spec-author 只生成 .isl.md 规格文件；用户审阅并接受后，再调用 a-isl-compile，将应用生成到 bin-<stack>/。规格生成后不会自动触发代码生成。作者强调，审阅首先看产品行为是否正确，不要求用户掌握规格语法。

这里的「编译」由 agent 配合运行时完成，不能直接等同于传统编译器的确定性转换。规格驱动的通用思路，是先明确行为约束，再据此实现；规格写错，实现也可能忠实地执行错误要求。

内部测试只有 5 例。在规则封闭的小任务上，规格流程与单次提示在 JS 上均为 5/5。C# 单次提示首次为 1/5，但补上相同的「优先使用 records」规则后，差距消失。日常使用和测试均在 Cursor 上完成，其他宿主尚未单独测试。

我的判断

可借鉴的是人工审阅关口，效果优势尚未得到证明。

对程序员而言，这种流程可以把需求讨论落到可检查的规格文件上。尤其在生成多个技术栈实现时，先确认共同的行为要求，有助于明确后续核对的依据，但不能据此认定各端行为已经一致。

C# 测试还提示了一个具体问题：提示中的约束是否一致，会直接影响比较结果，不能把规则遗漏造成的差距算成流程优势。

作者期待它用于大型、多模块项目和通过修改规格持续演进，但当前测试没有证明这些收益。修改规格后如何保留手工代码、怎样验证多端行为一致，给出的材料也没说清，仍需完整文档和更充分的测试确认。