案例研究：本网站

你正在阅读的这个站点，运行在它所记录的方法论之上。它对 Deep Work Plan 进行了 dogfood：用的是同一套技能、同一套 /init 流程、同一套任何其他仓库都会使用的 .dwp/ 计划。这是一份真实的记述，而非一个假设。

之前

像大多数仓库一样，这个仓库并非为代理而建。上下文存在于人们的头脑与零散的笔记中，没有一个代理能够读取的单一事实来源，而接入一个新代理意味着每个会话都要重新解释这个项目。长周期的工作会发生漂移。

采纳 DWP

这个仓库通过一份单独的 Deep Work Plan 实现了 AI-first，该计划被分解为带验证关卡的原子化任务：

1. 把 Deep Work Plan 技能作为一次参考安装来安装，由 skills-lock.json 锁定。
2. 运行接入，从仓库真实的技术栈生成一份经过推理的 AGENTS.md、docs/ 树与各模块文档。
3. 构建跨代理的 .agents/ 套件——轻量的 dwp-* 命令委派器，以及一份与磁盘上存在之物相一致的目录。
4. 搭建被 gitignore 的 .dwp/ 工作区以存放计划与草稿。
5. 用 /dwp-verify 验证符合性。

每项任务都在被标记为完成之前，依据仓库真实的关卡——biome、astro:check、测试套件、生产构建，以及代理端点的一致性核查——加以验证。

之后

这个仓库如今依其自身的规范实现了 AI-first：一份经过推理的 AGENTS.md、一套分类的 docs/ 树、一套跨代理的 .agents/ 套件，以及一个被 gitignore 的 .dwp/ 工作区。任意代理——Claude Code、Cursor、Codex、Gemini、Copilot——都能打开它、读取其 harness，并执行长周期的计划，无需逐会话的悉心引导。

成果

这套方法论在它自己的源代码上自证：这个站点的构建与维护方式，正是它告诉你去构建你自己仓库的方式——遵循 /init.md。如果这套标准在这里、在生产中行得通，那它对你的仓库也同样行得通。