FcDesigner Pro 创新需求总纲

日期：2026-08-23
范围：上一轮产品分析中的 14 个重磅能力
代码基线：designer3.0 v6.4.0（Vue3 + Element Plus，无现成单测）
文档基线：fc-design-pro/src

本文是 14 个独立子系统 的需求与架构总纲，不是一份能一次落地的单体规格。每个子系统有自己的实现计划，见 docs/superpowers/plans/。

1. 产品约束（所有方案必须遵守）

保持 SDK 基因。 设计器继续通过 rule + options + @save 交给宿主。不把登录、租户、数据库做进 FcDesigner.vue。
新能力做成可开关模块。 一律走 config.show* + config.<module>，默认关闭或仅在显式接入 adapter 后开启。
不要继续膨胀 FcDesigner.vue。 该文件已超过 3700 行。纯逻辑进 designer3.0/src/modules/<name>/，UI 进 designer3.0/src/designer/<name>/。
宿主适配器优先于官方后端。 官方可以提供参考实现（examples/platform/），但运行时只依赖 adapter 接口。
YAGNI。 每个模块的第一期只做最小可售卖闭环，不做宜搭级平台。

2. 子系统拆分与依赖

text

00 共享基座（snapshot / HostAdapter / vitest）
 ├─ P0-1 Schema 版本治理
 ├─ P0-2 文档转表单
 ├─ P0-3 表单即应用        ──依赖 P0-1 的 snapshot
 └─ P0-4 轻量审批流        ──依赖已有 roles/permissions


P1-1 跨运行时（协议冻结 + React 子集）
P1-2 数据中台（adapter + 可选参考服务）
P1-3 套打设计器
P1-4 运行时 AI Agent
P1-5 双模设计器            ──几乎只组合现有 show* 开关
P1-6 完整移动端 + 渠道


P2-1 行业包 / 模板市场
P2-2 协同设计
P2-3 私有化 AI / 信创
P2-4 插件商店

推荐开工顺序：00 → P0-1 → P0-2 → P1-5 → P0-3 → P0-4。双模设计器成本低、能立刻服务业务人员，插在 P0-2 之后做。

3. 共享契约

所有模块读写同一份快照，不直接操作画布内部状态。

// designer3.0/src/modules/shared/types.js 中落地的语义（JSDoc）

/**
 * @typedef {Object} FormSnapshot
 * @property {'1.0.0'} format
 * @property {string} formId
 * @property {string} name
 * @property {string} [description]
 * @property {import('@form-create/element-ui').Rule[]} rule
 * @property {import('@form-create/element-ui').Options} options
 * @property {SchemaTable[]} schema
 * @property {string} createdAt
 */

 /**
 * @typedef {Object} HostAdapter
 * @property {(p: {snapshot: FormSnapshot, rule: string, options: string}) => Promise<{id: string}>} [saveForm]
 * @property {(formId: string) => Promise<FormVersion[]>} [listVersions]
 * @property {(formId: string, version: number) => Promise<void>} [publishVersion]
 * @property {(q: ListQuery) => Promise<{list: Object[], total: number}>} [listRecords]
 * @property {(id: string) => Promise<Object>} [getRecord]
 * @property {(data: Object) => Promise<Object>} [saveRecord]
 * @property {(id: string) => Promise<void>} [deleteRecord]
 * @property {(formId: string, data: Object) => Promise<{instanceId: string}>} [startWorkflow]
 * @property {(taskId: string, action: 'approve'|'reject'|'transfer', comment?: string) => Promise<void>} [completeTask]
 * @property {(messages: AiMessage[]) => Promise<AiResult>} [chat]
 */

FormSnapshot.schema 复用现有 src/utils/sql.js 的 buildSqlTables 语义（主表 + 子表、sqlType、_fc_id），不再另造字段模型。

4. 各需求：分析与方案选择

P0-1 Schema 版本治理 + 灰度发布

问题： 生产表单一改就可能炸线上。现有 getSQL() / getSQLDiff() 只覆盖数据库列，不管字段被公式、事件、权限引用，也没有版本对象。

成功标准：

设计器能导出不可变 FormSnapshot。
对比两个快照给出：SQL 变更、字段删除影响（公式/事件/显隐）、破坏性等级 safe | warn | breaking。
宿主通过 adapter 存版本；设计器提供「历史版本 / 回滚预览 / 发布」面板。
灰度只做配置，不做流量引擎：publishedVersion + gray（角色或百分比）由宿主解释。

方案：

方案	做法	利弊
A. 设计器只产快照+影响，宿主存版本	扩展 sql.js，新增 VersionPanel	符合 SDK；大客户可对接自己的发布系统。推荐
B. 设计器内置云版本库	做官方后端	和现有授权模型冲突，中小客户方便但政务进不去
C. 用 Git 管 JSON	导出到仓库	只服务开发者，业务人员用不上

非目标： 不做 Git 式分支合并、不做自动数据迁移执行（只生成 SQL）。

关键接口： getSnapshot()、getSchemaImpact(oldSnapshot)、config.version.adapter。

