面向产品化公司的研发团队：这不是又一个脚手架，而是一台把“常变”上收、把“差异化”托底的业务生产线。
30 秒电梯词
做产品化最痛的，不是写代码，而是高频变更：字段/表单/列表/权限天天改、客户化分叉、回归炸裂。
Oinone 把这些“常变”交给元数据+可视化，把“真逻辑”交给可编程扩展（Java/Vue），对外统一 GraphQL。结果：更快交付、更少分叉、更好治理。
你是否正在经历这些（产品化七宗“痛”）？
- 一个功能 N 个客户版本，分叉越来越多
- 字段/校验/权限天天调，CRUD 返工不断
- 前后端联调来回，接口总差半口气
- 走查权限/链路像黑箱，难定位
- 组件复用率低，客户化复制粘贴
- 线上问题难复现，排障低效
- 版本升级怕牵一发动全身，不敢动
Oinone 的回答
- 范式：模块 → 模型 → 字段（含显示/校验/权限元属性），默认就能跑
- 接口：GraphQL（Query/Mutation），前后端按 Schema 协作，一次性取对数据
- 前端：Kunlun 组件/布局，可插拔/覆写，不绑死视觉风格
- 扩展：函数/拦截器/SPI，把行业能力沉淀成插件
- 可观测：内置 Debug 页，页面 DSL / SQL 轨迹 / 权限链 / 函数链 一站可见
- 治理：模块化安装/升级、BOM 对齐、可灰度，平台升级 ≠ 客户化重做
和“脚手架 + 生成器”的关键差别
- 脚手架让你快起步；Oinone 让你长期演进
- 生成器让你快写 CRUD；Oinone 让你少写 CRUD
- 传统是人盯分叉；Oinone 是机制收敛分叉
30 分钟“自证挑战”（立刻能感知的变化）
- 新增 3 个字段（含校验/显示规则/权限）→ 列表/表单自动生效
- 用 GraphQL 拼一个聚合视图 → 少写 3 个 REST
- 打开 Debug → 直接看到这个字段为何不可见/不可写
- 写一个函数扩展 → 同域业务复用而非复制
适合谁
- 多租户/多客户，变更频繁的 SaaS/ISV
- CRM/工单/库存/合同/采购等中后台域应用
- 想把“项目制”**升级为“产品化”**的团队
边界与承诺
- 不是来替代你的代码，而是替代反复、模板化、高频变的那部分
- 极端低延迟/超高并发场景需配合缓存/异步/旁路策略
想要“对比清单 + 评估表 + Demo 账号”，评论回「试用」，我发你一套 7 天上手包。
