第11章工作流即资产

第10章讲了 AI 能力编排：你不再把 AI 当单点工具，而是把多个能力组织成系统。但能力编排之后，真正决定你能不能长期放大的不是「这次做成了」，而是「下次能不能不用重来」。本章解决的问题是：把重复劳动改造成工作流资产；第12章会继续讲，工作流跑完后产生的知识，如何沉淀成可检索、可复用、可喂给 AI 的知识系统。

11.1 结论先行：重复做第二次的事，就应该变成工作流

你重复做第二次的事，就不该再以「任务」形态存在，而应该变成工作流（Workflow）。任务是一次性消耗，流程是经验描述，工作流是可执行资产，产品是可售卖资产。四者不是同义词，而是一条递进链：

text

一次性任务 → 流程 → 工作流 → 产品
消耗时间   记录经验  复用能力  产生现金流

本章的核心判断很直接：工作流是最接近现金流的资产。内容资产需要传播，代码资产需要适配，知识资产需要检索；工作流资产只要能稳定解决一个高频问题，就可以直接服务交付、培训、外包、咨询、软件化和产品化。它离钱近，因为它回答的不是「我知道什么」，而是「我能稳定把什么事做完」。

这正是在显式呼应第01章的公式三 · 复利资产 = 一次生产 × N 次复用。工作流的本质，就是把一次成功交付拆成可重复执行的资产，让每一次复用都降低边际成本。它同时也间接拉升公式一：当一个 AI 能力被包进工作流，它就不再靠记忆调用，而是靠规范重复调用。

理解这一点后，本章其余都在回答一个问题：如何判断什么事值得工作流化，并把它写成能跑、能验、能维护、能产品化的资产。

11.2 工作流是什么：定位、能力与边界

工作流不是「我做事的大概步骤」，也不是一段漂亮的 prompt。工作流是一个可重复执行的交付协议：给定输入，按固定步骤调用工具，产生可验收输出，并且知道失败时怎么处理。

与一次性任务、流程、产品的差异

维度	一次性任务	流程	工作流	产品
核心形态	做完一件事	记录怎么做	固化怎么做	让别人也能用
输入要求	临时描述	大概条件	明确字段	标准入口
执行方式	靠人判断	靠人照着做	人 + AI + 工具协同	用户自助或半自助
验收标准	做完算完	经验判断	明确检查项	用户价值与付费
复用能力	极低	中等	高	最高
现金流距离	远	中	近	最近

一次性任务只消耗时间。比如「帮某个项目做一次代码审查」。它做完就结束，最多留下一个结果。

流程开始沉淀经验。比如「代码审查先看入口、再看权限、再看数据流、最后出报告」。它能指导人，但还不能自动稳定执行。

工作流把流程变成规格。比如「输入仓库路径、审查范围、风险等级；按文件树扫描、依赖识别、风险清单、复核、报告模板输出；验收项包括可复现路径、影响等级、修复建议」。它不依赖某次灵感，而依赖结构。

产品是工作流外化后的形态。比如一个审查服务包、一个自动化脚本、一个 Agent 产品、一个交付 SOP、一个课程模板。产品不是凭空来的，它通常是从高频工作流里长出来的。

能做什么

降低重复成本 — 把「每次重新想」变成「每次按规格跑」，让你的脑力只用于例外判断。
提高交付稳定性 — 工作流自带输入、步骤、验收和失败处理，减少靠状态吃饭。
放大 AI 编排价值 — 第10章的 AI 能力编排只有沉淀为工作流，才不会停留在一次性炫技。
训练协作对象 — 你可以把工作流交给 AI、外包、同伴或未来员工，而不是把自己变成唯一入口。
逼近产品化 — 当一个工作流复用足够多次，它天然暴露用户需求、收费方式和产品边界。

不能做什么（边界）

不能替代需求判断 — 工作流解决「怎么稳定做」，不解决「该不该做」。需求真假仍然回到第02章到第08章。
不能消灭复杂性 — 它只是把复杂性显性化、分层化、可检查化，不是把难题变简单。
不能一次写完永远不改 — 工作流是活资产；无人维护的工作流会变成过期文档。
不能无脑自动化 — 过早自动化会把错误固化成高速错误。先稳定，再自动化。

11.3 工作流的原理拆解：把经验变成可执行协议

工作流的底层结构可以压缩成六个部件：输入、触发、步骤、工具、验收、失败处理。缺一个，它就会退化成口头经验。

