企业官网建设流程全解析

钉钉和飞书放下“入口执念”这件事，在 WorkBuddy 这类 AI 工作助手跑出来之后变得更加明显。所谓“入口执念”，并不是一个商业口号，而是一种长期主宰企业软件架构的设计假设：所有工作都应该从同一个 IM 客户端出发，用户通过工作台、菜单、小程序、H5 和搜索找到功能，平台则通过高频的聊天入口带动低频的业务入口。这个假设在过去十年里成就了企业协作平台的生态模式，但也被它自己带来的复杂度反噬。AI 工作助手的出现，让“入口”这个概念的权重发生了变化：用户不再需要记住功能在哪里，系统也不再需要把所有功能都塞进同一个导航结构里。这篇文章以 WorkBuddy 作为这一类 AI 工作助手的代表，讨论它们出现后钉钉、飞书为什么从架构上开始放弃“超级入口”路线，以及作为开发者，我们应该如何调整自己的集成方式，从“做一个入口应用”转向“做一组可被 AI 调用的能力”。

这里不是要讨论某一家公司的内部战略，而是要拆解一个实实在在的工程问题：当入口不再重要，平台应该开放什么、开发者应该实现什么、验证和排错应该关注什么。文章会按照从概念到落地的顺序，先讲清楚“入口执念”的技术来源，再对比传统入口型应用和 AI 工作助手背后的能力型应用，然后用一个最小可运行案例，演示如何在钉钉、飞书这类开放平台上通过 Webhook、事件订阅和开放 API 构建一个“AI 工作助手”的雏形。最后给出常见坑、排查链路和可复用的接入清单。

1. 先厘清“入口执念”：曾经为什么所有平台都想成为一个入口

1.1 超级入口的业务逻辑：IM 高频带动业务低频

企业协作平台的“入口执念”，本质上是移动互联网时代“高频带动低频”这一增长逻辑的延伸。钉钉和飞书这类产品首先是一个 IM，聊天是员工每天打开次数最多的动作，而审批、报销、日报、会议、项目管理这些业务动作发生频率相对低。如果平台能把低频业务也塞进高频 IM 里，用户就不需要切换产品，流量不会外流，生态开发者也能获得更稳定的分发渠道。

这个逻辑在技术上有非常具体的作用：平台掌握菜单位置、信息流位、搜索排序和应用分发，开发者接入后获得的是“被看到”的机会。对企业用户来说，统一入口也确实降低了学习成本，新员工不需要记几十个内部系统的网址，只要打开钉钉或飞书就能进入工作台。

但入口思维一旦推到极致，问题就会浮现。工作台里的应用越来越多，菜单层级越来越深，用户从“聊天”到“完成一个审批”往往要经历多次跳转，入口从“提高效率”变成了“增加跳转成本”。平台侧也面临同样的压力：为了容纳更多业务，客户端体积、冷启动时间、消息推送频率和权限模型都在快速膨胀，最后入口本身变成了最大的技术债来源。

1.2 入口型应用的技术代价：导航膨胀、权限复杂、链路冗长

从开发者视角看，入口型应用通常按下图结构组织：

IM 客户端 -> 工作台入口 -> 应用主页 -> 功能菜单 -> 业务页面

这种模式在中小规模应用里很顺畅，但随着业务变多会出现几个典型问题。

第一，导航层级膨胀。工作台需要分组、置顶、搜索和个性化排序，否则几百个应用根本无法被找到。导航本身变成了一套业务系统，需要单独维护应用分类、可见范围、排序策略和下架逻辑。

第二，前端链路变长。从聊天窗口进入 H5 或小程序，再跳转到具体业务页面，中间要经历登录态传递、路由鉴权、页面鉴权和接口鉴权，每一层都可能失败。越是复杂的审批业务，跳转链路越长，排查问题越困难。

第三，权限模型被耦合进页面结构。很多团队的习惯是先建菜单，再给菜单配权限，于是“能不能访问某个 API”和“菜单位置在哪里”绑定在一起。一旦入口结构调整，权限就会跟着失控。

第四，第三方应用被绑定在平台的页面容器里。开发者必须适配平台的登录协议、UI 规范、版本兼容规则，很难把同一套能力复制到其他渠道。

这些代价在“入口=流量”的时代是可以接受的，因为入口本身能带来收益。但当用户交互方式从“点菜式”切换成“对话式”之后，入口的真实价值就开始下降。

