RASEN · 螺旋上升的循环
文档
v 0.1.3
MIT
⬤ 自主引擎
EN / 中文 / 日本語 / 한국어
[ contents ]
理解它

先做探索

/rasen:explore 是你的思考伙伴。在你有问题却还没有方案时，就该用它。 它会探查你的代码库，和你一起权衡各个选项，在任何产物或代码行被创建之前就澄清你真正想要的东西。当思路清晰后，它把工作交给 /rasen:propose。

如果你只从这些文档里学一个习惯，就学这一个：当你不确定时，先探索再提案。

这件事为什么重要。AI 编程助手很积极。问得含糊就能自信地把某个东西构建出来，只是可能不是你需要的那个。探索就是解药。它是一次零成本的对话，让你和 AI 一起摸清正确的方向，这样当你提案时，你提案的就是正确的东西。

什么时候探索

探索往往是比人们想象的更好的第一步。在以下任何一个情况下都适用：

  • 你知道问题但不知道解决方案。（"页面感觉很慢。" "认证一团糟。" "我们总是在创建重复订单。"）
  • 你在选择不同的方案，想把各方案的权衡与你的实际代码对照起来。
  • 你对一个代码库陌生，需要理解某个部分在改动之前是如何工作的。
  • 需求还很模糊，你想在承诺之前把它们打磨清晰。
  • 你怀疑这次工作比看起来大或小，想诚实地给它定好范围。

仅在你已经确切知道要什么、怎么做时才跳过探索。这种情况下直接去 /rasen:propose。

它会做什么（和不会做什么）

探索是一次对话，不是生成。

它会：

  • 读取你的代码库并搜索它来回答真实问题。
  • 对比各个选项并点明各自的权衡。
  • 画图来让设计清晰易懂。
  • 帮你把含糊的想法打磨成具体、可构建的范围。
  • 在你准备好时交给 /rasen:propose。

它不会：

  • 创建变更文件夹。
  • 写任何产物（没有提案、规格、设计或任务）。
  • 写或修改代码。

这就是关键。探索对你没有成本，也没有约束。你可以探索三条死胡同，从各自学到东西，然后只在存活下来的那条路上提案。

它已经装好了

好消息：/rasen:explore 随附在默认的 core profile 里，和 propose、apply、sync 和 archive 并肩。你不需要启用任何东西。如果 Rasen 在你的项目里已经设置好，explore 就准备好在你的 AI 聊天里用了。（和所有 /rasen:* 命令一样，你在助手的聊天里输入它，而不是在终端。参见命令是如何工作的。）

一个完整的例子

看看一个含糊的担忧是如何变成清晰、可构建的变更的。

You: /rasen:explore

AI:  What would you like to explore?

You: Our checkout sometimes creates duplicate orders. I don't know why
     and I don't know how to fix it safely.

AI:  Let me dig into the checkout path...
     [reads the order service, the payment webhook handler, and the
      client submit logic]

     Here's what I found. There are two ways a duplicate can happen:

     1. The client can submit twice (double-click, retry on slow network).
        Nothing debounces it.
     2. The payment webhook can fire more than once, and the handler
        creates an order each time. There's no idempotency key.

     Cause #2 is the dangerous one: it can charge and fulfill twice.

     Three ways to fix it, roughly in order of robustness:
     - Idempotency key on the order-creation endpoint (handles both causes)
     - Dedup on the webhook by payment-intent id (handles #2 only)
     - Client-side debounce (handles #1 only, papers over the real bug)

     Given your code already stores the payment-intent id, the
     idempotency-key approach is a small change with the biggest payoff.
     Want me to scope that?

You: Yes, let's do the idempotency key.

You: /rasen:propose add-order-idempotency-key

AI:  Created rasen/changes/add-order-idempotency-key/, with a proposal
     and delta spec grounded in what we just found. Ready for implementation.

注意发生了什么。起点是"有什么东西不对，我害怕改动它。" 20 秒的探索把它转变成了一个已命名的根本原因、三个排过序的选项、一条系于现有代码的建议，以及一个精确的变更。随后的提案之所以清晰，是因为思考已经发生过了。

交给提案

探索不会归档到任何地方。当你准备好时，你只需启动一个变更，AI 就会把你这段对话中的上下文携带到产物里。

explore  ──►  propose  ──►  apply  ──►  archive
 (think)     (agree)       (build)     (record)

你可以用纯语言说出来（"让我们把这个转成一次变更"）或直接运行 /rasen:propose <name>。无论哪种方式，你刚做过的探索都成了提案的基础，而不是一次性的聊天。

如果你使用扩展命令集，explore 可以改为交给 /rasen:new，用于逐步创建产物。参见工作流。

做好探索的建议

  • 带来问题，而不是解决方案。 "登录感觉很慢"给 AI 调查的空间。"添加一个 Redis 缓存"会让你预先承诺一个你还没测试过的答案。
  • 大声问出权衡。 "每个选项的缺点是什么？"会让你得到更诚实的对比。
  • 让它先读。 最好的探索从 AI 真正去看你的代码开始，不是猜。如果能帮助的话，指点它相关区域。
  • 放弃也没关系。 如果探索表明想法不值得做，那就是一个赢。你廉价地学到了它。
  • 在变更中间再探索。 在 /rasen:apply 期间卡住了？你可以后退一步，探索一个子问题，然后回来。

诚实的权衡

你获得什么： 探索在最便宜的时刻——任何产物存在之前——抓住错误的拐弯。在陌生代码中尤其强大，AI 读取和总结系统的能力能为你省去一个下午的钻研。

它的代价： 一点点耐心。探索是对话，所以比直接启动 /rasen:propose 和期待要慢。对于你真正已经理解的工作，那个额外的步骤完全是开销，你应该跳过它。

经验法则：任务越模糊，探索的收益越大。任务越清晰，越能直接跳到提案。

接下来去哪