企业官网建设流程全解析

FDE岗位实务指南 · 第12篇

业务人员常会问：“我在企微里点了确认，为什么旧系统里的记录没有变？”技术同事则可能回答：“工作流节点已经成功了。”两句话都可能为真，但它们没有回答同一个问题。前者关心业务结果是否真的写入，后者只说明某一段流程没有报错。

FDE不必成为每个系统的管理员，却需要读懂一条业务请求从哪里进、经过哪里、最后写到哪里。系统图的作用也不是展示组件有多少，而是把责任边界、数据状态、身份和待验证条件摆在同一张图上，让业务人员能指出：哪一段由我们配置，哪一段要找系统负责人，哪一个“成功”还不能当作业务完成。

本文用一套教学架构说明：企微多维表格承载业务记录和入口；Agent平台负责资料提取与流程编排；受控连接器访问既有业务系统。产品名称只用于说明职责，不构成具体产品配置教程；连接方式、权限和接口能力均需在实际项目中验证。

一次点击经过了哪些地方

先从一个很小的动作开始。采购员在企微多维表格中打开申请 A-017，提交供应商附件，点击“发起核验”。这一点击并不等于“数据已经进入旧系统”。它只是创建了一条业务请求，后面至少还有读取、提取、确认、授权写入和回读核验几个环节。

可以先画出窄而完整的主链路：

采购员 → 企微业务记录(A-017 V2) → Agent工作流 → 人工确认 → 受控连接器 → 既有业务系统 → 回读结果 → 企微核验记录

每一段都要标注输入与输出。企微记录输出申请ID、版本、附件引用和发起人；Agent工作流输出候选资料与解释；人工确认输出确认字段与确认人；连接器输出一次受控写请求；既有系统输出真实记录或错误；回读把真实结果关联回企微。

这样读图时，一眼就能判断问题在哪：候选资料不对，先查工作流输入与提示规则；确认人不对，查身份与权限；旧系统没变，查连接器请求、写入回执和回读结果。不要用“AI那边有问题”这种总称掩盖边界。

画清数据、模型和业务系统的职责

企微多维表格适合承载轻量的业务台账、人员协作入口和过程记录。它可以存申请ID、版本、附件链接、候选状态、确认状态和待办，但不应被默认当作所有业务系统的唯一事实来源。实际是否作为主数据、能否写入、谁能访问，要由业务治理和系统现状决定。

Agent平台负责把可配置流程串起来，例如解析附件、调用模型生成候选、检查必填信息、把候选交给人工确认。它的职责是编排和辅助判断，不天然拥有业务审批权，也不应在没有受控接口的情况下直接改变关键业务状态。

既有业务系统负责其权威记录与核心交易，例如采购申请、订单、库存或财务凭证。连接器是受控通道：它带着明确的目标ID、字段范围、身份和请求ID访问业务系统。没有连接器时，人工桥接也可以存在，但要把“待人工录入”画在图上，不能画成已经自动写回。

为了避免误会，可用第二张职责图：

企微：入口、协作、过程记录 Agent平台：提取、判断、编排、候选输出 业务系统：权威交易记录与最终业务状态 连接器：带身份、范围和回执的受控通道

这里有两个常见错觉。第一，企微表中的“负责人”字段不是API调用身份；字段是业务信息，后台实际用什么凭据、权限是否有效，必须另行验证。第二，工作流节点显示成功，不等于业务系统写入成功；它可能只表示请求发出、参数组装完成，或者成功写入了中间记录。

沿输入到实际写入走一遍

把第11篇的动作卡接到系统图。A-017 V2 的原始资料进入企微，Agent生成候选资料，采购员在界面确认。确认后，流程生成一条“保存核验结果”的受控请求。该请求至少带申请ID、版本、确认字段、可信身份和请求ID；它不应只带一段自然语言。

教学内部消息可以写得很短：

{ "request_id": "verify-A017-V2-001", "target": {"application_id": "A-017", "version": "V2"}, "confirmed_fields": ["supplier", "quantity", "delivery_date"], "actor": "trusted-identity-reference", "action": "save_verification_result" }

这不是官方API请求，也不是拿来直接复制的接口定义；它只帮助团队检查一件事：连接器收到的到底是可定位、可审计的动作请求，还是一句“帮我处理一下”。

请求进入既有系统后，必须返回可验证的结果。理想结果包括目标记录ID、实际写入字段、执行时间和状态；若失败，要有可解释的错误；若超时或网络中断，则为未知，需要按请求ID查询，不能直接重试。最后一步回读最容易被忽略，却最能回答业务问题：真实业务记录是否已经有这次核验结果？

数据状态也要沿线标。原始资料是原始；模型抽取的是候选；人工点选之后是已确认；既有系统写入后才是实际记录。候选不能冒充确认，确认也不能冒充已写入。把这四层画在图旁边，许多“为什么显示已完成”的争议会立即变清楚。

说明身份、依赖与待验证条件

系统图应把已具备与待验证分开画。比如“企微可保存申请记录”“Agent可生成候选”可能是现有能力；“连接器可按请求ID幂等写入旧系统”“写入后能回读所有字段”则是需要系统负责人确认的能力。不要在方案图里把待验证的连线画成已上线能力。

可以为三处连接各写一张小注释。A：企微到Agent，确认是否能安全传递附件引用、申请ID和版本；B：Agent到连接器，确认是否能传递可信身份、请求ID和已确认范围；C：连接器到旧系统，确认读写权限、字段映射、错误返回和回读接口。每张注释都写责任人和验证方式。

身份链要单独看。业务表中记录“采购员张三”只是业务角色；Agent工作流用哪个运行身份、连接器用哪个服务身份、旧系统按何种权限校验，是三个问题。它们可以有关联，但绝不能靠显示名称推断。如果需要人工确认，也要记录确认人的业务身份，并在动作执行前验证它是否满足规则。

依赖关系同样是风险来源。模型服务不可用时，能否退回人工填写？旧系统接口超时时，企微记录显示什么状态？附件解析失败时，候选资料是否保留为空？这些不是上线后才处理的技术细节，而是业务连续性的一部分。图上把“人工桥接”“待查询”“待补充”画出来，团队才能提前约定谁接手。

让另一位同事读图解释故障

一张系统图是否合格，最简单的检验是请没参与设计的同事用它解释故障。给他三个问题：采购员看到“节点成功”，但旧系统没有变化，他先查哪一段？候选资料来自旧版附件，谁负责阻止写入？连接器超时后，为什么不能立即再点一次？

如果图能让他回答：先查连接器回执与旧系统回读；在版本校验和确认依据处拦截；先按请求ID查询实际状态，那么图已经在支撑协作。如果他只能说“找技术看看”，图还停留在展示层。

FDE在评审时可以使用五项检查：每条连线是否写了输入和输出；每个系统是否有清晰职责；每个写动作是否有可信身份与请求ID；每个“成功”是否对应实际记录；每个待验证连接是否有责任人和验证计划。它不要求一次画出全企业架构，却能让一个具体业务闭环可读、可测、可追责。

企微、Agent平台和业务系统的关系，不是谁替代谁，而是各自在正确的边界内承担职责。FDE要守住的是最后一公里：业务人员看到的完成状态，必须能追到真实对象、真实动作与真实结果。