本文描述的系统，在一场企业内部黑客松中以 96/100 的分数获得综合第一，并且已经落实到真实业务场景中。

开篇：你们公司的流程，是怎么烂掉的？

大多数产研团队的需求管理，看起来是这样的：

售前群里发：「王总，那个客户要一个能自动配置话术的功能，很急」 产品回：「好的，记一下」 研发三个月后：「这个需求当时谁提的？客户是谁？验收标准是啥？」 售前：「我也记不清了」

还有另一种情况，同样真实：

测试快收尾了，按流程这时候应该可以发版了。 产品突然说：「这个做的不对。另外我再加一个需求。」

测试本来是收口的那道门。但这道门从来没有真正关上过。

还有第三种：

产品整理了十几条需求，文档写得很完整，进了评审会。 售前说：「这些我们客户没有提过。」 会上没有人反驳。 产品：「……」

一批需求跑完了整个内部立项流程，最后在评审会上被一句话否掉。浪费掉的，是所有人为它花的时间。

问题不在于哪个人不负责任。每个人都在做自己那部分。但边界没有人划清楚，判断没有人拍板记录，信息每传一层就丢一块。等到有人开口问，已经没有人记得清楚了。

我在真实的产研环境里看到这些问题之后，花了几天时间，试着用 AI 解决它。

在动手之前，我翻了一遍当时团队的需求台账，看了看字段填写情况。发现了一件让我意外的事：守门环节的核心字段，填写率极低。大量需求进来的时候，没有「客户是谁」，没有「为什么要做」，没有「做完了怎么算完成」。系统是有的，流程也走了，只是这三个问题，从来没有人回答过。

这不是需求管理系统，这是一个状态看板。这两件事不是一回事。

先说清楚这本白皮书讲什么。

它讲的不是「我做了一个需求管理系统」。需求链只是我用来证明一件事的那条链——因为它足够长、角色足够多、足够容易掉棒。

它真正讲的，是怎么把一段长在人脑子里和群聊里的烂流程，改造成 AI 可以执行的流程。

这套打法本身只有三步，简单到有点让人失望：

1. 找到掉棒的那几个点。 不是开会问大家哪里痛，是去翻记录——看哪个字段从来没人填、哪一次交接之后信息突然变少了。人会美化自己的流程，记录不会。
2. 把每一次交接改写成一张必须点掉的卡。 谁点、点之前必须回答什么、不回答会怎么样，全部写死在卡上。流程不再是一份文档，而是一个不点就过不去的动作。
3. 让 AI 承担填空，让人只承担判断。 AI 把模糊的话结构化成字段、起草初稿、生成可执行的验收步骤；人只做「通过 / 打回 / 改一个字」这类 AI 做不了的决定。

难的从来不是第三步。难的是第一步的眼力和第二步的取舍。

如果你读完之后想起的是自己公司的某一段流程，而不是我的这套系统，那这篇东西就写对了。

第一章：我在那个产研环境里看到了什么

章首结论：问题不是人不负责，是系统根本没设计好。

第一节：我观察到的现象

产研团队里最难受的一种局面，不是有人摆烂，而是每个人都在认真做自己那部分，但事情还是会出问题。

销售在收集需求，产品在写方案，研发在开发，测试在测试——每个人都完成了自己的环节。但当你把一条需求的全程拉出来看，你会发现这些环节从来没有被真正连接起来。

第一种症状，信息在传递中消失。 一个需求从售前进来，到了研发手里，客户是谁、为什么要做、做完了怎么算完成——这些问题的答案通常都不见了。不是有人故意隐瞒，是因为系统从来没有要求过这些信息必须留下来。

第二种症状，边界从来没有被设计过。 流程里有测试环节，但「测试」这个词在实际执行中是模糊的——它有时候是质量门，有时候是讨论会，有时候是产品临时重新审视需求的机会。产品在提测前突然说「这个做的不对」，然后再加一个需求；测试发出去的版本带着 bug，因为修不完，版本迭代太快。这些情况发生时，没有人有明确的依据说这不对——因为谁在哪个环节有什么权力，从来没有被写清楚过。

复盘的时候很难说清楚问题出在哪。因为每个人做了什么、依据是什么、结论是什么，都没有记录。

