深夜11点,某中型建筑公司的总经理李总,正对着电脑屏幕上密密麻麻的Excel表格皱眉。这是他为明天季度经营会准备的“项目经营分析”,数据来自成本部、物资部、工程部七八个不同格式的报表。

“成本超支3.2%,但物资报表显示采购节约了5%,这数据对不上啊……”他揉了揉太阳穴,知道明天的会议,又将陷入长达两小时的数据核对与拉扯中。

而同一时间,公司的采购主管小张,正在某查查网站上,手动翻看着一家潜在供应商的司法风险、经营异常信息。她需要为这份评估报告附上自己的“主观判断”,但心里直打鼓:“信息不全,万一踩雷了怎么办?”

这,就是当下无数工程企业数字化转型中,最真实、也最容易被忽略的切面。当我们谈论选择“红圈”还是“明建云”时,绝大多数决策者还停留在功能列表的比对:谁的功能模块多?谁的界面更美观?谁的价格更优惠?

但一个灵魂拷问往往被淹没在参数里:这款软件,究竟解决了我们公司里,哪个具体“人”的痛点?是让总经理决策更安心了,还是让采购员睡觉更踏实了?

今天,我们就抛开冰冷的功能清单,潜入工程企业的真实场景,看看当红圈遇上明建云,关键分水岭不在“事”的管理,而在对“人”的赋能。

在为经营会头疼?你可能缺个能“读心”的AI军师

工程企业的老板或高管,最缺的是什么?时间。最烦的是什么?开会。

传统经营会的困境堪称经典:会前,项目人员整理数据容易出现漏、误、错,汇报内容与实际情况偏差大,准备仓促缺少结构化分析。会上,大量时间耗费在矫正数据和集体分析问题上,而非形成有效决议。会后,行动计划执行与否、结果如何,难以跟踪。

问题的核心是:管理者被困在数据迷雾里,缺少一双能瞬间穿透表象、直抵核心的“眼睛”。

红圈的思路是,不给管理者增加阅读负担,而是直接给他一个“智能指挥官”。这个就是红圈AI的“项目360°AI解读”,像一位永不疲倦的经营分析师。它通过整合全维经营指标(资金/成本/合同/付款等),一键生成项目全景作战图,并借助大模型深度解读经营风险与应对策略。其目标是让复杂数据转化为清晰决策语言,让管理全局尽在掌握。

管理者获得的不是简单报表,而是一份带有 “AI智能评级” (对项目经营状况综合评定后智能分级)和 “AI经营分析” (用3句以内描述描述核心问题)的洞察报告。更重要的是,它能围绕项目风险及问题,匹配业务管理实践方案,提供可落地的改进建议,将研讨快速转变为行动。这背后,是AI在调用行业专家经验积累进行诊断。

那么,以流程稳健著称的明建云呢?

明建云能出色地完成一项基础且至关重要的工作:把经营数据规范、清晰、实时地呈现出来。它能够帮助管理者实时了解项目整体资金状况是否安全、经营风险是否可控这给了管理者一双“看得清”的眼睛,解决了信息不透明的问题。

但红圈AI想给的是 “看得懂且会思考” 的眼睛。一个帮你“呈现数据”,一个试图帮你“分析数据并给出策略雏形”。对于日理万机、需要在信息洪流中快速抓住关键的管理者而言,后者解决的不仅仅是“看”的问题,更是 “判断”和“决策启动”效率的问题,能够让经营决策效率提升10倍。当你的软件开始尝试帮你思考业务,这已经是从“工具”到“伙伴”的跨越。

供应商评估还在“凭感觉”?小心埋下赔光利润的雷

在工程行业,一次失败的供应商选择,足以拖垮一个项目的利润。传统采购评估,高度依赖个人经验和零散查询,像在雷区里凭感觉走路。

采购员小王的日常:收到一份新供应商资料,打开数个网页,手动查询工商信息、法律诉讼、失信记录……这个过程,耗时、不全面,且充满人工主观误差。

红圈AI的“采购助理Agent”,目标就是成为小王的“外挂大脑”。

它的工作流程极具冲击力:整合多维度供应商企业数据并通过AI算法智能动态评分,3秒完成信用数据抓取,40秒AI完成各风险排查及评估,10秒生成完整报告。报告不仅给出“企业得分:44,风险等级:高风险,合作建议:建议终止合作或高度谨慎合作”的结论,还会用精炼的语言列出致命伤:“企业存在破产案件记录;被法院列为限制高消费企业;存在多起终本案件;因未按规定提交年度报告信息而被列入经营异常名录……”。这等于将风控专家经验与多维数据挖掘能力,压缩成了一个自动化流程。

明建云在采购环节能做什么?

它能很好地构建一个 规范化、可追溯的采购流程管理体系。作为专业的工程项目管理系统,其功能模块涵盖招采管理,能够确保采购动作的合规与高效,解决了“怎么买”的流程问题。

而红圈AI解决的,是更前端的 “向谁买”的本质安全问题。一个守护 “流程的合规”,一个狙击 “源头的风险”。对于采购员而言,明建云让他的工作更规范;而红圈AI则在努力让他避免职业生涯的“惊天大雷”,快速筛选优质供应商、实时监测潜在风险。当软件开始为你规避系统性风险时,它守护的不仅是公司资产,更是每个相关岗位从业者的职业安全。

项目部的“表哥表姐”,你们被Excel绑架多久了?

去过工地的人都知道,项目部的桌子上堆满了各种单据:手写的混凝土签收单、机打的送货单、手写确认单甚至外文单据……项目材料员、成本专员的大量时间,就消耗在将这些信息逐字敲进系统,比如手动处理合同文本、结算单信息或出入库单。

这个工作枯燥、易错、价值感低,却至关重要。传统软件的解决方案,是设计更友好的录入界面,但这依然没有改变 “人服务于系统” 的本质。

红圈AI的 “录单助手 Agent pro” (或称“AI录单助手”)提出了一个想法:为什么不能是系统主动理解并服务于人? 它通过大模型自动识别各类单据,实现从图像识别到高质量系统录入的秒级闭环,减少90%人工操作。无论是合同、结算单还是出入库单,系统能智能提取关键字段、智能匹配相关数据(如合同明细)并回填业务系统。更关键的是,它能智能分析入库材料匹配的合同明细并挂接,厘清成本发生源头,实现后期实际成本精准统计及溯源。项目人员从“数据搬运工”,变成了“流程确认官”。

明建云在单据处理上自然不会缺席。

它通常提供完善的单据管理模块,支持创建、审批、关联、归档全流程。手机端拍照上传附件、在线填写表单已是标配,这已经比传统纸质流转先进了无数倍,实现了单据的 “线上化与协同化”。

但两者的哲学在此有所区别:明建云在优化“录入的流程”,而红圈AI在挑战“录入”这个动作本身的存在必要性。 一个提供了更先进的“笔和纸”,另一个则试图给你一支“自动书写笔”。对于常年被重复劳动折磨的一线项目人员来说,谁能真正解放他们的双手和精力,让他们去做更有价值的现场协调与管理,谁的吸引力无疑是指数级上升的。

老师傅退休,经验就带走?你的公司需要一个“永生大脑”

工程企业的核心资产,除了设备和资质,就是那些藏在老师傅脑子里、散落在历年项目硬盘中的经验:某个特殊工艺工法、一份成功的投标策略、一次诉讼的关键判例、公司的差旅报销制度……

但这些知识,大多处于“沉默”状态。新员工问不到;投标时想找历史方案,得在共享盘里大海捞针;法务遇到纠纷,手动检索相关判例效率极低。

红圈AI的 “AI企业知识库” ,想成为企业的 “知识中枢”。它不仅仅是一个云盘,而是一个能用自然语言对话的“智慧专家”。通过大模型与智能检索技术,它将分散知识转化为即问即答的能力。

员工可以像聊天一样提问:“去哈尔滨住410块的酒店可以么?”“我的年假有多少天?”系统能在3秒内获取精准答案。它甚至能为商务部快速检索并整合历史投标成果,涵盖中标/未中标标书、技术方案等;为法务部构建专属的“诉讼智库”,涵盖判决书、律师函等所有相关资料。这大幅降低了新人培养周期,让企业核心经验传承提升3倍。

明建云如何管理知识?

作为项目核心平台,它自然是 项目资料归档和共享的最佳场所。所有与项目相关的文档都能存储在对应项目下,权限清晰,查找方便。它建立了一个有序的、项目维度的 “知识档案馆”。

红圈AI企业知识库所做的,是在档案馆之上,加装了一个 “超级智能检索员”和“金牌解说员”。前者解决了知识“存而不易找”的问题,后者解决了“找到而不易读懂用活”的问题。当新员工能随时向AI询问公司制度并得到精准解读,当项目经理能瞬间获得历史上类似风险的全部处理方案时,软件解决的就不再是信息存储问题,而是组织智慧的传承与激活问题,是团队整体学习曲线和应变能力的飙升。

你的选择,暴露了你的管理优先级

行文至此,我们可以清晰地画出一条分界线:

明建云,像一位严谨的“流程架构师”。它致力于为工程企业搭建一个标准化、可视化、强协同的数字管理基座。它把混乱的线下流程变得有序在线,让数据得以归集,让协作得以穿透部门墙。如果你的企业正处于数字化转型的初级阶段,迫切需要把管理规范立起来、把数据黑洞照亮,那么明建云代表的是一条稳健、成熟、已被验证的路径。

红圈(红圈工程项目管理系统 + AI系列智能产品),则像一位“角色赋能大师”。它在坚实的项目业务管理基础上,涵盖项目资金管理、成本管理、物资管理、劳务管理等功能,将一系列AI能力精准注入管理者、采购员、项目人员、新员工等关键角色的高频痛点场景中。它不满足于只管理好“事”,更执着于提升每个核心岗位上的“人”的决策质量、风险免疫、工作效率与知识获取速度。其AI系列智能产品,如BOSS助理Agent、采购助理Agent、录单助手Agent pro、项目360°AI解读、AI报表助手、AI企业知识库以及AI业务助手等,共同构成了一个更懂工程企业经营的赋能体系。

所以,回到那个终极拷问:红圈和明建云哪个好?

答案不在于软件本身,而在于你更想优先解决哪个层面的问题。

如果你认为当前最大的瓶颈是流程的规范化与标准化,那么请关注谁能把“事”理得更顺。

但如果你觉得,流程已经初步在线,而更深层的焦虑在于:高管如何从繁杂数据中快速洞察?业务如何防范未知风险?一线员工如何从重复劳动中解放?组织经验如何不随人员流失而消散?——那么,红圈所展现出的“以AI深度赋能具体角色”的思路,无疑指向了一个更锐利、更面向未来的答案。

最终,最好的软件,是那个能让你公司里最重要的那些“人”,工作得更强大、更安心、更有价值的那一个。这场选择,实则是对你管理哲学和公司下一阶段重心的一次隐秘洞察。

