第 6 章 智能体产品的研发周期

把一名智能体员工从一句话的想法，做成三家门店天天在用的产品，从头到尾要经过哪几站，每一站产品经理干什么、交出什么，是本章回答的问题。这个问题值得专门一章，不在周期本身有多深奥，而在它管着此后的阅读，本书从下一章起还有十二章，每一章都挂在这条周期的某一段上，读到形态选型，那件事发生在需求定义那一段，读到放量决策，它站在上线那一段，读到任何一章找不到位置，回这一章定位。

本章分六节。6.1 把六阶段连成一张图；6.2 逐站清点产品经理的产出物；6.3 讲智能体周期与传统周期的三大差异；6.4 讲周期的节奏与里程碑怎么排；6.5 请案例线把六阶段从头走一遍；6.6 收拢一根贯穿全书的决策链。案例线照常跟进，本章它不当主角，只做每一站的参照。章末自查一句，拿手头任何一个项目，能指出它站在哪一站、下一站的产出物备齐了没有，这一章就过关了。

6.1 研发周期的六个阶段

传统产品的研发周期，产品经理走过不止一遍，需求定义、设计开发、测试、发布、维护，五段排开；走瀑布还是走敏捷，差别在走法，不在站点。智能体产品的周期长什么样？市面上有两种极端说法，一种说没什么两样，照老流程走就行，另一种说天翻地覆，过去的经验全部作废。两种都不对。工程界真把 AI 应用和传统软件的开发流程摆在一起对过表，结论是两边重叠远大于差异，绝大多数工作量仍是软件工程的活，但每个阶段都多出一块 AI 特有的东西，而多出来的那块，样样都要产品经理拍板。骨架没换，换的是每个站点上的重心。

本书把这条周期画成六站。

第一站，需求定义。把业务诉求拆成四样东西，能力清单，它要会干什么；决策点，哪些环节交给它判断、哪些写死在流程里；验收标准，做到什么程度算好；还有产品形态，做成对话窗、嵌进现有工具，还是在后台自动跑。第 7、8 章正面讲。出门的标志，是一份写清验收标准的产品定义。

第二站，PoC 验证。PoC（Proof of Concept，概念验证），拿最小的成本回答一个问题，这个活，模型干得动吗。两个提示词、一份真数据、一个简陋的壳，一个周末的量级。它的目的不在做产品，在花小钱买一个“干得动还是干不动”的结论。7.6 讲最小路径。出门的标志，是一份 PoC 报告。

第三站，开发协作。产品经理和工程一起把演示稿做成产品。这一段设计议题最密，信任怎么建、错了怎么兜，第 9、10 章正面讲的两件事都发生在这里；用哪几档模型、怎么组合，是这一站的架构决策，第 13 章的材料也用在这一站；写给模型的提示词，从这一站起在产品和工程之间共管。这一站产品经理不是旁观者，提示词的产品语义一半归产品经理管，工具说明是写给模型看的产品文档，这两样第 5 章都立过。节拍是双周迭代。出门的标志，是一个过了内部评测、够资格进验收的版本。

第四站，评测验收。拿一批固定任务测试它，按通过率说话。任务集、裁判、指标、验收门四件事，第 11 章整章展开。出门的标志，是过验收门、拿到上线资格。

第五站，上线放量。上线要分三步走，影子、试点、放量，每步一道门，第 15 章正面讲。这三步把一次上线拆成三次可退的机会。一份产出的成本核算（第 12 章）、哪类动作绝不放行的硬线（第 14 章），都在门上兑现。出门的标志，是一页放量决策。

第六站，运营迭代。上线之后的长跑，度量结果、盯它每天在干什么、坏案例回流、换模型、往更多门店推（第 15 到 17 章）。它的产出回流成下一轮需求定义的原料。

图 6-1 里有两处要看仔细。一处是箭头闭成了环。第六站的出口接着第一站的入口，运营期攒下的坏案例和新诉求，正是下一轮需求定义的素材。把图画成环不是为了好看，它画的正是这类产品的真实形状，说的就是“上线不是终点”这六个字，6.3 会展开成一条正式差异。

