第 8 章从单点到工作流：让 AI 嵌进真实流程

上一章结尾，我们停在一抽屉打磨好的零件上。一个个 Skill，各自能干一件事，干得又快又稳，随叫随到。但零件不会自己变成机器。一颗再精密的齿轮，扔在抽屉里，它就只是一颗齿轮；装进传动结构里，对上别的齿轮，它才开始输出动力。这一章处在第二部「协作」的第四站，解决的就是从零件到机器的那段距离——它也是这条成长线上最像「工程」的一站。

我先把这一章的核心判断立起来，然后用整章去论证它：AI 的价值不在单点，在流程。一个再惊艳的单点 AI，嵌不进真实流程，就永远是个 demo；嵌进去了，配上兜底和可观测，才是产品。demo 和产品之间隔着的，不是技术，是流程、兜底，和你能不能看见它在干什么。

这个判断听上去平淡。它的代价，却具体得很。

我见过太多这样的周五下午。会议室，投影亮着，一个 AI 客服的 demo 正在跑。演示的人挑了一条真实工单贴进去，两秒钟，AI 给出了分类、优先级、一段措辞得体的回复建议。全场安静了一下，然后有人小声说「这也太快了」。老板当场拍板：很好，下个月上线。

五个月后，这个项目还停在「上线前最后一轮验证」。

不是模型不行。模型在 demo 里的表现，五个月后依然惊艳。卡住它的是另一些东西：真实工单里夹着写错的订单号、夹着方言、夹着一句话问三件事的客户；AI 答错了一单，客服主管要求所有输出先过人工审核；加了人工审核，整条链路比原来纯人工还慢；运营想知道它这个月到底答对了多少，发现没人记录，谁也说不清。

demo 五分钟，上线五个月。这不是哪个团队特别笨，这是行业的常态。两边隔着的那段距离，就是这一章要走的路。

一、收藏夹之死

先看一个比客服项目更小、也更普遍的版本。这一次，主角是我自己。

我曾经花两周打磨出一条非常好的 AI 文案 Prompt。输出质量稳定，格式规范，我自己用得飞起，兴冲冲分享给全组。半年后看后台数据：整个组里，还在用的只有我自己。

同事们的反馈出奇一致：「挺好的，但我不会用。」

这句话值得拆开看。「挺好的」是真心话——他们见过输出，质量确实好。「不会用」也是真心话，但它的意思不是「看不懂」，而是三件更具体的事。

一是它没有嵌进既有的工作流。同事写文案的路径是打开文档、看需求单、动笔。要用这条 Prompt，他得额外打开一个对话框，找到那条收藏的指令，把材料一段段贴进去，再把结果一段段贴回来。多出来的每一步，都是一道流失的闸门。人不会为了一个工具改变自己的路径，再好的工具也不会。

二是它没有兜底。AI 十次里有一次会翻车，这本来不算大问题——问题是同事不知道是哪一次。他没参与设计这条 Prompt，分不清「正常发挥」和「一本正经的胡说」，每次都得从头到尾自己核一遍。核一遍的时间跟自己写差不多，那用它干什么？

三是它没有可观测性。用了一段时间，到底省了多少时间、出过几次错、哪类输入容易出问题，没人知道。说不清效果的东西，在任何组织里都活不长。

你看，这条 Prompt 本身没有任何毛病。它死掉的原因，全部在 Prompt 之外。这种死法太常见了，值得有个名字，我叫它「收藏夹之死」：一条好指令，躺在收藏夹里孤零零地老去，杀死它的不是能力不够，而是孤立。

打个比方。一个单点的 AI，哪怕能力再强，在你的工作体系里也只是一个很能干的临时工：没有工位，没有交接单，没有考勤记录。活儿干得漂亮，但上游没人知道什么时候该把材料递给他，下游没人知道他交的东西能不能直接用，出了错也没人知道该找谁。这样的临时工，再能干，组织也用不起来。给他一个工位、一张交接单、一份考勤记录——这就是把单点变成工作流。

上一章我们说，Skill 是螺丝钉。现在可以把后半句补全了：工作流才是机器。你跟一个只会调 Prompt 的人最大的差别，是你知道螺丝钉该装在机器的哪个位置。