text

             ┌──────────────┐
             │    输入       │
             │ 任务材料/边界 │
             └──────┬───────┘
                    │
                    v
┌──────────┐   ┌──────────┐   ┌──────────┐
│  触发条件 │ → │  执行步骤 │ → │  工具编排 │
└──────────┘   └────┬─────┘   └────┬─────┘
                    │              │
                    v              v
             ┌──────────────┐
             │    输出       │
             │ 文档/代码/报告 │
             └──────┬───────┘
                    │
                    v
             ┌──────────────┐
             │    验收       │
             │ 标准/检查/确认 │
             └──────┬───────┘
                    │
         ┌──────────┴──────────┐
         v                     v
   ┌──────────┐          ┌──────────┐
   │  归档复用 │          │  失败处理 │
   └──────────┘          └──────────┘

11.3.1 输入：把「你看着办」改成字段

输入越模糊，工作流越不可复用。很多人的工作流失败，不是步骤写得少，而是输入没有结构化。

坏输入是：

text

帮我调研一下这个方向。

好输入是：

text

任务类型：资料调研
主题：__________
目标读者：__________
使用场景：决策 / 写作 / 产品设计 / 销售材料
时间范围：近 1 年 / 近 3 年 / 不限
地域范围：中国 / 美国 / 全球 / 指定地区
必须回答的问题：
1. __________
2. __________
3. __________
输出格式：摘要 / 表格 / 报告 / 决策建议
验收标准：至少覆盖 ___ 个来源，结论必须区分事实、推断、建议

字段化输入的价值，是让 AI、工具和人都知道边界在哪里。边界明确，后面才有验证；没有边界，所有输出都只能靠感觉判断。

11.3.2 步骤：把隐性经验拆成不可省略的动作

步骤不是越多越好，而是要抓住不可省略的节点。一个好步骤必须满足三点：

动作明确 — 不是「分析一下」，而是「列出 5 个风险点并按影响排序」。
顺序有因果 — 前一步的输出是后一步的输入。
中间可检查 — 每一步都能判断是否继续、返工或中止。

以代码审查工作流为例，粗糙流程是「读代码 → 找问题 → 写报告」。可执行步骤应该是：

text

1. 确定审查范围：仓库、分支、语言、入口模块、排除目录。
2. 建立结构地图：文件树、主入口、数据入口、权限边界、外部依赖。
3. 识别风险面：认证、授权、输入校验、文件操作、网络请求、命令执行、数据持久化。
4. 抽样验证：对高风险路径做最小复现或静态证据链。
5. 分级归因：按影响、可利用性、触发条件划分优先级。
6. 输出报告：每个问题包含位置、场景、影响、根因、修复建议、复测方法。
7. 归档复用：沉淀风险模式、检查清单、报告模板。

这组步骤之所以能复用，是因为它不绑定某个具体项目，而绑定「代码审查」这个任务类别。

11.3.3 工具：把 AI 放在正确的位置

工作流不是「让 AI 全自动做完」。更准确的结构是：人定义边界，AI 扩展认知，工具执行动作，检查项负责收口。

环节	人负责	AI 负责	工具负责
范围	判断做什么、不做什么	帮助澄清边界	读取材料、列目录
分析	选择重点与风险等级	扩展假设、生成初稿	检索、运行、统计
实现	决策方案	起草、改写、补全	编辑文件、执行命令
验证	判断是否可交付	生成测试思路	跑测试、截图、比对
归档	选择沉淀什么	总结模板	保存、索引、同步

第10章讲 AI 能力编排时，重点是「有哪些能力可以组合」。本章往前推进一步：只要组合方式稳定出现，就应该写成工作流规格。

11.3.4 验收：没有验收的工作流只是自嗨

工作流的验收必须先于自动化。你不能先问「怎么自动跑」，而要先问「什么叫跑对」。

一个工作流的最小验收标准包括：

text

输出完整性：该有的字段、文件、章节、结果是否齐全？
过程可追溯：关键判断是否有来源、证据或执行记录？
结果可复用：下次能否基于这次产出继续执行，而不是重来？
失败可定位：出错时能否判断是输入、步骤、工具还是验收的问题？
人审边界：哪些决策必须由你确认，不能交给自动化？

