让他们写 RFC

# 让他们写 RFC 来源：https://ohadravid.github.io/posts/2026-08-let-them-write-rfcs/ 或者：为什么我花了数亿个 token 写同一份 markdown 文件的四个版本。 --- 我正在做一个复杂的项目，它*刚好*超出我目前知道怎么构建的范围，这很有意思！但也很难，尤其是当我试图用 LLM 来加快速度时。[1](https://ohadravid.github.io/posts/2026-08-let-them-write-rfcs/#fn:1)结果： 1. 有时我对问题的理解不够充分。 2. 有时我*不知道*自己理解得不够。 3. 有时，由于第 1 点和第 2 点，我很容易被听起来[不错](https://www.paulgraham.com/goodwriting.html)的想法愚弄。 有人会说，一个人不应该在几乎什么都不懂的情况下，只凭一腔热情就去做事。 化学狗，配文“我完全不知道自己在做什么” 这是一派胡言。我*从来*不是在开始做某件事时就对它有了很好的理解。做这件事，才是你理解这件事的方式！ 但这些问题*确实*会被 LLM 的使用放大：摩擦被消除了，所以你可以*继续*做这件事，却并不理解它，甚至没有注意到自己不理解，这当然让你更容易被欺骗——从而陷入一个可怕的 LLM 精神错乱循环。 再结合当代 LLM 那种顽强地朝一个目标猛冲的倾向，你就明白为什么人们会失去理智了。 《魔法师的学徒》——幻想曲中的扫帚场景 在这个项目中，有两件事帮了大忙。第一件事是扔掉代码库的两个“完整”实现。没有什么比糟糕的初稿更能教会你理解一个问题了，而在如今，构建糟糕的初稿已经变得（过于？）经济了。但即便是这些粗糙的初稿，也清楚地表明事情会在预期和意想不到的地方出错。所以，虽然我对问题有了*更多*了解，但我也隐隐觉得前面还有*更多更多*未知。 ## 优化目标是讨论问题，而不是解决方案 当你要求 LLM[2](https://ohadravid.github.io/posts/2026-08-let-them-write-rfcs/#fn:2)解决一个问题时，即使在计划模式下，它也会优化“如何解决这个问题”（废话）。即便它会问几个追问，这些问题也是为了最终解决问题——通常是一头扎向最直接可行的方案。这样做得次数足够多，你就会淹没在劣质内容里。 如果你知道自己要找的是什么，你就能朝着正确的解决方案前进。但当你不知道时，你会怎么做？尤其是当你*应该*怀疑自己对问题了解得还不够时？我们总不能一直把*所有*代码都扔掉！ 我开始要求（有时是在激烈的[漫谈](https://x.com/guinnesschen/status/2068744472528314811)之后）：“……这就是我们目前面临的模糊问题。**请写一个名为 $PROBLEM_RFC.md 的 markdown 文件**，描述这个问题以及如何解决它。*保持行文[3](https://ohadravid.github.io/posts/2026-08-let-them-write-rfcs/#fn:3)简短，给出好的代码示例*。” **通过要求模型产出 RFC，我在优化理解和解释**，这让问题变得更可见。RFC 不太可能第一版就足够好，所以我会**迭代和修订**（V1.md、V2.md 等），查阅文档、查找资料，直到我对问题理解得足够好，并且认为这些想法是可靠的——而这个过程正是我大部分学习的发生之处。 我发现它既**更有用**——能产生更好的解决方案和代码；也**更有趣**——对我来说，比起阅读劣质代码，迭代 RFC 迫使我去解释自己不理解的地方，并专注于把握问题中最难的部分。 ### 为什么是 RFC 一份 RFC[4](https://ohadravid.github.io/posts/2026-08-let-them-write-rfcs/#fn:4)需要把几样东西送进我的大脑（💬➡️🧠）： 1. 问题*到底*是什么？ 2. 它有多糟，或者有多重要？ 3. 这个解决方案能解决问题吗？ 4. 与替代方案相比，这个解决方案的代价有多大？ 如果这些点没有说服我，尤其是对问题的定义，我就会直接问。“解释一下问题的这一部分”“为什么是这样而不是那样？”“那……呢？”“我们不是已经在……里做过这个了吗？”——一遍又一遍，直到我真正被说服。 RFC 对行文和解释性代码都有很高的标准，迫使 LLM 比读者承担更多的功夫，而且它让“