AI 写配置，不写代码
大模型输出的不是一段程序源码，而是一份受严格约束的结构化配置。界面只由一组预先备好的组件搭成，模型能做的是挑选与组合。
生成物可枚举、可校验，不存在「一段能干任何事的代码」——这比让 AI 写代码安全一个数量级。
奇喵汪谷 · 运营底座
让业务系统
让业务系统
长在对话里
支撑繁育版与客户版运转的，是一套我们自己造的运营平台。 它最核心的能力不是某个功能，而是让运营人员用一句话描述需求，系统就把可用的业务页面造出来—— 并且造出来之后，运行起来跟大模型再无关系。
一句话 · 变成一个页面
// 运营人员在对话框里说： 「查各宠舍这个月的宠粮消耗，能按时间筛，带趋势图」 // 系统把它理解成一份结构化方案： 页面形态 ···· 明细列表 + 趋势图 数据范围 ···· 宠粮流水（限定在有权限的宠舍内） 筛选条件 ···· 时间区间、宠舍 处理步骤 ···· 取数 → 按日汇总 → 出图 // 逐条校验通过、人工预览确认后， // 固化成一个可执行页面 —— 此后运行不再需要大模型
架构总览
三个平面，一条关键的分界线
整套平台被拆成三层。真正决定它能不能上生产的，是第二层和第三层之间那条线。
GENERATION
生成平面
对话、生成、校验、预览、发布都发生在这里。大模型只在这一层出现，产出的是结构化方案，而不是可执行代码。
EXECUTION
执行平面
加载已发布的配置、渲染界面、响应操作。这一层完全不依赖大模型——这是我们不肯让步的一条线。
执行平面完全不依赖大模型。大模型只出现在生成平面。 —— 我们给自己定下的一条铁律
生成链路
从一句话到一个能用的页面
每一步都可停下、可检查、可回退。没有任何一步是「模型说了算」。
-
描述需求
运营人员在对话面板里用自然语言说明要什么，例如「查宠舍的宠粮消费记录，能按时间筛选，带趋势图」。
人工输入 -
理解与规划
大模型先在已登记的业务对象里圈定相关范围，再给出一份方案：只说清筛选条件、处理步骤与展示意图，不直接动手写页面。
AI 规划 -
编译
系统把这份方案展开成一套完整、自洽的页面配置。这一步不含任何猜测：同样的方案，永远得到同样的结果。
确定性编译 -
逐条校验
成套的规则挨个过一遍：用的界面元素是否在允许范围内、每个动作是否都有着落、有没有碰到不该碰的数据。不通过就退回模型自动修正。
自动拦截 -
预览与试运行
生成结果先在测试环境里跑一遍给人看，涉及改动的操作只做预演、告诉你会影响多少条，不会真的落到数据上。
人工确认 -
版本化发布
确认后固化成一个新版本存下来，系统同时判定它的风险高低。默认只有创建者自己能用，要公开给团队需管理员授权。
可回滚
自然语言
结构化方案
编译
校验
预览
发布
运行时渲染
设计原则
我们为什么这么造
「让 AI 写业务系统」这个想法不新鲜。难的是让它写出来的东西敢上生产。
生成与运行彻底分离
页面通过校验并发布后，运行时执行的是已经固化下来的配置，用户的每一次操作都不会再触发任何大模型调用。
线上行为确定、可复现、可审计；推理的延迟、成本与不确定性都被挡在生成阶段。
安全在运行时兜底
能看哪些数据、能做哪些操作，全部由最底层强制约束，上层无论生成出什么，都越不过这道边界。
成败关键不在模型有多聪明，而在越界时有没有东西能拦住它。
可选项越少，结果越稳
可用的界面元素越克制，生成质量反而越稳定，这是低代码领域反复验证过的经验。管理系统这类场景，可靠性比表达力重要得多。
把常见套路沉淀成模板
管理系统里翻来覆去就是那几类读写操作，我们把它们做成了标准模板。模型负责编排，不必也不能重新发明一遍同样的逻辑。
生成权属于每个人
所有运营人员都能造自己的页面，发布后默认挂在自己的菜单下自用；要公开给团队时，由管理员按系统判定的风险等级审核。
可靠性从哪来
让 AI 造的东西敢上生产，靠的是这几件事
「让 AI 写业务系统」不难，难的是让它写出来的东西没人半夜提心吊胆。
| 机制 | 它解决什么 |
|---|---|
| 统一的业务登记 | 有哪些业务对象、谁能看谁能改、走什么审批流，全部登记在一处。AI 的理解与选择都被限制在这份登记之内，范围之外的东西它既看不到也碰不到。 |
| 先出方案，再落页面 | 模型交出的是一份「要什么」的方案，而不是「怎么做」的代码。让它专注表达业务意图，把格式与正确性交给系统兜底，从源头上压掉大半的幻觉。 |
| 确定性的展开 | 把方案展开成完整、自洽的页面配置。这一步没有任何猜测成分：同一份方案，今天和明天得到的结果完全一样。 |
| 标准化的操作模板 | 管理系统翻来覆去就是那几类读写操作，我们把它们固化成了标准模板，一律按参数执行，不给临时拼装危险指令留任何缝隙。 |
| 底层的数据边界 | 整套系统的安全基石。能访问哪些数据、能执行哪些操作由最底层强制，上层无论生成出什么、出多大的错，都越不过这道边界。 |
| 发布前的逐条校验 | 成套规则在发布前挨个检查一遍，任何不合约定的地方都会被拦下，并以明确的错误交回模型自行修正，人不必守在旁边。 |
| 版本与风险审计 | 每次生成都留有版本、随时可回滚。这个页面实际做了哪些操作由系统自动判定，不许创建者自行申报，避免「说的是查询、做的是删除」。 |
它和宠物业务的关系
从一个真实业务里长出来的底座
这套平台不是先有架构再找场景，而是反过来：先有了繁育版与客户版每天产生的真实运营需求 ——查宠舍数据、看消费明细、处理反馈工单、审核异常账户——才有了「能不能让运营自己造页面」这个问题。
所以它天然是业务驱动的：运营平台看的是两端业务同一份真实数据，但账号体系与小程序完全独立。 终端用户永远接触不到它，它只服务于内部运营。
它的内核被刻意做成与具体业务无关——今天支撑的是宠物档案，换一门生意同样立得住。
| 定位 | 支撑上层业务的内部运营底座 |
|---|---|
| 面向对象 | 内部运营人员，非终端用户 |
| 核心能力 | 自然语言对话生成业务页面 |
| 服务端 | 内存安全的高性能编译型语言，配企业级关系型数据库 |
| 运营前端 | 跨平台 Web 框架，界面由服务端下发驱动 |
| 大模型 | 以通用协议接入，可随时更换；对话全程留痕 |
| 运行时依赖 | 无大模型依赖 |
| 数据隔离 | 按工作区隔离，彼此不可见 |
技术常见问题
关于这套平台，被问得最多的四个问题
AI 生成的页面会在生产环境实时调用大模型吗？
不会。这是平台最重要的一条约束：大模型只出现在生成阶段。页面通过校验并发布之后，运行时执行的是已经固化下来的配置，整个执行环节完全不依赖大模型。
这样做的好处是三重的：线上行为确定、可复现、可审计；推理的延迟与成本不会进入用户的请求路径；就算模型服务当天挂了，业务也照常运行。
为什么让 AI 生成配置而不是前端代码？
因为受严格约束的结构化配置是可枚举、可校验的，而生成的代码不是。平台的界面只由一组预先备好的组件搭成，大模型能做的是挑选、组合、把数据接上去，而不是编写一段可以做任何事情的程序。
不符合约定的输出会在校验阶段被拦下来，并以明确的错误交回模型自动修正。反过来，如果让它生成代码，就意味着每次都得有人去审计一段能干任何事的程序——那才是真正不敢上生产的东西。
生成出错了怎么办？会不会误删业务数据？
平台设计了三道防线。第一道在数据层：能访问哪些数据、能执行哪些操作由最底层强制约束，生成出来的页面无论如何都越不过这道边界。
第二道在流程：发布前必须经过自动校验、试运行与人工预览确认，预演阶段涉及改动的操作只报告会影响多少条，不会真的落到数据上。
第三道在治理：每次生成都留有版本、随时可回滚；这个页面实际做了哪些操作由系统自动判定并给出风险等级，要公开给团队使用得先过管理员这一关。
这套平台和奇喵汪谷的宠物业务是什么关系？
它是支撑上层业务的运营底座，不面向普通用户。繁育版与客户版两个小程序服务终端用户，运营平台则供内部运营人员管理与分析业务数据，账号体系与小程序完全独立。
它的内核被刻意做成与具体业务无关——宠物档案是第一个验证它的场景，但这套东西本身并不只认这一门生意。