这也呼应第01章的公式二 · 交付闭环 = 范围 → 实现 → 验证 → 验收。工作流不是只管实现，它必须把验证和验收写进规格。否则你只是把烂尾流程自动化了。

11.4 四个心法：把工作流变成资产，而不是文档

心法一：第二次出现，就是资产候选

铁律：任何你第二次手动重复的动作，都必须问一句——它为什么还没有变成工作流？

记录触发条件：什么时候会重复？谁提出？频率多高？
记录输入输出：每次开始需要什么，结束交付什么。
记录可变部分：哪些字段每次不同，哪些步骤每次固定。
记录失败点：上次卡在哪里，这次有没有再卡。

不是所有重复都值得自动化，但所有重复都值得被识别。识别后再决定：删除、外包、模板化、工作流化、产品化。

心法二：先手动稳定，再半自动，再全自动

过早自动化是最常见的浪费。你还没知道任务是否高频、输入是否稳定、验收是否清晰，就急着写脚本或做 Agent，结果只是把不成熟经验封死。

正确路径是：

text

手动执行 3 次 → 写出 SOP → 半自动辅助 5 次 → 固化工作流 → 评估产品化

手动执行用于理解问题，SOP用于稳定经验，半自动用于找出工具边界，工作流用于复用，产品化用于服务他人。

心法三：工作流规格比 prompt 更重要

prompt 是工作流的一部分，不是工作流本身。很多人沉迷收藏 prompt，本质上是在收藏「局部动作」，而不是构建「完整交付」。

一个 prompt 可能解决「生成一段报告」，但工作流要解决：输入从哪里来、资料怎么核验、报告怎么分章、结论怎么标注置信度、失败怎么返工、最终怎么验收。prompt 负责一句话，工作流负责一件事。

心法四：每个工作流都要有维护人

工作流一旦无人维护，会快速腐烂。工具接口会变，模型能力会变，用户需求会变，你自己的判断标准也会变。无人维护的工作流比没有工作流更危险，因为它会制造一种「我有标准」的错觉。

维护不是大重构，而是固定做三件事：

记录每次失败 — 不掩盖，不靠临时补丁糊过去。
更新输入字段 — 每发现一个新变量，就决定是否纳入规格。
收紧验收标准 — 把模糊的「差不多」改成可检查项。

11.5 实战：把三类高频任务变成工作流

这一节给三个可迁移场景：代码审查、资料调研、文章成书。它们都经过脱敏处理，不涉及真实平台、凭据、客户信息或绕过手段，只保留工程范式。

步骤一：把「代码审查」变成工作流

代码审查是典型的高价值工作流，因为它具有明确输入、稳定步骤、强验收标准和可复用报告格式。

text

工作流名称：Code Review Workflow

输入：
- repo_path：待审查仓库路径
- scope：审查范围（全量 / diff / 指定模块）
- focus：重点风险（安全 / 正确性 / 性能 / 可维护性）
- exclude：排除目录（依赖、构建产物、测试数据）

步骤：
1. 读取项目说明和约束文件，确认审查规则。
2. 建立文件结构地图，识别入口、配置、权限、数据流。
3. 按 focus 生成检查清单。
4. 对高风险路径建立证据链：位置 → 触发条件 → 影响 → 修复方向。
5. 对每个发现做复核，删除无法支撑的猜测。
6. 输出报告，按严重程度排序。

工具：
- Read：读取关键文件
- Bash：运行只读分析命令和测试命令
- grep / rg：定位调用链
- 测试命令：按项目规范执行

验收：
- 每个问题必须有文件位置和可解释场景。
- 不输出无法复现、无法推理或只有风格偏好的问题。
- 报告必须区分 confirmed / plausible。
- 结尾必须给修复优先级。

失败处理：
- 找不到项目规范 → 先停止，要求补充规则或读取说明。
- 无法运行测试 → 记录原因，不伪造验证结果。
- 证据不足 → 降级为观察项或删除。

这不是一份报告模板，而是一套交付协议。它的价值在于：你下次审查不同项目时，不再从「我该怎么看」开始，而是从「这次输入字段是什么」开始。

步骤二：把「资料调研」变成工作流

资料调研最容易变成信息堆砌。工作流化的关键，是把它从「找资料」改成「回答决策问题」。

text

工作流名称：Research Workflow

输入：
- topic：调研主题
- decision：本次调研要支持的决策
- audience：读者是谁
- geography：地域范围
- timeframe：时间范围
- must_answer：必须回答的问题列表
- source_rules：来源要求（官方、论文、行业报告、媒体、访谈等）

