企业官网建设流程全解析

AI 概念图｜企业 AI 开发系列教程，非产品实机截图。

✦01｜先决定系统怎样运转，再让 AI 动手

把一份需求文档交给 WorkBuddy、Codex 或 DeepSeek Harness，AI 很快就能搭出页面、接口和数据库。第一次看到系统跑起来，确实令人兴奋。但企业软件还要面对下一批用户、下一次需求变更、下一家分公司，以及一次迟早会发生的故障。

一个采购系统，从“能新增订单”走到“能长期承载业务”，中间还隔着权限、并发、事务、审计、附件、审批、打印、数据迁移与运维。企业真正需要评估的是：这些能力由谁提供、如何组合、出了问题由谁维护。

◆您可以把这句话放进团队的第一份开发约定

请先阅读项目规范，盘点现有系统、数据模型与可复用引擎。 提交业务边界、架构选择、权限矩阵和验收方案。 说明需要新增的能力，以及复用方案不适用的具体原因。 确认设计后，再分阶段实现并用真实业务结果验收。

“从 0 开始”有它的价值。一次性脚本、概念验证、探索性产品、特殊算法，可能用一个小项目就能解决。企业也可能已有成熟自研底座，继续复用它比迁移框架更合理。判断依据应是适配度与总拥有成本。

对于 ERP、MES、OA、CRM、项目管理、供应链和多租户平台，许多基础能力会不断重复出现。每个项目都重新生成一遍，团队就要不断重新承担这些能力的设计、测试、迁移和维护成本。

✦02｜分清 AI 客户端、业务引擎和基础设施

◆三者配合时，各自承担什么

• AI 客户端与 Agent 运行环境：理解需求、读取上下文、调用工具、修改代码、执行验证。WorkBuddy、Codex、DeepSeek Harness 各有自己的产品定位与运行机制。
• Microi吾码这类应用框架：提供可复用的业务建模、表单、模块、动态接口、工作流、租户、权限与运行约定，让 AI 有一套明确的操作对象。
• 基础设施与外部服务：数据库、Redis、对象或文件存储、消息中间件、搜索服务、容器、身份提供方和模型服务，负责真实数据与服务运行。

AI 概念图｜连接两端的关键是清晰的协议、工具与边界；图中建筑不是产品界面。

OpenAI 的 Codex MCP 文档说明了通过 MCP 连接工具与上下文的方法；WorkBuddy 官方文档也介绍了 MCP 对外部工具和业务系统的接入。DeepSeek Harness 官方资料强调通过插件组合 Agent 能力，并提供 MCP 客户端相关文档。它们都给复用既有能力留下了明确入口。

◆MCP、Skills 和引擎，怎样一起工作

MCP 为 AI 提供结构化工具入口；Skills 告诉 AI 怎样按项目规范使用能力；引擎在服务器与前端运行时执行具体业务。接口的存在不会自动赋予所有权限，文档的存在也不会自动证明业务正确。

例如，“新增采购申请”不该只被翻译成一个页面文件。AI 应先发现当前租户的表、字段、菜单和接口，避免重复建模；再生成或更新符合协议的资源，校验权限和关系；最后在已授权的环境执行，并回读结果。

✦03｜架构师开工前必须回答的八组问题

◆① 业务边界：系统到底负责哪一段流程

先画清楚客户、订单、库存、付款、审批等实体之间的关系。区分“某张表归谁维护”“哪个系统是最终事实源”“哪些操作允许撤回”。同一客户散落在三个系统，不能靠三个相似的输入框解决一致性问题。

要写出业务状态机。例如采购申请允许从草稿进入审批；驳回后能否修改、撤回后是否释放预算、已入库订单能否删除，都属于业务规则。页面是否出现一个按钮，应当由这些规则推导。

◆② 分布式与高性能：规模究竟是多少

不要为了“看起来高级”直接拆成几十个微服务。先明确活跃用户、并发请求、表数据量、峰值任务、文件大小与响应目标，再决定部署拓扑和扩容方式。一个模块边界清楚的单体，也可以是合适的起点。

