专治“批量文件敷衍”：Deep Work Agent Pipeline

10.1 不要再下“写 30 个文件”的单次命令

先让 Planner 只负责产出 File Manifest：文件名、目的、读者、必须覆盖的章节、依赖文件、验收标准、预计长度。Manifest 被锁定后，Writer 一次只写一个文件。这样可以把“全局规划”和“局部写作”分离，避免模型边规划边遗忘。

10.2 Context Pack

每个文件开始前自动构建 Context Pack，只放真正需要的信息：项目总目标、相关决策、上游文件摘要、术语表、该文件的 contract。不要每次把全部 20 万字历史塞进去。上下文越相关，模型越有资源用于深入，而不是用于寻找重点。

10.3 Writer → Reviewer → Rewriter

Writer 完成草稿后绝不直接标记 done。Reviewer 使用结构化 Rubric 输出分数、缺陷和具体修改要求。若低于 85 分，Rewriter 必须基于缺陷列表重写，而不是“润色一下”。达到阈值后进入 Consistency Checker。

10.4 跨文件一致性

Consistency Checker 检查术语、API 名称、版本号、角色、目录结构、关键决策是否冲突。它不负责重新写整篇，而是生成冲突清单。冲突回到对应文件 owner 修正。最终再运行 Link Checker / Code Test / Schema Check 等确定性工具。

10.5 状态机

每个文件至少有 TODO → WRITING → REVIEW → REVISION → CONSISTENCY → PASS 六个状态。失败原因写入 log，不能只在对话里说“有问题”。这样 Agent 中断后也能恢复，而且你可以清楚看到到底卡在哪一步。

10.6 深度预算

对于重要文件，为每一章节设置 minimum coverage，例如 PRD 的“用户问题”“系统边界”“验收指标”分别需要实质内容。不要用“至少 5000 字”作为唯一标准，因为模型可以用废话凑字。应组合：章节覆盖 + 证据 + 决策理由 + 示例 + 风险。

本课最小代码 / 结构

file_id: PRD-001
status: REVIEW
contract:
  purpose: 定义产品闭环和边界
  required_sections:
    - problem
    - users
    - workflow
    - architecture
    - acceptance
quality_gate:
  pass_score: 85
  max_revisions: 3