何娜
AI PM
2026
Hi there! 我是何娜 ✦

用产品思维
把 AI 能力
做成能用的东西

AI PRODUCT MANAGER · 2026 应届硕士

北京工业大学硕士，两段 AI 产品实习： 360集团 做 GEO 诊断报告模块，北京构力科技 做 PKPM-Agent 自然语言建模。 还自己从 0 做了 Lumode —— 一句话生成 3D 模型，已独立上线。 习惯先把指标口径讲清楚，再讲数字；能自己动手把原型跑起来。

看四个项目 → 下载简历 PDF
何娜
「动手去做，成长更快。 ✎」
2 段
AI 产品实习（360 / 构力）
1 篇
顶刊论文（一作）
1 个
独立上线的 AI 产品

我能带来什么

What I bring

不是工具清单，是四件能独立交付的事。

01

产品能力

Product

需求调研 → 优先级排序 → 方案设计 → 开发跟进 → 上线交付 → 迭代优化，跑过完整闭环。

用户访谈需求拆解PRD版本节奏
02

AI 落地能力

AI Delivery

RAG 知识库、Prompt 工程、Agent 与 Workflow 设计；结合业务做模型选型与效果对比，不凭感觉选模型。

RAGPrompt 迭代Agent 编排模型选型
03

数据能力

Data

Python / SQL 数据处理分析，能设计埋点、搭评测集，把「效果好不好」变成可复算的口径。

评测集设计埋点badcase 归因SHAP
04

动手能力

Hands-on

Claude Code / Dify / Figma Make / MCP：能自己把原型做出来给团队看，而不是只画图等排期。

Vibe CodingDifyMCPXmind

四个项目

Selected works

点开任意一张卡片，看完整的背景、我的动作、和我对结果的判断。

01GEO

360智见 GEO · 诊断报告模块

B端 SaaS 2026.04 – 2026.08 · 360集团

AI 搜索成了新的流量入口。我负责诊断报告模块：设计输出什么、怎么保证结论有据可依，并验证「监测—优化—报告」闭环在 B 端跑得通。

37% → 61%
AI 推荐可见率
12% → 38%
前三推荐率
2天 → 1.5h
单份报告产出时间
7.1/10
用户满意度
读完整项目 ✎ →
02AGENT

PKPM-Agent · 自然语言驱动结构建模

垂直行业工具 2024.12 – 2025.12 · 北京构力科技

结构设计师建模、布荷载全靠鼠标点选。我把它做成一句话交互：Dify「1主+3子」Agent 架构，解析—调度—执行闭环。

77%
参数提取准确率
81%
任务执行成功率
+23.2%
建模效率提升
3.2/5
用户满意度
读完整项目 ✎ →
030→1

Lumode · 一句话生成 3D 模型

个人项目 · 已上线 2026 · 独立完成

从想法到线上产品全是我一个人做的：需求、架构、前后端、部署、兜底策略。用户输入一句话，服务端 Blender 出可编辑模型。

PC + 移动
双端已上线
建模闭环
生成→可编辑→可下载
评测选型
含失败兜底设计
读完整项目 ✎ →
04研究

顶刊论文 · 可解释深度学习预测模型

一作 · 已发表 硕士期间

VMD-SSA-ATT-BiLSTM 混合模型，配 SHAP 可解释性分析与完整消融实验。这段经历是我做 AI 产品时「先定口径、再看数字」习惯的来源。

消融实验
逐模块拆贡献
SHAP
特征归因可解释
专业前 10%
硕士学业成绩
读完整项目 ✎ →

我是怎么走到这儿的

About / timeline

从工程与数据训练出来的习惯：先定标准，再谈结果。这套方法一路带进了 AI 产品。

2019.09 – 2023.07
2019.09 – 2023.07
聊城大学 · 土木工程 本科
专业成绩前 5%

高数、线代、概率统计、人工智能导论。第一次接触模型和数据，也是第一次发现自己更喜欢「解释结果」而不是只算出结果。

