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

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

AI PRODUCT MANAGER · 2026 应届硕士

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

何娜
「先想清楚,再动手 ✎」
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」。
← 回到作品列表
Project 01 / GEO

360智见 GEO · 诊断报告模块

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

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

先说清楚边界

Scope first
我不是这个产品的负责人。「监测—优化—报告」这个闭环,我负责的是其中诊断报告模块;技术实现是基于扣子 + 火山方舟这套低代码栈搭的,不是从零训模型。写在前面,是因为我更希望被问「你做的那部分怎么想的」,而不是被误认为做了全部。

背景与问题

Context

2025 年下半年起,AI 搜索逐渐成为用户获取信息的主要入口,生成式引擎优化(GEO)成了企业新的流量增长点。但 B 端客户当时面临三个具体的痛:

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

我的四步动作

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

关键决策:怎么让结论不是编的

Anti-hallucination

诊断报告最怕的不是不准,是「听起来很有道理但其实是模型编的」。客户看到一条编造的竞品数据,整份报告的信任就归零了。所以我做了三件事:

RAG 知识库锚定
搭客户产品信息 RAG 库,切片 1000–1500 字、top_K=5、召回权重=1,让诊断结论必须落在检索到的事实上。
结构化 JSON 强约束
规定输出字段与格式,模型不能自由发挥叙事,也方便下游报告模板直接渲染。
提示词评测集 + badcase
迭代提示词时用固定评测集回归,badcase 归因后反哺知识库与提示词,不靠单次手感调优。

报告输出什么(三指标 + 两建议)

Deliverable
AI 推荐可见率
目标词在 AI 回答中被提及的比例
前三推荐率
被提及且位置进入前三的比例
竞品提及率
同问题下竞品出现的比例,用来定位相对差距
两类建议
文章优化建议 + 信源投放建议,各自可执行

形成完整闭环:评测诊断 → 缺口定位 → 策略建议 → 内容优化 → 再评测验证。指标定义先定,再谈提升,否则「提升了多少」没法复算。

效果验证与结果

Results

验证口径:随机选取 40 个长尾词,投放到 6 个 AI 平台,对比诊断报告优化前后的三项指标。

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 编排

先说清楚边界

Scope first
我交付的是交互原型与方案验证,不是随 PKPM 商业版发布的功能。指标是在自建的真实业务场景测试集上跑出来的,样本规模写在下面,可以直接核对。

为什么切「建模 / 布荷载 / 改模型」这三件事

Why here

先做竞品分析,调研广联达等国内建模产品的功能与定价;再通过用户访谈和问卷,归纳结构设计师的高频操作场景。三件事同时满足:发生频率高、操作步骤重复、输入本身可以用自然语言描述清楚——所以选它们作为 AI 切入点,而不是从最复杂的计算环节切。

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

架构:1 主 + 3 子 Agent

Architecture

基于 Dify 搭「解析 - 调度 - 执行」闭环,并配套 RAG 知识库补齐领域术语与规范。

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

Router

判断用户这句话属于哪类任务,抽取关键参数,缺参数时主动追问,再分派给对应子 Agent。

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

拆成主+子而不是一个大 Agent,是因为三类任务的参数结构和校验规则差别很大,混在一个提示词里会互相干扰,也没法单独回归测试。

模型选型:不靠感觉,靠三维度对比

Model selection

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

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

同时建立提示词评测集,收集 badcase 做归因,反哺知识库和提示词调优——让每次改提示词都能验证是变好了还是变坏了。

结果

Results

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

77%
建模参数提取准确率
81%
任务执行成功率
+23.2%
建模效率提升
3.2 / 5
用户满意度

原型演示

Prototype
PKPM-Agent 自然语言建模原型界面
PKPM-Agent 交互原型 · 一句话驱动建模与布荷载

我自己的反思

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

Lumode · 一句话生成 3D 模型

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

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

要解决的问题

Problem

3D 建模的门槛不在于「想不出要什么」,而在于「不会操作软件」。市面上的文生 3D 工具大多给你一个不可编辑的成品网格——好看,但改不了,也拿不进工作流。所以我把产品目标定成两句话:

  • 零学习成本:用户全程不接触本地建模软件,浏览器里输入一句话就行。
  • 结果可继续用:产出的是可编辑模型,能下载 .blend 文件带回自己的流程里。

架构决策:Blender 放在服务端

Architecture

核心决策是把 Blender 部署在服务端、通过 MCP 驱动,而不是让用户装插件。代价是服务器成本和并发压力,换来的是用户侧零安装——对「普通用户」这个目标人群,这个交换是值的。

01
意图解析
一句话 → 结构化建模参数
02
MCP 驱动
调 Blender 执行建模脚本
03
渲染回传
预览图 + 可编辑工程文件
04
兜底
失败降级与重连,不让用户空手而归

真正难的地方(踩过的坑)

Engineering pitfalls

这个项目让我对「AI 产品的成本在工程细节里」有了很具体的体感。挑三个说:

双层 MCP 重连
服务端与 Blender 之间是长连接,一断整条链路失败。做了分层重连与状态检测,而不是简单重试。
loadToken 竞态
用户连续提交时,后到的结果可能覆盖先到的界面。用 token 校验保证只渲染当次请求的结果。
缓存与懒加载
模型文件体积大,首屏必须先给预览、后加载工程文件,否则移动端等待感极差。

我给自己定的两条铁律

Principles

前端是纯透明壳子

Transparency

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

失败必须被记录

Fail loud

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

产品界面

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

我自己的反思

Reflection
目前它还没有真实规模的用户数据,我不会拿「上线了」当成商业验证。已知的短板很清楚:复杂描述的成功率还不稳定,服务端 Blender 的并发成本在用户量上来后会变成硬约束。我留着它的价值不是证明我能做爆款,而是证明我能独立把一个 AI 想法推到线上、并且诚实地知道它差在哪

打开线上产品试试 ↗

← 回到作品列表
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 ↗