——覆盖芯片制造、封装测试、智能仓储与供应链协同的一体化智造平-台

在半导体国产化加速与高端电子制造升级的双重驱动下，电子制造企业（涵盖晶圆厂Fab与封测厂OSAT）正面临前所未有的挑战：工艺复杂度指数级上升、客户追溯要求严苛至单颗芯片、物料成本占比超60%、设备停机1分钟损失数万元。传统ERP+WMS+通用MES的割裂架构已难以为继。

万界星空电子制造行业专属MES系统——深度融合芯片制造（前道）、电子封装测试（后道）、智能仓储与供应链执行的全栈式解决方案，真正实现从“硅片进厂”到“芯片出货”的端到端闭环管控。

一、行业痛点：为何通用系统失效？
芯片制造（Fab） 工艺步骤超千道，Lot路径动态分裂；设备Recipe毫秒级同步；缺陷根因分析依赖跨工序数据

电子封装（OSAT） 多芯片异构集成（SiP/Chiplet）；金线/塑封料温湿度敏感；汽车电子需满足AEC-Q100追溯

供应链与仓储 关键物料（光刻胶、金线）保质期短；洁净室库位管理复杂；投料错配=整批报废

共性需求 全链路追溯（Wafer→Die→Package→终端产品）、EHS合规、OEE提升、零缺陷交付

普通MES仅关注“报工”，而电子制造需要的是以物料流、信息流、控制流三流合一的智能执行中枢。

二、系统整体架构：前道+后道+仓储一体化

见图

三、电子行业MES核心功能体系

✅ 1. 芯片制造（Fab）全流程管控

• Lot/Wafer级追踪：支持Split/Merge操作，记录每片晶圆上千道工序历史；
• Recipe与设备闭环：下发工艺配-方至设备，实时监控腔室参数，异常自动Hold Lot；
• 缺陷智能分析：集成AOI/E-beam数据，自动关联工艺步骤与设备，生成Yield根因报告；
• 洁净室EHS监控：粒子数、压差、特气泄漏实时告警，保障Fab安全运行。

✅ 2. 电子封装测试（OSAT）高精度执行

• 先进封装支持：管理Fan-Out、2.5D/3D、SiP等工艺，绑定RDL、TSV、Microbump数据；
• 全流程防错：贴片扫码校验Die与基板匹配，回流焊曲线自动比对，X-ray未检禁止流转；
• 测试数据闭环：ATE（CP/FT）结果自动归集，不良品关联失效模式，驱动FA分析；
• 汽车电子合规：一键生成PPAP文件包，满足IATF 16949与AEC-Q100要求。

✅ 3. 采购与供应商协同（MES驱动）

• 智能物料需求：基于MPS与BOM，自动计算光刻胶、金线、靶材等关键物料净需求；
• 供应商门户：共享交付计划、质量标准、包装规范，支持ASN电子化；
• 来料质量预控：COA（分析证书）预加载，IQC结果自动比对，超标物料冻结。

✅ 4. 智能投料与物料防错

• Fab投料校验：启动Lot前，校验光刻胶有效期、靶材使用次数、特气余量；
• OSAT投料拦截：Die Bin码、基板烘烤状态、湿度卡不合格 → 设备联锁停机；
• FIFO与效期管控：化学品按开封时间强制先进先出，超期自动锁定。

✅ 5. 精细化出入库与仓储管理

• 智能库位分配：

  • 恒温区（光刻胶）、氮气柜（金线）、防静电架（FOUP）自动匹配；
• AMHS/AGV协同：MES下发配送任务，自动送物料至机台口；
• 库存实时可视：展示在库量、库龄、洁净室水位，预警呆滞与缺料风险；
• 退料与危废管理：不良品隔离、废酸废溶剂登记，满足EHS审计。

✅ 6. 全链路追溯与合规

• 正向追踪：某片晶圆 → 切割Die → 封装成品 → 终端手机型号；
• 反向溯源：客户投诉 → 精准定位至光刻层、刻蚀机台、贴片时间、测试Bin；
• 电子批记录（EBR）：自动生成不可篡改档案，支持FDA 21 CFR Part 11、ISO 9001。

✅ 7. 设备物联与智能排产

• 千台设备接入：通过SECS/GEM、OPC UA对接中微、北方华创、ASM等设备；
• OEE自动分析：精准统计时间开动率、性能率、良品率；
• 柔性排程：Fab按腔室可用性调度，OSAT考虑模具准备与交期，支持插单模拟。

四、实施价值
产品良率（Yield） ↑ 2–5%（缺陷根因快速定位）

设备综合效率（OEE） ↑ 10–15%（减少非计划停机）

物料错用事故 ↓ 90%（投料防错拦截）

库存周转率 ↑ 20%（智能FIFO+呆滞预警）

追溯响应速度 从“天级” → “分钟级”

客户飞检通过率 100%（电子批记录完整合规）

**在“中国芯”崛起的时代，
制造的竞争力不再仅靠设备，而在于数据驱动的协同力、过程受控的稳定性与快速响应的柔性力。**
电子行业MES——不止于执行，更赋能中国电子制造迈向自主、高效、可靠的新纪元。

📞 立即预约，获取《电子制造行业数字化转型MES解决方案》+ 行业免费Demo演示！

近日，在中国信通院组织开展的 2026 上半年批次“可信数据库”测试中，涛思数据 TDengine IDMP 成为截至目前唯一一家全项完成“基于 AI 大模型的时序数据管理平台”基础能力检验的产品。

经中国信通院测试验证，TDengine IDMP 符合《基于 AI 大模型的时序数据管理平台技术要求》标准的全部能力要求，覆盖 AI 时序数据应用、时序数据建模与组织、情景化与标准化、实时分析、事件管理、安全与扩展性等关键能力方向。这也标志着 TDengine IDMP 在 AI 大模型与时序数据深度融合的工业数据平台领域，已达到国内技术先进水平。

《基于 AI 大模型的时序数据管理平台技术要求》标准简介

为规范基于AI大模型的时序数据管理平台技术和能力，指导提升AI大模型在时序数据领域的管理、建设应用，促进相关技术创新发展，完善行业协同生态，中国信通院依托CCSA TC601开展《基于AI大模型的时序数据管理平台技术要求》标准编制工作，围绕AI时序数据应用、时序模型管理、时序数据建模和组织、时序数据情景化、时序数据标准化、时序数据预处理、时序数据可视化、时序数据实时分析、事件管理、时序数据服务、平台管理、兼容性和扩展性、安全性等维度进行规范，为相关产品的应用落地提供了可供参考的技术规范。

TDengine IDMP：AI 原生工业数据管理平台的四大核心优势

作为时序数据库领域的长期实践者，涛思数据的 TDengine TSDB 已在工业、物联网等场景中广泛应用，覆盖智能制造、能源、电网、石油石化、汽车、矿山、新能源、制药、IT 基础设施等众多行业。

随着 AI 技术与工业互联网、物联网的深度融合，企业对数据平台的要求正在从“能存、能查”，升级为“能理解、能推理、能主动给出决策线索”。

在这一背景下，涛思数据于 2025 年 7 月正式发布 TDengine IDMP（AI 原生的工业数据管理平台），与 TDengine TSDB 协同演进，从底层架构重构工业数据平台能力，打通数据采集、汇聚、存储、分析、实时计算、可视化、事件管理与智能洞察的全链路，帮助企业以极高的性能、极低的成本和极简的体验，全面释放数据价值。

TDengine IDMP 具备以下四大核心优势：

• 无问智推，数据自己说话：无需主动提问，基于采集的数据，TDengine IDMP 能够利用 LLM，自动感知应用场景，自动生成场景特有的的指标、可视化面板、报表和实时数据分析。无需业务知识的多年积累，无需主动查询，核心洞察主动推送。
• 智能问数，实时分析零等待：除 AI 主动推送的面板、分析之外，用户还可以用自然语言主动提问与数据相关的任何问题。无需数据分析师、IT 工程师的帮助，AI 基于采集的数据实时给予答案，即可形成行动方案。从提问到决策，分钟级闭环。
• 工业数据全栈解决方案：与 TDengine 时序数据库一起，为工业数据管理提供从数据采集、清洗、情景化、标准化，到存储、查询、实时分析、预测、异常检测，再到可视化、事件管理等全栈的解决方案。架构极简，运维轻量化。
• 开放的企业级应用：支持单点登录、基于角色的权限控制、数据模型版本管理，提供数据备份、异地容灾与实时分发能力，支持虚机与容器化部署，兼容 Windows 与 Linux，可与 MES、ERP、AI 等企业应用系统无缝集成。

唯一完测，赋能百业，智驱未来

作为截至目前唯一一家全项通过中国信通院基于 AI 大模型的时序数据管理平台基础能力检验的产品，TDengine IDMP 在推出不足半年内，已在能源、化工、智能制造、交通、食品等多个行业实现落地应用，客户覆盖海内外市场。

此次全项完测，不仅是对 TDengine IDMP 技术体系完整性与成熟度的权威验证，也体现了涛思数据在 AI 与时序数据融合方向上的长期投入与工程实践能力，标志着 TDengine IDMP 在这一领域的成熟度已达到国内领先水平。

面向未来，涛思数据将持续提升平台的开放性、实时性与智能化水平，推动 AI 真正参与工业数据消费与决策过程，为企业数字化与智能化转型提供更加可靠、可持续的技术底座。

一、数据中心巡检之“困”

数据中心与智算中心作为数字基础设施的核心，其稳定运行依赖高频次、高精度的日常巡检。在以人力为主的运维模式下，巡检工作正面临系统性瓶颈。

当前的巡检模式，已逐渐无法满足现代数据中心日益提升的巡检需求。AI时代下，以智能巡检机器人为代表的自动化方案，正逐步成为行业的新选择。

二、从轨道到全地形：数据中心巡检机器人的演进之路

数据中心包含动力、暖通、机房等多个系统，空间结构天然存在梯坎、门槛、斜坡等复杂地形，对巡检载体的通过性提出持续挑战。

近年来，四足等全地形机器人在其他领域被广泛应用，但在数据中心狭窄通道、防静电地板等环境中面临实用性障碍，尚未有效落地。

真正适合数据中心的巡检载体，必须在通过性、效率与可靠性之间取得平衡——这为轮足机器人的出现提供了明确方向。

三、轮足机器人：数据中心巡检中通过性、效率与可靠性的平衡之选

在智能巡检载体的形态探索中，轮足式机器人，逐渐被视为数据中心场景的一种理性选择。它融合轮式底盘的高效、低噪与长续航优势，同时具备跨越台阶、斜坡等非平整地形的能力。

稳定上楼梯

轻松过门槛