二、先看真人怎么干活

那么，机器从哪儿开始搭？

大多数人的第一反应是打开电脑：选模型、写 Prompt、搭框架。这恰恰是最常见的第一步翻车。正确的第一步跟技术毫无关系——去观察一个真人，是怎么把这件事干完的。

斯坦福那堂讲 Agentic Workflow 的课上有个练习，题目很朴素：做一个能处理「我要改订单地址」的客服 AI。教授给的第一步指令不是写代码，是去看真人客服接到这通请求后，手上实际做了什么。这个动作有个正式的名字，叫任务拆解（Task Decomposition）。

为什么第一步不是写代码？因为你一旦先动手写，写进系统的就不是真实的流程，而是你想象中的流程，这两者的差距大到足以毁掉项目。真人客服处理这件事的时候，手上有一连串连他自己都懒得说出口的小动作：他会先瞟一眼订单状态再开口，免得许下做不到的承诺；他会留意到客户嘴里那句「上周买的那个」其实没给订单号，得先追问一句；他改完地址还会顺手补一句「您放心，仓库还没出货」。这些动作不在任何一份操作手册里，全在他的手上和习惯里——那是几年里成千上万通请求压缩出来的边界处理经验。你不去看，就不知道它们存在；你不知道它们存在，你的系统就会在这些地方一个接一个地漏。开头那个客服项目卡住的五个月，本质上就是在用最贵的方式补这一课。

观察怎么做，也有讲究。最好的姿势是坐到真人客服旁边，看完十个真实请求，请他边做边把心里的话说出来：为什么先点这个页面、为什么这句话要换个说法、什么时候他会皱眉。拿不到坐在旁边的机会，就去要十条真实的对话记录，自己从头到尾走一遍。注意，要的是真实记录，不是让对方「描述一下你的流程」——人在总结自己的工作时，会自动抹掉那些最值钱的小动作，因为他自己都不觉得那算步骤。

盯着真人客服看一遍，你会发现「改个地址」这件听起来一句话的事，实际上是五步。

第一步，从客户的话里抽出关键信息：他要干什么、订单号是多少、新地址是哪里。别小看这一步，真实的客户不按表格说话，他说的是「我搬家了，上周下单那个件别寄老地址了行吗」，意图埋在叙述里，订单号压根没出现，新地址要追问才有。把这团自由文本理成三个干净的字段，是整条流程的入口。第二步，拿着订单号去数据库里调出这位客户的订单记录，确认单子真实存在、确实是他本人的。第三步，查公司政策——这一单发货了没有？已经出库的还能不能拦截？生鲜和定制类目是不是另有规矩？真人客服查的是内部知识库，查不到的还会扭头问旁边的老员工。第四步，根据查到的信息起草一封回复：能改的告诉他改好了，不能改的解释清楚为什么、给出替代方案，语气还得接得住客户的情绪。第五步，把邮件发出去。

拆到这个程度，每一步该交给谁就开始清晰了。第一步是从自由文本里抽取信息，这是语言模型的看家本领，交给 LLM，一次就能做对。第二步是查数据库，这是再传统不过的程序调用，写个工具接口就行，跟 AI 没关系。第三步要在一堆政策文档里找到适用条款，交给检索，也就是第 6 章讲过的 RAG。第四步要把冷冰冰的查询结果写成一封有人味的回信，再次交给 LLM。第五步发邮件，调用邮件接口，又是纯程序。

五步里，只有两步真正需要 AI。

每一步该怎么判，标准其实只有一句话：这一步有没有标准答案。订单在不在数据库里，有标准答案，交给程序；这封回信怎么写才接得住客户的火气，没有标准答案，交给模型。判完之后，不妨再做一次反向检查：把标签贴反，会发生什么？第二步要是交给 LLM，让它「凭记忆」报订单信息，它会一本正经地编一个不存在的订单号，语气笃定得让人不忍怀疑。反过来，第四步要是省下 AI、用程序模板拼一封「尊敬的客户，您的请求已处理」，客户读完只会觉得自己在跟一台售票机吵架。错配的代价是双向的：把确定的事交给 AI，你买进了不必要的随机；把模糊的事交给程序，你交出了本来能有的体面。