另一处是站与站之间没有密封的墙。评测不是第四站才开始，评测计划在第一站就要起草，案例线里当测试题用的二十六份历史周报，是立项第一周就攒得起来的现成材料，第四站只是它评分的时点。提示词从第二站写起，一直活到第六站。六站是重心的移动，不是六个格子，把“这一站只干这个”读死，周期就成了换皮的瀑布。

六站与熟悉的五段对得上号，对一遍就不陌生。需求定义，对应老周期的需求加一部分设计；PoC 验证是新增的一站，传统产品用不着它，功能行不行，写出来就知道，智能体行不行，得让模型先跑跑看；开发协作对应设计开发；评测验收对应测试，内容却加宽加重，从查错变成量能力；上线放量对应发布，从一个动作拉成三步；运营迭代对应维护，从修缺陷的被动活，变成回流数据、主动经营的活。骨架与次序都认得出，产品经理手上的活却不一样了，最看得见的变化，是每站交出的东西。

6.2 各阶段的产品经理产出物

产品经理在哪一站干什么，最实的回答不在岗位职责，在交出什么。周期走得快慢不看日历，看东西齐没齐，产出物清单，就是责任清单。先上总表，再逐样说透。

阶段	PM 交出什么	这份东西给谁用	交不出来的后果
需求定义	需求文档与验收标准	研发接需求，业务方对预期	模糊验收，最常见的项目失败原因之一
PoC 验证	PoC 报告	拍板投不投研发的人	演示好看，投钱后才发现干不动
开发协作	迭代优先级	研发的双周排期	修什么全凭嗓门，要紧的坏案例没人管
评测验收	评测计划	研发执行，业务方认指标	上线没依据，回滚没凭据
上线放量	放量决策	管理层，也是给自己	无保护放大，出了事不知从哪退
运营迭代	复盘	下一轮的自己	数据不回流，产品停在第一版

六样东西，有四样是智能体周期里新加重的，挨样说。

需求文档与验收标准，重就重在后一半。传统需求文档写功能清单，智能体的需求定义还要把“做得好”写成可检查的判据，周报初稿“可用”，什么叫可用，是每条归因都带证据链，还是小周十分钟内能改完？判据写不清楚，研发只能按自己的理解做，验收那天变成吵架。7.4 立方法，这里先立地位，这份东西定不下，后面每一站都不稳。

PoC 报告是对演示下的结论，说的不止演示本身，三段话，干得动吗，能力上够不够；离能用差多远，差距一条条列出来；下一步建议，投研发、改方向还是停止。写给拍板的人看。要替他把一个坑指出来，演示挑的是最顺的三个案例，上线测试的是没见过的一百个，两件事中间隔着一条沟，PoC 报告的职责就是把这条沟量出来。这条沟叫 demo 效应，7.6 展开。

迭代优先级是开发协作期每两周都要重新交的一份东西。双周迭代每轮都要回答，这轮修哪三个，不修哪两个。依据是坏案例的分诊，哪些归提示词、哪些归工具、哪些归需求本身，11.6 专讲这场会怎么开。要害在“不修什么”，智能体的坏案例修不完，排优先级才是产品决策；不排，研发就顺手修喊得最响的那个。

评测计划先立四件，任务集从哪来、裁判是谁、指标定什么、门划在多少分。第 11 章整章讲怎么填。它是六样产出物里最像资产的一份，任务集攒起来就不贬值，日常迭代靠它，换模型也靠它，第 13 章讲的换型安全，保底的就是它。

放量决策是一页纸，四个空。数字，连续几轮评测通过率过没过线；成本，一份产出的全成本算不算得平，算法在第 12 章；线，哪类结论绝不自动发出，硬线在第 14 章画；退路，出了事怎么降档、怎么回滚。四空填齐才放大，缺一空，上线就没有保护。

复盘的产物是下一轮的输入，算不上总结文章。运营期每周的坏案例归因，回流进评测集变成新的测试题，测试题催生下一轮的迭代优先级，15.4 管这个循环叫数据回流飞轮。飞轮转不转，决定产品是活的，还是停在第一版。