步骤：
1. 把 topic 改写成 3-5 个可检索问题。
2. 建立来源分层：一手来源、二手分析、观点材料。
3. 提取事实，单独标注出处和时间。
4. 从事实中推导结论，明确哪些是推断。
5. 对关键结论做反向验证：有没有相反证据？有没有样本偏差？
6. 输出报告：摘要、事实表、判断、建议、未知项。

验收：
- 事实、推断、建议三者分离。
- 每个核心结论至少有来源支撑。
- 明确写出不确定性，而不是假装全知。
- 能支持一个具体动作：做 / 不做 / 延后 / 继续验证。

失败处理：
- 来源不足 → 降低结论强度，不强行下判断。
- 来源冲突 → 列出冲突原因和可信度排序。
- 问题太大 → 先切分范围，不直接开写。

资料调研工作流一旦稳定，就可以服务很多场景：产品选题、竞品分析、行业报告、销售材料、课程内容、决策备忘。它的复利点不只是报告本身，而是每次调研都会沉淀问题库、来源库、判断框架和表达模板。

步骤三：把「文章成书」变成工作流

文章成书不是把文章复制到一个目录里，而是把零散内容重构成连续论证。工作流化后，它可以从一次写作项目变成长期内容资产生产线。

text

工作流名称：Article To Book Workflow

输入：
- theme：书的主题
- reader：目标读者
- promise：读完后读者能获得什么能力
- source_articles：已有文章列表
- chapter_map：章节地图
- style_rules：语气、结构、术语、禁用项
- acceptance：每章验收标准

步骤：
1. 提炼全书主线：问题 → 方法 → 实战 → 案例 → 系统化。
2. 建立章节地图，确认每章在主线中的功能。
3. 把已有文章归类：可直接改写、需合并、需重写、应删除。
4. 为每章写骨架：结论、概念、原理、实战、失败边界、小结。
5. 分章生成初稿，保持术语和结构一致。
6. 全书一致性审校：概念、导航、例子、风格、重复内容。
7. 发布前验收：目录、链接、格式、字数、读者路径。

验收：
- 每章都服务全书主线，不是独立博客拼盘。
- 每章都有可执行清单和失败边界。
- 术语前后一致，章节之间能互相引用。
- 读者读完能执行一套方法，而不是只获得观点。

失败处理：
- 章节重复 → 合并或删减，不为凑篇幅保留。
- 主线断裂 → 回到 chapter_map，不直接补文字。
- 风格漂移 → 用 style_rules 重写，不靠后期润色糊住。

这个场景本质上是把内容资产和工作流资产叠加。文章是素材，成书工作流是加工系统，书是复利资产。你真正要沉淀的不是某一本书，而是「从主题到成书」的生产能力。

步骤四：为自己的工作流建立规格卡

无论你处理什么任务，都可以用下面这张规格卡收口。

text

工作流规格卡

名称：____________________________
任务类型：一次性交付 / 周期任务 / 内容生产 / 技术交付 / 运营动作
触发条件：什么时候启动？________________________________
复用频率：每天 / 每周 / 每月 / 每个项目 / 不确定

输入：
- 必填字段：________________________________
- 可选字段：________________________________
- 禁止输入：________________________________

步骤：
1. ________________________________
2. ________________________________
3. ________________________________
4. ________________________________

工具：
- AI：________________________________
- 本地工具：____________________________
- 外部服务：____________________________
- 人工判断：____________________________

输出：
- 主交付物：____________________________
- 附属材料：____________________________
- 归档位置：____________________________

验收：
- 完整性标准：____________________________
- 正确性标准：____________________________
- 可复用标准：____________________________
- 人审节点：____________________________

失败处理：
- 输入不足时：____________________________
- 工具失败时：____________________________
- 结果不达标时：__________________________
- 需要中止时：____________________________

维护节奏：每次执行后 / 每周 / 每月
下一次改进点：____________________________

验证：一张规格卡写完后，交给另一个 AI 或一个没参与过的人，如果对方能按它产出 70% 以上合格结果，说明它已经是工作流雏形；如果对方完全无法执行，说明你写的只是个人笔记。

失败边界（逐项排查）：