相比纯轮式机器人受限于地面条件，履带或四足方案又普遍存在噪音大、速度慢、维护复杂等问题。轮足构型在通过性、作业效率与长期运行可靠性之间实现了有效平衡，可在不改造建筑结构的前提下，适应多楼层、多房间的复杂布局，满足数据中心对稳定和连续作业的要求，真正推动巡检范围从单机房走向全站覆盖。

四、云智慧 Cloudwise X1：专为数据中心打造的轮足巡检机器人

云智慧Cloudwise X1 并非通用轮足平台的简单移植，而是云智慧针对数据中心多地形环境（楼梯、斜坡、窄道、门槛等）深度定制的轮足巡检机器人。

其轮足底盘具备20cm越障与30°爬坡能力，可自主上下电梯、穿越台阶与狭窄通道，轻松应对跨楼层复杂场景。

在运营超过5年的混合架构机房中，云智慧Cloudwise X1 轮足巡检机器人无需改造地面或加装导轨，即可实现全站无死角覆盖，巡检范围从单一机房扩展至动力、暖通、IT机房及消防等多个区域。

在移动能力之外，云智慧Cloudwise X1  轮足巡检机器人的作业体系全面面向数据中心需求构建：

* 7×24小时自主作业

依托边缘计算单元与激光雷达SLAM系统，云智慧Cloudwise X1  轮足巡检机器人能在高噪音、弱光环境中实时建图、动态避障，定位精度达毫米级，夜间巡检全自动执行，运维人员无需值夜班。

• 多模态AI感知融合

可见光、红外热成像、声纹与气体传感器数据，智慧Cloudwise X1  轮足巡检机器人 内置17项自研AI算法，支持110+巡检项。例如，在配电柜区域，可通过温差分析提前预警“虚接”隐患，早期故障发现率提升50%。

• 端云协同

所有巡检数据由端侧自主采集，自动附加时间戳与空间坐标，加密上传至一体化运维平台。面对审计时，可一键调取任意设备的历史完整证据链，告别纸质打勾表的主观争议。

基于全地形覆盖能力与多模态智能感知，云智慧Cloudwise X1 轮足巡检机器人的工程潜力，转化为一套面向数据中心、可落地且可验证的智能巡检方案。

五、跨楼层全自动巡检，重塑数据中心运维范式

轮足机器人的价值，不在于形态本身，在于它能否真正解决数据中心的巡检难题。云智慧Cloudwise X1 轮足巡检机器人的实践表明：只有深度理解数据中心场景，并将通过性与多模态感知能力有效结合，智能巡检才能逐步从概念走向实际应用。

云智慧Cloudwise X1 轮足巡检机器人已在大型数据中心完成部署验证，稳定支撑跨楼层、多系统的常态化巡检任务。

未来，云智慧持续致力于为数据中心提供可靠性保障服务，AI赋能提升产品创新力，为金融、政企及云服务商等行业提供更安全、高效、可落地的智能巡检解决方案。

同时，作为专注于AI 基础设施智能运维的服务商，云智慧助力客户构建智能电力、AI算力与服务、AI 智能体的全栈安全和可靠性保障体系。

致力于保障AI基础设施规模化、连续性、稳定运行，通过监测、预警、快速响应、自动化运维与合规治理，帮助客户实现更高可用性、更低风险与更优运营成本。

详询热线：400-666-1332

[大模型实战 04] 从玩具到生产：基于 ChromaDB 打造工程级 RAG 系统

核心摘要 (TL;DR)

• 痛点：大模型不知道最新的新闻，也不知道企业的私有文档（如员工手册）。
• 方案：RAG (检索增强生成)。就像“开卷考试”，先去翻书找答案，再回答问题。
• 工具链：LlamaIndex (框架) + BGE (嵌入模型) + ChromaDB (向量数据库) + Qwen2.5 (推理模型)。
• 实战：在 Kaggle 上从零搭建一个能回答“企业内部机密”的 AI 助手。

前言

各位友人们，大家好，这里是阿尔。在上一节中，我们大概知道了大模型的构成，safetensor格式的大模型的文件组成，transformers库的基本使用。我们已经能够使用大模型去做一些简单对话应用了，它可以是上知天文，下知地理，中间还能知道人情冷暖。但是，我们需要加一个限定词，在训练数据截止日期前的。因为训练一次需要耗费很多的计算资源，时间和人力，当我们想让它知道一些新知识的时候，比如让它知道现在美国的总统是拜登还是特朗普，我们可以在对话中告诉他，这没问题，但是如果我们想让它知道更多，比如我的私人日记?比如我刚写的那篇博客？比如公司的员工手册, 比如自己产品的使用说明书？

这类私有数据，是大模型企业应用的痛点，毕竟大模型是基于在互联网上公开数据训练的。重新把这部分资料加进去，再训练一下模型？也不是不行，但是有点没有性价比，这时候就引出了大模型落地应用的核心技术-> RAG (Retrieval-Augmented Generation，检索增强生成)。

1. RAG（检索增强生成）

1.1 什么是RAG?

考试的时候，如果考到不会的知识，不知道各位友人们会不会头疼，如果这时候，允许我们翻书，现去书里找，我们也很有可能找得到对应的答案，哪怕我们可能完全没学过。这就是RAG的大致思路：不让模型凭空回忆，而是先给它找资料。

RAG，检索增强生成,字面上讲，就是 拿到考题->然后去翻书，通过目录之类的索引，快速翻到（检索）相关的内容->再根据这些内容（增强了的内容），回答出问题（生成回答）。

对比简单地把东西一股脑全部跟大模型说一遍，我们能清楚得发现，我们只用了检索到的那一部分内容，并没有让整本书大模型的脑子将占用, 这就是RAG的效率体现。

1.2 RAG的步骤

RAG技术的思路很简单，但是实现并非只是一个单一的技术能实现的，它有一套流水线（流水线）。 把这头"大象"放进冰箱，总共需要两步：准备好数据和让模型拿到数据。

第一个阶段：数据准备(Indexing) -> 把书装进书包

在大模型能够翻书之前，咱们得先把我们想给它看的书整理好，放进书包里。

1. 加载 (Load)：咱们的资料可能是各种各样的格式，一般大模型是不认识这么些格式的，所以我们就需要把 PDF、Word、网页等各种格式的文件读进来，统一提取出纯文本。
2. 切分 (Chunking)：大模型一次吃不下整本书,就和我们一眼看不完整本《三国演义》一样，它有上下文长度限制。我们需要把长文本切成一个个小的片段 (Chunks)，比如每 500 个字切一段。

3. 向量化 (Embedding)：这是最关键的一步！

   • 计算机无法直接比较“苹果”和“iphone”是不是相关的。
   • 我们需要用一个专门的模型（Embedding Model），把每一段文字变成一串数字向量（比如 [0.1, -0.5, 0.8, ...]）,是不是有点耳熟，对这和大模型训练的Embedding是一个思路，但是我们一般会使用特制的嵌入模型来做这个专业的事情。
   • 在这个数学空间里，语义相近的词，距离就越近, 这样我们就能知道，这本书中的所有向量，哪些是和我们的问题相关的了。
4. 存储 (Storage)：把这些向量和对应的文字，存入向量数据库 (Vector DB) 中。
   

第二个阶段：应用数据给大模型生成（Retrieval & Generation）-> 开卷答题

拿到书了之后，我们想要翻书，就得找到和问题有关系的内容，然后再将这些内容和我们自己的常识结合起来，对提出的问题进行答题。

1. 问题向量化(Embedding)：要想知道用户的提问（例如“火星基地吃什么？”）和内容的相关性，我们就需要像对准备的数据一样，用同一个 Embedding 模型将问题变成向量。

2. 检索 (Retrieval)：拿着这个“问题向量”，去向量数据库里搜, 去找到关系性高的内容。

   • 系统会计算：“哪个文档片段的向量，和问题向量的距离最近？”
   • 找出最相似的前 3-5 个片段 (Top-k)。

3. 增强 (Augmentation)：把这 3-5 个片段拼在一起，和用户的问题组合成一个超级长的 Prompt。

   • Prompt 模板示例：

     你是一个助手。请根据以下参考资料回答问题。
     参考资料：[片段1]... [片段2]...
     用户问题：火星基地吃什么？

4. 生成 (Generation)：把这个 Prompt 喂给大模型（LLM）。大模型阅读资料，总结并生成最终答案。
   

2. RAG技术选型

好了，理论我们已经懂了，现在我们撸起袖子，准备来实操一下子吧。我们打算从零开始快速搭建一个工程级的RAG系统: 私有API助手, 在我直接告诉各位友人们我们要用到的工具前，我觉得也有必要大概让各位友人们知道还有哪些别的选择，我们为什么选择了这几个。

2.1 框架: LlamaIndex vs. LangChain

• LangChain：万能胶水，适合做复杂的 Agent（智能体），但写 RAG 代码比较啰嗦，抽象层级太碎，我们后面写智能体的时候（如果有精力做智能体的教程的话）再来使用它。
• LlamaIndex：数据专家。专门为 RAG 也就是“索引和检索”而生。接口极度简洁，且对数据清洗（Ingestion）的处理更专业。
• 结论：我们做RAG，直接先上LlamaIndex, 快速地实现效果。
  

2.2 嵌入模型 (Embedding)：BGE vs. OpenAI

• OpenAI (text-embedding-3)：效果好，但要钱，且数据要传给 OpenAI（隐私风险）。
• BAAI/bge-small-zh-v1.5：国货之光。中文效果霸榜，体积极小（几百 MB），完全可以在 Kaggle 本地跑。
• 结论：为了免费和隐私，首选 BGE-Small。
• PS: 如果是英文资料的话，建议换成 BAAI/bge-small-en-v1.5 或者 OpenAI 的 text-embedding-3-small
  

2.3 向量数据库：Chroma vs. Milvus vs. Pinecone

• Pinecone：纯云端 SaaS，不可本地部署，对 Kaggle 不友好。
• Milvus：性能强悍，适合十亿级数据，需要 Docker 部署，适合数据量大的时候使用，但是对于咱们的这个项目来说，太重了。
• ChromaDB：轻量级王者。可以像 SQLite 一样以“本地文件”形式存在，也可以部署成服务器。
• 结论：中小型项目，首选 ChromaDB。
  

3. 上手实操

项目背景：假设我们是一家名叫 "DeepStar" 的初创公司，我们有一套内部绝密的 API 文档，新来的实习生总是问重复的问题。我们要用 RAG 让他自己查。

3.1 环境配置 (Kaggle)

启动 Kaggle Notebook，确保 Internet: On，Accelerator: GPU T4 x2。

# 1. 更新transformers及其相关库
!pip install -U transformers peft accelerate bitsandbytes sentence-transformers

# 2. 安装 LlamaIndex 核心及相关插件
!pip install llama-index-core llama-index-llms-huggingface llama-index-embeddings-huggingface

# 3. 安装 ChromaDB 向量库支持
!pip install llama-index-vector-stores-chroma chromadb

