九维度决策的完整拆解：五类 agent 跑分表 + 反向校验 + 五段 brief 模板（付费层首篇）

D4 是「九维度五类 type 的目录」——四十五个跑分点 + 三步选型流程，五段真实项目复盘。 P1 是「全本」——九维度逐维拆解（每维四百字）+ 一份 Excel 跑分表 + 五段 brief 模板 + 七个 cron 自检脚本。

区别：D4 给你看「为什么这五个项目选错了」，P1 给你直接抄走就能用的工具。

这一篇是付费层首篇。免费层给「是什么」，付费层给「怎么做」——这是 14 个月账本压出来的承诺。

为什么 D4 不够用

D4 摆出来的四十五个跑分点是真的，但打分的依据没说清。

举个真实的——我接到「把三十章细纲拆成一百章节目标」这个活，按 D1 的五个信号打分：

• 目标清晰 ✓
• 边界明确 ✓
• 结果可量化 ✓
• 不需要中途决策 ✓
• 时间可预估 ✓

五个全勾，结论「选 Commander」。我跑了。

跑出来：100 章细纲像流水线，章节之间没有弧光——主角从头到尾是同一个人。

为什么选错了？

因为 D1 的五个信号是二元判断（是 / 否），但工程活经常是灰度。这活其实是「60% 指挥 + 40% 共生」——边界明确（60%），但需要在拆细纲时让 Mavis 反问「人物弧光」（40% 共生）。

D4 给了九维度五类 type 的跑分，但维度本身没拆。我打「可逆性」3 分、「不确定性」4 分，凭直觉——不同人打出来能差 2 分。

P1 解决这个：九维度逐维拆解 + 反向校验五招，让你打分的依据可复述、可校验。

---

九维度 · 逐一拆解

每个维度 1 个定义 + 1 个反例 + 1 条边界 + 1 段真实账本。读完你能复述每个维度的判断标准。

维度 ① · 预算（token / 钱 / 时间）

定义：这个活愿意花多少资源？token 计量、人民币计量、还是按”人天”算都行——关键是预算可量化。

反例：用户说”你看着办”——这不叫预算，这叫”无限预算”。无限预算 = 无预算，因为没有上限就没有决策依据。

边界：预算低于”这个活最小可行产出的资源” → 跑不动。预算高于”做一个能交付的好活” → 浪费。

真实账本：怪招本改版三次，每次预算定在五千到八千 token。改版一（v1）超出 1.2 倍，原因是没提前列资源清单；改版二（v2）卡在 95%——刚好够；改版三（v3）控在 80%，节省下来的 20% 留给发布后的 SEO 体检。

维度 ② · 时长（一次会话能不能跑完）

定义：从接到 brief 到交付，活能不能在一个会话窗口（一两个小时内）跑完？超过就跑接力。

反例：用户说”这个活不急”——这不叫”时长长”，这叫”无 deadline”。

边界：单会话超过两小时 → 必须接力 → 接力就要 Supervisor 接手。

真实账本：番茄投稿 4 章 1.2 万字，单会话 90 分钟能跑完；超过 4 章就跑不动——必须分会话接力，超 90 分钟就出现 Mavis “失忆”（忘前面的人物设定）。

维度 ③ · 上下文（活需要的背景信息量）

定义：这个活需要 Mavis 知道多少前置信息？人物设定、历史项目、风格规范、外部数据——量化成”千字”。

反例：用户说”按之前那个风格写”——“之前”是哪次？哪篇？什么风格？

边界：上下文超过两万字 → 跑不动。这是 LLM 的物理极限（两百 K 上下文的窗口，你塞二十万字 prompt 就只剩一点回旋空间）。

真实账本：妖管局 100 章细纲 = 三万四千字——必须分章节加载，不能一次塞。接力的「中继」维度会用到这个数字。

维度 ④ · 可逆性（错了能撤回吗）

定义：这个活跑砸了，能不能回滚？能不能局部改？能不能重来？

反例：用户说”试试看”——但”试试”如果是发到生产环境的发版，“试试”就回不来。

边界：不可逆的活 → 强制 Co-thinker 介入，每步确认。

真实账本：改版怪招本 v3，UI 重做——改错了最多 git revert，五分钟回滚；上线番茄投稿——发出去就改不回，必须 Co-thinker 介入。

维度 ⑤ · 不确定性（活有多少未知数）

定义：brief 给完，还有多少未知？百分之多少是确定的？用百分数。

反例：用户给”做一个 AI 智能体博客”——这是 5% 确定。给”做一个像怪招本那样的暗色 editorial 风格 AI 智能体博客”——这是 60% 确定。

边界：不确定性 < 30% → 选 Commander；30%-70% → 选 Co-thinker；> 70% → 先做一轮探索再决定。

真实账本：M3 「什么时候不该用 agent」那篇的不确定性是 75%——我跑 Co-thinker 跑出 5 轮反问才收住。

维度 ⑥ · 中继（要不要多 type 接力）

定义：这个活能不能单 type 跑完？还是要五类 type 接力？接力节点怎么切？

反例：用户说”这个活很复杂”——“复杂”是模糊词。要量化：接力节点有几个？每个节点的 type 是什么？