1.3 AI 工作助手为什么让“入口”贬值

WorkBuddy 这类 AI 工作助手的交互模型，和传统入口型应用完全不同。

传统模型里，用户是人肉搜索引擎：先记住功能位置，再进入菜单，再操作表单。AI 工作助手的模型则变成：用户用一句话描述目标，助手负责把目标拆解成动作，再通过公开或私有的 API 调用对应的业务能力，最后把结果回复给用户。整个过程里，用户并不关心“待办入口在哪”“审批中心在哪”，他只关心“结果是否完成”。

这对平台架构的影响非常深远。当用户通过自然语言表达意图时，系统必须先把业务功能拆成可调用的“能力单元”，比如创建待办、发起审批、查询日程、更新项目状态。能力单元不再依赖菜单层级，而是依赖 API、事件、数据模型和权限范围。也就是说，原本装在“入口”里的价值，正在转移到一个更底层的开放能力层。

这也是钉钉和飞书这类平台开始“放下入口执念”的原因之一：它们仍然拥有身份体系、消息通道、通讯录和组织关系，但这些要素的价值更多体现在“为 AI 提供上下文和权限边界”，而不是“让用户停留在工作台里”。入口的意义从“聚合流量”变成“分发能力”。

两个时代的平台结构对比如下：

这张表也是后续所有技术方案的选择依据：如果你的业务还在用“做一个入口”的思路去接钉钉和飞书，可能很快会发现自己既不适合 AI 调用，也不适合移动端的高效场景。

2. 钉钉飞书“放下入口执念”背后的架构含义

2.1 从页面容器转向开放 API 和事件流

“放下入口执念”在架构上最明显的变化，是平台开始把“页面容器”和“能力开放”解耦。过去第三方应用接入 IM，主要交付物是一个工作台页面或一个小程序；现在，平台更鼓励开发者直接使用开放 API、机器人消息和事件订阅。

这种解耦在开发上对应三块基础设施：

第一是身份认证。用户仍然通过钉钉或飞书账号登录，但第三方系统不再依赖页面跳转来获取身份，而是通过 OAuth 或扫码登录获取用户身份码，再换取访问令牌。

第二是 API 网关。平台把组织通讯录、审批、日程、待办、云盘、消息等能力抽象成统一的 REST API，第三方应用按 Scope 申请权限，而不是按菜单位置申请权限。

第三是事件订阅。平台的业务事件，比如“审批通过”“日程创建”“用户入群”，可以通过回调或 Webhook 推送给开发者服务器。这比“用户进入应用后轮询接口”更接近实时系统，也是 AI 工作助手能够主动感知业务变化的基础。

常见的能力开放分层如下：

平台侧： 组织数据（组织架构、成员） 流程数据（审批、任务、待办） 内容数据（文档、知识库） 消息通道（群消息、单聊、卡片） 开发者侧： 服务端 API 调用 事件回调接收 机器人消息发送 AI Agent 工具封装

对开发者来说，这意味着接入方式的重点从“适配 UI”变成了“适配协议”。

2.2 从菜单导航转向场景卡片和会话交互

即使不引入 AI，钉钉和飞书也已经在弱化“工作台九宫格”的重要性，转而强调“在会话里完成任务”。最典型的载体是消息卡片：一条审批消息里直接包含同意、拒绝、查看详情按钮，用户不用离开聊天窗口就能完成操作。

场景卡片的设计逻辑，是把一个业务闭环压缩到一条消息里。它的工程价值不在于 UI 好看，而在于减少了上下文切换。用户看到卡片时，当前会话上下文仍然保留，不需要跳到另一个页面重新定位问题。

从技术栈上看，卡片系统通常包含以下结构：

{ "msg_type": "interactive", "card": { "header": { "title": "待办提醒", "template": "blue" }, "elements": [ { "tag": "div", "text": "明天上午十点前需要提交周报" }, { "tag": "action", "actions": [ { "tag": "button", "text": "查看详情", "value": "todo_detail_1024" }, { "tag": "button", "text": "标记完成", "value": "todo_done_1024" } ] } ] } }

注意，不同平台的卡片字段名称并不一致，上面只表示交互模型。实际接入时要以开放平台的最新卡片协议为准。