症状	根因	处理
每次执行都要大量解释	输入字段不完整，隐性假设太多	把解释过的话补进规格卡
输出质量忽高忽低	验收标准模糊，AI 自由发挥过多	增加必填输出结构和检查项
工作流没人愿意用	步骤太重，收益不明显	删除低价值步骤，只保留关键节点
自动化后错误更多	手动阶段未稳定，过早自动化	回退到半自动，先跑通 5 次
复用几次后失效	工具、模型或需求变化无人维护	设维护节奏和责任人

11.6 工作流 vs SOP vs Skill vs Agent：分工与选型

这几个概念很容易混在一起。你不需要纠结术语，但必须知道它们的分工，否则会把小问题做重，把大问题做散。

维度	SOP	Workflow	Skill	Agent
中文定位	标准作业程序	可执行工作流	封装能力单元	自主任务执行体
解决问题	人怎么照做	任务怎么跑完	某类动作怎么复用	目标怎么自主推进
自动化程度	低	中	中高	高
适合场景	人工交付、培训	多步骤重复任务	明确、窄范围能力	长链路、不确定任务
风险	变成文档坟场	维护成本上升	能力边界过窄	失控、幻觉、误操作
验收重点	是否照做	是否稳定产出	是否可调用	是否达成目标

决策树：

text

这件事是否会重复？
│
├─ 不会 → 做一次即可，不沉淀
│
└─ 会
   │
   ├─ 主要给人照着做 → 写 SOP
   │
   ├─ 需要多步骤 + 工具协同 → 写 Workflow
   │
   ├─ 是某个窄能力反复调用 → 封装 Skill
   │
   └─ 需要自主拆解和推进 → 设计 Agent

你的默认策略应该是：先 SOP，再 Workflow，再 Skill / Agent。不要一上来就做 Agent。Agent 是高阶形态，不是懒人捷径。没有 SOP 和验收标准的 Agent，只是会跑得更快的混乱。

11.7 失败边界：三种最常见的死法

死法一：过早自动化，把错误固化

症状：你刚做过一次任务，就开始写脚本、做自动化、封装 Agent。结果第二次输入稍微变动，整个流程就崩；你为了修自动化花的时间，比手动做还多。

根因：你把「一次成功」误判为「稳定规律」。一次成功只能证明这次路径可行，不能证明它值得固化。真正的工作流至少要经历几次不同输入，暴露出变量和例外。

对抗策略：采用「3-5-10」规则：手动跑 3 次，半自动跑 5 次，复用 10 次后再考虑深度自动化。没有达到这个阈值前，只写规格卡，不急着写完整系统。

死法二：无验收标准，输出看似很多但不可交付

症状：工作流能生成大量文档、报告、代码、表格，但每次都要你重新判断能不能用。你没有省时间，只是把时间从「生产」转移到了「筛垃圾」。

根因：你只定义了步骤，没有定义验收。AI 最擅长填满空白，如果没有标准，它会用流畅语言掩盖结构缺陷。

对抗策略：先写验收，再写步骤。每个工作流至少包含四类验收：完整性、正确性、可复用性、人审节点。凡是无法验收的输出，宁可不自动生成。

死法三：流程无人维护，资产变债务

症状：你有一堆 SOP、模板、prompt、脚本，但真正要用时总要改半天。旧流程和新现实不匹配，最后你选择从零开始。

根因：工作流没有维护机制。资产不是写出来就自动增值，它需要更新、淘汰、合并、版本化。没人维护的工作流会从资产变成债务。

对抗策略：给每个工作流设三个字段：owner、last_used_at、next_review_at。超过 90 天未使用的工作流，要么归档，要么重写，要么删除出当前工作区。复利资产不是越多越好，而是能被复用的越多越好。

红线边界：不可让渡的决策

是否值得做成工作流：不能交给 AI 决定。AI 可以建议，你决定投入维护成本。
验收标准是什么：必须由你定义。否则工作流会优化错目标。
是否进入产品化：必须结合需求、付费意愿、交付成本判断，不能因为流程顺手就误判为产品机会。
敏感信息处理：任何涉及凭据、客户资料、真实平台细节的工作流，都必须先脱敏、最小权限、可审计。
高风险动作执行：删除、发布、迁移、支付、权限变更等动作，即便自动化也必须保留人审。

11.8 小结 / 核心心法

工作流不是把你变忙的工具，而是把你从重复劳动里赎出来的资产。能复用的流程才是资产，不能验收的自动化只是噪音。

