面对一次长任务，先不要急着决定拆还是不拆，而是先把这次任务本身量清楚：把准备提交的内容分成「输入材料」「上下文与约束说明」「期望输出」三段，分别统计字符数和段落数，再看总量主要压在哪一段。压在某一段比较集中，通常优先裁剪那一段；三段都均匀偏大、且期望输出本身包含多个独立交付物时，才考虑拆成多次任务，并设计交接摘要。
一次任务该不该拆分，取决于三段总量的分布，而不是总字数本身。输入材料占大头时先裁剪和摘录，上下文说明占大头时先合并重复约束，只有期望输出跨多个独立交付物时才值得拆。拆分之后，用同一组对照项比对「整段执行」与「拆分执行」的结果，确认结论没有被交接摘要改掉；对照不通过就退回一次提交，或补全交接摘要再试。
把一次任务拆成输入、上下文、输出三段分别计数
把这次要发出去的内容先落成三个文件或三个明确区块，不要混在一段提示里。分别计数时，字符数用 wc -m，段落数按空行切分统计，两者都记下来——同样字符数下段落多，通常意味着约束条数多，拆分和交接时更容易漏项。
# 三个区块各自保存为独立文件后逐个统计
wc -m task_input.md task_context.md task_output.md
# 按空行统计段落数（一段连续文本算一段）
for f in task_input.md task_context.md task_output.md; do
printf "%s\t" "$f"
awk 'BEGIN{RS="";n=0}{n++}END{print n}' "$f"
done把结果填进下面这张表，可裁剪列先凭肉眼判断，后续再按第 2 节的换算复核。
| 段落 | 字符数 | 段落数 | 可裁剪部分 | 裁剪方式 |
|---|---|---|---|---|
| 输入材料 | 待填 | 待填 | 与本次结论无关的背景段落、重复贴过的历史讨论 | 只保留结论相关段落，原文留在本地备查 |
| 上下文与约束 | 待填 | 待填 | 重复表述的格式要求、口头补充的偏好说明 | 合并为一份编号约束清单 |
| 期望输出 | 待填 | 待填 | 顺带想看的附加内容、未确定是否需要的章节 | 移出本次任务，另起一次 |
判断标准很简单：如果某一段占比明显高于另外两段，问题多半不在「任务太长」，而在于这一段没整理。此时拆分只是把未整理的输入分两次扔进去，中段失控的根因还在。
用通用换算方式估算各段规模
字符数不能直接跨中英文比较，需要换算成同一口径再做相对判断。通用经验是：中文大致一个字对应一个词元量级，英文大致四个字符对应一个词元量级，代码、表格、标点和长数字的密度和自然语言不同，换算结果会有偏离。这里只用于三段之间的横向比较和拆分次数估算，不等于任何具体模型的窗口数值；实际可用余量需要结合你所用接口的返回信息和日志确认。
import re, sys
text = open(sys.argv[1], encoding="utf-8").read()
cjk = len(re.findall(r"[\u4e00-\u9fff]", text))
other = len(text) - cjk
# 保守口径：中文按 1 计，其他字符按 4 字符约 1 计
print(f"字符 {len(text)} 中文 {cjk} 其他 {other} 粗估 {cjk + other / 4:.0f}")对三段分别跑一遍，得到三个可比的粗估数字。如果中文比例高、又担心估低，可以把中文系数按 1 到 1.5 之间取一个更保守的值再算一次，看排序是否会翻转——排序不变，说明拆分判断对换算误差不敏感，可以按这个口径继续。
按总量决定拆成几次任务
把三段的粗估数字加起来，结合「期望输出是否只有一个交付物」来定次数，按顺序过下面这份清单，命中即停：
- 三段总量不大、期望输出只有一个交付物：一次提交，不拆。
- 输入材料偏大但结论单一：先按第 1 节的裁剪方式压缩输入，仍一次提交，不拆。
- 期望输出包含多个互不依赖的交付物：按交付物拆，每次任务只带与该交付物相关的输入段落。
- 后一段结论必须依赖前一段结果：拆成「先出结论骨架、再补细节」两次，中间用交接摘要衔接。
- 拆完发现某一次任务的交接摘要本身就接近原输入规模：说明这次拆得不划算，退回一次提交并改为裁剪输入。
交接摘要只保留五类内容，不复制原文：本次任务目标一句话；已确认的约束条目编号；已定稿的片段及其标识；尚未解决的问题列表；输出格式要求。原文段落留在本地文件里，后续任务需要时按标识回查，而不是把整段贴回提示。
| 拆分方案 | 每次任务包含的段落 | 交接摘要保留项 |
|---|---|---|
| 两次：骨架 + 细节 | 第一次全部约束 + 输入摘要；第二次骨架结论 + 对应输入原文 | 目标、约束编号、骨架结论、未决问题 |
| 按交付物拆三次 | 每次单一交付物 + 其依赖的输入段落 | 目标、共用约束、术语与格式约定 |
验证拆分后结果是否一致
拆分是否划算，最终看结果有没有被改变。做法是把同一份任务分别用整段提交和拆分提交各跑一次，把两次输出存成文件，逐项对照下面这些检查项；只对照文字风格没有意义，要对照可判断对错的部分。
- 交付物数量与顺序：拆分执行是否多出或漏掉章节。
- 关键结论与数值：同一问题在两次执行中的取值、判断方向是否一致。
- 约束遵守情况：格式、长度、术语、禁止项是否在拆分后仍然成立。
- 引用位置：拆分执行引用的原文段落，是否与整段执行指向同一处。
- 未决问题清单：拆分执行是否把上一段遗留的问题当成已解决。
对照中只要出现结论方向不一致，先检查交接摘要是否漏了约束条目，再决定补摘要重跑还是退回一次提交。把两次输出的差异记录在任务目录里，下次遇到同类任务可以直接复用这份拆分方案，而不必从零判断。