下载依赖库可能会需要一点时间，之后我看看能不能在kaggle上用uv去做包管理。

3.2 造数据：模拟企业内部文档

我们创建两份文档：一份是核心接口定义，一份是错误码说明。

import os

data_path = "/kaggle/working/data"
# 创建数据目录
os.makedirs(data_path, exist_ok=True)

# 文档 1: 核心 API 定义
api_doc = """
[机密] DeepStar 核心交易接口 v2.0
1. 创建订单 API: POST /api/v2/order/create
   - 必填参数: 'user_id' (String), 'amount' (Decimal), 'token' (X-Auth-Token)
   - 特殊逻辑: 如果 amount > 10000, 必须额外传递 'audit_code' (审计码)。
   - 频率限制: 单用户每秒最多 5 次调用。
2. 查询余额 API: GET /api/v2/balance
   - 缓存策略: 默认缓存 5 秒。传递 'no-cache=true' 可强制刷新。
"""

# 文档 2: 错误码字典
error_doc = """
[机密] DeepStar 全局错误码字典
- E1001: 签名验证失败。请检查 X-Auth-Token 是否过期。
- E2009: 余额不足。注意：冻结金额不计入可用余额。
- E5003: 审计风控拦截。大额交易未通过自动审计，请联系人工客服。
"""

with open(f"{/data_path}/api_specs.txt", "w") as f:
    f.write(api_doc)
with open(f"/{data_path}/error_codes.txt", "w") as f:
    f.write(error_doc)

print("[Success] 企业文档库已就绪！")

3.3 初始化大脑与眼睛 (Settings)

提前根据自己的情况来配置待会儿用的词嵌入模型和推理模型。

embedding_model ="BAAI/bge-small-zh-v1.5"
llm = "Qwen/Qwen2.5-7B-Instruct"
# 在本地服务器，可以用modelscope下载下来, 把路径配置在这儿

利用 Settings 全局配置，将默认的 OpenAI 替换为本地模型。

import torch
from llama_index.core import Settings
from llama_index.llms.huggingface import HuggingFaceLLM
from llama_index.embeddings.huggingface import HuggingFaceEmbedding

# 1. 设置 Embedding (眼睛)
# 使用 BGE-Small，显存占用极低，检索中文效果极佳
print("正在加载 Embedding 模型...")

Settings.embed_model = HuggingFaceEmbedding(
    model_name=embedding_model
)

# 2. 设置 LLM (大脑)
# 使用 Qwen2.5-7B-Instruct
print("正在加载 LLM 模型...")
Settings.llm = HuggingFaceLLM(
    model_name=llm,
    tokenizer_name=llm,
    context_window=30000,
    max_new_tokens=512,
    generate_kwargs={"temperature": 0.1, "do_sample": True}, # 技术文档要求严谨，温度调低
    device_map="auto",
    model_kwargs={"dtype": torch.float16, "trust_remote_code": True}
)
print("[Success] 模型加载完毕！")

3.4 核心组件：ChromaDB 持久化流水线

这是本篇最关键的代码。我们要实现：如果本地已经有数据库，就直接读；如果没有，才去解析文档。

import chromadb
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext
from llama_index.vector_stores.chroma import ChromaVectorStore

# 定义持久化路径
CHROMA_DB_PATH = "/kaggle/working/chroma_db"
COLLECTION_NAME = "deepstar_docs"

# 1. 初始化 Chroma 客户端 (PersistentClient 实现了写硬盘功能)
db_client = chromadb.PersistentClient(path=CHROMA_DB_PATH)

# 2. 创建或获取集合 (Collection)
chroma_collection = db_client.get_or_create_collection(COLLECTION_NAME)

# 3. 将 Chroma 对接给 LlamaIndex
vector_store = ChromaVectorStore(chroma_collection=chroma_collection)
storage_context = StorageContext.from_defaults(vector_store=vector_store)

# 4. 智能加载逻辑 (幂等性设计)
if chroma_collection.count() == 0:
    print("[Info] 数据库为空，开始初始化...")
    # 读取 data 目录下的所有文件
    documents = SimpleDirectoryReader("./data").load_data()
    # 建立索引并自动存入 Chroma (Ingestion)
    index = VectorStoreIndex.from_documents(
        documents, storage_context=storage_context
    )
    print("[Success] 数据写入完成！")
else:
    print(f"[Info] 发现 {chroma_collection.count()} 条存量数据，直接加载...")
    # 直接从 Vector Store 加载，无需重新计算 Embedding
    index = VectorStoreIndex.from_vector_store(
        vector_store, storage_context=storage_context
    )
    print("[Success] 索引加载完成！")

3.5 验收测试：复杂逻辑问答

现在，我们模拟实习生提问。注意，这个问题需要结合两个文档（接口定义 + 错误码）以及逻辑推理才能回答。

# 创建查询引擎
query_engine = index.as_query_engine(similarity_top_k=3)

# 实习生的提问
questions = [
    "创建订单时，如果你只有 100 块钱，能传 amount=20000 吗？为什么？",
    "我收到了 E5003 错误，这是什么意思？该怎么办？"
]

print("======== 开始 RAG 问答测试 ========")

for q in questions:
    print(f"\n[Question] {q}")
    response = query_engine.query(q)
    print(f"[Answer]\n{str(response)}")

    # 打印引用源 (Debug 必备，看看它参考了哪个文件)
    source_file = response.source_nodes[0].metadata.get('file_name')
    print(f"[Source]: {source_file}")

答复如下

4. 进阶技巧：如何管理你的数据库？

既然用了 ChromaDB，我们就可以像查 SQL 一样查它。这在 Debug 时非常有用。

# 偷看数据库里的前 2 条记录
data = chroma_collection.peek(limit=2)

print("\n[Debug] 数据库抽查:")
for i, doc in enumerate(data['documents']):
    print(f"--- 片段 {i} ---")
    print(f"内容: {doc[:50]}...") # 只打印前50个字
    print(f"来源: {data['metadatas'][i]}")

5. 完整代码

完整代码可以点击kaggle笔记获取

5. 常见问题 (Q&A)

Q: 为什么不直接把所有文档都塞进 Prompt 里 (Long Context)？
A: 虽然现在很多模型支持长文本（比如 128k），但直接塞文档有三个问题：

1. 太贵：Token 是要钱的（如果用商业 API）。
2. 太慢：上下文越长，推理越慢。
3. 记不住：大模型有“长上下文迷失 (Lost in the Middle)”现象，塞太多反而会忽略中间的关键细节。RAG 相当于先做了一次筛选，只给模型看最有用的，效果反而更好。

Q: LlamaIndex 和 LangChain 我该学哪个？
A:

• 做 RAG/知识库：首选 LlamaIndex，它对数据索引、切分、向量化做了极其深度的优化，接口更简洁。
• 做 Agent/工具调用：首选 LangChain，它的生态和工具链更丰富。
• 结论：咱们这个项目专注于“找资料”，所以 LlamaIndex 是最佳选择。

Q: ChromaDB 的数据存在哪里了？
A: 在上面代码中，我们通过 PersistentClient 指定了路径 /kaggle/working/chroma_db。
它就像 SQLite 一样，数据就存在这个文件夹里的 .sqlite3 和 .bin 文件中。咱们可以把这个文件夹拷贝到任何电脑上，无需重新向量化就能直接使用。

本文作者： Algieba
本文链接： https://blog.algieba12.cn/llm04-rag-llamaindex-chromadb/
版权声明： 本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！

别卷 Prompt 了！它只是你 AI 员工的“开机键”

进入 2026 年，Skills 的爆火和 Clawdbot（OpenClaw）的横空出世，传递了一个清晰的信号：当 Agent 从酷炫的演示走向支撑业务的生产系统时，单纯依靠优化提示词（Prompt）的“艺术”，已无法满足企业对可靠性、执行力与持续进化能力的刚性需求。

这并不是说 Prompt 不再重要，而是它的角色发生了根本性转变。它从一个需要被无限雕琢、承载所有逻辑的“总指挥”，演变为一个触发器。它的新任务是：准确理解人类指令，然后高效地唤醒后方一套庞大且专业的能力系统。就像手机的开机键，按一下就可以打开各种应用功能的入口。

这个能力系统，正是现代 AI 工程的核心——一个为 Agent 打造的“可控思维”架构。

它由三个相互协作的引擎构成：

• 记忆引擎（Memory）：确保 Agent 有“记性”，能够记住用户偏好和交互历史。这意味着它能记住重要的对话历史和你的要求，做事有头有尾，不用你每次都从头交代。
• 知识引擎（RAG）：确保 Agent 有“实时的知识库”，能够从海量、动态的企业数据中精准检索信息，保证它给出的信息永远准确、最新，不会凭空乱造。
• 技能引擎（Skills）：确保 Agent 有“手脚”，能够将复杂的业务操作（如数据查询、报告生成、系统调用）封装为可被随时调用的标准化模块，从“能说”走向“会做”。

Prompt、Memory、RAG、Skills 共同构成了一个能独立干活、不出错、有记性的 AI 员工，当它要完成的任务越复杂、越关键，后三者的系统化工程价值就越发凸显，Prompt 也因此必须从舞台中央退下。作为使用者，我们不再只是和模型对话的“提问者”，而是为 Agent 设计和组装能力模块的“架构师”，思考重点也从“怎么问得好”，全面转向“怎么让 AI 干得好”。

理解这种从孤立提示到系统工程的范式迁移，是我们今天话题的起点。

下面，就让我们聆听来自 1 月 31 日 OceanBase 社区嘉年华的圆桌讨论，看顶尖的实践者们如何具体拆解这些核心组件的演进与融合。

从 Prompt 到 Skills，RAG 还行不行

主持人：张海立，LangChain Ambassador、OceanBase Ambassador，up主“沧海九粟”

对话嘉宾：

• 张颖峰，RAGFlow CEO
• 余金隆，FastGPT 负责人
• 古思为，Co-founder of Nowledge Labs
• 吉剑南，OceanBase AI 平台与应用负责人

议题一：2026 年 RAG 生态何去何从？

张海立：从去年末到今年年初，AI 领域热点频发。除了近期备受关注的 Clawdbot（OpenClaw），Skills 成为另一个重要话题。我在进行 Skills 相关实践时发现，许多 Skills 与本地文件系统紧密相关，但都离不开 RAG 体系对外部数据的召回，这对 Agent 发挥更大作用至关重要。LangChain 在构建 Agent 生态时，RAG 也是核心体验之一。想请教各位老师：在当前大环境下，您认为 2026 年 RAG 生态将如何发展？请结合各自产品进行简要介绍。

张颖峰：先说个笑话，2025 年被称为 Agent 元年，当时有朋友问我们要不要（从 RAGFlow）改名为 AgentFlow。而今年是 Agent 落地元年，我们内部也讨论要不要改名为 ContextFlow。实际上我们永远不会改名，因为我们认为“R”是核心点，单纯的 RAG 确实不足以服务 Agent，但“R”是服务 Agent 数据层的核心点。