P0-2 文档 / 图片 / 表格智能转表单

问题： 导入已支持 docx/xlsx/json（ImportDialog.vue + wordParser / excelParser），但图片、扫描件、不规则表格不能变成可用表单；导入结果缺少校验和联动。

成功标准：

导入入口增加：图片（png/jpg）、PDF 首页。
流水线：文件 → 结构化草案 →（可选）AI 补校验/选项 → 用户确认后 setRule。
Word/Excel 导入后可一键「AI 润色」（补 title、required、手机号校验）。
失败时保留原文/表格预览，不允许静默丢字段。

方案：

方案	做法	利弊
A. 扩展 ImportDialog + 现有 AI	客户端解析 + `config.ai` 二次整理	复用最多，一周内能出演示。推荐 MVP
B. 独立 OCR 服务	服务端版面分析	图片质量高，但要运维，作为二期
C. 只靠截图问 AI	无本地解析	不稳定，字段对不齐

非目标： 不做手写识别；不做多页 PDF 全量版面还原。

P0-3 表单即应用（CRUD 生成）

问题： 客户买完设计器仍要手写列表页、详情页、接口。getSFC() 只生成单张表，且提交逻辑仍是空的。

成功标准：

从 FormSnapshot 生成 AppSpec（list/create/edit/detail + 列 + 筛选 + 权限码）。
预览弹窗新增「应用」页：左侧列表、右侧表单，走 HostAdapter.listRecords/saveRecord。
getAppSFC() 输出三份 Vue SFC：List.vue、FormPage.vue、api.js 适配器桩。
无 adapter 时预览使用内存 mock，保证设计器可独立演示。

方案：

方案	做法	利弊
A. 只生成 SFC 文件	扩展 `sfc.js`	仍要客户接线，价值有限
B. 运行时 App 渲染器 + 可选代码导出	`FcAppView` 吃 AppSpec	设计器内就能跑通。推荐
C. 完整页面设计器	路由/菜单/仪表盘	偏离表单主业，不做

非目标： 不做菜单树、不做图表看板、不做多表关联查询器。

P0-4 可视化审批流（轻量 BPM）

问题： 官网写流程管理，产品只有表单内 EventFlow（行为节点），没有待办、通过/驳回、节点字段权限。

成功标准：

一张表单可绑定一份 WorkflowDef（start → approve* → end，允许 condition）。
节点可配：办理人（角色/权限）、可写字段、只读字段、隐藏字段。
运行时状态机纯函数：applyAction(instance, action, actor)；持久化由 adapter 做。
新增行为：startWorkflow、completeTask。
设计器左侧「流程」入口，复用 FcFlow 画布风格，但数据模型与 EventFlow 分离。

方案：

方案	做法	利弊
A. 把审批硬塞进 EventFlow	加行为节点	模型不对，没有实例和待办
B. 独立 WorkflowDef + 宿主引擎	设计器只编流程，运行走 adapter	可对接 Flowable，也可官方轻引擎。推荐
C. 内嵌 Camunda	重	SDK 客户绝大多数用不上

非目标： SLA、会签或签、子流程、超时自动跳转（二期再加会签）。

P1-1 跨运行时：React / 小程序 / 鸿蒙

问题： JSON 规则理论上可跨端，实际上绑定 Vue 组件名和 Element/Vant。

成功标准（第一期）：

冻结 Rule 协议白皮书：允许的 type 白名单、禁止的运行时耦合。
@form-create/react 渲染 20 个核心字段（input/textarea/number/select/radio/checkbox/switch/date/upload/subform 等）。
React 应用可通过 FcForm 吃同一份 getJson()。
小程序/鸿蒙只出适配指南和 type 映射表，不在本期写完整渲染器。

方案： 协议冻结 + React 子集。不推荐 先做完整多端。iframe 嵌 Vue 只作为兼容垫片，不写进主路径。

P1-2 表单数据中台 + 开放填报

问题： 提交、统计、分享链接全部要宿主自建；examples/SaveFormModel.vue 容易被误认为产品能力。

成功标准：

SDK 只定义 HostAdapter 的 records/share 方法。
官方可选包 examples/platform/data-service：表单、提交、简单统计、公开填报 URL。
设计器预览可切「填报页」生成分享参数（formId + publishedVersion）。
明确文档：演示云存储 ≠ 商业后端。

方案： adapter 合同 + 参考服务。不做强制云。

P1-3 套打 / 票据打印设计器

问题： api.print / exportPdf 基于 html2canvas，不是套红头/票据。

成功标准：

独立打印模板：页尺寸、页眉页脚、绝对定位绑定。
支持背景底图（红头/票据扫描件）。
运行时 api.printTemplate(templateId) 按模板渲染，不再截整表。
第一期只做 A4 单页 + 主表字段，子表用重复行区域。

方案： 新打印画布，不复用表单栅格。表格布局经验用于「明细重复区」。

P1-4 AI 运行时 Agent

问题： AI 只在设计期改规则。填表现场没有对话补全、异常拦截。

