接入数据库后，如果你看到的页面字段很多、关系复杂，不知道业务人员应该从哪里开始使用，先不用急着把它当成最终业务系统。
**数据列表页首先是一套面向数据管理的通用页面。**它把数据库中的记录快速变成可查询、可查看、可维护的入口，但不会只凭数据库结构，自动还原财务、运营等岗位的完整工作流程。
TIP
**一句话理解：**数据列表页用于管理数据；业务模型帮助 Agent 和开发工具理解业务；Skill 组织可复用的任务路径，函数服务稳定执行复杂业务规则；面向具体岗位的业务页面，则需要围绕角色和流程继续设计。
为什么生成的页面看起来复杂
数据库通常按数据存储和系统实现来组织，里面会同时存在业务字段、关联字段、状态字段、技术字段和历史兼容字段。数据列表页从管理视角呈现这些内容，所以初始页面更像“数据工作台”，而不是财务人员每天按步骤处理任务的业务界面。
| 页面类型 | 主要回答的问题 | 常见形态 |
|---|---|---|
| 数据列表页 | 有哪些数据，如何查找、核对和维护？ | 字段较完整，突出筛选、表格、详情、新建和编辑 |
| 业务页面 | 某个岗位此刻要完成什么任务？ | 只呈现当前角色需要的信息、操作步骤、结果和异常处理 |
因此，“看起来复杂”不一定代表业务分析做错了，更可能是把管理页面当成了最终业务页面。第一步应先确认使用场景：是要核对和维护数据，还是要让某个岗位完成一条具体业务流程。
数据列表页真正用来做什么
数据列表页适合解决高频、标准的数据管理需求，例如：
- 快速查看数据库里有哪些客户、合同、订单、报销单或其他业务记录；
- 按条件筛选、核对、补录或修改数据；
- 验证业务模型中的字段含义和数据关系是否正确；
- 为实施、运营和管理人员提供通用的数据管理入口；
- 在完整业务页面开发前，先形成一个可使用、可验证的基础入口。
它的价值，是减少重复搭建列表、筛选器和基础表单的工作，让团队更快开始管理和验证数据。它不是要代替角色工作台、审批流、经营看板、复杂结算或行业专属交互。
数据库分析的主要产物，是业务模型
数据库分析并不是“读完表结构，然后自动生成一套完整业务系统”。更重要的产物是业务模型：它帮助系统理解有哪些业务对象、对象之间是什么关系、字段代表什么，以及哪些能力可以被查询和调用。
| 产物或能力 | 主要作用 |
|---|---|
| 业务模型 | 为 Agent、Skill 和开发工具提供业务对象、关系与语义上下文 |
| 数据列表页 | 快速查看、核对和维护数据，也是验证模型的一种入口 |
| Instant API / SDK | 让开发者基于统一模型查询和操作数据，继续开发业务代码 |
| Skill | 把任务步骤、使用方法和组织经验变成 Agent 可复用的执行路径 |
| 函数服务 | 承接结算、过滤、状态流转等需要确定性和工程保障的复杂规则 |
| 自定义业务页面 | 围绕具体角色、任务和流程提供最终使用体验 |
INFO
**页面仍然重要，但不是唯一产物。**数据列表页是管理数据的标准入口；业务模型、API、Skill 和函数服务，才让同一套业务能力可以继续被 Agent、开发工具和其他页面复用。
业务人员、实施人员和开发者分别怎么用
| 角色 | 主要入口 | 适合完成的工作 |
|---|---|---|
| 业务人员 | Agent、Skill、业务页面 | 提出目标、查询与分析、执行标准任务、确认关键结果 |
| 实施与运营人员 | 数据列表页、配置工具 | 核对数据、维护基础资料、验证模型、处理通用管理任务 |
| 技术人员 | 自己习惯的 AI Coding 工具与开发环境 | 使用业务模型作为上下文，通过 Rabetbase CLI、Instant API、SDK 和函数服务开发复杂页面与业务逻辑 |
技术人员无需放弃现有开发习惯。Lovrabet 提供业务模型、数据接口和执行能力，开发者仍可在 Codex 等熟悉的 AI Coding 工具中完成定制开发。
为什么不能只凭数据库自动做完整业务系统
数据库能告诉 AI“数据如何存”，却通常不能完整告诉 AI“业务应该如何运行”。下面这些信息往往不在表关系里：
- 不同岗位分别看什么、能做什么；
- 一项任务从哪里开始，经过哪些审核和异常分支；
- 报表、结算和统计采用什么业务口径；
- 哪些状态可以修改，哪些动作需要权限、预览或人工确认；
- 页面应该突出什么，哪些技术字段不应展示给业务人员。
这些语义需要业务人员确认，也需要实施和技术团队把稳定规则沉淀到模型、Skill、函数和页面中。AI 可以加快分析和开发，但不能在没有业务语义输入的情况下，仅凭数据库关系替企业决定完整流程。
例子：公司有多少报销单
这个问题看似只是计数，实际可能包含明确的财务口径：被驳回、已作废或测试数据是否应该统计？统计申请单数量，还是已完成报销的数量？
| 只依赖什么 | 可能得到的结果 |
|---|---|
| 直接查数据库 | 可能把所有记录都算进去，结果有数值，却不符合财务口径 |
| 只在提示词里描述规则 | 可以完成临时分析，但规则容易遗漏，难以保证每次执行一致 |
| 由函数服务固化口径 | 明确排除哪些状态、采用哪个时间和组织范围，再由 Skill 调用，结果可重复、可测试、可审计 |
这就是函数服务的价值：Skill 告诉 Agent 应该完成什么任务、按什么路径执行；函数服务保证复杂业务规则被准确执行。两者结合，既保留 Agent 的灵活性，也保留工程系统的确定性。
如何判断下一步该做什么
| 你的目标 | 建议入口 |
|---|---|
| 先看清数据、核对模型、维护基础资料 | 数据列表页 |
| 让业务人员查询、分析或执行一项标准任务 | Agent + Skill |
| 固化复杂过滤、结算、审批或状态规则 | 函数服务 / SQL / BFF |
| 为某个岗位提供专属工作台或完整业务流程 | 自定义业务页面 + 业务逻辑开发 |
常见问题
页面复杂，是不是说明前面的业务分析不准确？
不一定。先区分是模型本身有误，还是初始页面展示了过多管理字段。可以先用数据列表页核对对象、字段和关系，再根据具体岗位删减信息、补充业务语义或改做定制页面。
生成了数据列表页，是不是完整业务系统已经做好了？
不是。它只完成了通用数据管理入口。完整业务系统还可能包含角色工作台、流程、权限、指标口径、系统集成和行业专属逻辑。
Lovrabet 是不是只能生成列表页？
不是。列表页只是页面承载能力之一。Lovrabet 更重要的作用，是把数据库和旧系统转化为业务模型与可调用能力，再供 Agent、Skill、函数服务、API 和自定义页面共同使用。
Agent 能不能直接完成所有业务逻辑？
不建议把所有规则都留给 Agent 临场判断。探索性分析和长尾任务可以由 Agent 灵活处理；财务口径、结算、权限、事务和状态流转等关键规则，应通过函数、SQL、BFF 或现有服务提供确定性保障。
继续使用
如果当前目标是生成并验证一个数据管理入口，可参考 数据列表页创建与修改｜平台操作。
如果需要调整字段、筛选器、表单和表格，可参考 数据列表页编辑器。
如果需要在 AI Coding 工具中继续开发复杂交互和自定义模块，可参考 数据列表页创建与扩展｜AI Coding。
如果希望了解 Lovrabet 的整体定位与能力边界，可参考 Lovrabet 体系定位、企业问题与核心价值总结。