核心用法
loop-constructor-codex 是一款面向 OpenAI Codex CLI 的工程设计技能，用于将中大型（半）自主编码任务转化为结构化的闭环循环体系。它不直接执行代码，而是产出可机检的循环设计 JSON 与可执行运行手册（.loop/ 目录）。
核心流程遵循 SELECT → NEGOTIATE → FILL → VERIFY → PERSIST 五阶段：
1. SELECT（选择）：执行 D0-D6 决策程序，从"是否为循环"到"迭代策略"逐层推导循环结构，生成决策日志
2. NEGOTIATE（协商）：分离规划者/生成者/评估者三角色，协商可测试的契约断言（防止自评导致的谄媚偏差）
3. FILL（填充）：写入标准格式的循环设计 JSON，包含每阶段的完成定义、反馈信号、停止条件等
4. VERIFY（验证）：通过 lint_loop_design.mjs 结构校验 + 新鲜读者清单语义校验双重 gate
5. PERSIST（持久化）：渲染为带 Codex CLI 运行指引的可执行运行手册
关键设计原则：从检查倒推设计——每个循环必须以机器可运行的"完成检查"为锚点，无检查即非循环。
显著优点
- 工程化严谨性：用决策程序替代"凭感觉选型"，所有设计选择可追溯、可评审
- 对抗性验证：强制三角色分离，评估者以"发现错误"为指令运行，根治自评谄媚
- 机器可检契约：契约断言数量有下限（端点≥8/模块≥12/应用≥20），防止橡皮图章
- Codex 原生映射：清晰对应
codex exec进程、git worktree 并发、磁盘状态持久化等运行时概念 - 故障恢复设计：支持
on_failure: restart策略，避免补丁堆积成考古遗址 - 跨技能兼容：与
loop-constructor共享 JSON Schema，设计可跨运行时复用
潜在缺点与局限性
- 认知门槛高：需要理解循环工程原理、角色分离模型、契约驱动开发等概念，非开箱即用
- 设计 overhead：简单任务可能因完整流程显得笨重，D0-D6 决策程序对小型脚本有过度设计之嫌
- 依赖外部 KB：需要
loop-principle知识库支撑，缺失时降级为"KB 降级模式" - 仅设计不执行：产出运行手册后仍需人工或外部系统触发 Codex 执行，非一键自动化
- 并行性受限：Codex CLI 当前仅支持进程级并发（
codex exec多实例），无原生 sub-agent 机制 - 契约质量依赖协商：若生成者与评估者"共谋"薄弱契约，评估可能流于形式
适合的目标群体
- AI 辅助开发团队：需要系统化管理多轮 Codex 会话、避免上下文混乱的工程师
- 复杂任务拆解场景：中大型功能开发、跨模块重构、需要多阶段验收的代码生成任务
- 质量敏感型用户：对"AI 幻觉"高度警惕，需要可验证、可审计的代码产出流程
- 流程标准化需求者：希望将个人 Codex 使用经验沉淀为团队可复用运行手册的技术负责人
- 循环工程研究者：探索人机协作闭环设计、对抗性验证、停止条件优化的前沿实践者
使用风险
- 性能风险：多阶段循环 + 频繁磁盘 I/O（状态持久化）可能增加任务延迟；大型设计的并发
codex exec可能触发速率限制 - 依赖项风险：依赖
loop-principleKB 路径解析、Node.js 脚本环境、Codex CLI 版本兼容性；$LOOP_PRINCIPLE环境变量配置错误导致降级 - 设计失效风险：机器通过的 linter 无法捕捉语义级缺陷（如
falsifiable_when描述的是目标而非真实故障模式），需依赖人工 fresh-reader 检查 - 契约僵化风险：过度严格的断言下限可能催生"凑数"契约，反而掩盖真实质量问题
- 运行时漂移：设计时的 Codex 版本与执行时版本行为差异可能导致运行手册失效
- 数据持久风险：磁盘状态是跨
codex exec的唯一记忆，路径配置错误或清理脚本误删导致循环断片