一个后端支持网页和移动应用：实用规划

为什么两个应用会逐渐分离

两个应用即便最初目标相同，也可能逐步变成不同的系统。办公室团队需要清晰的管理端网页应用，外勤团队需要快速的移动应用。两者都处理相同的工单、客户、表单和状态更新，但日常流程不同，会把应用塑造成不同的体验。

这就是分裂的起点。办公室人员可能负责创建和调度工单，而外勤人员在现场更新它们。如果两队都接触同一条记录，但每个应用以不同方式处理，就会很快出现问题。网页上标为“已分配”的任务，在移动端可能被视为“已就绪”。一个应用要求填写的备注，在另一个应用可能是可选的。很快，这条记录就不再讲同一个清晰的故事。

主要原因是逻辑重复。当业务规则写在两个应用里时，微小差别会变成真实的冲突。一个界面可能允许技术员在没有照片的情况下关闭任务，而另一个可能在没有照片时阻止计费。现在状态显示工作已完成，但数据不完整。

名称也会漂移。一个团队说“访问完成”，另一个说“工作完成”，管理者可能说“已关闭”。这些术语在口头上听起来相近，但在软件中会成为不同的步骤、筛选器和报告。随着时间推移，尤其是新成员根据自己面前的界面学习流程时，混乱会加剧。

即便是小的改变也会扩大差距。新增的审批步骤、必填签名或额外的客户字段看似微不足道，但如果这些变更必须在两处重建，通常会先更新一个应用，另一个随后才跟上。延迟会带来返工、支持问题和错误数据。

这就是为什么需要共享后端。当管理端网页应用和现场移动应用共享记录但不共享规则时，系统会慢慢分成两部分。

从一个共享工作流开始

在考虑界面之前，把完整的真实流程写下来。从请求被创建的那一刻开始，一直到工单被关闭、审批或计费为止。这样可以为两个应用提供相同的骨架。

一个常见错误是把管理端网页应用和现场移动应用当作两个独立的产品来规划。那通常会产生两个版本的相同流程、一个状态的两种含义，以及后续的额外人工修正。工作流必须放在第一位。

使用通俗的语言描述步骤。例如：请求创建、已分配、已接受、进行中、暂停、已完成、已复核。然后查看每一步并问谁会接触它。有些步骤属于两个角色。办公室人员可能在网页上分配工作，而外勤人员在移动端接受任务。两者都是同一个工作流的一部分，而不是两个不同的工作流。

先标出共享步骤

规划时最简单的做法是把共享动作和设备特有的动作分开。

共享动作包括创建请求、分配人员、更新状态、添加备注和关闭工单。偏重网页的动作通常有审核队列、重新分配、批准完成和生成报告。偏重移动端的动作往往包括接受任务、上传照片、采集签名和记录到达。

这能帮助你看清哪里应当不同，哪里不应不同。网页可能显示更多筛选和管理控制；移动端可能使用更大的按钮和更少的选项。但状态逻辑、验证和业务规则应集中在一个地方。

尽早为状态变更选定一个事实来源。如果任务只有在附上照片和客户签名后才能变为“已完成”，该规则应放在后端，而不是只存在于移动界面或管理面板中。

一个简单的测试：如果同一动作可由任一应用触发，结果是否应当相同？如果答案是肯定的，那么你的工作流是共享的；如果不是，说明业务规则可能隐藏在界面里。

定义核心数据模型

从两个应用必须达成一致的记录开始。不要从界面开始。先从业务每天跟踪的真实对象入手：客户、地点、工单、员工、库存、发票或检查项。如果管理端网页应用和现场移动应用都要处理同一项工单，那么该工单应作为单一记录存在于共享数据模型中。

一个有用的测试是问：“这两个应用会对什么是真实存在分歧吗？”如果答案是会，说明模型拆分得不对。后端应当保存单一事实来源。

对每个核心记录，把共享字段放在一起。一个工单可能包括 ID、状态、客户、地点、被分配的员工、排期日期、完成日期、备注、附件和照片。

这些字段对两种体验都很重要，尽管呈现方式不同。管理团队可能在网页仪表盘上编辑日程并分配人员；外勤团队可能只是查看日程、上传照片并标记完成。这仍然是同一条记录，只是权限不同。

仅在确有需求时才添加角色特定字段。如果调度人员需要内部优先级评分，这可以存放在同一工单上并对外勤用户隐藏。如果移动端需要离线同步标志或设备采集的元数据，要谨慎添加，不要改变记录的主要业务含义。

别忘了让应用在真实工作中可用的辅助字段。所有权字段表明谁创建、拥有或被分配到记录；时间戳显示何时创建、更新、开始或完成；文件和图片提供工作证据；备注帮助人们解释例外而不改变核心数据。