2023.09 – 2026.07
2023.09 – 2026.07
北京工业大学 · 土木工程 硕士
专业成绩前 10% · 顶刊一作

数值分析、数据分析、模式识别与机器学习、人工智能原理、工程项目管理。用 VMD-SSA-ATT-BiLSTM 做预测建模，配 SHAP 与消融实验，发表顶刊一篇。

2024.12 – 2025.12
2024.12 – 2025.12
北京构力科技有限公司 · AI 产品实习生
PKPM-Agent · 自然语言驱动建模

竞品分析与用户访谈定切入点，Dify 搭「1主+3子」Agent 架构，3 个候选模型在 40 条测试集上三维度对比选型，建 badcase 归因闭环。

2026.04 – 2026.08
2026.04 – 2026.08
360集团 · AI 产品实习生
360智见 GEO · 诊断报告模块

从 0 搭诊断报告模块：模型选型、RAG 配置、结构化输出规则、三指标定义，并用 40 个长尾词 × 6 个 AI 平台验证优化前后效果。

2026 · 持续
2026 · 持续
Lumode · 个人项目
一句话生成 3D 模型 Agent（已上线）

没有团队、没有排期，从需求到部署一个人做完。这个项目让我明白：产品经理会动手，沟通成本会低一个量级。

🎯 荣誉
科技创新一等奖 · 国家励志奖学金 · 学业一等奖学金 · 优秀毕业生 · 顶刊一篇
🧰 常用工具
Claude Code · Dify · Figma Make · VS Code · Codex · MCP · Xmind · Python / SQL
🌱 现在在做
继续迭代 Lumode，同时找一份能长期做下去的 AI 产品经理工作。

工作之外

Life wall

面试聊完项目，总还得聊聊人。

✍️
把想法写下来
🖊️
讲一遍才算真懂
☕
周末的进度条
🎿
雪季不缺席
🏃
每周三次，不谈条件
🏹
专注是练出来的
📄
论文那两年
🍂
下班绕两站路回家
📎 照片位待填：把图片放进 assets/photos/，命名 01.jpg ~ 08.jpg，刷新页面自动替换（顺序对应上面八格）。生成提示词见文件夹里的「照片提示词.md」。

聊聊吧

Get in touch

求职意向：AI 产品经理 · 2026 应届，一周内到岗。

我的邮箱
he18315997938@163.com
我的电话
183-1599-7938
随时可接，微信同号。
下载简历 PDF ↓ 写封邮件
← 回到作品列表
Project 01 / GEO

360智见 GEO · 诊断报告模块

AI 搜索成为新入口后，企业需要在 AI 推荐结果里拿到合规、可量化、可归因的曝光。我负责其中的诊断报告模块——把「你在 AI 搜索里表现如何、差在哪、该怎么改」变成一份能交付给客户的报告。

时间
2026.04 – 2026.08
团队 / 角色
AI 产品实习生
我负责
诊断报告模块 0→1
技术栈
扣子 · 火山方舟 · 豆包 · RAG

项目背景与痛点

Context & Pain

2025 年下半年起，AI 搜索逐渐成为用户获取信息的主要入口，生成式引擎优化（GEO）成了企业新的流量增长点。用户越来越习惯直接问 AI「这类产品哪家质量好」，而不是打开搜索引擎翻十页——AI 只会说出它采信的那几家，没被采信的企业等于在这个入口彻底消失。

但客户想做这件事的时候，卡在三个很具体的地方：

  • 看不见：不知道自己在各个 AI 平台的回答里到底有没有被提到、排第几。
  • 说不清：即使知道表现差，也不知道差在信源、内容、还是话题覆盖。
  • 做不动：人工出一份分析报告要 2 天，结论还高度依赖写报告的人的经验。

诊断报告模块要解决的就是这三件事：把「你现在什么样、差在哪、明天该改什么」变成一份能直接交付给客户的报告。

我的动作

