对话式应用迭代：加字段、改流程、生成视图和自动化

先给结论：对话式改系统真正的价值，不是“聊一句就改”，而是每次加字段、改流程、调权限都落到可审查、可回滚的元数据层——改得快，还改得安全。

业务系统上线以后，真正的工作才开始。

客服主管想加字段，销售总监想改阶段，财务想加审批，法务想调风险规则，运营想多一个看板，IT 想收紧权限。传统软件开发里，这些都是需求单，要排期、评估、开发、测试、上线。

AI Builder 最值得期待的地方，是让其中一大部分变化从“提需求”变成“对话修改”。

但这里必须说清楚：对话式修改不是让 AI 随便改系统，而是让自然语言生成一份可解释、可确认、可回滚的元数据变更计划。

读者会担心什么

站在低代码平台用户的角度，“用对话改应用”听起来很方便，也很危险。

他们会自然担心：

• AI 会不会改错对象；
• 加字段会不会影响已有表单；
• 改流程会不会影响正在审批的单据；
• 权限变化会不会造成数据泄露；
• 自动化会不会发错通知；
• Agent 会不会执行越权动作；
• 改完以后能不能回滚。

所以一篇讲 AI Builder 的文章，不能只说“用一句话修改应用”。真正要讲的是：平台如何把一句话变成受控变更。

第一类修改：加字段

用户说：

给客户增加一个“续约风险”字段，选项是低、中、高；高风险客户要显示在客户成功经理的看板里。

专业的 AI Builder 不应该直接执行，而应该生成变更计划：

变更项	计划
对象	修改 customer
字段	新增枚举字段 renewal_risk
表单	在客户详情和编辑页展示
视图	新增“高风险续约客户”看板
权限	客户成功经理可编辑，销售只读
自动化	高风险变化时提醒负责人
Agent	客户摘要允许引用该字段

用户确认后，平台再修改元数据。

这和普通“加一列”的差别在于：字段进入了整个应用运行时，而不是只进入数据库。

第二类修改：改流程

用户说：

报销金额超过 3000 元时，先直属主管审批，再财务经理审批；如果关联项目预算不足，还要预算负责人确认。

这句话涉及条件、审批节点、状态、通知、异常和审计。

Builder 应该生成：

1. 金额条件；
2. 主管审批节点；
3. 财务经理审批节点；
4. 预算不足判断；
5. 预算负责人节点；
6. 驳回和补充材料路径；
7. 审批意见和时间戳审计。

同时，它应该提示影响范围：这个流程只影响新提交的报销，还是也影响已在审批中的报销？如果影响存量流程，是否需要迁移？

这是低代码平台里非常关键的专业细节。流程不是画出来就结束，它还和运行中的实例有关。

第三类修改：生成视图

视图是最适合对话式生成的能力之一，因为用户往往知道自己想看什么，却不知道如何配置筛选和排序。

用户说：

给项目经理生成一个“本周高风险项目”视图，按预计延期天数排序，只显示我负责的项目。

平台应该生成：

• 对象：项目；
• 筛选：风险等级为高，且预计影响本周里程碑；
• 权限：只看当前用户负责或参与的项目；
• 排序：预计延期天数降序；
• 字段：项目名、负责人、里程碑、风险原因、下一步动作；
• 展示：列表或看板。

好的 Builder 还应该允许用户继续追问：

再加一列“最近一次会议结论”。

这时它不是重建页面，而是修改视图元数据。

第四类修改：调整权限

权限是对话式修改里最需要谨慎的部分。

用户说：

销售只能看自己负责的客户，区域经理可以看本区域客户，老板可以看全部客户。

这句话看起来清楚，但平台必须生成并展示权限矩阵：

角色	记录范围	字段范围	可执行动作
销售	自己负责的客户	隐藏成本、合同敏感条款	创建跟进、更新活动
区域经理	本区域客户	可看汇总金额	分配负责人、查看风险
管理层	全部客户	可看汇总，不一定能改	查看报表、导出需审批

同时，Agent 查询也必须继承这套权限。销售问“所有高风险客户有哪些”，系统只能返回他有权看的客户。

AI 可以帮助配置权限，但不能让权限配置变得轻率。

第五类修改：创建自动化和 Agent 动作

用户说：

每周一上午，把高风险客户汇总给客户成功经理，并给负责人创建跟进任务。

平台应该拆成：

• 定时触发；
• 查询高风险客户；
• 按负责人分组；
• 生成内部摘要；
• 创建跟进任务；
• 记录自动化运行日志；
• 失败时提醒管理员。

还要判断动作风险：

• 内部摘要：低风险；
• 创建任务：中低风险；
• 修改客户风险等级：中风险，需要确认；
• 给客户发邮件：高风险，需要审批或人工发送。

对话式自动化的关键不是“自动做更多事”，而是“把可自动化和必须确认的动作分清楚”。

好的对话式修改应该有 4 个产品细节

第一，展示变更计划。用户应该知道平台准备改哪些对象、字段、视图、流程、权限和自动化。

第二，展示影响范围。尤其是权限、流程和自动化，要说明影响哪些角色、哪些数据、哪些运行中实例。

第三，支持预览和回滚。修改前能预览，修改后能回滚到上一个版本。

第四，留下审计。谁提出修改，AI 如何解释，人是否确认，系统最终改了什么，都应该有记录。

没有这四点，“对话改应用”会变成一个危险的黑盒。

ObjectStack 的价值

ObjectStack 适合做对话式应用迭代，是因为它把应用结构放在元数据层。

字段、视图、流程、权限、自动化和 Agent 工具不是散落在代码里，而是可以被生成、解释、修改、版本化和审计的业务结构。

业务人员用自然语言说出变化，平台生成变更计划；管理员或业务 owner 确认后，运行时按新元数据工作；Agent 也继承同样的对象、权限和动作边界。

这就是用对话改业务系统的关键：不是让 AI 帮你临时改一个功能，而是让业务系统具备持续被业务语言塑造的能力，同时仍然保持低代码平台应有的治理能力。