分工的判据只有一条：这一步有没有唯一正确答案。有，交给脚本；没有，交给模型。 全给模型的代价不是做不对，是你没法验证它对不对。全给脚本的代价是判断类的步骤写不成 if。 这一篇拿一个完整的分析任务，把十二步拆开分工，脚本那几步真跑一遍。
上一篇定了「做不做」，这一篇定「谁来做」。这是写技能正文时最实际的一个决定。 分工错了，技能会变成两种东西之一：一个包着代码的自然语言壳，或者一个假装能思考的脚本。 第 5 章搭工作流、第 7 章的三版迭代，都建立在这条分界线上。
一、为什么不能全文给模型
先说清楚「全文给模型」是什么意思：把数据、要求、判断全塞进提示词，让它一次做完。 这么做的第一个问题不是质量，是验证。 它给的每个数，你都想去核一遍。核一遍的时间，往往比自己做还长。 第二个问题是不稳。同一份数据问两次，可能得到两个略微不同的数字。 因为它在「生成」数字，不是在「计算」数字。这两件事在机制上就不一样。 所以数据一多、要求一复杂，全文给模型就开始不可靠——不是它能力不够，是路径不对。
二、完整案例：出数据分析报告怎么分工
拿一个具体任务走一遍：「给一份销售 CSV，出一份带结论的分析报告」。 拆成十二步，逐步判断交给谁。 读 CSV、校验列名、分组求和、算环比、找跌幅最大的月份——这五步都有唯一答案，脚本。 判断这个跌幅算不算异常、想一句能说人话的解释、决定报告先说哪一条——这三步没有唯一答案，模型。 画趋势图——严格说也算脚本，因为它是确定性的渲染。 写结论、检查数字有没有抄错、定稿措辞——前两个是模型加脚本，最后一个是模型。 分完之后地很清楚：算的归算，说的归说。 「检查数字有没有抄错」这一步值得单独说：它必须在脚本里做，不能靠模型自查。 因为模型自查的时候，用的是同一套可能出错的判断。
三、提示词、技能、脚本
分完工，还要分清这三样东西各自管什么。它们经常被混在一起说。 提示词管这一次：这次要什么、给谁看、多长。它随对话结束消失。 技能管这一类：这类活按什么顺序做、什么情况怎么办、什么不许做。它存在文件里。 脚本管这一步：给定输入，算出确定的结果。它是代码，跑出来是什么就是什么。 三者的关系是嵌套：技能里可以点名调用脚本，脚本里不该反过来去「问模型」。 一个常见的错误是在脚本里调模型接口做判断——这样脚本就不确定了，既不能重跑也不能对比， 等于把两样东西的优点都丢了。 正确的方向只有一个：脚本做确定的事，模型做判断的事，技能把它们按顺序串起来。
四、一条能当场用的判据
遇到一个步骤拿不准交给谁，问自己一句话：这一步有没有唯一正确答案？ 有唯一答案的：求和、计数、排序、格式化、校验、比对、过滤。全部交给脚本。 没有唯一答案的：判断轻重、解释原因、拟措辞、决定先说什么。全部交给模型。 灰色地带也有，比如「找异常点」——如果异常的定义写死了（超过三倍标准差），那是脚本； 如果异常要靠人看上下文判断，那是模型。判据不在步骤本身，在判据有没有写死。 所以遇到灰色地带，先问的不是「交给谁」，是「我能不能把判据写死」。 能写死，就变成脚本；写不死，就交给模型，并且接受它每次可能不一样。
五、动手 Demo：同一个分析任务，三种分工算一遍
这一段把「出分析报告」拆成十二步，逐步标上脚本还是模型，然后真跑脚本那几步。 数据是真的：六个月的销售记录，两个品类。环比、最大跌幅都由脚本算出来。
# 脚本那几步，二十行搞定，零 token
rows = list(csv.DictReader(open('data/sales.csv', encoding='utf-8')))
tot = {}
for r in rows:
tot.setdefault(r['品类'], {})[r['月份']] = int(r['金额'])
for a, b in zip(ms, ms[1:]):
chg = (phone[b] - phone[a]) * 100.0 / phone[a] # 环比
实跑输出：
--------------------------------------------------------------------
同一个分析任务，三种分工算一遍
--------------------------------------------------------------------
① 先把任务拆成十二步
--------------------------------------------------------------------
| 步 | 动作 | 交给谁 |
|:---:|---|:---:|
| 1 | 读 CSV | 脚本 |
| 2 | 校验列名与行数 | 脚本 |
| 3 | 按品类分组求和 | 脚本 |
| 4 | 算环比 | 脚本 |
| 5 | 找环比跌幅最大的月份 | 脚本 |
| 6 | 判断这个跌幅算不算异常 | 模型 |
| 7 | 想一句能说人话的解释 | 模型 |
| 8 | 决定报告先说哪一条 | 模型 |
| 9 | 画趋势图 | 脚本 |
| 10 | 写三句话的结论 | 模型 |
| 11 | 检查数字有没有抄错 | 脚本 |
| 12 | 定稿措辞 | 模型 |
十二步里，脚本 7 步、模型 5 步。
分界线很清楚：有唯一答案的交给脚本，要判断的交给模型。
② 脚本那几步，真跑一遍
--------------------------------------------------------------------
| 品类 | 月份数 | 合计 |
|---|---:|---:|
| 手机 | 6 | 776000 |
| 配件 | 6 | 212000 |
读文件、分组、求和——这三步全是脚本，十几行代码，零 token。
③ 环比：脚本算出来的东西长什么样
--------------------------------------------------------------------
| 月份 | 上月 | 本月 | 环比 |
|---:|---:|---:|---:|
| 2026-02 | 120000 | 98000 | -18.3% |
| 2026-03 | 98000 | 156000 | +59.2% |
| 2026-04 | 156000 | 88000 | -43.6% |
| 2026-05 | 88000 | 143000 | +62.5% |
| 2026-06 | 143000 | 171000 | +19.6% |
跌幅最大的是 2026-04，-43.6%。这个数是算出来的，不是看出来的。
! 如果让模型「看一遍表格找最大跌幅」，它多半找得对，但你会想验一遍。
! 脚本算完直接给结论，你不需要验——这就是分工的价值。
④ 模型那几步，问题在于没有唯一答案
--------------------------------------------------------------------
「判断这个跌幅算不算异常」——多少算异常？跌 10% 还是 20%？要看行业。
「想一句能说人话的解释」——没有标准答案，只有好与不好。
「定稿措辞」——同上。
模型那五步里最典型的是这三个，共同点是：评分标准是人定的，不是算出来的。
所以它们交给模型，但最终要人来点头。
⑤ 三种分工的代价
--------------------------------------------------------------------
| 分工 | 步数 | 可行性 | 问题 |
|---|---|---|---|
| 全给模型 | 12 | 不可靠 | 数要它自己数，结论要它自己验 |
| 全给脚本 | 0 | 做不完 | 「判断异不异常」写不成 if |
| 按上面的分工 | 7 脚本 / 5 模型 | 可行 | 算的归算，说的归说 |
全给模型的问题不是它做不对，是你没法验证它对不对——
它给的每个数你都想去核一遍，核的时间比自己做还长。
全给脚本的问题更直接：判断类的步骤写不成条件分支。
! 分工的判据只有一条：这一步有没有唯一正确答案。
第一张表是十二步的分工：脚本 7 步、模型 5 步。 分界线在「有没有唯一答案」：求和、环比、找最大值都有，判断异常、拟措辞都没有。 第二段真跑了脚本那几步：两个品类各六个月，手机 776000、配件 212000。 第三段是环比表，跌幅最大的是 2026-04，-43.6%。这个数是算出来的，不是看出来的。 如果让模型「看一遍表格找最大跌幅」，它多半找得对，但你会想验一遍。 脚本算完直接给结论，你不需要验——这就是分工真正的价值，不在准确率，在可验证性。 第四段列出模型那几步，共同点是评分标准由人定，不是算出来的。 第五段比三种分工：全给模型不可靠，全给脚本做不完，按分工才可行。
30 秒实验
- 把你现在这个技能拆开，每一步标上「有唯一答案」或「没有」。标完你就知道该不该写脚本了。
- 找出你技能里「模型自己算的数」，改成脚本。这一条通常能立刻消掉一类错误。
- 检查你的脚本里有没有反过来去调模型做判断。有的话，那块该挪到技能正文里。
常见误区
- 让模型自己数数。 「数一下有多少条 ERROR」这种活交给模型，它会给一个数，但你永远不确定准不准。三行脚本的事。
- 在脚本里调模型做判断。 这样脚本就不确定了，既不能重跑也不能对比，把脚本和模型两边的优点都丢了。
- 以为分工是一次性的。任务变了，分界线也会变。 同一个步骤，判据能写死就是脚本，写不死就是模型——判据变了，归属就该跟着变。
自测三问（点开对答案）
1. 分工的判据是什么？ —— 这一步有没有唯一正确答案。有就交给脚本，没有就交给模型。 2. 全给模型最大的问题是什么？ —— 不是做不对，是你没法验证它对不对。核一遍的时间往往比自己做还长。 3. 看待灰色地带（比如「找异常点」）该问什么？ —— 先问「我能不能把判据写死」。能写死就变脚本，写不死就交给模型并接受不确定性。下一篇往外看一层：选手头的工具之前，先看看机器上已经装了什么，别急着装库。
- ☐ （本篇完，下一篇 3.4 选什么工具干活）