What I did
STEP 1
需求洞察
配合团队访谈 B 端企业，从客户真正关心的核心指标反推报告要输出什么
→
STEP 2
产品设计
诊断 Agent 模型选型、专家系统提示词迭代、结构化 JSON 输出
→
STEP 3
输出规则
从缺口分析结果推导三指标，并生成内容优化与信源投放建议
→
STEP 4
效果验证
40 个长尾词 × 6 个 AI 平台，跑优化前后对照

这四步里我实际动手最多的是第 2、3 步：Agent 的模型选型与 RAG 配置、提示词的设计与迭代、以及报告输出规则的定义。第 1 步是配合产品团队做的，第 4 步的检测执行由系统完成，我负责定口径和读结果。

卡点与解决办法

Problems & Fixes

这部分是我觉得最值得讲的——每一条都是真踩过之后才加的规则。

卡点 1：模型会编
报告最怕的不是不准，是「听起来很有道理但其实是模型编的」。客户看到一条编造的竞品数据，整份报告的信任就归零。

怎么解：搭客户产品信息 RAG 库（切片 1000–1500 字、top_K=5、召回权重=1），让诊断结论必须落在检索到的事实上；知识库检索不到的，宁可留空也不让模型补。
卡点 2：输出格式不稳
模型自由发挥叙事的时候，同一个客户跑两次，报告结构都不一样，下游模板没法渲染。

怎么解：规定结构化 JSON 字段与格式，模型只负责填内容不负责决定结构；报告模板直接读字段渲染，产出稳定可复现。
卡点 3：提示词凭手感调
早期改提示词全靠单次试，这次好了下次可能更差，没有判断依据。

怎么解：建固定评测集做回归，每次改完跑一遍看整体分数而不是看单条；线上 badcase 归因后反哺知识库与提示词，形成踩过的坑不复现。
卡点 4：可见率会虚高
命中词只做「答案生成后的字符串匹配」，口径干净可复算；但客户如果填的是通用泛词，可见率会虚高，数字好看却没意义。

怎么解：加泛词校验兜住，把明显的通用词挡在词表外，保证指标反映的是真实竞争位置。

报告输出什么

Deliverable

三个指标 + 两类建议。指标定义先定，再谈提升，否则「涨了多少」没法复算。

AI 推荐可见率
正向或中性引用的问题数 ÷ 总测试问题数
前三推荐率
进入前 3 位的问题数 ÷ 被引用问题数
竞品提及率
同问题下竞品出现的比例，用来定位相对差距
两类建议
缺哪种体裁的内容、该投哪些信源，各自落到可执行条目

客户最常直接执行的是建议部分：缺什么体裁、该投哪些信源，都带预估影响。整体形成闭环——评测诊断 → 缺口定位 → 策略建议 → 内容优化 → 再评测验证。

验证与结果

Results

验证口径：随机选取 40 个长尾词，投放到 6 个 AI 平台，同一词表、同一时间窗口、同一批平台，优化前后各跑一次做对照（40 × 6 × 2 = 480 次检测）。内容上线至复采窗口 14 天。

37% → 61%
AI 推荐可见率
12% → 38%
前三推荐率
2天 → 1.5h
单份报告产出时间
7.1 / 10
用户满意度
数字的边界：这套结果来自试点客户的前后对照，样本是单一客户、单一行业，不能当成产品的普适效果承诺。跨行业泛化需要更多客户验证。

产品界面

Interface · 可交互

下面是这个模块的界面演示稿，可以直接点——左侧导航切换平台各功能模块，页面里的按钮和分区都能操作。数据为试点客户口径示例。

360智见GEO · 诊断报告模块 · 界面演示稿 新窗口打开 ↗

演示稿在手机上不易操作，建议用电脑查看；也可以点右上角「新窗口打开」看全屏。

我自己的反思