六样东西之间还有一条接力线，比单看每样更要紧。需求定义立下的判据，就是评测验收的测试题；评测跑出来的指标，就是放量决策要填的数字；放量后的线上抽检，就是复盘的原料。上游含糊，下游直接受损。判据写得含糊，任务集就出不了好题，通过率跟着变成没意义的数，到放量决策那里，就只能凭感觉拍板。这条线也是自查的路子，项目卡住了，顺着线往上游找，病根多半不在卡住的那一站。

还有一层共性，越往后，产出物越不是写给别人看的，越是拿来做决定的。文档可以应付，测试应付不了，分数会说话。传统周期里产品经理最重的产出物是文档；这条周期里，验收标准、评测计划、放量决策三样合起来是一套测试，出题、评分、定去留。第 3 章讲角色变化，说产品经理从功能定义转向能力定义、从确定性交付转向不确定性管理，在周期上，就是这个从写文档到出题评分的样子。

6.3 与传统产品研发的三大差异

智能体周期与传统周期有三处根本不同，验收方式、上线含义、需求与实现的关系。前两条的来源就是第 3 章三大特殊性里的前两条，概率性行为与持续进化在研发流程上的样子；第三条是智能体产品特有的结构变化。

差异一，验收从一次通过，变成按比例通过。传统软件的测试非对即错，这个按钮点了跳不跳转，跳了就过，今天过明天还过。智能体不行，第 3 章讲过概率性行为是它的固有特性，同一份任务跑两次，可能一次好一次坏。拿案例线看得更具体，同一周的三家店数据，周一交给周报帮手跑一遍，再跑一遍，两份初稿的归因可能一处说到了点子上、一处偏到天气头上，单看哪一份都定不了性。能定性的只有一批，一个月、二十几份初稿，对了多少。于是验收对象整个换了，从“这个功能对不对”，换成“一批任务里对多少”。没有一批固定任务、一套统一判分，也就是第 5 章词汇表里见过的评测集，验收就没法做。还有一层要顺带交代，这个比例不是测一次就定终身，同一版系统跑两轮，分数自己都会晃，判断一次改动到底有没有效，得拿多轮的均值连同波动一起看，这门方法第 11 章讲，这里先把“按比例验收”的观念立住。

没有评测集的迭代长什么样，姊妹卷开头有个故事，放到产品经理身上同样成立。一个上线两个月的智能体，团队改了三处提示词，每处都有说得通的理由；一周后质量掉下来，没人知道是哪处惹的祸，只能整体回滚，两处可能有益的改动陪着一处坏的一起下线。改动是好是坏，没有数字能说明白，于是每次迭代都在赌。评测集补的就是这块数字。

差异二，上线从完工，变成开始盯。传统产品发版那天定型，不改代码，行为不变，上线即完工。智能体的行为会漂，供应商给底层模型换了版、知识库的数据源改了口径、用户的问法变了花样，产品行为跟着变，团队常常最后一个知道。第 3 章讲持续进化时点过，连“版本”这个词的含义都跟着变了，传统软件改版本要发版、要公告；智能体的行为变了，可能只是供应商更新了底层模型，没人按过发布键，产品团队自己都是后知后觉的那个。那里还给过一个反向剧本，上线时人人夸，几个月后口碑悄悄下滑，一查日志，源头是一次没人察觉的数据源变更。所以上线那天的正确做法是开始盯，庆功还早。度量看板管结果好不好，可观测管它每天在干什么，两块都得在上线前装好，15.2、15.3 展开。第 13 章讲的换模型，是漂移里最突然的一种，换型等于换产品行为，兜底的还是那套评测集。

差异三，需求与实现之间，多了提示词层。传统产品从需求到实现隔一层代码，改产品就是改代码，改代码要走发版。智能体产品的行为有相当一块写在提示词里。第 2 章 2.2 立过的认识在这里兑现成流程差异，提示词是产品逻辑的一部分，不是研发的私有财产；改十行提示词，产品就变了，连版都不用发。案例线里就会演到这一幕，业务方说一句“归因别老提天气”，研发改两行提示词重新部署，下一份周报就变了。这个动作的产品分量，与改一个功能入口一样重，却常常连评审都不经过。这个差异的日常后果有三条，2.2 都预告过，提示词当产品资产管，版本和改动理由留痕；改提示词与改功能一样过验收，改前改后各跑一遍评测；谁有权改哪一段，事先说清。在每天的协作里，这些就是 11.6 的主题。

