大多数产研团队的需求管理，看起来是这样的：
售前群里发：「王总，那个客户要一个能自动配置接待话术的功能，很急」
产品回：「好的，记一下」
研发三个月后：「这个需求当时谁提的？客户是谁？验收标准是啥？」
售前：「我也记不清了」
还有另一种情况，同样真实：
测试快收尾了，按流程这时候应该可以发版了。
产品突然说：「这个做的不对。另外我再加一个需求。」
测试本来是收口的那道门。但这道门从来没有真正关上过。
问题不在于哪个人不负责任。每个人都在做自己那部分。但边界没有人划清楚，判断没有人拍板记录，信息每传一层就丢一块。等到有人开口问，已经没有人记得清楚了。
我在真实的产研环境里看到这些问题之后，花了几天时间，试着用 AI 解决这件事。
在动手之前，我翻了一遍当时团队的需求台账，看了看字段填写情况。发现了一件让我意外的事：守门环节的核心字段，填写率极低。大量需求进来的时候，没有「客户是谁」，没有「为什么要做」，没有「做完了怎么算完成」。系统是有的，流程也走了，只是这三个问题，从来没有人回答过。
这不是需求管理系统，这是一个状态看板。这两件事不是一回事。
而这本白皮书，就是「一个 AI 工程师从看到问题到系统真实跑通」的完整路径。不仅是理论，不仅是框架，而是一套可以复用的系统。
章首结论：问题不是人不负责，是系统根本没设计好。
产研团队里最难受的一种局面，不是有人摆烂，而是每个人都在认真做自己那部分，但事情还是会出问题。
销售在收集需求，产品在写方案，研发在开发，测试在测试——每个人都完成了自己的环节。但当你把一条需求的全程拉出来看，你会发现这些环节从来没有被真正连接起来。
最典型的症状有两种。
第一种，信息在传递中消失。 一个需求从售前进来，到了研发手里，客户是谁、为什么要做、做完了怎么算完成——这些问题的答案通常都不见了。不是有人故意隐瞒，是因为系统从来没有要求过这些信息必须留下来。
第二种，边界从来没有被设计过。 流程里有测试环节，但「测试」这个词在实际执行中是模糊的——它有时候是质量门，有时候是讨论会，有时候是产品临时重新审视需求的机会。产品在提测前突然说「这个做的不对」，然后再加一个需求；测试发出去的版本带着 bug，因为修不完，版本迭代太快。这些情况发生时，没有人有明确的依据说这不对——因为谁在哪个环节有什么权力，从来没有被写清楚过。
复盘的时候很难说清楚问题出在哪。因为每个人做了什么、依据是什么、结论是什么，都没有记录。
这不是执行问题，这是设计问题。
在判断做什么之前，我翻了一遍当时团队的需求台账，逐类看了字段填写情况。
我原本以为会看到填写不规范的问题。但实际看到的，比这更系统性——不是填错了，是整体设计没有原则。
第一件事：「客户是谁」这个问题，台账里几乎没有答案。
台账里有「服务主体」这个字段，设计得很细，有终端用户、一线运营、技术集成方等选项。但实际填写率极低，近乎废弃。与此同时，「需求来源」这个字段的填写内容，几乎清一色是公司内部人员。这意味着：大量需求的来源不是客户，是内部人员认为该做的。台账本身就在记录这件事，只是没有人把它当作信号读出来过。
第二件事：「为什么做」这个问题，台账里也没有答案。
台账里有「痛点描述」字段，但填写率极低。有人写一句话，有人写的是解决方案而非痛点本身，更多的是空白。需求标题基本上都写了「做什么」，但「现在有多痛」「不做的代价是什么」，这些问题在台账层面从来没有被回答过。
第三件事：字段设计本身有根本问题。
有一个「优先级」字段，设计意图是给需求打优先级，但选项里混入了「解决方案还需完善」「需采集更多反馈再评估」这样的状态描述。优先级和流程状态是两件事，被放进了同一个选项列表。填写者不知道该选哪个，于是干脆不填。这不是执行懒惰，是字段设计让人没有办法填对。
第四件事：进展信息不在台账里。
台账里有进度详情字段，前期有人填，后来几乎完全弃用。执行过程中的讨论、决策、障碍，全部转移到了飞书群聊里。台账记的是起点和终点，中间发生了什么、卡在哪里、谁做了什么决定，时间一长全部消失。
第五件事：时间成本完全不可追溯。
排期估算是存在的——只是全在口头和日会上对齐，没有落进台账。哪类需求总是低估工作量、哪个阶段最容易卡住，这些问题永远无法被数据回答。
看完这张台账，有一件事变得很清晰：
近 50 个字段里，被认真维护的不超过 6 个——需求标题、负责人、版本号、需求状态、PRD 链接。其余字段要么从来没活过，要么活了一段时间之后废掉了。
这张台账现在承担的功能，是「版本归属登记」，不是「需求管理」。
这两件事的填写动力根本不一样。版本号必须填——否则周会说不清楚。但背景信息、痛点描述、客户来源，可填可不填，不填也不影响任何人当下的工作。于是这些字段，全部烂掉了。
一个系统里，填写动力决定填写质量。没有入口校验，没有强制字段，背景信息就永远不会被认真对待。这不是态度问题，是机制问题。
章首结论：工具不难，判断难。
这套系统搭起来之后，问我用了什么技术的人不少。答案其实很普通：飞书开放平台、多维表格、一个大语言模型的 API、几段 Python 代码。没有用任何复杂的框架，没有任何炫技的成分。
真正花时间的，是在动手之前做的四个判断。
第一个判断：这是线性流程，不是图。
在做技术选型的时候，我在三个方向之间做决定：LangGraph、Crew AI 和 Pipeline。
LangGraph 适合的是各节点之间需要协商、下一步不确定去哪里的场景。CrewAI 的核心是多个 Agent 并行协作——一个研究员 Agent 搜集信息、一个分析师 Agent 同时做处理、一个撰写员 Agent 最后汇总，三条线可以并行跑。这两个框架都有它们适合的场景，只是都不是我需要的。
从会议纪要出发，把整个流程拉出来看：售前 → 产品 → 研发 → 测试 → 售后 → 复盘。每一步的输出是下一步的唯一输入，流程严格线性，有条件分叉和拒绝退出逻辑，还有人工审批断点卡着等待。这是一个带条件出口的线性 Pipeline，不是并行协作的多 Agent 网络。
用复杂框架会把一个清晰的流程搞复杂。Pipeline，定了。
第二个判断：每个节点必须人拍板。
这个判断在设计之初就定了，没有动摇过。
原因不是 AI 不够聪明，而是要把人机协作的边界在设计阶段就划清楚——AI 能做什么、不能做什么，这条线必须写死，不能在运行中模糊。
举一个具体的例子：如果一个需求进来说「机器人响应时间 1 分钟以内」，AI 没有办法判断这是不是合理的需求。它不知道这个机器人现在的响应时间是多少，不知道行业里什么叫做快。这个判断必须由懂业务的人来做。
AI 能做的，是把模糊的想法结构化，确保信息明确传递下去。判断这个信息值不值得做，是人的职责。
第三个判断：守门守的是真需求，不是信息完整性。
守门这个设计，有人理解成「要求填的字段足够详细」，但这不是我的出发点。
我的设计原则是：模糊不存。任何一个环节，如果这个需求回答不了「它背后有没有真实的客户群体」这个问题，它就不能往下传。
这不是苛刻，这是对整个团队负责。一个伪需求如果顺利通过了守门，进入产品审批、研发排期、测试验收，每个环节的人都为它花了时间。等到最后发现做出来客户不认可，整个链路的成本全部浪费。
守门守的不是信息完整性，守的是这条需求的真实性。这两件事不是一回事。
第四个判断：飞书卡片是操作入口，不是通知工具。
这个判断的来源，说出来可能出乎意料——不是来自对飞书的深入研究，而是一次偶然的信息摄入。
我在用 Hermes Agent 的时候，它有时会在飞书里发一张卡片，问我「同意还是不同意」，等我点按钮之后再继续执行。我记住了这个交互形式。
后来设计这套系统的时候，我想到：每个审批人拿到卡片，里面包含完整的需求背景，然后只需要做一件事——通过或拒绝，写一句理由，点按钮。按钮点完变灰，不可撤销，自动记录。不需要进任何其他系统，不需要切换工具，不需要额外培训。
这不是功能炫耀，是降低执行摩擦的设计。
AI 在这套系统里真正做什么。
从售前到售后，信息在每一层都会衰减。售前用客户的语言说需求，产品用自己的理解翻译一遍，研发拿到又是另一套逻辑。每多一次传递，模糊就多一分，损耗就多一分。到了最后，做出来的东西和客户最初说的那句话，可能已经相去甚远。
AI 在这套系统里做的事，是在每一次传递发生之前，帮当前这个角色把模糊的想法落地成结构化的字段——不是替他们判断，而是迫使他们把自己的想法说清楚，然后以不会失真的形式传递给下一级。
这不是 AI 在帮人做决定。这是 AI 在帮人把决定说清楚。
章首结论：最大的变化不在中间，在两端。
跑完全链路之后，最让我意外的提升不是某个审批环节变快了，而是一头一尾——
头：伪需求在进来的那一刻就被拦住了。情绪化发言、无法追溯到客户的表述，守门 Agent 直接拒绝，不让它往下传。以前这类需求会进来，产品去追，追半天发现背景模糊，最后变成产品自己理解出来的需求，研发做了，客户不认，整条链路的成本全部浪费。现在这件事不会发生了。
尾：复盘视角第一次真正存在了。公司里没有任何一个人能有完整的跨部门视角——管理层在各部门之上，但没有时间仔细复盘每一个版本的每一个环节。AI 复盘 Agent 针对特定版本、特定经手人自动生成报告，字段公开透明，所有人可见。这是以前完全没有的东西。
对比表格：
| 维度 | Before | After |
|---|---|---|
| 需求进来时 | 群里记一下，没有结构 | 四问守门，伪需求直接拦截 |
| 审批方式 | 拉群讨论，没有结论，没有记录 | 飞书卡片，点一下，自动留痕 |
| 信息传递 | 每传一层丢一块 | 每张卡片含完整背景，下游看得清楚 |
| PM 的日常 | 四处收集信息，手动维护台账 | 不再需要——多维表格随协作自动写入 |
| 追进度 | 人工催，靠记忆 | 多维表格实时同步，全程可追溯 |
| 复盘 | 靠记忆，基本不发生 | AI 自动汇总，跨部门视角，发给所有经手人 |
中间环节的变化同样不小：每个阶段有结构化的输入与输出，信息以固定格式在各角色之间流转，不再依赖口头对齐和群消息追记。PM 不需要四处收集进度、手动更新台账——协作发生，记录自动追加，信息传递的摩擦大幅减少。
说实话：
这套系统能做到的，是让每个阶段有结构化的输入和输出，有规范的审批，所有字段公开透明。就算一个人扮演多个角色，全链路也是通的——这意味着 20 人左右的小团队同样适用。
它做不到的，是代替人进行业务判断。机器人响应 1 分钟算不算合理，这个问题 AI 回答不了，因为它不知道你的业务背景。判断权始终在人手里，这是设计的本意，不是缺陷。
还有一件事它做不到：代替没有决心的老板。 如果团队不愿意让信息链路公开透明，这套系统帮不上忙。它能做的，是在老板真正想推的时候，把推行成本降到最低。
章首结论：用飞书，有产研分工，想要信息透明化——就已经准备好了。
先说规模。
20 人以下的公司通常不急。这个规模信息传递的层级还没有厚到需要系统化管理，一两个人就能口头对齐。
20 到 50 人同样适用，尤其是一个人身兼多职的团队。这套系统的审批流程以角色为单位，不是以人头为单位——同一个人可以扮演售前、产品、研发多个角色，全链路照样跑通，多维表格照样自动写入。小团队跑单人全链路，反而是验证系统是否稳定的好方式。
500 人以上的公司可以推，但成本很高。这个规模的组织里，同一个部门内协作的人很多，工具也往往是 Jira 这类重系统，迁移成本极高。更现实的问题是：信息透明化会触及某些人的真实利益。很多人靠着信息不对称、流程模糊、协作摩擦在中间维持自己的位置——这套系统一上，这种空间就没了。推行阻力会很大。
50 到 500 人是最合适的区间。 这个规模的公司，产研各部门通常在 10 人以内，用飞书协作的比例很高，尤其是科技公司和 AI 公司。每个人都在认真做事，但信息损耗和口头对齐的问题已经开始出现。这套系统介入的成本最低，收益最明显。
再说老板。
工具能不能用起来，最终取决于一个人：老板有没有足够的决心。
这不是一个技术门槛的问题，是一个意愿问题。信息透明化对认真做事的人有利，但对靠信息不对称混日子的人不利。如果老板不愿意真正推动这件事，这套系统最后会变成另一张填了又烂掉的表。
适合的老板是这样的：真正想搞清楚需求在哪里卡住的，愿意让每个人的决策都留记录的，对 AI 工具持开放态度而不是本能抵触的。
关于技术门槛，说实话。
这套系统的配置成本，比大多数人想象的低很多。飞书 Bot 创建是 UI 操作，多维表格随这个协作系统自动生成，AI 模型现在直连 API 即可，很多主流大模型都支持。只要有一台能上公网的机器，教程写得足够详细，初级开发者甚至有一定技术背景的运营都能完成配置。
但更现实的路径不是自己从零搭：先诊断，再落地。 在动手之前，先把产品和售前拉下来，看看现有的需求记录，摸清楚现在的问题在哪里。方案不是通用模板，是基于真实现状设计的。
最小可行路径：先上 Stage 1 + Stage 2。
不要一次全上六个阶段。先只做守门和产品审批这两步——需求有人守，审批有记录。这两步跑通，已经解决了第一章说的五个问题里最核心的两个。
Stage 3 到 Stage 6 可以之后逐步补齐，每增加一个阶段都是独立的改动，不影响已经在跑的部分。
如果你决定找我谈：
我的习惯是先了解，再给方案。具体会做两件事。
第一件事是诊断。把你现在用的需求记录拉出来看——不需要整理，原始状态就行。看字段填写情况、看信息源头、看哪个环节最容易断掉。这一步通常一两天，结论是具体的：你们的问题卡在哪里，从哪里切入性价比最高。
第二件事是落地。根据诊断结果，裁剪一套适合你们规模和协作工具的方案，配置飞书 Bot、搭多维表格、把 AI 节点接进来，直到全链路在你们的真实需求上跑通。不是给你一个文档，是给你一个能真正用的系统。
最后一个判断：
如果你读到这里，脑子里已经有一两个人的脸——就是那种靠着流程模糊、信息不透明在团队里过得很舒服的人——那这套系统可能正是你需要的。
我不打算在这里列一遍我的简历。
你读到这里，已经看到了一套真实跑通的系统，看到了每一个判断是怎么做出来的，看到了一条需求从提出到复盘的完整路径。这就是我希望你记住的：我是一个能识别真实企业痛点，并且能把解决方案落地的人。
为什么要写出来？
说实话，是为了找客户。
市面上写 AI 企业提效的文章很多，框架漂亮，案例都是「某企业」。我不想再加一篇。
我想要的结果，是有老板看完之后，觉得「我们公司也有这个问题」，然后来找我谈。不是概念上的谈，是真实痛点、真实工具、真实落地的那种谈。
这套系统不是我虚构的。它是我在真实产研环境里观察到问题之后，花了几天时间从零搭起来的。每一个设计判断都有来由，每一条跑过的需求都在多维表格里有记录。这份白皮书是我能给出的最诚实的自我介绍，比任何一页简历都更能说明我能做什么。
如果你的团队正在经历第一章说的那些问题——
需求进来没人筛，传到研发背景全丢，做完了客户说不对；
或者你已经有飞书或企业微信，多维表格也建了，但那张台账正在慢慢烂掉——
欢迎直接联系我，寻求咨询解决方案。我的习惯是先了解你们的真实流程，再说能不能帮上。
→ 联系方式：（待补充）