第三种症状，需求的来源根本不是客户。 产品整理了一批需求进评审，逻辑自洽，文档也写了，但评审会上被一句「客户没提过」全部否掉。这批需求走完了内部立项流程，占了产品几周时间，最后在会上一句话结束。浪费掉的不只是时间，是整个链路在一个从来不存在的需求上跑了一遍。

这类需求最隐蔽，因为它在系统里看起来和真实需求一模一样——有标题、有负责人、有版本号。台账里看不出来源是客户还是内部推断，因为台账从来没有要求这个信息必须存在。

这不是执行问题，这是设计问题。

第二节：翻完台账之后，我看到了什么

在判断做什么之前，我翻了一遍当时团队的需求台账。没有逐字读每一条记录——宏观扫了一眼字段名称和填写情况，问题已经很明显了。

我原本以为会看到填写不规范的问题。实际看到的，比这更系统性——不是填错了，是整体设计没有原则。

第一件事：「客户是谁」这个问题，台账里几乎没有答案。

台账里有一个专门记录「这东西是给谁用的」的字段，设计得很细，选项分了好几类用户。但实际填写率极低，近乎废弃。与此同时，「需求来源」这个字段的填写内容，几乎清一色是公司内部人员。这意味着：大量需求的来源不是客户，是内部人员认为该做的。台账本身就在记录这件事，只是没有人把它当作信号读出来过。

第二件事：「为什么做」这个问题，台账里也没有答案。

台账里有「痛点描述」字段，但填写率极低。有人写一句话，有人写的是解决方案而不是痛点本身，更多的是空白。需求标题基本都写了「做什么」，但「现在有多痛」「不做的代价是什么」，这些问题在台账层面从来没有被回答过。

第三件事：字段设计本身有根本问题。

有一个「优先级」字段，设计意图是给需求打优先级，但选项里混入了「解决方案还需完善」「需采集更多反馈再评估」这样的状态描述。优先级和流程状态是两件事，被放进了同一个选项列表。填写者不知道该选哪个，于是干脆不填。这不是执行懒惰，是字段设计让人没有办法填对。

第四件事：进展信息不在台账里。

台账里有进度详情字段，前期有人填，后来几乎完全弃用。执行过程中的讨论、决策、障碍，全部转移到了群聊里。台账记的是起点和终点，中间发生了什么、卡在哪里、谁做了什么决定，时间一长全部消失。

第五件事：时间成本完全不可追溯。

排期估算是存在的——只是全在口头和日会上对齐，没有落进台账。哪类需求总是低估工作量、哪个阶段最容易卡住，这些问题永远无法被数据回答。

看完这张台账，有一件事变得很清晰：

几十个字段，被认真维护的不到零头——需求标题、负责人、版本号、需求状态、文档链接。其余字段要么从来没活过，要么活了一段时间之后废掉了。

这张台账现在承担的功能，是「版本归属登记」，不是「需求管理」。

为什么会这样，值得多说一句，因为它决定了后面所有设计。

这两类字段的填写动力根本不一样。版本号必须填——否则周会说不清楚，填它是工作本身的一部分。痛点描述可填可不填，不填也不影响任何人当下的活——填它是额外劳动。

凡是额外劳动，长期一定归零。 经济学把这件事叫激励相容：只有当一个人做对系统有利的事，同时也对他自己当下有利，这件事才会持续发生。靠自觉、靠培训、靠周会点名，都是在跟这条规律对着干，短期有效，长期必输。

所以记录如果不产生于工作本身，就永远需要有人额外去填。

这直接给出了后面整套系统的第一条设计原则：不要求任何人多填一栏，而是把记录变成动作的副产品——他点掉一张卡完成自己那步工作，表就已经写好了。

四月份往这张台账里加字段的做法之所以注定失败，不是因为字段设计得不好，而是因为它加错了地方——它在往记录系统里加要求，而人活在工作系统里。

第二章：我是怎么判断的

章首结论：工具不难，判断难。

这套系统搭起来之后，问我用了什么技术的人不少。答案其实很普通：一个 IM 平台的开放接口、一张在线多维表格、一个大语言模型的 API、几段 Python 代码。没有用任何复杂框架，没有任何炫技的成分。

真正花时间的，是在动手之前做的五个判断。

第一个判断：这是线性流程，不是图。