三条合起来，改写了一个词，就是完工。传统产品有完工那一刻，智能体产品没有，只有“当前这版稳不稳”。这是这类产品的日常，本书后面十二章，说到底都在教产品经理怎么与这个日常相处。

6.4 周期的节奏与里程碑

周期不是匀速的，各站有自己的节拍，三样最要紧，双周迭代、影子期、放量门，节拍踩准了，里程碑自然立在门口。

双周迭代，是开发协作期的节拍。为什么是双周不是双月，坏案例回流、分诊、修复、回归，一轮走完两周正合适；再长，坏案例攒成堆，一轮改不动；再短，一轮改不出名堂。这个节奏还有个副产品，它给了业务方一个稳定的预期，每两周能看见一次变化，比“快搞好了”这类话好交代得多。节奏之外还有一条纪律，从工程侧借来，产品侧同样管用，一次进一处。几处改动捆着上，出了问题分不清谁惹的祸；一处一进，惹祸的当天现形。配套的还有改动的阶梯，先改提示词里的一个词，不行再改一句话，再补一节，然后才轮到动工具、换模型。顺序从最小往最大走，与人的直觉正好相反，直觉总想重写一整段。

影子期，是评测验收与上线之间的过渡带。做法叫影子运行（shadow mode），智能体在真实环境里跑真任务，产出只给内部人看，不触达任何真用户。它跑它的周报，小周照常写他的，周一早上两份摆在一起对，这就是影子期的每周测试。影子期多长看用例，只读的问答，一两周摸得出底；带写操作、动钱动数据的，以月计。案例线的周报产品影子了两周，15.6 有全程决策记录。

放量门，是上线的节拍。上线要过三道门。影子门，评测通过率连续过线，拿到见真用户的资格。试点门，真用户真数据，小范围，看点从“能不能”换成“用不用”，真实用户采纳不采纳、人审驳回多不多、一单成本多少，三个数都在试点里现形。放量门，成本算平、硬线画死、回退演练过，三样齐了才放大。放权的依据是数字，不是胆量，连续几轮评测稳定过线、线上抽检驳回率压在低位，这类数字构成门槛。具体数值各产品自定，但“拿数字说话”这个形式没有商量的余地。跳档的诱惑不外乎三条，demo 惊艳、业务在催、领导拍了板，三条没有一条够格当放权依据。第 15 章把三步路线正面展开。

深挖指路：影子起步、分档放权的完整工程制度（从影子运行到域内全自主的五档阶梯、放权依据的三类数字、一票降档的回退配置），《悟道智能体开发》第 15 章有工程版展开，本章取其产品含义。

多长的周期算健康？按用例的风险分档，量级列在下面，数字是示意，不是承诺。

用例档	例子	影子期	从立项到可用
低风险，只读或纯内部	内部知识问答、文档摘要	一两周	以月计
中风险，生成内容带人审	周报初稿、归因建议	两周上下	一个季度上下
高风险，写操作直接落地	自动下单、改数据、对外发送	以月计	以半年计，放量逐个动作放

档位之外还有一层，产品类型也改节奏。从零造一个新产品，需求定义和 PoC 占的分量重；往现有产品里加智能体能力，重心后移到上线与运营。健康周期的判据不在快，在每道门前手里有没有数字。

最后防两种病，它们是同一根病根的两种发作。一种叫评测瘫痪，评测做不到完美就不发布，钱和时间全耗在这上面；可评测再完善，也保证不了真实用户要什么，这只有发布了才知道。另一种是无保护上线，评测没搭就放全量，出了事连坏在哪都说不清。正路在中间，把发布做小，先放一小圈人，第一批反馈到手，回头把评测补扎实，再走下一轮。发布在这类产品里是又一步验证，谈不上终点，也谈不上赌博。

