OpenSpec 是你与你的 AI 之间一层轻量的约定层。 你写下某个变更应该做什么，AI 起草细节，你们双方看着同一份计划，然后才动笔写代码。本页在一屏之内呈现完整的思维模型。若想看完整长版，请见核心概念。
整件事用五个词概括：先对齐，再自信地构建。
OpenSpec 中的一切都由五个概念构建而成。学会这些，其余皆为细节。
1. Specs 即事实。 一个 spec 描述你的系统当下如何运作。它位于 openspec/specs/，按领域组织（auth/、payments/、ui/）。Specs 由需求（"系统 SHALL 在 30 分钟无活动后使会话过期"）和场景（具体的 given/when/then 示例）构成。把 specs 想成关于"这个软件做什么？"的唯一约定答案。
2. 一个 change 是一个工作单元。 当你想要新增、修改或移除某种行为时，你创建一个变更：一个位于 openspec/changes/ 的文件夹，把关于那项工作的所有内容放在一处——一份 proposal、一份 design、一份任务列表，以及 spec 的修改。一个变更，一个文件夹，一个功能。
3. 增量规范描述正在变化的，而非整个世界。 在变更内部，你不需要重写整个 spec。你写一个小小的增量：ADDED 这条需求，MODIFIED 那一条，REMOVED 另一条。这正是让 OpenSpec 擅长编辑既有系统、而非仅限全新项目的关键技巧。你描述的是 diff，而非终点。
4. 制品相互依托。 一个变更包含几个文档，按自然的顺序创建，每个都为下一个提供养料：
proposal ──► specs ──► design ──► tasks ──► implement
why what how steps do it
你可以随时回到其中任意一个。它们是促成因素，而非关卡。（下文详述。）
5. 归档将变更合并回事实来源。 工作完成时，你归档该变更。它的增量规范合并进你的主 specs，变更文件夹带着日期戳移入 changes/archive/。现在你的 specs 描述了新的现实，你已准备好迎接下一个变更。循环闭合。
┌─────────────────────────────────────────────────────────────────┐
│ openspec/ │
│ │
│ ┌──────────────────┐ ┌──────────────────────────┐ │
│ │ specs/ │ │ changes/ │ │
│ │ │ ◄───── │ │ │
│ │ source of truth │ merge │ one folder per change │ │
│ │ how things work │ on │ proposal · design · │ │
│ │ today │ archive │ tasks · delta specs │ │
│ └──────────────────┘ └──────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
两个文件夹。specs/ 是事实所在。changes/ 是你正在拟议的内容。归档把一个提案移入事实。
在默认设置下，你的一天如下。可选地先想清楚；然后一条命令起草计划，你阅读它，下一条命令构建它，最后一条归档它。
/opsx:explore → (可选) 先与 AI 一起把思路理清
/opsx:propose add-dark-mode → AI 起草 proposal、specs、design、tasks
(你阅读并调整计划)
/opsx:apply → AI 构建它，逐项勾选任务
/opsx:archive → specs 已更新，变更已归档
拿不准时，从探索开始。 /opsx:explore 是一个零负担的思考伙伴：它阅读你的代码，铺陈选项，在任一制品诞生之前把一个模糊的想法变成具体计划。当 AI 可能因模糊提示而构建出错误东西时，它是最好���解药。已经确切知道想要什么？直接跳到 /opsx:propose。无论哪种方式，explore 都随默认 profile 提供，因此它始终在那里。请参阅探索指南。
这些斜杠命令输入在你 AI 助手的聊天框中。初始化（openspec-cn init）在你的终端中执行。如果这种划分对你而言是新事物，请先阅读命令如何运作；这是最常见的困惑点。
这句话在 OpenSpec 中随处可见，所以这里用大白话解释它的含义。
老派规范流程是瀑布：先完成规划，然后才允许实现，回头重来则痛苦不堪。OpenSpec 拒绝那样。顺序 proposal → specs → design → tasks 展示的是接下来可能做什么，而非你被强迫接下来做什么。
实现过程中发现设计错了？编辑 design.md 然后继续。意识到范畴应当收窄？更新 proposal。没有任何东西被锁死。依赖的存在只是为了让 AI 拥有它所需的上下文（没有 specs 作基础你就写不出好任务），而非为了把你框住。
其长处在于诚实：真实工作混乱而迭代，OpenSpec 允许它如此。代价在于自律：因为没有什么强迫你前进，保持一个变更聚焦而不至于失控膨胀，就靠你了。工作流指南提供了达成此目的的好习惯。
说实话：OpenSpec 增加了一个步骤。你在构建前写一份简短计划。那么你为之得到什么？
- 你在付出代价前就拦下走错的方向。 在一个段落长的 proposal 中修正一处误解是免费的。在 AI 写了 400 行后再修正则不然。
- 计划与代码留在同一个仓库。 六个月后，spec 会告诉你（以及下一次 AI 会话）系统为何如此运作。
- 变更可审查。 变更文件夹是一个整洁的包裹：读 proposal，扫一遍增量，核对任务。无需在聊天历史中考古。
- 适配既有代码库。 增量意味着你可以为一个 50,000 行的应用规范一次变更，而无需先记录下整个应用。
而诚实的代价是：对于一个真正琐碎的单行修复，这套仪式可能得不偿失，这没关系。OpenSpec 被设计为轻量的，但它并非免费。在约定要紧的地方使用它——一旦你开始与一个会自信地构建出你含糊要求之任何东西的 AI 共事，你会发现在大多数时候它都值得。