ub-mode：把工程纪律装进智能体

定位：一份工程纪律规则

ub-mode 不是带有运行时的框架，也不是把代码改动接管下来的自治流程。它只有一份说明文件，作用是在智能体写代码或改代码时，把工作约束到一个明确的三阶段顺序里：先让变更跑通，再把实现修正到可长期维护，最后用日志、上下文管理和提交纪律把过程留住。作者在说明文件开头就把这个顺序写成硬性要求，避免智能体把“拿到结果”和“交出可靠结果”混成同一步。

这个设计的关键在于它不假装能代替人的工程判断。规则会要求先写失败测试、把复杂数据形状想清楚、减少共享可变状态，但真正检查复杂度、重复和变异测试存活率的工具都放在独立仓库里。因此，把它理解成一份可装载的工程行为合同更准确；合同有了，执行质量仍取决于智能体是否遵守，以及团队是否接上配套工具。

第一阶段：先让变更跑通

第一阶段的重点不是快，而是减少不必要的工作。规则要求一个决策只放在一个地方，交付能解决问题的最小编辑。这里的“懒惰”不是省掉理解成本，而是拒绝过早抽象、拒绝把改动扩大到当前问题之外。它还要求先确定数据形状，再写处理逻辑；凡是能让后续所有阶段受益的动作先做。也就是说，模型结构、边界和状态所有权被放在逻辑铺开之前。

测试驱动开发在这一阶段被写得非常具体：先写失败测试，确认它以预期原因失败，再用最小修改让它通过。如果诚实的测试不可行，规则禁止用劣质测试凑数。这个细节很重要，因为它把测试当成行为证据，而不是为了覆盖率而存在的形式。

当需求不能自然装进旧设计时，规则要求回到第一性思考：不把新要求硬挂在旧结构上，而是想象这个需求从一开始就存在时会怎么设计，再把那个设计拆成可交付的小块。若两个共享同一前提的修复反复撞上同一个问题，规则要求把这个前提写成一句话，数出哪一方承担了失衡的责任，移除这个错误指派，然后才开始下一个修复。它还要求在增加任何东西之前先移除复杂度，把注意力对准能检查的最终状态，而不是漫无目的地重写。

架构约束：把非法状态挡在外面

ub-mode 的架构段可以看成五个可执行的判断标准。第一，领域模型要让非法状态无法表达，并维护领域术语表；如果现有代码已经清晰、局部，就不必为了形式而重写。第二，在数据进入系统的地方检查它，进入内部后信任它，把业务逻辑放进纯函数。第三，类型系统要参与设计，让非法值写不出来，外部数据只在入口解析一次，并且不许静默压掉编译器给出的信号。

第四，操作要幂等：重复执行一次，或者在执行中途崩溃后重试，都应该收敛到同一个状态。第五，若多个执行方不需要共享同一个可变对象，就给它们各自的状态；确实必须共享时，只允许一个写入方，并用结构把这个约束固定下来。这些规则没有指定语言或框架，但共同指向同一件事：让错误更难被写出来，让并发和重试的后果可以被推理。

第二阶段：把实现修正到可维护

第一阶段跑通之后，规则不允许把粗糙实现直接当成完成。第二阶段要求先复现问题，再修因；只吞掉崩溃的守卫不算修复。工作也要拆成小的可验证单元，完成一个、检查一个，再开始下一个。测试必须面向用户可见的行为，按用户会调用的方式去调用代码；如果一个测试在所有函数都不返回值时仍然通过，说明它测的是实现细节，应当丢弃。

这个阶段的特色是配套质量门。Crapper 计算每个函数的圈复杂度、测试覆盖率和变更风险分数，目标是让每个函数的风险分数低于 10，必要时通过拆分、补测试或两者并用达到。Dryer 检测结构化重复，要求消除相似度达到 0.8 及以上的重复块。Mutator 运行变异测试，覆盖尚未被测试触达的代码，消灭存活突变体，并删除死代码。uml-viewer 则把组件、覆盖率、风险分数、变异得分和依赖方向可视化，帮助团队看到质量门背后的整体结构。

重构规则补上了安全顺序：先固定当前行为，再改变结构，最后证明行为没有变化。这里的质量观很清楚——代码不仅要通过测试，还要有足够小的单元、足够的变异杀灭率、更少的重复和可追踪的结构变化。

第三阶段：让过程可审计

最后一段针对智能体工作流里最容易丢失的部分。规则要求记录每个动作和背后的原因，并在任务结束时报告这份日志。这样，最后的结果不再是黑箱里凭空出现的补丁，读者可以回看每一步为什么发生。

上下文管理也被当成正式工作项：主线程保持小，把大块工作送到别处，只保留摘要。工作区清理要求先判断哪些内容可以安全移除，确认没有仍在使用的东西，再回收磁盘；未提交的变更必须等待一个明确决定。提交则要小、有序、频繁，每条提交说明为什么改、改了什么、如何证明行为正确，最后推送回主线。

适合谁，以及边界在哪

ub-mode 最适合已经有代码评审和测试基础的智能体开发流程。它给出的不是新语法，而是一套可以约束模型行为的顺序：避免把探索性改动直接美化成完成品，避免让测试变成实现细节的镜子，也避免质量检查只停留在人工感觉。

边界同样明确。安装方式是把说明文件复制到智能体的技能目录，然后通过斜杠命令触发；上游文档给出 Claude 和 Cursor 目录作为示例，也提到 Grok 目录。它本身没有可执行代码，许可证信息在仓库元数据中没有给出，因此不能假设任何授权条款。Crapper、Dryer、Mutator 和 uml-viewer 是四个独立仓库，使用前需要分别查看和接入。对想要一个“一键自动保证代码质量”的团队来说，这个技能不会满足预期；它更适合被当成纪律层，配合外置工具和人的评审共同生效。