6.5 案例线的周期对照

案例线把六阶段从头走一遍，这一节是导航章的实例版，后面各章的案例站共十二站，一站一站全在图上。先把前情对一遍，第 4 章 4.6 的判断结论是，这套诉求值得做，形态要分层，取数拼表走固定自动化，归因初稿和店长问答交给智能体；第一单选周报归因，发出前留小周核对那道关口；店长问答排第二；管理层那一环被动收结果，不自动化。判断站在周期之外。三把尺子、选项阶梯、任务画像、粗算、漏斗矩阵这五件工具，干的活是决定要不要进周期，判断不过关，六阶段一步都不用走。这就是周期图从需求定义起笔、而第 4 章排在它前面的原因。

进周期之后，时点表如下。数字全为示意，档位依据见 6.4。

阶段	时点（示意）	案例线在这一站的事	对应章
需求定义	立项头两周	三张报表的诉求翻成能力清单与验收标准，“周报初稿可用率”“归因方向正确率”怎么立（7.5）；三种形态怎么切：店长嵌入式问答、小周后台周报加对话窗深挖、管理层零门面（不给管理层另做界面，8.5）	第 7、8 章
PoC 验证	第 3 周的一个周末	两个提示词、一份门店真数据、一个低代码壳，周一给老板看（7.7）	7.6、7.7
开发协作	约两个月，四个双周迭代	信任三件套：结论附证据链接、拿不准的分级标注、人工核对入口（9.5）；归因错了的纠错回路（10.5）；主力、廉价、嵌入三档模型组合（13.5）	第 9、10、13 章
评测验收	第 10 到 12 周	二十六份历史周报当任务集、裁判怎么当、双周迭代怎么跑（11.5）	第 11 章
上线放量	第 13 周起的第一个季度	放量门前算清一份周报的全成本（12.5）；财务合规结论的人审硬线画死（14.5）；影子两周、试点一月、放量一月（15.6）	第 12、14、15 章
运营迭代	第二个季度起	三个门店到全区的推广（16.5）；定价、续费、扩展场景的商业答卷（17.5，案例线收尾）	第 16、17 章

表里有四处值得多看。价值从哪来，先立住，小周每周归因要花一个半工作日，拉数对数占大半天，写稿写到晚上八九点，这个数是需求定义里算价值用的，口径第 4 章立下，细算第 12 章展开。评测站不是从天上掉下来的，二十六份历史周报，立项第一天就躺在收银后台里，任务集的第一批测试题第一周就能开攒，第四站只是评分的时点，攒题从第一站就开始，这就是 6.1 说“站与站没有密封的墙”在案例里的样子。章与站不锁死，第 13 章的模型组合定在开发协作那一段，三档模型是开发期的架构决策，但第 13 章讲的换型风险，一直活到运营期，每章的知识不锁死在它的案例站那一周。直线是教学的裁剪，真实的周期会回头，评测发现归因方向判得偏，回需求定义改决策点，改完再回来；影子期发现有的错拦不下来，回开发协作补剧本，图上只画主干，回头的那几笔，15.6 的决策记录里一笔笔都在。

这张表的用法就一句，后面读到任何一站，回来对一眼它站在哪，上一站交了什么给它，下一站在等它什么。十二站读完，这家茶饮连锁就从“老陈十一点半才锁门”走到了全区推广，从立项到收尾大半年。这是一个智能体产品完整一生的第一轮，环还会转下去。

6.6 贯穿全书的产品方法论

六阶段是一根时间轴，先做什么，后做什么。还有一根轴与它交叉，是决策链。不管站在哪一站，产品经理脑子里转的是五个问题，一环扣一环，判断值不值，定义成什么，设计怎么兜，验证好不好，经营活不活。五步挨个过，每步三件事，这一问在问什么，书里哪些章答它，做错的代价是什么。

第一步，判断值不值。第 4 章的全部内容都在答它，三把尺子量价值，选项阶梯挡滥用，任务画像验匹配，粗算看划算，漏斗矩阵排先后。做错的代价是，不值当的需求进了周期，后面每一站都在为它付钱，评测集要建，兜底要设计，放量要盯，全套做下来，越认真亏得越多。智能体需求判断不过关的代价，与传统需求不一样，浪费的不只是几周开发，还有背上之后甩不掉的验证与运营负担。

