小团队 SQL 改写落地模板¶
- 沉淀时间：2026-09-09
- 来源：
origin/summer-intern的 SQL 改写第一周落地包与 Agent 能力探索任务说明 - 成熟度：
provisional - 适用范围：1–3 人、以一周为最小交付周期的 SQL 改写或 Agent 能力验证项目
最小管理面¶
首周不需要先建复杂平台，一套可审计台账即可承载工作：
| 载体 | 记录什么 |
|---|---|
| Case tracker | 输入、负责人、状态、阻塞、产物路径和验收结论 |
| Benchmark | 基线版本、参数、环境、执行次数、统计值和结果一致性 |
| 执行 Checklist | 每个 case 的固定步骤与证据门禁 |
| 周报 | 本周完成、数据变化、主要 blocker、下周动作和需决策事项 |
| Prompt 模板 | 输入字段、约束、输出 schema 和人工复核点 |
一周节奏¶
Day 1 锁定样本、环境和成功指标
Day 2 跑通少量端到端 case，暴露真实 blocker
Day 3 修流程和证据链，不盲目扩大样本
Day 4 批量执行并记录失败分类
Day 5 汇总指标、复盘、归档可复用知识
任务按 P0 / P1 分层。P0 是没有它就无法形成可信交付的能力，例如固定测试集、自动化执行、结果一致性和产物可追踪；P1 是模式探索或体验增强，可以根据进度取舍。
合流点¶
不同方向不能只在最终汇报时碰面。上下文、Memory、评测和数据标注至少要在三处合流：
- 早期统一输入 schema、case_id 和评测指标。
- 中期用同一批 case 做接口和产物联调。
- 收尾用统一基线做 A/B、回归和知识归档。
升级机制¶
执行人报告卡点时应包含 case、阶段、失败次数、最后错误、证据路径和需要谁决策。负责人只处理需要取舍的事项；可由契约和脚本判定的问题应回到流程修复。
反模式¶
- 第一周先做平台，尚未跑通一个可审计 case。
- 只报告“完成多少条”，不记录失败阶段和证据。
- 每个方向自行设计 schema，直到最终才集成。
- 目标写成提升百分比，却没有固定 baseline 和测试集。
- 把调研清单当成已验证结论归档。
限制¶
来源文档是实习与首周方案，没有对应合入和完成报告。时间分配与样本数量仅供规划参考，正式采用前应按团队能力、数据库权限和验证成本校准。