从 Plan 出发
AI Agent 时代不被外包的能力：解决问题的策略与能力——从弄清与探索开始
§ 本节目录
序篇临走前我埋了一个钩子——把解决问题的策略和方法的 Plan 三步，机器化为可执行契约。从这一节起，我们进入阶段一"想清楚，定契约"。这个阶段的主要矛盾是意图与实现脱节：你脑子里那份，跟它跑出来的那份，对不上（AI可能会回复你说：“我懂你意思”😂）。
要解这对矛盾，先得回答一个更前面的问题——"想清楚"到底是个什么动作？它很容易被读成"多想想"三个字，那样读它就变成鸡汤了。这一节要给你看的，是它作为一套具体动作的样子。
Plan模式：什么时候需要？又如何规划？
再说这套"想清楚"的功夫，不是每个需求都配得上——看你手头这个需求属于哪一档，直接决定你要不要动它。我大致列出三挡：
- 档 1：完全不需要Plan
- 档 2：有一定复杂度，需要先Plan做较简单的规划便可以快速实施
- 档 3：需求复杂、涉及多方、历史决策多、出错代价大，需要祭出problem-solving这套解决问题的策略与方法的法宝来详细规划、分析和设计。
| 判据 | 档 1 · 不需要 | 档 2 · 需要一点 | 档 3 · 必须祭出法宝 |
|---|---|---|---|
| 影响范围 | 单点新增 | 局部改造 | 整模块 / 整项目 |
| 是否涉及历史决策 | 否 | 少量 | 大量，且互相依赖 |
| 出错的可逆性 | 容易回滚 | 中等 | 出错代价大，难回滚 |
| 是否引入新架构决策 | 否 | 一般不 | 是 |
| 典型场景 | 给看板页加个数据表格、加个按钮、某个方法的bug修复 | 数据流水线状态机的变更、单个接口的调整 | 新项目的架构设计、老旧项目核心模块的重构、甚至是你完全摸不着头脑的其他领域问题 |
教这张表不是让你背结论，是让你每次拿到需求时，自己走一遍这四条判据。档 1 想多了没必要；档 2 最容易被错当成档 3 用：想少了会漏、想多了会慢；档 3 就是这一节要展开的我个人实践的贯穿案例："项目权威文档的重构"，稍后正式登场。
这三档的分界，其实也对应主流 Agent 平台的一个通用做法。Claude Code、OpenCode、Codex 这一批工程型 Agent 平台上，普遍出现了把"想"和"做"分开的趋势（有的做成一个独立模式，有的做成一个专门的 Plan Agent，实现方式各异），但先在 Plan 里厘清意图，不做任何编辑，再进入 Execute（执行）。
这门课这一节要立的，就是这条流的第一步。为什么第一步这么重要？是因为
Plan 塌了，Rubbish In, Rubbish Out。
至于剩下还有两步——Execute 是这门课后面几个阶段的主体，Review 在阶段四集中展开。这一节，我们聚焦 Plan。
那 Plan 阶段到底要做什么、具体一套怎么走？下面这套东西，就是这一节要拆给你的——它有个具体的名字，叫 problem-solving。
解决问题的策略与能力
problem-solving 是我自己攒的一个 skill——"skill"是 Agent 平台上一种可装载的能力包，本质是一份写给 Agent 看的方法说明书。我已经公开发布在 GitHub 上，你可以直接取用：crixue/my-skills · methodology/problem-solving。它干的事，是把"解决问题的策略"这件听起来很虚的能力，落成让Agent五步谁都能走的动作：
- 弄清问题 —— 弄懂题意，识别输入 / 输出 / 已知 / 约束 / 准则
- 探索思考 —— 找到真正的问题所在，生成多条可能途径
- 拟定计划 —— 从多条途径中选定一条，拆成可执行步骤
- 实现计划 —— 仔细执行，随时检查进程
- 回顾总结 —— 校核合理性、评价思考过程、推广迁移、沉淀经验
这份说明书的末尾我还画了一张流程总览——注意看里面的箭头，回环和正路一样多。
这些回环不是倒退——序篇讲《实践论》时说过那句：实践、认识、再实践、再认识，每一循环都进到高一级的程度。带着新暴露的材料回到上一步，下一轮的起点就比上一轮更高。
这份 skill 有两个入口：入口 A（Plan），你带来一个还不清晰的问题，走前三步；入口 B（Review），一件事已经做完，走第五步做复盘。它还给 Agent 规定了两个角色——问题倾听者（帮你把脑子里模糊的想法外化、澄清）与问题处理者（贡献实质的分析与结构），这里先认个门，后续会专门展开。这一节，我们从入口 A 进去。
还有一样东西要先交代：这套方法的每一步都会留下纸面记录。它的家在项目根目录的 .problem-solving/ 目录——每解决一个问题，就在那里落一份档案，文件名是"日期 + 主题"。这个目录同时是经验库：下一次问题来了，先扫一遍旧档案的文件名，看有没有可借的燃料。
前面我提到的"项目权威文档的架构级重构"这个例子，具体是这件事：项目里 4 份重要且权威文档，用于定义Agent实施的铁律（conventions.md 700 行 / design-system.md 1136 行 / runbook.md 792 行 / eval-rubric.md 668 行，我们内部管它叫 canonical 文档），这几份文档在N多次迭代中内容臃肿且存在冲突和漂移，需要拆成"母文档 + 子目录细节"的渐进披露结构（Agent先读短的母文档，需要细节再按索引进子文档），同时消除文档与代码的漂移，并输出一份迁移指南。这就是那次协同要解的问题。
档案就住在 .problem-solving/ 目录里，我和一个 Agent 协同走完 Plan 全程留下的一份记录，跟problem-solving skill的五步一一对应：
.problem-solving/2026-06-21-docs-progressive-disclosure.md
├─ ## 1. 弄清问题 · 问题陈述 / 要素表 / 定势破除
├─ ## 2. 探索思考 · 真问题 / 候选途径 / 关键决策 / 意外发现与收束
├─ ## 3. 拟定计划 · Change A（先修漂移）→ Change B（再做拆分）
├─ ## 4. 实现计划 · 两份已归档的 change
└─ ## 5. 回顾总结 · 结晶：真源优先级——代码 > 文档 > 原型（历史）
顺便说一句你迟早会自己发现的事——这门课的结构，本身就是这套方法的一次演示：阶段一教你弄清与探索，而这门课每一节的写作本身，也是先弄清、再探索、再拟定、再实现、再回顾，一步步走过来的。你在学的方法论，正是这门课的结构本身。
最后把这一节的底牌先亮出来。这套东西为什么值得用一整节来立？因为 AI Agent 时代，能被外包的是检索、汇总、复述这类繁琐工作；不能被外包的，是判断、取舍、和"想清楚"本身。这门课不教你把大脑关掉——而是教你把大脑用在真正值钱的地方，并让你在每次协同中，把自己的思考能力磨得更利。
骨架看完了，我们从第一步开始——弄清问题。
第一步 · 弄清问题
Plan 阶段的第一步，叫弄清问题。它主要是分析：弄懂"真正要解决的是什么"，而不是急着解。
但"弄清"两个字容易被读成"多想想"——这样读它就变成鸡汤了。这一步在 skill 里其实是一套动作。我们把动作先摊开，再回到那份 docs-progressive-disclosure 案例，看它是怎么落成的。
复述与要素表：把默认藏起来的东西摊到桌面
skill 里的第一个动作，是复述确认：用你自己的话把用户的问题重述一遍，请他确认"我理解得对吗"。这不是走过场——它的目的是延迟判断，避免会错意。人抛出的问题，几乎从来不是他脑子里那个问题的完整投影；用他自己的话再听一遍，常常是他自己也第一次听清楚这个问题长什么样。
紧接着，用一张五行小表把问题摊开：目标、已知、约束、准则、未知，skill 里叫要素表。每一行都是一次"我知道 / 我不知道"的当场承认。尤其准则这一行（"怎样算做对了、做好了"），最容易被跳过，却最重要：日常问题里，"提出问题"和"成功的标准"往往比"求解"更难。
这两个动作合起来干一件事——把默认藏在脑子里的假设，全部搬到桌面上。默认值不摊出来，后面 Agent 就会用它的常识替你猜；猜错了它不知道，你也不知道。
回到我们的案例。我当时开口的原始陈述只有几句话——"项目中的权威文档太臃肿了，而且写得像法典一样相互引用且还存在冲突，请探索文档中的所有有问题的文档，最终拆成'母文档 ≤200 行 + 子目录细节'的渐进披露结构，顺便消除文档跟代码的漂移，再写一份迁移指南。"
这几句话，摊开就成了案例 §1 的要素表：
| 要素 | 内容 |
|---|---|
| 目标 | 拆 4 个文档 → 母子结构 · 修 3 项漂移 · 写迁移指南 |
| 已知 | "一概念一权威文档"规约 · AGENTS.md ≤30 行 · docs/architecture/ 先例 |
| 约束 | Plan 模式只读 · 必须走 OpenSpec change · registry 需更新 |
| 准则 | C1 母 ≤200 · C2 零信息丢失 · C3 漂移修复 ... C7 迁移指南可读 |
| 未知 | 漂移程度（要抽样验证）· 用户对粒度的偏好 · CSS 块如何处理 |
表里几个项目内部的说法，先认个门："一概念一权威文档规约"就是刚才那条"每个概念只留一份权威文档"规矩的正式规格书；"OpenSpec change"是我们项目里"任何改动先写一份变更提案、走流程评审"的机制；"registry"是所有权威文档的总登记表——新增一份权威文档，要在这里上户口。
再看准则那一行的 C1-C7 七条——这就是刚才说的"最容易被跳过的一行"。要不是这一步逼你写下来，后面拆完了发现"母文档 300 行"，你还以为自己达标了。准则一写，达没达标就没有争议了。 不过这一点我们后续章节会有更详细地实现方式。
分档来源可靠度，破除定势
skill 里的第二组动作，是给要素表里的每一条"已知"标注来源可靠度：
- 直接经验 —— 亲历、亲眼看过、亲手跑过
- 间接经验 —— 听说、文档、记忆、他人转述
两者都是知识的正当来源，但间接经验可靠度低一档——尤其"关键的一环仍是道听途说"时，要点出来。序篇那句话在这里落地：AI 的所有知识，对你这个具体项目而言，全是间接经验。
与来源可靠度紧挨着的，是破除定势。人常在没人要求时给自己套上枷锁——经典的"九点四线"题：题目没说线必须落在方框内，是人自己默认的。所以要留意话里那些题目本没有、却被默认为限制的条件，温和点破："这条是题目要求的，还是我们自己默认的？如果去掉它会怎样？"
这两组动作合起来，干的是同一件事——让"我以为的"跟"实际的"，至少校准一次。
案例印证。 案例里被破除的定势，有 3 条：
- "CSS 代码块必须保留在文档里" —— 抽检后决定：以项目代码为真源，文档只留规则要点。
- "design-system 以原型为真源" —— 抽检发现原型那套命名空间早已废弃，实现早已演进。
- "开闭原则需要新的工程机制" —— 确认现有的权威文档登记表已经够用，不另造轮子。
每一条都是"我以为 A，一去核就是 B"。三条里最有意思的是第二条——"design-system 以原型为真源"这条，在项目里流传了很久，从来没人质疑过。直到这次抽检，才发现真源关系反过来了。
这就是序篇那句话在这里的具体落地：AI 是书呆子，满肚子间接经验；你的 codebase，是那颗梨。让 Agent 去 grep、去抽检、去跑一小段真实代码，就是让它亲口吃梨。梨吃过了，定势破了，三条"我以为"至少被校准了一次，材料才算合于实际。
材料充分性门槛：什么时候可以停
skill 里第一步的收尾，是一道自检门槛：感觉材料是否既丰富（不是零碎不全），又合于实际（不是错觉）？
- 不丰富 —— 要素表里还有大片"未知"，或核心事实还没被点过一遍。
- 不合于实际 —— 关键的一环仍停留在道听途说，"我记得好像是……"。
只要其一没过，理性认识就是无源之水。这时候不要急着往前推，先安排一次最小的直接接触：看现场、读真实代码、跑一次、问当事人。"要知道梨子的滋味，就得亲口吃一吃"，这一步安排在弄清问题的尾巴上，比后面才发现前提错了，要便宜得多。
反过来，门槛过了的表现是——你不再需要问基础，而是开始就"取舍和边界"发问。这时可以进下一步。
案例印证。 案例里"抽样验证 design-system 漂移"那一小步，就是这道门槛的现场执行。走到那里，我已经不问"我们要不要拆"，开始问"母文档的粒度是 200 还是 150、迁移指南进不进权威文档集"。这些都是取舍和边界的问题——门槛过了。
一整块走下来，回看一下分工：AI 帮你外化了要素表、跑了抽检、汇总了对比结果，这些都是外化的活儿；但每一行的拍板、每一条定势要不要点破、材料够没够，是你的判断。这就是这套 skill 想让你养成的第一层功夫：让 AI 干繁琐的，把判断留在自己手上。
弄清了——但弄清 ≠ 有路走。下一步：探索思考。
第二步 · 探索思考
skill 里的第二步，叫探索思考。它是整个 Plan 阶段最复杂、最有创造性、个体差异最大的一步——也正因如此，它值得多花时间。别误以为时间都该花在执行上。这一步要走四个动作。
找真问题：表面下面还有一层
skill 里探索思考的第一动作，叫"找真问题"——表面问题往往不是真问题，把它说破。
这一步在 skill 里被称为第一次飞跃：把弄清问题里积累的感性材料，去粗取精、去伪存真、由此及彼、由表及里——从"现象与外部联系"，推进到"本质与内部联系"。序篇讲两次飞跃时说的是课程尺度的画面；这里，是它在一次具体协同里的样子。
找到真问题以后，还有一个不起眼但重要的动作——带着它回看原始材料。《实践论》里那句"只有理解了的东西，才能更深刻地感觉它"，意思就是：一旦你把真问题拎清了，回头看原来那堆材料，会看见先前忽略的细节。
我在这里提到一个我遇到的案例里：表面问题看起来是"4 份给Agent查看的文档太长且有大量冲突，拆一下"的问题，也就是拆分本身。我委派 explore agent（一个专门派出去"跑腿调查"的子 agent，只读不改，回来交一份报告）去做抽检，它报告说："发现 6 类系统性漂移"。如果就这样直接信，那这次修漂移要动几十上百项，整个改动立刻炸掉。
但我没直接信，又做了一次二元核对——发现 6 类里有 5 类其实是基准错配：explore agent 比的是原型里的 CSS，但项目代码早已用上了文档那套语义化命名空间。真漂移，其实只剩 4-5 处小数值。
拎清这一层之后，表面问题"文档拆分"背后的真问题才浮出水面：真问题不是"文档漂了"，而是"文档、原型、代码三处真源的优先级，从来没被明确过"。这条真问题后来沉淀成一句话：代码 > 文档 > 原型（历史），而这句话，会贯穿到这门课的阶段二、阶段三、阶段五。
这就是"找真问题"的分量——找对了，一次拆分的沉淀能用到三个阶段之后；找错了，整个改动当场炸掉。
3-4 条合理途径：每条明码标价，提防两条沟
skill 里探索思考的核心动作，是给出 3-4 条合理途径——每条简述思路 + 主要权衡（代价 / 风险 / 前提）。
- 不能只给一条就推着走——单条候选是"许愿"，不是"选择"。
- 也不能堆出十几条把人淹死——3-4 条，是精心筛过的、站得住的候选。
- 每条必须注明"根据来源"——来自理论、通用实践、过往记录，还是本次直接观察？这既是让人看清底牌，也是给你自己的一道刹车。
为什么强调"3-4 条"、而不是"越多越好"？ 这里插一个反面教材。国外有位叫 Matt Pocock 的网红开发者出过一个叫 grill-me 的 skill——你让它帮你审一条路，它能把每一层分支都拆得很细。仔细，但有个致命问题：它不抓主次。
打个比方——你去餐厅结账。服务员先问："现金、微信还是支付宝？"你答现金。他算好找零后接着问："找零你要一张 20，还是两张 10，还是各种硬币组合？"你说随便。他又追问："纸币要新的还是旧的？要不要连号？硬币要新款还是旧款？"……
这个服务员不是不负责——是太负责了，负责到把一个两秒钟的动作拆成了二十个同等权重的子决策。grill-me 对分支的拆解，就是这种感觉：每条它都想帮你走深一步，但分不清哪几条最要命、哪几条其实无关紧要。
穷尽所有分支 ≠ 抓住主次。skill 之所以卡在 3-4 条，是让你把有限的认知资源，押在最重要的那几条上。至于 grill-me 什么时候能用、什么时候该搁置，我们在后续契约化环节和 problem-solving 的 Plan 三步里会展开讲。
回到 skill 本身。这个动作还要提防两条沟：
两条沟共同的病根：主观与客观脱节，脱离了当前这一次问题的具体条件。避开两条沟的最朴素办法：每一条候选，都拿这个项目当下的条件重新权衡一遍。别盲信"通用最佳实践"，也别盲信"上次"。
案例印证。 案例里这一步的候选表，是这样的：
| 方案 | 描述 | 权衡 | 结论 |
|---|---|---|---|
| A | 一个大 change（漂移 + 拆分一起做） | diff 大、评审难、回滚粗 | ✗ |
| B | 4 个小 change（每份文档一个） | 粒度过细、registry 来回更新、要走 4 轮评审 | ✗ |
| C | 2 个 change（先修漂移 → 再拆分） | 修漂移的小改动快速过 → 拆分建立在正确基线上 | ✓ 选中 |
注意每一行的权衡那一列。方案 A 不是"不好"，是它的三个代价（diff 大、评审难、回滚粗）太重；方案 B 不是"不对"，是 4 轮评审的成本换不回什么。没有代价，就没有选择，只有许愿。
这三条，也正好演示了避开两条沟的路数：没有一条是因为"业界都这么做"或"上次就这么干过"入选的——每一条，都是对着这个项目当下的条件（4 份文档、评审带宽、评审成本）单独权衡的结果。
分支预演：找依赖链，命名悬空的前提
skill 里第三个动作，叫分支预演——在让人选路之前，沿着最有希望的几条途径，各自往前快速走一步：
- 如果走这条路，接下来要面对的依赖决策是什么？
- 它依赖什么前提？这些前提哪些已成立、哪些还悬空？
- 几条路之间有没有共同依赖——某个决定必须先定，不然后面几条路都走不通？
这一步的目的不是穷尽所有分支，而是找出决策之间的依赖链——让人在选路之前，真正理解每条路的后果。对最有希望的 1-2 条走深一点，其余点到为止。
分支预演里最容易漏、也最重要的动作：前提悬空的路，要命名清楚。如果一条路依赖的关键前提"仅在将来才有现实可能性"（资源、能力、时机还不在），那走它就是把理想当作现时计划，这是要点出来的风险，不是含糊地"再看看"。
案例印证。 案例里选定方案 C 之后，又拍板了 5 个关键决策——这五条，全部是分支预演过程中被"命名清楚"的悬空前提：
| # | 决策 | 结果 |
|---|---|---|
| P1 | 漂移修复是否改代码 | 仅改文档 |
| P2 | 母文档内容策略 | 仅含索引 + 红线 |
| P3 | 子文档粒度 | conv 6 / design 5 / runbook 6 / eval 4 |
| P4 | 迁移指南位置 | docs/docs-migration-guide.md · 不进权威文档集 |
| P5 | design-system 抽检范围 | 委派 explore agent 执行 |
这五条，每一条都是"不写下来，走到拟定计划就会以为它已经解决"的类型。写下来，后面每一步都能追溯到"我为什么这么做"。
收束原则：计划是待检验的假说
skill 里探索思考的最后，有两条贯穿动作。
一条叫"发散监控"。 探索思考本身就容易让分支越来越多、越扯越远。一旦你察觉离题、或路径多到开始消耗耐心——主动收束：回到第一步，重新明确"我们核心要解决的到底是什么"，砍掉枝节。宁窄而清，不宽而散。
一条叫"计划是待检验的假说"。 这是这份 skill 从《实践论》引来的底色，也是序篇那本书在这里的落地。它给这一步定了个态度：你现在探索出来的路，不是圣旨，是假说。所以选定一条路的时候，要给自己留回退口——一旦这条路在执行里被证伪，允许带着新暴露的材料，回到弄清问题重开一轮。
案例印证。 案例里这两条，各有各的落成。
发散监控的证据，藏在"意外发现与收束"那段——explore agent 报"6 类系统性漂移"时，我没有顺着把改动无限扩容，而是主动收束（"等等，是不是基准错配？"），把范围又拽了回来。这一次收束，让修漂移的改动从"几十上百项"缩回到最终的一百行上下。
回退口的落成，是同一段里的那句："进一步指示 design-system 以项目代码为核心，文档引用代码"。这不是原路径的直接推进，而是基于抽检暴露的新材料，回到弄清问题重开了一小轮，整个改动的范围也因此再次缩小。这就是回退口在真实案例里的样子：不是等失败了才回，是新材料一暴露就回。
探索思考四个动作走完，你手上有：
- 一条被拎清的真问题（案例：真源优先级从来没被明确）
- 3-4 条明码标价的候选（案例：方案 A / B / C）
- 一张悬空前提清单（案例：P1-P5 五条决策）
- 一次基于新材料的回退（案例：抽检后再次缩小改动范围）
前两块，是 skill 里说的第一次飞跃完成的标志——从感性材料走到了理性认识；后两块，是给这次理性认识明码标价，承认它的边界。
走到这，Plan 阶段的前两步（弄清与探索）就完了。剩下的一步"拟定计划"，我们下一节讲。
能被外包的，与不能被外包的
两步走完，回望一下——这一节里，AI 干了什么、你干了什么？
一整节，我们只走了 problem-solving 五步里的前两步——弄清问题、探索思考。但这两步走完，你已经能感觉到：它的每一步，都在训练你"哪些能交出去、哪些必须留在自己手上"的分辨力。
那剩下的三步呢？各归各位。
第三步 · 拟定计划：把已经想清楚的路，拆成一份 Agent 能接手去跑的东西。这是 Plan 阶段的收口。两个辅助工具留下来，你也可以尝试尝试：一个是刚才提到的 grill-me，用它来压力测试你的计划里的盲区；另一个叫 tracer-bullets，拟定计划时把大路径切成能端到端跑通的薄片，SKILL.md 也已公开。后续的章节我也会专门讲具体让你的Plan落成具体的执行契约。
第四步 · 实现计划，也就是三步大路里的 Execute。那是这门课后面几个阶段的主体内容：从阶段二"备齐弹药与阵地"开始，到阶段三"把墙修成门禁"，都在讲 Execute 这一步：怎么让 Agent 真的把想清楚的东西，端到端跑通。
第五步 · 回顾总结。你可能已经注意到，贯穿全节的这份案例，其实还有一段 §5 回顾总结。那就是这套 skill 的第五步：Review。它做的事，是把这一次弄清和探索得来的东西结晶下来，变成下一次遇到相似问题时的燃料。看案例作者最后沉淀出的那一条：
确定了单一源的优先级：代码 > 文档 > 原型（历史），因为文档会偏移，但是代码会忠实地反映项目的真实情况，原型只是历史参考。
这一条结晶，这门课后面会反复用到：阶段二讲上下文时用到，阶段三讲门禁时用到，阶段五讲 SSOT（single source of truth · 单一真相源）治理时还用到。Review 不是走完就丢——它把每一次的思考沉淀在 .problem-solving/ 目录里；下一次问题来了，你的起点就更高。
Review 本身也是一门功课——而且它跟弄清问题、探索思考之间，有一条深藏的对应：Review 不只是复盘"事情做完了没"，更是复盘"当时弄清得够不够、探索得对不对、那些拍板经得起时间检验吗"。这是一个元层次的自我校核，也是让这套方法从"一次性动作"变成"螺旋上升"的关键。这一整套，我们会在阶段四"让它自己转起来"集中展开。
请记住能被外包的是搜索、汇总、复述这些重复、繁琐的事；不能被外包的是判断、取舍、和"想清楚"本身。
我希望你在看完整个系列的课程之后，不再为难与"这个问题解没解决"——而在"问题解决了，而你解决问题的能力变强了"。
换个战场：两道练习
这套 skill 的五步没有一步是软件工程独有的。下面两题——一道来自生活、一道来自工作作为参考，你遇到的其他不同领域方面，都可以尝试使用problem-solving，自己解决一下问题。
练习一 · 生活
你的娃学习成绩一般，你老觉得他学习积极性不高。周末——该给他报几个补习班、把成绩稳住？还是别报，带他出去玩、发展点兴趣、给他一个"快乐童年"？夹在中间的你左右为难。
练习二 · 工作
你手下的人把一个重要交付搞砸了。客户已经投诉、领导今天下午刚指着你鼻子大骂了一顿。骂完，你回到工位思考——接下来 24 小时，你要拿出一份"怎么救"的方案。从哪儿下手？