outsource

name	outsource
description	面对机械/验证/探索类体力活——编译构建、跑测试、查/采数据、看日志、解析依赖或版本或符号(FQN)、环境与连通性探测、批量重复操作等，任意技术栈不限 Java——时，不在主线 session 亲自执行，而是产出一份「自包含的委派提示词（内嵌报告格式）」，交用户转派给低配模型 session 去跑，再消费其回传报告。目的：省主线（贵模型）token，让主线专注架构/决策/写代码。触发词：外包、委派、验证、构建、编译、跑一下、查一下、看日志、采集数据、探测、解析依赖、查版本、查FQN、派给别的session、省token、生成提示词、报告模板。

Outsource · 外包

把机械/验证/探索类体力活从主线 session 外包出去：主线只定义任务——产出一份自包含的委派提示词（五段式，"产出"段内嵌报告格式），由用户一次性转派给低配模型 session 执行、按格式回传，主线消费。主线不自己跑这些命令。

为什么这么做（图什么）

外包不只是省钱，三层收益从轻到重：

1. 省 token：机械活的输出又贵又没营养——一次 mvn 失败几百行堆栈、jar tf 上千行、javap 几十个签名。在主线跑就按贵模型单价烧这些噪音；外包后低配 session 趟泥潭，主线只收一张几十行的结构化报告。
2. 保上下文（比省钱更值钱）：主线上下文窗口是稀缺资源，装着架构决策、迁移方案、用户偏好、已写代码。机械命令的海量原始输出会把这些判断材料挤出窗口、提前触发 compact、让记忆失真。外包让噪音根本不进主线，上下文始终高信噪比。token 烧完能充，被噪音挤掉的架构判断充不回来。
3. 角色分离、各自最优（最本质）：写代码/定架构要强模型 + 全局上下文；跑命令/查符号/grep 日志要的是"听话照做 + 如实回报"，弱模型更便宜也够用。强行让主线干体力活＝拿律师时薪去复印文件。五段式 + 内嵌报告格式则负责让便宜那端也可靠（堵住瞎编 FQN、概括掉证据、卡点反复重试等通病）。

核心原则

• 主线（贵模型）只做：架构、决策、写代码、读少量文件做判断、定义委派提示词。
• 机械活外包：凡"跑一下/查一下/验证一下/采一下"，产出委派提示词，不自己调 Bash/工具去跑。
• 产出 = 一份五段式委派提示词：① 角色（定位成「<领域>专家」+ 直接交代「本次任务：…」，不写"你是助手/替谁干活"）② 背景（路径·栈·版本·意图）③ 步骤（精确命令 + 每步「目的」+ 替代项）④ 铁律（只读·逐字原文·查不到说查不到·不确定标注·只报事实不下结论·卡点如实报）⑤ 产出（报告格式内嵌于此，措辞"你按下面格式回传"）。
• 报告格式必须嵌在提示词里，让用户一次输入，别拆成两段让用户二次拼接。

何时用 / 不用

用（外包）：编译构建、跑测试、依赖/版本/符号(FQN)解析、查数据库/接口/文件、日志与报错排查、环境/网络/连通性探测、格式转换、批量重复操作……任意栈。

不用（仍主线做）：写代码本身、读少量文件做架构判断、方案/接口设计、需上下文权衡的决策、对外不可逆的副作用操作（主线把关或问用户）。

工作流

1. 判断：这是机械/验证/探索活吗？是 → 走外包；否（写代码/决策）→ 主线自己做。
2. 产出委派提示词（五段式骨架见 references/templates.md；按场景现成模板见 references/scenarios/，目录见 references/scenarios/index.md）。报告格式嵌在"产出"段。
3. 定档 + 让用户拍板跑法：先按规模定档（档 0 主线自己干、不外包）；档 1/2 产出提示词后，给出建议并让用户在 subagent / 新 session 间选（除非用户已设长期默认）。见「执行模式」。
4. 消费报告：PASS → 继续；FAIL/缺口 → 据证据自己修，信息不足再派一轮（迭代委派，别下场自己跑）；报告可疑/自相矛盾 → 让其补证据再判，别全盘采信结论化表述。