技术选型时我在三个方向之间做决定：LangGraph、CrewAI 和 Pipeline。

LangGraph 适合各节点之间需要协商、下一步不确定去哪里的场景。CrewAI 的核心是多个 Agent 并行协作——一个研究员 Agent 搜集信息、一个分析师 Agent 同时处理、一个撰写员 Agent 最后汇总，三条线可以并行跑。这两个框架都有它们适合的场景，只是都不是我需要的。

把整个流程拉出来看：售前 → 产品 → 研发 → 测试 → 售后 → 复盘。每一步的输出是下一步的唯一输入，流程严格线性，有条件分叉和拒绝退出逻辑，还有人工审批断点卡着等待。这是一个带条件出口的线性 Pipeline，不是并行协作的多 Agent 网络。

用复杂框架会把一个清晰的流程搞复杂。Pipeline，定了。

第二个判断：每个节点必须人拍板。

这个判断在设计之初就定了，没有动摇过。

原因不是 AI 不够聪明，而是要把人机协作的边界在设计阶段就划清楚——AI 能做什么、不能做什么，这条线必须写死，不能在运行中模糊。

举一个具体的例子：如果一个需求进来说「响应时间要在 1 分钟以内」，AI 没有办法判断这是不是合理的需求。它不知道现在的响应时间是多少，不知道这个行业里什么叫做快。这个判断必须由懂业务的人来做。

AI 能做的，是把模糊的想法结构化，确保信息明确地传递下去。判断这个信息值不值得做，是人的职责。

第三个判断：守门守的是真需求，不是信息完整性。

守门这个设计，有人理解成「要求填的字段足够详细」，但这不是我的出发点。

我的设计原则是：模糊不存。任何一个环节，如果这条需求回答不了「它背后有没有真实的客户群体」这个问题，它就不能往下传。

这不是苛刻，这是对整个团队负责。一个伪需求如果顺利通过了守门，进入产品审批、研发排期、测试验收，每个环节的人都为它花了时间。等到最后发现做出来客户不认可，整个链路的成本全部浪费。

守门守的不是信息完整性，守的是这条需求的真实性。这两件事不是一回事。

第四个判断：卡片是操作入口，不是通知工具。

这个判断的来源说出来可能出乎意料——不是来自对 IM 平台的深入研究，而是一次偶然的信息摄入。

我在用另一个 agent 工具的时候，它有时会在 IM 里发一张卡片，问我「同意还是不同意」，等我点完按钮再继续执行。我记住了这个交互形式。

后来设计这套系统的时候我想到：每个审批人拿到卡片，里面包含完整的需求背景，然后只需要做一件事——通过或拒绝，写一句理由，点按钮。按钮点完变灰，不可撤销，自动记录。不需要进任何其他系统，不需要切换工具，不需要额外培训。

这不是功能炫耀，是降低执行摩擦的设计。流程不长在文档里，长在你每天已经打开的那个聊天窗口里。

第五个判断：把它拆成三层，业务层才是客户的资产。

这套东西如果只能长在一个特定的 IM 平台上，它就不是一套打法，只是一个应用。所以从第一天起我就按三层拆：

• 平台层——消息怎么进来、卡片怎么发出去、数据写进哪张表。这层今天是飞书，也可以是企业微信、钉钉，极端情况下甚至可以是网页表单加邮件。换平台，改的是适配层，不是流程。
• 模型层——谁来做分类、追问、起草、结构化。今天接的是某个大模型的 API，明天换一个更便宜或更强的，改的是一段配置。
• 业务层——你的流程到底有几关、每一关谁说了算、什么条件不许往下传、什么情况必须打回。

代码上，前两层被收在抽象接口后面，业务层只认接口不认具体平台；离线状态下用一组模拟实现就能把全链跑完，一行真实网络请求都不发。这不是架构洁癖，是这套东西能不能搬到别人公司去的分水岭。

一个企业买的不是我的机器人，是把自己那套流程写进第三层的能力。 前两层我负责让它可换，第三层我负责让它可写——而第三层的内容，只能来自你们自己的流程。

AI 在这套系统里真正做什么。

从售前到售后，信息在每一层都会衰减。售前用客户的语言说需求，产品用自己的理解翻译一遍，研发拿到又是另一套逻辑。每多一次传递，模糊就多一分。到最后，做出来的东西和客户最初说的那句话，可能已经相去甚远。

