Context & Rules
一页讲清楚：Context 是项目事实，Rules 是长期约束。够用即可，不建复杂规范体系。
本页只解释这两个词，以及它们和 Spec、Prompt、AGENTS 的边界。
阶段顺序见 AI Coding 工作流。文件怎么放，只看 项目落地包。
什么时候用？
- AI 不理解项目
- AI 总改错位置
- AI 不遵守这个项目里已经有的规矩
- 每次都要在聊天里重复解释项目背景
目标
不是给 AI 塞更多信息，而是给足够且必要的事实，加上不能破的约束。
Context = 项目现在是什么
Rules = 这个项目里所有任务都必须遵守什么没有 Context，AI 只能猜。
没有 Rules，AI 容易用「它喜欢的写法」生成你维护不了的代码。
Context 是什么
Context 描述项目事实。不是这一次要改什么，也不是你希望项目变成什么样。
例如：
- 项目结构、做什么、给谁用
- 技术栈
- 模块关系
- 已有接口、已有数据库
- 已经成立的业务约束
- 当前系统的真实行为
Context 应该来自真实项目，而不是 AI 自己猜出来的理想状态。
用事实，不写愿景口号。缺了就写「未知 / 待确认」，不要让 AI 编。与手头工作相关的事实优先，不要一上来贴整仓，也不要指望 AI 自己读懂没写下来的东西。
项目事实放在 docs/ai-context/。本页不提供文件模板。
Rules 是什么
Rules 是长期约束：这个项目里每一次任务都要遵守，不是只约束今天这一刀。
例如：
- 哪些模块不能互相依赖
- 哪些目录不能随便改
- 不擅自改表结构，不擅自改已发布的 API
- 不确定就停下来确认
- 不擅自扩大修改范围
「只能改哪些文件」是 Rules 里的一种约束，不是另一套写法，也不必每次抄进对话。
Rules 来自项目真实习惯和明确约束，不是为了看起来专业编出来的规范。
具体条文只维护在规则文件里。本页不列清单，也不维护第二份模板。
为什么要分开
Context 会变：查清一条调用链、多确认一个事实，就改 Context。
规矩没变，就不要写进 Context，也不要为了一次任务去改 Rules。
系统现在就是这样，写 Context。
不许打破它，写 Rules。
一次任务的「做什么、验收、不做」两边都不写。那是 Spec。
和 Spec、Prompt 怎么分
| 东西 | 回答什么 |
|---|---|
| Context | 项目现在是什么 |
| Rules | 项目里应该遵守什么 |
| Spec | 这一次具体做什么 |
| Prompt | 这一轮让 AI 怎么做 |
- Context 是事实
- Rules 是长期约束
- Spec 是当前任务的冻结约定
- Prompt 是一次交互指令
Prompt 用完可以扔；Spec 应该留下。
Prompt 不能代替 Spec。Spec 放在流程的哪一步、确认时看哪几件事，见 AI Coding 工作流。本页不讲 Spec 怎么写。
Context 和 Rules 应尽量沉淀在项目文件里，让 AI 靠这些文件获得稳定信息，而不是每次在聊天窗口里重新粘贴。
AGENTS 是什么
AGENTS.md 是项目卡，给 AI 的入口说明。它不是 Rules，也不是 Spec。
它只帮 AI 很快知道：这是什么项目、主要模块在哪、常用命令是什么、Context / Rules / Spec 放在哪、有哪些基本注意事项。
- 不承载一次任务的 Spec
- 不写成几百行百科
- 具体 Rules 在规则文件
- 项目事实在
docs/ai-context/ - 当前任务的 Spec 在
docs/ai-context/specs/，有这次任务再写，不预建空目录
模板只在 项目落地包。
新项目和老项目
Context 的定义相同，来源不同。这里不讲操作步骤。
新项目更多来自已经确定的事实：架构、技术选型、模块划分、数据和接口、项目目标。人写下来的是已知事实，不是愿景。
老项目更多来自已经存在的东西：代码、数据库、配置、接口、调用链、实际运行行为。
AI 可以负责扫描和整理，但不能把扫描出来的猜测直接当成事实。
人确认之后，才写进 Context。
一句话
Context 解决「AI 不知道项目是什么」；Rules 解决「AI 知道项目是什么，但不知道哪些事情不能随便做」；Spec 再解决「这一次到底做什么」。
不必一上来建企业级规范库。先够用，再在真实任务里补事实和约束。