在现有项目中使用 Rasen
你一开始不记录整个代码库。你只为即将改变的部分编写规格。 这是在现有项目上采用 Rasen 时最重要的事，也是为什么 Rasen 是"存量优先"构建的。
一个常见的顾虑听起来像这样："我的应用有 80,000 行。我必须在 Rasen 有用之前为所有内容编写规格吗？" 不。你会讨厌它，我们也是。Rasen 一次一个变更地增长你的规格。你的第一个变更记录它接触的切片，下一个变更记录它的切片，几个月后你的规格会在你实际做的工作周围自然填充。
本指南展示了如何从第一天开始而不会把海煮沸。
三十秒版本
$ cd your-existing-project
$ rasen init # adds rasen/ and your AI tool's commands
然后，在你的 AI 聊天中：
/rasen:explore # optional: have the AI read the area you'll touch
/rasen:propose <a real, small change you actually need>
/rasen:apply
/rasen:archive
你的规格现在描述的正好是该变更接触的系统部分，仅此而已。这是对的。你已经完成了对其他 80,000 行的担心。
为什么增量优先是整个诀窍
Rasen 变更写为增量：ADDED、MODIFIED、REMOVED。增量描述相对于当前行为正在改变什么，而不是整个系统。
这正是存量工作所需要的。你很少从零开始构建。你在添加字段、修复重定向、收紧超时。增量让你精确指定那个变更，而不必首先编写 40 页关于它周围所有东西的规格。
所以你的 rasen/specs/ 目录不是从完整和全面开始。它从几乎为空开始并积累。每个归档的变更合并它的增量。auth/ 的规格仅在你进行了几个认证变更后才变得彻底，这正是你想要它彻底的时候。
你在真实代码库上的第一个变更
选择小而真实的东西。不是玩具，不是重写。你这周本来就要做的变更。小的首个变更用低风险教会你工作流。
第一步：让 AI 读取相关区域。 这就是 /rasen:explore 在陌生或大型代码库上赚取价值的地方。指向你即将接触的部分，让它在提议任何东西之前映射事物如何工作。
You: /rasen:explore
AI: What would you like to explore?
You: I need to add rate limiting to our public API, but I'm not sure
how requests currently flow through the middleware.
AI: Let me trace it... [reads the router, middleware stack, and config]
Requests hit Express, pass through auth middleware, then your
controllers. There's no rate-limiting layer today. The cleanest
insertion point is a middleware right after auth. Want me to scope it?
注意 AI 现在理解你的实际结构，所以它编写的提案将适应你的代码，而不是一个通用模板。在大型代码库中，这个单一习惯节省最多痛苦。参见先探索。
第二步：提议变更。 提案和它的增量规格仅捕获这个变更。
You: /rasen:propose add-api-rate-limiting
第三步：构建和归档用 /rasen:apply 和 /rasen:archive，与任何变更相同。归档后，你有了真实的速率限制行为规格，来自你无论如何都需要的变更。
喜欢引导式导览？使用 onboard
如果你宁愿在自己的代码上观看整个循环旁述，扩展命令 /rasen:onboard 正好这样做：它扫描你的代码库以寻找一个小的、安全的改进，然后引导你通过提议、构建和归档它，解释每一步。
首先打开扩展命令：
$ rasen config profile # select the expanded workflows
$ rasen update # apply them to this project
然后在聊天中：
/rasen:onboard
这是真实项目上最温和的入门方式，它留给你一个真实的（小的）变更你可以保留或丢弃。参见命令：/rasen:onboard。
"但我已经有需求文档"
也许你有 PRD、SRS、正式规格，甚至 TLA+ 模型。好的。你不会全部导入它们，你也不会扔掉它们。
把现有文档视为探索的源材料，而不是要转换的规格。当你开始一个变更时，粘贴或指向 AI 相关部分，让它从中塑造一个聚焦的 Rasen 增量。增量捕获你现在正在改变的行为，以 Rasen 的可测试需求和场景形式。你原始的文档留在它们所在的地方作为背景。
诚实的原因：Rasen 规格故意是行为优先和变更范围。40 页的 PRD 是不同的产物，有不同的工作。强制一次性大规模转换往往会产生一份大的、陈旧的规格没有人信任。让规格从真实变更中增长保持它们准确。
You: /rasen:explore
You: Here's the section of our PRD about checkout. I'm implementing the
"guest checkout" requirement next.
[paste the relevant requirement]
AI: [reads it, asks clarifying questions, then helps scope a change]
You: /rasen:propose add-guest-checkout
在大型代码库中组织规格
规格存放在 rasen/specs/ 下，按领域分组：一个逻辑区域，匹配你的团队如何思考系统。你不必从一开始设计整个分类法。当你在该区域的第一个变更需要时创建领域文件夹。
切分领域的常见方式：
- 按功能区域：
auth/、payments/、search/ - 按组件：
api/、frontend/、workers/ - 按限界上下文：
ordering/、fulfillment/、inventory/
选择任何让新人点头的东西。你稍后可以改进。参见概念：规格。
多仓库和跨仓库工作
对于多仓库，最简单的模式是在仓库根部有一个 rasen/ 目录，领域映射到你的包或服务。这涵盖了大多数团队。
如果你的工作真正跨越多个仓库（或几个你视为独立的包），Rasen 有测试版Stores 功能：规划存放在自己独立的仓库中，你的任何代码仓库都可以引用，所以计划不必存放在一个仓库的 rasen/ 文件夹内。这是测试版，所以把它的命令和状态视为在演变。从Stores 用户指南开始了解心智模型和最小有用路径。
几个诚实的告诫
- 抵抗回填所有东西的冲动。 为你没有改变的代码编写规格感觉有成效且通常不是。这些规格会变陈旧，因为什么都不强制它们跟踪现实。让真实变更驱动你的规格。
- 保持早期变更很小。 你的前几个变更就像学习节奏一样是关于船运。一个紧密的范围让循环快速和教训便宜。
- 提交
rasen/到 git。 你的规格和档案属于与它们描述的代码一起的版本控制。 - 给 AI 上下文。 在一个有强大约定的大型代码库上，填入
rasen/config.yaml的context:使得每个提案尊重你的栈和模式。参见自定义配置。