AI 在这套系统里做的事，是在每一次传递发生之前，帮当前这个角色把模糊的想法落成结构化的字段——不是替他们判断，而是迫使他们把自己的想法说清楚，然后以不会失真的形式传递给下一级。

这不是 AI 在帮人做决定。这是 AI 在帮人把决定说清楚。

第三章：这套系统实际长什么样

章首结论：把每一次交接都改写成一张必须点掉的卡；卡点掉了，表就自己写好了。

这条链分两轨。

外触轨只对客户：客户在群里说一句话，机器人当场分类、预填、分流，处理完把结论送回客户最初那条话题。客户全程只说一次。

内流轨只对内：一条被判定为「新需求」的消息交接进来之后，走四要素追问 → 需求池 → 版本立项 → 审视 → 执行 → 集体验收 → 发版 → 复盘回流。

两轨之间有一个交接点，也就是最容易掉棒的地方。全部动作最终落进同一张总表。

下面按关卡讲。每一关我先写当时是怎么掉棒的——这些小场景是虚构的，但每一个都真实发生过；再写系统里的接法。

第零关：客户的话怎么进来

当时掉的棒：

客户在群里说：「这个功能用不了。」 于是拉了个群。群里有售前、产品、两个研发、一个测试。 七条消息之后有人问：「所以这到底是 bug，还是他不会用？」 客户又被 @ 了一次，把刚才那句话重新说了一遍。

系统的接法：客户路由机器人。

客户在群里说一句话，机器人立刻把它分成三类，并预填成一张卡：技术 bug / 使用问题 / 新需求。

分类不对可以一键改判——关键在于，改判之后的卡仍然回在客户那条原话题里，不另起炉灶、不把人拉进新群。确认提交之后按类型进对口的内部群认领：bug 带着机型和版本号精确转研发、使用问题转售后、新需求转售前。处理完了，结论回到客户最初那条话题。

客户全程只说了一次，剩下的流向由系统决定，不由「谁刚好看见了这条消息」决定。

顺便说一句这一关的另一种用法。

把「客户群」换成「客户咨询」，把「三类分流」换成「常见问题 / 订单问题 / 需要人处理」，这一关就是一个 AI 客服：消息进来 → 判断类型 → 查这个客户是谁、什么级别 → 能自动回的自动回，回不了的带着完整上下文转给人，而不是让客户对着人再说一遍。

是同一段代码结构，换掉的只是分类词表和路由目标——也就是第二章说的第三层。如果你的公司没有产研需求链，但每天有一堆客户咨询要接，这一关可以单独拿出来用。

第一关：一句话，问成四要素

当时掉的棒：

「客户要个批量导出。」 「哪个客户？」「就上次那个。」 「导出什么？」「他没细说。」 「什么时候要？」「挺急的。」

系统的接法：对话式追问。

一句话需求进来，机器人不直接放行，而是逐轮追问四件事：这是哪类客户遇到的问题？在什么场景下发生的？具体遇到了什么障碍？解决之后客户希望得到什么结果？

这四个问题是强制的，不是建议。缺哪个追哪个，最多三轮，三轮还补不全就拒绝。

还有一个问题它一定会问：这个描述是客户说的，还是你自己的推断？如果回答是「我感觉用户会喜欢这个功能」，它不放行——来源不是客户，是内部判断。第一章说的第三种症状，堵在这里。

四个字段齐了，机器人生成一张确认卡推回去。提出人看到的，是自己刚才那句话被拆解成四个清晰字段之后的样子。确认没问题，点按钮，卡片变灰，信息锁定，自动写表。

第二关：提完之后，不再沉底

当时掉的棒：

「上次说的那个需求呢？」 「在列表里。」 「排第几？」 「……都是最高优。」

系统的接法：需求池。

通过第一关即自动入池。池子做三件事：

• 累积热度。 同一个诉求被不同客户、不同渠道反复提起，计数往上加。提过一次和提过十次，在池子里长得不一样。
• 记住来源。 这条需求是从客户群来的、从复盘回流来的、还是内部提的，池子里分得清。
• 带分进池。 需求带着 AI 预评分（痛点强度 / 公司利益 / 竞争优势 三维）进来，人在这个基础上审、调、拍板。

