SQL 改写项目管理设计¶

分支文档快照 · 同步于 2026-09-09 · 来源：origin/summer-intern @ 9f4cdc5 · 原路径：docs/superpowers/specs/2026-07-09-sql-rewrite-project-management-design.md。正文描述的是该分支的方案或进展，合入与验收状态以当前看板为准。

日期：2026-07-09

背景¶

团队共有三人。PM 负责路线设计和方案设计，通常不参与单条 SQL 的具体执行。资深开发负责技术判断和方案质量。初级开发可以完成执行层面的工作，但需要明确指导。

项目目标是提升分布式 SQL 的优化效果。目前端到端优化率约为 15%，目标是 50%。前期在集中式数据库上已经能达到约 60%，所以当前挑战不仅是 SQL 改写知识本身，还包括分布式数据库行为、Agent 自动化可靠性、模型输出质量，以及可重复的项目过程管理。

现有 SQL 改写 skill 已经具备多阶段流程：元数据采集、规则匹配、AI 改写、验证、重试、索引建议、规则发现。项目管理方案应该让这些阶段变得可观察，同时不引入过重流程。

目标¶

在不引入重型工具的前提下，让优化进度可见。
区分真实 SQL 能力缺口，以及 Agent、模型、服务、数据环境导致的问题。
将失败 SQL 沉淀为可复用的失败模式和工程资产。
让 PM 管路线和优先级，而不是陷入单条 SQL 细节。
减少资深开发对初级开发的重复指导。
利用 AI 生成摘要、聚类、缺陷草稿和周报。

非目标¶

第一阶段不引入重型项目管理平台。
PM 层面不跟踪每个执行细节。
不把每条失败 SQL 都当成一个长期缺陷管理。
每日新增慢 SQL 不作为核心优化率口径，除非它们被转成可复现的 benchmark 候选。

管理模型¶

采用两个输入轨道和两个归因层级。

输入轨道¶

Benchmark 回测轨

这是优化率指标的主要来源。它使用稳定数据库和稳定 SQL 集，可以反复运行。所有规则、prompt、Agent 或流程改动，最终都应该在这里验证效果。

每日慢 SQL 分诊轨

这里接收来自业务测试库的每日新增慢 SQL。由于这些 SQL 不一定能稳定反复测试，所以主要用于快速分诊、反馈和发现新问题。有代表性或可复现的 SQL，可以转入 benchmark 候选集。

归因层级¶

端到端结果层

这是 PM 视角，回答三个问题：优化率是多少，是否提升，本周主要被什么问题拖住。

失败原因层

这是执行和技术视角，回答失败到底来自 SQL 能力、Agent 编排、模型输出、模型调用，还是数据环境。

每条失败 SQL 都应先归因，再分配处理。不是所有失败都叫 SQL 优化失败。

缺陷分类¶

使用五个一级缺陷类型。

缺陷类型	含义	主要负责人
SQL 能力	流程正常运行，但改写无收益、语义不安全、规则未覆盖，或在分布式 SQL 特征上失败。	资深开发
Agent 编排	Agent 没有执行预期阶段、跳过重试、参数传错、上下文缺失，或自动化流程失败。	资深开发
模型输出	模型输出非法 JSON、字段缺失、夹带多余文本、修改字面值或输出列名，或违反 skill 约束。	资深开发
模型调用	模型调用失败、超时、返回空、限流，或出现认证、网络、服务稳定性问题。	初级开发先排查，系统性问题由资深开发处理
数据环境	数据库、权限、执行计划、统计信息或业务测试环境导致验证不可靠。	初级开发先补齐信息，必要时 PM 协调

轻量看板¶

看板只保留四个泳道。第一阶段可以使用表格、Markdown、飞书表格或任何轻量工具。

Benchmark 回测

放每周 benchmark 批次、回归结果和 benchmark 结论。

SQL 能力攻关

放可复用的 SQL 优化失败模式，例如分布式 JOIN、下推、聚合、排序分页、分片键、语义等价风险、规则缺失和规则冲突。

Agent/模型可靠性

放模型调用失败、非法输出、阶段跳过、自动化中断、元数据缺失、重试触发问题和 skill 指令遵守问题。

每日慢 SQL 分诊

放每日新增慢 SQL。状态保持简单：待分诊、处理中、已反馈、转 benchmark 候选、转缺陷。

缺陷卡片模板¶

每张缺陷卡片只保留路由和验收所需字段。

标题：
缺陷类型：SQL 能力 / Agent 编排 / 模型输出 / 模型调用 / 数据环境
来源：Benchmark 批次 / 每日慢 SQL
影响 SQL 数：
失败阶段：Phase 0 / Phase 1 / Phase 2 / Phase 2.5 / Phase 2-RETRY / Phase 2.6 / Phase 3
现象：
证据：SQL 编号、日志、输出片段、结果 CSV
初步原因：
负责人：
下一步动作：
验收方式：

最重要的字段是 缺陷类型，因为它决定负责人和优先级。

团队分工¶

PM¶

PM 负责方向和优先级，不负责单条 SQL 执行。

定义阶段目标，例如四周内将端到端优化率从 15% 提升到 30%。
每周选择 Top 1-3 个失败模式或可靠性阻塞。
判断资源应该投入 SQL 能力、Agent 编排、模型可靠性还是数据环境。
查看周报并做取舍决策。
当数据环境或业务测试访问阻塞进展时，协调外部资源。