边界：接力节点 > 3 个 → 必须 Supervisor 全程；接力节点 ≤ 3 → 可以 Co-thinker 兼任。

真实账本：M1 五阶段接力 = 五个节点（Supervisor 启动 → Conversationalist 收口 → Co-thinker 三段 → Supervisor 收口 → Trainer 收口）——Supervisor 全程。

维度 ⑦ · 监督（要人盯多紧）

定义：这个活要不要人盯？盯的频率？每步确认？只盯结果？

反例：用户说”你跑跑看，跑完告诉我”——这是”零监督”，但大多数活不是零监督，是”中等监督”。

边界：高监督 = 每步要人确认 → Conversationalist；中监督 = 看关键节点 → Co-thinker；低监督 = 只看结果 → Commander。

真实账本：番茄投稿章节是”中监督”——我每章末看一眼，不每句都看。

维度 ⑧ · 出错（跑砸的代价多大）

定义：活跑砸了，最坏后果是什么？丢钱？丢时间？丢信任？丢生产环境？

反例：用户说”砸了就砸了”——这要么是无限信任（危险），要么是没想清楚（更危险）。

边界：出错代价 > 这个活价值的两倍 → 必须 Supervisor 介入；反之可以让 Commander 放手跑。

真实账本：D4 提的”项目 ②番茄投稿 4 章”——砸了最多重写，出错代价 1 倍活价值；改版怪招本 v3 UI——砸了掉 SEO 流量，出错代价 5 倍活价值，必须 Supervisor 介入。

维度 ⑨ · 复用（跑完这次，下次能不能用）

定义：活跑完产出的方法、模板、cron 脚本——能不能下次复用？复用率 0%-100%？

反例：用户说”就这一次”——“就一次”的活，预算 / 时长 / 监督都可以放宽，但复用率 = 0%——这是反向信号，不是正向。

边界：复用率 > 50% → 值得花时间做模板；反之就用一次性的写法。

真实账本：D4 跑分表是 100% 复用——我接每个新活都用这套表；M3 「什么时候不该用 agent」是 30% 复用——套路能用，但具体反例每次都要重写。

---

一份计算表 · 五类 type × 九维度

下表是 D4 的完整版。每维度按 1-5 分打，数字越大越适合对应 type。

type ＼ 维度	预算	时长	上下文	可逆	不确定	中继	监督	出错	复用
Commander	4	4	3	1	1	1	1	1	1
Conversationalist	1	1	4	4	4	2	4	4	1
Supervisor	2	2	2	2	3	5	3	5	2
Co-thinker	3	3	5	5	5	3	5	3	3
Trainer	5	5	2	1	1	2	1	1	5

加权公式：

9 维度总分 = 预算 × 0.1 + 时长 × 0.1 + 上下文 × 0.15 + 可逆 × 0.15 + 不确定 × 0.15 + 中继 × 0.1 + 监督 × 0.1 + 出错 × 0.1 + 复用 × 0.05

总分最高的 type 就是首选。

权重不是平均分——「上下文」「可逆」「不确定」这三个维度对选型影响最大（占 45%），「复用」影响最小（占 5%）。

5 个真实项目跑分复盘：

项目	Commander	Conv.	Supervisor	Co-thinker	Trainer	实际选
100 章细纲	2.65	2.35	2.50	3.85	2.15	Co-thinker ✓
番茄 4 章	2.95	2.05	2.15	2.50	2.50	Commander ✓
改版 v3 UI	2.35	2.30	2.75	2.45	1.90	Supervisor ✓
5 个失败案例	1.60	2.90	1.95	3.40	1.55	Co-thinker ✓
M1 五阶段	1.85	1.75	2.50	2.20	1.80	Supervisor 接力 ✓

粗体是加权分最高的 type，与「实际选」列对照。

加权公式的来历：14 个月账本里，挑了五个跑过的项目，反推权重——「上下文」「可逆」「不确定」错了选型的项目占 60%，所以这三个维度权重各 15%。

---

三步选型流程

步骤 1 · 打分：拿到 brief，先把九维度跑一遍（1-5 分）。别跳步——不打的维度会让你反向校验时无据可查。

步骤 2 · 加权算分：用上面的公式算五个 type 的总分。别用算术平均——维度之间权重不同。

步骤 3 · 反向校验：用「反向校验五招」验证你的选型。

---

反向校验五招 · 避免 D1-D3 的错

招 1 · 检查”边界明确”是不是事后诸葛。

D1 提的”项目 ① 拆 100 章细纲”——边界事前看是明确，跑完发现”明确”是事后才看出来的。

校验法：brief 里写”边界明确”时，问一句”如果中途要加 1 章，主角怎么办”——答不上来就是事后诸葛。

招 2 · 检查”目标清晰”是不是用户自己的清晰。

用户给”做一个 AI 智能体博客”——目标很清晰，但用户清晰 ≠ Mavis 清晰。

校验法：写一版 brief 给 Mavis，看 Mavis 问几个澄清问题——问 0 个就危险（说明在猜），问 3-5 个是健康的。