第三点要说准确：AI 给的是一份草稿，不是结论。 优先级不是系统算出来的，是人在一份已经写好的草稿上改出来的——把这个动作从「对着二十列空白从头填」降成「审一眼，改一个数」。这两者的执行成本差一个数量级，而这正是第一章那条规律的直接应用。

重要但不紧急的需求，从此有了一个排队的地方，而不是沉到列表底部再也不会被想起。

第三关：版本只有一个正门

当时掉的棒：

「这版做什么？」 「把手上这些做完。」 「这版的核心价值是什么？」 「……客户提的都挺重要的。」

系统的接法：版本立项 → 一张「版本任务书」卡。

版本号只能从立项产生。任务书卡是四件套：

1. 本版本核心价值——一句话，用客户听得懂的语言写。AI 根据这一版选中的需求起草，人可以改，也可以推翻重写，但不能留空。
2. 需求清单——每条 = 标题 + 归属主线 + 客户视角的验收标准 + 责任人。
3. 631 配比——当期客户需求六成、主线建设三成、技术与未来一成。
4. 不做清单——这一版明确不做的东西，连同理由一起写下来。

这里要多解释一句，因为这是整套设计里最不直观的一环。

优先级为什么会通胀？因为标最高档不要钱。每个人都希望自己的需求先做，标最高档没有任何代价，那么理性的做法就是人人都标最高档。等所有人都这么做，标尺就只剩一档在用——信号死了。

这和货币超发是同一件事：钱印得越多，每一块钱携带的信息越少。优先级本质上是一种内部货币，用来传递「什么更重要」这个信号；一旦它可以零成本无限增发，它就不再传递任何信息，只剩下噪音。

631 配比就是给这把标尺重新加上预算约束。 这一版一共只有这么多格子，六成给当期客户、三成给主线建设、一成给技术与未来。想把一条需求塞进来，就必须指出把谁挤出去。代价一旦真实存在，优先级就重新变回一个有信息量的判断。

「不做清单」是同一个机制的另一半：被挤出去的东西必须被写下来、被看见。否则它会以「口头答应了但一直没排」的形式，继续在背地里消耗信任。

第四关：一次显式的通过或打回

当时掉的棒：

版本排完了，发到群里。 没有人回复。 三周后：「这个版本怎么没有那条最要紧的？」

系统的接法：审视卡。

任务书提交之后，推送给对市场负责的那个角色，卡上只有两个按钮：通过 / 打回。

打回必须填意见，任务书回炉重发；通过即落一条决策记录——谁确认的、什么时候。

卡上写着两个问题：哪些你认为很重要的，没在里面？哪些不重要的，排在里面了？

这一关的角色是配置化的。换成谁来审、审几道，是配置项，不是代码——第二章的第三层，在这里具体表现为「你们公司谁有权拍板」这件事可以被写进去。

第五关：交接改成只读继承

当时掉的棒：

「这条不是排在下个版本吗？」 「我这边写的是这一版。」 「谁改的？」 「不知道。」

系统的接法：批量分发 + 只读继承。

审视通过，需求逐条分发给下游。版本号和计划发版日期只读继承自立项——下游表单里再填的版本值一律不采信。同一个字段只有一个源头，不存在两个人写不同的值然后谁也说不清以谁为准。

另一半是防绕过：没有走过池子的需求直接提到下游，会被硬拒。这一条是整个版本规划层能不能成立的前提——只要存在一条绕过去的小路，所有人最终都会走那条小路，前面四关全部作废。

第六关：客户视角随卡到底

当时掉的棒：

「验收标准是什么？」 「按文档来。」 文档里写的是：接口返回 200。

系统的接法：四要素是字段，不是聊天记录。

第一关问齐的客户 / 场景 / 痛点 / 期望，一路随卡走到研发和测试手上。研发第一眼看到的不是一句需求描述，而是三层信息叠在一起：客户原话拆成的四要素、产品的价值判断与验收标准、AI 结构化之后已被确认的测试用例。

AI 在这一步做的是把标准变成可执行的动作。比如把「首次响应时间 < 10 秒」这句话，变成：「在客户日常使用的那个场景下，由现场负责人触发一次对话，用计时工具连续记录不少于 5 次，每次均须 < 10 秒；任意一次 ≥ 10 秒判定 Fail。」

