工程案例
Rootloom：让编码智能体的工程变更可检查
把风险分级、根因定位、范围约束和证据诚实验证组织成可检查的 Codex 工程工作流。
角色
我的角色与范围
产品设计、工程实现、文档与验证，2026 · 持续迭代。
问题
要解决什么
编码智能体可以很快修改代码，但“改了什么、为什么这样改、是否触及真正的不变量、验证证据是否足够”经常散落在提示词和日志里，难以复查。
Rootloom 面向真实仓库工作流，把任务授权、风险、根因、变更范围、验证和完成声明放进同一套可检查约束中，同时避免把普通任务变成过重流程。
范围
目标与不做事项
目标
- 让修改范围、诊断依据、执行动作和完成声明保持一致
- 按风险选择足够但不过度的工作流和验证证据
- 把稳定的项目事实沉淀在最近边界的 AGENTS.md 中
不做事项
- 替代仓库规格、测试、Lint、安全扫描、持续集成或人工审查
- 让所有任务都运行同一套深度治理流程
约束
现实边界
- 需要兼容 Codex 的插件、Skill 和项目指导机制
- 日常任务必须保持轻量，高风险任务才进入更严格的治理路径
- 建议的检查不能冒充已经运行并观察到的证据
决策
真正影响结果的取舍
用风险信号决定流程深度
把持久化状态、权限、迁移、共享契约和破坏性操作等作为风险信号，普通变更直接走证据、诊断、修改、验证，高风险变更再增加契约和最终复核。
在行为所有者边界修复根因
先建立现象、触发状态、所有权路径和被破坏不变量的证据链，减少下游特判、吞异常或放宽断言造成的伪修复。
区分建议、执行结果与语义判断
命令退出码为零只证明该命令通过；最终仍需核对范围、仓库状态和任务验收条件，避免把“跑过测试”直接等同于“任务完成”。
主流程
架构与实现
主流程：任务意图与授权 → 风险分级 → 仓库证据与根因 → 最小一致变更 → 比例化验证 → 最终范围与证据复核。
能力分层：日常 Change / Review / Guidance 保持轻量；Autonomy、Evidence 和 Project Memory 作为显式可选能力，不在安装后静默启用。
证据
如何确认它真的工作
结果
已经产生的影响
- 形成覆盖变更、审查和项目指导的轻量核心路径
- 把高风险授权、证据采集和项目记忆拆为显式可选能力
- 通过公开文档、契约检查和发布记录让工作流本身可复查
边界
限制与后续
当前限制
- 它约束工程过程，但不能替代项目本身的正确规格与领域判断
- Project Memory 仍是实验能力，当前仓库证据始终优先
后续
- 继续用真实仓库任务校准风险分级和验证强度
- 扩充兼容性与失败模式文档，同时保持日常路径轻量