化学专业作者，70 天做出 10 万行分布式系统：这篇论文把 Vibe Coding 讲明白了
论文地址：https://arxiv.org/pdf/2602.20478
最近看到一篇很有意思的论文，题目叫 《Codified Context: Infrastructure for AI Agents in a Complex Codebase》。作者本身主要背景并不是软件工程，而是化学；但他在大约 70 天的兼职开发里，用 AI Agent 做出了一个 约 10.8 万行的 C# 分布式系统。
这篇论文最值得看的，不是“AI 又写了多少代码”，而是它把一个关键问题讲透了：
AI 真正缺的，不是编码能力，而是持续、稳定、可复用的项目记忆。
论文里直接指出，AI coding agent 的主要问题不是不会写，而是跨会话失忆：它会忘记项目约定、忘记之前踩过的坑，也无法天然继承团队经验。单靠一个 .cursorrules、CLAUDE.md 或 AGENTS.md，在小项目里还够用，但一旦到 10 万行级别，就明显不够了。
作者的解决办法很像是在给 AI 建“记忆系统”，并且是按人类认知方式来分层的：
第一层：热记忆（Hot Memory）——项目宪法 Constitution
这是一个始终加载的核心文件，论文里大约 660 行。里面放的是项目目标、技术栈、代码规范、命名约定、常见失败模式，以及“遇到什么任务该调用什么专家 Agent”的触发表。它回答的是：哪些规则必须永远遵守。
第二层：工作记忆（Working Memory）——专家 Agent
作者一共做了 19 个专业化 Agent，总计约 9300 行规格说明。不同 Agent 负责不同领域，比如网络协议、坐标系统、调试、架构审查等。它们不是泛泛地“更聪明”，而是提前注入该领域的错误模式、注意事项和输出格式。也就是说，不是让 AI 临时猜，而是让它带着“预装领域知识”上场。
第三层：冷记忆（Cold Memory）——按需检索的知识库
作者还维护了 34 份规格文档，总计约 1.6 万多行，作为按需调用的“长期记忆”。这些文档不是写给人看的，而是明确写给 AI 看的：要有文件路径、参数名、函数名、预期行为、清晰的 do / don’t。它回答的是：某个子系统到底是怎么工作的。
这套体系最后长成了一个相当夸张的规模：
在 283 次开发会话里，作者累计有 2801 次人工提示、1197 次 Agent 调用、16522 次 Agent 轮次；整个“上下文基础设施”加起来约 26200 行，相当于代码规模的 24.2%。论文特别提醒，这个比例不是目标值，但它说明了一件事：复杂项目里，文档不是附属品，而是 AI 能否稳定工作的基础设施。
我觉得这篇论文最有启发的，不是它的数据，而是它总结出来的几条实践原则：
1）尽早建立“宪法”
哪怕一开始只有项目目标、技术栈、核心约定，也足以从第一天起减少一整类 AI 错误。论文原文把这点总结成：A basic constitution does heavy lifting。
2）文档要写给 AI 看，不是写给人看
人类文档喜欢抽象、喜欢叙述；AI 文档要具体、可执行、可定位。
要写清楚：
-
文件路径
-
关键函数名
-
约束条件
-
明确的“这样做 / 不要这样做”
这不是“文档美学”，这是给模型减少歧义。
3）同一件事解释过两次，就应该写下来
论文给出的原话几乎就是这句：If you explained it twice, write it down.
只要你发现自己反复向 AI 解释同一套业务规则、架构约定或领域知识，这就是一个明确信号：它已经不该再存在于聊天记录里，而应该沉淀成规范。
4）卡住时，不要死磕，创建专家 Agent 重启
如果某个领域调了很久还没解开，继续在通用上下文里硬磨，往往只是在消耗 token 和注意力。更好的做法是：把这个领域的规律、错误模式、边界条件整理出来，做成一个专家 Agent，然后重新开始。论文也明确总结为：When in doubt, create an agent and restart.
5）最危险的问题不是不会写，而是“文档过期”
论文特别强调：过期规格是主要失败模式。
因为 AI 会“相信文档”。一旦规范落后于代码，它就可能生成语法正确、但方向错误的实现，而且这类错误常常要到测试阶段才暴露。作者甚至做了一个 context drift detector，在会话开始时检查最近代码变更和文档是否同步。
还有一个很现实的点：
很多人会觉得“文档化很重”。但论文给出的实际维护成本并不离谱——当相关规格受影响时，同步更新文档通常只多花 约 5 分钟；再加上双周一次的全量回顾，整体维护成本平均 每周约 1–2 小时。
所以这篇论文最值得借鉴的结论，我会概括成一句话：
AI 编程一旦进入复杂项目阶段，真正决定上限的，不是模型有多强，而是上下文有没有被“工程化”。
谁能把项目目标、架构约定、领域知识、错误经验，按“热记忆 / 工作记忆 / 冷记忆”分层固化下来，谁就更容易把 AI 从“偶尔灵感爆发的助手”，变成“能持续协作的执行系统”。
如果把这篇论文放在今天的语境里看，它其实讲的不是“怎么更会 Vibe Coding”，而是：
当项目变复杂后，Vibe Coding 必须升级为 Context Engineering。
感觉流可以启动项目，但文档化的上下文基础设施，才决定项目能不能持续推进、能不能多人协作、能不能越做越稳。