它不修改标准，只是把标准写成谁都能照着做一遍的步骤。因为 AI 判断不了技术边界——「响应时间 1 分钟以内」合不合理，它不知道，只有懂业务的人知道。所以 AI 只做结构化，评判权留在人手里。

再往下，一条需求可以拆成多条研发子线，估算、自测、场景测试各自记在自己那条子线上，谁做到哪一步在表里一目了然。自测没过，硬门控挡回、补发卡片重来。

验收锚定的是客户每天在用的那个场景，不是一个个点按钮。

第七关：发布是一个决策

当时掉的棒：

「发了吗？」 「发了。」 「那两条没做完的呢？」 「下版本吧。」 没有人记得这是谁决定的。

系统的接法：集体验收 + 显式发版。

发版之前有一道集体验收：这一版里的每一条需求，由最初提出它的那个人逐条确认。有异议必须填原因；异议一提交，那条需求当场打回返工，发版确认卡同步作废——防的是「卡片上显示可以发版、实际上还有人在返工」。

全部通过，才放行「确认发版」这个按钮。

版本自己也有生命周期：草稿 → 审视中 → 已确认 → 已发布 → 已复盘。走不到最后一步，这个版本不算完。

发布从一件自然滑落的事，变回一个有人签字的决策。

第八关：复盘回流，链条闭合

当时掉的棒：

「上个版本效果怎么样？」 「应该还行吧。」 「上次复盘说要改的那件事呢？」 「……」

系统的接法：复盘卡 + 承诺对账。

确认发版的那一刻，复盘卡自动送到版本负责人手上，上面把两样东西摆在一起：当初任务书里承诺的核心价值，和实际达成的情况。必须填一条「下个版本的改进」才能点「完成复盘」。

关键在下一句：下一个版本复盘的时候，上一版承诺的那条改进会自动出现在对账区——落实了没有，一眼可查。复盘从一件说完就散的事，变成一件会被追的事。

发版之后收到的客户反馈，同样回流进池子，参与下一轮排队。第八关交回第一关，链条闭合。

复盘全程零人名、零负面归因——写的是「哪一棒的交接标准不够」，不是「谁做得不好」。这条纪律是硬的：一旦复盘变成追责，下一次就再也拿不到真话。

收口：一张总表兜底

每一张卡片的提交，都会触发一次自动写入——字段、时间戳、责任人、结论，全部进表，不需要任何人手动维护。

列的顺序就是一条需求的生命周期：索引 → 发起 → 产品定位 → 四要素 → 需求池 → 承接 → 估算 → 自测 → 测试 → 集体验收 → 发版 → 反馈。

103 列 = 一条需求的一生。

不会再出现几十个字段只有零头有内容的情况，因为写入是系统在做，不是依赖某个人有没有空去填。

这张表不再是版本归属登记，它是一条需求从第一句话到客户反馈的完整档案。

第四章：Before vs After，哪里不一样

章首结论：最大的变化不在中间，在两端。

跑完全链路之后，最让我意外的提升不是某个审批环节变快了，而是一头一尾——

头：伪需求在进来的那一刻就被拦住了。情绪化发言、无法追溯到客户的表述，守门直接拒绝，不让它往下传。在这条链上，「产品自己理解出来的需求，研发做了，客户不认」这件事不再有发生的路径。

尾：复盘视角第一次真正存在了。一家公司里通常没有任何一个人拥有完整的跨部门视角——管理层在各部门之上，但没有时间仔细复盘每一个版本的每一个环节。复盘卡针对特定版本自动生成、发给所有经手人，字段公开透明。这是以前完全没有的东西，不是因为以前不想要，而是因为以前没有人处于这个位置能做这件事。

对比表格：

说实话：

这套系统能做到的，是让每个阶段有结构化的输入和输出，有规范的审批，所有字段公开透明。就算一个人扮演多个角色，全链路也是通的——这意味着 20 人左右的小团队同样适用。

它做不到的，是代替人进行业务判断。响应时间 1 分钟算不算合理，这个问题 AI 回答不了，因为它不知道你的业务背景。判断权始终在人手里，这是设计的本意，不是缺陷。

它也做不到自动帮你定优先级。AI 给的是草稿，拍板的是人——如果你想要的是「把优先级这件事外包给 AI」，这套东西不是你要的。