卡片的价值在于它既是“输出”也是“输入”：用户点击按钮后，平台的交互回调会主动把事件推送回开发者的服务器，开发者通过事件回调继续完成业务流程。相比传统页面表单，卡片的输入项更少、路径更短、失败概率更低。

2.3 平台真正要保留的是身份、权限和数据关系

“放下入口执念”不代表平台变成纯管道。钉钉和飞书真正有价值的部分，是它们手里的组织关系和身份体系。AI 工作助手越智能，越需要回答三个问题：当前用户是谁、他有权操作什么、他的组织上下文是什么。

这些能力需要以服务形式开放出来。常见做法包括：

• 用统一身份 SDK 获取用户唯一 ID，而不是让每个应用自己建账号体系。
• 用组织架构 API 判断审批链和可见范围。
• 用权限 Scope 控制第三方应用能访问哪些数据。
• 用审计日志记录谁在什么时间通过什么工具调用过什么接口。

换句话说，平台的核心资产从“用户的停留时长”变成了“可信的上下文”。对开发者来说，尤其是正在做 AI 助手的团队，应该把平台提供的身份和权限能力当作智力资产，而不是简单的登录需求。

3. 面向“能力调用”的最小接入方式：Webhook、事件订阅与机器人

3.1 准备一个开放平台应用

不管接钉钉还是飞书，第一步都是在对应开放平台创建一个“企业内部应用”。创建过程中通常会拿到以下三类信息：

• App ID / App Key：应用的唯一标识。
• App Secret：调用服务端 API 时用来签名的密钥，不能写进前端代码。
• 机器人 Webhook 地址或消息发送凭证：用于向群聊或个人发送消息。

创建应用后，要在权限管理里申请 API 权限。这里最容易犯的错误是把权限申请得过大，比如只需要创建待办，却申请了全部通讯录权限。权限越大，安全风险越高，审核也越难通过。推荐按最小权限原则申请，只选择当前功能真正会用到的 Scope。

在开始写代码前，建议先做一次环境检查。

3.2 用自定义机器人推送一条消息

当你没有任何业务系统时，可以用自定义机器人先验证消息通道。在对应 IM 群里添加自定义机器人后，会得到一个 Webhook 地址。调用时，把要发送的内容以 JSON 格式 POST 过去即可。

curl -X POST '{YOUR_WEBHOOK_URL}' \ -H 'Content-Type: application/json' \ -d '{ "msg_type": "text", "content": { "text": "这是一条来自能力调用示例的消息" } }'

如果返回成功，群里会收到一条文本消息。这个步骤的价值是确认网络链路、Webhook 地址和消息格式都没有问题。后续做 AI 工作助手时，所有结果回复都可以复用同一个通道。

注意：自定义机器人的 Webhook 地址包含密钥，泄露后任何人都能向群里发消息。不要把 Webhook 地址硬编码到前端页面或提交到公共仓库。

3.3 事件订阅：让平台主动通知你的服务

入口型应用通常是“用户拉取数据”，能力型应用则是“平台推送事件”。事件订阅的流程一般包含四步：

1. 在开放平台配置事件回调 URL。
2. 平台发送 URL 验证请求，开发者服务器正确返回加密后的 challenge 字符串。
3. 验证通过后，平台在业务事件发生时推送 JSON 数据。
4. 开发者服务器处理事件，并返回成功响应。

下面是一段处理事件回调的简化逻辑，用 Python 表示核心流程：

import json import hashlib import hmac from flask import Flask, request, jsonify app = Flask(__name__) # 这里使用示例密钥，实际要替换成开放平台下发的配置 ENCRYPT_KEY = "your_encrypt_key" SIGNING_TOKEN = "your_signing_token" def verify_signature(timestamp, nonce, signature, body): raw = "timestamp={}&nonce={}&body={}".format(timestamp, nonce, body) mac = hmac.new( SIGNING_TOKEN.encode("utf-8"), raw.encode("utf-8"), digestmod=hashlib.sha256 ).hexdigest() return mac == signature @app.route("/event/callback", methods=["POST"]) def event_callback(): data = request.get_json() # 真实场景中需要先解析 headers 中的 timestamp、nonce、signature # 再校验签名，校验失败时直接返回 401 if not verify_signature( request.headers.get("X-Timestamp", ""), request.headers.get("X-Nonce", ""), request.headers.get("X-Signature", ""), request.get_data(as_text=True) ): return jsonify({"code": 401, "message": "invalid signature"}), 401 event = data.get("event", {}) event_type = event.get("type") # 根据事件类型分发 if event_type == "message.receive": handle_user_message(event) elif event_type == "todo.created": handle_todo_created(event) # 平台要求快速返回，避免后续重试或超时 return jsonify({"code": 0})

