脚本与大模型分工
在 AI 知识加工流水线里划清一条边界：确定性的重复劳动（读取、生成、格式化、迁移）固化进脚本，语义理解和知识推理交给大模型，把人的精力留给关键结果的最终决断。
简介
脚本与大模型分工是 @Sean 在《3 个脚本、4 个 Skill、3 层防线》中反复强调的工程原则。它回答的问题是：一条 AI 知识加工流水线里，什么该写成确定性代码，什么该调用大模型，什么必须留给人？作者的答案是一句话——“让脚本程序处理不需要人来介入的重复劳动，让大模型来负责语义理解和知识推理，把人的精力留给关键结果的最终决断上。”
这条边界不是理论推导出来的，而是踩坑后形成的习惯。作者写第一个脚本 batch_ai_process.js 时就意识到”预处理脚本里不是所有环节都适合交给大模型”：脚本擅长的是”按固定规则把结果框在一个标准框架里”，不擅长”替你理解知识”。所以脚本里只把”总结提炼文章要点”这一步交给大模型，且要求不发散、不延伸，其余读取原文、生成文件、格式化、迁移文件等确定性步骤全部固化在代码里。
关键信息
- 类型：AI 协作分工原则 / 流水线设计方法
- 三方角色：脚本（确定性劳动）、大模型（语义理解）、人（最终决断）
- 划界依据：成本（token 消耗）+ 能力边界（“文章的理解” vs “我的理解”）
- 脚本职责三收敛：压缩噪声、统一格式、降低后续讨论门槛
- 相关概念：目录即状态、准入准出条件、Skill、Harness闭环工程、知识库构建工程
核心特性
1. 为什么不把深度理解也交给大模型：成本 + 能力边界
作者给出两条理由：
- 成本：大模型每次调用都消耗 token。如果让它做深度理解，十篇文章的处理成本会翻好几倍。批处理阶段用 DeepSeek V4 Pro 做提炼总结”完全够用，关键是性价比极高”——它只需要把噪声压掉、格式统一，不需要昂贵的深度推理。
- 能力边界：大模型提炼的知识点是”文章的理解”，不是”我的理解”。一篇讲 AI PM 能力迁移的文章，大模型可以列出五个核心观点，但这五个观点和我有什么关系？在我的业务里哪些成立、哪些不成立？这些问题需要领域知识、个人经验和判断力，不是调一次 API 就能回答的。
因此深度理解这件事被刻意留在流水线后段的人机深度讨论（见 Skill 里的 deep-discuss）里，而不是塞进批处理脚本。
2. 脚本职责的三收敛：压缩噪声、统一格式、降低门槛
脚本在这套系统里只干三件事：
- 压缩噪声：把几千上万字的原文提炼成结构化笔记（摘要、关键知识点、对 PM 的启发、金句摘录）
- 统一格式：让所有笔记进入同一个标准框架，便于后续校验和讨论
- 降低后续讨论的门槛：把原文变成”可以讨论的对象”，人不必再从长文里捞重点
理解的事，留给后面的人工 + AI 深度讨论。“脚本的工作是让大模型按规矩交作业，不是替你思考。“这条界限想清楚之后，才有了后续把深度讨论蒸馏成 Skill 的动作——因为深度讨论本来就不是脚本该干的活。
3. 大模型要”关进笼子”：不发散、不延伸
即便调用大模型，也要给它戴上约束。脚本里交给大模型的那一步明确要求”不做发散，不延伸”——只提炼要点，不自由发挥。这与后文的三层护栏（validate_notes / batch_fix_notes）和 准入准出条件 是同一种思路：大模型能力越强，越需要用结构把它的输出框在标准框架里，否则”大概处理 8 次就有 1 篇会出现’好的，我作为资深产品知识分析专家’的 AI 式回复”。
4. 三方分工的收益：确定性、成本、判断力各归其位
把三方角色对齐到各自最擅长的事，整条流水线才稳：
| 角色 | 擅长 | 在流水线里负责 |
|---|---|---|
| 脚本 | 确定性、可重复、零成本 | 读取/生成/格式化/迁移/校验/修复 |
| 大模型 | 语义理解、模式提炼 | 把长文压成结构化要点（受约束、不发散） |
| 人 | 领域判断、经验迁移、价值决断 | 深度讨论、产卡、最终决断 |
不同素材中的观点
-
2026-07-11-woshipm-knowledge-base-engineering-practice：@Sean 把这条分工原则作为整套知识库设计的底层习惯。核心判断是脚本擅长”按固定规则把结果框在标准框架里”、不擅长”替你理解知识”，所以只把提炼总结这一步交给大模型且不许发散，其余确定性步骤固化进代码；深度理解因为成本高、且是”文章的理解”而非”我的理解”，被留给人机深度讨论。三句话概括这套原则：“让脚本处理重复劳动、让大模型负责语义理解、把人的精力留给最终决断""脚本的工作是让大模型按规矩交作业，不是替你思考”。
-
2026-05-28-woshipm-llm-wiki-qmd-architecture：秋孝隱那篇把类似分工体现在架构层——qmd/CLI（脚本层）只负责”帮 LLM 找到该看的东西”，不负责理解知识或设计结构；LLM 层负责执行 ingest/query；lint 只抓结构问题不判断内容真伪（“内容判断需要来源、证据和人的判断，不要交给 LLM 自己凭感觉看”）。两篇在”确定性劳动归脚本、语义判断归模型、价值判断归人”上完全一致。
实用信息
落地判断清单
给流水线里每一个环节问三个问题：
- 这步能不能用固定规则完成？ 能 → 写脚本（读取、迁移、格式化、字段校验）
- 这步需要语义理解但不需要个人判断？ 是 → 调大模型，但加约束（不发散、限定输出格式）
- 这步涉及”和我有什么关系、我信不信、我要不要用”？ 是 → 留给人（深度讨论、产卡、决断）
注意事项
- 不要图省事把确定性步骤（迁移、格式化）也交给大模型——既贵又不稳定
- 调用大模型时一定要约束”不发散、不延伸”，否则输出会漂出标准框架
- 大模型的产出是”文章的理解”，不能直接当成”你的判断”归档，必须经过人的讨论校准
- 脚本的输出质量仍需校验兜底（见 Harness闭环工程 的三层防线思路）