如果你使用 AppMaster，通常意味着先建模共享实体，然后在网页和移动端应用中应用不同的 UI 和访问规则。这样可以把逻辑集中在后端，而不是分散到两个界面中。

把业务规则从界面中抽离出来

如果管理端网页应用和现场移动应用各自决定允许什么操作，它们几乎肯定会立即发生偏差。一个界面会接受另一个界面会拒绝的值，或者一个应用会把工单标为“已完成”，而另一个还认为它“进行中”。

解决办法很简单：把业务规则放在后端，让两个应用调用相同的逻辑。

验证规则应该放在一个地方。如果工单在被分配前必须有客户、地点和至少一个任务，后端应每次都强制执行。网页可以显示友好的提示信息，移动端也可以如此，但规则不应被任一界面占有。

状态变更同样适用。使用一个共享的状态流程供两个应用使用，例如草稿、已分配、进行中、完成和关闭。一旦该流程放在后端，两个应用都会遵循相同路径。办公室可以在网页上分配工作，外勤可以在移动端更新进度，但除非后端允许，否则任一应用都无法跳过步骤。

计算和检查也应在一个地方运行。如果总成本取决于工时、材料、税费或审批限额，在后端完成计算。如果技术员在没有照片或签名的情况下无法关闭工单，也应在后端校验。

实践中的样子

想象一家服务公司。办公室团队用网页应用创建工单，技术员在现场用移动应用。两个应用都应调用相同的后端逻辑来创建工单、分配人员、变更状态和计算总额。

这种分离让界面更简单。每个应用专注于用户需要看到和做的事，而后端保护必须一致的规则。

如何按步骤规划

从人开始，而不是界面。写下谁在使用系统、他们做什么，以及他们被允许做哪些选择。

对于管理端网页应用和现场移动应用，这通常包括办公室人员、经理和外勤人员。办公室团队可能创建工单、分配人员、批准变更并关闭工单。外勤团队可能只查看被分配的工单、更新进度、添加备注并上传证明材料。

明确后，在一页上画出共享数据模型。先保持简单：工单、客户、员工、地点、照片和状态历史。只添加每条记录真正需要的字段。

围绕记录和状态变更来设计，而不是围绕页面。如果两个应用都接触同一工单，它们应使用相同的状态值、相同的分配规则和相同的审批逻辑。

简单的规划顺序

1. 列出每个用户角色的主要操作。
2. 记录每个操作读取和改变的数据。
3. 明确定义状态规则。
4. 将每个页面映射到其确切所需数据。
5. 用几个真实任务测试模型，从开始到结束。

最后一步最关键。拿一个真实场景，例如办公室创建维修请求、分配给技术员、现场更新、然后由经理复核。如果模型能在没有隐藏的界面特定规则的情况下处理这个流程，那你就走在正确的路上。

每个应用应该有什么不同

后端应保持共享，但体验不应相同。管理端网页应用和现场移动应用服务不同的工作角色，因此应以不同方式展示相同的记录。

在网页端，人们通常需要更宽的视野。他们对比多条记录、排序列、查看历史、运行筛选和批量更新。调度员或运营经理可能希望一次性更新十条工单、分配人员并在表格中检查状态变化。

在移动端，速度比概览更重要。外勤人员通常只需要一个明确的答案：下一步我该做什么？主页应把下一个任务、地址、联系方式、截止时间和状态更新按钮放在显眼位置。

相同数据，不同呈现

关键思想很简单：保持记录不变，改变围绕它们的布局。如果两个应用都使用相同的工单、客户、状态和备注对象，业务规则就能保持在一个地方。

不同的是界面。网页可以显示密集的表格、保存的筛选和批量编辑工具。移动端应突出当前任务和下一步动作；移动端可以采集相机照片、签名、条码扫描或位置。网页则适合更深入的复核、报表和异常处理。

离线使用是另一个真实差异。现场应用可能在地下室、路上或客户现场失去信号，这会影响同步设计、冲突处理以及设备上必须缓存的数据。管理端网页应用通常假定连接稳定，因此可以更多依赖实时更新。

一个简单例子是检查流程。办公室团队使用网页应用分配访问、复查结果并批量修正错误；检查员使用移动应用打开下一个访问任务、拍照、确认到达并提交报告。不同界面，相同检查记录。

一个简单示例场景

设想一家负责设备维修的服务公司。办公室团队用笔记本工作，技术员大部分时间在路上。

调度员使用管理端网页应用创建新工单，输入客户姓名、地址、问题详情、优先级、预约时间和被分配的技术员。这会创建一条共享记录，而不是网页端的独立版本。

随后，技术员在现场打开移动应用，看到同一条工单。界面不同，因为使用场景不同，但底层数据相同。技术员可以查看地址、拨打客户电话、查看任务详情并更新进度，无需重复输入。

