← 全部作品

CASE STUDY / 03

2024.11 - Now

Enterprise AI Systems

superun FDE

superun FDE / AI 工作坊 · 企业系统交付

把企业现场的问题快速变成可操作 Demo,再把被客户认可的方向推进为正式交付。

DESIGN × PRODUCT × AI03 / KK

项目概念视觉 · 用于解释系统结构

把商家需求转化为网站、移动端应用、表单与运营面板的多端构建工作台
把复杂的系统,变成可理解的体验。CONCEPT VISUAL
我的角色
AI Workshop Mentor / FDE
项目阶段
2024.11 - Now
案例性质
公开案例 · 已脱敏
涉及能力
Vibecoding · FDE · Rapid Prototype

01 / THE BRIEF

先用一分钟,
看清这件事。

进入完整过程

把企业现场的问题快速变成可操作 Demo,再把被客户认可的方向推进为正式交付。

在 superun 阶段,我既是线下 AI 工作坊导师,也是进入企业定制需求的 FDE。工作坊帮助负责人自己搭建;当业务复杂或能力不足时,我会快速理解现场、画出交互原型、搭出 Demo,让客户先确认方向,再衔接技术团队实施。

工作坊
指导 B 端企业负责人识别核心任务,并现场搭建符合自身业务的系统
FDE 角色
理解业务、整理流程与数据、输出交互原型和可操作 Demo,再衔接技术实施
代表案例
招聘简历智能评分、注塑机选型推荐与产品参数管理后台
系统范围
覆盖招聘、工业选型、采购、工单与票据管理等企业业务系统

公开展示已脱敏。内部数据与未公开指标不在本案例中展开。

项目局面

先把真实阻力和责任范围放在一起,避免只看到一串功能。

企业负责人理解业务,却不一定具备系统搭建能力;而传统定制开发在需求沟通阶段缺少可操作的共同语言,容易在实施后才发现方向偏差。

不能忽略的约束

  • 客户来自招聘、制造、采购、工单和票据等不同领域,业务语言、数据结构和权限差异很大。

  • 招聘简历可能来自邮件,工业产品参数分散在 Excel 与 PDF,原始资料并不适合直接进入系统。

  • Demo 需要足够真实地验证任务,又不能把未确认的数据和交互误解成最终交付承诺。

我实际负责的工作

  • 指导 B 端企业负责人把业务需求转化为可搭建的系统任务与 Workflow。

  • 为某公司搭建招聘管理系统:将 Boss 直聘候选人邮件沉淀进系统,由智能体结合岗位要求和硬性条件为简历评分。

  • 为某注塑机制造企业设计 B2C 技术顾问和机型匹配推荐系统,并落地产品参数数据管理后台。

  • 推进采购、工单、票据管理等多类 ERP 系统的原型验证与交付衔接。

Delivery flow

快不是省略步骤,而是更早看见问题。

vibecoding 缩短了实现时间,但项目仍然需要清楚的任务定义、信息结构、反馈判断和交付边界。这四步是我在商家应用项目中反复使用的推进骨架。

01

先进入业务现场

业务流程 / 数据来源 / 核心任务

从负责人当前使用的邮件、Excel、PDF 与人工流程入手,确认角色、数据、关键判断和最消耗精力的工作。

02

把经验翻译成系统规则

领域规则 / Agent Workflow / 权限边界

将岗位匹配、机型选择或业务审批中的专家判断拆成字段、约束、评分依据、异常路径与人工复核节点。

03

快速搭出可操作 Demo

交互原型 / 可操作 Demo / 现场验证

用交互原型和 vibecoding 让客户真正完成一次核心任务,以真实操作验证理解,而不是只在会议里确认文档。

04

把认可的方向交给技术落地

范围确认 / 实施说明 / 交付衔接

客户确认 Demo 后,再补齐数据来源、系统边界、异常处理和交互说明,衔接公司技术团队完成正式交付。

THE PROCESS / 推进路径

不止做出来。
更要想清楚。

01

执行动作

在线下工作坊中先帮助企业负责人识别核心任务,再指导其用 AI 和 vibecoding 搭建业务原型。

02

执行动作

对定制需求以 FDE 角色进入业务现场,快速拆解流程、数据和角色权限,输出可交互 Demo。

03

执行动作

在客户认可 Demo 后,将经过验证的结构、边界和交互说明带回公司,衔接技术团队完成正式交付。

Supporting material / disclosure

用图示补充过程,也说明素材性质。

以下画面依据公开案例中的工作结构生成,用来解释需求、原型和交付之间的关系。它们不是客户后台截图,也不包含内部数据。

01 / Discovery model · 概念重建:用目标、用户、页面模块、关键动作与范围边界组织需求,不对应任何真实客户内部文档。

从业务目标、用户任务到页面地图和交付边界的需求结构示意图

01 / Discovery model

先把口头需求变成可以检查的结构。

概念重建:用目标、用户、页面模块、关键动作与范围边界组织需求,不对应任何真实客户内部文档。

02 / Responsive prototype · 概念重建:展示目录、预约、表单与状态模块的响应式关系,不是实际交付界面。

同一商家业务应用在桌面、平板与手机端的响应式原型示意

02 / Responsive prototype

让客户在不同设备上提前看见核心任务。

概念重建:展示目录、预约、表单与状态模块的响应式关系,不是实际交付界面。

03 / Delivery review · 概念重建:用视觉方式说明方向调整、必要修正、范围追加和最终检查的关系。

版本对比、反馈分类、范围判断与发布检查组成的交付复盘场景

03 / Delivery review

把反馈、范围和版本决定放在同一张图里。

概念重建:用视觉方式说明方向调整、必要修正、范围追加和最终检查的关系。

结果与验证

最后形成了什么,又凭什么判断方向成立。

敏感指标不在公开案例中展开,这里只保留可验证的项目结果、判断方式和可复用资产。

已形成的阶段结果

  • 让企业负责人可以在工作坊中直接参与系统定义和原型判断。

  • 通过可操作 Demo 把抽象需求提前变成可验证的业务流程,降低定制交付中的方向风险。

  • 覆盖招聘、工业选型、采购、工单与票据管理等多种企业业务系统。

留下的方法

FDE 的价值在于把技术能力、客户现场与产品判断连接起来,而不是只负责更快写出页面。

可操作 Demo 是企业定制项目里非常有效的共同语言,可以显著提前发现业务理解偏差。

证据账本

先说清责任,再讨论成果。

这张表区分本人所有权、团队协作、已确认事实和公开材料无法证明的部分。

我本人负责
作为深入企业现场的 FDE 与 AI 导师,负责一线业务解构、全栈高保真 Demo 研发与交付技术方案对齐。
协作边界
由本人在客户现场用可用 Demo 锁定确定性范围与交互体验,再将架构与规格说明交付研发团队进行规模化集成。

已确认结果

  • 代表性方案覆盖:招聘管理智能简历打分、注塑机工业匹配顾问系统。
  • 扩展覆盖采购协同、工单流转与票据自动归集等多类企业 ERP 系统。

KEEP EXPLORING / 下一个案例

登科星

面向高考志愿信息差的微信小程序,已服务 4000+ 用户

在移动端收集分数、位次、地域与专业偏好,并生成院校比较结果的高考志愿智能体