复杂改造真正难的不是写代码，而是控制跨层一致性

在交叉表改造里业务上的直接诉求其实不复杂原有“表格”展示更适合看明细但当用户想同时按多个维度做横纵对比时比如看“某类指标在不同区域、不同时间段上的分布关系”普通表格的阅读成本会迅速升高。交叉表的价值就在于把这种“按行看分组、按列看展开、在交点看结果”的分析方式直接放进查询结果里。真正的难点并不是把一个新组件写出来而是让多个链路在同一次改造里稳定协同配置层要支持结果视图切换以及行维度、列维度的独立编排参数层要保证组参、历史回填、重置逻辑在双模式下都成立渲染层要把交叉表从原有展示方式升级为 Canvas并接入已有查询和看板链路这类需求的风险通常不在单点实现而在跨层契约容易断裂。如果只用传统“问答式 AI Coding”推进常见结果是某一段代码看起来能运行但改造一旦跨过多个模块AI 就容易丢上下文、误扩散修改范围最后把问题从“实现功能”变成“收拾集成阶段的连锁回归”。所以这次复盘的重点不是交叉表本身做了多少业务能力而是superpowers如何把复杂改造组织成一个可控、可验证、可复用的交付过程。2. 为什么是 superpowers从问答式 AI 到工程化协作框架这次项目里superpowers承担的不是“多写代码”的角色而是“组织 AI 参与方式”的角色。它的核心价值是先把协作过程标准化再让 AI 进入编码阶段。相比直接让 AI 对着需求生成代码superpowers更强调几个前置动作先固定目标、范围、非目标和验收口径避免需求在实现中漂移先收敛仓库上下文只暴露高相关模块避免 AI 无边界扩散修改先拆成可独立验证的阶段再逐段交付而不是一次性大改每轮失败都结构化回灌让 AI 根据证据修复而不是反复猜测这套方法的意义在于它把 AI 从“代码补全器”提升为“受约束的协作执行者”。对复杂前端需求来说真正决定交付效率的往往不是 AI 能不能写出局部代码而是它能不能在约束下持续输出可合并结果。3. superpowers 在这次改造中的三个关键动作3.1 任务归一化先统一问题定义再开始实现交叉表改造如果直接进入编码很容易把工作理解成“新增一种展示组件”。但在真正的业务链路里它实际上是一个跨配置、跨参数、跨渲染的联动改造。这次在进入实现前先通过superpowers把任务统一成几个明确结论目标不是单点替换组件而是在不破坏原查询链路的前提下支持双模式运行非目标要提前锁死例如不改后端协议、不新增拖拽依赖、不碰无关业务模块验收口径不是“能看到交叉表”而是模式切换、参数回填、渲染接入要形成完整闭环这一步的直接收益是把后续实现从“边写边补需求”变成“围绕固定边界推进”。对于 AI 协作来说这比任何 prompt 技巧都更重要因为约束清晰之后输出才会稳定。3.2 最小上下文投喂限制 AI 的修改半径复杂需求的另一个常见问题是上下文投喂过多导致 AI 把不该改的地方一起改掉。这次没有把整条业务链都摊给 AI而是只围绕高相关模块收敛上下文例如FilterscrossConditionBoxquery/helpcrossTable这种最小上下文策略核心不是省 token而是控制​修改半径​。当 AI 只围绕关键模块做推理时它更容易理解当前阶段真正的契约减少跨模块误改和“顺手重构”。3.3 分段交付与失败回灌让修复建立在证据上这次改造没有一次性推进到底而是按三个阶段逐步落地先锁定维度语义模型再打通参数闭环最后推进 Canvas 渲染接入每一段都有独立验证点出问题时也不是笼统地说“这里不对”而是把错误类型、位置、复现路径和期望差异结构化回灌给 AI。这样 AI 的下一轮修复不再依赖猜测而是基于明确证据收敛。这一步直接降低了两类成本无效往返避免同一个问题被反复用不同方式试错集成爆炸避免多个未验证修改堆到最后一起出问题4. 三个案例superpowers 如何具体作用到代码行为为了避免方法论变成空泛总结这里只保留三个最能说明superpowers价值的技术证据点。先补一层最小业务语境这次交叉表并不是单纯把字段换个摆放方式而是要支持用户把分析维度拆成“行维度”和“列维度”再在交点上查看聚合结果、汇总和对比关系。也正因为它天然同时牵涉配置、参数和渲染三层所以非常适合作为superpowers方法是否有效的验证样本。4.1 语义契约先锁定dimensions dimType在维度模型上这次没有把行维度和列维度拆成两套独立字段而是保留统一dimensions再通过dimType区分行列语义表格模式下继续使用统一dimensions交叉表模式下通过dimType: row | column补充语义这里体现出的superpowers价值不在于它提出了某个字段名而在于它推动团队先把“唯一契约”定下来再进入实现。一旦契约明确模式切换、历史回填、别名共存这些后续问题都能沿同一条路径推进避免出现两套字段并行演进、后期再做状态迁移的额外成本。4.2 参数闭环先定义resultDisplayMode分流规则真正决定功能是否可用的不是界面能不能切换而是参数链路是否闭环。这次在参数层先锁定一条核心规则由resultDisplayMode决定是否进入交叉表分流组参。在这个前提下rowDimIds从dimType row || !dimType的维度里提取colDimIds从dimType column的维度里提取仅在交叉表模式下透出交叉表专属参数这背后体现的是一种很典型的superpowers工作方式先确定模式边界再让 AI 生成实现细节。这样改造过程里每一段代码都在回答同一个问题即“当前模式该产生什么参数”而不是在多个文件里各自理解展示语义。4.3 渲染分层先拆职责边界再做 Canvas 化渲染层同样不是先写代码而是先拆边界。交叉表 Canvas 改造在职责上先分成四类容器与滚动状态单元格绘制可视窗口计算渲染契约定义运行时再分成corner、header、frozen、body四层画布。这样处理的价值不只是性能优化更是把后续定位问题的成本降下来。冻结区、滚动区、窗口计算各有独立职责出了问题更容易追到具体层而不是在一个巨大的渲染文件里混合排查。从superpowers视角看这一步体现的是“先拆模块责任再推进实现”的纪律。AI 很擅长补结构化代码但前提是边界已经被定义清楚一旦边界清晰AI 在这里的产出就更容易稳定落到可合并区间。5. 收益提效不只体现在编码速度更体现在返工减少如果只看 AI 参与了多少代码容易把这次改造理解成“AI 帮忙写了一部分实现”。但从实际复盘看superpowers带来的收益主要体现在交付过程而不只是编码速度。5.1 更值得关注的是流程指标这类复杂需求里更有解释力的指标不是“AI 写了多少行”而是一次通过率是否提高平均修复轮次是否下降单需求交付周期是否缩短回归缺陷和返工成本是否下降这些指标更能直接反映superpowers的作用因为它真正优化的是协作过程中的不确定性而不是单点生成能力。5.2git-ai指标记录从本次交叉表改造的统计看AI 参与度本身并不低统计 commit 数4AI 参与 commit 数4AI 代码占比11.3%AI 留存率90%