三层合起来才是闭环AI 编程铁三角怎么一起用本文是「AI 编程铁三角」系列的第四篇也是收束篇。前三篇分别讲了三层Harness 给 Agent 准备可工作的工程环境OpenSpec 把需求变成可执行规格Superpowers 按流程完成代码变更。本篇不再展开任何一层的细节而是回答一个问题这三层为什么必须一起上少一层会怎样以及它们在一个真实变更里如何前后衔接。一、先说清楚铁三角不是三个工具是三个控制面很多人会把铁三角理解成三个工具选一个用。这是误解。铁三角的三层不是互相替代的工具而是三个互补的控制面OpenSpec固化需求和设计——回答做什么、为什么、边界在哪Superpowers把工作组织成可执行流程——回答怎么做、按什么顺序、每步留什么证据Harness用上下文、权限、脚本和质量门禁约束 Agent 行为——回答在什么环境里做、不能碰什么、怎么证明做对了三者共同形成「规范—执行—验证」的闭环。判断是否落地成功只看三类职责是否完整不看工具名字是否一致——OpenSpec 可以由企业已有的需求/设计模板实现Superpowers 可以由 Skills、命令和工作流脚本实现Harness 可以由AGENTS.md、CLAUDE.md、CI、Pre-commit、权限网关和内部知识库共同构成。二、少一层会怎样把三层拆开看每一层缺失都会导致一类典型问题。只用 Harness没有 OpenSpecAgent 在一个约束良好的仓库里跑得很快但跑的是谁的需求不清楚。没有规格Agent 会自己补齐合理但不一定正确的默认值失败次数按用户名还是按来源表满走 fail-open 还是 fail-close时钟回绕怎么处理这些决策每个都影响系统行为却都藏在 Agent 的合理默认里审查者很难发现。症状代码跑得快、测试也过但做错了事。只用 OpenSpec没有 Superpowers规格写得很清楚但 Agent 执行时跳步直接改代码、一次改太多、忽略失败测试、看到报错连续打补丁让代码碰巧通过、修复症状而不是根因。规格再好没有流程约束Agent 照样会在执行环节把规格意图走样。症状规格很完整代码却对不上规格审查时才发现漏了关键边界。只用 Superpowers没有 Harness流程很规范先写失败测试、小步提交、两轮审查。但 Agent 跑在错误分支、脏工作区、过期构建结果上能修改不该改的目录能外发不该外发的数据。流程约束了怎么改却约束不了在哪改、能碰什么。症状流程都对但环境失控证据不可信。三层都没有这就是大多数团队上 AI Coding 的现状先装工具再让开发者自行摸索。每个人用法不同Agent 反复猜测构建方式和目录边界最终形成大量不可复用的对话风险被放大而不是被控制。三、三层之间的数据流三层不是平行关系而是有明确的数据流OpenSpec 产物 ──► Superpowers 任务输入 │ ▼ 代码 测试 │ ▼ Harness 持续约束上下文/权限/门禁 │ ▼ 验证结果回写变更记录 ──► 归档OpenSpec 的产物proposal / behavior / design / tasks是 Superpowers 的输入。Superpowers 产生的代码和测试接受 Harness 的持续约束。验证结果再回写变更记录并完成归档。这条数据流的关键在于单向依赖Superpowers 读 OpenSpec但 OpenSpec 不依赖 Superpowers 的实现细节Harness 约束 Superpowers 的执行但 Superpowers 不负责定义 Harness 的规则。每一层只对自己的职责负责边界清晰。四、一个变更里三层如何衔接用一个防暴力破解的变更走一遍看三层如何前后衔接。阶段一Harness 先行变更开始前Agent 开始任务前先跑scripts/context.sh拿到当前分支、基线测试、工具链版本。AGENTS.md告诉它不得修改third_party/、不得改变对外 API、数据面热路径禁止动态内存分配。PreToolUse Hook 拦住任何试图写入禁止目录的动作。这一步的意义Agent 在一个可约束的环境里开始工作边界由技术控制不靠口头承诺。阶段二OpenSpec 固化决策编码前变更目录openspec/changes/add-mgmt-bruteforce-guard/里有四类产物proposal.md为什么做、范围、影响、风险等级 L3specs/behavior.md失败 N 次锁定、窗口滚动、表满策略design.mdauth_guard_check()接口契约、状态机、并发模型、所有权tasks.md小步任务和验证命令规格评审确认Agent 可以在不发明任何关键决策的前提下开始工作。内存分配失败走 fail-close、时钟回绕由 time 模块统一处理、HA 切换时状态如何同步——这些决策都写清了不是 Agent 自选。这一步的意义所有会影响系统行为的决策在编码前被看见。阶段三Superpowers 按流程执行编码中Agent 按九步工作流推进读取规范与上下文Harness 提供的CONTEXT.md OpenSpec 的变更目录风险分级确认L3公开接口变化需人工审批编写任务计划基于tasks.md先写失败测试RED——test_lock_user_when_failures_reach_threshold实现至通过GREEN重构REFACTOR静态分析与增量验证verify_changed.sh代码审查两轮先规格符合性再代码质量目标侧验证与分支收尾每个任务 15–60 分钟独立可编译可测试。完成报告引用真实命令和返回码不是代码看起来正确。这一步的意义每一步都产生可审查证据Agent 不能跳步。阶段四归档变更结束后变更目录移动到archive/归档包包含最终规格、审查意见、CI 链接、设备报告、性能数据、已知限制、回滚说明。后续新增按租户策略时以该归档为基线创建新变更不直接修改历史记录。这一步的意义任何时刻都能回答这段代码当年为什么这么写。五、三层各自的到位标准把三层的自检问题放一起就是铁三角的到位标准Harness 到位了吗Agent 一条命令能否拿到当前分支、基线测试和工具链版本Agent 试图修改禁止目录或改变对外 API 时会不会被自动阻断每次任务结束时Agent 能不能列出验证命令和返回码OpenSpec 到位了吗读完规格能不能在不发明任何关键决策的前提下开始写测试每条行为规格是否都有可执行的验证命令对应内存分配失败、表满、时钟回绕、HA 切换这些边界规格里写清了吗Superpowers 到位了吗Agent 是先写失败测试再写实现还是直接改代码审查是分两轮先规格符合性、再代码质量还是混在一起看实现细节完成报告引用的是真实命令和返回码还是代码逻辑看起来正确九个问题都能答是铁三角才算闭环。任何一层缺位都会在某个环节把风险放大。六、不必绑定具体产品三层是职责划分不是工具绑定。OpenSpec 可以由企业已有的需求/设计模板实现Superpowers 可以由 Skills、命令和工作流脚本实现Harness 可以由AGENTS.md、CLAUDE.md、CI、Pre-commit、权限网关和内部知识库共同构成。不同 Agent 对指令文件名称和加载规则不同建议以一份平台无关的源文件为准再同步到各工具入口详见第一篇。判断是否落地成功只看三类职责是否完整不看工具名字是否一致。七、结语从偶尔写对到稳定产出AI 能显著缩短代码生成、测试编写、信息检索和问题分析的时间但它不会自动理解企业架构也不会自然承担质量责任。真正可持续的做法是把 Agent 放入已有的软件工程体系并用规格、流程和约束把其能力转化为稳定产出Harness让上下文、权限和门禁在整个生命周期持续生效——解决在哪做、能碰什么OpenSpec让关键决策在编码前被看见——解决做什么、边界在哪Superpowers让工作按小步、TDD、审查和验证推进——解决怎么做、怎么证明三者结合后AI 才从偶尔能写对代码的助手转变为受控、可审计、可复用的研发执行力。这不是一次培训能落地的而是靠仓库改造、试点场景、门禁建设和指标复盘逐步形成。推广顺序应从具体问题出发避免先建设一个大而全平台。每个阶段都要以可工作的仓库和真实变更为验收避免只完成制度、模板和工具安装。铁三角的真正价值不在于让 AI 写得更快而在于让 AI 的产出可被信任。