一张报修单里的工作量

假设客户在 App 中选择设备、填写故障、上传照片，客服确认保修范围后派单。列表和表单容易画出来，设备归属、派单权限以及撤回后的处理却会影响整个数据模型。经销商能否查看其他区域的设备，工程师已出发时能否取消，都需要业务负责人给出明确规则。

现有账户和权限工程可以承担身份验证、会话撤销及操作授权，文件模块负责受控上传。保修判断、备件核销和到场确认要放在项目的业务模块中开发。把这两部分分别估算，才能看见复用实际减少了哪些工作。

这类报修流程是设计示例。复用前应在当前版本中检查所需接口和模块，不应仅凭官网出现过“售后”就认为完整派单系统已经包含在源码内。

各端负责什么

移动端使用 uni-app x、UTS 和 UVue，处理手机交互与原生能力；React + Vite 管理端供运营人员配置、审核和查询。Go 服务维护授权与业务规则，PostgreSQL 保存数据。官网另用 Next.js 提供公开内容和会员账户入口，通过 App API 接入后端。

一个业务字段的名称、可空性和错误状态由 API 契约约定，客户端据此展示和提交。修改“处理说明”时，数据库、OpenAPI、后台表单和 App 详情应在同一项变更中核对。界面可以不同，保存含义必须一致。

管理端调用 /admin-api/v1，App 与官网调用 /api/v1。共享数据模型不授予共享权限，普通用户 Token 不能用来操作管理接口。用户和 App 范围仍由服务端检查。

给 AI 一个具体的起点

用 AI 辅助开发时，可以把需求落到已有模块和接口上：增加哪个字段、由谁编辑、旧客户端遗漏字段时如何处理，再让 AI 按这些条件修改代码。账户和网络层已有实现，开发者无需每次重新生成整套基础代码。

提交结果仍要经过契约检查和测试。编译通过无法证明一个用户读不到另一位用户的记录，也无法证明推送在目标设备到达。AI 可以执行已定义的检查；测试范围、业务约束和最终发布责任由团队确定。

适合什么项目

需要长期维护自有品牌、同时服务移动用户与后台人员，而且业务规则会持续变化的团队，可以把 AppKernia 纳入选型。团队应具备 Go、React、UTS 的维护能力，或有明确承担这些工作的开发伙伴。

临时收集报名信息时，已有表单工具可能够用。需要马上投入使用的教务或财务系统，应先比较成熟产品。已有后端、只缺一个客户端的项目，也可以只检查移动端模块的接入成本，不必同时替换服务端。

判断费用时，除首期开发，还要考虑版本升级、云资源、备份、签名与系统兼容。源码允许自行修改，也需要有人解释和维护这些修改。

选型验证应留下什么

选一项实际任务，例如登录、保存文章、修改资料，记录经过哪些接口以及失败时的结果。再做一次跨用户或跨 App 的访问检查，确认数据范围；最后增加一个测试字段，走完迁移、契约和客户端生成流程。

将检查结果按“可直接使用”“需要适配”“需要新开发”记录，并附对应目录、接口和剩余条件。这份清单可以用于估算，也能交给后续开发人员复核。目录与开发约定见公开仓库，技术分工见全栈架构。