还有一件事它做不到：代替没有决心的老板。 如果团队不愿意让信息链路公开透明，这套系统帮不上忙。它能做的，是在老板真正想推的时候，把推行成本降到最低。

最后，把证据边界说清楚。

这套系统端到端真实跑通过；跑过的每一条需求，在表里都有从第一句话到客户反馈的完整记录；自动化回归 272 项；在一场企业内部黑客松中拿到 96/100 的综合第一。

这是我能拿出的全部证据。多的我一个字都不会说——一份连自己的证据边界都要含糊其辞的白皮书，不配让你把公司的流程交给它。

第五章：你们公司能用吗

章首结论：有产研分工、协作发生在 IM 里、老板想要信息透明——就已经准备好了。

先说规模。

20 人以下的公司通常不急。这个规模信息传递的层级还没有厚到需要系统化管理，一两个人就能口头对齐。

20 到 50 人同样适用，尤其是一个人身兼多职的团队。这套系统的流程以角色为单位，不是以人头为单位——同一个人可以同时扮演售前、产品、研发，全链路照样跑通，表照样自动写入。小团队跑单人全链路，反而是验证系统是否稳定的好方式。

500 人以上可以推，但成本很高。这个规模的组织里同一个部门内协作的人就很多，工具往往是重系统，迁移成本极高。更现实的问题是：信息透明化会触及某些人的真实利益。很多人靠着信息不对称、流程模糊、协作摩擦维持自己在中间的位置——这套系统一上，这种空间就没了。阻力会很大。

50 到 500 人是最合适的区间。 这个规模的公司，产研各部门通常在 10 人以内，日常协作高度依赖 IM。每个人都在认真做事，但信息损耗和口头对齐的问题已经开始出现。这套系统介入的成本最低，收益最明显。

再说老板。

工具能不能用起来，最终取决于一个人：老板有没有足够的决心。

这不是技术门槛问题，是意愿问题。信息透明化对认真做事的人有利，对靠信息不对称混日子的人不利。如果老板不愿意真正推动这件事，这套系统最后会变成另一张填了又烂掉的表。

适合的老板是这样的：真正想搞清楚需求在哪里卡住的，愿意让每个人的决策都留记录的，对 AI 工具持开放态度而不是本能抵触的。

关于技术门槛，说实话。

配置成本比大多数人想象的低很多。IM 机器人的创建基本是 UI 操作，表格随系统自动生成，AI 模型现在直连 API 即可。只要有一台能上公网的机器，教程写得足够详细，初级开发者、甚至有一定技术背景的运营都能完成配置。

换平台也不是重做。第二章说的三层拆分在这里兑现：换 IM 改的是平台层的适配，换模型改的是一段配置，你们的流程规则住在业务层，不跟着一起动。

但更现实的路径不是自己从零搭：先诊断，再落地。 方案不是通用模板，是基于你们真实现状设计的。

最小可行路径：先上前两关。

不要一次全上。先只做「客户的话怎么进来」和「一句话问成四要素」这两关——需求有人守，来源必须真实。这两步跑通，第一章那五个问题里最核心的两个已经解决了。

后面的关卡可以逐步补齐，每增加一关都是独立的改动，不影响已经配好的那几关。

推行的第一道坎，不是配置，是让人相信它真的能跑。

前面讲的都是「能不能用」。还有一个问题同样决定成败：推得动吗。

流程类的东西最容易死在这一步。你说得再清楚，对方脑子里的默认假设都是「又一个要我填表的系统」。要翻转这个假设，只能让他亲眼看见它跑起来。所以你一定会做一次演示——而演示这件事本身，是有打法的。

两条，都是我自己准备演示的过程里踩出来的。

第一条：演示顺序是信任管理工具，不是信息罗列。

先让观众看到它能跑，再解释它怎么跑。

顺序反了就完了。上来先讲架构、讲字段、讲设计取舍，观众全程在心里问一句「所以它到底能不能用」——你讲的每一句都在消耗他的耐心，而不是积累他的信任。反过来，先给一张主干图当坐标系（一分钟，讲清楚一句话主干就打住），再直接跑一条真实需求给他看，他会自己把细节问出来。被问出来的信息，和被灌进去的信息，可信度完全不同。

