开发者让Claude写代码前先写一天计划，评论区：这不新鲜

先花一天写计划，再让 AI 写代码

过去一年多，有位开发者的固定规矩是：让 Claude 写代码之前，先花一整天甚至更久，只写一份 Markdown 格式的项目计划。

最近这个项目上，他编码前花几天反复改 project_plan.md 和 implementation_plan.md，当场看到回报。第一版草案原本打算用内嵌的 Axum mTLS 服务器做同步，改规范时发现改用 iroh（QUIC）、按 Ed25519 公钥拨号加 mDNS 要干净得多，省掉了几周白写的代码。

计划里还锁死了同步和加密方案。密钥放在操作系统钥匙串里的 Ed25519/X25519，不建云账户；SQLite outbox 触发器加上混合逻辑时钟，做字段级冲突合并；团队留一份签名的成员日志，成员被移出时轮换保险库密钥。

这套做法不新鲜，谷歌只是把其中一部分自动化了。

一头大象、一条金鱼

这套 EGM 插件基于 Dave Rensin 的文章，针对对话偏见：同一场对话聊得越久，越容易顺着前面的思路点头。插件分三块。

Elephant（/egm-brainstorm、/egm-draft）是一个长上下文会话，访谈使用者，把需求写成 Markdown 规范。硬规则：一行代码都不写。

Goldfish（/egm-review）生成无状态的子代理。这些审查者对刚才的头脑风暴聊天零记忆，只冷读 .md 规范和代码仓库，以对抗性审查者的身份，在动代码之前把边缘情况和歧义挑出来。

Drift Check（/egm-drift-report）拿最终的代码 diff 去对 .md 规范，看写出来的东西是不是计划里的东西。

分工很清楚：写计划的那一端允许上下文很长，审计划的那一端故意什么都不记得。

评论区说这不新鲜

帖子下 71 条讨论。高票评论把流程概括成“规划细化加开冲刺”，说重新发明工程的人多到像笑话。

更多人指向同一件事：这些功能工具里已经有了。有评论说 Claude Code 现在几乎不用提示，就会自己产出 Markdown 和计划，然后照着往下推；有评论说这是“刚发现子代理和编排”；有人把类似私藏技巧叫做 PRD.md——把详细步骤列进文件，指一个新子代理过去说“处理用户故事 X”就完事；Superpowers 也被点名，一个评论说这技能基本就干这个，另一个直接问，这跟 Superpowers 或 /plan 有什么区别。

批评更彻底的一位说：Markdown 方案全是垃圾，系统全活在散文里，工作流早晚散架。他的解法是工作图和知识图。

空白

EGM 是否已经进入主流编程工具，没有明确说法。零上下文的审查子代理在真实项目里能不能抓到有价值的歧义，现在也没有公开的效果数据。纯 Markdown 计划与结构化工作图在长期维护上的差距，同样缺对照。插件能否用在编程之外，比如写作或项目管理，没有说明。被反复确认的反而是另一件事：这套流程早就以别的名字存在于现有工具里。