Reflection
样本量只有 40 词 × 6 平台，结论的泛化范围有限：能说明这套方法在选定词表上有效，不能直接推广到全行业。满意度 7.1 分也说明报告的可读性还有明显空间——客户想要的是「我明天该改哪篇文章」，而不是一堆指标。如果继续做，我会先把建议部分做成可勾选的行动清单，再考虑扩样本。

另外要说清楚的是：「监测—优化—报告」这个闭环，我负责的是其中的诊断报告模块，技术实现基于扣子 + 火山方舟这套低代码栈，不是从零训模型。
← 回到作品列表
Project 02 / Agent

PKPM-Agent · 自然语言驱动结构建模

PKPM 里建模、布荷载、改模型全靠鼠标点选，效率低还容易出错。我要解决的核心问题是：把非结构化的一句话，稳定转换成建模与荷载参数。

时间
2024.12 – 2025.12
团队 / 角色
AI 产品实习生
我负责
需求调研 · 方案设计 · 选型 · 验证
技术栈
Dify · RAG · 多 Agent 编排

项目背景与痛点

Context & Pain

PKPM 是国内结构设计师用得最多的软件之一。但在里面建模、布荷载、改模型，全靠鼠标一层层点选菜单——建一个 8 层框架结构，轴网、构件、层高要反复点几十次，改一个局部还得先在树状目录里翻到对应构件。

我先做竞品分析，调研广联达等国内建模产品的功能与定价；再通过用户访谈和问卷，归纳结构设计师的高频操作场景。最后锁定三件事作为 AI 切入点：

建模
轴网、构件、层高，重复点选最多
布荷载
参数化程度高，最适合用语言表达
改模型
局部修改频繁，手工操作最易出错

这三件事同时满足：发生频率高、操作步骤重复、输入本身可以用自然语言描述清楚。没有从最复杂的计算环节切，是因为计算涉及规范判定和责任归属，不是 AI 现阶段该碰的地方。

所以核心问题被定义成一句话：把非结构化的一句话，稳定转换成建模与荷载参数。

我的动作

What I did
STEP 1
需求调研
竞品分析 + 用户访谈与问卷，归纳高频重复操作场景
→
STEP 2
架构设计
Dify 搭「1 主 + 3 子」Agent，解析—调度—执行闭环
→
STEP 3
模型选型
3 个候选模型在 40 条测试集上做三维度对比
→
STEP 4
原型验证
交互原型跑通，统计四项指标并做 badcase 归因

架构上拆成主 + 子而不是一个大 Agent：主 Agent 判断这句话属于哪类任务、抽取关键参数、缺参数时主动追问，再分派给对应子 Agent。

主 Agent · 意图识别与非结构化输入解析

Router

判断任务类型 → 抽取参数 → 缺参数主动追问 → 分派子 Agent。配套 RAG 知识库补齐领域术语与规范。

子 Agent A · 建模
承接轴网、构件、层信息的建模指令
子 Agent B · 布荷载
承接荷载类型、数值、作用范围
子 Agent C · 改模型
承接定位 + 修改动作的组合指令

拆开的理由：三类任务的参数结构和校验规则差别很大，混在一个提示词里会互相干扰，也没法单独做回归测试。

卡点与解决办法

Problems & Fixes

这部分是我觉得最值得讲的——每一条都是真踩过之后才加的规则。

卡点 1：设计师说话不按格式来
「柱网 8×8 米，共 5 跨×4 跨」和「8 米柱距，横向 5 跨纵向 4 跨」是同一件事，但表达方式无穷多；还经常省略前提，比如不说单位、不说是标准层还是首层。

怎么解：主 Agent 专职做意图识别与参数抽取，配 RAG 知识库补齐领域术语（哪些是同义表达、默认单位是什么）；抽不到的关键参数不猜，主动追问补齐再执行。
卡点 2：一个大提示词越改越糟
最初想用一个 Agent 处理三类任务，结果建模的校验规则会干扰布荷载的参数解析，改好一类另一类就退化。