成功标准：

formCreate.use(FcAiAgent)：侧栏对话，上下文 = 当前 schema + formData + 权限。
工具白名单：setValue、validate、explainField，禁止任意 JS。
可关闭；config.ai.runtime === false 默认关。

方案： 设计器复用 config.ai，运行时做成渲染器插件，不塞进设计器主包默认路径。

P1-5 双模设计器

问题： 业务人员会被 JSON、事件、公式吓退。现有 showEventForm 等开关已经能裁切 UI，但没有一键模式。

成功标准：

config.mode = 'developer' | 'business'。
business 默认：隐藏 JSON、事件、插槽、SFC/HTML/SQL、全局事件；保留组件、基础、校验、显隐、AI、模板、导入。
可用 config.modePreset 覆盖。
工具栏显示模式切换（可 config.allowModeSwitch）。

方案： 纯配置映射，不新做两套设计器。这是性价比最高的扩用户项。

P1-6 完整移动端设计器 + 微信/企微渠道

问题： 文档写明仅部分组件自适应；复杂子表/表格覆盖不足。

成功标准：

发布「移动端组件覆盖表」，每个 DragRule 增加 mobile: 'native' | 'fallback' | 'hidden'。
tableForm / vxe / 嵌套子表给出移动端 fallback（卡片列表，不是直接压扁表格）。
渠道包：把当前 rule 输出为微信小程序页面所需的 JSON（先只支持白名单组件）。
独立移动布局（v6.3 已有）成为默认能力，而不是预览开关。

方案： 补覆盖 + fallback，不重写一个全新移动设计器。

P2-1 行业包 + 模板市场

成功标准： 官方 npm 包 fc-pack-hr 等通过 list + addDragRule 注入；设计器可从 URL 拉模板清单。第一期 3 个包：HR 入职、费用报销、政务申请。

非目标： 不做计费与分成。

P2-2 协同设计

成功标准： 字段级锁 + 评论锚点 _fc_id + 基于版本的「另存为分支」。不做 CRDT 实时同编（二期）。

P2-3 私有化 AI / 信创

成功标准： config.ai.api 兼容 OpenAI chat completions；内置系统提示可本地化；文档给出无 CDN 离线依赖清单（现有 echarts/xlsx 等）。不内置模型权重。

P2-4 插件商店

成功标准： fc-plugin.json 清单（menu、dragRules、behaviors、formulas）；FcDesigner.usePlugin(manifest, module)；官方 registry 只是 URL 列表。不做应用内支付。

5. 明确不做（全局）

不把 FcDesigner 改成宜搭/Mendix。
不把 examples/SaveFormModel.vue 的演示云包装成未声明的正式后端。
不在第一年并行启动 React 全量、完整 BPM、CRDT 协同。
不继续以「再加 20 个组件」作为版本主题。

6. 验收总原则

每个子系统必须同时交付：

src/modules/<name>/ 可单测的纯逻辑
config + types/index.d.ts 公开 API
中文帮助文档（fc-design-pro/src/help/ 或对应技术页）
examples/ 里最少一个可点击演示
默认关闭或无 adapter 时零行为变化（兼容现有客户）

FcDesigner Pro 创新需求总纲 ​

1. 产品约束（所有方案必须遵守） ​

2. 子系统拆分与依赖 ​

3. 共享契约 ​

4. 各需求：分析与方案选择 ​

P0-1 Schema 版本治理 + 灰度发布 ​

P0-2 文档 / 图片 / 表格智能转表单 ​

P0-3 表单即应用（CRUD 生成） ​

P0-4 可视化审批流（轻量 BPM） ​

P1-1 跨运行时：React / 小程序 / 鸿蒙 ​

P1-2 表单数据中台 + 开放填报 ​

P1-3 套打 / 票据打印设计器 ​

P1-4 AI 运行时 Agent ​

P1-5 双模设计器 ​

P1-6 完整移动端设计器 + 微信/企微渠道 ​

P2-1 行业包 + 模板市场 ​

P2-2 协同设计 ​

P2-3 私有化 AI / 信创 ​

P2-4 插件商店 ​

5. 明确不做（全局） ​

6. 验收总原则 ​

FcDesigner Pro 创新需求总纲

1. 产品约束（所有方案必须遵守）

2. 子系统拆分与依赖

3. 共享契约

4. 各需求：分析与方案选择

P0-1 Schema 版本治理 + 灰度发布

P0-2 文档 / 图片 / 表格智能转表单

P0-3 表单即应用（CRUD 生成）

P0-4 可视化审批流（轻量 BPM）

P1-1 跨运行时：React / 小程序 / 鸿蒙

P1-2 表单数据中台 + 开放填报

P1-3 套打 / 票据打印设计器

P1-4 AI 运行时 Agent

P1-5 双模设计器

P1-6 完整移动端设计器 + 微信/企微渠道

P2-1 行业包 + 模板市场

P2-2 协同设计

P2-3 私有化 AI / 信创

P2-4 插件商店

5. 明确不做（全局）

6. 验收总原则