招 3 · 检查”时间可预估”是不是被低估了。

番茄投稿 4 章 1.2 万字，我估 90 分钟——实际 110 分钟，超 22%。

校验法：第一次跑这个类型的活，时间预估 × 1.3 才是真实时间。第二次跑再校准。

招 4 · 检查”可逆性”是不是被高估了。

“改了能 revert 吗”——git revert 是真可逆，但用户心理预期不是可逆。改版怪招本 v3 UI 第一版用户说”你改吧”——真改完用户说”这不是我要的”——git revert 容易，用户预期 revert 难。

校验法：可逆性 ≤ 3 分的活，先跑 1 个最小例子（不超过预算 10%）让用户确认再展开。

招 5 · 检查”复用率”是不是被忽略了。

用户说”就这一次”——但你跑出来的方法下次大概率会用。

校验法：每个活跑完，问一句”下次同类活，我能不能直接套这个方法”——能 = 复用率 ≥ 30%，值得做模板。

---

五段 brief 模板 · 接到活直接套

模板 1 · 写作类（章节 / 文章 / 博客）

预算: <token / 字数 / 人天>
时长: <单会话能否跑完>
上下文: <需要的前置资料·千字>
可逆: <1-5 撤回难度>
不确定: <1-5 未知程度>
中继: <要不要接力·几个节点>
监督: <每步 / 关键节点 / 只看结果>
出错: <跑砸最坏后果>
复用: <下次能否用 0-100%>

模板 2 · 改版类（UI / 架构 / 重构）

在模板 1 基础上加：

回滚成本: <git revert 几分钟>
用户预期: <用户希望保留什么>
A/B 测试: <要不要新旧并行>

模板 3 · 数据类（爬虫 / 分析 / 报表）

在模板 1 基础上加：

数据源: <API / 文件 / 网页>
数据量: <条数 / GB>
更新频率: <一次性 / 每天 / 每周>
合规: <有无隐私 / 版权问题>

模板 4 · 决策类（选 type / 选方案 / 选技术）

候选: <三到五个选项>
评估维度: <九维度里挑相关的>
权重: <每个维度的权重>
截止: <什么时候要拍板>

模板 5 · 探索类（试试看 / 不确定方向）

假设: <你赌哪个方向>
验证: <跑几步能验>
最小成本: <不超过 X>
失败定义: <什么算失败>

---

七个 cron 自检脚本 · 每周跑一次

cron 1 · 周自检打分

每周日跑一次：把过去 7 天的活全过一遍九维度跑分表。

# cron-weekly-ninedim.sh
last_week=$(date -d '7 days ago' +%Y-%m-%d)
today=$(date +%Y-%m-%d)
echo "[$last_week → $today] 九维度周自检"
python3 scripts/ninedim-weekly.py --since=$last_week --until=$today

cron 2 · 错配告警

打完分后，自动比对”实际跑的 type” vs “加权得分最高的 type”——不一致就发告警。

# ninedim-mismatch.py
def check_mismatch(brief, actual_type):
    weighted = compute_weighted(brief)
    if actual_type != weighted[0]:
        return f"⚠️ 错配：brief 选 {weighted[0]}，实际跑 {actual_type}"
    return "✓ 一致"

cron 3 · 维度漂移检测

每个维度如果连续 4 周都打”中位数 ±1”——说明这个维度你没认真打，是”打酱油维度”。

# ninedim-drift.py
def detect_drift(scores_history):
    for dim in nine_dims:
        if all(abs(s - 3) <= 1 for s in scores_history[dim][-4:]):
            yield f"维度 {dim} 连续 4 周打酱油"

cron 4 · 接力节点检查

中继维度 ≥ 4 分的活，跑完自动列出接力节点耗时——节点之间的「等待」超过 1 小时就标记。

cron 5 · 监督密度统计

每个活的”监督节点数 / 活的总步骤”——监督密度 > 60% 说明活不适合单 type 跑，应该改接力。

cron 6 · 出错账本

每次活跑砸，自动记录”维度打分”vs”实际出错维度”——关联分析找出”打分不准”的维度。

cron 7 · 复用率回收

跑完一个活，30 天后回查：方法/模板被复用了几次？复用率 < 30% 的方法，下次不必花时间做模板。

---

给愿意付一杯咖啡钱的人

这一篇是付费层首篇。免费层（D1-D4）给”是什么”——五个信号、两个对比、一份跑分表、四十五个数据点。

付费层（从 P1 开始）给”怎么做”——

• 九维度逐维拆解（每维四百字）
• 一份加权公式 + 五个项目跑分
• 三步选型流程
• 反向校验五招
• 五段 brief 模板
• 七个 cron 自检脚本

这一套是我 14 个月账本压出来的——每跑一个新活，先过这五段模板之一 + 九维度跑分 + 反向校验五招。选对 type 省一周，选错 type 重做一周——这之间的差，就是付费层要收的咖啡钱。

订阅方式：竹白（微信扫码 1 分钟开通）。

---

下期预告 · P2：「九维度跑分表的 5 个常见错配」——把这套打分落地时最容易踩的 5 个坑，配 5 段真实账本 + 5 个修法。