1. Dify 工作流体系

原客服产品依赖规则引擎和关键词匹配，复杂问题回答能力有限。引入大模型后面临领域知识不足的挑战——相比微调（成本高、知识更新频繁且多租户隔离开销大），RAG 将知识检索与生成解耦，更灵活可控。在此基础上我搭建了 Dify 可编排工作流，核心思考是将 AI 能力拆成独立节点而非单体功能，这样后续扩展只需编排节点无需改核心逻辑。串联了会话总结、猜你想问、客户画像、话术引导、客户留资等节点，共享底层 RAG 检索能力。客户自助解决率提升、人工介入率下降，新客户接入只需配置知识库和工作流模板即可交付。

2. 助手 SDK

随着产品成熟度提升，千篇一律的风格不足以支撑客户多样化的需求。经过探索与思考，我设计了一套 headless SDK 方案，采取分层设计：与平台和 UI 无关的 core SDK 提供了足够的扩展能力供用户个性化定制，UI 层完全交给客户。采用 Rollup + UMD 构建确保兼容任意前端框架，通过发布-订阅模式实现事件驱动通信。SDK 的推出降低了客户集成门槛，推动了产品的多场景落地。

3. 圆野 AI 数据分析平台

从零构建的 AI SaaS 产品，面向企业、商户提供行情、趋势等数据的自然语言分析能力。我负责 Agent 层和后端体系搭建。

Agent 层：基于 LangGraph + DeepAgent + LlamaIndex 构建数据分析 Agent（自然语言 → 意图理解 → 数据检索 → 分析执行 → 结果返回），核心能力包括上下文摘要压缩（滑动窗口+摘要压缩）、人机交互（任务中断恢复）、记忆管理（跨会话偏好持久化）、Skill 注入（业务分析技能按需注册）。

后端体系：积分设计上数据库只存"总积分"和"已使用积分"，扣费做原子递增避免高并发数据竞争，无需引入分布式锁。套餐过期与积分重置采用惰性检查——不在后台定时扫描，而是在用户发起查询时顺带校验，按规则降级或重置。这样做只检查活跃用户、无状态滞后、也不需要额外任务调度基础设施。

1. 活动模板引擎

推广活动原依赖逐个定制开发，重复工作量大。核心矛盾是如何在"交付效率"和"页面性能"之间取舍：CSR 加载慢 SEO 差；SSR 在高流量下服务器压力大；SSG 兼具 SEO 和 CDN 分发且适合静态活动页，代价是 HTML 数量 = 国际化语言数 × 活动模板数——但这仅影响编译阶段，可接受。最终选 Next.js SSG，将页面组件化拆分，配合可视化面板实现运营自助配置、一键发布。

2. 组件库建设

主站重构面临两难：从零写组件库成本太高，全用第三方又难以对齐设计规范。我选择对 shadcn 二次封装而非自研——shadcn 提供了高质量基础，我只需对齐 Design Token 做定制，实现明暗主题和 99% 设计还原度，同时沉淀排行榜、交易面板等业务组件，组件层面支持 H5 适配和响应式布局。

1. 微前端架构

所有应用部署在 Bubble 平台，独立编译部署导致全局 CSS 互相污染，40+ 应用时维护成本急剧上升。对比三种方案：qiankun 接入成本高、侵入性强；Module Federation 灵活但配置复杂、沙箱隔离弱；Wujie 基于 iframe 天然 CSS/JS 沙箱、子应用几乎零改动即可接入。考虑到已有 40+ 应用不可能全部重构，Wujie 的"无感迁移"是关键决策点。最终设计标准化接入规范和通信机制，推广至 20+ 子应用并建立 CI/CD 流程。

2. PDF 报表重构

原有前端 pdfmake 方案渲染性能差且无法支持定时推送等后端调度场景。核心问题是 PDF 生成逻辑到底应该放在前端还是后端——后端方案天然支持定时任务和模板化管理，且 Playwright 渲染质量远超 JS 库。最终改用 Flask + Jinja2 + Playwright 服务端渲染，支持定时推送和自定义模板。

1. DWG 大文件在线预览

需支持 10000px+ 分辨率工程图纸在线预览，纯前端方案浏览器无法承载。思考后决定将"解析"和"渲染"分离：后端专注 DWG 解析输出瓦片图，前端专注交互体验。前端采用双缓存（离屏 Canvas + 显示 Canvas）消除缩放闪烁，CSS3 transform 硬件加速实现流畅拖拽，最终实现本地软件级的浏览体验。

2. 网架规划系统

基于 Openlayers 实现电网设备布局和线路规划。核心挑战是让工程师在浏览器地图上获得接近 CAD 的操作体验。我实现了智能打断（交叉点自动分割）、自动合并、磁性吸附和框选等交互，并基于 Canvas 和几何算法绘制设备剖面图，Three.js 实现 3D 展示，支持 10+ 种设备的 2D/3D 可视化。