执行模式（三档梯子 + 每次由用户拍板跑法）

先按规模定档，再让用户选具体跑法。

档 0 · 极小且干净 → 主线 inline 自己干，不进委派流程 读一个短文件、取一个值、一条输出几行的命令。派 subagent 也有冷启动+推理开销，一条 javap 不够它热身的——主线顺手做掉。

档 1 · 小到中、机械、会刷屏或要几步 → 委派（建议默认 subagent） 解析几个 FQN、一串 javap、跑个单测。零判断、纯机械，是廉价模型最稳的甜区。

档 2 · 大/重复/会冲爆窗口，或带判断、要人工把关、要独立计费 → 委派（建议默认新 session 手动） 整串依赖解析、翻大 jar 几十个符号、grep 几万行日志。报告大或风险高时留人在环。

两种跑法（档 1/2 才涉及）

• B · subagent 自动跑：主线用 Agent 工具派低配模型（如 haiku）subagent 执行委派提示词、收回报告，零人工来回。噪音留在 subagent 自己的上下文，只有报告回主线。
  • 前提（必须先校验）：Agent 工具可用 / 系统列出了可用 agent 类型。不支持就退回 A，别假装能派。
  • 务必指定低配模型，把整份委派提示词（含产出段）塞进任务；仍守铁律：只读/不改文件（除非任务本就是改文件且用户同意）、卡点不硬重试。
• A · 新 session 手动转派：用户拿委派提示词去另一个低配 session 一次粘贴运行、再贴回报告。适合：要用独立计费的便宜额度、想人工把关每步、环境不支持 subagent。

拍板规则（重要）

• 每次都由用户在 A / B 之间选。AI 按上面的档给出合理建议（哪档建议哪种），但不替用户定——产出提示词后停下来问"这次走 subagent 还是新 session？"。
• 唯一例外：用户明确说过"以后默认都用新 session"（或"以后都用 subagent"）这类长期默认，之后才不再每次问、直接按其设定跑。
• 让用户知情计费差异：subagent 花同一账号额度（按 haiku 价、省的是噪音 token），新 session 可走独立的便宜额度（省的是主账号额度）。
• 档 0 不在此列——极小活主线直接干，不问。

新增自定义场景（按需扩展模板库）

当用户要的场景库里没有时，主线走作者流程自助扩展，而不是临时拼一个（拼的不沉淀、下次还得重来）：

1. 收原始诉求：用户用一两句话说这个场景要干嘛。
2. 产澄清问题让用户填：生成一份填空式清单，问清工作流每步 + 护栏 + 报告要回什么 + 常见卡点（完整问题集与作者步骤见 references/authoring.md）。能合理推断的给默认值、只问拿不准的，别滥问。
3. 落盘：据用户答案新建 references/scenarios/<场景名>.md（适用 + 一段委派提示词，提示词内嵌产出/报告格式），并在 references/scenarios/index.md 登记一行。

触发：用户说"加个场景 / 这类活也归进来 / 自定义模板 / 新建一个 xxx 场景"等。

反模式

• 主线亲自跑 mvn / grep / curl / 查表 这些机械命令。
• 把档 0 的极小活也包装成委派（杀鸡用牛刀），或不问用户就擅自派 subagent / 替用户选跑法。
• 提示词依赖目标 session "记得"上下文——它没有记忆，写漏即盲跑。
• 角色写成"你是助手 / 替某某干活"，而不是"你是<领域>专家、本次任务是…"。
• 报告格式不嵌进提示词（拆成两段让用户二次拼接）。
• 报告无证据、结论埋在长文里。
• 放任目标 session 改文件 / 反复重试卡点 / 顺手扩大范围。

📎 五段式提示词骨架与检查清单 → references/templates.md；按场景现成模板 → references/scenarios/（目录 index.md）；新增场景作者流程 → references/authoring.md