AI 提效为什么总卡在验收一条施工-验收闭环的五个控制点AI 生成速度已经不成问题真正卡住交付的是验收。这不是个人感觉有行业数据MIT 一项覆盖十万多名 GitHub 开发者的研究发现自主编程 Agent 能让代码提交量增加 120%但这些代码立项时缩水到 50%真正发布上线的只剩 30%。生成端快了 2 倍多验收端把成果砍掉了七成。经济学里有个替代理论流程的效率由流程中不可被自动化替代的那部分决定。AI 把生成速度拉满人的审查、验收、拍板还在原地系统就被卡住了。下面这套施工-验收闭环是我在文档格式自动化这个真实交付场景里跑出来的解法。它跑过真实交付也跑过返工。五个控制点上下文、成本、质量门、节点错误率、安全边界一、把改文档当成工地施工我做的场景论文格式自动化——目录页码、三线表线宽、黑体混排、交叉引用交付标准是第三方检测脚本。人工改一篇 2-4 小时肉眼漏检客户侧检测一跑就现形。一开始是一个人 一个对话框改完自己看。结果是生成 100 倍提速验收原地踏步。后来我换了个思路不当用 AI 干活当管一个工地。整个流程拆成角色施工方多 Agent 执行多个新窗口并行改每窗口限 3 篇。总工编排拆任务、定范围、写交接单。监理 甲方验收验证双层脚本 金标准回归。一条工作链[客户需求] → [施工方·多Agent] → [总工·交接单] → [监理·双层验证] → [甲方·金标准回归]↑ │错误写回·规则库 diff0 才放行│ │└──── 返工 ←───────┘关键不是AI 有多强是这条链能不能一直转下去。下面五个控制点决定它转得稳不稳。二、上下文第一性原理级的敌人LLM 没有记忆上下文窗口是每次调用重新喂进去的内容。对话越长三个退化机制越明显1.信息被稀释早期内容被后续内容冲淡模型对前置要求的遵从度下降——已有研究把这种现象称为 lost in the middle。2.一致性下降长序列里模型自我矛盾的概率上升同一个约束前面执行、后面遗忘。3.错误自我强化前文一旦出现错误表述后续会顺着错下去而且错得越来越自信。这不是模型不够好的临时问题是架构特性。所以对抗手段全是工程化不是提示词——这个概念在行业里叫上下文工程Context Engineering隔离每个执行窗口限 3 篇到量就开新窗口。宁可重新加载文件也不让上下文长到失控。外部记忆交接单、规则库、金标准文件都是记忆的仓库。模型会忘仓库不会。每轮改了哪几段、改了什么写进交接单复查时按单定位不做全量重查。节点控制把流程画成节点链每个节点一个布尔判定——过放行到下一节点不过切断路径回退。错误在源头被拦不往下游扩散。三、成本控制token 是执行链的燃料一次交付被拆成可计量的单元工时、token、返工次数。三个数字是这条链的仪表盘工时单篇从 2-4 小时压到约 70 分钟token单篇约 12-20实际计费返工多数一次过个别返工后过。成本控制的核心不是省 token是让单位预算内的验证次数变多。行业证据也在往这个方向走哈工大提出有效反馈算力——复杂任务里花出去的算力中真正影响下一步的只有约 10%剩下 90% 耗在重读、试错和无效往返上。Anthropic 也披露过多 Agent 研究系统的 token 消耗可达普通 Agent 的四倍。所以两个具体决策1. 交接单定位复查替代全量重查——复查成本差一个数量级砍掉的正是那 90% 的无效往返。2. 限 3 篇、到量开新窗——不只是防上下文错乱也是把多 Agent 的 token 消耗按回去。行业教训Uber 的 Claude Code 预算一个季度烧穿说明不设上限的 Agent 投入产出并不随 token 线性增长。3. 定价里写死质量风险查验不过扣款、再不过免费返工。表面是让利实质是把过不了的成本前置到自己身上倒逼质量门在交付前收紧。代价也有新窗口要重新加载文件这部分时间没有省掉验证本身也花钱所以验证成本要量化这条是后期补的不是一开始就设计好的。四、质量门不是检查是分级 可回归质量门不是改完自己看一遍是三个层次1.结构层验证直接解析 docx 的 OOXML检查目录、样式、引用域、三线表线宽、页脚值。结构层能查出人眼看不出的问题——比如 OOXML 里 w:rPr 必须放在 run 的第一个子元素放错了 Word 会静默丢弃上标直接消失。2.渲染层验证导出 PDF 再扫一遍。改对了 docx 不代表 PDF 对——有一次表线宽在 docx 里已修正导出 PDF 却还是旧值靠渲染层复扫才抓出来。3.金标准回归拿已通过的成品当基准结构 diff0 才算过。我觉得对了不算数diff0才算数。质量门还有分级基础项字体、页脚、线宽这类硬指标和内容项分开判定基础项未达标单独排返工避免混在一起扯皮。这对应到研发里就是 CI 的质量门禁基础项不过流水线直接红不往下走。质量门也有盲区PDF 渲染层、混排黑体、引用上标这些项脚本不能全覆盖最终靠金标准人工兜底。而且**脚本本身也要被验证**——有一次段号错位 88 段根因是脚本与 Word 的段落计数口径不一致后来补了规则。五、节点控制与错误率错误不跨节点错误率不是靠小心压下来的是靠结构错误写回检测盲区登记成规则从 R1 攒到 R17。每翻一次车规则库多一条下次被拦的概率高一点。这就是行业里说的反馈回路——AI 能持续运行的前提是每一次错误都能写回下一次执行。节点闸门关键路径上设布尔检查点过放行不过切断回退。错误不流到下一节点——因为下游扩散的成本是指数级的。对应到工程上就是流程状态机每个节点一个判活条件不满足就终止这条路径。数字诚实7 篇通过2 篇返工后过1 篇返工中。规则库的边际收益递减但真实。教训两条错误写回是滞后发生的R17 规则在方法论第 18 轮才补登记说明初期是边交付边补验证工具的自身错误也要有机制发现。六、安全边界决策权留在人手里边界不是限制是保护。四个边界1. 可行性门接单前先算钱、时间、能力、风险。过不了不接——这是翻车后补的。2.授权边界凡是变更必过总查涉及内容级变更如引用率必须人来裁定。AI 可以建议人才能拍板。3.信任边界单一模型会自我肯定。同一个活多模型交叉验证——不是信谁说得对是信验证过的结果。4.红线押金、会员费、灰单一律不碰。这些不写进流程写进习惯。行业里管这个叫 Human-in-the-loop 和 guardrail。听上去很高级本质就一句话AI 扩大执行并提供验证证据人决定解决什么问题并对结果负责。七、这套系统的边界它不解决所有问题上下文只能缓解不能根治新窗口失忆重读文件的时间没省掉。只适用于可量化验收的标准化场景创意类、主观判断强的活直接失效。规则沉淀是事后补的不是设计出来的。并行受资源限制一个窗口限 3 篇不能无限堆。这些限制不构成退回旧流程的理由——人工流程同样漏检且没有沉淀机制。但它们划定了适用范围**标准越死收益越大标准越活越不划算。**八、没实践的部分当探索点说上面写的都是我跑过的。没跑过的我当探索点列出来企业级多 Agent 编排团队规模下TL 多个子 Agent 按 Wave 并行调度这种架构我只在个人场景跑过 3-4 个窗口并行没在团队规模验证过。子 Agent 拆分、派发、回收的工程细节是我没碰过的领域。按调用链路拆 token 成本我只记了单篇总量12-20没拆到工具调用粒度。像 AgentLens 那样按 TraceId 追到单次调用、按 Wave 聚合消耗分布是探索点。部署进客户业务系统这套链目前跑在文档交付场景还没真正嵌进一家企业的业务系统、沉淀成对方团队能用的 SOP。这是最想验证、也最没底的一块。并行资源优先级同一台机器多文件并行会不会互相拖慢、谁该排队只凭直觉限了 3 篇没有压测数据。这些问题的共同点它们需要更大的场景、更多的钱、更长的周期才能验证。我现在的阶段先做到分得清我跑过和我听说再谈扩展。九、人的责任没有消失AI 干执行人做三件事定标准、验收拍板、承担结果。AI 提高的是执行纯度不取消人的责任。Q2 的趋势报告结尾有句话说得比我准机器可以快速交答案人还得判断题目值不值得做、答案会带来什么后果并且为它负责。方法论成立的条件是验收标准可量化满足就自动化不满足就保持人工。谁先把意图-生成-验证连成循环谁就能在投入扩大之前早停。这不依赖天才依赖流程。—— 个人实践仅供参考。