EP5. 架构驱动生成实践
💡 从「写代码」到 72 项验证检查
「develop jsondb。」
典型 AI 可能欢呼*「没问题！」*并在屏幕上刷出几百行。Cocrates 又愉快地辜负我们的期待。
🦉 Cocrates：「你要用这个
jsondb做什么？我先设计架构，请你审查批准，再安全地生成代码。」
不是先挥斧（Do）——先完善蓝图（Plan）。这是 Cocrates 产出制品的规则。
本集跟随一句话——「帮我做」——看它如何变成六份 ADR、一份 spec、七个源文件和 72 项验证条目。
🏛️ 步骤 1. ADR — 用户直觉 vs. AI 的「省事建议」
与 Cocrates 对话中会出现一种模式：AI 本能地提议它训练最多、最容易实现的东西。没有人类锚点，你会漂向 AI 的便利。
本项目有三场激烈的架构辩论（ADR）。
1️⃣ [ADR 1] 存储模型：「NoSQL 更简单」vs.「我需要直观路径」
- AI 的首推： MongoDB 式集合-文档结构。
- 用户的刹车：「我需要路径可寻址的存储——
Set("episode/e1")→episode/e1.json。」 - 结果： 打破 AI 默认；转向文件夹/文件路径映射。
2️⃣ [ADR 2] 架构：「纯库更简单」vs.「多个 agent 会用它」
- AI 的首推： 单进程内部库——好处理。
- 用户的刹车：「若多个 AI agent 进程同时读写这个 DB 呢？我们需要客户端-服务器。」
- 结果： Cocrates 承认疏漏，围绕 REST API 服务器（
jsondbd）加 CLI 重新设计。
3️⃣ [ADR 3] 并发：「锁整个 DB」vs.「按文件锁」
- AI 的首推： DB 级锁——三行代码；写入时整个 DB 暂停。
- 用户的刹车：「服务器上那是巨大瓶颈！不同文件用 per-file locks。」
- 结果： 升级为用
sync.Map实现并发的高性能引擎。
💡 教训： 当 AI 说*「这样简单又好用」*，可能是对它好建的那个陷阱。只有人类知道真实上下文与场景。
📝 步骤 2. Spec — 一份蓝图
ADR 批准后，Cocrates 把决策合并成一部宪法：spec/jsondb.md。
自洽：只读这份文档，就能一眼看到十个 REST 端点、API 签名、CLI 命令和测试要求。
⚡ 步骤 3. Generation — 仅由 Spec 驱动
spec 锁定后，Cocrates 启用 spec-driven-generation。它忘掉模糊的开场提示，只按我们达成的 spec 编码。
- 产出： 七个核心 Go 库文件、REST 服务器、CLI、单元与集成测试——首次
go build与go vet即通过。
🔍 步骤 4. Verification — 72 项检查之网
代码完成不等于庆祝。Cocrates 运行 spec-driven-verification，把每条 spec 要求拆成清单并比对。
📊 记分板：72 项中 70 PASS，1 FAIL，1 不可验证
一处偏差，沉默的 AI 默认就在看似完美的森林里浮出水面。
🚨 抓到的偏差
- Spec：
jsondb schema set /blog/episode→PUT /schema/blog/episode - 实际代码： 重复斜杠 →
PUT /schema//blog/episode - 服务器容忍了——但 API 一致性被破坏。没有验证很容易漏掉。
🤫 未文档化的 ASR（沉默默认）
spec 沉默处，AI 做了六处隐式设计选择：
- 合并查询参数时缺少 URL encoding；数据更新时跳过 schema 再验证——等等。
💡 教训： 「有 spec——代码必须完美」 太天真。缺口会被任意填补——运行验证，让 spec 成为活文档。
📝 三行总结
- 怀疑 AI 的「最省事建议」。 业务上下文与性能是人类的事。
- Spec 是活的。 验证发现缺失需求时更新它。
- Cocrates 的价值不是打印答案。 是通过对话把控架构节奏，让你审视每一步。
🎬 下期预告
我们已在 Cocrates 设计体系上完成一整圈。该再进一步。
下一集：不止使用现有 skill——与 Cocrates 一起构建新的架构驱动生成 skill（例如文档/报告自动化）。动手做 skill。
在那之前，问自己：
「我有没有不假思索就复制粘贴 AI 的第一版代码建议？」
本系列介绍 Cocrates Harness 框架。Cocrates 是为苏格拉底式对话设计的 agent harness，使用户保留主导权并持续成长。