这段代码需要重点关注三个点：签名校验、事件分发、快速响应。签名校验是防止伪造回调的关键；事件分发决定了系统能否扩展不同业务；快速响应则是为了避免平台超时重试。

3.4 用开放 API 创建待办：能力调用的最小单元

在入口型应用中，“创建待办”是一个表单页面；在能力型应用中，“创建待办”是一个 API 调用。下面用通用 JSON 展示请求结构，真实字段名要以平台开放 API 文档为准。

POST /open-apis/todo/v1/todos { "summary": "提交周报", "due_time": "2025-07-14T10:00:00+08:00", "assignee": "user_123" }

调用时通常需要在请求头里携带访问令牌：

Authorization: Bearer {ACCESS_TOKEN} Content-Type: application/json

成功返回后，服务器会收到一个待办 ID，后续查询、更新、完成操作都可以用这个 ID 关联。这里有一个工程上的关键点：创建类接口必须考虑幂等。AI 助手可能会因为网络超时而重复调用同一个请求，如果每次调用都生成一条新待办，用户就会看到大量重复数据。推荐在请求参数里加入幂等键，比如client_token或request_id，服务端识别同一请求后返回同一个待办 ID。

POST /open-apis/todo/v1/todos { "summary": "提交周报", "due_time": "2025-07-14T10:00:00+08:00", "assignee": "user_123", "client_token": "req_todo_20250714_001" }

幂等设计不仅是为了技术严谨，更是为了让 AI 工作助手在不确定执行结果时，可以安全地“重试一次”。

4. 做一个最小可用的“AI 工作助手”闭环

4.1 场景设定：用户通过 IM 一句话创建待办

现在把前面几节的能力串起来，做一个最小闭环。场景如下：

用户在企业 IM 群聊或单聊中给机器人发送消息：

明天上午十点提醒我提交周报

机器人收到事件回调后：

1. 解析消息，提取时间、动作和事项内容。
2. 调用待办创建 API，生成一条带截止时间的待办。
3. 把创建结果以消息或卡片形式回复给用户。

这个场景虽然简单，但已经覆盖了 AI 工作助手最核心的三个环节：意图接收、能力调用、结果反馈。

4.2 消息接收与解析：先用规则，再上模型

在真实项目中，自然语言解析可以选择大模型或规则引擎。最小闭环阶段不推荐一上来就接大模型，先用规则把链路跑通，能显著降低排错难度。

下面用一个简洁的 Python 函数展示规则解析思路：

import re def parse_todo_command(text): # 提取时间部分：明天上午十点 time_pattern = r"(今天|明天|后天|(\d{1,2})点|上午|下午)" # 提取动作和内容：提醒/创建/安排 + 事项 action_pattern = r"(提醒|创建|安排|记一下)\s*(.+)" due_time = "今天" if "明天" in text: due_time = "明天" elif "后天" in text: due_time = "后天" match = re.search(action_pattern, text) if not match: return None item = match.group(2).strip() return { "due_time": due_time, "summary": item, "remind": "提醒" in text }

这段代码不追求覆盖所有自然语言表达，而是为了说明一个思想：对话式入口与菜单式入口一样，都需要把用户输入转换成结构化请求。规则解析的好处是结果可控、便于排查，适合作为 AI 能力的降级方案。

4.3 调用待办 API 并回复结果

解析完成后，调用待办创建 API，再把结果拼成机器人消息发出。完整流程可以写成如下服务端函数：

import requests def handle_todo_request(user_id, text): parsed = parse_todo_command(text) if not parsed: send_im_message(user_id, "没有识别到待办内容，请说“明天上午十点提醒我提交周报”这样的格式") return # 调用待办 API，这里用占位地址代替 resp = requests.post( "https://open-platform.example.com/todo/v1/todos", headers={"Authorization": "Bearer " + get_app_access_token()}, json={ "summary": parsed["summary"], "due_time": parsed["due_time"], "assignee": user_id, }, timeout=5 ) if resp.status_code == 200: todo_id = resp.json().get("todo_id") send_im_message( user_id, f"已创建待办：{parsed['summary']}，截止时间：{parsed['due_time']}，ID：{todo_id}" ) else: # 这里要打印完整响应，方便排查 send_im_message(user_id, f"创建待办失败，错误码：{resp.status_code}")