怎么解：拆成 1 主 + 3 子，每个子 Agent 只管一类任务的参数结构和校验，可以单独回归测试，互不影响。
卡点 3：模型选型凭印象
「感觉这个模型更聪明」不能作为选型依据，尤其成本和时延差很多的时候。

怎么解：建 40 条建筑建模测试集，3 个候选模型跑同一套题，从参数提取准确率、任务执行成功率、响应时延三个维度对比，选性价比最优而不是单项最强的。
卡点 4：改提示词无法判断好坏
早期改完提示词只能拿几条 case 试，这次过了下次可能更差，没有依据。

怎么解：建提示词评测集做回归，每次改完跑整套看总分；收集线上 badcase 归因后反哺知识库与提示词，让踩过的坑不复现。

模型选型的三个维度

Model selection

选取 3 个候选模型，在 40 条建筑建模测试集上评测，从三个维度对比后选定性价比最优的那个：

参数提取准确率
能不能把一句话里的数值和构件抽对
任务执行成功率
抽对之后能不能真的把动作跑完
响应时延
设计师等得起多久，直接影响愿不愿意用

把准确率和成功率拆成两个指标，是因为它们坏在不同地方：抽错参数是理解问题，抽对了跑不完是执行链路问题，归因方式完全不同。

验证与结果

Results

验证口径：构建真实业务场景测试集，统计四项指标。

77%
建模参数提取准确率
81%
任务执行成功率
+23.2%
建模效率提升
3.2 / 5
用户满意度
数字的边界：我交付的是交互原型与方案验证，不是随 PKPM 商业版发布的功能。指标是在自建的真实业务场景测试集上跑出来的，样本规模有限，不代表产品级表现。

产品界面

Interface · 可交互

下面是交互原型，可以直接点——左侧是构件树，右侧是属性面板，底部对话框可以看到「一句话建模」的完整交互过程。

PKPM-Agent · 自然语言建模交互原型 新窗口打开 ↗

这是桌面软件界面，手机上需要横向滑动；建议用电脑查看，或点右上角「新窗口打开」看全屏。

我自己的反思

Reflection
77% 和 81% 都不算能直接上生产的水平。结构设计容错率极低，一个荷载填错的代价远大于省下的点选时间。所以这套方案真正的价值定位应该是「草稿助手 + 强制人工复核」，而不是「自动建模」。满意度 3.2/5 也印证了这点——设计师认可省事，但不敢信。下一步我会先做参数回显与差异确认界面，让人在提交前一眼看清 AI 理解成了什么。
← 回到作品列表
Project 03 / 0→1

Lumode · 一句话生成 3D 模型

普通用户想要一个 3D 模型，得先学会一个专业软件。Lumode 把这件事压成一句话：输入描述，服务端出可编辑、可下载的模型。这个项目从需求到部署都是我一个人做的。

时间
2026 · 持续迭代
角色
独立完成（产品 + 开发 + 部署）
状态
已上线 PC / 移动端
线上地址
lumode3d.net ↗

项目背景与痛点

Context & Pain

普通人想要一个 3D 模型，第一道门槛不是「想不出要什么」，而是「不会操作软件」。Blender 这类专业工具的学习曲线，把绝大多数有需求的人挡在门外。

市面上已有的文生 3D 工具，我用下来卡在三个地方：

  • 装不起：多数方案要求用户先装建模软件或插件，对目标人群等于没有入口。
  • 改不了：给你一个不可编辑的成品网格，好看，但拿不进工作流，改一个尺寸都做不到。
  • 断了就空手：生成链路一旦中间失败，用户什么都拿不到，也不知道为什么。

所以我把产品目标压成两句话：零学习成本（浏览器里输入一句话，全程不接触本地建模软件）、结果可继续用（产出可编辑模型，能下载 .blend 带回自己的流程）。这个项目从需求、开发到部署都是我一个人做的。

我的动作

