一、我是谁，为什么做面团 AI
我是一名前端开发工程师，也长期处在业务需求与软件实现的交界处。工作中我经常看到：真正理解问题的人就在现场，但他们的经验散落在聊天记录、Excel、纸张和个人记忆里；把一个想法变成系统，却要跨过需求、设计、数据库、权限、工作流、开发和部署等多道门槛。
AI 已经会写代码、画页面、做推理，但这份能力仍然更容易被懂技术的人使用。我想做的，不是再造一个更会聊天的 AI，而是把聊天框变成“应用生产线的操纵杆”：让普通人从自己最熟悉的业务问题出发，也能建立一套真正属于自己的系统。
参赛方式：个人参赛。我的主要工作包括产品设计、前后端实现、架构与质量门建设，以及使用 TRAE 持续完成开发、审查、测试和迭代。
二、产品简介：一句话，不止生成页面
产品定义 面团 AI 是一套面向企业与业务场景的“意图到应用”推演平台。用户输入一句业务想法，系统会推演完整产品方案，并生成可以直接运行、继续修改和再次打开的应用。
1. 它解决什么问题
以早餐摊为例。摊主很懂进货、库存、预订、会员和日结，却未必懂数据库、RBAC、工作流与部署。传统方式下，他需要先学会如何向软件团队描述需求；面团 AI 希望反过来，让技术主动适应他的业务语言。
这套能力同样适用于门店经营、宠物医院、采购审批、培训管理、设备巡检、课程管理与社区服务等场景。它并不宣称“一句话生成任何软件”，而是聚焦结构清晰、流程可表达、数据可建模的企业与业务应用。
2. 为什么叫“面团”
“面”代表千人千面：每个人的工作、数据和流程都不同；“团”代表能力成团：数据、权限、流程、页面和 AI 各自就位后，组成一套完整系统。它像面团一样可塑，但最终不是一张好看的皮，而是能真正承载工作的应用。
3. 一条完整的用户路径
-
用户输入业务目标，例如：“给中小学课后托管做一套管理系统：登记学生和托管班次、老师排班考勤、每日签到签退、家长请假申请、按月生成托管费账单”
-
系统先判断这是不是有效的建系统请求，再追问关键缺口，避免无意义地触发长时间推演。
-
调度器组织证据检索、风险分析、数据建模、权限、工作流、页面与 AI 能力，能并行的并行，需要上游结果的设置屏障。
-
五套系统生成后进入确定性校验；引用断裂会触发定向修复，关键证据没齐则停在 AWAIT，不把失败包装成成功。
-
当 Data、RBAC、Workflow、Page、AIGC 与 AppBundle 六项证据全部闭合，状态才从 blocked 变成 closed。
-
用户点击“运行应用”，录入订单、切换角色、观察库存变化和流程流转；应用会被保存到应用中心，可再次打开和继续修改。
待替换｜插入“输入一句话 → 推演 → 6/6 Closed → 运行应用”的横向流程图或拼图
三、核心创新：页面不是应用，闭环才是
1. 五系统法定真相源
很多 AI 产品可以生成页面，但页面本身不是应用。面团 AI 把一个业务应用拆成五套必须同时成立的系统：
- 数据模型：准确表达客户、订单、库存、病例、设备、课程等业务对象及关系。
- 角色与权限：决定老板、员工、财务、医生或客户分别能看什么、能做什么。
- 工作流：让采购审批、预约分诊、设备报修等事情从开始流到结束。
-
页面系统：把数据、权限和流程落到真实可操作的桌面端或移动端界面。
-
AI 能力：绑定真实数据、真实动作和业务目标，不把 AI 当作装饰。
最终五套系统组成 AppBundle。页面引用不存在的实体、审批人找不到角色、按钮没有动作、KPI 没有真实 dataRef——任何一个关键引用断裂，应用都不应被发布。
2. 模型说“完成了”，不算完成
V5.7 的核心不是更长的 Prompt，而是一组确定性的门。模型负责提出候选答案，规则和测试负责验收：字段类型是否合法、实体是否存在、审批链是否闭合、动作是否可执行、数字是否来自真实绑定，都必须由机械规则检查。
核心原则 AI says done ≠ Done。门过了，才算数。
校验失败后，错误会带着具体路径回到修复环节，只重跑缺口，不必推倒重来。网络断开后可以从事件序号续播；用户可以暂停、补充信息、回退版本，再从同一个状态重新进入。
3. 结构正确之后，体验仍要可用
系统会判断应用更适合桌面还是移动设备：桌面端基于 Ant Design，移动端基于 antd-mobile；页面可以组合为工作台、看板、日历、仪表盘、向导或监控页。主题色经过 OKLCh 机械校验；KPI 必须绑定真实字段，没有数据就显示空状态，不能为了好看编造增长。
外部服务失败也不能让核心链路一起失败。视觉生成失败会回落到安全骨架；存储可从远端 Postgres TCP 转向 SQL over HTTP，再降级到 SQLite 与 JSON。目标不是宣称永不失败，而是让失败可见，并始终知道下一条安全路径。
4. 结构透视：从界面反查系统依据
面团 AI 不只让用户看到应用“长什么样”，还允许从运行界面反查它“为什么这样运转”。用户悬停字段、菜单、按钮或流程动作时，可以查看它绑定的实体字段、可见角色、权限条件、工作流节点和页面声明。
这是一套界面与五系统声明之间的元素级双向追溯：既能从模型找到它落在哪个界面，也能从界面追到背后的数据、权限和流程依据。出现错绑或悬空引用时，问题会定位到具体声明，而不是只告诉用户“生成失败”。
待替换｜插入“结构透视”截图：悬停一个字段或按钮，展示数据绑定、角色权限和流程依据
四、完整功能与技术实现
| 能力层 | 已经形成的能力 | 用户得到什么 |
|---|---|---|
| 意图与调度 | 入站判定、澄清、能力选择、并行屏障、预算控制 | 从业务语言开始，不必先学技术术语 |
| 五系统生成 | Data / RBAC / Workflow / Page / AIGC / AppBundle | 得到完整应用结构，而非几张孤立页面 |
| 质量闭环 | 结构校验、引用检查、定向修复、6/6 证据闭合 | 空壳功能和断裂引用被提前拦住 |
| 结构透视 | 界面元素与数据、权限、流程、页面声明双向追溯 | 知道每个字段和动作为什么存在 |
| 可恢复运行 | 事件日志、断线续播、失败重跑、版本回退、人工重入 | 长任务中断后不必全部重来 |
| 多端体验 | 桌面/移动外壳、六种页面范式、主题与数据绑定校验 | 在真实界面中操作业务 |
| 运行与降级 | Postgres / HTTP / SQLite / JSON，多模型兼容，可选沙盒与检索 | 可以低成本起步，也能按需扩展 |
| 应用中心 | 保存、缩略图、再次打开、继续修改、角色与数据边界 | 想法留下可持续工作的系统 |
技术栈与工程体系
前端使用 React 19、TypeScript、Ant Design、antd-mobile、ECharts、React Flow、CodeMirror 与 Three.js；服务端由 Node.js / Express 承担产品入口与连接，Python / FastAPI / Pydantic 承担推演引擎、结构化生成与确定性校验。
系统支持 OpenAI 兼容接口；E2B 可提供隔离代码执行与浏览器沙盒；Neon / Postgres 提供远端存储；Docker Compose 支持一条命令启动；GitHub Actions、Vitest、Playwright 与 fast-check 共同组成构建、单元测试、真实浏览器验收和发布门。
工程复杂度本身不能证明可靠。真正证明可靠的，是失败不装成功、测试与门禁持续执行、降级路径明确，以及每次架构变化都能追溯到提交、检查与修复记录。
一、你还没打字的时候，系统里已经有什么
三样常驻的东西，后面所有环节都靠它们：
一本账 five_system_legal.json —— 规定「合法的字段类型有哪些、页面能有哪些形态、图表能有哪几种」。这本账有五个消费方（结构闸、修复器、生成契约、前端渲染器、入站判定），谁没跟上，一致性测试当场报红。以前这些规则抄在五个地方靠人对齐，出过事。
一份积木目录 experience_block_catalog —— 316 个区块（表格、看板、时间线、审批流……），每个记着能摆在什么页面、什么区域、要绑什么数据。
一份积木是拿什么搭的依赖图 —— 218 个基础组件（antd / antd-mobile / ProComponents / 自研）。这份不是人写的，是从渲染器源码 AST 里生成的。原来是手写声明，查出来 316 个区块跟实际渲染对不上（84 条声称了没渲染、974 条渲染了没声称），因为没有任何一处会发现它写错。
二、你打完一句话：先判这一轮该不该跑
一轮推演大约 6 分钟、烧一次完整 LLM、最多几张图。以前任何输入都直接开跑，你打个「你好」照样烧。
现在停止打字 500 毫秒后先判一次，三层：
- 零成本预判 —— 空输入、纯标点、纯问候语，直接出结果
- 规则表 —— 按会话状态挑相关规则，不全塞
- LLM 判六态 —— 真需求 / 迭代 / 说不清 / 跑题 / 问系统本身 / 超纲
「说不清」和「超纲」是分开的：对超纲的说「再多说两句」是骗人，你补再多细节也变不出一个游戏引擎。超纲的话术要求直说做不了、点明哪部分做不了、给一个周边真做得了的。
这一层只提示，不拦你。 发送键始终能按。判定本身出任何问题一律放行——闸门坏了不能变成产品坏了。
三、进推演循环：这是个环，不是一条直线
进来之后不是「一步接一步走到底」，是转圈：
预算闸 → 调度核挑下一步干什么 → 能力池执行 → 信任门验收 → 回灌状态 → 覆盖率闸问「够了吗」
↑ │
└────────────────────────── 不够，再转一圈 ───────────────────────────────┘
预算闸管一轮内烧多少（轮数、调用数、token）。
调度核每次只决定「下一步该干哪件事、派给哪个角色」，不预先排好全部计划。
覆盖率闸是二元机械判定：合约上列的能力是不是每个都跑成功过、该问人的缺口是不是都填了。够了才准写结论、准停。
停下来有几种：想清楚了、等你回答、超预算、你按了停止。
四、能力池里都有谁
平权的一堆能力，调度核按需要挑：
意图理解 · 证据检索 · 仓库解析 · 澄清缺口 · 扩展假设 · 路线生成 · 路线对比 · 提示词构造 · 脱敏 · LLM 生成 · 结构拆解 · 文档起草 · 验收 · 效果预演 · 视觉生成 · 图表渲染 · 工具调用 · 风险反驳 · 综合收敛 · 报告 · 指令包 · 可追溯矩阵 · 交付包
中间夹着几道小闸：就绪度闸（要问人就停在这）、Schema 闸、不变量闸。过不了就落到确定性兜底，不炸。
角色那边有个分岔：简单的走单 Agent，复杂的走头脑风暴（讨论投票分工），再由综合器收敛。有个流边界守卫把「互相吵架的过程」剥掉，只让净化后的观点回灌——吵架细节进审计台账，不进正式产物。
五、每次真调 LLM，底下是怎么走的
调用不直接打模型，先过执行层：
- 执行器抽象 —— 四种形态（模板 / 真跑 / 服务端 LLM / 浏览器端 BYOK）
- 双端同源提示词 —— 服务端和浏览器端消费同一个函数，不各写一份
- 分级上下文 —— 收敛类给 6000~24000 字，分析类 800，轻量 220，截断了要明说
- key 池调度 —— 租约、最闲优先、429 冷却、401 禁用
- key 零信任边界 —— key 只在浏览器 localStorage 和闭包里，不进状态、不进账本、不进导出，有测试锁死
出来的产物要过提交闸：schema 对不对、不变量有没有破、有没有该确认没确认、有没有凭空编、够不够厚（有输出契约规定最少多少字、要哪几段）。过了才盖 provenance 章、进校验台账。
另有个工具层：真搜索（Tavily→Serper→维基，全挂了回落本地检索并如实标注）和沙盒执行（E2B 一次性沙盒，宿主零执行，没 key 就直接不可用）。
六、转够了：把五系统模型装配出来
这是应用的骨架，六段：数据模型 / 页面 / 角色权限 / 工作流 / 不变式 / 应用包。
五系统起草 → 确定性修复 → 结构闸 → 没过就把裁决喂回去重来 → 闭环证据 → 应用主舞台
确定性修复是零 LLM 的：引用写错了但能唯一猜出来的就机械改，修不好的整条剔除，留痕。骨架六段不修——悬空的由结构闸硬拦。
结构闸二元机械：六段齐全、跨段引用全部解析得开。任何一处悬空就拦。今天早上跑的报修工单那一轮就被它拦下来过，报的是「不变式引用了一个不存在的 reassign_work_order」。
闭环证据 6/6 之后，右栏才长出可操作的应用：能切角色、能录数据、能走流程，桌面 / 手机 / 代码三个视图。
还有个确定性终止边：同一轮、同一个目标、模型没变、闭环没 blocked、证据 6/6 —— 直接结束，不再让调度核决定要不要重复同一件事。
七、过了门之后、装配之前：体验层
这一层管「长得像不像个产品」，全程 fail-open：任何一步失败就静默降级回固定骨架，绝不拦发布。
- 首页设计 —— 首页交给自由树设计，不再每个应用都长一个样。只挑 monitor / dashboard 且声明了 stats 或 charts 的页。
- 参照板生图 —— 整个应用只画首页那一张，60~85 秒。这张图同时是应用中心卡片显示的画面。
- 自由树内容生成 —— 深校验 + 出错回问；数字必须挂真实数据引用（查不到就显「—」，不许编）；图表是真 ECharts；逐行数据靠
rowsRef绑真表。 - 色板机械校验 —— 配色约束原来只写在提示词里，模型一字不差地干它被警告过的事（橘色应用主色一次没出现、蓝占六成、还自己发明色板外的绿）。现在在 OKLCh 色彩空间里机械判两条规则，违规先重问，重试完了机械纠偏。 配色问题绝不抛错——抛了就回落固定骨架，那正是这条链路在治的病。
- 前端安全渲染器 —— 只用
React.createElement，绝不dangerouslySetInnerHTML或eval。这是纵深防御第二道。 - 设备壳 —— 手机档整层换 antd-mobile，不套 PC 组件。
八、积木从哪来，以及为什么要"挑"
供给侧三层：218 个基础组件 → 316 个区块 → 目录。
但量出来一件事：11 个真实应用一共只用到 17 种区块，而且没有一个来自名单第 52 名之后。不是那些区块不合法（逐个验过），是全量目录塞进提示词等于一句 358 个名字的逗号串，模型只从串首那几十个里挑。
所以中间插了目录窄化：按题意挑 60 条注入，而不是全量倒进去。评测数据：对题件被选中 0.67 → 3.25（统计显著），提示词字符 16 万 → 5.3 万。
这里踩过一个坑值得记：窄化依赖的 rank-bm25 曾经漏在依赖清单外，而代码对它 fail-open —— 照当时状态部署，窄化会一声不吭地整个失效，本地测试还照样绿（其他用例只要返回一个合法列表就满意，全量也是合法列表）。现在健康探针里有它的位置。纪律是：会静默失效的功能，健康探针里必须有它的位置。
九、应用长出来之后
- 种子数据 —— 打开就有内容，否则每个表零行、图表 KPI 全线「暂无数据」。三条边界保证不跟真实数据混淆：每个表只首次铺一次、每行带标记界面上挂「示例数据」徽标、你写入第一条真实数据时该表种子整批清掉。
- 身份与归属 —— 这不是一个子系统，是一条横穿三处的线：入口（写操作前过权限闸）→ 落库（谁推演出来的归谁）→ 展示（墙上看得见什么）。匿名能看，登录能推演能复刻，超管能管所有人。 401 是权限失败，不重试、不降级、不回落——本地重跑同样绕不过登录。
- 应用中心作品墙 —— 瀑布流，跨列定位器是自建的（现成库表达不了跨列卡）。
- 失效重入 —— 你质疑某个结论 → 查依赖图 → 标记失效 → 级联重算 → 重新排程。另有个「被替代」索引，跟「失效」语义分开：被纪要替代的东西信任不变，不级联。
还有个外环（只在「持续推演」模式生效）：跑完一轮 → 蒸馏成纪要 → 纪要当下一轮种子 → 生成新前沿 → 再跑。连续两次提不出新东西就算耗尽。会话级预算跟轮内预算是两层闸。
真实工程问题如何被解决
面团 AI 的稳定性不是一次设计出来的，而是在真实失败中逐步收口。开发过程中，TRAE 曾协助定位并修复多类会直接影响用户体验的问题：
-
半截 JSON 无法渲染：模型流式输出尚未结束时并不是合法 JSON。系统通过字符串感知扫描、候选截断、悬空键修剪与补齐收尾，持续提取可校验的部分结构；完整产物仍须通过最终结构门。
-
并发保存覆盖新进度：同一轮多个能力落盘时，旧快照可能覆盖新状态。修复后以单调轮次版本和追加集合子集校验区分真实进展与过期写入。
-
流式正文停在第一帧：字符数持续增长，但界面正文因为节流依赖错误不再更新。最终通过连续采样必须增长的端到端断言定位，并加入回归防护。
-
服务错误语义被抹平：Node 兼容层曾把不同的 Python 会话错误统一压成 502，破坏前端对缺失会话的判断。修复后保留原始状态语义，并补齐初始化错误与安全降级。
诚实溯源与结构化交付
每项推演产物都会记录来源、版本和校验状态，区分模型生成、确定性规则、外部证据与安全回退。模型调用失败后的固定骨架不会冒充 AI 生成，未通过校验的内容也不会被包装成正式结论。
推演完成后，用户可以导出需求、设计、任务、追溯矩阵和运行时快照，继续交给开发团队或执行 Agent。面团 AI 的目标不是让一次对话看起来完整，而是留下能被验证、继续使用和持续修改的工程起点。
待替换｜插入一张简化技术架构图：入口 → 调度 → 五系统 → Gate/修复 → 运行应用；避免放满屏技术名词
五、相比初赛 Demo，我把它补成了什么
复赛要求作品从“证明创意成立”升级为“评审可以完整体验的产品”。下面这一段必须以实际完成情况为准，请发布前逐条核对，删除未完成项。
-
从单次生成升级为可恢复的长任务：支持事件续播、失败重跑、人工补充与版本回退。
-
从页面展示升级为 Data、RBAC、Workflow、Page、AIGC 与 AppBundle 的完整闭环。
-
从模型自述成功升级为确定性 Gate：6/6 证据未闭合就不发布。
-
从固定单端页面升级为桌面/移动外壳与多种页面范式。
-
从一次性结果升级为应用中心：应用可保存、再次打开、运行与继续修改。
-
从理想路径升级为真实降级：视觉、模型、存储或外部工具不可用时有明确安全路径。
待替换｜根据真实复赛提交记录，补充最重要的 3–5 个升级点，并配前后对比图
六、产品演示视频
公开视频链接：https://www.bilibili.com/video/BV1B8MU6xEsh/?vd_source=f07b7d222ea8a4494ad17a2a3911b1ae
建议视频只走一条黄金路径：输入早餐摊需求 → 展示推演过程 → 查看五系统与 6/6 发布闭环 → 运行应用录入订单 → 切换员工角色验证权限 → 观察库存与补货/日结联动 → 回到应用中心再次打开。
七、产品创作历程
面团 AI 的起点不是“让 AI 多生成几个页面”，而是一个更基础的问题：为什么真正懂业务的人，仍然无法把自己的经验直接变成软件？
最初的 Demo 证明了自然语言可以生成应用雏形，但继续开发后我发现，真正困难的不是生成，而是结构正确：同一条规则可能分别存在于提示词、后端校验和前端类型中；页面可能很好看，却没有真实数据绑定；审批人、角色、动作和字段之间可能互相找不到。
因此，项目逐步从“生成页面”转向“生成并验证系统”。我把数据、权限、流程、页面和 AI 收敛为唯一事实源，引入 OutputContract、QualityBaseline、Gate、定向修复和闭环证据；随后又补上事件续播、多端外壳、应用中心、主题与数据绑定校验，以及从云端到本地的逐级降级。
这条路线也改变了我的产品判断：AI 应用真正的价值，不是第一次生成得多惊艳，而是在业务不断变化时，系统仍能保持结构正确、过程可恢复、结果可运行。
八、TRAE 实践过程
TRAE 不是这个项目最后用来补几行代码的工具，而是贯穿需求分析、开源调研、架构审查、代码实现、测试修复与文档整理的工程协作者。我的使用方式大致分为四类：
-
架构对照：让 TRAE 读取实际仓库与架构文档，逐层检查设计与代码是否一致，避免只凭印象描述能力。
-
源码研究：对 json-render、A2UI、Grafana、Gitea、ToolJet、Budibase、Appsmith 等成熟项目做定向阅读，明确哪些是直接采用、局部移植、结构借鉴或方法参考。
-
闭环开发：把需求拆成可验收任务，完成代码、类型检查、单元测试、真实浏览器验证，失败后根据错误继续修复。
-
持续审计：核对提交记录、能力边界和对外表述，删掉无法由代码或提交证明的夸张说法。
为了避免只展示“成功生成代码”的片段，我会优先选择能够形成完整证据链的任务截图：先给出问题和代码坐标，再展示修改方案，最后展示类型检查、自动化测试或浏览器验收结果。
待替换｜TRAE 过程截图 1：修复“可见性枚举写成了 link ，实际实现是 unlisted”的问题，并审查这块代码实现
待替换｜TRAE 过程截图 2：“首页参照板同时就是应用中心卡片显示画面”已经不准确，开始修复
待替换｜TRAE 过程截图 3：blockRef 被描述成“前端渲染也已同步消失”，但运行时仍保留 legacy 兼容路径
待替换｜Session ID 1：.7550159849393554450:f1efd642d11fb035ed640b864aade4ea_6a722c87abd8bca79ae26cf0.6a72349aabd8bca79ae26f3a.6a72349a8ba73075827130f0:Trae.T(2026/8/5 02:51:06)（对应关键架构/任务）
待替换｜Session ID 2：.7550159849393554450:85125a46b4cd6e129413919ec9e9442a_6a722c87abd8bca79ae26cf0.6a723938abd8bca79ae2719d.6a7239378ba73075827130f1:Trae.T(2026/8/5 03:10:48)（对应关键功能实现）
待替换｜Session ID 3：.7550159849393554450:9e2fbae58690de93e5dda3cf7fa86cfb_6a722c87abd8bca79ae26cf0.6a723b9aabd8bca79ae271d9.6a723b998ba73075827130f2:Trae.T(2026/8/5 03:20:58)（对应测试、审查或修复）
我在这个过程中最深的体会是：Vibe Coding 不只是让模型多写代码，而是把目标、证据、检查和反馈组织成一条可以持续推进的生产线。TRAE 的价值，体现在它能进入真实仓库、理解上下文、完成实现，并在失败后继续收敛，而不是只给出一段建议。
九、开源、生态与成本选择
1. 不重复造轮子，但对结果负责
面团 AI 不以开源世界的对立方出现。项目参考或直接采用了成熟的身份权限、生成式 UI、仪表盘、响应式布局、应用中心与测试方案；但只有提交标题或描述中明确出现“参考、对标、读源码、移植、借鉴、直接采用”的项目，才进入对外参照图谱。普通依赖不自动算作创新来源。
借鉴并不等于复制粘贴。真正的工作是把成熟能力接入统一契约、校验门与降级体系，让它们在同一条链路里可替换、可追溯、可验收。
2. 先证明有用，再为规模付费
React、FastAPI、Postgres 等核心能力来自开源；Docker Compose 可在普通机器上启动；SQLite 与 JSON 提供本地回落；图像、向量、沙盒和邮件服务均可按需启用。在已有设备、免费额度或本地模型的口径下，基础系统可以做到零新增云服务成本运行；规模化后再为服务器、域名、邮件和模型能力付费。
3. 伙伴共同完成能力地图
目前，面团 AI 已与 DiyGw 框架低代码平台、Isqqw 图表大屏平台、CodexForMe Token 站达成合作意向。DiyGw 提供低代码框架与应用装配积累，Isqqw 擅长图表大屏与数据可视化，CodexForMe 提供模型与 Token 连接。合作仍处于意向阶段，后续将通过标准能力接口逐步落地。
十、价值与下一步
面团 AI 首先不是为 AI 专家准备的。它面向最懂自己摊位的小摊贩、没有软件团队的小店、学校、宠物医院、社区组织，也面向企业里的业务人员、产品经理、运营人员和一线工程师。
当一笔订单能够继续驱动库存、权限、流程与日结，当一次经验不再只存在某个人脑中，AI 才真正进入生产关系，而不只是生成更多内容。
下一阶段，我会继续沿着三条线推进：第一，提高复杂业务下的推演与修复稳定性；第二，完善应用运行态、真实数据连接和更多体验区块；第三，把标准能力接口开放给生态伙伴，让更多专业能力可以被同一条业务链路调用。
最后想说 让有想法的人，不再受制于不懂 AI；让每一份业务经验，都能变成可以运行的结构；让每一条工作流，都真正流动起来。面团 AI——让每一个想法，都拥有自己的系统。