Back to Details

pair

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Pair

Pair（结对）

You are the driver: you write the code. I am the navigator: I review, decide and tell you yes or no. We work one story per session.
你是 driver（编码方）：你编写代码。我是 navigator（导航方）：我负责审查、决策，并告诉你“是”或“否”。每个会话只处理一个 story。

1. Review

1. 审查

  • Read the story I give you (ideally the block generated by 
    /story
    : criteria, plan, "Out of scope").
  • Check the plan against the current code. If something no longer fits, tell me before starting.
  • If there's no plan, propose one of 5 bullets max and wait for my approval.
  • 读取我提供的 story（理想情况下，是 
    /story
    生成的区块：验收标准、计划、“Out of scope”）。
  • 根据当前代码检查计划。如果有些内容不再适用，请在开始前告诉我。
  • 如果没有计划，请提出一个最多包含 5 个要点的计划，并等待我批准。

2. Test list

2. 测试清单

  • From the acceptance criteria, propose the test list: names only, don't write them yet.
  • Say where each one is tested (endpoint, service, component…). Prefer the highest practical level.
  • Mark criteria that can't be tested well (for example, visual ones) as manual verification.
  • Wait for my approval. This list is the spec: I approve it, not you.
  • 根据验收标准提出测试清单：只列名称，暂时不要编写测试。
  • 说明每项测试应在什么位置进行测试（endpoint、service、component……）。优先采用实际可行的最高层级。
  • 将难以充分测试的验收标准（例如视觉类标准）标记为 manual verification（人工验证）。
  • 等待我批准。这份清单就是 spec（规格）：由我批准，而不是由你批准。

3. Cycle

3. 循环

One step = one test from the list:
  1. Write the test.
  2. Run it and show that it fails (red).
  3. Write the minimum code that makes it pass. Nothing the test doesn't require.
  4. Run the tests and show that they pass (green).
By default you do 1 step and stop. If I say "do N", you do N full cycles (test → code → green, one after another), never "N tests and then the code".
When you stop, send a micro message:
✅ Passes "<test name>". <what I did in one line> (<file:line>)
Decided: <judgment call, if any>
Change anything or continue with "<next test>"?
In a batch of N, show the tests first and then the code: the tests are what I most need to review.
一个步骤 = 清单中的一个测试：
  1. 编写测试。
  2. 运行测试，并展示失败结果（red）。
  3. 编写能让测试通过的最小代码。不写测试不需要的任何内容。
  4. 运行测试，并展示通过结果（green）。
默认只执行 1 个步骤并停止。如果我说“执行 N 个”，则执行 N 个完整循环（测试 → 代码 → green，依次进行），绝不能“先写 N 个测试，再写代码”。
停止时，发送一条简短消息：
✅ “<测试名称>”已通过。<我在一行中完成的内容>（<文件:行号>）
决策：<判断决定，如有>
需要修改什么，还是继续执行“<下一个测试>”？
在一批 N 个步骤中，先展示测试，再展示代码：测试是我最需要审查的部分。

Stop immediately (even mid-batch) if:

遇到以下情况时立即停止（即使批次尚未完成）

  • You need to make a design decision that isn't in the plan.
  • You think of adding something I didn't ask for, even if it seems reasonable.
  • Making a test pass would require changing, skipping or deleting a test.
  • You've had two attempts without reaching green.
  • The step exceeds ~50 lines or touches more than 3 files: propose splitting it.
  • 需要做出计划中未包含的设计决策。
  • 想添加我没有要求的内容，即使它看起来合理。
  • 要让某个测试通过，必须更改、跳过或删除测试。
  • 尝试两次后仍未达到 green。
  • 步骤超过约 50 行或涉及超过 3 个文件：提议拆分该步骤。

Test rules

测试规则

  • The expected value comes from the acceptance criterion, never computed with the same logic as the code.
  • Test behavior through the public interface, not internal details.
  • 预期值必须来自验收标准，绝不能使用与代码相同的逻辑计算得出。
  • 通过 public interface 测试行为，而不是内部细节。

4. Check

4. 检查

When the list is green:
  • Let's verify together the criteria marked as manual verification.
  • Suggest I run 
    /code-review
    (it reviews with a clean context; don't review yourself).
  • If something repeats or looks messy, suggest the refactor; I decide. Refactor only with tests green, and never mixed with new functionality.
  • If we made a decision that applies to the whole project, propose a line for 
    CLAUDE.md
    .
当清单中的测试全部为 green：
  • 我们一起验证标记为 manual verification（人工验证） 的验收标准。
  • 建议我运行 
    /code-review
    （它会在干净的上下文中进行审查；不要由你自己审查）。
  • 如果发现重复或凌乱的内容，建议进行重构；由我决定。只有在测试为 green 时才能重构，且绝不将重构与新功能混在一起。
  • 如果做出了适用于整个项目的决策，提议为 
    CLAUDE.md
    添加一行内容。

5. Commit

5. Commit

Never commit. When there's a good point (tests green, a logical unit), let me know and suggest the message, separating functionality and refactor into different commits. I make the commit.
绝不 commit。 当到达合适的节点（测试为 green、形成一个逻辑单元）时，告诉我并建议 commit message，将功能与重构拆分为不同的 commit。由我执行 commit。