这就是任务拆解给你的第一份礼物：它逼你看清，一件事的全流程里，哪些步骤是模糊的、需要理解和生成，哪些步骤是确定的、一行代码就能搞定。前者叫模糊的（Fuzzy），后者叫确定的（Deterministic）。给每一步贴上这两个标签，是搭任何 AI 工作流之前必须做完的功课。

你可能觉得这个动作眼熟。没错，它就是第 4 章三层颗粒度的延伸——当时我们把一个模糊的想法拆到字段层，现在我们把一条完整的流程拆到步骤层。拆解这门手艺，从你跟 AI 协作的第一天起就没变过，变的只是拆的对象越来越大。

三、确定的归程序，模糊的归 AI

给每一步贴完标签之后，紧跟着就是落地的第一原则。这条原则朴素到容易被轻视，但它筛掉的翻车项目，比任何高深技术都多：

能用确定性方法解决的问题，就用确定性方法解决；剩下那些真正模糊的部分，交给 AI，并且加上护栏。

举个考试评分的例子。假设你在做一个在线语言考试产品，一套试卷里有选择题和口语题。选择题该怎么判？答案是写死的，A 就是 A，用传统程序算分——又快，又准，又便宜，跑一亿次也不会错一次，考生交卷的那一秒分数就出来了。有人会觉得「我们是 AI 项目，评分当然全交给 AI」，于是让 LLM 去判选择题。结果是花十倍的成本，换一个偶尔会把对题判错的系统，还顺手给每道题加上了几秒的等待。这不叫先进，这叫胡来。

口语题不一样。一段两分钟的开放式口头表达，没有标准答案，传统程序无从下手——你没法用 if-else 判断一个人讲得流不流利。这才是 LLM 该上场的地方：把评分标准写成一张明确的量表，发音、流畅度、内容切题各占多少分，让模型对照量表逐项打分，顺带给出一段评语，告诉考生扣分扣在哪。这是真人考官都未必有耐心做到的颗粒度。

量表怎么写，决定了这件事的成色。写「请给这段口语打分」，模型每次的标准都在漂，今天对口音宽容，明天对停顿苛刻；写成「发音三十分，元音清晰度和重音位置各占一半；流畅度三十分，看每分钟有效词数和卡顿次数；内容切题四十分，看是否回应了题目要求的三个要点」，模型的产出立刻稳下来，评语也从空泛的「表达尚可」变成「第二个要点未展开，扣八分」。你发现没有，这一步的功夫还是第 5 章那件事——把判断标准说清楚。量表写得越像一份给新手考官的培训手册，AI 判得就越像一个老考官。

但注意，它上场的姿势是带着护栏的。AI 评分是概率性的，必然有判得离谱的时候：考生答得切题又流畅，模型却可能因为口音重给出低分。所以系统在设计之初就配了人工申诉通道——学生对分数不服，一键发起复核，真人考官重听一遍录音，改判的以人工为准。申诉数据还有第二重用处：每一次改判都被记录下来，攒上一个季度回头看，你就知道模型在哪类口音、哪类题型上最不可靠，下一版的评分量表该往哪里修。AI 干主力，人工接住它必然会犯的错，被接住的错又反过来校准 AI。这个小小的环，是后面整章兜底思想的缩影。

这套设计还顺手解决了一个运营难题：申诉率本身成了一块免费的仪表盘。申诉率稳定在低位，说明模型大体可信；某次量表改版后申诉率翻倍，不用等季度复盘，当周就知道出了事。成本这边，让我们算一笔账：十万考生的选择题，程序算分的成本约等于零；口语题让 LLM 判一遍，人工只接申诉的那一小撮，总成本不到全人工评卷的十分之一，出分时间从两周缩到一天。确定的归程序，模糊的归 AI，争议的归人，三方各干各的活，这笔账才算得过来。

一边是「能不用 AI 就不用」，一边是「该用 AI 就用足，但备好后手」。这两个动作合在一起，才是成熟的落地姿势。