资深开发¶

资深开发负责技术闭环。

对失败模式做最终归因确认。
设计 SQL 改写规则、prompt 调整、Agent 编排修复和验证策略。
审核高风险改写和语义等价问题。
维护 benchmark 回归质量。
将重复指导沉淀为初级开发可使用的 checklist 和 AI prompt。

初级开发¶

初级开发负责执行闭环。

运行每周 benchmark 批次。
保存结果 CSV、日志、失败 SQL 编号和关键输出片段。
做一级分类：SQL 能力、Agent 编排、模型输出、模型调用、数据环境。
为 Top 问题准备最小复现材料。
分诊每日慢 SQL 并记录反馈。
将有代表性的每日慢 SQL 提交为 benchmark 候选。

AI 助手¶

AI 作为项目助理和技术助理，不作为最终技术裁判。

生成批次摘要。
将失败 SQL 聚类为失败模式。
起草缺陷卡片。
生成日报或周报。
辅助初级开发执行 checklist。
基于历史缺陷模式建议可能负责人和优先级。

周节奏¶

周一：计划会，30 分钟¶

查看上周指标。
选择本周 Top 1-3 个失败模式或可靠性阻塞。
明确本周验收标准。

周二到周四：执行与攻关¶

初级开发跑批、收集日志、准备缺陷草稿。
AI 生成失败聚类和摘要草稿。
资深开发确认高价值根因，并实现或评审修复。
每日同步只讨论阻塞。

周五：回测与复盘，45 分钟¶

运行 benchmark 回归。
与上一批次对比指标。
关闭已验收缺陷。
识别回归问题。
产出下周建议。

每日慢 SQL 不应主导周节奏。它们只做分诊、反馈，并选择性转入 benchmark 候选或缺陷。

指标体系¶

每周跟踪六个指标。

指标	定义	用途
端到端达标率	达标 SQL 数 / SQL 总数	PM 层面的成功指标
流程成功率	完整跑完预期阶段的 SQL 数 / SQL 总数	Agent 自动化可靠性
格式合规率	合法模型输出数 / 模型输出总数	模型输出可靠性
语义通过率	语义验证通过的改写数 / 已改写 SQL 数	改写安全性
有效改写率	流程成功、语义通过且性能提升达标的 SQL 数 / 流程成功 SQL 数	真实 SQL 优化能力
Top 失败模式贡献	某失败模式影响 SQL 数 / 未达标 SQL 数	优先级选择

PM 主要看三个结论：

端到端达标率是否提升。
如果没有提升，阻塞来自 SQL 能力还是 Agent/模型可靠性。
本周选择的 Top 1-3 个阻塞是否缩小。

AI 自动化产物¶

先从四个固定 AI 产物开始。

批次摘要¶

输入：结果 CSV、summary 文件、日志。

输出：

批次编号：
SQL 总数：
端到端达标率：
流程成功率：
格式合规率：
语义通过率：
有效改写率：
相较上一批变化：
Top 失败模式：
建议下周优先级：

失败聚类¶

输入：失败 SQL、分析文本、错误日志、失败阶段。

输出：

失败模式：
影响 SQL：
缺陷类型：
疑似阶段：
共同特征：
建议负责人：
建议下一步动作：

缺陷卡片草稿¶

输入：一个失败模式或一条失败 SQL。

输出：尽可能自动填充缺陷卡片模板和证据。

PM 周报¶

输入：批次摘要、缺陷变化、关闭项。

输出：

本周结论：
指标变化：
最大阻塞：
已解决问题：
未解决风险：
下周建议：
需要 PM 决策：

第一周落地¶

第一周不要搭系统，也不要引入重流程。只做五件事。

建立 benchmark 基线

运行一批稳定 benchmark，记录 SQL 总数、端到端达标率、流程成功率、格式合规率、语义通过率、有效改写率和 Top 失败模式。

建立轻量台账

先使用以下字段：

ID
来源：Benchmark / 每日慢 SQL
SQL 编号
缺陷类型
失败阶段
失败模式
影响 SQL 数
负责人
状态
下一步动作
验收方式

给初级开发执行 checklist

是否跑完批次
是否保存结果 CSV
是否保存关键日志
是否标出失败阶段
是否用 AI 生成失败聚类
是否补齐缺陷证据
是否整理不确定项给资深开发确认

保护资深开发确认时间

设置固定的每日确认窗口。初级开发需要带着 Top 失败模式、疑似原因、证据、建议动作和明确问题来确认。

产出一页周五 PM 周报

端到端达标率：
流程成功率：
格式合规率：
有效改写率：
Top 3 阻塞：
已关闭缺陷：
下周优先级：
需要 PM 决策：

验收标准¶

第一轮落地在一周后满足以下条件，即视为成功：

有可信的 benchmark 基线。
每条失败 SQL 都能归入五类缺陷之一。
团队能按影响 SQL 数或影响程度说清 Top 3 阻塞。
SQL 能力问题和 Agent/模型工程问题被明确拆开。
PM 只看一页报告，就能判断项目是否正在向 50% 目标靠近。

运行原则¶

按失败贡献度管理优化率，而不是按零散任务活动管理团队。团队应该少问“大家这周做了什么”，多问“哪个失败模式正在阻塞下一次可度量提升”。