在实际项目中，get_app_access_token需要携带 App ID、App Secret 去换取 access token，并且要根据有效期做缓存。不要每次请求都重新换 token，也不要无限期使用同一个 token，缓存过期时间通常以平台返回的过期时间为准。

4.4 运行验证：在 IM 里完成一次请求

将服务部署到本地或测试服务器后，按下面的顺序验证闭环是否完全打通。

如果第 3 步失败，说明消息事件没有送达你的服务端，先检查事件订阅地址、网络链路和服务是否在运行。如果第 4 步失败，说明问题在权限或 API 参数上，优先查看错误码。

注意：不要只验证程序能启动，还要验证输入、输出、异常分支和日志是否符合预期。对话式应用尤其如此，因为用户输入的每个词都可能影响最终结果。

5. 去掉“入口执念”后，最容易踩的坑和排错链路

5.1 Webhook 地址连不通

现象：在 IM 里发送消息后，机器人没有回复，服务端日志也没有任何请求记录。

可能原因：

• 事件订阅回调地址配置错误。
• 服务没有部署在公网可达的 HTTPS 地址上。
• 平台要求回调地址必须外网可访问，本地服务器默认不可达。
• 防火墙或安全组没有放行对应端口。

检查方式：

• 用 curl 或浏览器访问回调地址，确认是否能返回服务信息。
• 查看平台后台的“事件订阅”页面，确认回调地址是否已保存。
• 查看服务日志，确认是否收到任何请求。

处理建议：

• 本地调试时使用内网穿透工具，把本地端口映射成公网 HTTPS 地址。
• 正式环境使用域名 + HTTPS，并确保证书有效。
• 在回调入口加一条访问日志，记录来源 IP、路径和请求头，方便确认平台是否真的请求到了。

5.2 验签失败和事件重复推送

现象：回调接口偶尔返回验签失败，或者同一事件被处理多次，产生重复数据。

可能原因：

• 时间戳不准确，平台签名校验会包含时间窗口。
• 签名拼接顺序和官方文档不一致。
• 事件回调没有正确返回成功响应，平台进入重试机制。
• 消费者处理逻辑没有做幂等，重复消息被重复消费。

检查方式：

• 打印当前服务器时间和平台时间戳，确认是否有分钟级偏差。
• 对照官方示例逐字符核对签名算法。
• 查看返回码，确认是否在 200 毫秒以内返回{"code": 0}或同等成功结构。

处理建议：

• 所有事件回调处理器都加幂等键去重，比如用事件 ID 做去重表。
• 不要把耗时操作放在回调处理主线程里，先快速返回，再异步处理。
• 重试可能导致消息顺序变化，业务逻辑不要依赖回调到达顺序。

5.3 权限不足与 API 版本不匹配

现象：调用待办创建 API 返回forbidden、no permission或invalid scope。

可能原因：

• 应用没有申请对应的权限 Scope。
• 权限已申请，但应用发布或审核状态没有更新。
• 使用了旧版 API，官方已迁移到新接口。
• 用户没有在组织内开通对应功能。

检查方式：

• 查看开放平台“权限管理”页面，确认 Scope 状态是“已开通”而不是“申请中”。
• 查看接口文档，确认当前调用的路径和请求方法是否已废弃。
• 查看错误码，在官方错误码文档中检索具体含义。

处理建议：

• 按最小权限创建独立的内部应用，单独申请待办、消息等 Scope。
• 收到权限错误时，先检查 Scope 状态，再检查代码里的访问令牌是否来自同一个应用。
• 维护一份 SDK 版本清单，升级平台 SDK 前先阅读变更日志。

5.4 对话式接入的通用排错顺序

由于 AI 工作助手链路较长，排错时不要随意乱查。推荐按下面的顺序排查：

