AI工具在Markting分析中的应用(4)

起点：一个美好的幻觉

这大概是每个人建知识库时的心理活动：

「先上传再说，几百篇文献都在这儿了，AI自己能搞定的。」

我也一样。医学文献、白皮书、指南、教材……一口气上传了几百份文件，自信满满。然后我用了一个最简单的测试——问了一个非常具体的问题：

「中国代谢综合征的患病率是多少？在不同人群中有哪些差异？」

知识库返回了一堆文件列表，关联性很差，关键数据散落在各处。我手动翻找好几份PDF，才拼凑出答案。

那一刻我非常清楚：知识库不是仓库，不是把文件丢进去就完事了。

但接下来的路怎么走，并不是一开始就清晰的。它和这个工具本身的进化史，紧紧绑在一起。

一个隐藏的线索：平台进化史

我在好几个平台建立过知识库，IMA是其中之一。一开始，IMA只支持上传文件——真的就只是上传和搜索，没有别的操作。

根本性的转机出在Copilot上线，他有了Skill能力，有点类似龙虾，可以给AI预设一些工作流程，做一些略微复杂的操作。

到这里，按理说够用了对吧？实际用下来发现：不太对。

不是Skill这个功能不好——而是它太通用。每个Skill都是为通用场景设计的，不是为我的工作目标、我的使用习惯、我的分析逻辑量身定做的。用起来总是差一点：流程不对，输出格式不对，该做的检查不做，不该做的啰嗦一大堆。

说白了，就是「不顺手」。

我选择了自己动手改。而这一改，就走出了两条路线。

两条路线：Skill和Flow

改造的过程中，我逐渐摸索出两条路线：

📍 Skill 路线

直接修改和创建技能——把不顺手的地方改了，把缺的环节补上，把自己的工作流写进去。完整性强，一个Skill就是一个独立的能力单元，注册后随时可用。

📋 Flow 路线

不是改技能，而是建立一套流程协议——写规则、建SOP、搭检查清单。灵活，可以快速响应新问题。

两条路线各有各的用处，但真正让这件事产生质变的，是它们的交集——在Skill里嵌入流程规则，在流程里调用Skill能力。中间的结合部，才是这个知识库真正好用起来的地方。

接下来的故事，就是这两条路线交替推进的过程。从第一个最基础的痛点开始——

1文件是死的，知识是活的

无论走哪条路线，都要先解决最底层的问题：文件本身和文件中的知识，是两个完全不同的东西。

你上传了一份200页的PDF，它的标题可能叫「中国心血管健康与疾病报告」，但AI并不知道这里面藏了——

• LDL-C达标率仅30.1%
• 心血管患病率3.3亿
• 农村死亡率持续高于城市

AI读的是文件名，不是文件里的知识。

怎么办？做「原子化」——把每篇文献拆解成最小的知识单元：核心主张、关键效应量、机制路径、引用关系、跨域推理。一篇文献拆成5-10个原子级知识点。

我花了很多时间，完成了200+篇文献的深度原子化。同时制定了「弹性批处理协议」——每批5篇原子化，逐批推进。

"中国代谢综合征患病率31.1%，约4.5亿人。来源：第7批原子化。"

不再返回文件，而是返回答案。← Flow路线首次应用

2有知识，没连接

原子化解决了「找到知识」的问题，但下一个问题来了——这些知识怎么连起来？

一个产品分析需要跨4个领域的文献支撑——消化、代谢、心血管、神经。但知识是孤岛，得人工串。

于是做了知识图谱。

建立两类连接：

真实引用边：文献A引用了文献B，A支持B的结论AI推理边：文献A证实「胰岛素抵抗→脂肪酸氧化受阻→骨骼肌脂肪异位沉积」，文献B证实「内脏脂肪增多→脂肪因子分泌紊乱→加重胰岛素抵抗」，AI可推理出「胰岛素抵抗→脂肪沉积→IR加重」的正反馈回路

✅ 跨越7大领域，300+条文献间连接。产品分析数秒内完成跨领域推理。← Skill路线成果

3AI也犯错，而且会一直犯同一个错

今天搜索某个患病率数据，AI给出了错误答案；明天换个问题，AI可能又犯类似的错。

我建了一个「工作流宪法」。

每次出错三步走：记录根因 → 写规则防再犯 → 汇总到「宪法」。两周积累了30+条SOP：

• 数据验证规则
  ：所有数据必须回溯原始文献标注PMID/DOI
• 搜索优先规则
  ：知识库优先→联网补新→闭环入库
• 引用格式规则
  ：正文方括号标注，文末可点击链接

↓80%同类错误的重复率

← Flow路线：不是改代码，而是建制度

4每次分析都从零开始

要做报告？写PPT？查流行病学数据？——每个场景的流程都不一样。

需要给AI安装「工作技能包」。

陆陆续续开发了15+个技能：

5知识库没有「全景视图」

你有一堆零散的知识点，但看不到全貌。做跨轴分析时，我需要一个全景框架——从消化系统到神经系统，疾病和机制是怎么一步步传播的。

做了P0到P6的全轴机制链。

• 核心病理枢纽
• 疾病差异路径（为什么同样从炎症出发，有人得糖尿病、有人得抑郁）
• 治疗缺口 + 产品干预定位

拼图终于连起来了。

你可能会问：这么多优化升级，是不是很难？

其实不是。大多数优化的起点，可能来自一篇帖子、一篇论文、或者和其他AI的一次对话。

补丁 1

一篇帖子教会我做「概念Wiki」

看到Karpathy的LLM Wiki方法论——让AI自己维护概念网络。判断：这套逻辑可以搬到我的知识库里。

搭建了Wiki引擎：一篇文献入库后，自动更新6-8个概念页，知识体系自动生长。

✨ 一个灵感，一个下午，一个技能

补丁 2

一篇论文帮我省了一半Token

读到SKILLADAPTOR论文——出错后定位具体步骤，只修那一步。判断：这正是我每天在经历的痛点。

搭了故障归因脚本。单次错误处理成本从浪费60-85% Token降到10-20%。

✨ 一篇论文，一段脚本，效率翻倍

所以优化升级不靠技术背景，靠判断力

看到一个好方法 → 判断能否移植 → 快速落地 → 效果可量化

坦诚说——我没有计算机背景，也不会编程。

我做的事是：基于我的专业理解判断什么东西「可能有用」，然后把决策权和实现权交给AI。然后我把帖子链接给他，把文献给他甚至把沟通的截图给他，说“请学习这个，看看对我们的系统有没有用，如果有用，你出个落地的方案”

我的角色是指方向，AI的角色是走通。

你不必成为技术专家，你只需要成为「会判断什么值得学」的人。

看看都从哪些地方「借」过东西：

每条都一样：我看到 → 我觉得有用 → 丢给AI评估 → AI帮我落地。

回看：两条路线 + 一条补给线

• Skill路线
  ：解决「能做什么」——能力边界
• Flow路线
  ：解决「怎么做对」——行为规范
• 补给线
  ：解决「怎么迭代」——持续进化

写在最后

不要只上传文件。先搞清楚自己的工作习惯——哪些地方不顺手，然后判断：这个问题更适合改能力，还是改流程，还是两者结合。

不要觉得优化很难。AI就是来帮你做这个的，让他去分析自己和标杆的差距，然后升级自己。

上传文件只是开始，真正的工作从之后才开始。

以前微软的产品开发是产品经理+工程师，后来谷歌用招聘既懂产品又懂编程的人的方式打败了微软……现在，我这种没有工程师辅助的小白也能实现一些想法了

一个不一样的时代正在到来……

祝夏安