高性能需要在真实数据规模下验证索引、分页、连接池、缓存命中、慢查询、排队和资源限制。框架提供能力不等于任意业务脚本都快；“我的电脑打开很快”也不能代替生产容量规划。

◆③ 跨平台：哪些终端真的要交付

PC 管理后台、H5、微信小程序、Android、iOS 和桌面应用有不同的交互、权限与发布要求。共用接口和业务模型能减少重复工作，但扫码、相机、文件预览、定位、离线和推送仍需逐端验证。

◆④ 跨数据库：兼容范围如何定义

ORM 和引擎可以屏蔽一部分差异。复杂 SQL、日期函数、分页、大小写、精度、事务隔离、索引和执行计划仍有数据库差异。应优先使用平台提供的参数化查询与标准 API，再单独验证必要的专用 SQL。

“支持多种数据库”需要结合具体版本、驱动和功能范围理解。已经绑定一个数据库的业务系统，也应考虑备份恢复、迁移脚本与数据校验，而不是只看连接是否成功。

◆⑤ 权限与租户：谁能对什么做什么

权限至少涉及登录身份、角色部门、菜单动作、表操作、数据行与附件。隐藏按钮只是用户体验的一部分；直接请求接口、跨租户访问、导出与下载也必须遵守服务器权限。

◆⑥ 变化管理：下个月新增字段怎么办

业务系统会持续修改。新增字段、改选项值、调整流程和换报表，都要考虑历史数据、迁移、回滚和版本兼容。元数据驱动的引擎可以集中表达大量重复变化，减少散落在各页面中的分叉实现。

◆⑦ 运行与恢复：故障出现后如何查清楚

要准备业务日志、异常日志、链路关联、性能指标、告警、备份与恢复演练。API 进程返回正常，只能证明这次探测有响应；数据库、文件服务和实际业务流程仍可能失败。

◆⑧ AI 治理：AI 获得多少权力

明确 AI 可访问的环境、数据、工具、模型、预算和写入范围。只读分析、测试库变更、生产操作应分别授权。外部网页、附件和工具返回的数据，不能自动升级为可执行的管理指令。

架构示意图｜业务规则、通用引擎、运行服务与基础设施需要明确分工。

✦04｜从一张采购单，看见整套引擎体系

设想员工提交一张采购单：选择供应商、增加商品、上传报价附件，主管审批，财务核对预算，仓库收货，最后生成报表与通知。这是一条很普通的业务链，却自然牵涉多个引擎。

◆数据进入系统：表单、模块、数据源

表单引擎定义字段、控件、校验、布局和事件；模块引擎把业务组织成列表、筛选、操作与导航；数据源引擎为供应商、商品等选择项提供可维护的数据入口。三个部分协同，才能把“录一条数据”做成稳定业务操作。

◆业务开始流转：动态接口与工作流

接口引擎承载预算计算、状态校验与系统集成；工作流引擎负责流程节点、条件路线和待办。流程图表达审批路径，服务器业务逻辑维护不可绕过的约束，两者要共同保护业务结果。

◆文件成为业务资产：存储、Office、打印

附件进入统一存储与访问控制；Office 在线能力涉及文件预览、编辑和版本；打印引擎表达纸张、模板和输出布局。合同文件可访问，不等于任何用户都可下载；打印请求已发送，也不等于设备已经出纸。

◆任务继续在后台运行：调度、MQ、通知

大批量导出、同步和重试可以进入后台任务。消息队列帮助解耦，但消费者要幂等；任务调度要考虑多实例抢占和失败恢复；消息通知要区分平台提醒、邮件或其它通道的送达状态。

◆企业开始分析经营：报表、搜索、AI 分析

报表将数据组织成稳定指标；搜索帮助跨业务定位信息；AI 分析让用户用自然语言探索数据。所有统计都应明确口径和权限，AI 生成的结论还需要可核查的数据来源。

✦05｜30+ 篇系列路线：逐一讲清“为什么需要”

这一篇先建立判断框架。后续计划按下面的路线逐步展开；具体顺序可随着案例调整。每篇都围绕业务问题、关键配置、AI 协作方法与验收标准展开，而不是堆叠功能名词。

◆第一组：把业务模型变成可维护的软件

