推荐这个思路。Google 工程师 Matt Rickard 提出了一个概念叫"mini-app spec"——用可执行的小型浏览器制品来替代纯文本 spec。Markdown 为人类可读性赢了，但它对 agent 不是最强的合约。Mini-app spec 把 prose、结构化数据、原型行为、注解和对账检查装进一个东西里。核心思想就一句："spec 最高的工作是在实现不断变化时，保住你最初的意思。" Mini-App Spec 的不合理有效性 HTML 是新的 Markdown。但 mini-app 是新的 HTML。 今天 agent 的工作流很简单：写一个 Markdown spec，让 agent 构建，然后人工检查结果是否匹配原始意图。Anthropic 的 Thariq 说得很对：HTML 改善了信息密度和阅读便利性。但更深层的问题是对账。 Mini-app spec 是一个小型的、浏览器原生的制品，它把 prose、结构化数据、原型行为、注解和检查结合在一起。 最好的 spec 格式是把意图和实现保持得最近的格式。Markdown 赢了，因为人类可以读它——不是因为它对 agent 是最强的合约。它干净、便携、容易编辑、高效。但它的结构大多是隐含的：需求、约束和边缘情况坍缩成 prose 和项目符号。 Spec 的最高工作是：在实现不断变化时，保住你最初的意思。 这就是为什么很多人更倾向于一个快速原型而非文档。原型携带着 prose 会丢失的行为。但原型和 spec 通常分开存在——原型展示了感觉是什么样的；spec 记录了想要的是什么。一个 mini-app 把它们放在一起。 对账检查 Mini-app spec 不只是对 Markdown spec 的美化。它引入了自动检查： • 模板对账。把模板写成 React 组件的 props，这样它们不会从约定格式漂移。没有缺失的章节、没有回退。更新自动传播到下游消费者。 • 文件树对账。Spec 中的包和文件是否存在？有多余的吗？ • 测试对账。Mini-app spec 不替代单元测试或集成测试。它回答元问题：spec 中的测试存在吗？它们在通过吗？你能按需运行它们吗？ • 配置和密钥对账。Spec 通常包含应用需要的配置键，但不包含值。比如 Service A 需要一个 OPENAI_API_KEY。Spec 可以报告这个密钥是否存在并绑定到了正确的地方。 工作流三层 | 层级 | 做法 | |------|------| | Markdown loop | 写 spec，构建实现，人工比对 | | HTML loop | 写更丰富的 spec，构建实现，用更好的可视化人工比对 | | Mini-app loop | 建模意图，嵌入原型，构建实现，运行对账检查 | Markdown loop 是今天大多数人的做法。HTML loop 加了可视化密度——你能看到它应该长什么样。Mini-app loop 是最高的——你不仅能看到，还能机械地对账意图是否被实现了。 下一步是让这个制品足够可执行，能参与到构建循环中。注解可以关闭另一个环：人类可以在精确渲染的子树上画圈或指向——"这个不对"——然后 agent 修复那一个点而不是整个东西。 原文： #Spec# #Agent工作流# #前端#