What I did
STEP 1
定部署形态
把 Blender 放服务端而不是让用户装插件——这是整个产品最关键的一次取舍
→
STEP 2
打通建模链路
一句话 → 结构化参数 → MCP 驱动 Blender 执行 → 回传预览图与工程文件
→
STEP 3
补稳定性
断连重连、异步竞态、缓存与懒加载，这部分占的工作量比建模本身多
→
STEP 4
上云上线
服务器部署、进程守护、反向代理与 HTTPS，做到崩溃自动拉起

核心架构决策是把 Blender 部署在服务端、通过 MCP 驱动。代价很直接：服务器成本和并发压力都归我；换来的是用户侧零安装。对「普通用户」这个目标人群，这个交换我认为是值的——装软件这一步会劝退的人，远比服务器账单更贵。

做的过程中我给自己定了两条铁律，它们后来救过我好几次：

前端是纯透明壳子

Transparency

前端绝不修改用户输入、也绝不美化后端产出。看到什么就是系统真实做出来的什么——否则我自己都没法判断模型到底行不行。

失败必须被记录

Fail loud

所有失败都落日志、可复现，不静默兜底掩盖问题。生成类产品的迭代速度，取决于你有多敢看自己的失败样本。

卡点与解决办法

Problems & Fixes

这一栏是这个项目对我价值最大的部分——它让我对「AI 产品的成本藏在工程细节里」有了非常具体的体感。四条都是真踩过之后才加的机制。

卡点 1：Blender 一断，整条链路就废
服务端和 Blender 之间是长连接，偶发断连时用户看到的就是「建模失败」，什么都拿不到。简单重试没用，因为连接还没回来。

怎么解：做成双层自愈。后端层检测到离线先等重连（最多 60 秒、每 3 秒探一次）再自动重跑；重跑前先清场，新建任务重置场景、改模型任务回滚到原始 .blend，护住用户已有的产出。插件层再加一个看门狗定时探端口，该开却没监听就自己重启。后端层是根本，看门狗只是兜底。
卡点 2：切换会话时两个模型叠在一起
加载变快之后才暴露的 bug：用户快速切会话，旧模型还在下载途中，清理逻辑挡不住，两个模型都被加进场景，画面直接穿模。

怎么解：给每次加载发一个自增序号，下载完成时先比对序号，不是最新那次就直接丢弃不渲染。异步加载 + 快速切换 = 竞态，这条后来成了我写前端的通用自检项。
卡点 3：有的模型接口是「套壳」的
换模型供应商时踩过坑：请求写的是 claude-*，返回的实际是另一家的模型，建模质量直接不达标，而接口表面上完全正常。

怎么解：定了一条验真流程——绕开 SDK 直接发裸 HTTP 请求，看响应 JSON 里的 model 字段是不是真的那个模型。另外加一条硬性要求：生产接口必须国内可直连，不能依赖任何代理工具，否则上线即不可用。
卡点 4：预览图慢，但不是我以为的原因
缩略图加载很慢，第一反应是文件太大或后端慢。实际排查下来，瓶颈在网络链路的跨境延迟上，跟文件大小基本无关——如果照直觉去压缩图片，会白干一整天。

怎么解：给带版本号的资源加长期强缓存，第二次访问不再走网络；列表里的缩略图改成懒加载。同时承认这只是缓解，根治要靠部署位置。先定位再动手，别信直觉。

技术选型的三个判断

Trade-offs

独立做项目最大的好处是每个取舍都得自己承担后果。三个我想清楚了才动手的：

Blender 放服务端，不放用户本地
用成本换门槛。服务器费用和并发压力我承担，用户侧零安装。判断依据是目标人群——会被「先装个软件」劝退的人，正是这个产品要服务的人。
前端不做任何补救逻辑
很多人会在前端偷偷修正输入、美化输出，短期体验更好。我选择不做，因为一旦前端会撒谎，我就失去了判断模型真实能力的唯一窗口。
检索优先、生成兜底（在探索）
现成模型库里能检索到的，不必每次都重新生成，质量和速度都更好。难点在智能匹配与版权协议的合规判断，这条目前还是方向，没有落地。

验证与结果

Results

