用一句话生成业务页面，最容易展示的是第一次搭建。真正投入使用以后，问题很快会变成：新增阶段是否还能解释旧记录，看板和列表是否采用同一含义，下一次修改会不会又产生一套新系统？
这些问题决定了 Teloa 对自然语言搭建的取舍。我们让 AI 帮助形成业务定义，再把结果落到当前支持的对象、字段、视图和页面中。自然语言负责降低表达门槛，共同结构负责让生成后的业务继续存在。
这会限制可生成的范围，却为查询、修改和升级保留一致依据。对需要长期使用的中小企业系统，第二次维护的成本应当进入第一次设计的判断。
先从一条真实事项需要什么开始
假设负责人要跟进一批报价，想知道谁还没有确认。首先需要客户名称、报价阶段、有效期和待确认条件。如果只设计一张漂亮列表，却没有定义这些字段，后续筛选和看板都只能凭文字猜测。
“阶段”尤其容易含糊。以下三件事不能混成一个状态：
- 报价已经发出。
- 客户正在核对内容。
- 客户已经接受报价。
把它们写进同一个自由文本字段，第一次填写很方便，统计时却难以比较。
业务建模需要把这类差异整理为有含义的字段与选项。暂时不知道的值可以留待补充，不能为了页面完整而编造；也不必提前设计一家企业可能遇到的所有情况。
同一个定义，服务不同查看方式
记录详情帮助处理具体客户，列表帮助查找，看板帮助看整体。它们应当围绕同一组业务对象和字段，而不是各自保存相似的数据副本。
例如，看板上的待确认数量应来自约定的阶段条件。负责人点回具体记录时，还能解释为什么这位客户算在其中。若每个页面各写一段模型描述，名称相同也可能采用不同口径。
我们在这里选择了受约束的业务建模，而不是每次直接生成一套独立页面。自由生成可以很快展示不同外观，难点在于第二次修改：字段是否还是原字段，列表和统计是否仍使用同一含义，已有记录是否还能继续读取。
受支持的对象、字段、视图和页面形成一组共同结构。AI 将表达整理成候选配置，原业务服务再校验、预览和采用。这样，模型可以帮助形成定义，而不需要每次重新发明数据保存、筛选和升级的方式。代价是能生成的范围受当前配置能力约束。
这个约束服务于长期使用。客户跟进第二周增加一个阶段，应该修改原业务并检查历史影响；如果每次都得到一个新页面，最初省掉的配置时间就会变成后来的迁移和对账。自然语言的目标是降低维护门槛，而不只是缩短第一次演示。
草案阶段，让要求有机会被纠正
第一次表达通常不完整。你说“需要一个跟进日期”，生成草案后才发现，应分成客户约定时间和内部提醒时间。对话可以继续调整，草案预览则提供检查结构和保存的位置。
草案让抽象要求有机会被看懂。用户未必能从一段配置文字发现“跟进日期”有歧义，看到它与客户阶段怎样排列，就更容易指出缺少哪个条件。预览是在帮助业务负责人作判断，不能只承担生成成功的展示。
结构确定以后，才能把 AI 的工作接到具体事项上。继续报价跟进的例子：列表先找出待确认客户，负责人从某条记录发起核查，员工结合获准资料解释尚缺的条件，必要修改形成可审阅草稿。正式记录按实际采用更新，看板再依据同一字段定义计算。每一步继续使用原业务对象，用户无需在报告、表格和聊天之间重新对齐客户身份。
结构在这里给判断提供共同语言。字段和状态让人能够比较多条事项，员工解释其中一条为什么需要关注，任务与成果承接具体处理。没有前者，每次分析都可能重新定义“待确认”；只有前者，负责人仍要自己读完全部材料、形成下一步。把两者连接，AI 才能参与原有业务，而不只是生成一张新页面。
这些环节仍需按实际能力与许可建立，不会在保存业务时一并启动。先用几条本地记录检验含义，再准备相应员工、资料和连接，能让负责人发现缺口后修订原定义，而不是同时调试一整套持续流程。
系统开始使用以后，建模还会继续
业务建模不会在保存草案时结束。新增复核阶段、调整字段类型、缩小选项，都会改变已有记录能够怎样解释。当前升级影响检查识别相关不兼容变化，新的合法配置不能直接代替对旧数据的处理。
因此，自然语言需要持续服务同一个业务定义。人可以在实际使用中发现要求，AI 帮助整理变化，原服务检查并保存。第一次搭建与以后的维护才会成为同一段工作。
对 Teloa 来说，生成速度有意义，前提是生成物有清楚的后续生命。记录能够继续使用，含义可以一致改变，企业才有机会真正留下自己的业务能力。