ECC 工程纪律

问题

当你把一段代码交给 Agent 生成或修改时，最常见的失败不是模型"不会写"，而是它写得太多：明知生态里已有成熟库，却从零实现一套；明明该写测试，却先堆实现再补；改完不自查，硬编码密钥和拼接 SQL 留在文件里；同一份代码自己写、自己审，盲点原地循环。工程纪律的缺失，比模型能力不足更致命。

如何工作

ECC 工程纪律把约束前置到每一行代码落盘之前，加载后覆盖 Marvis 写代码、改代码、交付的全流程：

• 开工前强制 Research & Reuse：任何新功能前先过决策矩阵。已有库覆盖需求就直接引入，开源方案解决 80% 以上问题就复刻适配，只有完全无方案才进 TDD。
• TDD 铁律：新功能、Bug 修复、重构都必须走完整测试循环，每一步调用真实工具，不允许跳过或假装。覆盖率目标 80%+，测试按 AAA 结构写，命名描述预期行为。
• 编码硬约束：函数不超过 50 行、文件不超过 800 行、嵌套不超过 4 层、严禁原地修改、严禁空 catch、死代码零容忍。违者当场修正。
• 安全自检：每次 write_file 后自查四项——无硬编码凭据、无 SQL 拼接、用户输入有校验、日志不泄露敏感信息。
• 独立审查：写完必须通过 dispatch_task 分派到独立上下文，写代码的 Agent 不能审自己。CRITICAL 阻断交付，同批代码最多审查 3 次。
• 语言特定规则：TypeScript/JavaScript、Python、Go、Rust 各有专属章节，覆盖类型系统、不可变性、错误处理、密钥管理、测试工具链和设计模式适配。
• 交付检查清单：测试全绿、审查无 CRITICAL、安全自检通过、硬约束满足、commit 规范，五项全过才算交付。

适用边界

• 无硬拦截：原版 ECC 的 PreToolUse/PostToolUse Hooks 在 Marvis 上无法等效实现，规则依赖 Agent 自觉遵守，edit_file 不会自动拒绝超标代码。
• 审查非专用模型：独立审查用通用 Agent 模拟，满足上下文隔离，但不是审查专长模型，OWASP 深度扫描也无 SAST 集成。
• 覆盖有限：ECC 原版 67 个专用 Agent 仅迁移 3 个，22 种语言规则仅覆盖 4 种，200+ Skills 未迁移，只是标注引用名供查阅。
• 按需评估：Java、C#、Kotlin 等语言规则需按项目实际需求后续迁移，无法批量套用。