• 02 表单引擎：字段、44 类当前控件、个性化配置、布局、附件和表单事件。
• 03 模块引擎：菜单、列表、筛选、排序、按钮与数据权限如何保持一致。
• 04 数据源引擎：选项、查询与外部数据的统一管理，避免下拉框各写一套。
• 05 动态接口与 V8 引擎：业务逻辑如何在明确的事务和权限边界中执行。
• 06 工作流引擎：节点、条件、待办、退回、撤回与流程异常处理。
• 07 界面引擎：如何组织仪表盘、业务页面与可配置布局。
• 08 打印引擎：模板、纸张、分页、条码与真实打印验收。
• 09 报表引擎：指标口径、查询、汇总、明细钻取与导出。

◆第二组：交付不同用户、不同客户、不同终端

• 10 SaaS 引擎：租户识别、配置、隔离与多租户运维边界。
• 11 身份与权限：会话、角色、部门、数据范围和敏感操作验证。
• 12 SSO：外部身份认证与本系统业务授权怎样连接。
• 13 前端微服务：独立页面、路由、复杂弹窗与主框架集成。
• 14 应用商城：声明式资源、版本、安装、升级与客户扩展保留。
• 15 跨数据库与 ORM：通用查询能力、数据库差异和迁移验证。
• 16 UniApp、H5、小程序与 APP：公共业务模型和终端差异的分工。
• 17 前端 SDK 与定制组件：让已有网站和专业控件接入同一业务体系。
• 18 多语言翻译：词条、业务文本、回退与语言环境的一致性。

◆第三组：把系统运行稳定

• 19 分布式缓存：键命名、租户范围、失效、穿透与一致性。
• 20 分布式文件存储：公开/私有文件、签名访问、生命周期与备份。
• 21 搜索引擎：索引、同步、权限过滤与最终一致性。
• 22 任务调度：定时、可靠后台任务、租约和失败重试。
• 23 MQ 消息队列：生产、消费、幂等、死信与补偿。
• 24 MQTT 与 IoT：设备连接、主题权限、消息处理和设备状态。
• 25 消息通知：站内提醒、邮件与业务通道的统一编排。
• 26 系统日志与监控：从一次失败请求追到真实依赖与业务原因。
• 27 部署、升级与性能：容器、容量、灰度、回滚及恢复演练。
• 28 HTTP/TCP 与设备集成：第三方接口、回调、超时与设备执行结果。

◆第四组：让 AI 进入业务，而不丢失控制

• 29 MCP 与 Skills：能力发现、上下文、工具边界和团队规范。
• 30 AI 引擎：模型调用、结构化结果、知识库与业务编排。
• 31 AI 数据分析：问数、查询权限、指标口径与结论可追溯。
• 32 AI 平台治理：应用、模型、调用、配额、凭据和执行过程管理。
• 33 OCR：票据、文档识别、置信度、人工复核与业务入库。
• 34 视觉引擎：视觉任务、服务部署、身份验证与业务授权边界。
• 35 Office 在线编辑与导入导出：格式、版本、数据校验和文件权限。
• 36 3D、Unity 与数字孪生：业务数据、三维场景和设备状态怎样协同。
• 37 采集与系统对接：授权数据来源、任务节奏、解析和质量检查。
• 38 端到端交付案例：从业务蓝图到建模、发布、回读与持续维护。

✦06｜WorkBuddy、Codex、DeepSeek Harness 的协作流程

◆第一步：让 AI 先看见现状

为团队维护项目规则、引擎文档和必要的 Skills；根据客户端当前官方方式连接吾码 MCP。先确认服务器、租户和权限，再读取现有表结构、菜单、应用与接口。不同客户端的配置入口会变化，不能把一份客户端配置文件机械复制到所有产品。

◆第二步：让 AI 先设计可验证的业务边界

需求里不只写“做一个采购管理”，还应写角色、数据范围、状态流转、输入输出和异常。把开放问题留给业务负责人决定，例如审批额度、数据保留期限和撤回规则；这些内容不应由 AI 默默猜测。

案例：采购申请 角色：申请人、部门主管、采购员、审计员。 范围：申请人只看本人；审计员只读授权范围。 规则：金额由服务端按有效明细重算；审批后禁止直接改价。 验收：正常提交、重复提交、越权读取、附件下载、撤回重提。

