如何用AI+确定性工具将4小时文档任务压缩至40分钟

将重复性文档工作高效转化的核心在于清晰分工：让AI仅负责需求解析，将实际执行交由确定性工具处理。这避免了模型在细节上（如格式、字段命名）的出错风险，也杜绝了“读需求到交付全流程”的不切实际期望。

三层流程设计：分解、执行、验证

1. 第一层：需求解析阶段（AI专区）
输入：会议纪要、产品文档或客户邮件。
输出：固定JSON结构，包含任务类型、优先级、依赖上下文等。关键在于Prompt限制：禁止任何可执行代码（SQL、配置文件）生成，AI仅完成需求拆解。

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

2. 第二层：确定性执行引擎（无AI参与）
结构化JSON输入内部Task Runner（Python + Jinja2 + SQLGlot），执行以下步骤：

• 根据task_type匹配模板
• SQLGlot对schema进行AST级别diff，自动生成ALTER TABLE或CREATE OR REPLACE VIEW
• Jinja2渲染Airflow DAG、dbt模型、单元测试stub
• 关键点：整个流程不涉及模型推理，仅为确定性转换。CI通过后方可合入。

3. 第三层：人工验证（仅处理例外）
Runner生成的PR自动分配给owner，CI绿灯后直接合并。人工介入仅限两种情况：

• acceptance中明确标注需要人工核对的业务规则（如“金额字段四舍五入逻辑”）
• Runner抛出UNHANDLED_PATTERN，模板库未覆盖新场景（此时手动编写新模板）

曾经的教训与优化实践

• SQL写错风险：直接让LLM生成SQL会在JOIN顺序、分区裁剪等细节上出错。解决方案是SQLGlot+模板组合，确保语法正确。
• 理解与生成分离：将需求解析和文档生成拆分为两次调用，中间加入结构化校验器（如Pydantic）。成本增加微乎其微，但稳定性提升显著。
• 模板管理：将所有Jinja2模板放在独立repo，每次修改走Code Review，Runner启动时拉取指定tag。出现问题时，git bisect定位版本比手动查找Prompt快十倍。
• 工时预估修正：LLM估算的工时通常高估2-3倍。实际排期采用1.5倍系数，结合团队历史完成率进行调整。

实际执行节奏

• 9:30：拉取overnight积压的结构化JSON任务
• 10:00前：Runner完成所有PR创建
• 10:30-11:00：集中处理代码评审
• 剩余时间：处理需人类判断的事项（业务对齐、新模板设计、例外处理）

效果验证
该流程已运行三个冲刺周期，团队人均交付周期从3.2天降至1.4天。关键在于明确交付边界：将AI的优势（理解）与确定性工具的优势（执行）有机结合，避免两者混淆。

适用场景
如果你在处理数据、后端或文档类的重复性工作，不妨先梳理团队的确定性模板而非直接购买企业版工具。模板化才是真正的效率杠杆。