项目背景与痛点
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
验证口径:构建真实业务场景测试集,统计四项指标。
数字的边界:我交付的是交互原型与方案验证,不是随 PKPM 商业版发布的功能。指标是在自建的真实业务场景测试集上跑出来的,样本规模有限,不代表产品级表现。
产品界面
Interface · 可交互
下面是交互原型,可以直接点——左侧是构件树,右侧是属性面板,底部对话框可以看到「一句话建模」的完整交互过程。
这是桌面软件界面,手机上需要横向滑动;建议用电脑查看,或点右上角「新窗口打开」看全屏。
我自己的反思
Reflection
77% 和 81% 都不算能直接上生产的水平。结构设计容错率极低,一个荷载填错的代价远大于省下的点选时间。所以这套方案真正的价值定位应该是「草稿助手 + 强制人工复核」,而不是「自动建模」。满意度 3.2/5 也印证了这点——设计师认可省事,但不敢信。下一步我会先做参数回显与差异确认界面,让人在提交前一眼看清 AI 理解成了什么。
← 回到作品列表
Project 03 / 0→1
Lumode · 一句话生成 3D 模型
普通用户想要一个 3D 模型,得先学会一个专业软件。Lumode 把这件事压成一句话:输入描述,服务端出可编辑、可下载的模型。这个项目从需求到部署都是我一个人做的。
项目背景与痛点
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
需要先说清楚:这个项目我能验证的是工程可用性,不是商业效果。所以下面这几个数字都是可复核的部署与机制事实,不是用户数据。
服务端跑的是无界面 Blender,配了进程守护,崩溃和开机都能自动拉起,这一条我重启机器验证过。全链路从浏览器输入到拿到可下载的 .blend 文件是通的。
数字的边界:上面没有一个是效果指标,因为我确实没有。「已上线」不等于「被验证」——我不会把部署成功包装成商业成功。复杂描述的建模成功率目前还不稳定,这是已知短板。
产品界面
Interface

Lumode 线上界面 · 输入一句话,得到可编辑模型
我自己的反思
Reflection
我留着这个项目的价值,不是证明我能做爆款,而是证明我能独立把一个 AI 想法推到线上、并且诚实地知道它差在哪。
已知短板很清楚:复杂描述的成功率还不稳定;服务端 Blender 的并发成本在用户量上来后会变成硬约束,现在这套架构撑不住规模;还有一个我一直没做完的事——请求卡住时缺少超时自动清理,网络切换的场景下会留下永久 pending 的任务,我知道该怎么修,但还没修。
如果重做一次,我会更早把稳定性当成第一优先级。这个项目里我花在「让链路不断」上的时间远多于「让模型更好」,一开始我以为这是意外,后来才明白对生成类产品来说,这本来就是主要工作量。
打开线上产品试试 ↗
← 回到作品列表
Project 04 / Research
顶刊论文 · 可解释深度学习预测模型
VMD-SSA-ATT-BiLSTM 混合模型,配 SHAP 可解释性分析与完整消融实验。放进作品集不是为了炫学术,而是因为我做 AI 产品的那套方法论就是从这儿来的。
方法
VMD · SSA · Attention · BiLSTM
模型是怎么搭起来的
Method
不是把几个时髦模块堆在一起,每一层都对应一个具体问题:
VMD
变分模态分解,先把非平稳信号拆成更规律的分量,降低直接建模难度
SSA
麻雀搜索算法做超参寻优,避免人工调参带来的偶然性
BiLSTM
双向长短期记忆,同时利用前后文时序信息
为什么必须做消融实验
Ablation
四个模块叠在一起效果好,不代表每个模块都有用——很可能其中一个纯属装饰。所以我逐模块拆开验证各自的贡献度。这个习惯直接迁移到了产品工作里:
做 GEO 和 PKPM-Agent 时,我坚持先定指标口径、固定评测集、再改一个变量,就是因为写论文时被消融实验教过——不控制变量的「效果提升」,你没法回答「到底是哪一步起了作用」,下次也没法复现。
SHAP:让模型说出理由
Explainability
预测准不是终点,能解释才敢用。用 SHAP 做特征归因,量化每个输入特征对单次预测的推动方向和幅度。这是我后来在产品里坚持「结论必须有据可依」(RAG 锚定 + 结构化输出)的同一个思路——不可解释的高分,在真实决策场景里是负资产。
这段经历给我留下什么
Takeaway
- 先定评价标准,再开始优化。否则「变好了」只是错觉。
- 拆开看贡献。整体有效不等于每部分有效,产品功能也一样。
- 可解释性是信任的前提。B 端客户和结构设计师都不会为一个黑盒买单。
- 数据能力要能自己动手。Python / SQL、埋点设计、评测集搭建,不必等分析师排期。
查看论文全文 PDF ↗