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

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

AI PRODUCT MANAGER · 2026 应届硕士

01 年生，北京工业大学土木工程硕士，本科毕业于聊城大学，两段学业都在专业前列。 研究生阶段做深度学习预测建模，以一作发表 SCI 一区 Top 期刊论文一篇。 也正是那段经历让我想换个位置——比起把模型调得更准，我更想解决「怎么让它真的被人用起来」， 所以转做了 AI 产品。

两段 AI 产品实习：

  • 360集团　做 360智见 GEO　诊断报告模块。
  • 北京构力科技　做 PKPM-Agent　自然语言建模。

一个个人项目：

  • 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

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

01B端 SaaS
360智见 GEO 诊断报告界面
2026.04 – 2026.08 · 360集团

360智见 GEO
诊断报告模块

AI 搜索成了新的流量入口。我负责诊断报告模块，验证「监测—优化—报告」闭环在 B 端跑得通。

37% → 61%AI 推荐可见率
2天 → 1.5h单份报告产出
GEO读完整项目 ✎ →
02垂直行业工具
PKPM-Agent 交互界面
2024.12 – 2025.12 · 北京构力科技

PKPM-Agent
自然语言驱动建模

结构设计师建模全靠鼠标点选。我把它做成一句话交互：Dify「1主+3子」Agent 架构。

77% / 81%参数提取 / 执行成功
+23.2%建模效率提升
AGENT读完整项目 ✎ →
03个人项目 · 已上线
Lumode 生成 3D 模型界面
2026 · 独立完成

Lumode
一句话生成 3D 模型

从想法到线上产品全是我一个人做的：需求、架构、前后端、部署、兜底策略。

PC + 移动双端已上线
生成→可编辑→可下载建模闭环
0 → 1读完整项目 ✎ →
04一作 · 已发表
SHAP
可解释性分析
硕士期间 · 顶刊

顶刊论文
可解释深度学习

VMD-SSA-ATT-BiLSTM 混合模型，配 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 产品的那套方法论就是从这儿来的。

角色
第一作者
状态
已发表 · SCI 一区 Top
期刊
Tunnelling and Underground Space Technology
方法
VMD · SSA · Attention · BiLSTM · SHAP

项目背景与痛点

Context & Pain

盾构掘进会扰动周边土体，造成地表沉降。沉降一旦超出允许范围，就会损伤既有建筑，严重时引发工程事故。所以施工期间需要提前预测沉降趋势，把预警窗口留出来。

机器学习已经被广泛用来做这件事，但我在梳理已有模型时发现它们卡在同一个地方：

  • 只顾调参，不管数据本身：多数模型把精力放在超参优化和输入权重分配上，却没处理沉降时序数据本身的非平稳性和监测噪声。
  • 抓不住突变：地表沉降会出现局部急剧变化，而这些突变段恰恰是预警最需要的部分，偏偏最难拟合。
  • 算得准但说不出理由：给一个高精度预测值，却无法回答「是哪些施工参数把沉降推上去的」，现场没法据此调整。

于是我把目标定成两条：先降噪再建模，以及预测完要能归因——不可解释的高分，在真实施工决策里没人敢用。

我的动作

What I did
STEP 1
拆信号
用 VMD 把原始沉降序列分解成多个较平稳的分量，先把非平稳性和随机噪声压下来
→
STEP 2
调参数
引入麻雀搜索算法 SSA 自动寻优 BiLSTM 超参，替掉人工试参的偶然性
→
STEP 3
分权重
加注意力机制，让模型自己决定该重点看哪些时间步的特征
→
STEP 4
做归因
用 SHAP 量化每个输入特征对预测结果的推动方向和幅度

四个模块不是把时髦方法堆在一起，每一层都对应上面某一个具体痛点：

VMD
变分模态分解，对应「数据非平稳、有噪声」
SSA
麻雀搜索算法寻优，对应「人工调参不可复现」
ATT
注意力机制，对应「抓不住局部突变」
BiLSTM
双向长短期记忆，同时利用前后文时序信息

卡点与解决办法

Problems & Fixes

这一栏是这篇论文对我后来做产品影响最大的部分——每一条都是「怎么证明这个东西真的有用」的方法问题，不是模型技巧。

