PRODUCT & ARCHITECTURE PROPOSAL
AI 自助修改能力方案
文档编号 QX-AI-2026-001 │ 版本 V1.0 │ 2026-11-08 │ 面向：产品、研发、交付、销售
| 要解决的问题 | 客户想在系统里自己改功能，能不能开放、开放到什么程度、怎么保证不出事 |
|---|---|
| 核心结论 | 开放「受控修改权」，不开放「改代码的权限」；按四层分级，先读后写、先配置后代码 |
| 前置依赖 | 一客一分支、变更集、沙箱预览、CI 发布——缺一项就不能开 L2 |
| 与现有文档 | 需求 QX-SRS-2026-001 设计 QX-SDD-2026-001 界面 QX-UI-2026-001 报价单（深圳版） |
| 落地节奏 | P0 只读问数（4 周）→ P1 配置设计器（6 周）→ P2 AI 配置助手（8 周）→ P3 分支与 CI（并行）→ P4 灰度 |
1 结论与三条红线
一句话：开放 AI 改系统是对的方向，但必须做成「提案 → 预览 → 回归 → 回滚」的受控变更，
而不是给客户一个能直接写生产的对话框。分层开放，先读后写，先配置后代码。
先说不做什么，比说做什么更重要。以下三条是硬线，任何一层能力都不得突破：
| 红线 | 含义 | 为什么 |
|---|---|---|
| 不改钱与货 | 计费、折扣、库存扣减、结算、挂账的算法逻辑不可由客户侧 AI 直接改写 | 算错一次就是真金白银，且客户第一时间发现不了，等到对账时已经错了两个月 |
| 不在生产直接写 | 所有改动必须经「变更集 → 沙箱 → 预览 → 审批 → 合并」，没有直连生产的通道 | 生产是唯一没有回滚余地的环境；门店白天在营业 |
| 不绕我方 CI | 构建、测试、签名、发布全部在乙方流水线完成，客户只能提交变更 | 否则等于把供应链交出去，出问题无法追溯也无法兜底 |
2 客户到底想改什么
把过去交付里被提过的“改功能”拆开看，比例大致如下（经验估计，需用实际工单校准）：
| 客户的说法 | 占比 | 真实性质 | 该由谁做 |
|---|---|---|---|
| “加一个字段／改必填／调顺序” | 约 40% | 配置 | 客户自己，表单设计器 |
| “打印模板换个抬头／加个二维码” | 约 20% | 配置 | 客户自己，模板编辑器 |
| “提醒提前几天／按里程提醒” | 约 15% | 配置 | 客户自己，规则引擎 |
| “看板我要看人均产值” | 约 10% | 配置 + 指标定义 | 客户提，指标字典统一 |
| “加一种新单据／新流程” | 约 8% | 代码 | AI 变更集 + 人工审 |
| “对接我的 ERP／财务软件” | 约 5% | 代码 + 外部系统 | 人工定制，报价格外计 |
| “改计费规则／改提成算法” | 约 2% | 核心逻辑 | 人工，且必须走变更单与回归 |
结论：92% 的诉求根本不需要 AI 写代码，只需要一个够用的配置层。
先把配置层做强，AI 的用武之地才是剩下的 8%——也才值得为它建分支、建沙箱、建回归。
3 四层开放模型
| 层级 | 能力 | 客户看到什么 | 改动范围 | 风险 | 开放对象 |
|---|---|---|---|---|---|
| L0 配置自助 | 表单设计器、字典、打印模板、提醒规则、审批阈值、看板指标、角色权限 | 拖拽 + 开关，改完立即生效 | 仅配置数据，不产生代码 | 极低（可一键还原默认） | 全部客户 |
| L1 AI 配置助手 | 自然语言 → 配置 diff 提案（“折扣超过 200 要老板批”） | 左侧原配置、右侧新配置，点确认或放弃 | 配置层 diff | 低（不触碰金额算法） | 全部客户 |
| L2 AI 代码变更 | 自然语言 → 代码 diff → 沙箱构建 → 自动回归 → 预览 → 合并 | 变更集详情 + 预览地址 + 测试报告 | 客户分支内的业务代码 | 中（需护栏与人工复核） | 年费客户，配额制 |
| L3 人工定制 | 计费口径、财务规则、外部资金、硬件对接、性能改造 | 需求单 + 报价 + 排期 | 任意 | 高 | 不开放，按项目计价 |
顺序不能颠倒：L0 没做好就上 L1，客户会把“AI 改配置”当成万能许愿池；
L1 没跑稳就上 L2，等于用最贵的方式（代码）解决最便宜的问题（配置）。
4 能力矩阵
这张表建议直接写进产品文档和合同附件，客户问“我能改到什么程度”时按它回答。
| 可以自助（L0/L1） | 需审批（L2 + 人工复核） | 一律禁止 |
|---|---|---|
| 页面布局与字段顺序 字段校验与必填 下拉选项与字典 打印 / 小票模板 提醒文案与触发时间 报表列与导出字段 看板指标组合 角色与权限分配 优惠券与营销文案 |
新增业务单据类型 修改工单状态机 新增报表计算口径 对接外部系统（只读） 新增数据表与字段 客户侧小程序页面 |
计费与折扣算法 库存扣减与成本核算 结算与挂账逻辑 权限判定与越权检查 登录、令牌、密码 数据删除与批量导出范围 数据库迁移中的 DROP / UPDATE / DELETE 依赖与构建配置 |
5 技术架构
五个部件决定这套能力能不能长期跑下去，缺一个都会在半年内崩：
| 部件 | 作用 | 不做的后果 |
|---|---|---|
| 一客一分支 | 主干保持干净，客户改动落在 feature/<tenant>，升级用 rebase | 客户改三行，你以后每次发版都要手工合，合两次就放弃交付 |
| 变更集 ChangeSet | 一次修改 = 一条记录：diff + 影响面 + 回滚点 + 审批人 | 出了问题查不到改了什么，也无法回滚 |
| 沙箱预览 | 每客户一个 staging 容器 + 脱敏影子库，改完先在这里跑 | 只能拿生产试错，门店营业时间没有试错空间 |
| 部署形态 | 控制面共享、数据面每客户独立；共享实例只承载 L0/L1 | 一个租户的死循环拖垮所有门店；发版窗口无法错开 |
| 统一 CI | 构建、测试、签名、发布都在乙方流水线 | 供应链失控，客户端版本不可信 |
5.1 分支模型
规则：客户改动只进自己的分支；合并方向永远是「客户分支 → 主干」， 主干不反向覆盖客户分支，升级靠 rebase 把主干新提交垫到客户分支下面，冲突由 CI 列出清单。
5.2 变更流水线
六道关卡里，自动回归是唯一天天在救命的环节——它挡住的不是语法错误，而是“看起来能用但算错钱”。
5.3 部署形态与隔离等级
共享实例能承载配置，承载不了代码。原因不是“技术做不到”，而是四件事会同时发生：
| 问题 | 共享实例上会发生什么 | 独立实例怎么解 |
|---|---|---|
| 故障域 | 一个租户的死循环、内存泄漏或线程池打满，把所有门店一起拖垮 | 容器级隔离，故障只影响该客户 |
| 发版窗口 | 客户要发自己的版本，另外 30 家店得跟着停服；白天营业时间没有窗口 | 各实例独立发版，互不牵连 |
| 版本漂移 | 客户代码合进主干会污染通用版；不合进去，共享部署跑不了他的版本——无解 | 分支只在独立实例下才有意义 |
| 回滚责任 | 回滚 A 的改动必然影响 B，做不到“只回滚一个人” | 按实例回滚，边界清晰 |
正确的拆法是控制面共享、数据面每客户独立——不是“一客一台服务器”。
读法：上面一栏永远只有一套，下面一栏按客户复制。 复制的是运行实例与数据库，不是代码仓库——代码仓库仍然是「一个基线 + 每人一个分支」。
隔离等级
| 等级 | 部署形态 | 数据库 | 适用能力 | 发版方式 | 成本（元/月/店） |
|---|---|---|---|---|---|
| S0 | 共享实例 + 配置隔离 | 共享库 · 按租户分区 | L0、L1 全部场景 | 统一发版 | 已含托管费 |
| S1 | 共享实例 + 租户开关 | 共享库 | 仅 UI 文案、报表列、打印模板等零状态改动 | 统一发版 | 低（仅内部试点） |
| S2 | 独立容器 | 同一集群 · 独立库 | L2 常规：新流程、新页面、新报表 | 独立发版 | 100–300 |
| S3 | 独立容器 + 独立存储 | 独立实例 | 涉及新表、外部集成、客户有数据合规要求 | 独立发版 | 300–600 |
| S4 | 整机私有化 | 客户机房 | 政企、国企、数据不出门 | 客户节奏 | 整机另计 |
成本为云主机 + 存储的估算区间，按门店 20 并发的容量规划折算，实际以采购价为准。
判断规则（一句话）：改动是否触及数据结构、状态机、外部系统——
触及就至少 S2；不触及才考虑 S1。S1 建议只用于内部试点，不要写进对客户的承诺，
因为它本质上仍然共享进程，风险没有真正解决。
反直觉但重要：隔离解决的是爆炸半径，不解决改错了。
AI 把折扣算法改错，在这个客户的独立实例上一样会算错钱，只是不会传染给别人。
所以第 7 章那套护栏——金额/库存/权限回归、日结差异为 0、预览验收、72 小时回滚——一条都不能因为“反正隔离了”而省。
反过来也一样：不要指望护栏替代隔离，护栏是概率，隔离是底线。
起步建议：先做 S2 轻隔离（容器化 + 独立 database + 统一控制面），
不要一上来做 S3/S4。等 L2 客户超过 20 家，或出现第一个要求数据物理隔离的客户，再往上走。
按门店 20 并发的容量规划，一台 8C32G 的机器可以承载 10–15 个门店实例，
第一年的基础设施投入可以压在每月几千元以内。
6 变更集与发布流程
变更集（ChangeSet）是这套能力的最小单位，也是计费和追溯的凭据。一次变更从提出到关闭走九个状态：
| 状态 | 含义 | 谁能推进 | 失败处理 |
|---|---|---|---|
| DRAFT | AI 已生成提案，等待运行检查 | 客户 | 可编辑、可放弃 |
| CHECKED | 静态检查通过（未触碰禁改区） | 系统 | 不通过 → 直接拒绝并说明原因 |
| BUILT | 沙箱构建成功 | 系统 | 失败 → 回 DRAFT，附编译错误 |
| TESTED | 三类回归用例全绿 | 系统 | 任一红 → 打回，不允许人工强行通过 |
| PREVIEW | 生成预览地址与差异说明 | 系统 | 预览 7 天未验收自动关闭 |
| APPROVED | 客户确认 + 乙方复核（金额相关 diff 必须人工过） | 客户 + 交付 | 驳回 → 回 DRAFT |
| MERGED | 合入客户分支，主干不动 | 系统 | 冲突 → 转人工合并 |
| RELEASED | 随下次窗口发版，通知门店 | 系统 | — |
| ROLLED_BACK | 72 小时内或客户要求回滚 | 系统 | 记录原因，计入回滚率 |
计费口径：进入
TESTED 才算一次有效变更；因为检查或构建失败而打回的，
不扣额度——这条对客户友好，也逼我们把 AI 的首次成功率做上去。7 自动护栏
| 护栏 | 具体规则 | 不通过时 |
|---|---|---|
| 禁改区（AST 扫描） | 计费、库存扣减、权限判定、令牌、数据删除相关文件与函数签名 | 直接拒绝，提示“此能力需人工定制” |
| 依赖白名单 | 不允许引入新依赖；版本锁定；禁止 postinstall 脚本 | 拒绝合并 |
| 外联白名单 | 只允许访问已备案的第三方域名 | 拒绝合并 |
| 迁移可逆 | DDL 必须成对提供 up/down；禁止 DROP、无条件 UPDATE、DELETE | 拒绝合并 |
| 金额回归 | 折扣、组合支付、挂账、退货等 30+ 用例，断言到分 | 任一红即打回 |
| 库存回归 | 并发领料、超卖、退料、盘点差异用例 | 任一红即打回 |
| 权限回归 | 越权访问 403、跨租户隔离用例 | 任一红即打回 |
| 冒烟回放 | 20 笔真实工单脚本全流程 + 日结差异必须为 0 | 打回 |
| 性能护栏 | 关键接口 P95 劣化不得超过 20% | 打回或降级方案 |
| 人工复核 | 任何涉及金额、库存、权限的 diff 必须由交付人员逐行看过 | 未复核不得 APPROVED |
最容易被跳过、也最致命的一条：冒烟回放里的「日结差异必须为 0」。
AI 改动最容易出的事故不是报错，而是“能跑通、数字差几块钱”，门店要到月底对账才发现。
8 只读问数（建议第一个做）
客户用自然语言查数据——“上个月哪个技师产值最高”“哪些客户两年没回来了”“这台车修过几次”—— 只读、走语义层、权限继承现有角色。这件事比改功能更值得先做：
| 维度 | 只读问数 | 改功能 |
|---|---|---|
| 使用频率 | 老板天天问，一天好几次 | 一个月改一两次 |
| 出错代价 | 读错数据，重问一次 | 写错逻辑，账目错、库存错 |
| 价值感知 | 第一次提问就“哇” | 改完要过几天才感受到 |
| 副作用 | 顺手把数据治理做了（问不出来 = 数据没录对） | 增加维护面 |
8.1 链路
只读链路的价值在于：把“AI 会不会乱来”变成“SQL 能不能通过白名单”——判断标准客观、可测、可回归。
8.2 SQL 护栏
- 独立只读账号，库级只授
SELECT；只连从库，不连主库。 - 只允许单条
SELECT，禁止子查询嵌套超过 2 层、禁止UNION拼接多表。 - 表与字段白名单（客户档案、工单、结算、库存），敏感字段（手机号、身份证）默认不可选。
- 自动注入
tenant_id条件且不可被覆盖；行数上限 5000，查询超时 5 秒。 - 结果不落盘，日志只记录问题与 SQL 指纹，不记录结果集。
- 指标必须走语义层定义（产值、台次、客单价、回厂率），不允许 AI 自己编口径。
9 多租户与升级合并
| 问题 | 策略 |
|---|---|
| 客户分支落后太多 | 落后超过 3 个发布版本，强制合并后才能继续提交变更 |
| 主干改动与客户改动撞车 | 配置类冲突自动三路合并；代码类冲突转人工，CI 列出冲突文件与双方提交 |
| 接口变更破坏客户定制 | 对外接口与扩展点做版本化（/api/v1 不删字段），废弃走两个版本周期 |
| 客户改了主干文件 | 核心目录设 CODEOWNERS，客户分支改动核心目录直接转人工评审 |
| 客户想放弃定制 | 支持「一键回到主干」：丢弃分支改动并在预览环境验证后切换 |
10 计量与定价
开放之后年费的性质变了：从「维护费」变成「托管 + 升级 + 兜底 + AI 额度」。建议按变更集计量，成本随使用走。
| 层级 | 额度（月） | 超额计价 | 说明 |
|---|---|---|---|
| L0 配置自助 | 不限 | — | 客户自己改配置，不占额度 |
| L1 AI 配置助手 | 30 次提案 | ￥50 / 次 | 只算应用成功的提案 |
| L2 AI 代码变更 | 5 个变更集 | ￥800 / 变更集 或 按人时 | 含沙箱、回归、预览、一次发版 |
| 只读问数 | 不限次数，限并发 | — | 成本低，作为留存手段 |
定价的隐含作用：额度本身就是护栏。没有额度，客户会把 AI 当许愿池；
有了额度，他会先想清楚“这个改动值不值 800 块”——需求质量会自己变好。
11 合规与责任
| 项 | 要求 |
|---|---|
| 备案边界 | AI 仅面向客户自己的员工（企业内部使用），一般不构成“面向公众提供生成式 AI 服务”； 若客户把对话入口开放给他的终端客户（如车主微信里也能对话），须由客户完成备案/登记，并在合同中明确 |
| 供应链安全 | 代码签名、构建隔离、依赖锁定、产物哈希留档；客户不能自行构建或替换产物 |
| 数据隔离 | AI 上下文只包含当前租户数据；跨租户检索一律拒绝并记录 |
| 留痕 | 变更集、提示词、模型版本、构建产物、发布记录保留 ≥ 12 个月 |
| 训练数据 | 客户数据不用于模型训练；如需用于评测，须单独书面授权并脱敏 |
| SLA 边界 | 客户自助修改导致的问题不计入 SLA；乙方保留“回滚到上一稳定版”的义务与权利 |
12 落地路线
| 阶段 | 内容 | 周期 | 验收指标 |
|---|---|---|---|
| P0 只读问数 | 语义层 + SQL 护栏 + 权限继承 + 图表回答 | 4 周 | 常见 30 问准确率 ≥ 90%；越权拦截 100% |
| P1 配置设计器 | 表单、字典、打印模板、提醒规则、指标组合 | 6 周 | 配置类需求的自助解决率 ≥ 80% |
| P2 AI 配置助手 | 自然语言 → 配置 diff → 预览 → 应用 | 8 周 | 提案首次应用成功率 ≥ 70%；回滚率 < 5% |
| P3 分支与 CI | 一客一分支、变更集、沙箱、回归、发布流水线 | 10 周（与 P2 并行） | 升级合并冲突率 < 10%；回滚可在 10 分钟内完成 |
| P4 L2 灰度 | 选 3 家年费客户试点，配额制开放 | 3 个月 | 无金额/库存事故；客户续费率提升 |
P3 是硬门槛：分支与 CI 没上线，P4 一律不开。宁可晚半年开放 L2，也不要在没有回滚能力时把生产交出去。
附录 A 合同条款建议
以下条款建议原文写入服务合同附件，措辞已按可执行性调整：
| # | 条款 |
|---|---|
| A1 | 能力范围。乙方以「自助配置」与「受控变更」两种方式向甲方开放系统修改能力；具体可改范围以《能力矩阵》（本合同附件）为准，超出部分按定制开发另行报价。 |
| A2 | 变更流程。甲方通过变更集提交修改，经沙箱构建、自动回归及乙方复核后发布；甲方不得要求跳过上述流程直接修改生产环境。 |
| A3 | 额度与计量。甲方每月享有 L1 提案 30 次、L2 变更集 5 个的额度，超出部分按约定单价计费；因系统检查或构建失败而退回的变更不计入额度。 |
| A4 | 责任划分。因甲方自助配置或受控变更引起的功能异常，不构成乙方违约，亦不计入服务可用性统计；乙方应在接到通知后 4 小时内提供回滚或修复方案。 |
| A5 | 回滚权。乙方有权在发布后 72 小时内，出于稳定性考虑将系统回滚至上一稳定版本，并书面说明原因；因此造成的甲方定制功能暂时失效，乙方应在 5 个工作日内恢复。 |
| A6 | 知识产权。甲方通过自助或受控变更形成的配置与业务逻辑，其权利归甲方；乙方保留底层框架、模板库与工具链的权利，并有权在脱敏后复用于其他项目。 |
| A7 | AI 服务边界。乙方提供的 AI 能力仅供甲方内部员工使用；甲方若将其开放给终端客户，须自行完成生成式人工智能服务备案/登记，并承担相应责任。 |
| A8 | 数据使用。乙方不得将甲方经营数据用于模型训练；变更过程中的提示词、代码与构建产物仅用于本服务，留存不少于 12 个月。 |
一句话收尾：这套能力的真正卖点不是“客户能自己改”，而是
“客户敢改”——因为有沙箱、有回归、有回滚、有人兜底。卖的是确定性，AI 只是把成本降下来的工具。
本文档 V1.0，与需求说明书、开发设计文档、界面规范同版本发布；落地时若与报价单条款冲突，以合同附件为准。文档编号 QX-AI-2026-001。