1. 输入是否正确：用户消息是否真的到达服务端，内容是什么。
2. 解析是否正确：消息有没有转成预期结构化参数。
3. 环境是否正确：回调地址、端口、应用凭证是否指向同一套环境。
4. 权限是否正确：调用 API 是否携带了有权限的 access token。
5. 依赖是否匹配：SDK 版本、API 版本、加密算法是否与平台要求一致。
6. 日志是否完整：错误码、请求 ID、响应体是否被记录。
7. 重试是否重复：事件重试是否产生了重复业务数据。

这张表可以作为团队内部排查对话式应用的基础流程：

6. 从“入口思维”到“Agent 思维”：落地的工程化建议

6.1 能力清单优先于界面清单

传统接入流程里，团队先讨论“在钉钉/飞书工作台里放几个菜单”，然后按页面拆任务。AI 工作助手的接入逻辑正好相反：先梳理自己业务里有哪些“可被调用的原子能力”，再为每个能力定义输入、输出、权限、错误码和幂等规则。

比如一个内部工单系统，入口型应用会拆出“工单列表页、工单详情页、新建工单页、审批页”。能力型应用应该拆出“创建工单、查询工单、更新状态、分配处理人、催办、关闭工单”。这些能力既可以被用户手动点击卡片调用，也可以被 WorkBuddy 这类 AI 助手通过自然语言触发。

在实现上，推荐每个能力对应一个独立接口，并附带结构化描述：

{ "tool_name": "create_todo", "description": "为用户创建一条待办事项", "input_schema": { "summary": "string, 必填, 待办标题", "due_time": "string, 可填, 截止时间", "assignee": "string, 必填, 创建者用户 ID" } }

这种描述一旦写清楚，不仅人可以读，AI 也能在运行时理解应该调用哪个工具、传什么参数。它相当于把“功能菜单”翻译成了“机器可读的能力目录”。

6.2 用幂等设计承接 Agent 的重复调用

AI 工作助手和人的交互有一个显著特点：它可能在执行结果不确定时进行重试，也可能因为用户换一种说法而重复触发同一个能力。如果业务接口不保证幂等，用户很快就会看到重复审批、重复待办、重复通知。

工程上的几项建议：

• 所有创建类接口都支持幂等键，服务端用幂等键做唯一索引。
• 事件消费处理加入去重表，事件 ID 或消息 ID 作为去重依据。
• 删除、更新操作要返回精确的被影响条数，方便冷启动时核对一致性。
• 所有外部 API 调用设置超时和重试次数，重试时沿用同一个请求 ID。

这样设计之后，AI 的“不确定”才不会变成业务的“混乱”。

6.3 生产环境还需要补什么

学习环境里把闭环跑通，只完成了 30% 的工作。生产环境要额外补齐以下内容：

• 配置外置化：App Secret、回调地址、加密 Key 放在环境变量或配置中心，不写进代码仓库。
• 日志与监控：记录每个回调的请求 ID、耗时、结果和错误码，并用告警监控回调失败率和 API 调用失败率。
• 限流与降级：平台有调用频率限制，AI 助手的高并发场景需要本地限流和排队；第三方 API 抖动时要有缓存或降级方案。
• 审计与权限复核：记录“谁在什么时间通过哪个 AI 工具调用了什么接口”，并定期检查权限 Scope 是否仍然必需。
• 回滚方案：新旧版本能力并存，AI 助手调用失败时可以自动回退到页面入口，保证用户至少有一条可用的操作路径。

6.4 可复用的接入检查清单

在接入钉钉、飞书或其他协作平台时，强烈建议按下面这份清单逐项打勾，减少上线后的问题。

这套清单同样适用于后续把能力开放给其他 AI 助手或内部自动化系统。

“入口执念”之所以会松动，是因为用户真正需要的不再是一个永远停留在屏幕上方的九宫格，而是一套能够理解意图、精准执行、及时反馈的能力系统。WorkBuddy 这类 AI 工作助手承担了导航和调度的职责，钉钉、飞书则回归到身份、组织和消息通道的本职。对开发者来说，现在最值得做的不是继续堆页面，而是把业务能力拆成一个个可复用的原子接口，让这些接口既能在 IM 里以卡片形式呈现，也能被 AI 助手在会话中直接调用。判断自己是否完成了这个转变，可以看一个问题：如果你的 AI 助手今天想替用户完成一个业务动作，它需要你的系统提供几个 API、几种权限、几条错误码，而不是打开几个页面。答案越简单，这套架构就越接近下一个阶段。