核心概念一览
Rasen 是你和你的 AI 之间一层轻量的"共识层"。 你写下一次变更应该做什么，AI 起草细节，你们看着同一份计划，然后才动手写代码。这一页用一屏讲完整套心智模型。当你想要长版本时，概念里有。
整个想法用五个词概括：先达成共识，然后放手去构建。
五个核心概念
Rasen 中的一切都由五个概念构成。学会这五个，剩下的都是细节。
1. 规格是事实。 一份规格描述的是你的系统当下是如何运作的。它存放在 rasen/specs/，按领域（auth/、payments/、ui/）组织。规格由需求（"系统 SHALL 在 30 分钟后使会话失效"）和场景（具体的 given/when/then 示例）构成。把规格理解为"这个软件到底做什么？"这个问题的唯一公认答案。
2. 一次变更就是一个工作单元。 当你想新增、修改或移除某种行为时，你就创建一次变更：在 rasen/changes/ 下的一个文件夹，把关于这次工作的所有东西放在一处。一份提案、一份设计、一份任务清单，以及对规格的修改。一次变更、一个文件夹、一个功能。
3. 增量规格描述的是"什么在变"，而不是整个世界。 在一次变更里，你不必重写整份规格。你只需写一个小的 delta：ADDED 这条需求、MODIFIED 那条、REMOVED 另一条。正是这一招，让 Rasen 不仅能搞定全新项目，也擅长编辑既有系统——你描述的是 diff，而不是终点。
4. 产物之间层层递进。 一次变更包含几份文档，按自然的顺序创建，每一份都为下一份铺垫：
proposal ──► specs ──► design ──► tasks ──► implement
why what how steps do it
你随时可以回到其中任何一份。它们是"启用条件"，而不是"门禁"。（下文详述。）
5. 归档把变更折回事实之中。 当工作完成，你归档这次变更。它的增量规格并入你的主规格，而变更文件夹则带着日期戳移动到 changes/archive/。此时你的规格描述的就是新的现实了，你也为下一次变更做好了准备。循环闭合。
一张图
┌─────────────────────────────────────────────────────────────────┐
│ rasen/ │
│ │
│ ┌──────────────────┐ ┌──────────────────────────┐ │
│ │ specs/ │ │ changes/ │ │
│ │ │ ◄───── │ │ │
│ │ source of truth │ merge │ one folder per change │ │
│ │ how things work │ on │ proposal · design · │ │
│ │ today │ archive │ tasks · delta specs │ │
│ └──────────────────┘ └──────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
两个文件夹。specs/ 是事实。changes/ 是你正在提议的东西。归档，就是把一份提议搬进事实。
你实际会跑的那个循环
在默认配置下，你的一天长这样：可选地先想一遍；然后一条命令起草计划，你读它，下一条构建它，最后一条把它归档。
/rasen:explore → （可选）先和 AI 一起想透
/rasen:propose add-dark-mode → AI 起草提案、规格、设计、任务
（你阅读并调整计划）
/rasen:apply → AI 构建它，逐项勾掉任务
/rasen:archive → 规格更新，变更归档
拿不准时，先从探索开始。 /rasen:explore 是一个零成本的思考伙伴：它读你的代码、摆出各种选项，在任何产物存在之前，就把一个模糊的想法变成具体的计划。它是对付那种"否则就会从一个含糊提示里胡乱构建出某个东西的 AI"的最佳解药。已经确切知道你想要什么？那就直接跳到 /rasen:propose。无论哪种，explore 都随默认 profile 一起提供，所以它总在那儿。参见探索指南。
上面这些都是斜杠命令，在你 AI 助手的聊天里输入。而配置（rasen init）在你的终端里进行。如果这种分工对你来说很陌生，先读命令是如何工作的；它是最常见的困惑点。
"启用条件，而非门禁"
这句话在 Rasen 里随处可见，所以这里用大白话讲讲它是什么意思。
老派的规格流程是瀑布式的：先把规划做完，然后才被允许去实现，想回头很痛苦。Rasen 拒绝这一套。proposal → specs → design → tasks 这个顺序展示的是下一步可能做什么，而不是你被迫要做什么。
在实现阶段才发现设计错了？改 design.md 然后继续。意识到范围该收窄？更新提案。没有任何东西被锁死。这些依赖关系之所以存在，只是为了让 AI 拥有它所需的上下文（没有规格作依据，你写不出好任务），而不是为了把你框住。
这里的优势在于诚实：真实的工作是杂乱且迭代的，而 Rasen 允许它如此。代价则是自律：正因为没有东西逼着你往前走，保持一次变更加以聚焦、不任其蔓延，就全靠你自己。工作流指南里有这方面的好习惯。
为什么这点小小的开销是值得的
大实话：Rasen 多加了一步。你在构建之前先写一份简短的计划。那你能从中得到什么？
- 在错误拐弯让你付出代价之前就抓住它。 在一段话的提案里纠正一个误解是免费的。在 AI 写了 400 行之后再纠正，可不是。
- 计划和代码待在同一个仓库里。 六个月后，规格会告诉你（以及下一次 AI 会话）这个系统为什么是这样运作的。
- 变更可被评审。 一个变更文件夹就是一个整洁的包裹：读提案、扫一眼 delta、核对任务。不必去聊天记录里考古。
- 它契合既有代码库。 有了 delta，你就能给一个 5 万行的应用指定一次变更，而不必先把整个东西文档化。
还有诚实的代价：对于一个真正琐碎的一行修复，这套仪式可能划不来，没关系。Rasen 的设计是轻量的，但它不是免费的。在"达成共识"这件事重要的时候用它——而一旦你在和一个会自信满满地把你含糊要求的东西全造出来的 AI 协作时，这种重要的情况其实是大多数。