内容.md
只有你能写的一个文件。
README.md✓ 代理商.md✓ *…还有一件事。*
______________________________________________________________________
问题
一位新的团队成员加入了您的项目。他们问：“为什么这个项目存在？”
打开README。安装说明，API文档，使用示例-所有关于 *什么* 该项目确实如此。但没什么 *为什么*.
你查一下wiki。最后更新时间：2019。该项目始于2021年。
您的项目有描述以下内容的文件 什么 它确实：
README.md--这个项目是什么（针对人类）AGENTS.md--AI应该做什么（对于AI代理）CLAUDE.md,.cursorrules等等。--特定工具的行为方式
但没有一个标准文件能回答最基本的问题： 为什么这个项目存在？
解决方案
内容.md --任何项目根目录下的一个markdown文件，用于回答该问题。
- 为什么 项目存在（理念、目的）
- 什么 项目的身份是
- 它是如何联系起来的 更广泛的生态系统
your-project/
├── CONTEXT.md ← Why (you are here)
├── AGENTS.md ← What (AI agent instructions)
├── README.md ← Doc (often skipped)
├── CLAUDE.md, etc. ← How (tool-specific settings)
└── src/ ← (finally, some actual code)快速开始
每一个新工具都意味着配置文件、环境变量、依赖关系、 node_modules 它可以与一个小黑洞相媲美，稍后您将阅读README。 *（你不会的。）*
CONTEXT.md需要两件事：Markdown和你的意图。你已经两者都有了。
# CONTEXT.md - My Project
## PROJECT_CONTEXTwhy: "Why this project exists" aims: "What it ultimately serves"
## PROJECT_IDENTITYidentity: "What this project is and how it sees itself" meaning: "What this means for design decisions"
## RELATIONSHIPecosystem: "How this project relates to others" dependencies: "What it builds upon"
就是这样。如果你的人工智能可以阅读markdown——它也可以——它现在就能理解你的项目的目的了。
为什么选择CONTEXT.md？
内容与背景
||内容|上下文| |--|---------|---------| |定义|出现的内容（代码、数据、特征）|背后的含义（目的、意图）| |项目文件| README、AGENTS、源代码| 内容.md | |问题回答|“这有什么作用？”|“为什么会存在？”| | 类比 | git commit -m "fix" | 到底是什么坏了，为什么 |
两个开发人员可以编写完全相同的函数。一个是制作玩具。另一个是建设数千人依赖的基础设施。代码是相同的。这 *上下文* 就是一切。
想象一下，扬帆横渡大海。你的指南针偏离了一度，刚开始几乎看不见。一千英里后，你在一个完全不同的地方。你的项目的“为什么”也是一样的。早期目的的微小差异会导致未来截然不同的结果。
AI无法写入的一个文件
AI编写代码。生成测试。起草文件。甚至修复了bug（偶尔还会引入新的bug——我们都经历过）。
作为一名内容专业人士，人工智能正在重塑我们构建软件的方式。
但上下文——即“为什么”——是人工智能无法创造的东西。
在 *小王子*狐狸说： *“本质是肉眼看不见的。”*
人工智能处理所有可见的东西——代码、数据、文件、文档。但关键部分-- *为什么* 这个项目存在——是看不见的。它存在于发起它的人的脑海中。人工智能无法生成它。只有你可以把它写下来。
“但是等等，AI *能* 生成一个CONTEXT.md。我刚刚尝试过。”
当然可以。AI可以编写Ruby的CONTEXT.md： *“一种注重简单性和生产力的动态开源编程语言。”* 技术上准确。但Matz创建Ruby并不是为了“简单和高效”。他创建Ruby是因为他想让程序员快乐。这不是一个功能请求，而是一个愿望。AI可以描述语言。只有Matz能描述它背后的感觉。
你的项目也是如此。AI可以从你的代码、提交和README中推断出它的作用。但让你开始的火花——不在数据中。
在一个人工智能可以生成任何代码库的世界里，脱颖而出的项目不会是那些拥有最好代码的项目。他们将是目标最明确的人。人们不会为存储库做出贡献。他们为自己所信仰的事物做出了贡献。
CONTEXT.md是“某物”变成单词的地方。
*（是的，这个仓库是在人工智能的帮助下构建的。人工智能帮助编写了一个关于人工智能无法编写的一件事的标准。这正是重点。）*
超越存储库边界
“我是一名工程师，可以将广告点击率提高0.3%”告诉你别人是怎么做的。 “我成为了一名工程师，因为我想开发能让孩子们说‘再！再！’的应用程序。”告诉原因。
同一个人。完全不同的印象。
大多数项目文件都描述了 *里面* 存储库。CONTEXT.md描述了项目在 *更大的世界*一个拥有CONTEXT.md的AI不仅知道该做什么，它知道 *为什么这很重要*.
桥梁模式
为什么不把你的哲学放在AGENTS.md上呢？
因为指令文件在规则中说话： *这样做，不要那样做，使用这种格式。* 它们精确、可操作且机器可读。那是他们的工作。
哲学不是这样运作的。“我们相信用户拥有他们的数据”不是一条规则，而是一个指南针。把它放在旁边 "respond in JSON format" 人工智能平等对待他们。一个是硬约束。二是软引导。人工智能无法分辨其中的区别，你只是在规则手册中添加了噪音，或者更糟糕的是，造成了冲突。
CONTEXT.md通过分离解决了这个问题：
CONTEXT.md (Philosophy) → soft guidance, direction, no concrete answers
AGENTS.md (Rules) → hard constraints, specific actions两者均由AI加载。目的不同。没有冲突。
当AI读取你的规则时 *和* 你的哲学，有趣的事情发生了。它遇到了你的规则没有涵盖的边缘情况——它没有停止或猜测，而是有一个指南针。它甚至可能发现一些东西 *你* 错过：一个在技术上遵循你的规则但悄悄违反你的原则的请求。一个你不知道的盲点。
这就是桥梁：CONTEXT.md为AI提供了指令文件无法表达的视角。没有答案-- *方向*.
您可以通过以下方式加强联系 why: 指令文件中的注释：
# In your AGENTS.md or CLAUDE.md
rules:
- rule: "Never store user data in external services"
why: "See CONTEXT.md → PROJECT_CONTEXT: user owns their data"
- rule: "All APIs must support offline mode"
why: "See CONTEXT.md → DESIGN_PRINCIPLES: persistence over convenience"这些指针将特定的规则与特定的哲学联系起来。人工智能不仅遵循规则，它还能理解推理，并将推理应用于你没有预料到的情况。
规格
看 规格/内容_MD_v1.0.0.MD 对于正式规范。它比大多数cookie同意弹出窗口更短，而且更有用。
例子
| 示例 | 说明 |
|---|---|
| 最小 | 最低限度。三个部分。复制并离开。 |
| 人工智能项目 | 具有工具生态系统的AI/ML项目 |
| 个人资料 | 注重隐私的数据管理 |
| 混合 | 桥接模式：AGENTS.md规则如下 why: 指向CONTEXT.md的指针 |
| 反向上下文 | 逆上下文逻辑：context.md使用意识水平探索AGENTS.md范围之外的内容 |
文件层次结构
CONTEXT.md (Why) — Philosophy, purpose, the field of meaning
↓ contains
AGENTS.md (What) — Instructions for AI agents
↓ alongside
README.md (Doc) — Human-readable documentation
↓ alongside
Tool config (How) — CLAUDE.md, .cursorrules, etc.CONTEXT.md位于顶部。不是因为它很专横，而是因为“为什么”这个问题赋予了它下面的一切意义。没有它，你只是在打字。
设计原则
清单
| # | 原则 | 问问自己 |
|---|---|---|
| 1 | 为什么 | 你写的是上下文（为什么），而不是内容（什么）？ |
| 2 | 基础 | 它是否为所有其他项目文件赋予了意义和连贯性？ |
| 3 | 独立 | 有人能仅从这个文件中理解你的项目的目的吗？ |
| 4 | 永恒 | 如果实施方式发生了变化，这个“为什么”仍然成立吗？ |
| 5 | 简单 | 它是用最简单的词表达的吗？ |
| 6 | 超越 | 它是否显示了项目在更大的世界中的位置，而不仅仅是回购？ |
| 7 | 通用 | 它对人类和人工智能阅读它同样有价值吗？ |
不包括什么
没有人在日记里写购物清单。错地方了。
同样的想法：如果一个句子回答“什么”或“如何”而不是“为什么”，它就属于另一个文件。
- ❌ “要安装，请运行
npm install“这是自述文件。 - ❌ “使用Python 3.12或更高版本”——再次阅读README。
- ❌ “AI应该以JSON格式响应”——这是一个AGENTS.md。
- ✅ “我们建造这个是因为……”——现在你在写Context。
现有技术
| 项目 | 方法 | 重点 |
|---|---|---|
| llm上下文md | 目录中的分层CONTEXT.md文件 | 技术上下文（内容）：架构、约定 |
| 代码库上下文规范 | .context/ 结构化文档目录（存档） | 架构文档（内容）：设计决策 |
| 不良反应 （架构决策记录） | 每个技术决策的单独记录 | 决策依据（决定了什么以及为什么） |
这些项目侧重于 什么 --关于代码和决策的技术背景。 该项目的重点是 为什么 --没有技术背景提供的目的和意义。
ADR和CONTEXT.md尤其互补。ADR回顾过去：“我们选择PostgreSQL是因为……”——从已经做出的决定中推理。CONTEXT.md期待：“这个项目的存在是因为……”——这是任何决定之前的目的。一个健康的项目可以对照CONTEXT.md检查其ADR：如果决策不再符合目的，则表明出现了偏差。
他们解决不同的问题。一个项目可以使用所有这些。
工具
验证
python3 tools/validate.py CONTEXT.mdGitHub行动
- uses: aoitairako/context-md@v1没有依赖关系。没有配置。只是标准。
常见问题解答
Q： AI可以为我编写CONTEXT.md吗？ A： 当然。但问问自己：为什么你只是把你的“为什么”委托给人工智能？
Q： 如果我不知道我的项目的“为什么”怎么办？ A： 那么，你面临的问题比文档更大。
Q： 这只是一个包含额外步骤的README吗？ A： 一封情书只是一封带有额外感情的信吗？
贡献
欢迎捐款。打开一个问题，发送一个PR，或者在你自己的项目中添加一个CONTEXT.md。这也是一种贡献。
如果你采用它，考虑添加主题 context-md 到您的GitHub存储库。
如果你不接受它，就没有怨恨。存在问题需要时间。
许可证
CC0 1.0（公共领域） --不保留任何权利。无需归因。随心所欲地使用它。
______________________________________________________________________
AI可以帮助您编写项目中的其他所有文件。 这个？我不能。
事实上，让我试试： *“这个项目的存在是为了通过创新的解决方案创造价值。”* 完美，对吧？ .正确的
*一个项目的小文件。文档记录的一个巨大飞跃。*
______________________________________________________________________
*CONTEXT.md标准v1.0.0--创建时间：2026年2月15日* *作者 八月* *（幽默设置：75%）*