我把每天 4 小时的重复性文档工作压到 40 分钟

---

先说结论：把「需要判断」和「需要执行」彻底分开，再用确定性工具把执行端兜底，才是真正能落地的 AI 工作流。别指望一个大模型从读需求到出交付全包了——它会在格式、字段、命名规范这些鸡毛蒜皮上翻车，最后你还得人工擦屁股。

我现在的流程只有三层：

第一层：需求结构化，只让 LLM 做「理解」和「拆解」
输入：原始会议纪要 / 产品文档 / 客户邮件
输出：结构化 JSON，字段固定，包含 任务类型、优先级、依赖上下文、验收标准、预估工时
Prompt 里只有一条硬规则：不允许生成任何可执行代码、SQL、配置文件。它只负责「读懂」和「拆解」。

{
  "task_type": "data_pipeline",
  "priority": "P0",
  "context": "用户行为埋点表 schema 变更，需同步更新下游 3 张宽表",
  "acceptance": "宽表字段与新 schema 一致，历史数据回填无缺失",
  "estimated_hours": 2.5
}

第二层：确定性执行引擎，零 LLM 参与
拿到 JSON 后，直接喂给内部维护的 Task Runner（Python + Jinja2 + SQLGlot）：

• 根据 task_type 选模板
• 用 SQLGlot 做 AST 级别的 schema diff，自动生成 ALTER TABLE / CREATE OR REPLACE VIEW
• Jinja2 渲染出完整的 Airflow DAG、dbt model、单元测试 stub
• 全程不经过任何模型推理，全是确定性转换，CI 跑通才算通过

第三层：人工只做「验收」和「例外处理」
Runner 产出的 PR 自动分配给对应 owner，CI 绿了直接合。只有两种情况要人介入：
1. acceptance 里写明需人工核对的业务规则（如「金额字段四舍五入逻辑需财务确认」）
2. Runner 抛出 UNHANDLED_PATTERN——说明遇到模板库里没覆盖的新场景，这时候才轮到我写新模板

---

踩过的坑，省你踩：

• 别让 LLM 写 SQL。哪怕给它 schema、给它 few-shot，JOIN 顺序、分区裁剪、窗口函数语法它都能给你整花。SQLGlot + 模板才是正解。
• 别把「理解」和「生成」混在一个 Prompt 里。拆成两次调用，中间夹一个结构化校验器（Pydantic / JSON Schema），成本涨不了多少，稳定性指数级上升。
• 模板库要版本化、可回滚、可审计。我们把所有 Jinja2 模板放在单独 repo，每次改动走 Code Review，Runner 启动时拉取指定 tag。出问题 git bisect 定位模板版本，比在对话历史里找 Prompt 快十倍。
• 工时预估别信 LLM 的。它会乐观 2-3 倍。我们在 JSON 里加了 estimated_hours，但实际排期乘以 1.5 系数，再按团队历史完成率修正。

---

现在的节奏：
早上 9:30 拉取 overnight 积压的结构化任务 JSON → 10:00 前 Runner 全部跑完、PR 全部开好 → 10:30 代码评审集中处理 → 11:00 前合入主干。剩下的时间真正干「需要人类判断」的事：和业务对齐口径、设计新模板、处理例外。

这套流程跑了三个冲刺，团队人均交付周期从 3.2 天降到 1.4 天，不是模型变强了，是把它该干的活留给它，不该干的活全剥离了。

如果你也在搞数据/后端/文档类重复性工作，建议先别急着买 Copilot Enterprise，先把自己团队的「确定性模板」梳理出来——这才是杠杆。

---