现场，技术员添加损坏部件的照片、写几句备注并采集客户签名。所有这些都保存回同一条工单记录。移动应用不是创建自己的照片或备注的副系统，而只是把更多信息添加到共享数据模型中。

回到办公室，经理在管理端网页应用中查看更新后的工单，能看到外勤添加的内容、批准工作并把工单发到计费或后续处理。无人需要比对两个版本的事实。

状态历史让这一切变得有用。如果调度员将工单设为“已排期”，技术员标记为“进行中”，经理将其关闭为“已完成”，每个人都能看到相同的时间线。这能更容易回答简单问题：谁更改了状态、何时更改、在访问前后发生了什么。

常见错误及避免方法

最大的问题是把同一条规则放在两个地方。如果管理端网页应用说工单可以从“已排期”变为“进行中”，而移动端也做同样校验，这些规则就会偏离。把状态变更、权限和必填检查放在后端，让两个应用遵循相同逻辑。

另一个常见问题是为本质相同的工作创建不同记录。团队有时为了让办公室视图与现场视图感觉不同，就把“appointment”（预约）和“visit”（上门）分成两个对象。然后管理端有“appointment”，移动端有“visit”，就要有人来保持它们同步，通常会导致备注不一致、重复更新和关于哪条记录才是真实的混淆。

字段也是陷阱。出于某个团队需要“再加一栏”的理由，列会不断增加。但每个字段都应有其目的。问问它为何重要、谁会使用它、是否影响规则、报表或决策。如果答案不明确，就先不要加，直到确有需求。

弱网络连接常常被忽视，直到第一天在现场遇到为止。技术员可能在地下室、偏远道路或信号差的仓库打开移动应用。如果应用每个操作都需要实时连接，工作会停滞。规划哪些数据必须离线可用、哪些操作可等待同步以及设备重连时如何处理冲突。

命名也会破坏共享系统。如果一个团队称一步为“已分配”，另一个称为“已派发”，第三个称“就绪”，人们就会开始把它们当作不同状态。尽早就共享词汇达成一致并在各处使用。

一个好的直觉检查很简单：一条工单应只有一条事实来源、一条规则应只存在于一个地方、一种状态应有一个清晰名称。

在构建前的快速检查

在开始构建之前，在纸上测试你的计划。如果模型能在几分钟内讲清楚，通常也足够简单，能在两个应用增长时保持稳定。

一个好的检查是：两个团队能否指向同一条记录并有相同理解？如果办公室团队看到的工单、任务、客户或检查报告与现场团队的理解不同，分歧很早就开始了。

使用简短清单：

• 选择一个核心记录，例如工单，确认两个应用读取的是相同版本。
• 在后端只写一次验证规则，而不是在每个界面内重复写。
• 把每个状态变更当作一条路径来测试。
• 在一个简单图表上画出数据模型。
• 把移动端视图精简到必要项。

一个小场景有助于验证。想象一个管理端网页应用排定维修访问，而移动应用供技术员现场使用。管理端可能需要筛选、报表和完整客户历史；技术员可能只需要当天的任务、联系方式、安全注意事项和更新状态的方式。不同界面没问题，不同业务规则不行。

另一个实用测试：改变一条规则，看看需要修改多少地方。如果“完成前必须有照片”这一规则的变更意味着要修改后端逻辑再加上好几个独立界面，你的设计已经开始分裂。

下一步

如果你希望用一个后端支持网页和移动端，不要从映射每个界面或每个团队请求开始。先从一个每天都重要的工作流开始，例如创建工单、分配、更新状态和关闭。小的工作流更易测试，也能快速显露数据模型的清晰处与缺口。

在完善界面之前先构建后端规则。决定哪些字段必填、谁可以变更状态、当数据缺失时发生什么以及哪些动作应触发提醒或后续任务。当这些规则在后端时，管理端网页应用和现场移动应用在表面上可以不同，但仍遵循相同逻辑。

一个实用的顺序很简单：定义主要记录及其关系、编写核心业务规则和状态变更、用示例数据测试工作流、为办公室任务设计网页视图并为外勤任务设计移动视图，然后让真实用户评审第一个版本。

这个顺序能帮助你避免一个常见错误：构建两个漂亮但互相冲突的应用。

如果想更快推进，像 AppMaster 这样的无代码平台可以提供帮助。它让团队在一个地方定义数据和业务逻辑，然后围绕同一基础构建网页和原生移动应用。

保持首个发布版本精简。请一位经理在真实任务中使用网页应用，请一位外勤人员在实际班次中使用移动应用。观察他们在哪些地方犹豫、跳过哪些步骤、以及他们期望接下来发生什么。先修正这些点，再扩展到更多工作流。

通常最稳妥的路径是：一个共享模型、一套规则、两个围绕真实工作打造的不同体验。