为什么要这么强调？因为现实中大量团队是反着干的。AI 一上头，恨不得把流程里每一步都换成大模型，连「把日期格式从斜杠改成横杠」这种活都要请 LLM 出马。多花的钱还是小事，真正的代价是你主动放弃了确定性。第 6 章讲过基础模型的脾气：概率性输出，同一个问题，今天说可以，明天说不行。把一个本来一行代码就稳如磐石的环节换成这样的脾气，等于在自家流程里埋雷。

记住这个分配逻辑：确定性的部分是流程的骨架，要硬；AI 负责的部分是关节，要灵活，但每个关节外面都得缠上护栏。骨架越硬，关节越少，整个系统就越稳。

四、从姿势到结构

把这套思路推到头，你会撞上一个更根本的转变。提出它的人是吴恩达，他给这类系统起的名字，后来成了行业通用语：智能体工作流（Agentic Workflow）。

他特意造这个词，是因为「Agent」已经被用滥了——什么东西都敢叫 Agent。他想强调的是另一件事：单个模型再聪明也不是系统，把提示词、外部工具、检索、各种组件组织进一个有结构的流程里，让它们协同把事情做完，这才是真正产生价值的形态。RAG 只是个工具，会主动提问、能调用接口、把任务从头跑到尾的那个整体，才是系统。

而要搭这样的系统，工程心态必须换一次底层操作系统：从确定性工程（Deterministic Engineering），换到模糊工程（Fuzzy Engineering）。

这次切换具体换掉了四样东西。数据，从结构化的表格和字段，变成自由文本、图片、音频。逻辑，传统软件是同样的输入必有同样的输出，智能体工作流是概率的，会随上下文浮动。测试，从「跑一百次结果一致才算过」，变成迭代探索式的测——这一点第 12 章会专门展开。而最关键的是第四样，架构心态。

传统工程师的工作方式，是写下每一行代码，控制系统走过的每一条路径。智能体系统做不到这一点，也不需要做到。这套新心态，用一句话概括就是：像经理一样思考——你给 AI 的是目标和限制，让它自己决定怎么完成。

读到这里你应该会心一笑。这不就是第 2 章讲的老板心智吗？拆解、分派、验收，给目标不给步骤。没错，是同一件事。区别在于，第 2 章它还是一种「姿势」，靠你脑子里的自觉来维持；到了这一章，它变成了「结构」——你把目标写进系统提示，把限制写成规则和护栏，把验收做成检查节点，整套管理动作固化进一条流程里，从此不依赖你时刻在场。

老板心智的最高形态，不是你管得多紧，而是你把管理本身做成了系统。

五、三根支柱

说了这么多原则，落到纸面上，一条 AI 工作流到底长什么样？

骨架只有三根支柱。第一根，业务流程：这个 AI 节点的上游是谁、下游是谁、什么时候被触发。第二根，AI 节点：你精心设计的那条 Prompt，在流程的哪一步起作用。第三根，兜底机制：AI 失败的时候，整条流程怎么办。

三根支柱，缺一根都站不住。只有 AI 节点没有业务流程，就是那条死在收藏夹里的 Prompt；有流程没兜底，就是那个五个月上不了线的客服项目。

来看一个最简单的实例，简单到只有三个节点：用户提交反馈表单，AI 自动分类打标，然后按标签路由给对应的处理团队。产品问题进产品组的队列，账单问题进财务组的队列，愤怒等级高的直接置顶。

第一版，裸跑。表单进来，AI 打标，路由出去。demo 一跑，漂亮得很。但你现在已经知道该问什么了：AI 打错标怎么办？一条愤怒的投诉被错分到「功能建议」，在队列里躺三天，会发生什么？

于是有了第二版，加上兜底层。AI 对自己的判断给出置信度，低于阈值的不路由，转人工分类；模型接口超时，自动退回旧的关键词匹配规则，流程不断；每个接收团队的界面上有个一键改标的按钮，发现分错了，顺手就能纠正。