◆第三步：决定每段能力落在哪里

• 标准字段、列表与常规增删改查，优先配置表单和模块。
• 与数据提交紧密相关的规则，放在适合的表单服务端事件。
• 可复用的业务动作和系统对接，使用接口引擎编排。
• 复杂交互、专业图形与长期维护的定制页面，使用微服务或定制组件。
• 只有确实缺少可复用的底层原子能力时，才评估平台扩展。

◆第四步：先检查方案，再进行受控变更

读取 Manifest 协议，检查计划并执行 dry-run，核对影响对象。确认写入范围后再落地配置。应用包要声明资源管理策略，区分平台管理的资源与客户自行扩展的 Hook；业务数据和客户配置不能被升级流程粗暴覆盖。

◆第五步：用业务结果收尾

建表返回成功后，再查字段、关系与菜单；页面能打开后，再测角色、列表、表单和附件；任务提交后，再查后台状态及最终文件。一次 API 成功、一次构建通过、一次镜像推送，都只能证明交付链中的某一段。

流程示意图｜每个阶段都有独立的输出与检查对象，避免把“已生成”当作“已交付”。

✦07｜选择吾码时，同样要做一份真实评估

◆值得复用的部分，必须能算清楚

评估一个框架时，可以选择一个有代表性的业务切片，比较从需求到上线的总投入。把学习、配置、定制、测试、运维、升级、迁移和退出成本都放进去，而不是只比较第一次页面生成的速度。

• 适配度：现有引擎能覆盖多少稳定需求？独特需求的扩展入口是否清晰？
• 可维护性：元数据、脚本、组件和应用包能否版本管理、审查与迁移？
• 数据控制：数据、文件、凭据和日志存放在哪里？谁可以访问？
• 部署条件：所需基础服务、网络、硬件和外部服务是否满足企业要求？
• 授权与成本：逐项确认所用模块、产品版本和第三方服务的许可及费用，不能把所有能力都默认理解为免费开源。
• 退出能力：能否导出业务数据、保存自有逻辑、记录接口协议并制定替换计划？

◆一份小而完整的概念验证，比口号更有说服力

可以从“采购申请＋明细＋私有报价附件＋主管审批＋打印”开始。用同一份验收清单对照不同方案，记录工作量、缺陷、部署复杂度与二次变更成本。首次交付之外，再追加一次字段变更和一次权限调整，往往更容易看出维护差异。

◆需要定制，并不说明引擎失去价值

标准能力和差异化能力本来就应该共存。行业排产、复杂报价、专用算法和三维交互可以有独立实现；身份、数据访问、附件、日志和发布流程仍可复用。关键是把扩展边界保持清楚。

✦08｜下一步：从最常见的表单开始

企业软件中最常见、最容易被低估的对象就是表单。一张表单既是交互界面，也是数据模型、业务规则、权限和生命周期的交汇处。下一篇将从当前 44 类控件出发，把表单级配置和各控件的个性化能力逐项讲清楚。

◆可以交给团队讨论的三个问题

• 我们的新项目，有哪些能力正在重复实现？
• 如果需求下个月改变，哪些修改能集中完成，哪些会散落在各处？
• 哪些验收证明业务已经可用，哪些只证明代码已经生成？

◆延伸阅读

• Microi吾码官方文档：https://microi.net/doc/index
• OpenAI Codex MCP 官方文档：https://learn.chatgpt.com/docs/extend/mcp?surface=cli
• WorkBuddy MCP 官方文档：https://www.workbuddy.ai/docs/zh/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/MCP-Guide
• DeepSeek Harness 官方介绍：https://www.deepseek.com/harness/
• DeepSeek Harness MCP 包文档：https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/mcp/README.md

客户端能力与配置入口以各自当前版本为准；本文基于 2026 年 9 月 26 日可核对的官方资料与吾码实现撰写。系列路线中的后续文章为写作计划，不代表已经发布。

本文由AI辅助创作，配图包含AI生成的概念图；架构与配置示意图为确定性绘制。概念图不代表产品实机界面，技术内容依据当前官方资料与实现核对。