第二步，定义成什么。第 7、8 章答它，任务故事、能力清单、决策点、验收标准、形态与分工。做错的代价是模糊验收，研发按自己的理解做，上线那天谁也说不清“好”长什么样，产品败在“其实没那么差”上。7.4 那句话，在这里变成一句警告，模糊验收是智能体项目最常见的失败原因之一。

第三步，设计怎么兜。第 9、10 章答它，信任与透明怎么建，期望怎么管，失败分几类，兜底剧本怎么写。做错的代价是，第一次当众出错没有剧本。智能体必出错，这是常态不是事故；出错那一刻用户看到的是设计好的兜底，还是什么保护都没有，决定信任是受一点挫折，还是当场耗光。

第四步，验证好不好。第 11 章答它，任务集、裁判、指标、验收门。做错的代价是双重的，没有评测的迭代是赌博，6.3 那个三处改动整体回滚的故事就是下场；还有一种更隐蔽的失败方式，测试题出偏了，量的是文句通顺，用户要的是内容够长，量错了东西，分数越高，结果越糟。

第五步，经营活不活。第 12 到 17 章一起答它，成本、供应商、安全、放量、组织、商业。做错的代价最常见有两种。一种是钱上的，单位成本失控，越放量越亏；一种是组织上的，试点成功，推广卡壳，产品永远停在三个门店。产品活不活，一半在产品外。

五步和六阶段的关系要说破，不然容易当成同一件事换了个说法。判断值不值，大半发生在周期开始之前；经营活不活，从需求定义一直活到永远；中间三步与中间四站犬牙交错，设计怎么兜集中在开发协作，验证好不好从评测一直贯到放量。拿两个坐标看这个用法，第 10 章的失败兜底，时间轴上排在开发协作那一段，决策链上属于设计怎么兜；第 15 章的上线三步，时间轴上是第五站，决策链上验证好不好与经营活不活各占一半。时间轴说的是此刻在哪儿，决策链说的是此刻在问什么。这套问法平时也用得上，评审会上的方案讨论容易跑题，跑题的样子多半是两步之间串了门，需求还没定义清就在争兜底细节，验证还没做完就在谈商业模式。先问清今天讨论的是哪一步的问题，再往下谈，会就开得顺。后面十二章，每一章都能在这两根轴上找到坐标。

两根轴管导航，六个词管概念。全书反复用的就是这六个词，把它们的关系理成一张图，与两根轴放在一起。

第一部分到这里收官。六章攒下的判断力分三层，第 1、2 章给名词和模型的底子，第 3、4 章给产品逻辑与判断的手艺，第 5 章给智能体的机制；本章把它们连成一份全程框架。下一部分讲怎么设计，第 7 章从第一站开工，把三张报表的诉求，翻译成一份带验收标准的产品定义。

本章小结

• 6.1 六阶段。需求定义、PoC 验证、开发协作、评测验收、上线放量、运营迭代连成一张环，骨架与传统五段相认，重心不同；站与站不密封，评测计划在第一站起草，提示词从第二站活到第六站。
• 6.2 产出物清单。需求文档与验收标准（模糊验收是最常见的失败原因之一）、PoC 报告（量出 demo 效应的沟）、迭代优先级（要害在不修什么）、评测计划（最像资产，换型保底）、放量决策（数字、成本、线、退路四空）、复盘（数据回流飞轮的输入）；六样东西连成接力线，越往后越是拿来做决定的。
• 6.3 三大差异。验收从一次通过变按比例通过，要评测集；上线从完工变开始盯，要度量与可观测；需求与实现之间多了提示词层，改提示也是改产品，要版本、验收、权限三样管理。
• 6.4 节奏三件套。双周迭代配一次进一处与最小改动阶梯；影子期（shadow mode）只给内部人看，长短看用例风险；放量门三道（影子、试点、放量），放权依据是数字不是胆量；健康周期按风险分档，判据是每道门前手里有没有数字。
• 6.5 案例线十二站。判断（4.6）站在周期之外；需求定义头两周、PoC 第三周、开发协作约两个月、评测第 10 到 12 周、上线放量第一个季度、运营第二个季度起；章与站不锁死，直线是教学裁剪。
• 6.6 两根轴。六阶段是时间轴，五步是决策链，判断值不值、定义成什么、设计怎么兜、验证好不好、经营活不活；时间轴说此刻在哪儿，决策链说此刻在问什么，十八章都在两轴上，读任何一章找不到位置，回这一章。