第三版，再加可观测层。每一条流过的反馈，都留下记录：原始输入是什么、AI 打了什么标、置信度多少、有没有被人工改过。从此这条流程不再是黑箱——哪类输入容易出错、准确率是在变好还是变坏、人工兜底被触发的频率高不高，全都查得到。

三个版本摆在一起，你能清楚地看见一条 Prompt 是怎么一步步长成产品的。第一版人人会做，那是 demo；第二版开始有了工程的样子；第三版才敢真的接进业务。而从第一版到第三版，AI 本身一个字没改——所有的进化都发生在它周围。

六、四道闸与观测口

三根支柱里，最值得单独拎出来讲透的是兜底。因为它是大多数人设计里最薄的一环，也是上线评审时第一个被挑战的环节。

兜底不是一句「出错转人工」就能打发的。成熟的兜底是一套组合，我把它叫做兜底四件套。如果你还记得第 4 章字段层里「失败兜底」那一栏，没错，就是它——当时它是 PRD 里的几行字，现在它要从纸面上站起来，长成系统里的四道闸。四道闸各守一段：第一道拦在事前，第二道接在事中，第三道补在事后，第四道把所有漏过的错收拢起来，变成下一版的肥料。

阈值兜底。让 AI 对自己的每次输出报一个置信度，低于阈值就不许它落子。工单分类里，置信度低于 80% 的不写入结果，直接转人工。这是第一道闸，拦的是 AI「自己都没把握」的输出。

这道闸最常见的死法，是阈值拍脑袋。有人图稳妥定 99%，结果九成输出都被拦下转人工，AI 等于白请；有人嫌麻烦定 50%，闸门形同虚设，错的对的一起放行。阈值不该是拍出来的，该是测出来的：拿两百条标注好的历史数据让 AI 跑一遍，把置信度和实际对错摆在一起看，你会找到一个点——高于它，准确率你能接受；低于它，错误开始扎堆。那个点就是你的初始阈值。留意「初始」两个字，上线后用户的输入会变，阈值要跟着数据调，定完就忘的阈值，三个月后就是个摆设。

规则兜底。AI 失败或超时的时候，流程退回到原有的确定性规则。接口挂了，关键词匹配顶上。新系统再好，旧系统先别拆——它是你的备用发电机。这道闸保的是流程不断：AI 可以错，业务不能停。

反例我在不止一个项目里见过：团队对新系统信心爆棚，上线当天就把旧的关键词规则停了服。两周后模型接口抖了一个小时，整条客服链路跟着瘫了一个小时；要是旧规则还活着，这一小时不过是回复质量差了点。设置上还有一招比「失败了再退回」更稳的，叫白名单：有些输入压根不该让 AI 碰，提前用规则拦在门外。涉及资金的、提到法务的、命中敏感词的，直接走固定流程或人工，AI 连看都不看。这不是不信任它，是这些地方错一次的代价，抵得上它答对一千次的功劳。

人工兜底。转人工的入口必须明显、必须一步可达。AI 分错了，客服一个按钮就能纠正，而不是填表申请、走三层审批。这道闸接的是前两道都没拦住的漏网之鱼，它的设计标准只有一条：让发现错误的那个人，能在一秒钟内把错误改掉。

反例是某种你一定亲身遇过的客服机器人：你说「转人工」，它回「请描述您的问题，我来帮您」；你再说一遍，它给你列出五条不相干的常见问题。用户的耐心在第二轮就烧完了。转接时机也不能只盯着置信度，因为置信度量的是 AI 自己的把握，量不出用户的情绪。成熟的设计会多埋几条触发线：用户第二次表达不满，转；同一个问题来回绕了三轮没解决，转；对话里出现「投诉」「曝光」这类词，立刻转。还有一个常被漏掉的细节——转过去的时候，把前面的对话一并带过去。让用户对着真人把刚才的话重讲一遍，等于把 AI 省下的时间又原样还了回去。

数据兜底。所有被纠正的错误案例，自动收集起来，定期回流——喂给测试集，喂给下一版 Prompt。这道闸跟前三道气质不同：前三道在止损，这一道在增值。每一次翻车都变成系统变好的养料，错误从成本变成了资产。