当前 Agent 需要的是上下文（Context），它来自三方面数据：企业内部数据、工具数据以及对话过程中生成的数据。Skills 偏向工具层面，但比工具更高一层，还包含了规划（Plan）能力。Skills 本身也需要搜索——当企业内部有 1000 个 MCP 时，如何调用对应的 Tools 和 Skills 同样需要检索能力。因此 RAG 永远不会消失。

我们的布局是从 RAG 引擎向上层引擎演进。技术本身未变，但内涵发生变化：数据从简单的企业内部数据，扩展到 Agent 过程中的上下文数据。我们判断，未来所有 Agent 都是 Coding Agent，包括对工具的调用也将变成代码生成（Code Generation），需要 RTC（Run-Time Code）在沙箱中执行，访问各类 Tools 和 Skills，最终通过文件系统返回结果。这也是我们向上下文引擎方向演进的核心计划。

余金隆：我赞同颖峰老师关于 Code Generation 解决所有问题的观点，这也是我们团队的认知。无论是做 RAG 引擎还是 Workflow 引擎，都在向代码生成靠拢。

RAGFlow 不想改名，我们有点想改名字。因为近几年我们发现，做 Agent 本质是把数据使用起来，所以我们的平台主要解决数据连接层问题。过去数据分布在数据库、文档等各种结构中，现在通过大量连接器实现不同数据的连接。Skills 出现后，以前需要写代码和 Webhook 连接的数据层，现在可以通过 Skills 实现。这对国内交付场景特别有价值——国内系统数据格式不统一、缺乏标准，交付同学以前需要写大量适配代码，现在通过 Skills 将数据标准化连接到平台。

今年我们主要做两件事：一是完善连接层，二是优化 RAG 的 Retrieval 层。Retrieval 效果很大程度上取决于召回过程，不同场景的召回流程差异很大。过去需要通过 Workflow 形式搭建积木、进行意图识别分类、编写不同提示词适配不同场景，链路复杂。现在我们探索通过 Skills 这种偏语义化的方式生成代码，类似 Test-to-Code 的思路，但生成的是 SDK 代码来构建整个 Retrieval 流程，这是一个很有意思的探索方向。

古思为：关于 2026 年 RAG 相关变化，可以看到在 Coding Agent 中对代码的检索已从纯 Embedding 转向 AST（抽象语法树）、Agentic FS Graph 或 AST Graph 等方案。包括 PageIndex 项目，以及我们公司在 Haicon 2024 发布的实验性项目 OpenKL，尝试用类文件系统方法处理 Memory 和 RAG Docs。

另一个趋势是 RAGFlow 等通用内容引擎同时处理文档和 Memory。我们已发布的第一个产品是面向 C 端的 Memory 桌面 APP Knowledge MAM，动机是帮助用户在不同工具间无缝切换工作流。例如在 ChatGPT 完成 Deep Research 后，无需重新解释即可继续在 Cursor 中工作；或者当 Agent 帮助发帖子进入热榜后，可以切换到另一个 Agent 继续任务，同时保留所有交互历史和偏好设置。

吉剑南：OceanBase 面向 AI 的能力——seekdb、PowerRAG 与 PowerMem 均已开源。我们团队除了做向量数据库和 AI 应用基础设施外，也在探索面向数据库的 AI 应用，比如面向开发者工具的 Text-to-SQL 和数据库智能运维。

关于 2026 年趋势，我认可颖峰老师说的 RAG 不会消失，它和Skills、MCP处于不同维度。即使未来 Skills 和 MCP 越来越多，最终仍需通过 RAG 或某种方式召回，不能将所有 Skills 都喂给模型。

但我有不同观点：当前 RAG 仍集中在知识库领域，通过搭建 Chatbot 做问答，而问答更像玩具而非生产应用。真正的生产应用应将 RAG 融入日常工作，如销售根据集团材料为客户生成定制化 PPT或“一指禅”。未来 RAG 会结合应用反馈，反向影响数据如何切分、如何做更精细化的 Embedding，而非仅仅前置处理。

议题二：AI系统中的多路检索与数据源管理

张海立：感谢各位的分享，Skills 给我们带来了更多机会，能创建更多 Agent 和 RAG 应用。同时有一个概念非常重要：我们常说的 RAG 里的“R”，到底指什么？它指的是 Retrieval，是一个 “检索过程”。Retrieval 的 source可以是文件系统，可以是数据库，可以是 Web，甚至多种来源并存。

引申出第二个问题：随着 Skills 和 RAG 体系的发展，未来多路检索会越来越常见，RAG 不会消失，它将长期存在于 Agent 体系中。这样一来，数据源头的管理就变得更加重要。最简单的是把数据直接塞进软件系统，但更常见的情况可能是：越来越多的数据会落在数据库中。在这种情况下，当数据库的多路检索能力得到极大增强之后，做 RAG 应更多依赖数据库，还是在数据入库层面通过一些技巧将复杂的事情交给基础设施？

吉剑南：必然入库是最大影响，这也是 OceanBase 提出混合搜索（Hybrid Search）概念的核心。如果完全以非结构化数据或切片方式进入系统，召回效率顶天就是向量化的近似能力。去年所有 RAG 产品都在强调从非结构化数据中提取结构化数据，存为 JSON 等半结构化形式，用于前置过滤或与结构化数据一起做混合搜索。

为什么要这样做？本质上是语义理解包含两个层面：一是你问的是模糊问题，但脑子里想的是确定性答案；二是问题模糊，答案也模糊，希望召回所有相关点。大部分实践场景属于第一种。

在文档预处理时，结构化提取非常重要。例如从医疗文档或简历中提取结构化字段，召回时先对结构化数据做精确匹配，再对字段内的非结构化内容做向量检索。半结构化数据解决范围和准确性问题，向量检索解决语义理解问题。通过混合搜索模式，入库时做文档理解提取结构化数据，召回时统一检索，效率会大幅提升。数据库也应在接下来一年面向这个方向发展，我们看到 Chroma 等国外开源数据库已在往这个方向演进。

古思为：我们比较早做 Graph RAG，可能是第一个探索的团队。张老师分享的新架构与我们上一家公司做的 FusionGraph 很像。核心思想是：要让复杂 RAG 系统表现好，索引结构既要贴近知识本质，又要把特定场景的领域知识元信息投射到 Retrieve、Index、Transform 各环节做优化。

通用方法是知识后加工时做 Entity Graph 或 Semantic Graph，同时在做 IDP（Intelligent Document Processing）和 Parsing 时，对多层 folder 和复杂章节的长文档要识别 layout，涉及多模态时考虑是否转换模态。要做好这些并能演进，不要过度领域化 pipeline，而是按基本原理拆分，确保各组件能力跟上。

Database 是重要基础设施，比如 RAGFlow 的 Graph 和 Tree 结构能否原生保留、高效检索；要做 Dynamic Agents Retrieve，模型能否自然利用复杂多层结构。数据库的高性能、索引召回率和内置 Hybrid RRF 都很重要，决定系统下限。

余金隆：在交付过程中，数据源解析是基础且重要，但更重要的是召回（Retrieval）层。即使使用最简单的原始向量，只要检索词和检索语句构建得好，也能得到很好效果，只是效率较差。我们在此基础上扩展了语义化加标量方式。

但标量遇到较大问题：它不固定，用户自己也不知道需要什么标量。我们今年研究的方向是标量的动态扩展，包括用户自身扩展和模型自生成。例如给模型一些 Skills，或用户编写场景来生成场景下的标量存入数据库。当然这会引发多租户系统中成千上万标量的高效索引问题，以及渐进式生成问题——很难在预处理时生成所有标量，很多需要在检索时评估并渐进补全。在Retrieval阶段，多标量关联查询的生成方式也借鉴了 Text-to-SQL 的思路。我们希望找到通用存储方式覆盖 80% 场景，目前看语义化加标量检索加动态标量可以覆盖很多场景，所以我们没有用图，因为图是以复杂方式解决复杂问题，而 AI 时代可能有更简单的方式处理复杂问题。

张颖峰：我们现在是数据库使用者，但曾经也是数据库开发者。从纯技术角度，我非常喜欢“一边推理一边搜索”的技术方向，我称之为 Attention Engine，我认为它也是一种 RAG。DeepSeek 近期已大体实现类似方式，因显存限制不得不用内存，在推理时通过内存索引搜索内容，从外置记忆变为内置记忆。但从商业角度这条路行不通，要求检索与模型延迟极低，必须在同一交换机后，意味着只能卖一体机。因此我们仅作为调研方向。

从业务视角看，我们最早做 Infra 、做数据库时发现离业务太远，后来做 RAG 流量较大，促使我们重新思考 Data+AI 落地生态。我们的观点是：过去数据库是底座，上面写应用做增删改查；现在应用是 Agent，底座是以 RAG 为基础的组件，数据库在底层支撑 RAG 中间件。Data+AI 建设不能 AI 和 Data 各干各的，接口有时不清晰，因为中间层用 Python 实现，其好处是适应多变需求，召回策略可随时调整，不过 Python 带来的效率问题也让人头疼。AI 时代的数据底座让 Infra 人员直接触达业务，通道变短。因此中间层需要一个 Python 层适应业务多样化，一旦发现好的方式就迅速下沉到数据库解决效率问题。

我们在 2024 年底就鼓吹跨模态，但至今未落地，因为 Infra 到模型都未准备好。跨模态需要多向量搜索（Tensor Search），用多向量表示图片或文本，语义更准确、排序更准，但数据会膨胀两三个数量级，这是灾难。这需要模型、算法、Infra 共同解决挑战。因此我们需要端到端的、以 RAG 为中间层的体系，这其实就是 Agent 的数据库。

议题三：Memory 与 RAG 到底有何区别？

张海立：我非常认同颖峰老师提到的“端到端”。作为 LangChain 社区大使，我们主要做应用层框架，今年非常想做的一件事情是：和各个厂商比如 OceanBase seekdb一起提供真正的端到端解决方案，服务企业和个人用户，帮助他们快速构建生产级 Agent。

简单总结一下几位老师的理解：当我们面向用户提供检索能力时，会在中间层、应用层、数据库层进行多层协同优化，共性问题会逐步下沉到数据库解决。以我的个人体验为例：在最初布道时，我会给大家讲很多 RAG 的流程和算法，但从去年底开始，我更多会建议“你直接用这个数据库就好了”，因为它已经帮我们解决了很多多路检索的问题。这种 “沉淀” 是应用方和数据库厂商不断联合实践的结果。

下一个问题也与此有关：我们经常被问到Memory 和 RAG到底有什么区别？从 Memory 召回和从数据库召回有何区别？近期 Clawdbot（OpenClaw）从文件系统读取，到支持 PowerMem 直接接入进行更有效的内存管理。想请教剑南老师，这里做了什么特别工作？以及各位如何理解 Memory 与 RAG 的关系？

