7 月 5 日凌晨一点多，我在一个空目录里开了 Claude Code，想做一个网站，用来分享一种特殊的"蓝图"：一份详细的软件架构加描述，别人拿到以后丢给 Claude Code 或 Codex，就能有约束地把项目构建出来。GitHub 分享的是成品，这里分享的是蓝图。那天早上七点前，一轮 deep research 加一轮复审，在目录里留下了 9 份 Markdown 文档；之后这个目录再没有动过。这篇记下这个想法、当时聊到了哪，以及它停在了哪里。
想法本身
当时我是这么跟 Claude Code 说的：
"有点类似github在分享成品的项目，我只需要分享蓝图，其他客户拿到蓝图，给到claude code或者codex，就能开始有约束的构建。"（2026-07-05）
我心里其实有不少关于蓝图的想法：框架、类别、运行和分享的模式。但我拿不准哪些可行、哪些已经过时。最担心的一点是，蓝图里写死的东西会变成负担，原话是"架构中存在老的方案或者老的约束，反而会让将来的更强的AI……发生歧义或者降低结果的性能或者水平"。另一个念头是供给：我电脑上有几十个 Claude 写的项目，它们能不能反过来变成蓝图。
那一晚是怎么聊的
我先进了 plan 模式，八分钟里连发了五条：说清楚想法；补上 GitHub 的类比；交代"这个小时我不在电脑前"，让它把各个分支、细分方向、执行细节都用 deep research 去摸一遍；提醒它把项目变蓝图的问题也算进去；最后让它把结果写成本地的多份 MD 文档。
Claude Code 开了六条并行的 deep research 轨道，每条内部再扇出多路搜索，关键结论用三票做对抗式验证。两点多撞上了用量上限。这个痕迹留在了文档里：一部分结论的第三票没投完，几组论文数字（往返保真、需求异味）被降成"中等置信"，旁边注明需要用时点开原文核对。
早上六点半我回来说"继续"，接着把模型从 Opus 切到 Fable 5，让它复审刚才的方案，问有没有问题、有没有更优的方式。复审列了十条修订，我回了一句"直接修改全部文档，落修订。"九份文档最后一次修改都在六点半到七点之间：总览、竞品与思潮、蓝图格式规范、平台与技术栈、赛道与冷启动、消费端运行时、项目逆向生产、参考来源，外加一个可以直接复制的蓝图模板。
调研给了哪些判断
下面是文档里的结论。都是 AI 调研加复审的产物，引用的论文和数字我没有逐条再核对。
第一，品类是真的，但我设想的那一格几乎没人占。规格驱动开发（SDD）已经是一股清楚的思潮，GitHub Spec Kit、Amazon Kiro 都在做，OpenAI 的 Sean Grove 讲过"规格才是有价值的产物，代码只是它有损的投影"。可它们分享的都不是整份应用蓝图。最接近的是 Tessl，2025 年 9 月以"Spec Registry"起步，预置了一万多份 spec，2026 年 1 月转成了"agent skills 的包管理器"，分发单元退回到"教 AI 正确使用某个库"这种组件级。初版把这当成警号，复审补了另一种解读：也可能只是 B2B 的商业原因，组件级 skill 有明确的买单方。
第二，"同一份蓝图生成同一个 app"不成立。文档引了 ACM TOSEM 上的实验：同一个 prompt 重复 5 次，47% 到 76% 的任务产出不是测试等价的。所以蓝图能卖的只能是"有约束、可验证的构建"：意图、约束、可以机器判定的验收，构建结果每次不一样，但都要过同一套验收。
第三，我担心的"旧约束拖累更强的 AI"是个真问题，文档给的解法是分层。蓝图分三层：意图（MUST），契约和验收（MUST / SHOULD），实现建议（SHOULD / MAY），强度按 RFC 2119 的措辞标注。技术栈、旧方案都放进第三层，并且写明可以整层替换，更强的 AI 只按前两层构建就行。规范里有一句很好用的自检：如果哪段读起来像代码，就是写过头了。
第四，验收怎么写。复审发现了一个内在矛盾：可执行的验收会把项目焊死在某个测试框架上，纯文字的验收又等于让 AI 自己出题自己判卷。最后的办法是把验收写成"契约级探针"，只针对 HTTP、CLI、UI 这些表面做断言，比如"POST 某个接口返回 200 且带某个字段"，任何技术栈的实现都能被同一套探针检验，单元测试留给智能体自己写。
剩下几条是风险。共享的蓝图本身就是间接提示注入的载体，文档把它列为第一天就要有的防线，早期靠人工审核上架。逆向那几十个项目可行，但往返有损，每条抽出来的声明要标 confirmed、inferred、gap 三态，半自动抽草稿、人工精修。还有版权：文档引了美国版权局 2025 年的报告，纯 AI 生成、没有实质人类作者的东西不受版权保护，人策展的蓝图才是能确权的资产。
复审改掉了什么
复审最大的一刀砍在我最初要做的那个东西上：网站。初版的 MVP 是先建一个蓝图网站，复审的理由是"管道是商品"，护城河在格式和信任，Spec Kit 也是靠一个仓库加一个 CLI 走起来的。于是路线改成五步：M0 先做格式的端到端验证，从一个项目逆向出一份蓝图，真丢给 Claude Code 构建，跑通探针；M1 用一个 GitHub 组织加三到五个模板仓库上架，人工审核，看 star、fork 和 "Use this template" 的转化；M2 才做一个薄 CLI，校验格式、生成 CLAUDE.md 和 AGENTS.md 这些外壳；网站排到 M3，而且写明"仅当 M1 有拉力"才做。
其他几条修订也都落到了模板里。蓝图顶部必须带一段"点火协议"，就是消费者可以原样粘贴给智能体的启动指令，因为"第三层可以整层丢弃"这个约定本身也只是软约束，智能体不读到就不知道。发布前要过稳定判据：同一份蓝图独立构建 3 次，至少 2 次全部 MUST 通过。种子蓝图别挑最有代表性的，挑"裸 prompt 会失败、蓝图能救"的，比如第三方登录、支付回调、部署配置；短链服务这种裸 prompt 就能做出来的，写成蓝图反而削弱价值主张。
停在了哪
7 月 5 日早上 6:54 最后一份文档改完，之后这个目录没再动过，会话记录里也没有这个项目的下一句话。记录里没有哪一句说"不做了"。能确定的是，在这台电脑的记录里，M0 那份蓝图没有逆向，五个里程碑看不到哪个开了工，总览最后列的三个待我拍板的问题也一直没回答：MVP 的蓝图粒度是整功能还是允许组件级；消费方主要是会用 Claude Code、Codex 的开发者，还是想要成品的非开发者；蓝图用英文为主，还是中文社区先行。
调研自己也承认了两处空白。一是变现和防同质化的一手资料偏薄。二是"分享整应用蓝图"这一层，除了 Tessl 没找到直接竞品，文档的原话是：这既可能是白空间，也可能是"不实用"的信号，列为 MVP 首要验证的假设。这个假设要靠 M0 去验，而 M0 在记录里还没有开始。