卡点 1：分解成几个分量，没有标准答案
VMD 要先指定模态分量个数 K。K 太小噪声没除掉，太大又会把信号本身切碎，而这个值没有理论最优解。

怎么解：不靠拍脑袋。对同一个监测点逐个 K 值跑 BiLSTM，比较 RMSE、MAE、R² 三项指标的变化趋势，再结合分解阈值需小于 0.2 这个约束，选定 K。先定判断标准，再选参数，而不是反过来。
卡点 2：四个模块叠着效果好，但哪个真有用？
整体指标提升，不代表每个模块都在贡献，很可能其中一个纯属装饰。

怎么解：做完整消融实验，逐模块拆开量化贡献：VMD 让 MAE 降低 14.5%、SSA 降低 22.81%、ATT 降低 6.94%。还发现三个模块同时消融后的精度下降幅度大于单独消融的累加，说明它们之间存在协同效应。
卡点 3：单次结果好，可能只是运气
时序模型对数据划分和初始化敏感，一次跑赢不能说明稳定。

怎么解：做 1000 次重采样检验，看 RMSE 和 R² 是否始终稳定；再用泰勒图把标准差、相关系数、中心化均方根差三个维度放在一张图上和四个对比模型一起看，而不是只报一个单点指标。
卡点 4：预测准了，现场还是不知道该改什么
一个沉降预测值本身不构成施工建议，工程师需要知道该调哪个参数。

怎么解：用 SHAP 做特征归因，把影响程度分出层级——隧道平均埋深、盾构总推力、注浆量、隧道直径影响最大；注浆压力、最大掘进速度、顶底土层变形模量与黏聚力、刀盘扭矩与转速影响中等；盾构俯仰角、土层泊松比影响最小。这样输出的就不只是数值，而是可以排优先级的调整方向。

验证口径

Validation setup

先说清楚是怎么验的，再看数字——这是我在产品工作里一直保留的习惯。

工程案例
深圳大亚湾城际隧道
数据规模
3 个监测点、412 天实测沉降数据
输入特征
盾构机参数 + 地质参数 + 几何参数
对比基线
4 个已有主流预测模型

验证与结果

Results

相比其他四个模型，VSA-BiLSTM 在误差类指标上全面下降、拟合类指标上全面上升（下面是均值的改善区间）：

↓36.1–58.1%
MAE 平均绝对误差
↓32.7–55.6%
RMSE 均方根误差
↓36.9–61.2%
MAPE 平均绝对百分比误差
↑10.5–50.8%
R² 拟合优度

其中一个对照最能说明问题：VSA-BiLSTM 的 RMSE 比单独的 BiLSTM 低 32.7%——同样的主干网络，差距全部来自 VMD 降噪和 SSA 寻优这两层，这就把「提升是哪来的」回答清楚了。稳健性方面，泰勒图显示标准差比其他模型低 6.39–30.66%、相关系数高 6.67–31.91%、中心化均方根差低 28–64.7%，且 1000 次重采样后仍保持低 RMSE、高 R²。

数字的边界：这些结果是在历史数据上跑出来的，说明模型具备预警潜力，但实时应用还需要进一步测试；样本来自单一隧道工程的三个监测点，推广到其他地质条件前需要重新验证。这一条是论文里我自己写下的限制，不是事后补的免责声明。

论文原文

Full paper

完整方法、公式推导、消融实验与 SHAP 分析图都在原文里。发表于 Tunnelling and Underground Space Technology（Elsevier，第 168 卷，2026 年，文章号 107216），我是第一作者。

查看论文全文 PDF ↗

我自己的反思

Reflection
这篇论文放进作品集不是为了证明我会搭模型，而是因为我做 AI 产品的那套方法就是从这儿来的：先定评价标准再开始优化，否则「变好了」只是错觉；拆开看每部分的贡献，整体有效不等于每个模块都有用；把边界写清楚，比把数字说满更重要。

后来做 GEO 和 PKPM-Agent 时我坚持先定指标口径、固定评测集、每次只改一个变量，坚持结论必须有据可依（RAG 锚定 + 结构化输出），都是这段经历留下的。

要说局限：这是学术研究，不用面对真实用户、也不用考虑交付成本和迭代速度，这三件事恰恰是产品工作里最难的部分。所以我没把它当成产品经验来讲，它是方法论的来源。