吉剑南：Memory 是为让大模型更像人而引入的。如果查询的都是客观事实且不存在人与人之间的理解，RAG 已能解决问题。但问题在于每个人对客观事实的理解和描述不同，加上人有记忆曲线，希望记住昨天强调的内容——这些内容虽非客观事实，但是主观认可。

例如每个人都有一个叫“老王”的朋友，随着时间推移这个“老王”可能已变化，但在记忆中一直叫“老王”，这时 RAG 搞不定，但 Memory 能搞定，因它会更新对“老王”的认知。“老王”是一个知识吗？并不是，因此，Memory 的核心是个性化和千人千面。

无论是 RAG 还是 Memory，整体是搭建一整套解决方案面向 Agent 为业务带来价值，不应区分该用 RAG 还是 Memory，而应思考如何组合好共同为业务赋能。

古思为：我们目前做 Memory，之前做 Graph RAG。Memory 有广义和狭义之分，狭义指 Agent 或 LLM 需要检索的更外部的 Memory，它确实是特殊的 RAG，特殊在几个方面：

• 原始数据是持续的 message thread。
• 知识需求是时序性的（temporal），包含两个时间维度：信息创建时间、事件/事实时间。
• 时序性存在一个问题，遗忘（forget）是 feature 而非 bug，需结合时间、访问频率和正反馈影响 Retrieval。
• 条目层面有 category 和不同类型，取决于 Memory 目的，可能需要schema 区分 ephemeral（瞬时）和 permanent（永久）。
• 不同结构间需要 transform 关系，可在 Retrieve 或写入过程触发 event，或周期性处理（类似大脑做梦处理记忆）。
• 多租户和 sessional scoping。

如果做细会发现与典型 RAG 差别很大，但二者又有很大 overlap。RAG Engine 可以处理 Memory，Memory Engine Service 项目也会处理文档，界限会变得模糊。

余金隆：我理解 Memory 算是广义 RAG 的一种，无非也是数据 I/O、Pipeline 处理、特殊数据结构，比较偏个性化。

从产品角度看，Memory 目前 C 端个性化场景用得较多。在任务流中，用户提 Memory 的还不多。在技术实践中，Mem0 有工具调用的 Memory 用于长 Agent 任务，但看其架构有点像 Context Engine，与 Memory 又不太一样。所以感觉 Memory 还是 RAG 的一种特殊 Pipeline 形式，没有太大区别，可能实时性比 RAG 更高。

张颖峰：单从技术角度而言，Memory 与 RAG 确实没有本质区别，都是 Retrieval。但重要的是 Memory 如何发挥作用，这是在快速变化的。

我在分享 Context Engine 时提到三类数据：企业内部数据、Tools 数据、Agent 使用过程中生成的数据。但它们存储在两个地方：RAG 专有区域和 Memory 专有区域。可见所有大模型生成的内容都要存到 Memory，包括 Skills 的元数据（Skills 本身数据存文件系统）。

怎么存、什么时候存、什么时候取，这些设计点很难决策。例如生成 Plan 是否存入 Memory？作为 Plan Cache 有价值，但如果 Human-in-the-loop 干预修改了 Plan，应如何存储？以后如何根据 Memory 数据抽取内部 MCP Tools 的 Skills？这些都是新问题。

从 Infra 角度，RAG 和 Memory 没区别；但从使用者角度，Memory 是重要的基础设施，解锁了大量场景。因此 Memory 项目很多（如 Mem0、MemU），但对 Memory 区域的定义（数据库该有哪些表）尚未完全一致，反映 Agent 到底需要什么样的 Memory 还在进化中。不过整个 Agent 体系需要哪些组件，已进入收敛期，就是 Context。

议题四：Skills 开发实践与推荐

张海立：各位老师都在做 Workflow、数据库或融合方案，是否开发了自己的 Skills 帮助用户更好地使用产品？如有请推荐，如无请设想会开发什么样的 Skills 服务开发者？

张颖峰：抱歉我目前没有特别好的推荐。我比较关注如何针对大量内部 MCP Tools 生成对应 Skills，这需要一个专门的 Agent 平台来实现。我的观点是：未来 Agent 平台可能没有统一标准，所有都是 Coding Agent，但特定 Agent（如低代码、无代码、Workflow）可能因良好交互而便于生成 Skills。

余金隆：我们内部 Skills 用得很多，运营和 SEO、GM 等场景一大把。产研团队用得不算多，主要是代码开发和 Review。交付团队用得特别多：面向用户时遇到各种问题，排查系统后沉淀为 Skills，辅助交付和运维。因此，内部有句玩笑话“交付同学比研发同学更懂系统”，他们做了二十多个 Skills，涵盖工作流搭建、问题排查、RAG 优化等。总体感觉 Skills 更像自然语言工作流，虽更抽象，但目前大部分还是偏自然语言的 Workflow。对非开发人员在生产流程上比较友好。

古思为：我们维护基于 Skills 的插件，在 Skills 发布第二天就推出了 Cloud Code 插件支持。早期没有 Skills 时，我们只能基于 MCP，让插件调用 MCP 的 Custom Command 触发操作，用 Hook 实现功能。

后来发现 MCP 规范了工具调用，但有两个地方不如 Skills：

1.MCP 有 Prompt 抽象，实现为斜杠命令可主动调用类似 Workflow 的东西，但并非所有 Client 都实现，我们要做很多额外工作。Skills 天然支持主动说和自动做。

2.Skills 的打包方式让不同工具间组合更灵活。我们内部将 Skills 从 MCP 换成 CLI 后变化很大。例如让 Agent 做 Memory 复杂更新查询时，MCP 需要多轮次，即使 interleave 也不够好。但 CLI 可以动态组合 Linux Shell Pipeline，在一个 turn 里精确完成复杂操作，且内部 CLI/Script 可以 self-contain，打包给用户后自然享受复杂能力。

调试经验方面，Skills 比较通用，容易用不同平台测试。我们发现一个有意思的案例：Skills 对应的工具有很多具体选择，如何调优模糊的问题？我们的做法是用最聪明的 Agent 做 honest 的复杂 long run 评估，像跟客户聊天一样告诉我们如何改进。有时需要更端到端看细节，不得不自己server model，在 template 解析过程中用小模型发现工具复杂类型定义的问题，虽然其他模型能克服，但会影响 performance。

吉剑南：OceanBase 内部沉淀了很多 Skills。Skills 本质是最佳实践，告诉大模型最佳实践是什么，而最佳实践无非两类：一是提升工作效率的工程类（如 Cursor 的 rules），二是业务类 Skills。

Skills 也可以用在 RAG 上，RAG 效率和准确性今天跟两个因素相关：相似度和 Top K。但大家有没有想过，召回前 Top K 和相似度有时不能完全指定，需要反复调，知识库又在更新。如果针对不同的业务实现写不同的 Skills，例如当需要某类数据时，希望相似度设到什么位置、Top K 设到什么位置，根据召回结果动态调整，这就变成了一个 Skills。这是 RAG 搞不定的，需要根据具体召回内容判断，是 RAG 的最佳实践。

之前大家可能想是否把 RAG 数据放 Skills 里就不用召回了，而我觉得 Skills 是对 RAG 的增强。关于 OceanBase 的 Skills，我们是有准备的，包括 seekdb 的研发人员今天也在现场，未来应该会有更多相关的 Skills 开放出来。

张海立：非常感谢各位老师精彩分享。简单总结：RAG 还“行”！只要理解 RAG 的 R 是 Retrieval，有 Memory、传统数据库等多种数据来源，随着各位老师所在厂商的努力，多路检索能力、应用层提升、流程算法优化都在推进。相信 2026 年RAG会有更大发展。

Agent 可控思维的工程实现：从分散工具到一体化基座

本次圆桌讨论，为我们清晰地勾勒出 2026 年 AI 工程化的演进路径。专家们的共识指向一个明确的结论：构建可靠、可用的 Agent ，其核心不再是追求某个单一组件的极致，而在于如何系统性地整合记忆（Memory）、检索（RAG）与技能（Skills），形成一个协同的“可控思维”体系。

综合专家观点，这一体系的发展呈现出三大趋势。

01 RAG 不会消失，反而会变得更加基础与核心

它的内涵正在从狭义的文档问答，扩展为 Agent 对所有上下文数据的 Retrieval 能力——无论是企业内部文档、数据库中的业务数据，还是工具（Tools）与技能（Skills）的元数据，都需要被高效检索与调用。

未来的 RAG 将深度融入工作流（Workflow），根据应用反馈动态优化，并与混合搜索（Hybrid Search）等技术结合，实现更精准的“语义理解+精确过滤”。

02 Memory 与 RAG 边界模糊，融合为数据层

从技术基础设施（Infra）视角看，Memory 与 RAG 的本质都是数据的存储与召回。

二者的区别更多在于数据特性和使用场景：Memory 更侧重于个性化的、时序性的对话与状态记忆；RAG更侧重于客观的、相对静态的知识存储。但在服务 Agent 时，它们共同构成了支撑“上下文（Context）”的数据层。一个优秀的底层平台，应能一体化地管理这两种数据范式。

03 工程复杂度下沉，呼唤一体化数据基座

当应用层通过 Skills 和灵活编排满足业务多变需求时，通用的、性能瓶颈性的复杂度会自然下沉到底层基础设施。无论是多路检索、混合搜索，还是海量 Skills 元数据的管理，都对底层数据平台的能力提出了更高要求。

专家们指出，未来的理想路径是依赖一个强大的数据基座，它能原生支持向量检索、关系查询与结构化记忆，从而让开发者从繁琐的多系统集成工作中解放出来，更专注于 Agent 本身的业务逻辑。

因此，构建“可控思维”的终极路径，在于选择或打造一个能够统一承载 Agent 记忆、知识与状态的数据基座。这样的基座，正如专家们在讨论中多次暗示的，能够将 Memory 的个性化记录、RAG 的海量知识检索、以及支撑 Skills 运行的业务数据，融于一个简洁、高效、一致的系统中。它让 Agent 的“思维”过程变得可管理、可观测、可优化。

最终，Prompt、RAG、Skills、Memory 这些活跃于应用层的概念，都将在这样稳固的基座之上，更好地各司其职、协同工作，共同将 Agent 从“聪明的对话者”转变为“可靠的业务执行者”。这标志着 AI 应用开发正式进入系统工程时代，而坚实的数据基础设施，是这一切得以实现的基石。

Flink SQL 是 Apache Flink 的核心模块之一，它让开发者可以使用标准的 SQL 语法来编写流处理和批处理作业。对于不想深究 Java/Scala 复杂 API 的“小白”来说，Flink SQL 是进入实时计算领域的最佳敲门砖。

