500份文档,一个下午,140条接口:AI给产品经理的那根金手指

做产品经理越久，越有一种感觉：我们每天泡在数据里，却对数据视而不见。

光我们一个上线两年多的业务系统，需求文档就攒了500多份——这还不算其他系统。

每份文档都写清楚了业务要什么、接口怎么调、数据怎么流转。这些信息就是埋在业务系统里的矿脉。但它们躺在那里，跟石头没区别。没人翻，也没人翻得完。

这不是我一个人的困境。我查了查，哈佛商业评论有个著名结论：企业里只有3%的数据达到基本质量标准。数据不是没有，多得是——只是大量数据要么是错的，要么压根没人去看。我这500份文档，就属于后者：信息都在，却躺在没人打开的角落里。

产品经理的日常就是这样：你知道金矿就在脚下，但手上只有一把小铁锹，挖不动。

说实话，以前没挖也不耽误干活——用到哪个接口，去需求管理平台搜，找对应的产品问，或者让开发从代码里扒。能干，但很不方便。我一直想做一个接口汇总管理平台，但自己整理不现实，拉着团队整理更不现实——谁有空把500份文档逐篇翻一遍？

直到 OpenClaw 搭好了，我才想：这活不就该让它来干吗？

这个开源 AI 智能体框架从年初火出圈，GitHub 趋势榜一度登顶。它跟 ChatGPT 那种”你问我答”不一样——它能动手：读写文件、调用 API、控制浏览器，还能自己拆解任务、记录执行进度。我之前一直自己研究着用，但从没往工作中搬。原因很简单：业内普遍对 OpenClaw 这类智能体的安全性存有顾虑——谁敢让一个能自主操作的 AI 智能体碰生产环境的数据？

直到最近，我们想了个办法：单独买了一台小服务器，物理隔离部署 OpenClaw，再通过网络策略给它画了个”笼子”——只能在内网活动，只能看需求平台的数据，不能改，也出不去。

安全这道坎过了，才敢让它正式干活。

但”让它干活”不等于”把活甩给它”。500多份需求文档，模型上下文窗口有限，一口气全扔进去必崩。我得先想清楚怎么让它挖。

AI 是执行者，但”怎么挖”的规则是产品经理定的。它不需要判断，只需要照做。我给它定下了4条挖矿铁律：

几个小时后，140多条业务接口信息整整齐齐地出来了。从散落的需求文档到一张可筛选、可检索的接口清单，中间只隔了一个下午。

那一刻我的第一反应不是”AI 真快”，而是一种更深的震撼：这140多条接口信息，一直就在那500多份文档里。不是 AI 帮我”创造”了什么，而是它帮我”看见”了原本看不见的东西。

但铲子好不好使，得看地基。

前面说了，OpenClaw 是智能体框架，不是大模型本身——它负责”动手”，但”思考”得靠后端的大模型。我们公司本地部署了两个开源模型，OpenClaw 对接的就是它们。问题来了：全公司就那几块显卡，白天所有人抢着用，OpenClaw 跑着跑着就超时。我只能等下班后，用的人少了，再让它慢慢跑。下午更离谱——它不停地报 Error in input stream，我以为它崩了，问它出什么问题，返回的还是这个错。结果半小时后我再问进展，它才告诉我已经看了多少份需求、找到多少个接口。后台一直在跑，只是算力不够，连个回复都挤不出来。

白天抢不到算力只是麻烦之一，另一个问题更隐蔽——本地开源模型的训练数据是静态的，最多到模型发布那天。新政策、新接口规范、新业务规则，它统统不知道，结果还得人工复核。

所以回到最初的问题：AI 到底给了产品经理什么？

不是一把更快的锤子。锤子是效率工具——原来一天翻10份文档，现在能翻100份，这叫提效。但我的体感不是这样。那140多条接口信息，我原来不是翻得慢，而是根本不会去翻——500份文档摆在那，人工翻找的成本高到没人愿意干这件事。

也不是一双更巧的手。很多人以为会用 AI 工具就是产品经理的新技能，但工具会换——今天 OpenClaw，明天可能换别的。真正不变的是什么？是你知道让 AI 去挖哪座矿，知道怎么把”挖矿”这件事拆成它能执行的规则。

回头看这次经历，我做了什么？我没有写一行代码，也没有训练一个模型。我做的是三件事：识别矿脉——500份需求文档里的接口信息值得挖；设计挖法——逐条处理、记录进度、跳过无效项、定死输出格式；扫清障碍——找技术同事搭好物理隔离、网络策略、只读权限，让 AI 能合规地碰这些数据。

而且一旦你知道该干什么，这件事就不会只做一次——我准备给它加个定时任务，每天凌晨自动检查更新。从人工翻找到 AI 一次性提取，再到 AI 持续自动更新，金矿终于有了持续开采的能力。

这次从需求文档中提取接口信息的提示词，我整理好了。稍微改改规则，同样适用于合同提取、财报分析这些非结构化数据提取场景。

有需要的同学，在后台回复「金手指」即可自取，相关AI产品资料会持续更新。