需要先说清楚：这个项目我能验证的是工程可用性，不是商业效果。所以下面这几个数字都是可复核的部署与机制事实，不是用户数据。

已上线
PC / 移动端浏览器均可访问
双层
后端 + 插件两级断连自愈
60s
重连等待窗口，每 3s 探测一次
0
真实规模用户数据（如实标注）

服务端跑的是无界面 Blender，配了进程守护，崩溃和开机都能自动拉起，这一条我重启机器验证过。全链路从浏览器输入到拿到可下载的 .blend 文件是通的。

数字的边界：上面没有一个是效果指标，因为我确实没有。「已上线」不等于「被验证」——我不会把部署成功包装成商业成功。复杂描述的建模成功率目前还不稳定，这是已知短板。

产品界面

Interface
Lumode 一句话生成3D模型界面
Lumode 线上界面 · 输入一句话，得到可编辑模型

我自己的反思

Reflection
我留着这个项目的价值，不是证明我能做爆款，而是证明我能独立把一个 AI 想法推到线上、并且诚实地知道它差在哪。

已知短板很清楚：复杂描述的成功率还不稳定；服务端 Blender 的并发成本在用户量上来后会变成硬约束，现在这套架构撑不住规模；还有一个我一直没做完的事——请求卡住时缺少超时自动清理，网络切换的场景下会留下永久 pending 的任务，我知道该怎么修，但还没修。

如果重做一次，我会更早把稳定性当成第一优先级。这个项目里我花在「让链路不断」上的时间远多于「让模型更好」，一开始我以为这是意外，后来才明白对生成类产品来说，这本来就是主要工作量。

打开线上产品试试 ↗

← 回到作品列表
Project 04 / Research

顶刊论文 · 可解释深度学习预测模型

VMD-SSA-ATT-BiLSTM 混合模型，配 SHAP 可解释性分析与完整消融实验。放进作品集不是为了炫学术，而是因为我做 AI 产品的那套方法论就是从这儿来的。

角色
第一作者
状态
已发表（顶刊）
方法
VMD · SSA · Attention · BiLSTM
可解释性
SHAP + 消融实验

模型是怎么搭起来的

Method

不是把几个时髦模块堆在一起，每一层都对应一个具体问题：

VMD
变分模态分解，先把非平稳信号拆成更规律的分量，降低直接建模难度
SSA
麻雀搜索算法做超参寻优，避免人工调参带来的偶然性
ATT
注意力机制让模型自己决定关注哪些时间步
BiLSTM
双向长短期记忆，同时利用前后文时序信息

为什么必须做消融实验

Ablation

四个模块叠在一起效果好，不代表每个模块都有用——很可能其中一个纯属装饰。所以我逐模块拆开验证各自的贡献度。这个习惯直接迁移到了产品工作里：

做 GEO 和 PKPM-Agent 时，我坚持先定指标口径、固定评测集、再改一个变量，就是因为写论文时被消融实验教过——不控制变量的「效果提升」，你没法回答「到底是哪一步起了作用」，下次也没法复现。

SHAP：让模型说出理由

Explainability

预测准不是终点，能解释才敢用。用 SHAP 做特征归因，量化每个输入特征对单次预测的推动方向和幅度。这是我后来在产品里坚持「结论必须有据可依」（RAG 锚定 + 结构化输出）的同一个思路——不可解释的高分，在真实决策场景里是负资产。

全局解释
哪些特征整体上最重要
局部解释
这一次预测为什么是这个值
方向性
特征是往上推还是往下拉

这段经历给我留下什么

Takeaway
  • 先定评价标准，再开始优化。否则「变好了」只是错觉。
  • 拆开看贡献。整体有效不等于每部分有效，产品功能也一样。
  • 可解释性是信任的前提。B 端客户和结构设计师都不会为一个黑盒买单。
  • 数据能力要能自己动手。Python / SQL、埋点设计、评测集搭建，不必等分析师排期。

查看论文全文 PDF ↗