任务、流程、工作流、产品是递进关系：一次性任务消耗时间，流程记录经验，工作流复用能力，产品产生现金流。
工作流显式呼应公式三：一次生产 × N 次复用。它把一次成功交付变成可重复执行的复利资产。
工作流规格必须包含六件事：输入、触发、步骤、工具、验收、失败处理。
先稳定再自动化：手动 3 次、半自动 5 次、复用 10 次，再考虑深度自动化。
验收比生成更重要：没有验收标准，AI 只会制造更多需要你筛选的材料。
维护决定资产寿命：无人维护的工作流会腐烂，最终从资产变债务。
工作流是产品化前哨：一个高频、稳定、可验收的工作流，往往就是未来产品或服务包的雏形。

执行清单（每周自检）：

[ ] 本周有哪些事情重复做了第二次？是否记录为工作流候选？
[ ] 是否把一个重复任务写成了「输入、步骤、工具、验收、失败处理」规格卡？
[ ] 是否有一个工作流完成了至少 3 次手动执行，并沉淀出稳定步骤？
[ ] 是否为已有工作流补上了验收标准，而不是只补 prompt？
[ ] 是否复盘了一个失败工作流，定位是输入、步骤、工具、验收还是维护问题？
[ ] 是否删除或归档了一个长期不用、无人维护的旧流程？
[ ] 是否发现一个工作流具备产品化潜力，并记录它的用户、频率和付费场景？

上一章：第10章 AI 能力编排下一章：第12章知识沉淀系统

第11章 工作流即资产 ​

11.1 结论先行：重复做第二次的事，就应该变成工作流 ​

11.2 工作流是什么：定位、能力与边界 ​

与一次性任务、流程、产品的差异 ​

能做什么 ​

不能做什么（边界） ​

11.3 工作流的原理拆解：把经验变成可执行协议 ​

11.3.1 输入：把「你看着办」改成字段 ​

11.3.2 步骤：把隐性经验拆成不可省略的动作 ​

11.3.3 工具：把 AI 放在正确的位置 ​

11.3.4 验收：没有验收的工作流只是自嗨 ​

11.4 四个心法：把工作流变成资产，而不是文档 ​

心法一：第二次出现，就是资产候选 ​

心法二：先手动稳定，再半自动，再全自动 ​

心法三：工作流规格比 prompt 更重要 ​

心法四：每个工作流都要有维护人 ​

11.5 实战：把三类高频任务变成工作流 ​

步骤一：把「代码审查」变成工作流 ​

步骤二：把「资料调研」变成工作流 ​

步骤三：把「文章成书」变成工作流 ​

步骤四：为自己的工作流建立规格卡 ​

11.6 工作流 vs SOP vs Skill vs Agent：分工与选型 ​

11.7 失败边界：三种最常见的死法 ​

死法一：过早自动化，把错误固化 ​

死法二：无验收标准，输出看似很多但不可交付 ​

死法三：流程无人维护，资产变债务 ​

红线边界：不可让渡的决策 ​

11.8 小结 / 核心心法 ​

第11章工作流即资产

11.1 结论先行：重复做第二次的事，就应该变成工作流

11.2 工作流是什么：定位、能力与边界

与一次性任务、流程、产品的差异

能做什么

不能做什么（边界）

11.3 工作流的原理拆解：把经验变成可执行协议

11.3.1 输入：把「你看着办」改成字段

11.3.2 步骤：把隐性经验拆成不可省略的动作

11.3.3 工具：把 AI 放在正确的位置

11.3.4 验收：没有验收的工作流只是自嗨

11.4 四个心法：把工作流变成资产，而不是文档

心法一：第二次出现，就是资产候选

心法二：先手动稳定，再半自动，再全自动

心法三：工作流规格比 prompt 更重要

心法四：每个工作流都要有维护人

11.5 实战：把三类高频任务变成工作流

步骤一：把「代码审查」变成工作流

步骤二：把「资料调研」变成工作流

步骤三：把「文章成书」变成工作流

步骤四：为自己的工作流建立规格卡

11.6 工作流 vs SOP vs Skill vs Agent：分工与选型

11.7 失败边界：三种最常见的死法

死法一：过早自动化，把错误固化

死法二：无验收标准，输出看似很多但不可交付

死法三：流程无人维护，资产变债务

红线边界：不可让渡的决策

11.8 小结 / 核心心法