一年多来，我每次提示 Claude 之前都会花一整天写一份 Markdown 规格。Google 刚刚开源了"大象-金鱼模型"，把这套做法又往前推了十倍

无论你已经编程超过15年，还是一个月前才开始用Claude“随心编码”，你可能都遇到过同样的瓶颈：让AI直接开始写代码，前两个小时感觉如魔法般顺畅，但到了第三天，你就陷入了长达150条消息的对话中——修了一个bug，又破坏了另外两个地方。

一年多来，在让Claude写代码之前，我每个工作项目和副业项目的规则都很简单：先花一整天（甚至更久）专门在Markdown（.md）文件中制定详细的项目计划。

在我最近的一个项目中，在编码前花几天反复修订project_plan.md和implementation_plan.md的效果立竿见影：在纸上就否定了糟糕的架构设计：第一稿曾打算使用嵌入式的Axum mTLS服务器来实现同步。

但在细化需求时发现，基于Ed25519公钥加mDNS进行QUIC拨号的iroh方案要简洁得多，从而避免了几周的无效代码开发。明确了同步与加密机制：将Ed25519/X25519密钥存放在操作系统钥匙串中（不依赖云端账户），通过SQLite的发件箱触发器配合混合逻辑时钟（HLC）逐字段合并冲突，并维护一份经过签名的团队成员日志，当有成员退出时轮换存储库的加密密钥。

谷歌刚刚开源了Elephant-Goldfish Model（EGM）插件（opensource.googleblog.com/2026/10/intro...ng-elephant-goldfish-model-plugin.html），该插件基于Dave Rensin的文章，将这种Markdown工作流又推进了一大步，有效缓解了对话中的偏差问题：Elephant（/egm-brainstorm、/egm-draft）：这是一个长上下文会话，会与你互动并撰写Markdown规格文档，严格规定它绝不编写任何代码。

Goldfish（/egm-review）：它会生成无状态的子代理，这些子代理对你的头脑风暴聊天毫无记忆，仅以冷启动的方式阅读你的.md规格文档和代码仓库，像对抗性的评审者一样提前暴露边缘场景和模糊之处，确保在任何代码写出之前就发现问题。

漂移检查（/egm-drift-report）：它会将最终的代码差异与.md规格文档进行比对。你们当中有多少人在编码前会保留project_plan.md？

有没有人已经开始对自己的规格文档运行零上下文的评审子代理？