这道闸的反例最隐蔽，因为出事的当下你看不见：纠正按钮做了，客服也天天在点，但点完的数据没人存。三个月后团队想优化模型，回头一看，几千次宝贵的人工纠正全部蒸发，想分析都无从下手。所以设置的关键是先想清楚记什么。一条合格的纠错记录至少五个字段：原始输入、AI 的输出、人工改成了什么、谁改的、什么时候改的。再定一个回流节奏：每月把纠错案例整理一遍，错得集中的类型补进 Prompt 的规则，典型案例放进测试集，下个版本上线前先过这一关。记录本身近乎免费，回流才让它值钱。

四件套备齐，你才能回答上线评审会上那个必然出现的问题：「它出错了怎么办？」答不上这个问题的方案，工程师不敢接，老板不敢批，用户用一次就不会再用第二次。

四件套之外，还有一件事要在设计时就埋进去：可观测。每个节点留痕，每条数据可查。理由很实际——AI 系统跟传统软件最大的不同，是它会无声地变差。用户的输入在变，模型的版本在变，世界本身在变。没有观测，你只能等客户投诉了才知道它早就病了。

落到动作上，最低配置就三样。第一样，日志：每条请求记四个字段，输入是什么、输出是什么、置信度多少、走没走人工。一张表就够，不需要什么平台。第二样，抽检：每周固定抽十几条人工过目，别随机瞎抽，重点照顾两类——置信度贴着阈值的，和被人工改过的，病灶多半藏在这两堆里。第三样，看板：三四个数字摆在一页上，处理量、转人工率、纠正率、平均耗时，每周扫一眼。读数的时候多留个心眼：转人工率突然降了未必是喜讯，可能是置信度算法出了毛病，把没把握的输出也放了行。

至于怎么系统地评估、怎么让数据流转起来推着产品变好，那是第 12 章的主场，这里先把钩子埋下：上线不是终点，是观测的起点。

七、把自己的工作改成产线

讲到这里，所有的例子都是「公司里的项目」。但这一章真正想交给你的，是把同一套方法用回你自己身上——你个人的工作，同样是一条可以改造的流程。

还记得第 2 章那个带队的人吗？他把竞品分析拆成四步，搭了一条产线。当时我们只说了思路，现在你有了全部的零件，可以真的把它造出来了。

按三根支柱来。先定业务流程：每周一早上八点，定时触发，不需要你按任何按钮。再排节点，并且给每一步贴上标签：抓取各家竞品的官网更新、版本日志和新闻稿——确定性的，定时任务加固定来源列表就能做；去重、按时间排序——确定性的，程序处理；给每条更新写摘要、判断「这条值不值得你注意」——模糊的，交给 AI；把值得注意的几条按统一维度整理成一页简报，推送到你手机上——前半步模糊，后半步确定。

然后是兜底四件套的个人版。阈值兜底：AI 把握不足的判断，标上「待核实」，而不是装作笃定。规则兜底：某个来源抓不到了，简报照常生成，但注明「该来源数据截至上周」，绝不拿旧数据冒充新数据。人工兜底：每条结论必须附上原文链接，你随时可以一键穿透到源头去验证。数据兜底：你每次发现的误判，记进一个修正清单，月底统一喂回 Prompt，让下个月的它比这个月聪明。

最后是最低限度的可观测：每周花十分钟，抽查两条它的判断。就这么多。

这条产线搭完，每周一早上你睁眼时，一页竞品简报已经躺在手机里。第 2 章讲四级台阶时说过，第三级「驱动」的标志，是你至少有一条「你睡觉的时候它也在跑」的流程——现在你知道这句话怎么落地了。它不要求你会写代码，今天的自动化平台和 Agent 工具已经把门槛降到了「会拆流程就会搭」；它真正要求的，是你前面几章练出来的全部手艺。

内容创作者可以照这个模子搭选题流水线，从热点抓取到草稿初筛；做招聘的可以搭简历预筛流水线，从邮箱触发到打分入库；做研究的可以搭文献监测流水线，从新论文推送到摘要归档。模子是同一个：拆步骤，贴标签，硬的交给程序，软的交给 AI，缠上四件套，留好观测口。