同理，讲完主干别在图上逐字复述流程。图负责讲清楚，跑通负责证明真的。同一件事讲两遍，第二遍就变成了心虚。

第二条：Demo 就绪不等于零 Bug。

这是我自己长期搞错的地方。总觉得要等「没问题了」再给人看——结果就是永远不给人看。

真正该用的判据是三条：

1. 主故事线可演示——从头到尾那一条路径能走通；
2. 阻塞性缺陷已修——会让演示中断、看起来像崩溃的，必须清零；
3. 体验缺陷有预案——剩下的粗糙处，你知道它在哪、知道它会怎么表现、准备好了一句话怎么带过。

第三条是关键。已知的瑕疵不是风险，未知的瑕疵才是。 有预案的粗糙，观众只当是「还在打磨」；没预案的粗糙，观众当场看到你自己也愣住，那一瞬间信任就没了。

配套的还有一条反直觉的：不要现场演示那些「跑一遍要二十分钟」或者「设计上就会被硬门控拦住」的环节。 用录屏回放。设计如此的拦截，在 live 演示里看起来和 bug 一模一样——观众分不出来，而你没有时间解释。

这两条听起来像技巧，其实是同一件事的两面：**演示不是把你做的东西展示完，是把对方的怀疑一层层拆掉。**顺序、边界、预案，都是为这个服务的。

如果你决定找我谈：从一份台账和一个小时开始。

我把第一步做成了一个明确的、最小的产品，好让你不必先信我。

你给我： 一份你们现在真实在用的需求记录——台账、表格、项目工具导出，甚至一个群的聊天记录都行。不用整理。 我要看的恰恰是它原始的样子；整理过的台账会把问题一起整理掉。再加上你或你们产品负责人的一个小时。

我给你： 一份具体的结论。不是 PPT，不是通用方案，是三个问题的回答——

1. 你们的流程真正卡在哪一关。 不是「沟通不畅」这种话，是具体到哪一次交接、丢的是哪个字段、从哪个月开始没人再填。
2. 从哪里切入性价比最高。 通常不是从头开始，是从最痛的那一关开始——哪一关改了之后，剩下的问题会自己减轻。
3. 这件事到底值不值得做。 如果我判断不值得，我会直接说不值得，并告诉你为什么。这也是结论的一部分。

价格面谈，取决于你们的规模和台账的体量。要不要往下做落地，是这一个小时之后再说的事。

• 个人主页：jacky-mypage.pages.dev
• 邮箱：jacky231609@gmail.com

最后一个判断：

如果你读到这里，脑子里已经浮现出一两个人的脸——就是那种靠着流程模糊、信息不透明在团队里过得很舒服的人——那这套系统可能正是你需要的。

后记：为什么我要把这个写出来

我不打算在这里列一遍我的简历。

你读到这里，已经看到了一套真实跑通的链路，看到了每一个判断是怎么做出来的，看到了一条需求从提出到复盘的完整路径。这就是我希望你记住的：我是一个能识别真实企业痛点、并且能把解决方案落到能跑的代码里的人。

顺带一提，这不是我唯一一次把 AI 落进真实业务，只是唯一一件我能完整摊开讲的。

为什么要写出来？

说实话，是为了找客户。

我读过不少写 AI 企业提效的文章，框架漂亮，案例都是「某企业」。我不想再加一篇。

我想要的结果，是有老板看完之后觉得「我们公司也有这个问题」，然后来找我谈。不是概念上的谈，是真实痛点、真实工具、真实落地的那种谈。

这套系统不是我虚构的。它是我在真实产研环境里观察到问题之后，花了几天时间从零搭起来的。每一个设计判断都有来由，每一条跑过的需求在表里都有记录。这份白皮书是我能给出的最诚实的自我介绍，比任何一页简历都更能说明我能做什么。

（我硕士读的是经济学，机制设计那一块，大概解释了我为什么总盯着「谁有动力填这一栏」。）

再说一次这套打法：找到掉棒的点，把交接改写成必须点掉的卡，让 AI 填空、让人判断。

需求链只是我拿来证明它成立的那条链。你们公司那条最烂的流程，大概率也能这么改。

• 个人主页：jacky-mypage.pages.dev
• 邮箱：jacky231609@gmail.com