本文将基于 Flink 1.20.1 版本，手把手教你在 WSL2 (Ubuntu) 环境下搭建环境，并运行你的第一个 Flink SQL 任务。

一、为什么选择 Flink SQL？

1. 低门槛：会写 SQL 就能开发实时任务。
2. 统一性：批流一体，同一套 SQL 既可以跑历史数据（批），也可以跑实时数据（流）。
3. 生态丰富：内置了大量的 Connector（连接器），轻松连接 Kafka、MySQL、Hive 等主流组件。

(图：Flink SQL 架构示意图，展示 SQL 解析、优化到执行的过程)

二、环境准备 (WSL2 Ubuntu)

本教程演示环境为 Windows 下的 WSL2 (Ubuntu 20.04/22.04)，这是目前 Windows 用户体验 Linux 开发环境的最佳姿势。
参考以前些的文章从零开始学Flink：揭开实时计算的神秘面纱，搭建好 Flink 环境。

三、体验 Flink SQL Client

Flink 提供了一个交互式的命令行工具：SQL Client。它允许你直接在终端编写和提交 SQL 任务。

1. 启动 SQL Client

如果没有启动Flink集群,则先启动flink集群:

./bin/start-cluster.sh

,然后在 Flink 目录下执行：

./bin/sql-client.sh

你将看到那只著名的松鼠 LOGO：

(图：SQL Client 启动欢迎界面)

2. Hello World：数据生成与打印

我们不依赖任何外部组件（如 Kafka），直接使用 Flink 内置的 datagen 连接器生成模拟数据，并用 print 连接器打印结果。

第一步：创建源表 (Source Table)

复制以下 SQL 到 SQL Client 中执行：

CREATE TABLE source_table (
    id INT,
    name STRING,
    ts TIMESTAMP(3),
    WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) WITH (
    'connector' = 'datagen',       -- 使用数据生成器
    'rows-per-second' = '1',       -- 每秒生成1条数据
    'fields.id.kind' = 'sequence', -- id 字段为序列
    'fields.id.start' = '1',       -- id 从1开始
    'fields.id.end' = '100'        -- id 到100结束
);

执行后显示 [INFO] Execute statement succeed.。

第二步：创建结果表 (Sink Table)

CREATE TABLE print_table (
    id INT,
    name STRING,
    ts TIMESTAMP(3)
) WITH (
    'connector' = 'print'          -- 使用控制台打印连接器
);

第三步：提交任务

将源表的数据插入到结果表：

INSERT INTO print_table SELECT * FROM source_table;

此时，SQL Client 会提交一个异步任务到集群。你会看到类似 Job ID 的输出。

3. 查看运行结果

由于我们使用的是 print 连接器，在 Standalone 模式下，输出会打印到 TaskManager 的日志文件中。

打开一个新的 WSL2 终端窗口，进入 Flink 目录查看日志：

# 进入 log 目录
cd log

# 查看最新的 .out 文件 (文件名包含 taskexecutor)
tail -f flink-*-taskexecutor-*.out

你应该能看到屏幕上不断跳动的数据流：

(图：终端 tail -f 命令看到的实时数据输出)

四、常用命令速查

在 SQL Client 中，你可以使用以下命令：

• HELP: 查看帮助。
• SHOW TABLES: 查看当前创建的表。
• SHOW JOBS: 查看运行中的作业。
• DESCRIBE table_name: 查看表结构。
• QUIT: 退出 SQL Client。

五、总结

恭喜你！你已经成功运行了人生中第一个 Flink SQL 任务。

通过本文，我们完成了：

1. WSL2 下 Java 和 Flink 1.20.1 的安装。
2. 启动了 Flink 本地集群。
3. 使用 SQL Client 创建了 Source 和 Sink 表，并跑通了数据流。

下一篇，我们将深入讲解 Flink SQL 中的窗口（Window）操作，看看如何处理“过去5分钟的订单总额”这类经典需求。

参考资料：

• Flink 官方文档
• 原文来自

在数字化浪潮中，软件定制开发已成为企业竞争力的核心引擎。然而，项目的失败率依然居高不下，常见场景是：客户对最终交付物不满意，开发方则抱怨需求反复无常。其根源往往不在于技术能力，而在于选择了不匹配的交付与协作模式。

本文将深入剖析两种主流的交付模式，并论证为何周期性订阅制（升级迭代模式） 正逐渐取代传统的一次性买断模式（按图施工模式），成为对客户和开发方都更为明智的选择。

一、两种交付模式的本质剖析

1. 按图施工式（一次性买断模式）

• 核心理念：交付一个确定的、完整的软件产品。
• 类比：如同建筑领域的「总包工程」。客户提供详细的设计图纸（需求文档），开发方作为「施工队」，负责在规定时间和预算内按图完工，验收交付后即完成主要合同义务。
• 特点：需求需高度明确，合同范围固定，采用固定总价或分阶段里程碑付款。变更需要繁琐的流程和额外的费用。

2. 协作设计式（周期订阅制/迭代模式）

• 核心理念：提供一项持续的软件进化服务。
• 类比：如同客户雇佣了一位长期的「建筑设计师兼工程顾问」。双方从概念草图开始，通过不断沟通、建造样板间（MVP）、调整优化，最终共同建造出理想的房屋，并在入住后持续提供改建和维保服务。
• 特点：需求在过程中动态澄清和调整，采用敏捷开发、小步快跑，按时间材料或周期性（如月度/年度）订阅付费。

二、模式对比：一次性买断 vs. 周期订阅

三、为何劝说各方拥抱周期订阅制？

对客户的八大价值主张

1. 降低决策门槛与风险：无需在项目启动时就押注全部预算，可以用最小的成本验证核心思路，让投资始终追逐可见的价值。
2. 掌控感十足：您不是花钱买一个「黑盒」，而是雇佣一个团队。您全程参与，每2-4周就能看到进展并调整方向。
3. 灵活应对变化：市场在变，您的需求也会变。订阅制让您的软件能够像业务一样敏捷进化，而非被半年前签订的合同所束缚。
4. 财务更健康：将不确定的资本性支出（CAPEX）转化为清晰、可预测的运营费用（OPEX），便于财务规划和审批。
5. 获得持续关怀：软件上线只是开始，持续的优化、适配和运维支持同样关键。订阅制天然包含了这份长期承诺。
6. 期望值管理：多次、小额的支付降低了「巨额花费必须完美」的焦虑感，让协作氛围更积极、理性。
7. 专注于业务，而非技术细节：您无需一次性想清所有功能细节，可以优先解决当前最痛的痛点，把专业问题交给专业团队。
8. 建立长期技术伙伴：您获得的不是一个供应商，而是一个深度理解您业务、伴随您成长的技术伙伴。

对开发方的六大战略优势

1. 构建可持续的商业模式：从「项目驱动」的饥饱不定，转向「服务驱动」的稳定现金流，业务更健康，估值更高。
2. 沉淀核心资产，实现复利增长：每个项目积累的通用模块、行业解决方案，都是未来项目的「加速器」。开发成本边际递减，交付速度和质量却边际递增，形成强大竞争壁垒。
3. 深化客户关系，提升生命周期价值：长期合作带来深度信任，您从成本部门转变为价值部门，客户流失率低，增购和转介绍机会多。
4. 优化团队与项目管理：稳定的工作流和节奏，有利于团队技术成长和知识沉淀，减少因项目频繁启动/结束带来的管理损耗。
5. 专注于创造价值，而非争论范围：摆脱了「按合同条款扯皮」的消耗战，将精力真正投入到为客户解决问题、创造价值上，从而获得更高的职业成就感和客户满意度。
6. 吸引优质客户：这种模式会自动筛选出那些看重长期价值、理性决策、寻求伙伴的优质客户，远离那些一味比价、期望不切实际的客户。

四、如何成功开启订阅制合作？

1. 从最小可行产品（MVP）开始：用4-8周时间，集中资源打造一个解决最核心痛点的、可运行演示的MVP。这是建立信任的第一块基石。
2. 设计清晰的服务产品包：明确订阅费包含的内容（如：每月X人天的开发投入、运维支持范围、沟通机制等），让服务标准化、透明化。
3. 拥抱极致透明：使用协作工具共享开发看板，坚持定期演示与复盘。让客户的钱花得明明白白，进度看得清清楚楚。
4. 签订着眼于长期的合同：在合同中明确服务模式、知识产权归属（通用组件归属开发方）、续约与终止条款，为长期合作奠定法律基础。

给开发方的关键话术

“我们建议采用分阶段订阅合作，核心是 ‘为您降低风险，而非抬高预算’。我们先投入一小笔资金和几周时间，快速打造一个核心功能可用的‘样品’。您能立刻验证方向。若可行，我们就像您的内部技术团队一样，每月规划、每月投入、每月交付可见价值。您的资金始终在驱动确定的进展，而非消耗在漫长的、不确定的等待中。”

结语

从「按图施工」到「协作设计」，从「一次性买断」到「周期订阅」，这不仅仅是收费方式的变化，更是软件开发行业从手工作坊模式向现代专业服务模式的范式转移。

它要求开发方从代码工匠进化为价值顾问，也要求客户从被动验收者进化为积极参与的共创者。当双方基于信任与共同目标，以订阅制为纽带结成长期伙伴时，软件才能真正摆脱「项目」的桎梏，进化为持续驱动业务增长的活的生命体。

选择订阅制，就是选择了一条更稳健、更灵活、更具长期价值的数字化征程。

在现代汽车制造中，冲压工艺作为车身成型的核心环节，其稳定性与精度直接影响整车质量与生产节拍。然而，传统冲压依赖工程师经验进行参数调整，面对材料批次差异、模具磨损、环境温湿度波动等复杂变量，往往陷入“试错—反馈—再试错”的低效循环。模具更换动辄数小时，首件合格率徘徊在80%左右，不仅造成产能浪费，更推高了单位制造成本。这一困境的本质，是多变量强耦合与动态不确定性超出了人类经验的掌控边界。要真正突破瓶颈，必须引入一种能实时感知、自主学习、动态响应的智能系统，而人工智能，正成为破解这一难题的关键钥匙。
AI对冲压工艺的赋能，不在于替代人，而在于扩展人的感知与决策能力。通过在压力机、模具、送料系统等关键节点部署高精度传感器，结合PLC与MES系统，AI平台能够采集每一道工序的温度、压力、位移、振动等数百项参数，并以毫秒级频率进行流式处理。这些数据不再是孤立的数字，而是被赋予了时间序列与工艺语义的“工艺语言”。基于LSTM、Transformer等深度学习模型，系统能从历史数据中挖掘出材料回弹、模具热变形与压力补偿之间的隐性关联，构建出超越传统物理模型的预测能力。更重要的是，AI能将资深工程师的“手感”转化为可复用的决策规则，比如当模具温度上升至某一阈值时，自动触发压力微调补偿，这种隐性知识的显性化，使工艺优化从经验驱动转向数据驱动。
在实践层面，广域铭岛的Geega工业AI平台已在多家头部车企落地。以某自主品牌新能源车企为例，其冲压线曾因模具热变形导致尺寸超差，返修率高达12%。部署AI系统后，平台通过实时监测模具温度场变化，结合历史回弹数据训练出动态补偿模型，自动调节液压机压力曲线，使曲轴冲压件尺寸精度稳定在±0.02mm以内，换模时间从4小时压缩至1.5小时，设备综合效率提升35%，年节约成本超1800万元。无独有偶，德国博世旗下汽车零部件工厂也引入了基于数字孪生的AI冲压优化系统，通过在虚拟环境中模拟不同材料与润滑条件下的成型过程，提前预测模具寿命与缺陷风险，实现预防性维护与参数预调，使模具更换周期减少40%，废品率下降32%。两家企业的共同点在于，都未追求“一步到位”的全面改造，而是从关键工位试点，逐步构建起数据闭环与持续优化机制。
AI驱动的冲压工艺优化，正在重新定义汽车制造的精度边界。它不是一次性的技术升级，而是一场从“人适应机器”到“机器理解工艺”的范式转变。未来，随着多模态感知与自主决策代理的发展，冲压线或将实现真正意义上的“无人干预、自适应运行”，为全球汽车产业迈向零缺陷、零浪费的智能制造新阶段提供坚实支撑。

