夜雨聆风
AI项目规则模板.md：可以直接复制到项目里，让 AI 帮你初始化规则和记忆。AI项目规则模板.html：完整使用手册，适合先看懂流程，再动手改。
关注后回复 项目记忆 可以领取资料包。
你有没有遇到过这种情况：
一个项目明明已经和 AI 聊了好几轮，换个新窗口，它又像第一次见你。
你得重新解释项目背景、文件夹怎么分、哪些规则不能动、现在做到哪一步、上次已经确认过什么。
讲一次还行。讲多了，人会烦。
我是在开发工程里被这件事反复教育之后，才意识到一个更通用的问题：AI 的上下文管理，不只适用于写代码。
任何长期项目，都可以用类似的方法管理记忆、规则和材料。
稳定规则放在项目入口，动态进度放在记忆文件，具体材料留在对应目录。这样不管你换哪个 AI 工具，或者打开一个全新的会话，都不用先在聊天框里复述半天背景。
你只要说这次要做什么。
AI 会顺着项目里的规则去读：这是什么项目，现在在哪个阶段，需要调用哪些材料，应该按什么标准产出。
我最近整理自己的公众号资料库，刚好把这套方法落了一遍。这个文件夹以后会放重要资料、文章草稿、商务材料，还有一些临时记录。如果每次都靠我在聊天框里喂背景，AI 省下来的时间，很快又会被我喂回去。
所以我换了个办法。
不再把项目背景放在聊天里，而是放回项目文件夹。
我为什么要折腾这套规则
这不是为了显得专业。
长期用 AI 做项目，有三个问题躲不开。
第一个问题：新对话没有记忆。
你昨天让它整理过目录，今天再开一个窗口，它不一定知道昨天发生了什么。
第二个问题：工具之间不共享上下文。
你可能今天用 Codex，明天用 Claude，后天又在网页 AI 里问一句。聊天记录散在不同地方，但项目只有一个。
第三个问题：临时提示词越写越长。
一开始只写一句“帮我整理资料”。后来变成一大段：项目背景、目录规则、写作偏好、当前进度、注意事项。再后来，你自己都不想看。
这时候，问题已经不是提示词写得好不好。
是上下文放错了地方。
AGENTS.md 是把规则放到该放的位置
我在根目录放了一个 AGENTS.md。
你可以把它理解成“给 AI 看的项目入口协议”。
重点不是这个文件名有多神奇，而是我把项目规则细化成了两层：
项目级规则：这个公众号资料库是什么，一级目录怎么分，哪些决策要长期遵守。
子项目规则：文章管理、商务管理、重要资料这些板块，各自有自己的工作方法。
这就是分而治之。
根目录不用塞满所有细节。它只告诉 AI：这是一个微信公众号资料管理项目，主要分享 AI、科技、商务等方向的文章；当前目录怎么分；会话开始先读哪里；工作结束后哪些内容需要建议更新记忆。
比如现在有四个一级目录：
1-重要资料/2-文章管理/3-商务管理/4-杂项材料/
AI 进来之后，先读根目录的 AGENTS.md，至少不会把文章草稿扔进商务材料里，也不会把临时记录当成长期规则。
我还放了一个 CLAUDE.md。
这个文件只有一行：
@AGENTS.md它的作用很朴素：让 Claude 系工具也转去读同一份规则。规则只维护一份，不到处复制。
进度放进 .memory/，让 AI 跟上项目阶段
一开始我也想过：干脆把所有背景都写进 AGENTS.md，越详细越好。
后来觉得不对。
入口文件如果什么都装，很快会变成另一个没人想读的长提示词。
项目是会变化的。启动 → 规划 → 执行 → 监控 → 收尾，每个阶段需要 AI 关注的东西都不一样。
启动阶段，AI 要知道项目为什么存在、目录怎么搭。
规划阶段，AI 要知道目标、范围、优先级。
执行阶段，AI 要知道当前任务、已有材料、谁负责什么。
监控阶段，AI 要盯状态变化、风险和卡点。
收尾阶段，AI 要整理成果、复盘经验、归档长期记忆。
这些会变的东西，不适合写进入口。
我把它们放进 .memory/：
.memory/├── index.md└── project-status.md
index.md 是记忆索引，告诉 AI 有哪些状态文件可以读。
project-status.md 是当前状态快照，只回答几件事：
已经完成了什么
正在做什么
下一步是什么
哪些状态发生了变化
注意，是快照，不是日记。
我不需要它记录每一次聊天。那样很快又会变成垃圾堆。我需要的是下一次打开新对话时，AI 能知道项目现在在哪个阶段，该接着往哪儿做。
我的做法是：每次任务结束，让 AI 先列出建议更新的记忆条目。确认之后再写入 .memory/。
这样 AI 可以帮我追踪项目状态，但不会擅自把一堆临时想法写成长期规则。
子项目继续嵌套：规则可以一层一层往下长
根目录规则解决的是“这个项目是什么”。
但具体到某个长期板块，规则会更细。
比如 2-文章管理/ 是我以后最常用的地方。这里不是简单存几个 Markdown，而是要管理一篇文章从选题到发布的全过程。
所以我在这个子目录下，也放了自己的 AGENTS.md 和 .memory/。
这有点像递归。
同一套方法，在更小的范围里再跑一次：项目下面有子项目，子项目下面还有具体文章，具体文章里又有目标、素材、草稿、发布稿和复盘。
一篇文章的文件夹，大概长这样：
2026-06-14 别再反复给AI喂背景/├── 0-文章目标/├── 1-素材/├── 2-草稿/├── 3-正式发布/└── 4-杂项记录/
根目录的 AGENTS.md 会向下传导。 它定义整个公众号资料库的方向、目录边界和记忆协议。
子目录的 AGENTS.md 只管当前文件夹及其下面的工作。比如 2-文章管理/AGENTS.md 只约束文章创作，不去干涉商务合作怎么管。
好处很明显。
上层规则不用越写越胖。文章管理可以有自己的编辑流程，商务管理可以有自己的客户跟进规则，重要资料也可以有自己的归档标准。
AI 读到的不是一坨巨大的背景，而是一层一层靠近现场的上下文。
规则离工作现场越近，AI 越不容易跑偏。
我还给文章管理配了一个“编辑部”
写文章不是一个动作。
它是一串动作：
选题 → 素材 → 大纲 → 初稿 → 改稿 → 核查 → 发布 → 复盘所以我在 2-文章管理/AGENTS.md 里写了几个角色：
总编：看方向和标准
选题策划：找角度和标题
研究员：整理素材和来源
撰稿人：写大纲和初稿
编辑：调整结构和表达
事实核查：检查数据、引用和风险
归档员：维护目录和记忆
这不是角色扮演。
它解决的是分工问题。否则 AI 很容易一上来就写正文，写完才发现目标没定、素材没核、发布路径也没想清楚。
我还做了一个局部配置：把 writing-assistant-skill 和 patina 放在 2-文章管理/.skills/ 下面。
前者负责公众号文章的选题、标题、大纲、正文和排版方法。
后者负责检查并改掉一些常见的 AI 腔，比如过度整齐的段落、空泛总结、公文体、模糊来源、万能正确但没什么信息量的句子。
为什么只放在文章管理里？
因为不是每个项目都需要写公众号文章。商务材料、账号资料、临时记录，不应该每次都把写作 skill 背上。
token 是上下文里的座位，座位有限。尤其你要是用 Fable 5 这种“每个 token 都像坐了商务舱”的模型，就别让无关 skill 一上来占前排。
局部生效的好处是：该用的时候它在，不该用的时候它安静。
只要是项目制管理，都适合这样做
这套方法不是只给程序员用，也不是只给写作者用。
只要一件事能按项目管理，它就适合结构化。
判断标准很简单：
它有没有阶段？
它有没有材料？
它有没有规则？
它有没有决策？
它会不会反复打开、反复推进？
如果答案是“会”，那就值得放进项目文件夹，而不是全靠聊天记录。
写公众号可以这样管。
做产品调研可以这样管。
整理客户资料、推进商务合作、做课程、写书、准备一次复杂旅行，甚至装修房子，也可以这样管。
AI 最怕的不是任务复杂。
AI 最怕的是每次都不知道自己站在哪里。
你可以怎么照做
资料包里的 HTML 文件就是完整使用手册。
为了方便你先判断要不要用，我把最小步骤放在这里。
新建项目文件夹 ↓放入 AI 项目规则模板 ↓让 AI 采访你 ↓生成 AGENTS.md + .memory/ ↓每次新会话先读记忆 ↓工作结束后，经你确认再更新记忆
这里有三个原则，最好一开始就守住。
1.稳定规则放入口。
项目是什么、目录怎么分、长期原则是什么，放 AGENTS.md。
2.动态进度放记忆。
当前状态、下一步、阶段变化，放 .memory/。
3.局部上下文放现场。
文章管理、商务管理、资料整理，如果某个子目录会长期工作，就让它有自己的规则和记忆。
这样 AI 读到的不是一段越来越长的提示词，而是一套可以自己导航的项目地图。
资料怎么拿
我把两份文件打成了一个包：
AI项目规则模板.mdAI项目规则模板.html
一个用来让 AI 初始化项目规则和记忆。
一个用来当使用手册，先看结构，再照着改。
想直接试，可以关注公众号后回复：
项目记忆我的建议是：不要先追求搭一个完美系统。
先拿一个真实项目试。
只要下一次打开新会话时，你少说了 5 分钟背景，这套规则就已经开始回本了。
如果这篇文章对你有用，欢迎关注、点赞、转发，也可以点个“在看”。
后面我会继续分享 AI、科技和商务相关的实践记录。
