Part 10 实战：任务拆解 50 例（上）
墨叔：老哥，前面 Part 3 把”规划与分解”的机理、兵器都交给你了——Plan-and-Execute 先画可验的图、粒度控制把图拆成对得起的步骤、Critic 循环干完回头看、围栏兜底框住”假设顺利”的臭毛病。可机理这东西，你不拿真刀真枪比划，永远停在”听懂了”那层。
这一篇不聊原理，专给你 50 例里的上篇——偏”生产创造”：技术/编程、写作/内容两个领域，共 15 例（全集案例 1–15，编号连续），每个都按”问题 → 常人的第一反应 → 拆解过程 → 分析”四层走。你重点看的是：同样一个”怎么干”的问题，落到不同领域，拆解的骨架是不是同一套？——答案是肯定的。任务拆解这门手艺，跟写函数、做需求、搞装修是一回事，跟你是写代码还是办婚礼、理财还是带队伍，没有本质区别。
看完这 50 个，你该长出一种”自动拆任务”的肌肉：任何一件稍微复杂点的事摆面前，你脑子里会自动浮出”它该切成哪几步、每步怎么验收、哪步会翻车”。这层直觉，才是 Part 3 真正毕业的证据。
说明：本篇纯案例、不附代码，分析里点到 Part 3 的对应机制，方便你回扣。
一、技术 / 编程领域（10 例）
案例 1：把一个单体 Go 服务拆成微服务
问题：你接手一个跑了三年的单体 Go 服务，所有模块塞在一个 binary 里，构建要 8 分钟，改一处全量回归。老板说”拆成微服务，订单和支付独立部署”。你拍脑袋能从哪拆？
常人的第一反应：常人想「按代码模块直接切成几个服务，把函数搬过去就完事」。坑：不先定边界和接口契约，搬着搬着发现订单和支付共用一张表、互相直接调函数，根本切不开，最后变成「分布式单体」——比单体还难维护。
拆解过程：
- 先画边界：梳理现有代码，按”业务域 + 数据归属”切出候选服务（用户、订单、支付、库存）。
- 定接口契约：把原来函数调用改成 gRPC/HTTP 接口，先写 proto/OpenAPI，不动实现。
- 抽数据库：每个服务独立库，原共享表按归属拆分，写双写迁移脚本。
- 灰度切流：先让一个只读调用走新服务，验证无误再切写流量。
- 去依赖：把原单体里跨域的直接调用，改成走服务间接口，旧单体逐步变瘦。
墨叔分析：这活本质是 Part 3 讲的”开放式任务变封闭”——你不直接”拆服务”，而是先产出”边界清单 + 接口契约”这份显式计划，再让它可验。最坑的是第 2 步没写好契约就动手，后面步骤间依赖对不上（形态二）。让 agent 干这活，planner 必须先把”输出契约”写死成 schema，executor 每步交接用确定性代码校验”上一步产物是否满足下一步输入”，否则拆到一半前后接口对不上，比不拆还惨。
视角提炼：本例训练的是「边界视角」——按业务域与数据归属切分系统，而非按代码物理位置。可迁移到：任何大系统拆分、模块化、微服务划分。
案例 2：给老系统加一个全文搜索功能
问题：运营想在后台搜订单备注，现有 LIKE 查询慢成狗。你决定上 Elasticsearch，但老系统从没接过搜索引擎。
常人的第一反应：常人想「装个 ES，把 LIKE 改成查 ES 就完事」。坑：不锁范围顺手给所有表建索引；增量同步忘做，老数据搜不到；ES 挂了整个后台崩，没留 DB 兜底。
拆解过程：
- 明确范围：只搜订单备注和商品名两个字段，不碰其他。
- 选型与建索引：定义索引 mapping，写初始全量同步脚本。
- 写增量同步：订单新增/更新时双写 ES（或监听 binlog）。
- 改查询入口：后台搜索接口改成查 ES，保留原 DB 查询做兜底。
- 压测与降级：ES 挂时自动回落 DB 模糊查，不阻塞业务。
墨叔分析：注意第 1 步”只搜两个字段”——这是围栏。开放任务最怕模型顺手”顺带把用户表也建索引了”。第 4 步保留 DB 兜底，正是 Part 3 形态五的”备选路径”。让 agent 做，系统提示里必须写”禁止改动搜索范围外任何表”，并配独立 critic 盯越界，不然它干着干着把整个查询层重构了。
视角提炼：本例训练的是「围栏视角」——先锁范围，新增能力不波及无关模块。可迁移到：任何加功能、改旧系统的需求。
案例 3：把一个 CRUD 接口改成支持批量导入
问题：客户现在一条条录，要加个”上传 Excel 批量导入 5000 条”的接口。你咋落地不把库写爆？
常人的第一反应：常人想「读 Excel 循环 INSERT 进去」。坑：5000 条一个事务锁表半小时；坏行直接整批失败；重复主键覆盖数据；用户不知道到底成没成功。
拆解过程：
- 解析前置：校验 Excel 格式、表头、必填列，坏行先挑出来报给用户。
- 分批处理：5000 条按每批 200 切，逐批落库，每批独立事务。
- 冲突策略：定义”重复主键跳过 / 覆盖 / 报错”三选一，默认跳过并记日志。
- 进度与回执：返回”成功 4800、失败 200（附错误行）“，失败行可下载。
- 限流护栏：单用户并发导入限 1，避免互相锁表。
墨叔分析：第 2 步”每批 200”是粒度控制——一步塞 5000 条，事务太长锁表、上下文也爆。第 4 步”失败可下载”把不可验证的”导完了”变成可验的”成功 N 失败 M”。agent 最容易在第 3 步”凭记忆编冲突处理”，所以计划里要把冲突策略写死成明确契约，别留它发挥。
视角提炼：本例训练的是「粒度视角」——大操作分批，单批可独立事务、可回滚、不锁表。可迁移到：任何批量写入、大事务、大量通知。
案例 4：定位并修复一个偶发的内存泄漏
问题：服务跑三天内存涨 2G，重启就好，监控看不出哪漏。你总不能天天重启吧。
常人的第一反应：常人想「重启呗，或者加内存扛着」。坑：没复现就拍脑袋猜「肯定是缓存」，改了不验证三天后又涨；从不留 profile，下次照样抓瞎。
拆解过程：
- 复现：用 pprof 开采样，压测脚本跑长一点，看堆 profile 趋势。
- 定位：对比不同时点 heap 快照，找出只增不减的对象类型。
- 假设：根据对象类型反查代码（缓存没上限？goroutine 泄漏？channel 阻塞？）。
- 验证：加一行修复，重新压测，确认堆曲线变平。
- 加固：把 pprof 端点常驻，加内存告警阈值。
墨叔分析：这是”问题诊断”类任务的典型骨架——先复现、再定位、后假设、再验证。它和 agent 的 Critic 循环同构：第 4 步”重新压测确认”就是硬事实兜底，不是模型说”应该修好了”。让 agent 干排障，最忌它第 2 步没数据就编原因，所以必须强制”每步结论要有 profile/日志事实支撑”，否则它给你一个听起来合理的错答案。
视角提炼：本例训练的是「诊断顺序视角」——先复现、再定位、后假设、再验证，不跳步。可迁移到：任何偶发、难复现的 bug 排查。
案例 5：实现一个限流中间件
问题：API 被刷，要加限流：单 IP 每秒 10 次，超出返回 429。中间件怎么写才不误伤？
常人的第一反应：常人想「写个计数器，超了就拦」。坑：令牌桶还是漏桶没定；集群下各实例各计各的等于没限；忘了返回 Retry-After；白名单漏加误伤内部调用。
拆解过程：
- 定算法：选令牌桶还是漏桶？明确”突发允许 + 平均限速”用令牌桶。
- 定存储：单机用内存，集群用 Redis，先按单机做。
- 定 key：按 IP + 路由维度，白名单（内部调用）豁免。
- 定响应：超限返回 429 + Retry-After 头，不静默丢。
- 单测：模拟并发请求，断言限速边界和豁免生效。
墨叔分析：第 1 步”选算法”是 planner 该在计划里定死的决策，不该让 executor 临场发挥。第 5 步单测就是 Part 1”必然正确放代码”——限速对不对，测试定生死，不问模型。agent 做这类，计划里”算法选择”必须显式，否则它可能在第 3 步发现 Redis 没接又偷偷换实现，前后不一致。
视角提炼：本例训练的是「决策锁定视角」——方案先定再动手，不临场发挥。可迁移到：任何中间件/组件/库的选型引入。
案例 6：把同步接口改造成异步（消息队列）
问题：下单接口要调三个外部服务，耗时 3 秒，用户等得想摔手机。你想改成”下单即时返回，后台慢慢处理”。
常人的第一反应：常人想「下单后扔个 goroutine 去调那三个服务」。坑：没状态机，前端不知处理到哪；消息重复消费重复发券；消费者挂了死信没人管，用户以为成功其实没。
拆解过程：
- 识别可异步部分：支付回调、积分、通知三件，与”下单成功”无强一致要求。
- 引 MQ：下单写库后发消息，三消费者各自处理，失败进死信队列。
- 状态机：订单加”处理中/完成/部分失败”状态，前端轮询或推。
- 幂等：消费者用消息 ID 去重，避免重复发券。
- 可观测：监控积压、消费失败率，死信人工兜底。
墨叔分析：第 3 步”状态机”是这一步的输出契约——前端靠它知道进度。第 4 步幂等呼应 Part 3 形态五（工具/消息可能重复）。让 agent 改造，最容易漏的就是幂等和死信，因为它”假设顺利”；计划里必须把”幂等键 + 失败兜底”写成强制步骤，不然线上重复发券哭都来不及。
视角提炼：本例训练的是「契约视角」——异步化后靠状态机定义每步产出，让下游有锚。可迁移到：任何同步改异步、事件驱动改造。
案例 7：给项目加一套 CI/CD 流水线
问题：团队现在手动打包发布，一月出三次事故。你要搞一套”提交即构建、自动测、流水线发布”。
常人的第一反应：常人想「写个脚本自动打包发布就完事」。坑：一路绿灯 happy path，没阻断没回滚，一次坏提交直接全量上线出事故；没灰度，没法止损。
拆解过程：
- 定触发：push 到 main 触发构建，打 tag 触发发布。
- 构建阶段：lint + 单测 + 编译，任一挂则阻断。
- 产物阶段：打镜像推仓库，版本号用 tag。
- 部署阶段：先发灰度 10%，自动健康检查通过再全量。
- 回滚：健康检查失败自动回滚上一版。
墨叔分析：这活是把”防御性编程”搬到了流程层——第 2 步阻断、第 5 步回滚都是 Part 3 形态三”上限+兜底”的工程版。agent 配 CI 最大的坑是它写出”一路绿灯”的流水线（happy path），漏掉阻断和回滚；计划阶段就要把”失败闸门”当硬约束写进去，对应形态五的备选路径。
视角提炼：本例训练的是「失败闸门视角」——在流程层设阻断与回滚，把防御性编程搬进流水线。可迁移到：任何发布、部署、构建流程。
案例 8：重写一个混乱的支付对账脚本
问题：线上跑的对账 shell 脚本 800 行，没人敢动，偶尔算错金额。你接了”重写得干净且正确”的活。
常人的第一反应：常人想「读懂旧脚本然后重写一遍」。坑：旧脚本隐含业务规则读不全，重写后金额算错；没有双跑比对，靠「我觉得等价」就切换，上线才发现差异。
拆解过程：
- 提取现状：跑一遍旧脚本，记录它到底对哪些数据源、出什么报表。
- 列需求：对账规则逐条列清（单边账、金额差、状态不一致各怎么处理）。
- 重写内核：按规则拆成独立函数，每规则可单测。
- 双跑比对：新旧脚本对同一批数据跑，结果一致才切换。
- 替换：旧脚本归档，新脚本接定时任务，保留旧版一周可回退。
墨叔分析：第 4 步”双跑比对”是诊断类任务的黄金法则——不靠看懂旧代码，靠结果一致证明新代码等价。这比让模型”理解后重写”稳十倍。agent 重写遗留代码，最危险是第 2 步规则列不全（它读不懂隐含业务），所以要先逼它把规则显式化成清单再动手。
视角提炼：本例训练的是「等价验证视角」——新旧双跑比对，不靠”看懂”证明正确。可迁移到：任何重写遗留代码、迁移脚本。
案例 9：实现一个分布式锁
问题：两个实例同时跑定时任务，重复处理。你要一个”同一时刻只有一个节点执行”的锁。
常人的第一反应：常人想「SETNX 加个过期就完事」。坑：过期短了任务没跑完锁没了；没校验 value 误删别人锁；进程宕机锁不释放，脑裂两个节点同时跑。
拆解过程：
- 定语义：互斥 + 可重入？超时自动释放？明确”必须防死锁”。
- 选载体：Redis SET NX EX，或 ZooKeeper 临时节点，定 Redis 方案。
- 写加锁：原子 SET 带唯一 value + 过期，避免误删别人锁。
- 写释放：用 Lua 脚本校验 value 再删，防误删。
- 测边界：模拟持锁进程宕机，验证锁到期自动释放、不脑裂。
墨叔分析：第 3、4 步的”原子 + 校验 value”是这活的核心难点，也是 agent 最容易”凭记忆写个 SETNX 就完事”漏掉误删的地方。计划必须把”防误删、防死锁”两条硬要求写进步骤契约，并用单测（第 5 步）当 Critic 验证——这类”并发正确性”模型自己审不出，必须靠确定性测试定生死。
视角提炼：本例训练的是「并发正确视角」——防误删、防死锁，靠原子操作加归属校验。可迁移到：任何并发控制、分布式协调。
案例 10：把单体前端重构为组件库
问题：五个项目各自抄了一套按钮、表单，样式五花八门。你要抽一个内部组件库，统一还不打断现有业务。
常人的第一反应：常人想「把五个项目的按钮表单复制一份放公共目录」。坑：没先定规范，抽出来的 API 和现有设计冲突；一次全量替换五个项目打断业务；没试点直接推，回不去。
拆解过程：
- 盘点：扫五个项目，列出重复组件清单及差异点。
- 定规范：设计 token（色板、间距）、组件 API 约定。
- 抽底层：先抽无业务的原子组件（Button、Input），配文档和 Storybook。
- 渐进替换：选一个项目试点接入，逐个组件替换，旧组件标 deprecated。
- 推广：其余项目按试点经验批量替换，移除 deprecated。
墨叔分析：第 4 步”先试点一个再推广”是分层规划——不一次焊死全局计划，先在小范围验证再滚动。这正是 Part 3 讲的”计划滚动更新”。agent 抽组件最易在第 2 步自创一套和现有设计冲突的 API，所以规范必须先于人审锁定，executor 只照规范落地。
视角提炼：本例训练的是「分层渐进视角」——先试点一个再推广，计划滚动更新不焊死。可迁移到：任何抽公共、建标准、推规范。
二、写作 / 内容创作（5 例）
案例 11：写一篇技术深度长文
问题：主编约你写一篇”为什么微服务不是银弹”的 8000 字长文，下周三交。你从空白页怎么干起不写水？
常人的第一反应：常人想「打开空白页从头写到尾」。坑：没立核心论点，写到第三节忘了开头说啥；先抠字眼卡半天写不出；写完逻辑断、水话堆。
拆解过程：
- 定论点：先一句话立住核心观点（微服务解决组织问题，不解决技术复杂度）。
- 列骨架：分 5 节，每节一个子论点 + 案例，画出大纲。
- 找弹药：每节配 1-2 个真实案例/数据，缺的先去查。
- 逐节写：按骨架填肉，先求完整不求精美。
- 通稿：读一遍查逻辑断点、删水话、补过渡，定标题。
墨叔分析：这跟 planner 列计划一模一样——第 2 步”大纲”就是显式计划，第 4 步”先完整再精美”避免一步想太细卡死。让 agent 写长文，最怕它第 1 步没立论点就开写，写到第三节忘了开头说啥（目标稀释）。系统提示要锁死”核心论点”，每节写完 critic 回扣”是否服务于总论点”，防漂移。
视角提炼：本例训练的是「论点锚定视角」——先立核心论点再展开，不空白下笔。可迁移到：任何长文、方案、汇报撰写。
案例 12：写一份产品需求文档 PRD
问题：你要推动”站内信改版”，得写份 PRD 给研发和老板看，讲清背景、方案、指标。
常人的第一反应：常人想「按模板把功能堆上去」。坑：抄行业最佳实践套话，漏掉自己真实的业务约束；列一堆功能没指标没排期，研发拿到没法落地。
拆解过程：
- 背景与目标：现在短信打开率低，目标提升到 30%，写清为什么做。
- 用户与场景：列核心用户群和使用路径。
- 功能方案：分模块描述（列表、已读、免打扰），每个画原型要点。
- 非功能：性能、兼容性、埋点要求。
- 指标与排期：上线后看哪些指标、分阶段里程碑。
墨叔分析：PRD 本质是”给人类看的 plan”——第 3 步功能方案就是步骤契约，第 5 步指标是可验产出。agent 写 PRD 的坑是它爱堆”行业最佳实践”套话，漏掉你真实的业务约束；计划里要逼它”每节必须落到本项目具体数据/场景”，critic 专挑”空话”。
视角提炼：本例训练的是「模块契约视角」——功能方案即步骤契约，可审阅可验收。可迁移到：任何需求文档、设计文档。
案例 13：写一封委婉拒绝客户的邮件
问题：一个大客户提了个超出 scope 的需求，你得拒绝又不伤关系，还得给替代方案。
常人的第一反应：常人想「直接说做不了」。坑：语气硬伤关系；或绕半天不给替代，客户更烦；把门关死断了后续合作。
拆解过程：
- 定基调：先肯定合作、再转折、后给替代，三幕结构。
- 共情开头：感谢 + 认可对方诉求合理性。
- 说难处：用客观约束（排期/合规）而非”我们不想做”拒绝。
- 给台阶：提供缩小版方案或转介资源。
- 收尾：留进一步沟通口子，别把门关死。
墨叔分析：这是”单步骤但高代价”的产出——一封邮件写错措辞客户就凉了。对应 Part 3：高代价产出必须上 critic。让 agent 写，生成后跑一遍”语气/是否留余地/是否给替代”的软核对，再人工定夺。你不能让它”写完直接发”，要 HITL 确认。
视角提炼：本例训练的是「高代价复盘视角」——敏感对外产出须人工确认（HITL），不自动发出。可迁移到：任何对外沟通、外发动作。
案例 14：策划一个公众号系列专栏
问题：你打算做”后端踩坑 100 讲”专栏，每周两篇，持续一年。怎么规划不写到第 10 篇就弃坑？
常人的第一反应：常人想「先写第一篇，边写边想后面」。坑：没选题池，写 10 篇灵感枯竭弃坑；不建模板每篇从零质量飘；没库存，突发写不出断更。
拆解过程：
- 定主题池：先列 100 个题纲，确保有得写，不靠灵感。
- 排节奏：按难度/热度排期，热门话题蹭节点发。
- 建模板：每篇固定结构（现象→根因→解法→小结），降写作门槛。
- 备稿机制：始终保持 3 篇库存，防突发写不出。
- 数据复盘：每月看打开率，淘汰低分选题方向。
墨叔分析：第 1 步”先列 100 题纲”是治”开放任务无边界”的良方——把无限变成有限的待办池。第 4 步”库存”是容错缓冲（形态五备选）。让 agent 持续产出内容，必须外置”选题池 + 模板”当长期记忆，不然它每篇从零想，质量漂移。
视角提炼：本例训练的是「有限化视角」——先把无限主题池列全，降低持续产出门槛。可迁移到：任何长期内容、系列专栏。
案例 15：把一份英文技术文档翻译成本地化教程
问题：社区有篇很好的英文 gRPC 指南，你要翻成中文教程，不是机翻，得符合中文读者习惯。
常人的第一反应：常人想「机翻一遍改改通顺」。坑：术语不统一（metadata 一会元数据一会元信息）；英文省略的背景中文读者看不懂；代码块没验证，命令跑不通。
拆解过程：
- 通读定调：先读全文，定”信达雅”偏向——术语统一表（如 metadata 译元数据）。
- 切块翻译：按小节切，每段先直译再润色成本土表达。
- 补语境：英文省略的背景，中文加一句注解（如”国内常用 etcd 替代 Consul”）。
- 技术校对：代码块、命令逐条在本机验证可跑。
- 统稿：全篇术语、语气一致，出词汇表。
墨叔分析：第 4 步”代码逐条验证”是硬事实 Critic——翻译再顺，命令跑不通就是错。第 2 步切块是粒度控制，整篇翻完再校容易漏。agent 翻译最爱”编造看似合理的命令”，所以代码块必须确定性校验，不靠它自评。
视角提炼：本例训练的是「硬事实校验视角」——带代码的文档，命令逐条验可跑。可迁移到：任何翻译、技术文档本地化。
接龙：中篇偏”过日子+数据”——旅行、日常、健康、美食、数据分析；下篇偏”跟人/钱/规则打交道”——商业、理财、教育、法律、人际。三篇合起来才是完整 50 例，编号沿用全集 1–50。