---

用 AI 编程这一年，从一句话让它生成代码、到 vibe coding 式地边写边改，你大概率都配过规则文件：CLAUDE.md、.cursorrules、AGENTS.md，叫法不重要。

但真正喂给 AI 的那些“上下文”，其实散得到处都是：

• 一半在聊天记录里，窗口一关就没了；
• 一半在一个越堆越长的 CLAUDE.md 里，塞到自己都不想翻；
• 剩下的在你脑子里，换个人、换台机器就断了。

结果就是：每开一个新会话，你都得把项目重新交代一遍；同一件事，今天这么说、明天那么说，口径天天漂。

治本的办法只有一个：把这些上下文从聊天和脑子里搬出来，放进仓库、纳入版本控制，和代码一起 commit、一起演化、一起 review。落到目录上，就是给仓库开一个 .ai/。

下面按三步讲清楚：这套做法的来历（凭什么信它）、.ai/ 里到底装什么、以及为什么非得是个目录。

一、这不是我拍脑袋发明的：上下文进仓库已有权威背书

在你觉得“又是谁自创的小众玩法”之前，先把来历讲清楚——“给 AI 的上下文该进仓库”这件事，已经有真正的权威标准在背书了。

约定	谁的	本质
CLAUDE.md	Claude Code	把规则放进仓库根目录
.cursor/rules	Cursor	同上，支持按 glob 分文件
GEMINI.md	Gemini CLI	同上
AGENTS.md	OpenAI Codex、Cursor、Google Jules、Factory 等共建	跨工具开放标准

最有代表性的是 AGENTS.md：它不是某一家的私有格式，而是一票厂商共建的开放标准，2025 年 8 月发布，已被六万多个开源项目采用，年底还被捐进了 Linux 基金会旗下的基金会托管。换句话说，它已经是这个领域事实上的通用约定。

方向是一致的：AI 协作的上下文，该和代码住在一起。 我下面要讲的 .ai/ 目录，不是另起炉灶，而是在这条被权威背书的路上再往前一步——从“一个文件”，走到“一个分门别类的目录”。

二、.ai/ 里到底装什么

以我维护的一个真实后端项目为例（技术栈是 .NET，但这套结构跟语言无关），.ai/ 下大致是这么分工的：

.ai/
├── rules/        # 给 AI 的硬规矩：怎么写、什么不能碰、什么必须先确认
├── tasks/        # 把口头需求编译成的任务单，带验收清单
├── domains/      # 各业务域的领域知识（这块代码到底在干什么）
├── flows/        # 关键流程怎么走的说明
├── prompts/      # 固化下来、反复要用的提示词模板
└── 总规则文件     # 串起这套目录该怎么用

AI 干活就照这套来：接个需求，先编译成 tasks/ 里的任务单；改完代码，再回头同步对应的 domains/、flows/ 文档。

需求进来、代码出去、知识库跟着一起长。它最实在的好处是：每开一个新会话，AI 都能照这套目录快速恢复上下文、按统一口径干活，你不用每次从头交代。

三、为什么非得是“目录”，一个文件不够吗

很多人会问：我塞一个大 CLAUDE.md 不行吗？

试过的人都知道，单文件很快会撑爆：

单文件的问题	具体表现	目录怎么解
装不下	硬规矩+任务+领域+流程几千行，自己都不想读，AI 也被无关内容稀释	每块各管一摊
职责混	改个任务模板，跟领域知识挤一处，改一行牵全身	分别演化，互不干扰
检索难	AI 每次全量加载一个大文件，又烧 token、又抓不住重点	按需加载，用到哪块读哪块

拆成目录就两样关键好处：每块各管一摊、能分别演化；按需加载、用到哪块读哪块。这才撑得住长期协作。

顺带和市面上 dotai 这类工具比一句：它们大多解决的是“同步”——把一份规则分发到 Cursor、Claude、Gemini 各家的位置，很有用；但它们没解决“治理”——这套规则本身会不会过期、谁来维护、怎么防它腐化。那是另一个话题，后面单独讲。

你可以直接拿去用的提示语

道理说完，你大概率卡在同一个地方：现有的上下文乱成一团，从哪起步？下面这条提示语让 AI 帮你把散落的上下文收敛成一个 .ai/ 初始骨架——别一次求全，先搭起来。

我用 AI 辅助开发，但给 AI 的上下文现在很散：一部分在聊天记录里，
一部分塞在一个越来越长的 CLAUDE.md（或 .cursorrules）里，还有一些只在我脑子里。
我想把它们收敛进一个 .ai/ 目录、纳入版本控制。

别动业务代码，先帮我做两件事：
1. 扫一遍当前项目和我现有的规则文件，把散落的上下文按类型归一归：
   哪些是给 AI 的硬规矩、哪些是任务、哪些是领域知识、哪些是流程说明、哪些是可复用的提示词模板。
2. 据此给我一个 .ai/ 目录的初始骨架：列出该建哪些子目录、每个目录放什么、
   建议先从哪几个建起（不必一次到位），并把我现有 CLAUDE.md 里的内容拆分、归位到对应目录。

只输出骨架方案 + 归位建议，先别替我写每个文件的具体内容。

它给的是起步骨架，不是终态——该建哪些目录、先从哪几个起、现有内容怎么拆，你结合项目拍板。.ai/ 是跟着项目长出来的，不是一次设计完的。

一句收束

AI 协作的上下文，是和代码同等的资产；是资产，就该进版本控制、跟着代码一起演化，而不是活在一个随时会关掉的聊天框里。

给你的仓库开一个 .ai/ 目录，就是把这件事认真对待的第一步。至于 .ai/ 里到底该写什么、最不该放什么、怎么让它不腐化，每个都够单独一篇，后面慢慢聊。

你现在给 AI 的上下文，是散在聊天记录里，还是已经进了仓库？评论区聊聊。