后台系统（如ERP、OA、CRM，）作为企业内部系统，具有需求明确、变化频繁、逻辑复杂度适中的特点，而后台管理系统的开发效率和响应速度直接影响到运营效率，更甚者可能影响到业务竞争力。

传统开发模式面临成本高、周期长、维护难等挑战。

本文从背景分析、设计方案、核心模块及核心功能三个维度，系统阐述低代码平台如何从根本上提升运营后台开发效率，为企业数据化转型提供新路径。

一、背景分析

传统运营开发模式的核心痛点：

1、重复造轮子，创新成本高昂

运营后台70%功能是增删改查，简单的列表查询配置业务，占比30%，相同功能在不同项目中反复开发，不仅浪费资源，更导致技术债务累积。

2、响应速度滞后

简单的列表查询配置业务，从需求提出到最终上线，传统开发需求经历需求评审、技术设计、编码实现、测试验证、部署上线等多个环节，平均耗时3-5天。

二、设计方案

以贴合自身业务需求、落地开发提效为核心导向，前期充分调研业内主流低代码平台，深度分析各平台的功能优势，不盲从”全功能“标杆，而是以自身开发需求、业务场景、技术栈特性为标尺，构建低代码平台。

平衡功能与易用性，拒绝过度开发，针对平台基础能力与通用组件，采用“基础配置+业务轻封装”的设计思路。基础项保留灵活的原生配置能力；同时结合运营后台业务的通用场景，对高频使用的功能、组件进行简单封装，既保留配置灵活性，又能适配业务实际。平台整体架构设计如下：

应用层模块介绍

业务中心模块：接收页面管理模块同步的已发布页面，展示用户有权限的业务页面。

权限模块管理：管理系统权限、页面权限、用户。

数据源管理模块：

数据源管理：对接数据库、API接口，支持数据源的新增、编辑、停用等；

元数据配置：可视化配置数据库字段信息，定义字段类型（文本/数值/日期）、显示别名等。

页面管理模块

页面创建：提供空白画布、预制组件，支持拖拽式组件布局（文本、表格、筛选器等）。

组件配置：配置基础属性、数据源、事件交互等。

预览并保存：生成预览结果；保存即发布。

四大模块共同构建了平台的基础能力矩阵，但从业务落地的优先级来看，页面管理模块是驱动整个平台运转的核心引擎 —— 运营人员的所有配置操作都围绕它展开，其他模块也都是为它提供数据、权限、业务关联的支撑。

基于此，我们将从整体框架下沉到核心模块及核心功能。

三、核心模块及核心功能

01、核心模块——页面管理模块

页面管理模块分三大核心：引擎、物料服务、数据源。

三个核心的职责

引擎（蓝色模块）：是页面构建的 “操作中枢”，负责页面的可视化编辑与最终输出。它提供了页面拖拽布局、页面编排、组件树管理、组件属性配置等功能（运营人员通过这些操作完成页面的样式与逻辑配置），最终通过 “渲染、出码” 能力，将配置好的内容转化为可访问的页面。

物料服务（绿色模块）：是页面的 “组件资源库”，负责组件的生产、管理与规范。它提供标准化的组件（如按钮、表格、图表），并通过 “物料规范” 保证组件的统一性；同时支持组件的版本管理，确保不同页面使用的组件版本一致。

数据源（黄色模块）：是页面的 “数据支撑”，负责提供页面所需的业务数据。它对接企业的数据库、API 等数据来源，为页面中的组件（如数据表格、报表）提供数据绑定的基础。

三个核心的协同流程

物料服务与引擎联动：物料服务将标准化组件（按物料规范）同步到引擎的 “组件树” 中，供引擎的页面编辑功能调用。

数据源与引擎联动：数据源提供数据元信息，供引擎在 “属性配置” 环节将组件与具体业务数据绑定。

引擎整合输出：引擎通过 “拖拽布局、页面编排” 整合物料组件与数据源，最终通过 “渲染、出码” 生成可访问的页面（图下方的最终产物）。

核心功能

页面管理模块，通过具体能力支撑业务快速开发落地，核心功能主要包含：可视化页面开发、自定义组件、发布、出码。

可视化页面开发：可视化页面开发是低代码的核心优势。开发者通过拖拽组件绘制页面布局和配置组件与数据源绑定，整合物料组件与数据源，无需编写大量前端代码，快速实现项目落地。下面以实例介绍可视化页面开发过程。

实例：开发项目阶段信息维护页面

页面需求：展示页面名称“项目阶段信息维护，展示数据表格，包含id、项目阶段名称、操作三列，表格按照 id 正序排列，列表项支持编辑和删除两种操作，支持弹窗新增数据，并且需要校验阶段名称必填。

页面开发流程：

重点介绍拖拽组件绘制页面布局和配置组件与数据源绑定。

页面绘制区块介绍：

图源：织信低代码

在组件库中，选择合适的组件，拖拽到编辑器画布中；

对画布中的组件，进行组件配置，例如组件基础属性、数据源、交互事件、样式等。

针对实例需求：

标题：使用Title组件

新增按钮和列表：使用高级表格组件

配置组件与数据源绑定

列表：配置数据列，配置列标题、数据类型、数据字段、对齐方式等。

新增按钮：配置操作栏，配置名称、按钮样式、是否禁用、是否隐藏、点击事件等；其中点击事件绑定用户在左侧源码面板中创建的组件事件。

新增弹窗：配置弹窗标题、弹窗按钮、弹窗中表单、表单项校验是否必填项等。

最终页面结果：在上面的实例中，我们使用的是平台标准化组件，拖拽组件搭建页面布局，配置组件属性实现交互逻辑，将开发时间从天压缩到小时，显著提升开发效率。

功能二

自定义组件

组件库是整个平台的核心基石与价值载体，它直接决定了平台的开发效率、功能上限、交付质量和用户体验，是低代码模式能够实现 “少写代码、快速交付” 的核心支撑。

自定义组件让平台能够满足个性化的业务需求，突破标准化组件的功能局限。下面以实例介绍自定义组件开发过程。

实例：自定义组件table，实现表格展示支持多场景

背景介绍：标准化表格组件，不满足运营对列表展示要求，存在展示局限性：

仅支持基础文本展示，无法满足运营后台多样化内容展示需求，例如图片、超链接、音频、视频等

原始数据可读性差，例如：操作时间展示时间戳，状态展示0、1等

解决思路：

归纳运营后台常见列展示需求，覆盖多类型内容形式，

增加表格列属性配置，不同类型搭配不同配置项，

支持拓展，实现跨列数据源展示等。

开发实现：遵守物料协议和引擎规则标准化开发，确保组件能无缝融入平台的页面编辑与渲染体系；

类型汇总：

基础类：文字，直接展示列绑定数据，无需其他配置项

时间类：时间，将时间戳转换为YYYY-MM-DD HH:mm:ss 格式，无需其他配置项

媒体类：

图片，配置图片路径、替代文本

音频，配置音频资源

视频，配置视频资源

链接类：超链接，配置跳转地址、链接文案

拓展类：HTML自定义片段，配置渲染函数，满足个性化需求

部署发布：

组件物料独立打包发布

修改平台依赖包配置

平台重新构建发布

平台共实现自定义组件10+个，包括表格组件、统计图组件、菜单组件、布局组件等，满足运营后台个性化业务需求，丰富组件库生态，实现根据业务需求持续新增、优化组件，保障平台能力与企业业务发展同频，降低技术架构的迭代成本。

功能三

发布

平台采用保存即发布模式，页面配置完成后，直接同步至平台数据库，无需编写代码、单独测试与复杂的环境部署，可通过平台生成的专属链接直接访问使用，部分轻量需求甚至能实现小时级配置、即时上线，大幅简化开发流程，省去传统模式中编码、部署等核心耗时环节，将简单需求的交付周期从天级压缩至小时级，大幅提升业务需求的响应与落地效率。

功能四

出码

平台深度基于 Vue Render 渲染机制构建，支持通过可视化拖拽、属性配置完成页面 / 组件的可视化绘制后，一键导出基于 Vue2.js 框架 + ElementUI 组件库的标准 Vue 单文件组件（.vue）源代码。导出的代码完全遵循 Vue2 语法规范与 ElementUI 组件调用逻辑，保留完整的组件结构（template/script/style）、属性配置、事件绑定及逻辑关联，无黑盒封装，可直接在 Vue2 项目中复用、二次开发或部署运行，实现 “可视化搭建” 与 “原生代码” 的无缝衔接。

出码优势：摆脱平台绑定，掌握开发自主权

获取完整的源代码，能基于导出的文件进行独立部署、运维和迭代，让系统开发不再依赖低代码平台本身。

兼顾高效开发与深度定制，平衡效率与灵活：前期依托低代码可视化拖拽快速完成项目主体搭建，大幅缩短开发周期；针对高复杂度、高个性化的业务需求，可导出源文件通过纯代码进行深度定制优化，既用低代码省时间，又用原生代码满足极致化需求，实现“高效搭建 + 深度定制”的双重效果。

二次开发的灵活性：跨项目、跨技术栈开发时，源文件能被复用、拆解，提升整体开发资源利用率。

跨项目、跨技术栈开发时，源文件能被复用、拆解，提升整体开发资源利用率。

结论

总而言之，织信低代码平台以可视化配置、快速部署、低门槛上手的核心优势，契合当下对数字化开发 “快、准、省” 的需求。它不仅是一款开发工具，更是企业数字化转型的专属解决方案，用技术简化开发，用效率赋能业务，这正是低代码平台的核心价值所在。