试一试

1. 拿手头一个项目对照六阶段，标出它现在站在哪一站，再检查下一站要交的产出物备齐了没有。没备齐的那份，就是眼下最该干的活。
2. 三大差异写成自查三问：现在的“验收”怎么做，有评测集吗；上线之后谁盯行为漂移，看哪块看板；提示词改动谁批，改完过不过评测。三问里答不上来的那格，风险最大。
3. 给自己负责的产品画三道门：影子门、试点门、放量门，每道门写一行“过门的数字是什么”。写不出数字的那道门，就是以后出事的那道。
4. 找一个死掉或在挣扎的智能体项目，听说的也行，对着五步决策链找它失败在哪一步；再往前推一步：它的前一步，本可以怎么拦。

参考资料

• 《Building AI-Powered Products》（Marily Nika，O'Reilly 2025）第 2 章 The AI Product Development Lifecycle（AI 产品开发生命周期五阶段：创意、机会评估、概念与原型、测试与分析、发布；生命周期迭代往复，各阶段时长随产品类型而变，从零造新产品与在现有产品上增强各站配重不同；发布不是旅程的终点，而是真实应用与持续演化的开始；测试分析阶段收在放行或不放行的决策上：本章 6.1 六阶段合并自铸与 6.4 分档节奏的对表来源），见 txt/building-ai-powered-products.txt（英文原文，第 2 章行 2129-3105）
• 《The AI Product Playbook》（Marily Nika、Diego Granados，Wiley 2026）第 4 章 The AI Lifecycle（AI 生命周期逐阶段的 PM 角色：问题定义阶段 PM 主导，其后各阶段各列一条 PM's role：本章 6.2 产出物清单的对表来源之一），见 txt/the-ai-product-playbook.txt（英文原文，第 4 章行 4931 起）
• 《Building AI Agent Platforms》（Ben O'Mahony、Fabian Nonnenmacher，O'Reilly Media 2027 抢先版）第 1 章（AI 应用开发生命周期与传统软件工程互为镜像、重叠远大于差异；测试是与传统软件差异最大的一环，输出开放且非确定，须以评测替代断言式测试；上线后在线评测与漂移监控、完整记录交互历史的最佳实践；反模式：没有评测的盲目开发、因评测难题而分析瘫痪，中间道路是把发布做小：本章 6.1/6.3/6.4 的知识底本），见 txt-ref-zh/building-agent-platforms/01-Chapter-1-AI-Applications-and-Their-Lifecycle.md
• 《悟道智能体开发》（本书工程姊妹卷）第 12 章 评测（评测驱动开发：改三处系统提示无法归因只能整体回滚的开场故事、成功标准先于代码、同一任务多次结果不同故结论只能看整批通过率、一次进一处的最小改动阶梯：本章 6.2 产出物、6.3 差异一、6.4 双周迭代纪律的工程底本），工程深挖按该书对应章指引
• 《悟道智能体开发》第 15 章 人机协同与生产化（渐进自主：从影子运行起步的分档放权制度、放权依据是任务集通过率与线上抽检驳回率这类数字、demo 惊艳/业务在催/领导拍板都不够格当放权依据、事故后一票降档的回退通道：本章 6.4 影子期与放量门的工程底本），工程深挖按该书对应章指引
• Irene Bratsis《AI 产品经理》（中译）2.1/6.1（新产品开发 NPD 七阶段与 AI 产品开发四阶段的流程对照：6.1 六阶段合并自铸的目录级旁证），目录级支撑，见 参考资料/目录级参考索引.md