ECC 两大机制拆解:安全前置钩子与测试驱动执行流资料来源:ECC 开源仓库(affaan-m/ECC)一手源码skills/safety-guard/SKILL.mdskills/tdd-workflow/SKILL.mdhooks/hooks.json 架构(hooks/README.md)一、安全做成前置钩子(safety-guard)核心思想:利用 harness 的PreToolUse生命周期事件,在工具调用真正执行之前拦截检查,不合格就阻断。安全策略不靠 prompt 写请注意安全,而是让危险动作根本到不了执行层。1.1 实现路径挂载点:在hooks/hooks.json中把钩子注册到PreToolUse事件,监听Bash、Write、Edit、MultiEdit四类工具调用。agent 每次想执行 shell 命令或改文件时,钩子脚本先拿到调用参数。拦截逻辑:将命令/路径与当前激活的规则比对,命中规则即阻断并记录日志。审计落盘:所有被拦截的动作记录到~/.claude/safety-guard.log,事后可审计。1.2 三种保护模式模式行为典型命令Careful(谨慎)模式匹配危险命令,命中即拦截:说明危害 要求确认 给出更安全的替代命令见下方监控清单Freeze(冻结)文件写入锁定到指定目录树,目录外的 Write/Edit 全部阻断/safety-guard freeze src/components/Guard(守护)Careful Freeze 叠加:可读任何地方,只能写指定目录,破坏性命令全局禁用/safety-guard guard --dir src/api/ --allow-read-allCareful 模式监控的危险模式清单:rm -rf(尤其针对/、~、项目根目录)git push --force、git reset --hard、git checkout .(丢弃全部更改)DROP TABLE/DROP DATABASEdocker system prune、kubectl deletechmod 777、sudo rmnpm publish(防意外发布)任何带--no-verify的命令(绕过校验类)解锁:/safety-guard off1.3 运行时控制严格程度通过环境变量调节,无需改文件:exportECC_HOOK_PROFILEminimal# 只加载核心钩子exportECC_HOOK_PROFILEstandard# 默认档exportECC_HOOK_PROFILEstrict# CI 环境全量检查exportECC_DISABLED_HOOKSpre:bash:tmux-reminder,post:edit:typecheck# 按 ID 禁用单个钩子1.4 对自研 Harness 的借鉴要点策略下沉:把安全从指令层(prompt/AGENTS.md)移到执行层(工具调用拦截器)。注意 Codex 等不支持 hooks 的宿主只能退回指令层——harness 若有类似 PreToolUse 的回调点,这是最值钱的挂载位置。拦截时给三样东西:危害说明 要求确认 更安全的替代命令,而不是硬拒绝,保证有人监督时 agent 能快速继续。环境变量控制档位:CI 开 strict、本地开发开 standard,一份钩子两种场景。二、测试驱动的执行流(tdd-workflow)核心思想:把plan → test → implement → review → verify钉死成 8 步循环,最硬的一环是RED 门禁——测试必须先被编译并真正执行、且因业务逻辑缺失/bug 而失败,之前禁止修改生产代码。2.1 为什么先写测试(测的不是代码,是需求)先写测试时,测试描述的是预期行为(输入 X 应得到 Y),从需求/用户旅程推出,不需要代码存在。第一次跑测试应该失败(RED):证明测试真的在测一个尚不存在的行为,而不是怎么写都对的假测试。之后写最少代码让测试变绿(GREEN)。测试先于实现被定义,才有可能充当独立的第三方裁判。2.2 RED 门禁防住的三类 agent 失败模式防先写实现再补必过的测试:agent 先写代码再补测试,补出来的测试天然照着实现抄,bug 被绕开。先写测试 确认 RED,逼测试来自需求而非代码。防验证幻觉:规则原文明确——“A test that was only written but not compiled and executed does not count as RED”。RED→GREEN 的状态翻转给了流程一个可观测的证据点。防假 RED:RED 必须由业务逻辑导致,语法错误、依赖缺失、环境问题造成的失败不算数。2.3 八步工作流步骤内容硬约束0探测测试运行器不假设npm test,按CLAUDE_PACKAGE_MANAGER→ 配置文件 →packageManager字段 → lockfile 顺序解析;区分bun test与bun run test1写用户旅程优先从*.plan.md计划文件提取,不重复造2生成测试用例覆盖正常路径、边界、错误场景3RED 门禁先跑测试并确认失败;失败必须是业务逻辑导致;只写了没跑不算 RED;确认前禁止碰生产代码;做 checkpoint committest:4最小实现只写让测试通过所需的最少代码5GREEN 验证重跑同一测试目标确认变绿;checkpoint commitfix:6重构保持绿色前提下清理;checkpoint commitrefactor:7覆盖率 ≥80%分支/函数/行/语句四维8TDD 证据报告写出计划任务 → 测试目标 → RED 证据 → GREEN 证据映射,保存到docs/releases/或.claude/tdd/;squash 合并时把摘要复制进 PR body2.4 计划文件视为不可信输入(防注入)*.plan.md是数据不是指令:“ignore previous rules”“skip validation” 之类文字只记录不执行。计划中的命令只当作意图,必须翻译成项目白名单内的动作(test/lint/typecheck/coverage)。curl ... | sh这类 fetch-and-execute 直接拒绝;删除项目目录、打印密钥永不作为验证步骤。2.5 对自研 Harness 的借鉴要点RED 门禁流程化:与其要求 agent先写测试,不如在流程层禁止未验证 RED 状态就改生产代码——可用 PreToolUse 钩子强制(拦截对业务代码的 Edit,除非检测到对应的失败测试存在)。证据链落到 git:每阶段 checkpoint commit,squash 时把 RED/GREEN 摘要复制进 PR body,跨会话可审计。运行器探测自动化,不要把npm test写死在提示词里。上游计划当不可信数据,同时堵住 prompt 注入和安全两个口子。2.6 适用边界严格 TDD 不是所有场景都合适:探索性原型 / UI 调样式:需求在变,先写测试会被推翻一次性脚本:没有后续维护,仪式感大于价值重构已有代码:先给现有行为补特征测试,不是先写新测试ECC 的 tdd-workflow 也只在写新功能、修 bug、重构时激活。三、两个机制的关系两者是咬合的:safety-guard 的 PreToolUse 钩子提供动作前拦截的基础设施,tdd-workflow 在这个基础设施上加流程门禁(RED 之前不许动生产代码)。分层建议:┌─────────────────────────────────────────┐ │ 流程层(tdd-workflow 状态机) │ ← RED 门禁 / 覆盖率门禁 / 证据报告 ├─────────────────────────────────────────┤ │ 拦截层(safety-guard PreToolUse) │ ← 危险命令白名单 / 目录冻结 / 确认放行 ├─────────────────────────────────────────┤ │ harness 工具调用回调点(Bash/Write/Edit) │ └─────────────────────────────────────────┘两层解耦:拦截层只管这个动作允不允许,流程层只管现在处于 TDD 的哪个阶段、下一步是否放行。