AI 概念图企业 AI 开发系列教程非产品实机截图。摘要AI 让软件实现更快也让架构选择更值得提前完成。本篇从采购业务出发分清 AI 客户端、业务引擎与基础设施的职责给出企业架构的八组问题、实际协作步骤和 30 篇系列路线。✦01先决定系统怎样运转再让 AI 动手把一份需求文档交给 WorkBuddy、Codex 或 DeepSeek HarnessAI 很快就能搭出页面、接口和数据库。第一次看到系统跑起来确实令人兴奋。但企业软件还要面对下一批用户、下一次需求变更、下一家分公司以及一次迟早会发生的故障。一个采购系统从“能新增订单”走到“能长期承载业务”中间还隔着权限、并发、事务、审计、附件、审批、打印、数据迁移与运维。企业真正需要评估的是这些能力由谁提供、如何组合、出了问题由谁维护。本系列的主张先从系统架构师的角度识别约束把成熟能力交给合适的引擎把业务差异交给 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 客户端相关文档。它们都给复用既有能力留下了明确入口。一个容易忽略的区别能够生成 Redis、数据库或工作流相关代码与已经拥有经过项目检验的缓存约定、租户隔离和审批规则是两种不同的工程状态。AI 可以帮助建设这些能力也可以直接使用已存在的实现。◆MCP、Skills 和引擎怎样一起工作MCP 为 AI 提供结构化工具入口Skills 告诉 AI 怎样按项目规范使用能力引擎在服务器与前端运行时执行具体业务。接口的存在不会自动赋予所有权限文档的存在也不会自动证明业务正确。例如“新增采购申请”不该只被翻译成一个页面文件。AI 应先发现当前租户的表、字段、菜单和接口避免重复建模再生成或更新符合协议的资源校验权限和关系最后在已授权的环境执行并回读结果。吾码的价值入口当能力已经存在于表单配置、V8 接口引擎、微服务或应用包中AI 可以围绕它们完成业务组合。团队减少的是重复建设范围而不是取消需求分析、测试和责任分工。✦03架构师开工前必须回答的八组问题◆① 业务边界系统到底负责哪一段流程先画清楚客户、订单、库存、付款、审批等实体之间的关系。区分“某张表归谁维护”“哪个系统是最终事实源”“哪些操作允许撤回”。同一客户散落在三个系统不能靠三个相似的输入框解决一致性问题。要写出业务状态机。例如采购申请允许从草稿进入审批驳回后能否修改、撤回后是否释放预算、已入库订单能否删除都属于业务规则。页面是否出现一个按钮应当由这些规则推导。◆② 分布式与高性能规模究竟是多少不要为了“看起来高级”直接拆成几十个微服务。先明确活跃用户、并发请求、表数据量、峰值任务、文件大小与响应目标再决定部署拓扑和扩容方式。一个模块边界清楚的单体也可以是合适的起点。高性能需要在真实数据规模下验证索引、分页、连接池、缓存命中、慢查询、排队和资源限制。框架提供能力不等于任意业务脚本都快“我的电脑打开很快”也不能代替生产容量规划。分布式的代价跨进程意味着网络会超时、消息可能重复、部分节点会失联。设计必须回答幂等、重试、降级、超时、补偿与可观测性而不只是把项目放进多个容器。◆③ 跨平台哪些终端真的要交付PC 管理后台、H5、微信小程序、Android、iOS 和桌面应用有不同的交互、权限与发布要求。共用接口和业务模型能减少重复工作但扫码、相机、文件预览、定位、离线和推送仍需逐端验证。◆④ 跨数据库兼容范围如何定义ORM 和引擎可以屏蔽一部分差异。复杂 SQL、日期函数、分页、大小写、精度、事务隔离、索引和执行计划仍有数据库差异。应优先使用平台提供的参数化查询与标准 API再单独验证必要的专用 SQL。“支持多种数据库”需要结合具体版本、驱动和功能范围理解。已经绑定一个数据库的业务系统也应考虑备份恢复、迁移脚本与数据校验而不是只看连接是否成功。◆⑤ 权限与租户谁能对什么做什么权限至少涉及登录身份、角色部门、菜单动作、表操作、数据行与附件。隐藏按钮只是用户体验的一部分直接请求接口、跨租户访问、导出与下载也必须遵守服务器权限。◆⑥ 变化管理下个月新增字段怎么办业务系统会持续修改。新增字段、改选项值、调整流程和换报表都要考虑历史数据、迁移、回滚和版本兼容。元数据驱动的引擎可以集中表达大量重复变化减少散落在各页面中的分叉实现。◆⑦ 运行与恢复故障出现后如何查清楚要准备业务日志、异常日志、链路关联、性能指标、告警、备份与恢复演练。API 进程返回正常只能证明这次探测有响应数据库、文件服务和实际业务流程仍可能失败。◆⑧ AI 治理AI 获得多少权力明确 AI 可访问的环境、数据、工具、模型、预算和写入范围。只读分析、测试库变更、生产操作应分别授权。外部网页、附件和工具返回的数据不能自动升级为可执行的管理指令。架构示意图业务规则、通用引擎、运行服务与基础设施需要明确分工。✦04从一张采购单看见整套引擎体系设想员工提交一张采购单选择供应商、增加商品、上传报价附件主管审批财务核对预算仓库收货最后生成报表与通知。这是一条很普通的业务链却自然牵涉多个引擎。◆数据进入系统表单、模块、数据源表单引擎定义字段、控件、校验、布局和事件模块引擎把业务组织成列表、筛选、操作与导航数据源引擎为供应商、商品等选择项提供可维护的数据入口。三个部分协同才能把“录一条数据”做成稳定业务操作。◆业务开始流转动态接口与工作流接口引擎承载预算计算、状态校验与系统集成工作流引擎负责流程节点、条件路线和待办。流程图表达审批路径服务器业务逻辑维护不可绕过的约束两者要共同保护业务结果。◆文件成为业务资产存储、Office、打印附件进入统一存储与访问控制Office 在线能力涉及文件预览、编辑和版本打印引擎表达纸张、模板和输出布局。合同文件可访问不等于任何用户都可下载打印请求已发送也不等于设备已经出纸。◆任务继续在后台运行调度、MQ、通知大批量导出、同步和重试可以进入后台任务。消息队列帮助解耦但消费者要幂等任务调度要考虑多实例抢占和失败恢复消息通知要区分平台提醒、邮件或其它通道的送达状态。◆企业开始分析经营报表、搜索、AI 分析报表将数据组织成稳定指标搜索帮助跨业务定位信息AI 分析让用户用自然语言探索数据。所有统计都应明确口径和权限AI 生成的结论还需要可核查的数据来源。引擎之间的边界一个引擎可以专注解决一类重复问题。业务系统的质量则取决于这些引擎如何协同以及业务规则是否覆盖正常、异常、重复和越权路径。✦0530 篇系列路线逐一讲清“为什么需要”这一篇先建立判断框架。后续计划按下面的路线逐步展开具体顺序可随着案例调整。每篇都围绕业务问题、关键配置、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 端到端交付案例从业务蓝图到建模、发布、回读与持续维护。如何阅读这份路线不必把全部引擎安装进第一个项目。先找到业务瓶颈选需要的能力每增加一项依赖都明确配置、成本、故障和升级责任。✦06WorkBuddy、Codex、DeepSeek Harness 的协作流程◆第一步让 AI 先看见现状为团队维护项目规则、引擎文档和必要的 Skills根据客户端当前官方方式连接吾码 MCP。先确认服务器、租户和权限再读取现有表结构、菜单、应用与接口。不同客户端的配置入口会变化不能把一份客户端配置文件机械复制到所有产品。◆第二步让 AI 先设计可验证的业务边界需求里不只写“做一个采购管理”还应写角色、数据范围、状态流转、输入输出和异常。把开放问题留给业务负责人决定例如审批额度、数据保留期限和撤回规则这些内容不应由 AI 默默猜测。案例采购申请 角色申请人、部门主管、采购员、审计员。 范围申请人只看本人审计员只读授权范围。 规则金额由服务端按有效明细重算审批后禁止直接改价。 验收正常提交、重复提交、越权读取、附件下载、撤回重提。◆第三步决定每段能力落在哪里标准字段、列表与常规增删改查优先配置表单和模块。与数据提交紧密相关的规则放在适合的表单服务端事件。可复用的业务动作和系统对接使用接口引擎编排。复杂交互、专业图形与长期维护的定制页面使用微服务或定制组件。只有确实缺少可复用的底层原子能力时才评估平台扩展。◆第四步先检查方案再进行受控变更读取 Manifest 协议检查计划并执行 dry-run核对影响对象。确认写入范围后再落地配置。应用包要声明资源管理策略区分平台管理的资源与客户自行扩展的 Hook业务数据和客户配置不能被升级流程粗暴覆盖。◆第五步用业务结果收尾建表返回成功后再查字段、关系与菜单页面能打开后再测角色、列表、表单和附件任务提交后再查后台状态及最终文件。一次 API 成功、一次构建通过、一次镜像推送都只能证明交付链中的某一段。流程示意图每个阶段都有独立的输出与检查对象避免把“已生成”当作“已交付”。团队可以这样分工业务负责人定义规则与取舍架构师确定边界与约束AI 完成有依据的实现和检查开发与测试人员审查关键路径运维人员验证部署、监控和恢复。小团队可一人承担多个角色但工作内容仍需要被覆盖。✦07选择吾码时同样要做一份真实评估◆值得复用的部分必须能算清楚评估一个框架时可以选择一个有代表性的业务切片比较从需求到上线的总投入。把学习、配置、定制、测试、运维、升级、迁移和退出成本都放进去而不是只比较第一次页面生成的速度。适配度现有引擎能覆盖多少稳定需求独特需求的扩展入口是否清晰可维护性元数据、脚本、组件和应用包能否版本管理、审查与迁移数据控制数据、文件、凭据和日志存放在哪里谁可以访问部署条件所需基础服务、网络、硬件和外部服务是否满足企业要求授权与成本逐项确认所用模块、产品版本和第三方服务的许可及费用不能把所有能力都默认理解为免费开源。退出能力能否导出业务数据、保存自有逻辑、记录接口协议并制定替换计划关于效率的表述复用成熟引擎通常能减少重复实现但具体节省多少时间、Token 或维护成本取决于需求、团队、模型、环境和验证范围。本篇不把某个项目的体验写成所有项目都能兑现的倍数承诺。◆一份小而完整的概念验证比口号更有说服力可以从“采购申请明细私有报价附件主管审批打印”开始。用同一份验收清单对照不同方案记录工作量、缺陷、部署复杂度与二次变更成本。首次交付之外再追加一次字段变更和一次权限调整往往更容易看出维护差异。◆需要定制并不说明引擎失去价值标准能力和差异化能力本来就应该共存。行业排产、复杂报价、专用算法和三维交互可以有独立实现身份、数据访问、附件、日志和发布流程仍可复用。关键是把扩展边界保持清楚。✦08下一步从最常见的表单开始企业软件中最常见、最容易被低估的对象就是表单。一张表单既是交互界面也是数据模型、业务规则、权限和生命周期的交汇处。下一篇将从当前 44 类控件出发把表单级配置和各控件的个性化能力逐项讲清楚。◆可以交给团队讨论的三个问题我们的新项目有哪些能力正在重复实现如果需求下个月改变哪些修改能集中完成哪些会散落在各处哪些验收证明业务已经可用哪些只证明代码已经生成本系列的期待让 AI 在明确的架构和成熟引擎上持续创造业务价值。选择哪一种工具、复用哪一套底座都应该来自可解释的需求和可验证的结果。◆延伸阅读Microi吾码官方文档https://microi.net/doc/indexOpenAI Codex MCP 官方文档https://learn.chatgpt.com/docs/extend/mcp?surfacecliWorkBuddy MCP 官方文档https://www.workbuddy.ai/docs/zh/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/MCP-GuideDeepSeek 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生成的概念图架构与配置示意图为确定性绘制。概念图不代表产品实机界面技术内容依据当前官方资料与实现核对。