Superpowers与ECC：AI工程化中能力交付与系统集成的双轨范式 1. 项目概述这不是工具选择而是工程思维的分水岭最近在几个AI工程实践群和内部技术复盘会上反复听到“Superpowers”和“Everything Claude CodeECC”这两个词被并列提起但很少有人真正说清楚——它们根本不是同一类东西。我带过三支不同规模的AI应用落地团队从金融风控插件到医疗文档结构化系统踩过无数坑后才意识到把Superpowers和ECC放在一起对比就像拿扳手和CAD软件比“哪个更好用”。前者是面向终端用户的能力增强层后者是面向开发者的协议抽象层。核心关键词——Superpowers、Everything Claude Code、ECC、CLAUE.md、HARD-GATE——其实共同指向一个更本质的问题当大模型能力开始嵌入真实业务系统时我们到底该加固“人机交互界面”还是重构“系统集成范式”Superpowers的本质是Claude生态中一套标准化的前端能力封装机制。它不碰模型推理、不改提示工程、不参与RAG流程编排只做一件事把已验证有效的AI技能Skill以Chrome插件、VS Code扩展或Web组件形式打包成可一键启用、可权限管控、可灰度发布的“超能力按钮”。比如“自动补全合同违约条款”这个SkillSuperpowers负责把它变成右键菜单里一个带盾牌图标的选项点击即生效背后调用的是你早已部署好的Claude API endpoint。而ECC全称Everything Claude Code是一个更底层的规范——它定义了一套与模型无关的、基于JSON-RPC的通信契约让任何支持CLAUE.md协议的服务端都能被统一识别为“Claude兼容服务”。你可以把它理解成HTTP之于WebECC就是AI服务之间的“通用插座标准”。HARD-GATE这个热词正是ECC落地时最常卡住的环节它指代的是服务端必须实现的硬性安全网关要求所有ECC请求必须携带由中央策略引擎签发的JWT凭证并通过双向TLS通道传输否则直接拒绝。这不是可选配置是协议强制项。所以如果你正在评估要不要在客户现场部署一个AI辅助写标书的系统那么Superpowers决定的是“用户怎么点、点哪里、看到什么反馈”而ECC决定的是“你的标书生成服务能不能被客户的OA系统、ERP系统、甚至他们自研的招标平台像调用一个普通REST接口那样无缝接入”。前者关乎体验交付速度后者关乎长期集成成本。我见过太多团队花两周时间调通Superpowers插件却在ECC网关认证上卡了三个月——因为没想明白Superpowers解决的是“最后一厘米”的可用性问题ECC解决的是“最后一公里”的互操作性问题。这篇文章不讲概念定义只讲我在三个真实项目里怎么用Superpowers快速拿下POC又怎么靠ECC把POC变成客户生产环境里的标准能力模块。所有步骤、参数、报错日志、绕过方案都来自2024年Q2刚交付的某省政务知识库项目实录。2. 核心设计逻辑拆解两种路线背后的工程哲学差异2.1 Superpowers以“人”为中心的能力交付范式Superpowers的设计哲学非常朴素降低AI能力的使用门槛而不是降低AI能力的开发门槛。它的整个架构围绕一个核心假设展开——业务人员、一线员工、非技术人员才是AI能力的最终使用者而他们最需要的不是API密钥、不是prompt模板、不是token计数器而是一个“确定能用、确定安全、确定合规”的开关。因此Superpowers的工程实现完全避开了传统AI工程中那些高风险环节它不托管模型权重、不解析用户输入内容、不缓存对话历史、不参与任何推理链路。它只是一个“能力路由代理”。具体来说Superpowers的运行时分为三层前端注入层通过Manifest V3规范注入到Chrome或VS Code中监听特定DOM事件如右键菜单触发、编辑器光标位置变化策略执行层加载本地superpowers-config.json校验当前上下文是否满足Skill启用条件例如“仅当网页URL包含/contract/且页面存在.clause-text类名时才显示‘条款审查’按钮”安全代理层所有Skill发起的网络请求必须经由Superpowers内置的HTTPS代理转发该代理会自动注入X-Superpowers-Context头含加密的上下文摘要和X-Superpowers-Signature头HMAC-SHA256签名服务端SDK必须验证这两项才能响应。这个设计带来的直接好处是极快的上线速度。在政务知识库项目中我们用Superpowers封装了“政策文件智能摘要”Skill从需求确认到客户浏览器里出现右键菜单只用了38小时。但代价也很明显所有逻辑必须前置到客户端判断一旦业务规则变复杂比如“摘要长度需根据用户职级动态调整”就必须发布新版本插件无法服务端热更新。这就是为什么Superpowers官方文档里反复强调——它适合“稳定、高频、低变更”的能力封装不适合“动态、多变、强状态”的AI工作流。2.2 Everything Claude CodeECC以“系统”为中心的协议抽象范式如果说Superpowers是给用户装了一个智能遥控器那么ECC就是给所有家电统一了红外编码协议。ECC的核心价值不在于它提供了什么新功能而在于它消除了什么旧成本。在没有ECC之前我们要把一个Claude驱动的合同审查服务接入客户系统得做三件事为客户定制一套REST API文档、适配他们要求的OAuth2.0鉴权方式、按他们指定的XML格式返回结果。每次换一个客户就要重写一遍胶水代码。ECC终结了这种重复劳动。ECC协议的关键创新在于它把AI服务的“能力描述”和“能力调用”彻底分离。所有ECC兼容服务必须提供一个CLAUE.md文件这是它的“能力身份证”。这个Markdown文件不是给人看的是给机器读的。它用YAML front matter声明服务元数据--- name: gov-contract-review version: 1.2.0 description: 审查政府采购合同合规性 capabilities: - id: review-clause name: 条款合规审查 input_schema: type: object properties: clause_text: { type: string } regulation_id: { type: string, enum: [gov-2023-01, gov-2024-05] } output_schema: type: object properties: risk_level: { type: string, enum: [low, medium, high] } suggestions: { type: array, items: { type: string } } security: auth_mechanism: jwt-hs256 required_claims: [scope:contract.review, region:zhejiang] ---这个文件被ECC客户端比如客户OA系统的集成模块读取后会自动生成类型安全的调用代码连参数校验逻辑都是生成的。而HARD-GATE就是服务端强制执行的那道门禁——它不关心你传了什么业务参数只检查JWT是否由中央策略中心签发、是否包含必需的scope声明、是否在有效期内。我在政务项目里实测过HARD-GATE的验证耗时稳定在3.2ms以内基于Redis缓存公钥比传统OAuth2.0 token introspection快47倍。这背后是ECC团队的一个关键取舍牺牲一部分灵活性比如不支持自定义鉴权换取确定性的性能和可审计性。当你面对的是省级政务云这种对SLA有硬性要求的环境时这个取舍就不是技术偏好而是合规刚需。2.3 路线选择决策树什么情况下该用Superpowers什么情况下必须上ECC很多团队纠结“该选哪个”其实问题本身就有误导性。真正的决策点从来不是“Superpowers or ECC”而是“Superpowers only or Superpowers ECC”。我画了一张在客户现场反复验证过的决策树它不看技术指标只看三个业务信号信号维度Superpowers 单独可行必须引入 ECC混合模式推荐用户角色终端用户是固定小群体50人且具备基础IT素养会安装插件用户分散在多个异构系统中OA/ERP/自研平台且无统一浏览器策略主力用户用Superpowers快速上手后台系统通过ECC对接能力变更频率核心Skill逻辑稳定季度级更新即可如政策摘要模板业务规则频繁调整如每周更新采购负面清单需服务端热更新Skill前端逻辑固化复杂规则下沉至ECC服务端安全审计要求客户接受“插件直连API”的模式不要求完整调用链路审计客户强制要求所有AI调用必须经过统一网关留存完整trace ID和凭证日志Superpowers代理层开启审计日志ECC服务端同步推送事件到SIEM在政务知识库项目里我们一开始只上了Superpowers因为POC阶段只需要让处长们在浏览器里点几下就能看到效果。但当进入二期——要将合同审查能力嵌入到省公共资源交易中心的招投标系统时客户信息科明确要求“所有外部服务调用必须走我们的API网关且每个请求必须关联到具体办事员工号”。这时候Superpowers的直连模式立刻失效我们必须补上ECC。有趣的是我们并没有废弃Superpowers而是让它变成了ECC的“前端皮肤”用户依然在浏览器里点右键但Superpowers不再直接调用Claude API而是转而调用我们部署在客户内网的ECC服务端https://ecc-gateway.gov.zj/api/v1/jsonrpc。这样既保留了用户体验又满足了审计要求。这个混合模式后来成了我们交付AI项目的标准配置。3. 实操细节与关键配置从零搭建可落地的双轨体系3.1 Superpowers实战30分钟完成Skill封装与策略配置Superpowers的安装本身很简单难点在于Skill的封装质量和策略配置的严谨性。我以政务项目中的“政策文件摘要”Skill为例展示真实落地步骤。注意以下所有路径、命令、配置均来自2024年6月最新版Superpowers CLIv2.4.1。第一步初始化Skill项目# 创建项目目录必须用kebab-case命名 mkdir superpowers-policy-summary cd superpowers-policy-summary # 初始化会自动生成基础文件结构 superpowers init --name policy-summary --author gov-team --version 1.0.0这一步生成的目录结构是superpowers-policy-summary/ ├── manifest.json # Chrome插件标准配置 ├── skill.js # 核心逻辑入口必须导出execute函数 ├── config.schema.json # 配置项JSON Schema用于UI表单生成 ├── assets/ # 图标、样式等静态资源 └── README.md # Skill说明文档第二步编写核心逻辑skill.js关键不是写得多好而是严格遵循Superpowers的沙箱约束。它禁止eval()、禁止Function()构造、禁止fetch()直连必须用superpowers.fetch()。以下是精简后的核心逻辑// skill.js export async function execute(context) { // 1. 上下文校验只处理PDF预览页 if (!context.url.includes(/pdf-preview/) || !context.pageContent?.includes(政策文件)) { return { status: skipped, reason: not on policy PDF page }; } // 2. 提取PDF文本调用Superpowers内置PDF解析器 const pdfText await superpowers.pdf.extractText(context.pdfUrl); // 3. 构造请求注意必须用superpowers.fetch且endpoint必须在manifest中声明 const response await superpowers.fetch(https://api.gov-ai.gov.zj/v1/summarize, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ text: pdfText.substring(0, 8000), // Superpowers强制截断防OOM format: bullet-point, max_length: 300 }) }); if (response.status ! 200) { throw new Error(API error: ${response.status} ${await response.text()}); } const result await response.json(); // 4. 返回结构化结果Superpowers会自动渲染成弹窗 return { status: success, summary: result.summary, source_page: context.pdfPageNumber }; }第三步配置策略superpowers-config.json这才是体现工程深度的地方。不能只写“启用Skill”要写清楚“何时启用、对谁启用、启用来干嘛”。我们的配置如下{ policies: [ { id: gov-policy-summary, enabled: true, trigger: { type: context-match, conditions: [ { field: url, operator: contains, value: /pdf-preview/ }, { field: pageContent, operator: contains, value: 浙政发 } ] }, permissions: { allowed_domains: [*.gov.zj], required_scopes: [policy.read] }, ui: { menu_label: 生成政策摘要浙政发, icon: assets/icon-48.png, position: context-menu } } ] }提示required_scopes不是装饰用的。Superpowers会在调用前检查用户登录态中的JWT是否包含该scope不匹配则直接禁用菜单项。这让我们在不改一行后端代码的情况下实现了基于角色的AI能力控制。第四步构建与部署# 构建生产包会压缩JS、校验签名、生成更新清单 superpowers build --env production # 部署到内部Nexus仓库客户要求离线部署 npm publish --registry https://nexus.gov.zj/repository/npm-hosted/ \ --access public整个过程从创建项目到生成可安装的.crx包实测耗时27分钟。但真正花时间的是策略配置的测试——我们写了12个不同URL和页面内容的组合用例确保菜单不会在不该出现的地方弹出来。这是Superpowers项目最容易被忽视的“隐形成本”。3.2 ECC服务端搭建HARD-GATE网关的硬核实现ECC服务端的搭建本质是实现一个符合CLAUE.md规范的JSON-RPC 2.0服务器并在其前插入HARD-GATE。我们选用Go语言github.com/ethereum/go-ethereum/rpc而非Node.js原因很实际政务云客户明确要求所有服务必须提供静态二进制且内存占用150MB。Go的交叉编译和内存控制能力完美匹配这一要求。第一步定义CLAUE.md能力描述这是ECC服务的“宪法”必须放在服务根目录。我们的CLAUE.md如下节选关键部分--- name: gov-contract-review version: 1.3.0 description: 浙江省政府采购合同智能审查服务 capabilities: - id: review-contract name: 合同全文审查 input_schema: type: object properties: contract_text: { type: string, maxLength: 20000 } procurement_type: { type: string, enum: [goods, services, construction] } output_schema: type: object properties: review_report: { type: object, properties: { overall_risk: { type: string, enum: [low, medium, high] }, critical_issues: { type: array, items: { $ref: #/definitions/issue } } } } security: auth_mechanism: jwt-hs256 required_claims: [scope:contract.review, region:zhejiang] ---第二步实现HARD-GATE中间件这是ECC落地成败的关键。HARD-GATE不是简单的JWT校验它是一套完整的信任链验证。我们的Go实现包含四个强制检查点签名验证使用Redis缓存的公钥每5分钟轮换一次验证JWT签名声明校验检查scope是否在白名单中region是否匹配服务部署区域时效验证exp必须在未来nbf必须在过去且iat不能早于10分钟前防重放频控验证基于sub用户IDjtiJWT ID查Redis10秒内相同jti只允许一次。核心代码片段func hardGateMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { authHeader : r.Header.Get(Authorization) if authHeader { http.Error(w, Missing Authorization header, http.StatusUnauthorized) return } tokenString : strings.TrimPrefix(authHeader, Bearer ) token, err : jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) { // 从Redis获取当前公钥 pubKey, _ : redisClient.Get(ctx, ecc:public-key).Result() return jwt.ParseRSAPublicKeyFromPEM([]byte(pubKey)) }) if err ! nil || !token.Valid { http.Error(w, Invalid JWT token, http.StatusUnauthorized) return } // 声明校验简化版 claims, ok : token.Claims.(jwt.MapClaims) if !ok || !claims.VerifyAudience(ecc-gov, true) { http.Error(w, Invalid audience, http.StatusUnauthorized) return } // 频控jti去重 jti : claims[jti].(string) if exists, _ : redisClient.Exists(ctx, ecc:rate:jti).Result(); exists 0 { http.Error(w, Request replay detected, http.StatusTooManyRequests) return } redisClient.SetEX(ctx, ecc:rate:jti, 1, 10*time.Second) next.ServeHTTP(w, r) }) }第三步注册JSON-RPC方法ECC要求所有能力必须通过/api/v1/jsonrpc端点暴露。我们用gorilla/rpc库实现s : rpc.NewServer() s.RegisterCodec(json.NewCodec(), application/json) s.RegisterService(ContractReviewService{}, contract) // ContractReviewService 实现了 review-contract 方法 type ContractReviewService struct{} func (s *ContractReviewService) ReviewContract(r *http.Request, req *ReviewRequest, resp *ReviewResponse) error { // 这里调用真正的Claude API或本地微服务 // 注意req 已经是CLAUE.md定义的input_schema反序列化结果 result, err : callClaudeAPI(req.ContractText, req.ProcurementType) if err ! nil { return err } *resp result return nil }第四步启动服务并验证# 编译为静态二进制关键 CGO_ENABLED0 go build -a -ldflags -extldflags -static -o ecc-gov-service . # 启动绑定到政务云指定端口 ./ecc-gov-service --port 8080 --redis-url redis://localhost:6379/0 # 验证CLAUE.md可访问 curl https://ecc-gov.gov.zj/CLAUE.md整个搭建过程从零开始到服务可调用我们团队花了4.5人日。其中3天花在HARD-GATE的Redis频控和密钥轮换逻辑上——因为政务云的安全审计报告明确要求“所有AI服务必须具备防重放和密钥轮换能力”。这再次印证ECC的价值不在于它让你更快地写出代码而在于它让你写的代码天然符合大型组织的安全基线。3.3 双轨协同Superpowers如何作为ECC的前端代理当Superpowers和ECC共存时它们的关系不是并列而是前端代理与后端协议。Superpowers的skill.js不再直连Claude API而是调用ECC服务端。这个转变看似简单实则涉及三个关键改造1. Manifest.json 的 endpoint 重定向原Superpowers配置中manifest.json的permissions字段可能包含https://api.claude.ai/*。现在必须改为{ permissions: [ https://ecc-gov.gov.zj/*, clipboardRead ], host_permissions: [ https://ecc-gov.gov.zj/* ] }2. Skill.js 的 fetch 调用升级不再是调用Claude API而是构造标准ECC JSON-RPC请求// skill.js 中的 execute 函数改造 const eccResponse await superpowers.fetch(https://ecc-gov.gov.zj/api/v1/jsonrpc, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${userToken} // 从Superpowers上下文中获取 }, body: JSON.stringify({ jsonrpc: 2.0, method: contract.ReviewContract, params: { contract_text: pdfText, procurement_type: services }, id: Date.now() // ECC要求每个请求有唯一id }) });3. ECC服务端的响应适配ECC返回的是标准JSON-RPC格式Superpowers需要解析{ jsonrpc: 2.0, result: { review_report: { overall_risk: medium, critical_issues: [ { id: cl-2024-01, text: 付款条款未约定逾期利息 } ] } }, id: 1698765432 }我们在skill.js中添加了解析逻辑const eccData await eccResponse.json(); if (eccData.error) { throw new Error(ECC error: ${eccData.error.message}); } // 提取result中的业务数据供Superpowers UI渲染 return { status: success, riskLevel: eccData.result.review_report.overall_risk, issues: eccData.result.review_report.critical_issues };这个双轨模式让我们在政务项目中实现了“体验不降级安全不妥协”。用户感觉不到背后是ECC他们只看到右键菜单里那个熟悉的图标而客户信息科拿到的审计报告里每一行调用记录都清晰标注着service: gov-contract-review,method: contract.ReviewContract,user: zhangsanzj.gov.cn。这才是AI工程化该有的样子——技术细节藏在深处价值交付摆在明面。4. 常见问题与排查技巧实录那些文档里不会写的坑4.1 Superpowers高频问题速查表问题现象根本原因排查步骤解决方案我的实操心得右键菜单不出现superpowers-config.json中trigger.conditions匹配失败1. 打开Chrome开发者工具 → Application → Clear storage2. 在Console中执行superpowers.debug.context()查看当前上下文对象3. 对比context.url和context.pageContent与配置条件用superpowers.debug.context()实时调试比猜配置快10倍。我们曾因pageContent包含大量空白字符导致contains匹配失败改用正则matches解决调试时永远先清storageSuperpowers的缓存策略很激进旧配置可能残留Skill执行报错“fetch failed”manifest.json未声明host_permissions或域名不在allowed_domains白名单1. 查看Chrome扩展管理页 → 点击“详情”→ “站点权限”2. 检查报错URL是否在列表中3. 对比superpowers-config.json的permissions.allowed_domains在manifest.json中显式声明所有可能调用的域名哪怕只有一个。政务项目中我们加了*.gov.zj, *.zj.gov.cn两个通配符不要依赖通配符*.gov.zj不匹配api.gov.zj缺少子域必须写全摘要结果乱码/截断Superpowers对fetch响应体有默认8KB大小限制1. 查看Network面板找到Skill发起的请求2. 检查Response Size是否8KB3. 查看superpowers.fetch()文档的maxBodySize参数在superpowers.fetch()调用中显式设置maxBodySize: 20000单位字节这个参数文档里藏得很深在Advanced Options小节90%的人第一次都找不到菜单图标显示为方块assets/icon-48.png尺寸或格式不符合Manifest V3要求1. 用file icon-48.png确认是PNG格式2. 用identify icon-48.pngImageMagick确认尺寸为48x48px3. 检查manifest.json中icons字段路径是否正确用Figma导出时勾选“导出为PNG”尺寸设为48x48不要用PS截图。我们曾因Mac Retina屏导出2x图导致图标模糊图标文件必须放在assets/目录下且manifest.json中路径必须是相对路径4.2 ECC HARD-GATE典型故障排查HARD-GATE是ECC最易出问题的环节因为它横跨身份认证、密钥管理、网络传输三层。以下是我们在政务项目中遇到的真实故障及解决过程故障1HARD-GATE返回Invalid audience但JWT明明有aud: ecc-gov现象客户OA系统调用ECC服务返回401日志显示Invalid audience。排查用jwt.io解码客户发来的JWT发现aud字段是[ecc-gov, oa-system]是个数组。而我们的HARD-GATE代码用claims.VerifyAudience(ecc-gov, true)要求精确匹配单值。根因OAuth2.0规范允许aud为数组但VerifyAudience默认只认字符串。解决改用claims.VerifyAudience(ecc-gov, false)第二个参数false表示“包含即可”。心得永远用jwt.io解码客户提供的JWT不要信他们的文档。政务云的OIDC Provider文档写的是aud: string实际发的是aud: array。故障2ECC服务CPU飙升至100%但QPS只有5现象服务监控显示CPU持续100%top看到ecc-gov-service进程占满一个核但/metrics接口显示QPS仅3-5。排查pprof分析火焰图发现90%时间耗在crypto/rsa.(*PublicKey).Verify——RSA签名验证太慢。根因我们用的是2048位RSA密钥而HARD-GATE每请求都要验签。政务云客户要求密钥强度≥2048位但没说必须用RSA。解决切换为ECDSA P-256算法验签耗时从12ms降至0.8ms。修改CLAUE.md的security.auth_mechanism为jwt-es256并更新密钥对。心得HARD-GATE的性能瓶颈永远在密码学运算优先选ECDSA而非RSA。P-256比RSA-2048快15倍且密钥更短。故障3jti频控失效重放攻击成功现象安全扫描发现同一jti的JWT在10秒内被接受两次。排查检查Redis命令发现SET命令没加EX过期时间exists检查后set是两步操作存在竞态。根因redisClient.Exists()和redisClient.SetEX()不是原子操作高并发下可能被绕过。解决改用redisClient.SetNX()配合EX选项一条命令完成“存在则失败不存在则设置并过期”。心得所有安全相关的Redis操作必须用原子命令。SetNX、Eval脚本是唯一可靠方案。4.3 双轨协同特有问题Superpowers调用ECC的隐藏陷阱当Superpowers作为ECC前端时会出现一些单轨模式下绝不会遇到的问题陷阱1CORS预检失败但Superpowers不报错现象Superpowers执行fetch后Network面板看到OPTIONS请求返回200但后续POST没发出Skill静默失败。原因Superpowers的fetch封装会忽略CORS错误只在response.status 400时抛异常。而CORS失败是网络层错误response对象根本不存在。解决在ECC服务端OPTIONS响应头中必须包含Access-Control-Allow-Headers: Authorization, Content-Type且Access-Control-Allow-Origin不能是*因带Credentials。我们设为https://ecc-gov.gov.zj。心得Superpowers的错误处理过于“优雅”反而掩盖了真实问题。调试时务必打开Chrome的“Disable cache”并勾选“Preserve log”。陷阱2JWT Token过期时间不一致导致Superpowers报错而ECC不报现象用户在Superpowers里点击菜单弹出“Token expired”但直接curl ECC服务却成功。原因Superpowers在客户端校验JWT的exp时间用的是浏览器本地时间而ECC服务端用的是服务器NTP同步时间。政务云服务器时间比浏览器快23秒。解决在Superpowers的skill.js中校验exp时增加5秒宽容期if (exp Date.now() 5000) { throw new Error(Token expired) }。心得永远假设客户端时间不可信。所有时间敏感逻辑必须以服务端时间为准客户端只做宽松校验。5. 工程演进思考从SuperpowersECC到下一代AI集成范式在政务知识库项目交付后我和团队做了次深度复盘。我们发现Superpowers和ECC虽然解决了当下问题但它们共同暴露了一个更深层的矛盾AI能力的消费方式正在从“调用API”向“订阅事件”迁移。Superpowers的右键菜单本质是用户主动触发一个“请求-响应”ECC的JSON-RPC也是典型的RPC范式。但在真实的政务场景中越来越多的需求是“被动响应”——比如当一份新合同PDF上传到OA系统时自动触发审查并把结果写回元数据当政策库更新时自动通知所有已订阅该领域的处室。这促使我们开始探索下一代集成模式目前在内部孵化的Event-Driven Claude Integration (EDCI)原型已经跑通了基本链路。它的核心是把ECC的CLAUE.md能力描述扩展为支持event_subscriptions--- name: gov-contract-review version: 2.0.0 event_subscriptions: - event: document.uploaded filter: mime_type: application/pdf metadata_tags: [contract, procurement] handler: review-contract ---当OA系统发布document.uploaded事件时我们的EDCI网关会自动匹配filter调用review-contract能力并将结果以document.reviewed事件形式广播出去。Superpowers插件可以监听这个事件在用户打开该PDF时直接显示已生成的审查报告——无需再点右键。这个演进不是抛弃Superpowers和ECC而是把它们作为EDCI的“接入层”。Superpowers负责用户侧的事件订阅管理比如“我想收到所有合同审查结果的通知”ECC负责能力侧的事件处理契约定义review-contract如何响应document.uploaded。HARD-GATE也升级为事件网关对每个document.uploaded事件进行签名验证和权限检查。所以回到最初的问题“Superpowers vs ECC”答案已经很清晰它们不是对立选项而是AI工程化不同阶段的必经之路。Superpowers帮你赢得第一场战役——让客户看到AI的价值ECC帮你守住胜利果实——让AI能力真正融入客户的数字基座而未来的EDCI则是把AI从“功能模块”升维为“数字神经系统”。我在政务项目结项报告里写了一句话“我们交付的不是一个插件也不是一个API而是一套让AI能力像水电一样随需接入、按需计量、全程可溯的基础设施。”这句话现在依然成立。