你的工作里，至少藏着一条这样的产线。找到它，把它造出来。

本章要点清单

AI 的价值不在单点，在流程。嵌进流程、配上兜底、留下观测，是 demo 和产品的分界线。
警惕「收藏夹之死」：杀死一个好工具的，不是能力不够，而是孤立。没有工位、没有交接单、没有考勤记录的单点 AI，是组织用不起来的临时工。
搭工作流的第一步不在电脑上：先看真人怎么把这件事干完。任务拆解，把流程拆到步骤层，给每一步贴上「模糊」或「确定」的标签。
分工标准一句话：这一步有没有标准答案。有，归程序；没有，归 AI；有争议，归人。错配的代价是双向的——把确定的交给 AI，你买进随机；把模糊的交给程序，你交出体面。
能用确定性方法解决的，就用确定性方法解决。确定性是骨架，要硬；AI 是关节，要活，但关节外面缠护栏。骨架越硬，关节越少，系统越稳。
像经理一样思考：给目标和限制，不给步骤。老板心智的最高形态，是把管理本身做成系统。
一条工作流三根支柱：业务流程、AI 节点、兜底机制，缺一根都站不住。
兜底四件套：阈值拦在事前，规则接在事中，人工补在事后，数据把错误变成资产。AI 可以错，业务不能停。
阈值是测出来的，不是拍出来的；定完就忘的阈值，三个月后就是个摆设。
可观测最低配置三样：日志、抽检、看板。上线不是终点，是观测的起点。
你的工作里至少藏着一条产线：拆步骤，贴标签，硬的给程序，软的给 AI，缠上四件套，留好观测口。

小结

回到开头那间会议室。那个卡了五个月的客服项目，后来是怎么活过来的？答案毫无戏剧性：团队回头补课。他们花两周时间坐在真人客服旁边，把每类工单的处理过程一步步记下来——这是任务拆解；把一半原本塞给大模型的步骤，改回了普通程序——这是确定的归程序；给剩下的 AI 节点配齐了四件套，给整条链路加上了日志——这是兜底和可观测。三个月后上线，没有惊艳的发布会，但它稳稳地跑住了。demo 和产品之间那五个月，他们补的不是算法，是流程。

这一章走的就是这条路：先看清单点 AI 为什么活不成产品——收藏夹之死，死因全在 Prompt 之外；再学会搭产线的第一步——去看真人怎么干活，把流程拆到步骤层，贴上模糊与确定的标签；然后是分配原则——确定的归程序，模糊的归 AI，争议的归人；心态上，从写死每条路径的工程师，换成给目标不给步骤的经理，把老板心智从姿势固化成结构；落到纸面，三根支柱立起一条工作流，四道闸接住 AI 必然会犯的错，观测口让你在它无声变差之前就看见；最后，把同一套方法用回你自己的工作，造出一条你睡觉时也在跑的产线。

回头看，从第 4 章到这一章，其实是一条完整的成长线：第 4 章，你学会把模糊的想法拆成可执行的结构；第 5 章，你学会把判断标准写成好指令；第 6 章，你学会让 AI 记得住、靠得住；第 7 章，你学会把重复的劳动封装成零件；这一章，你学会把零件装上流水线，织进真实的流程。拆解、指令、记忆、封装、编排——「带 AI」的基本功，你已经齐了。你不再是那个对着空白对话框敲「帮我」的人，你是一个有方法、有零件、有产线的人。

但基本功齐了之后，一个新的念头早晚会找上你。可能是某条产线跑顺的深夜，可能是同事第三次来借你的 Skill 的下午——你会想：既然我能为自己的工作造流程，那能不能为一个更大的问题，专门造一个东西？造一个别人也能用的产品？这个念头很危险，也很珍贵。危险在于，AI 时代造东西的成本低到诱人，而做出一个没人要的东西，成本再低也是全亏；珍贵在于，它会把你从「带队」引向「造物」，引到一扇门前。推开它之前，有一个问题必须先回答，它决定了你接下来几个月是在创造还是在自嗨：你看中的那个问题，是真问题，还是伪需求？下一章，我们先学会分辨它。