大家好，我是深耕低代码6年的博主。

过去几年，我帮过不少教培机构从“买来的通用系统不好用”走到“自己掌控业务逻辑”的阶段。今天开始，我会用真实项目把整个过程拆给你看——从需求澄清、数据建模、权限设计，到复杂表达式与自动化规则的落地，全程用低代码视角重构。

这次合作的对象是一位教培老板。他已经完成小程序企业认证，也在微搭里建了部分基础表，但业务流转、数据关联、排课逻辑、绩效计算这些核心点，仍然卡在“感觉不对路，又怕后面推倒重来”。

背景：为什么要自己做，而不是继续用买来的系统？

这位客户的机构之前一直在用市面上的教务SaaS。表面功能齐全，真正落地后发现：

• 线索→试听→分班→在读→流失的状态流转和自己机构的SOP严重不符；
• 排课方式只有固定模板，寒暑假连排、临时加课、多时间段选择都要人工二次调整；
• 签到只能在PC端操作，老师上课前没法用手机快速完成；
• 员工绩效（课时费、招生量、试听转化）全靠Excel二次计算，误差和滞后明显；
• 权限粗暴，校长、教务、前台看到的数据范围几乎一样。

于是他决定自己搭。目标很明确：
用微搭把业务系统做出来，小程序端负责线索采集和移动签到，后台负责全流程管理。

目前进度：

• 数据源已建部分表（字典表、学员线索、学员主表、学费表、教室表等）；
• 企业认证完成；
• 核心卡点：底层数据模型是否合理？复杂业务逻辑（排课规则、试听达成率、流失判断、工资绩效公式）怎么优雅实现？

痛点：传统开发 vs 低代码+AI的真实差距

如果按传统方式，一位产品经理写完整PRD，再交给研发，至少需要：

1. 把“每周一次勾选周一到周日 / 寒暑假连续每天 / 临时指定日期”三种排课模式拆成可落地的规则；
2. 设计“试听成功→自动匹配班级→生成在读学员→可计算流失”的状态机；
3. 把“根据年级+科目+程度+班型自动生成班级名称”做成可维护的表达式；
4. 移动端签到与PC端排课数据实时联动；
5. 按角色做数据权限隔离。

这些对非技术老板来说，几乎是不可能完成的任务。即使请外包，沟通成本、返工成本也极高。

低代码本身已经降低了门槛，但复杂业务规则、跨表计算、状态流转依然需要清晰的业务建模能力。这正是我们这套新模式要解决的核心问题。

解决方案：AI辅助开发的新路径（第一阶段只做一件事）

我们升级了协作模式：
不再一次性把系统做完，而是先把PRD拆到“AI可以直接读懂并生成可执行方案”的粒度。

第一阶段目标只有一个：
产出一份结构清晰、可直接喂给Trae的PRD + 数据模型说明 + 核心Agent提示词。

后续阶段再按模块推进：

• 阶段一：获客与线索确认（小程序前端采集 + 前台补全）
• 阶段二：试听安排与结果判定
• 阶段三：班级匹配与在读学员生成
• 阶段四：排课引擎（三种排课模式）
• 阶段五：移动端签到
• 阶段六：员工绩效与工资自动计算
• 权限体系贯穿始终

设计理念只有三句话：

1. 数据模型先行，业务流转驱动表结构，而不是先画页面再补表。
2. 所有复杂逻辑尽量用表达式 + 云函数 + 自定义方法实现，减少硬编码。
3. 权限按“角色 + 数据范围”双维度设计，而不是简单的菜单开关。

开发工具介绍：Trae + 微搭，为什么是这对组合？

微搭（WeDa）
腾讯云低代码平台，天然适合小程序 + 管理后台一体化。
拖拽页面、数据源建模、工作流、权限、云函数，都能在同一环境完成。对教培这种“重流程、重数据关联”的场景非常友好。

Trae
字节跳动推出的AI原生IDE。它最大的价值不在“帮你写一行代码”，而在：

• Builder / SOLO模式：用自然语言描述需求，自动拆任务、生成项目结构、写代码、甚至生成PRD；
• 对中文业务场景理解极强；
• 支持自定义Agent与Rules，可以把我们的“教培业务规范”固化进去；
• 适合做复杂表达式、云函数、数据模型校验这类“低代码里需要写一点代码”的部分。

我们的工作流是：

1. 我先把业务拆成结构化PRD；
2. 设计好数据模型与核心字段关系；
3. 写出针对性的Agent提示词；
4. 把PRD喂给Trae，让它辅助生成微搭侧的数据源设计、页面结构建议、自定义方法草稿；
5. 再回到微搭里落地、调试、迭代。

这样，非技术老板也能参与决策，真正懂业务的人掌控逻辑，AI负责把逻辑翻译成可执行方案。

写在最后

这一篇只做一件事：把方向和第一阶段目标说清楚。

下一篇我会直接给出：

• 完整的业务阶段拆解（获客→试听→分班→在读→流失）
• 推荐的数据表结构与关键字段设计
• 核心状态流转图
• 可直接复制给Trae的Agent提示词模板

如果你也在用微搭做类似的教培或服务类管理系统，欢迎把你的数据模型和卡点丢出来，我们一起用低代码+AI的方式拆。

下一篇见。