用途：为编码会话设定节奏与纪律，强调软件开发本质是学习，通过小步、快速反馈和控制变量来提高学习速度。衡量“好”的唯一标准是变更的容易程度。
核心循环：为每个行为增量重复以下步骤。1）框定最小的可逆动作，识别一个用户或调用方可见的行为增量，比直觉更小；若无法用一句话说明结果，说明步子太大，需拆分。2）先写测试、预测失败、观察失败：从使用者（可能是另一个程序员）视角表达代码应做什么，运行前说出预期失败；若失败方式与预测不同，已有所收获；难以写的测试是设计坏味，改设计而非改测试。3）用最简单方式回到绿灯：写最少能通过的代码，朴素即可，这是战术步骤而非设计步骤，暂不精修。4）在绿灯下重构：保持测试通过，每做微小改动就跑测试，让代码比自己发现时略好。5）频繁集成：每10–15分钟提交小变更，尽量直接进主干；小提交隐藏问题更少、更易回滚，并保持通往生产的路径畅通；本地先跑快速测试。
控制变量：一次只改一样，不把重构、行为变更、配置调整捆绑；隔离测试数据，每个测试从已知空状态开始，测试间不共享可写数据，生成唯一ID；不依赖计时，等待可观察条件而非 sleep；把影响结果的一切（代码、测试、配置、基础设施）纳入版本控制；把间歇性失败的测试当作失败，绝不当作可重跑即通过。
以可观察行为而非实现为准：测试描述以“should”开头，如“should reject passwords shorter than 8 characters”，可用 Given/When/Then 表述；好测试固定可观察行为，更换实现后仍应有效；避免 UI/机制语言（如“click Buy”），改用意图（如“place order”）；把 I/O 与边界（UI、存储、网络、第三方）推到薄抽象之后。
以变更容易度评判每步：提交前扫描模块化、内聚、关注点分离、抽象、低耦合五个属性；若某步明显变差，趁便宜立刻重构。若代码比之前更难改，即使测试通过也说明质量退步。函数读起来像几句短句（约5–10行），命名能连成句子，通常是做对的迹象。
收尾前问“如果……会怎样？”：考虑无效输入、依赖抛错/超时/返回垃圾、并发与负载、安全或损失金钱路径；想清楚本身就是交付物，可有意推迟处理，但不可忽略。
设计需要转向时：理解会变，重访设计是好事；不要大爆炸式重设计，而是用小而安全的步骤让代码与测试驶向新模型，尽量保持绿灯。改主意有成本，这是小步此前换来的速度的账单。
反模式：巨型步骤（首次跑测试前写半天代码）、事后补测试、把覆盖率当目标、绿灯阶段镀金、“没时间测试/重构”、代码所有权心态。
范围说明：本技能设定节奏；红绿重构细节用 tdd，命名与局部结构用 clean-code，耦合/connascence 审查用 architect-lens，无测试可依的遗留代码先用 refactor-to-testability 搭建安全网，再回到本循环。限制与收费方式等资料暂未提供。