刚接触后端不久,帮忙推荐一个免费的数据库可视化工具
mac 系统,现在在用 Navicat Lite ,就是免费版本的,能支持个 ERD 就好
xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。
mac 系统,现在在用 Navicat Lite ,就是免费版本的,能支持个 ERD 就好
近日,OpenAtom openKylin(简称"openKylin")RISC-V SIG(特别兴趣小组)完成一项重要适配验证工作,依托超睿科技UR-DP1000 RISC-V芯片,结合KVM虚拟化技术,成功将开源云计算管理平台OpenStack完整移植至RISC-V架构。此次适配仅完成基础运行验证,实现了Ubuntu、Debian、openKylin等主流Linux发行版的稳定启动与运行,同时可借助DevStack搭建小规模测试环境,后续实际生产能力仍需进一步验证优化,为RISC-V架构在云计算领域的后续探索筑牢基础。 RISC-V云计算生态的待解难题 适配验证成果:实现软硬件基础协同运行 未来展望:持续优化,探索生产级适配可能 立即体验:RISC-V OpenStack基础运行测试指南 关于OpenStack和Devstack 关于openKylin RISC-V SIG
当前,RISC-V架构在硬件领域的发展速度不断加快,在嵌入式、消费电子等场景的应用逐渐铺开,但在云计算这一关键领域,生态短板始终制约其规模化落地。作为全球主流的开源云管理平台,OpenStack的适配缺失,导致RISC-V架构难以搭建起完整的云基础设施服务体系。此前,RISC-V架构缺乏成熟的虚拟化调度框架与云平台适配方案,开发者无法像在X86或ARM架构上一样,便捷地部署云服务相关能力。同时,硬件与软件层面的适配问题相互交织,让RISC-V云原生应用的开发与部署流程复杂且成本较高,难以在数据中心、边缘云等场景实现广泛应用。超睿科技UR-DP1000芯片的出现,为解决上述难题提供了可靠的硬件支撑。这款RISC-V处理器具备原生虚拟化支持能力,能够为OpenStack的移植与基础运行验证提供稳定且适配的硬件运行环境。
openKylin RISC-V SIG团队此次的工作,核心聚焦于硬件适配、虚拟化部署、云平台兼容三大方向,完成了全链路的基础运行验证。1. KVM虚拟化层与硬件的基础适配运行团队基于超睿科技UR-DP1000芯片的虚拟化特性,完成了KVM/riscv模块的基础适配部署。通过对虚拟化相关机制的调试与优化,打通了芯片硬件与虚拟化层之间的运行链路,确保KVM虚拟化技术能够在该RISC-V芯片上稳定发挥基础作用,为上层云平台的基础运行提供了可靠的虚拟化环境,相关性能与生产适配性仍需进一步测试。2. OpenStack与主流Linux发行版的基础兼容运行团队顺利完成OpenStack核心组件的RISC-V架构移植工作,解决了移植过程中出现的软件依赖与系统兼容问题,实现了基础功能的正常运行。移植后的OpenStack可兼容Ubuntu 24.04、Debian 13、openKylin 2.0等主流Linux发行版的虚拟机镜像,用户可通过标准OpenStack API开展实例创建、网络配置等基础操作,操作流程与在X86平台上保持一致,同时可借助DevStack快速搭建小规模测试环境,暂未验证其大规模生产场景的承载能力。
openKylin RISC-V SIG团队表示,此次OpenStack移植及基础运行验证的完成,只是RISC-V云计算生态探索的起点,目前仅实现基础运行能力,实际生产能力仍有待进一步验证与优化。接下来,团队将与超睿科技、RISC-V国际基金会等合作伙伴深化协作,推进两项重点工作。
1.推进上游社区融合:计划在未来3-6个月内,将RISC-V架构下的OpenStack适配代码、KVM相关优化成果贡献至上游社区,推动OpenStack官方正式支持riscv64架构,同时参与RISC-V虚拟化技术标准的制定,减少生态碎片化问题,为后续生产级适配奠定基础。
2.开展生产级适配测试:针对边缘云、工业云等特色场景,逐步开展基于超睿UR-DP1000芯片、OpenStack与KVM技术的生产级适配测试,完善资源调度策略,验证平台的规模化部署能力与安全隔离水平,逐步推进场景化解决方案的落地探索。
团队的最终目标是,联合各方合作伙伴,逐步完善RISC-V架构下的云计算生态,持续验证并提升相关技术的生产适配能力,让全球RISC-V用户能够便捷地探索云计算服务的应用可能,推动RISC-V架构从小众技术领域,逐步走向主流基础设施行列,为全球开源云生态的发展注入新动力。
为方便全球RISC-V开发者共同参与探索与优化,openKylin社区已开放移植后的OpenStack源码与部署脚本,供开发者开展基础运行测试,相关生产级应用请谨慎使用。开发者可按照以下步骤快速体验:
1.环境准备:准备搭载超睿UR-DP1000芯片的硬件平台,并安装openKylin 2.0 RISC-V版本操作系统。
2.下载部署脚本git clone https://gitee.com/openkylin/devstack.git
3.一键部署cd devstack#部署前请务必查看README./stack.sh
4.测试验证:部署完成后,通过浏览器访问OpenStack Dashboard,即可开展基础的虚拟机实例创建和管理测试。
OpenStack:是一个庞大的开源软件集合(由 Nova, Neutron, Cinder 等几十个项目组成),用于管理数据中心的所有资源(计算、存储和网络)。
DevStack:实际上是一套脚本(Shell Scripts),它的唯一目的就是从源代码快速克隆并安装一个“最小化”的 OpenStack 环境。
openKylin RISC-V SIG专注于RISC-V架构的开源软件生态建设,工作范围涵盖操作系统移植、工具链开发、云平台适配等核心领域,致力于联合全球开发者共同探索RISC-V技术的应用可能。社区欢迎全球范围内的RISC-V开发者、硬件厂商、科研机构加入,共同推动RISC-V技术的创新与落地。
SIG主页:https://gitee.com/openkylin/community/tree/master/sig/RISC-V
还有一些细节正在处理, 支持输入 github 仓库地址来检索目录下的 markdown 文件并展示, 做了连续加载和加入书架的一些操作简化
如果以后 V 友在这节点发布连载小说, 就可以 at 我, 或者我提供一个工具, 让一个自动化工具扫描 V 友提供的小说名, 然后根据规则拆分帖子, 导出一个 markdown 文件到 github 仓库中, 每一本小说都是一个文件夹.
这样其他 V 友就可以通过我做的这个工具来阅读在这个节点下发布的所有上架的小说了, 解决了帖子太分散, 不能连贯阅读的缺憾
等我优化完细节, 试用一段时间之后, 会开源这个小作品.





另附一个因为这个阅读器延伸出来的小项目截图, 打算用这个渡过前期这个节点的小说资源太少的尴尬时期:

ps: AI 生成小说实在是太耗 token 了
🌟 TrendForge 每日精选 - 发现最具潜力的开源项目 🌐 智能中文翻译版 - 项目描述已自动翻译,便于理解 项目简介: Claude Code插件可自动记录编码会话中Claude的全部操作,通过AI技术进行压缩处理,并将相关上下文智能注入后... 今日新增: 2638 | 总星数: 22452 | 语言: TypeScript 项目截图: https://github.com/thedotmack/claude-mem 项目简介: Codex 技能目录 今日新增: 746 | 总星数: 3646 | 语言: Python https://github.com/openai/skills 项目简介: ChatDev 2.0:基于大语言模型的多智能体协作实现全流程开发 今日新增: 227 | 总星数: 29961 | 语言: Python 项目截图: https://github.com/OpenBMB/ChatDev 项目简介: 智能体编排指挥中心 今日新增: 187 | 总星数: 1650 | 语言: TypeScript 项目截图: https://github.com/pedramamini/Maestro 项目简介: ⚡️ GenBI(生成式商业智能)支持使用自然语言查询任意数据库,可在数秒内生成精准的SQL(文本转SQL)、图表(文本... 今日新增: 89 | 总星数: 13897 | 语言: TypeScript 项目截图: https://github.com/Canner/WrenAI 项目简介: Qlib是一款面向AI的量化投资平台,其目标是从创意探索到生产部署的全流程,通过人工智能技术赋能量化研究。该平台支持多种... 今日新增: 83 | 总星数: 36521 | 语言: Python 项目截图: https://github.com/microsoft/qlib 项目简介: 真正独立的网页浏览器 今日新增: 68 | 总星数: 58263 | 语言: C++ https://github.com/LadybirdBrowser/ladybird 项目简介: 主Claude代码钩子 今日新增: 47 | 总星数: 2351 | 语言: Python 项目截图: https://github.com/disler/claude-code-hooks-mastery 项目简介: Node 版本管理器 - 符合 POSIX 标准的 bash 脚本,用于管理多个活跃的 node.js 版本 今日新增: 35 | 总星数: 91244 | 语言: Shell 项目简介: 通过代码生成的实时动态图表,实现软件架构的可视化、协作与持续演进。 今日新增: 29 | 总星数: 1421 | 语言: TypeScript 项目截图: https://github.com/likec4/likec4 项目名称: LadybirdBrowser/ladybird 项目描述: 真正独立的网页浏览器 今日新增: 68 | 总数: 58263 地址: https://github.com/LadybirdBrowser/ladybird 项目名称: dail8859/NotepadNext 项目描述: Notepad++ 的跨平台重实现版本 今日新增: 37 | 总数: 13347 项目截图: 地址: https://github.com/dail8859/NotepadNext 项目名称: deskflow/deskflow 项目描述: 在多个计算机之间共享同一套键盘和鼠标。 今日新增: 34 | 总数: 23680 项目截图: 地址: https://github.com/deskflow/deskflow 项目名称: ScoopInstaller/Scoop 项目描述: Windows 命令行安装程序 今日新增: 10 | 总数: 23568 地址: https://github.com/ScoopInstaller/Scoop 项目名称: microsoft/Agents 项目描述: Microsoft 365 Agent SDK 简化了为 M365、Teams、Copilot St... 今日新增: 7 | 总数: 705 地址: https://github.com/microsoft/Agents 项目名称: microsoft/fabric-toolbox 项目描述: Fabric工具箱是由Fabric CAT提供的工具、加速器、脚本和示例存储库,旨在加速您在Micr... 今日新增: 5 | 总数: 659 地址: https://github.com/microsoft/fabric-toolbox 项目名称: dreamhunter2333/cloudflare_temp_email 项目描述: CloudFlare 免费临时域名邮箱 支持附件收发 IMAP SMTP TelegramBot 今日新增: 40 | 总数: 5930 项目截图: 地址: https://github.com/dreamhunter2333/cloudflare_temp_email 项目名称: CorentinTh/it-tools 项目描述: 专为开发者打造的便捷在线工具集合,拥有卓越的用户体验。 今日新增: 21 | 总数: 36877 项目截图: 地址: https://github.com/CorentinTh/it-tools 项目名称: Lissy93/dashy 项目描述: 🚀 可自托管的个人仪表板,包含状态检查、小组件、主题、图标包、UI编辑器及更多功能! 今日新增: 17 | 总数: 23901 项目截图: 地址: https://github.com/Lissy93/dashy 项目名称: junegunn/vim-plug 项目描述: 🌺 极简Vim插件管理器 今日新增: 5 | 总数: 35532 项目截图: 地址: https://github.com/junegunn/vim-plug 项目名称: tpope/vim-fugitive 项目描述: fugitive.vim:一个强大到堪称非法的 Git 封装工具 今日新增: 4 | 总数: 21626 地址: https://github.com/tpope/vim-fugitive 项目名称: ggml-org/llama.vim 项目描述: LLM辅助代码/文本补全的Vim插件 今日新增: 1 | 总数: 1856 项目截图: 地址: https://github.com/ggml-org/llama.vim 项目名称: obra/superpowers 项目描述: Claude Code 超级能力:核心技能库 今日新增: 993 | 总数: 44435 地址: https://github.com/obra/superpowers 项目名称: automazeio/ccpm 项目描述: 基于GitHub Issues与Git工作树实现并行智能体执行的Claude Code项目管理系统。 今日新增: 387 | 总数: 6982 项目截图: 地址: https://github.com/automazeio/ccpm 项目名称: anthropics/claude-code 项目描述: Claude Code是一款基于终端的智能编程工具,它能理解您的代码库并通过自然语言命令执行常规任务... 今日新增: 351 | 总数: 64053 项目截图: 地址: https://github.com/anthropics/claude-code 项目名称: coollabsio/coolify 项目描述: 开源且可自行托管的Heroku/Netlify/Vercel替代方案。 今日新增: 34 | 总数: 50269 项目截图: 地址: https://github.com/coollabsio/coolify 项目名称: filamentphp/filament 项目描述: Laravel强大的开源UI框架 • 借助Livewire快速构建与部署管理后台及应用系统 今日新增: 27 | 总数: 29055 项目截图: 地址: https://github.com/filamentphp/filament 项目名称: krayin/laravel-crm 项目描述: 面向中小企业和企业的免费开源 Laravel CRM 解决方案,提供完整的客户生命周期管理。 今日新增: 24 | 总数: 21104 项目截图: 地址: https://github.com/krayin/laravel-crm 最活跃语言: TypeScript(4个)、Python(4个)、C++(1个) 今日总获星: 4,180 颗星 平均获星: 348 颗星/项目 今日之星: thedotmack/claude-mem (2638) TrendForge 致力于追踪全球开源项目动态,每日为开发者精选最具价值的 GitHub 项目。 数据来源: https://trendforge.devlive.top/ 数据说明: 基于 GitHub 官方 API 数据统计,每日更新 翻译声明: 项目描述采用 AI 智能翻译,如有疏漏请以原文为准 报告生成于: 2026年02月05日
📊 今日共收录 12 个热门项目,涵盖 50 种编程语言🏆 今日最热项目 Top 10
🥇 thedotmack/claude-mem

🥈 openai/skills
🥉 OpenBMB/ChatDev

4. pedramamini/Maestro

5. Canner/WrenAI

6. microsoft/qlib

7. LadybirdBrowser/ladybird
8. disler/claude-code-hooks-mastery

9. nvm-sh/nvm
10. likec4/likec4

🌈 分语言热门项目
● C++ 最热项目


● PowerShell 最热项目
● Vue 最热项目


● Vim Script 最热项目


● Shell 最热项目

● PHP 最热项目



📈 今日趋势分析
📊 数据总览
指标 数值 收录项目 12 个 编程语言 50 种 今日新增 4,180 颗星 报告日期 2026年02月04日 统计周期 日报 GitHub #开源项目 #技术趋势 #程序员 #软件开发
“我们坚信,开源是推动产品持续演进的关键引擎。尤其在探索 AI 原生场景的过程中,唯有与上下游生态和开发者并肩协作、共创共进,才能走得更远。” 1 月 31 日,在上海举办的 2026 OceanBase 社区嘉年华现场,OceanBase CTO 杨传辉表示。 社区嘉年华是 OceanBase 持续举办的年度品牌活动,至今已有三年,旨在构建开放共享的技术交流平台,链接全球开发者与行业伙伴。 本次活动吸引了 260 余位技术爱好者、开发者参与,通过主题演讲、圆桌对话、AI Coding 实战、社区开放麦等形式,呈现了 10 多场高质量分享,全面展现社区生态活力与技术创新。 OceanBase 是一款 100% 自主研发的原生分布式数据库,长期坚持“应用驱动技术创新”的理念,并于 2021 年 6 月正式宣布开源。 OceanBase CTO 杨传辉指出:“底层软件是靠用出来的。谁来用?答案自然是开发者。”他强调,数据库作为数字基础设施,其发展必须与用户和生态共同成长。 OceanBase CTO 杨传辉 他公布了一组数据:自开源以来,OceanBase 全球累计下载量已突破 10 万次,部署节点规模达到数百万级别,并吸引了超过 1600 名外部贡献者参与到代码提交、文档完善及问题修复等共建工作中。 杨传辉表示,开发者是技术落地的重要推动力,也是构建创新生态的基石。这也是 OceanBase 在 2025 年开源首款 AI 原生混合搜索数据库 OceanBase seekdb 的原因。OceanBase seekdb 主打“开箱即用”,开发者仅需三行代码,即可快速构建知识库、智能体等 AI 应用,轻松应对百亿级多模数据检索。“我们目前仍处于探索阶段,期待更多年轻开发者加入,共同推进 AI 与数据库技术的融合。” “社区的每一次进步,都离不开开发者和共建者的支持。”OceanBase 开源生态负责人封仲淹表示。现场,他以“一路有你,OceanBase 社区嘉年华”为主题,分享了 OceanBase 的开源理念与未来规划。 OceanBase 开源生态负责人封仲淹 封仲淹提到,OceanBase 开源已步入第四年,“开源开放,生态共赢”不是一句简单的口号,而是长期坚持的理念。过去一年,在社区开发者的积极参与与生态伙伴的协同推动下,OceanBase 社区版已逐步构建起完善的企业级数据库能力。 截至目前,OceanBase 已联合 400 余家独立软件开发商,共同打造超过 1000 项联合解决方案,拥有 300 多家经销商伙伴及 30 余家交付合作伙伴,累计完成技术集成 1600 余项,持续赋能千行百业的数字化转型。 展望 2026 年,封仲淹表示,OceanBase 将继续深化与生态伙伴的合作,汇聚更多行业力量。一方面积极拥抱 AI 技术,持续建设开发者生态;另一方面坚定推进全球化战略,携手生态上下游伙伴,拓展更多应用场景,助力 OceanBase 走向更广阔的全球市场。 活动当天,OceanBase 还正式聘任 LangChain Ambassador 张海立、Xenera LLM Project Lead 伊洪、英伟达技术专家程治玮、武汉大学国家网络安全学院学生李子毅,以及上海爱可生信息技术股份有限公司的何文超为 OceanBase 年度社区大使。封仲淹表示,期待在全球化道路上与更多社区大使携手同行。同时,2025 OceanBase 社区年度 31 位版主也同步揭晓。 在 AI 时代,构建坚实的数据底座离不开广大开发者的共同参与和生态协作。本次活动邀请了来自不同技术社区的嘉宾,他们结合自身实践与行业思考,围绕 AI 数据底座的构建路径展开深度分享。OceanBase seekdb 作为 AI 原生混合搜索数据库,成为多位嘉宾演讲中的高频词汇。 RAGFlow CEO 张颖峰亲历了从传统搜索到 AI 时代的跨越。“从 RAG 到 Context Engine,构建 AI Agent 的数据基座”为题,进行了分享。 RAGFlow CEO 张颖峰 “在很多人看来,RAG 或许已是过时的技术,但我认为,他恰恰能够成为 AI 原生数据库所需的重要基础。”张颖峰指出,未来的 AI 原生数据库不应仅仅是模型的堆叠,而应以“强检索能力”为核心,构建能够统一管理知识、数据与工具的上下文引擎架构。在这一框架下,单一的 RAG 技术虽已难以应对复杂的交互场景,但可以演进为支持智能体(Agent)的统一上下文引擎,通过“检索前置+上下文优化”机制,实现对结构化与非结构化数据、以及交互记忆(Memory)的综合处理。 他强调,RAG 的本质在于检索。未来的上下文引擎应具备按需为智能体提供精准信息的能力,并借助 OceanBase seekdb AI 原生数据库,支持多模态、高频率的混合检索,最终推动技术实现从单一检索到全方位上下文服务的跨越。 Dify 开源生态负责人郑立 Dify 开源生态负责人郑立以“Dify x OceanBase seekdb”为主题,进行了分享。他通过具体实践案例,介绍了 Dify 的核心能力,以及在与 OceanBase seekdb 的合作中打造一体化数据库的实践路径。 郑立指出,大量多智能体架构强调 AI 的自主决策与执行,但实际业务推进依然高度依赖人工沟通、确认与协同,这使得“完全自动化”的智能体难以直接落地到真实流程中。为此,Dify 秉持“增强人类能力”的设计理念,让 AI 融入流程、提升效率,而非取代人的角色。 在与 OceanBase seekdb 的合作中,Dify 完成了从多数据库组合到事务一致的统一数据层的升级。一方面,基于 OceanBase seekdb,Dify 自 v1.10.1 起正式兼容 MySQL。另一方面,通过统一的存储与检索架构,OceanBase seekdb 可同时承担元数据库,并提供向量与关键词混合搜索(Hybrid Search)能力,形成开箱即用的一体化部署方案,进一步降低部署与运维复杂度。 DevRel and Founding Member of Second State Miley Fu DevRel and Founding Member of Second State Miley Fu 则以“Building Cutomizable Agentic Voice AI: Echokit with OceanBase's Hybrid Search”为题进行了分享。 她介绍,WasmEdge 新开源了一款 Agentic Voice AI 产品——Echokit,其强调本地化部署能力,支持完全离线运行,兼顾隐私保护、可控性与高度定制化。在这一过程中,Echokit 已与 OceanBase seekdb 开展合作,将其作为本地数据库用于混合搜索。谈及选择 OceanBase seekdb 的理由,Miley Fu 表示,OceanBase seekdb 的三大优势:无 CDC 延迟、原生 AI 支持与良好 SQL 兼容性,能实现向量、元数据与文本的原子更新,并易于与智能体集成,非常适合实时语音 AI 场景。 Datawhale 内容生态负责人 Amy 来自 Datawhale 的内容生态负责人 Amy 则从社区与教育视角出发,以《让学习导向产业价值,Datawhale 的思考和探索》为题进行分享。作为成立七年的开源学习社区,Datawhale 始终致力于降低技术学习门槛,推动开发者通过实战掌握前沿技能。Amy 表示,这一理念与 OceanBase “开源开放,生态共赢”高度契合。Datawhale 计划与 OceanBase 共同建设 AI+数据库学习中心,降低数据库技术入门难度,助力构建健康、可持续的开发者生态。 从知识赋能到架构落地,开源工具正驱动 AI 应用走向成熟。 TEN Framework 发起人 & 架构师胡岳伟,在《TEN Framework:如何快速搭建带记忆的低延时对话式 AI Agent》演讲中,分享了在实时多模态智能体开发中的实践。 TEN Framework 发起人 & 架构师胡岳伟 TEN Framework 是一款面向实时多模态 AI Agent 的开源开发框架,已在 GitHub 获得近万星,具备真实落地能力。目前,TEN Framework 正在开发 Voice AI Agent 产品,并与 OceanBase PowerMem 开展合作,实现对话上下文的实时同步与记忆管理,为低延迟、高并发的对话场景提供底层支持。 从检索架构演进、一体化数据层构建,到语音 AI 落地、开源教育与框架赋能——五位嘉宾的分享,不仅呈现出 AI 数据底座建设的多元路径,也共同印证了开源协作、生态共建在推动技术走向成熟过程中的核心价值。 在嘉宾精彩分享之后,两场围绕 AI 时代关键议题的圆桌对话进一步激发了现场的思维碰撞。 在人工智能快速演进的大背景下,RAG 技术正成为推动 AI 能力落地的重要突破点,相关讨论也显得尤为深入。 活动现场,LangChain Ambassador 张海立、 RAGFlow CEO 张颖峰、FastGPT 负责人余金隆、Co-founder of Nowledge Labs 古思为以及 OceanBase AI 平台与应用部负责人吉剑南针对“从 Prompt 到 Skills,RAG 还行不行”这一话题,展开探讨。 多位行业专家从产品实践、技术演进与系统架构等维度切入,认为 RAG 不仅未过时,反而因与 Skill、Memory、数据库等技术的深度融合而更具生命力。成为上下文工程的核心基础设施,并与数据库、技能系统、记忆机制深度融合,推动 AI 应用从“问答玩具”向“生产级工作流”跃迁。 RAGFlow CEO 张颖峰表示,从 RAG 引擎到上下文引擎,技术不变,但其内涵会随着时代的变化而改变。谈及未来 RAG 是否应更多依赖数据库进行多路检索这一话题时,OceanBase AI 平台与应用部负责人吉剑南认为,RAG 应与数据库结合,这也是 OceanBase 提出的“混搜”这一理念的核心所在。Co-founder of Nowledge Labs 古思为则从图数据库视角出发,指出索引结构应贴近知识本质,并支持动态 Agent 检索;FastGPT 负责人余金隆补充说明标量与向量结合的动态检索实践。 在第二场圆桌对话中,南京大学研究生院人工智能课程企业教师谢肖瑜作为主持人,与 Eigent 核心研发工程师、CAMEL-AI 核心成员孙韬,OceanBase Ambassador 程治玮,蚂蚁百灵模型产品负责人边思康和Fellou 创始团队成员孙稼骏针对“Agent 元年之后,真正能用的 AI 长什么样”这一话题展开讨论。 随着AI技术深入现实应用,一个关键议题正引发广泛讨论:人类使用 AI 的门槛是否正在提高?针对这一问题,专家们认为,尽管当前部分 AI 工具仍需要一定配置与学习成本,但技术演进正推动交互方式发生根本性转变,回顾人机交互历史,从 DOS 命令到图形界面,技术门槛始终在不断降低。尤其在当下,大模型能力的显著提升,使得 AI 正变得更易理解与使用。越来越多的产品开始尝试通过界面引导、视觉交互降低操作难度,让非技术用户也能借助 AI 完成复杂任务。 这种“以人为中心”的设计趋势,意味着未来 AI 将不再仅是技术专家的工具,而会真正成为人人可用的普及型能力。在这一过程中,如何让技术适配人的习惯,而非让人适应技术,将成为产品进化的重要方向。 此外,本次活动创新设立了 AI Coding 实战环节。OceanBase Ambassador 伊洪以“开源,Agents 以及 AI Coding”为主题,进行了分享,并在现场零代码“手搓” coding agent 。 OceanBase Ambassador 伊洪 在 AI Coding 环节,颁发了“最快合并奖”“最难 pr 奖”“最多合并奖”“最佳创意奖”等 10 项大奖,其中,OceanBase Ambassador 程治玮获“最佳创意奖”,来自上海的 13 岁初二少年张天瑜获得 AI Coding “最难 pr 奖”第二名。 过去,参与开源往往需要先花时间熟悉项目,再完成编码、调试和提交,整体门槛较高。随着 AI Coding 工具能力的提升,开发者在理解代码、生成修改、定位问题和完善提交等环节能获得更多辅助,参与开源的门槛随之下降。 活动前,OceanBase 已在 OceanBase seekdb 的 GitHub 仓库集中开放了 83 个与 OceanBase 及其生态相关的 issue,便于社区开发者参与讨论与贡献。 获得 AI Coding “最难 pr 奖”第二名的张天瑜。此次选择的题目是“为 powermem 添加网页 Dashboard”,需要开发统计 API 和前端页面。前端他凭借两年的 React/Vue 经验独立完成,后端则交给 AI 辅助生成。“让我惊讶的是,AI生成的后端代码一次就跑通了。” 此外,在下午的社区开放麦环节,由 FastGPT、CelHive、CAMEL-AI、Refly.AI、Dify 以及 OceanBase seekdb 的各位技术专家 ,通过现场实操,为大家展示了在各个 AI 平台上构建 Agent 系统和工作流的便捷性。其中最令人印象深刻的是,各平台都纷纷展示了如何通过自然语言来高效地构建 Agent 和工作流,堪称吹响了一场 Agentic 革命的号角。 对于开发者而言,借助 AI 工具快速理解项目、上手的同时,能更专注于创意实现与边界探索,不仅让开发更智能,更让开源共建更可持续、更富创造力,而这也是 AI 时代赋予开源生态的新命题与新机遇。 本次社区嘉年华以技术为纽带,有效激发了社区的创新活力。展望未来,我们诚邀更多开发者与生态伙伴加入,携手拓展开源技术的应用边界与想象空间。


开源 4 年累计下载破 10 万次

开源开放,生态共赢




生态共聚:嘉宾共话 AI 数据底座建设





圆桌对谈:从 RAG 到 AI 专家共议未来方向


AI Coding 实战上演巅峰对决:13岁少年拿下第二名







公共资源速递 6 个公共数据集: 7 个公共教程: * Ovis-Image:高质量图像生成模型 * LightOnOCR-2-1B 轻量级高性能端到端 OCR 模型 * Personaplex-7B-v1:实时对话与角色定制语音接口 访问官网立即使用: openbayes.com 公共数据集 1. Sonar Signal 水下声呐信号数据集 Sonar Signal 是一个用于水下物体分类的声呐信号数据集。该数据集适用于二分类任务,目标是区分声呐信号是由岩石还是矿井反射而来。该数据集总计 207 个样本,每个样本包含 60 个连续数值特征。 在线使用: https://go.openbayes.com/RJhGo 2. Diabetes Mexico 墨西哥糖尿病数据集 Diabetes Mexico 是由墨西哥的国家公共卫生研究所发布的糖尿病数据集,旨在评估墨西哥人群中与糖尿病相关的代谢风险特征。该数据集包含墨西哥个体的社会人口学、人体测量及生物化学信息,主要变量涵盖调查标识符、性别、年龄、居住城市,以及体重、身高、体重指数等体格指标,并包括尿酸、白蛋白、肌酐、总胆固醇、HDL/LDL 胆固醇、甘油三酯、血清葡萄糖、胰岛素和糖化血红蛋白等相关生化指标。 在线使用: https://go.openbayes.com/gi6tC 3. Vehicles OpenImages 车辆图像数据集 Vehicles OpenImages 来源于 Google 的 OpenImages 大规模公开数据集,专注于车辆检测与定位的图像数据集,旨在支持车辆检测模型的快速高效训练。该数据集包含多种环境、光照条件和视角下的车辆图像,图像预处理为 416×416 分辨率,适用于 YOLO、SSD 和 RetinaNet 等现代目标检测模型提供COCO、YOLO、Pascal VOC 和 TensorFlow 格式的多种注释格式,兼容多种机器学习框架,包含平衡的训练/验证/测试分割,以评估模型性能。 在线使用: https://go.openbayes.com/Q61aS 数据集示例 4. LightOnOCR-mix-0126 文本转录数据集 该数据集包含训练集与验证集两部分,每个样本对应一个文档页面的文本转录结果,内容涵盖按自然阅读顺序组织的页面文本(输出格式包括 Markdown、LaTeX 数学公式及 HTML 表格等)以及相应的结构化标记,覆盖段落、标题、列表与表格等多类型页面内容。 在线使用: https://go.openbayes.com/SroyH 5. Delhi Pollution AQI 德里空气质量数据集 Delhi Pollution AQI 是一个面向空气质量分析和预测的环境数据集。该数据集提供了德里 NCR 地区主要城市的每小时空气质量和环境数据,适合用于污染分析、时间序列预测和机器学习应用。数据集拥有超过 200,000 条小时观测样本。 在线使用: https://go.openbayes.com/IbRsn 6. Chest X-ray Pneumonia 胸部 X 光肺炎数据集 Chest X-ray Pneumonia 是一个从胸部 X 光图像中提取的数值特征数据集。该数据集通过将每张图像转化为结构化的数值特征,包括全局强度统计、纹理描述符(GLCM)、频域特征(FFT)、基于边缘的度量以及局部二值模式(LBP)特征,来支持统计分析和经典机器学习。 在线使用: https://go.openbayes.com/IbRsn 公共教程 1. DeepSeek-OCR-2 视觉因果流 DeepSeek-OCR 2 是由 DeepSeek 团队推出的第二代 OCR 模型,通过引入 DeepEncoder V2 架构,实现从固定扫描到语义推理的范式转变。模型采用因果流查询和双流注意力机制,能动态重排视觉 Token,更精准地还原复杂文档的自然阅读逻辑。在 OmniDocBench v1.5 评测中,模型综合得分达到 91.09%,较前代提升显著,同时显著降低了 OCR 识别结果的重复率,为未来构建全模态编码器提供新路径。 在线运行: https://go.openbayes.com/C5oYw 2. Ovis-Image:高质量图像生成模型 Ovis-Image 是一个高质量图像生成模型系统,由 AIDC-AI 团队发布的 Ovis-Image-7B 高保真文本到图像生成模型构建。该系统采用多尺度 Transformer 编码器与自回归生成架构,在高分辨率图像生成、细节表现及多风格适配能力上表现卓越。通过优化的噪声采样和 classifier-free guidance 技术,Ovis-Image 能够在 1024x1024 分辨率下生成自然、连贯、细节丰富的图像,支持写实、赛博朋克、动漫、科幻等多种风格。 在线运行: https://go.openbayes.com/KFcQO 项目示例 3. vLLM+Open WebUI 部署 GLM-4.7-Flash GLM-4.7-Flash 是智谱 AI 推出的轻量化 MoE 推理模型,兼顾高性能与高吞吐,原生支持思考链(CoT)、工具调用与 Agent 能力。它采用 Mixture of Experts(MoE)架构,通过稀疏激活机制,在保持大模型表达能力的同时,大幅降低单次推理的计算成本。 在线运行: https://go.openbayes.com/ItzzP 4. Step3-VL-10B:多模态视觉理解与图文对话 Step3-VL-10B 由 StepFun 团队发布,是一款面向多模态理解与复杂推理任务的开源视觉-语言基础模型。STEP3-VL-10B 旨在在参数规模受限的前提下,重新定义多模态模型在效率、推理能力与视觉理解质量之间的平衡。尽管参数规模紧凑,该模型在视觉感知、复杂推理以及人类指令对齐等方面表现出色,在多项基准测试中持续优于同规模模型,并在部分任务上可与参数规模大 10–20 倍的模型相竞争。 在线运行: https://go.openbayes.com/LN9xD 5. TurboDiffusion:图像与文本驱动视频生成系统 TurboDiffusion是由清华大学团队开发的高效视频扩散生成系统。该项目基于 Wan2.1 架构进行高阶蒸馏,旨在解决大规模视频模型推理速度慢、计算资源消耗大的痛点,实现了极少步数下的高质量视频生成。该系统基于 rCM 蒸馏技术,将 14B 模型 5 秒视频的生成耗时从分钟级压缩至 2-10 秒,实现百倍以上的效率飞跃。支持 720P T2V 与 I2V 任务,在极速生成下依然保持 SOTA 级的视觉连贯性与画质。 在线运行: https://go.openbayes.com/8ufT5 6. LightOnOCR-2-1B 轻量级高性能端到端 OCR 模型 LightOnOCR-2-1B 是由 LightOn AI 于 2026 年 1 月推出的最新一代端到端视觉语言模型(OCR)。作为 LightOnOCR 系列中的旗舰级版本,它在一个紧凑的架构中统一了文档理解与文本生成功能,拥有 10 亿参数(1B),能够在消费级显卡(约 6GB 显存)上运行。该模型采用 Vision-Language Transformer 架构,并引入了 RLVR 训练技术,实现了极高的识别准确率与推理速度,专为需要处理复杂文档、手写体及 LaTeX 公式的应用场景设计。 在线运行: https://go.openbayes.com/uxY9d 7. Personaplex-7B-v1:实时对话与角色定制语音接口 PersonaPlex-7B-v1 是 NVIDIA 于 2026 年 1 月发布的 70 亿参数多模态个性化对话模型,面向实时语音/文本交互、长效角色一致性模拟与多模态感知任务。本 Notebook 基于该模型构建,旨在提供一个支持毫秒级响应的沉浸式角色扮演与多模态交互演示系统。 在线运行: https://go.openbayes.com/aM5GU

项目示例

项目示例
项目示例
项目示例
项目示例
不管你是 Linux 后端开发、C/C++ 编程,还是运维面试,系统调用和库函数都是大家绕不开的核心知识点。小编发现很多新手(也包括工作多年的)写代码时随手调用的函数(比如 printf、open、fopen),大部分小伙伴们压根就不关心这些函数哪些是系统调用、哪些是库函数,甚至误以为二者是同一概念,结果面试被问倒、排查问题找不到方向。 确实,从咱们普通人的角度来看,系统调用和库函数似乎没有什么区别,它们都是以 C 函数的形式出现,并且两者都为应用程序提供服务。但从实现者角度来看,它们之间是有根本的区别。那么,它们之间到底有哪些不同呢?在说明之前,先简单了解以下系统调用和库函数。 系统调用是操作系统为应用程序提供的一组特殊接口,是用户空间与内核空间之间的关键桥梁。在计算机系统中,内核负责管理硬件资源、调度任务和维护系统安全等核心功能,运行在特权级较高的内核态;而应用程序则运行在用户态,对硬件和系统资源的访问受到严格限制。系统调用充当“翻译官”,允许应用程序通过它向内核发出请求,执行特定操作,并将处理结果返回给应用程序。 咱们举个经常用的典型场景:当应用程序需要读取文件数据时,会直接调用 read 这一系统调用。应用程序会将文件描述符、数据接收缓冲区、预期读取的字节数等关键参数传入 read,随后通过系统调用触发 CPU 特权级切换,从用户态进入内核态。内核会依据传入的参数定位目标文件,从磁盘介质中读取对应数据,并将数据拷贝至应用程序指定的用户态缓冲区,最终把实际读取的字节数作为返回值,传递回用户态的应用程序。 常见系统调用很多,例如:open, close, read, write, ioctl,fork,clone,exit,getpid,access,chdir,chmod,stat,brk,mmap 等,需要包含 unistd.h 等头文件。 答:应用程序发起调用时,会触发内核陷入机制。以 x86 架构为例,通过 int 0x80 这类陷入指令,CPU 从权限受限的用户态,切换至拥有最高权限的内核态。内核会根据系统调用号,在系统调用表中找到对应的内核函数并执行,比如读取文件时就会调用磁盘 IO 相关的内核逻辑。操作完成后,内核将结果返回应用程序,CPU 再切回用户态,程序继续向下执行。 库函数用于提供用户态服务。它可能调用封装了一个或几个不同的系统调用(printf 调用 write),也可能直接提供用户态服务(atoi 不调用任何系统调用)。 小编把库函数理解为是预编译的程序代码,存储在共享库或静态库中,用于执行常规编程任务。 常见库函数有:printf,scanf,fopen,fclose,fgetc,fgets,fprintf,fsacnf,fputc,calloc,free,malloc,realloc,strcat,strchr,strcmp,strcpy,strlen,strstr 等,需要包含 stdio.h,string.h,alloc.h,stdlib.h 等头文件。 因为系统调用属于内核,和库函数不属于内核。因此,如果当用户态进程调用一个系统调用时,CPU 需要将其切换到内核态,并执行一个内核函数。 在内核中,整数或 0 表示系统调用成功结束,而负数表示一个出错条件。而出错时,内核不会将其设置在 errno,而是由库函数从系统调用返回后对其进行设置或使用。 判断一个系统是否符合 POSIX 标准,关键在于它是否提供了一组适当的应用程序接口,而与这些函数的具体实现无关。因此,从移植性角度来看,使用库函数的移植性优于直接使用系统调用。 许多库函数会调用系统调用,但直接调用系统调用的开销较大,主要是因为上下文切换的代价。在用户态和内核态之间切换时,需要保存和恢复 CPU 状态,这消耗时间。库函数通过使用双缓冲技术和缓冲机制来降低这种开销,以文件读写为例,调用库函数可以显著减少系统调用次数,从而提高性能。直接调用系统调用时,每次都需进行上下文切换,导致性能损失。因此,库函数的开销通常小于直接调用系统调用,同时它们也能对系统调用进行优化,提升整体效率。 弄个表格,方便记忆和对比:
什么是系统调用?
那系统调用的具体工作流程什么呢?
什么是库函数?

它俩之间区别:
什么时候使用系统调用?
什么时候使用库函数?
总结
背景: 2 年 Java 经验,无经济压力。年前因前司拖欠工资离职,入职新公司一周。 现在前司补发了薪资(1 个月),老板也支持我回去,薪资持平(比新公司低 20%)。
1. 新公司(目前在职)
2. 前司(回头草)
纠结: 目前不缺钱。 留新公司:钱多点但每天上班如上坟(通勤累+技术栈不喜+电脑卡)。 回前司:生活质量极高,但怕再次欠薪倒闭,面临二次找工作。新公司也是自己负责一个项目(包含前端和产品设计),前司有前端、产品,后端也只有我一人。项目都是同一类型项目。
求建议,是为了生活质量回前司苟着,还是在新公司硬抗?
在数据处理和分析的过程中,经常需要将不同格式的数据进行转换。Excel 文件是数据存储和操作中非常常见的格式,而 TXT 文件凭借其简单的文本格式,常用于数据共享和处理。本文将介绍如何使用 Python 和 Spire.XLS 库将 Excel 导出为 TXT 文件。 要实现这个功能,我们需要确保已安装 Spire.XLS for Python 库。如果尚未安装,可以通过如下命令进行安装: 此库提供了丰富的 Excel 文件处理功能,可以方便地进行读取、编辑和保存操作。 下面是一个完整的示例代码,展示了如何将 Excel 文件导出为 TXT 文件: 环境配置 我们首先导入必要的模块,为后续文件操作做准备。通过 创建 Workbook 对象 使用 加载 Excel 文件 通过 获取工作表 在 Excel 文件中,可以有多个工作表。这里我们通过 导出为 TXT 文件 使用 释放资源 最后,使用 通过以上步骤,我们成功使用 Python 将 Excel 文件导出为 TXT 格式。Spire.XLS 提供了简洁的方法,使得操作 Excel 文件变得极为简单,尤其适合于需要批量处理或自动化脚本的场景。 对于更复杂的需求,如需处理多个工作表或对数据进行格式化、筛选等,可以进一步改善代码逻辑和添加相应功能。此外,Spire.XLS 还支持对 Excel 文件的其他灵活操作,如修改单元格内容、添加图表等,用户可以根据需求更深入地探索该库的功能。环境准备
pip install Spire.XLS示例代码
import os
import sys
# 获取当前文件路径
curPath = os.path.abspath(os.path.dirname(__file__))
rootPath = os.path.split(curPath)[0]
sys.path.append(rootPath)
from spire.xls import *
from spire.xls.common import *
# 输入和输出文件的路径
inputFile = "Input.xlsx"
outputFile = "output.txt"
# 创建Workbook对象
workbook = Workbook()
# 加载一个Excel文件
workbook.LoadFromFile(inputFile)
# 获取第一张工作表
sheet = workbook.Worksheets[0]
# 将工作表保存为TXT文件
sheet.SaveToFile(outputFile, " ", Encoding.get_UTF8())
workbook.Dispose()代码解析
os 和 sys 模块,我们获取了当前文件的路径,以便进行文件导入和导出。Workbook() 类创建一个新的工作簿对象。这是操作 Excel 文件的基础。LoadFromFile 方法,我们加载了指定的 Excel 文件。在这个示例中,文件名为 "测试.xlsx"。workbook.Worksheets[0] 获取第一个工作表。索引从 0 开始,因此 [0] 表示第一张工作表。SaveToFile 方法将工作表导出为 TXT 文件。在此参数中,我们设置了输出文件名以及列分隔符(在这里使用空格 " ")。同时我们还指定了文件编码为 UTF-8,确保支持多种语言字符的正确显示。Dispose() 方法释放工作簿所占用的资源,确保程序的稳定性。小结
在当今工程建设领域,数字化转型浪潮汹涌,工程资料软件成为提升管理效率与质量的关键工具。市面上涌现出众多优秀的工程资料软件厂商,它们凭借卓越的产品性能与服务,推动着行业的进步。
创新技术驱动:筑业软件
筑业软件在工程资料管理领域深耕多年,以技术创新为核心竞争力。其软件具备强大的资料编制功能,依据各地不同的工程建设标准与规范,内置海量精准的资料模板,涵盖建筑、市政、水利等多个领域。通过智能识别与自动填充技术,大大减少工程人员手动录入的工作量,提高资料编制的准确性与效率。例如,在建筑项目资料整理过程中,软件能根据施工工序自动关联相应的资料表格,并填充部分常规信息,节省大量时间。同时,筑业软件注重用户体验,界面设计简洁直观,即使新手也能快速上手。
全面解决方案:品茗软件
品茗软件以提供全面的工程资料管理解决方案著称。除了基础的资料编制功能外,还涵盖资料审核、数据统计分析以及协同管理等模块。在资料审核方面,依据行业规范和标准,对工程资料进行智能检查,精准指出存在的问题与错误,帮助工程人员提升资料质量。数据统计分析功能则能从海量资料中提取关键信息,为项目决策提供有力支持。例如,通过分析质量验收资料,可直观了解项目各阶段的质量状况,及时发现潜在风险。在协同管理方面,品茗软件支持多部门、多参与方实时共享资料,实现高效协作,确保项目顺利推进。
行业深耕与定制化:恒智天成
恒智天成软件长期专注于工程资料软件的研发与推广,对行业需求有着深刻的理解。其产品不仅满足通用的工程资料管理需求,还能针对不同行业、不同规模的企业提供定制化解决方案。例如,针对大型建筑企业,可定制符合企业内部管理流程与标准的资料管理系统,实现资料的规范化、标准化管理。恒智天成软件注重技术与服务的结合,拥有专业的技术支持团队,为用户提供及时、高效的售后服务,确保软件在使用过程中遇到的问题能得到快速解决。
市面上这些优秀的工程资料软件厂商,通过不断创新与完善产品功能,为工程建设行业提供了强大的数字化助力。它们在提升工程资料管理水平的同时,也推动着整个行业向更加高效、智能的方向发展。工程企业在选择软件厂商时,应根据自身实际需求,综合考量产品功能、服务质量以及性价比等因素,选择最适合的软件产品,为项目的成功实施奠定坚实基础。
在搭建量化回测与策略验证体系时,美股历史数据几乎是绕不开的环节。无论是模型训练、指标验证,还是实时监控,数据结构能否统一、时间序列是否连续,都会直接影响分析的可靠性。 近期在协助某投顾团队整理量化研究流程时,我们尝试将历史与实时数据接入统一到同一数据结构中,以减少维护复杂度,也为长期分析提供可复用的底层框架。下面结合 [AllTick API]的接入实践,总结过程中的一些要点。 许多投研系统初期都能快速跑通,但在长期迭代中容易出现以下问题: 这些看似琐碎的结构问题,往往才是限制系统长期稳定性的核心。对于需要频繁回测与高频更新的投顾分析框架,稳定的数据结构比“拉到数据”本身更重要。 以 AllTick 的美股历史数据接口为例,其支持按股票、市场与时间区间拉取K线数据,并采用常规 HTTP 请求方式。主要参数包括: 响应数据则包含标准化字段:时间戳、开盘价、最高价、最低价、收盘价和成交量。 经过统一处理后,数据结构清晰、索引友好,可直接用于可视化或后续统计。 该 API 的一大优势在于:历史数据与实时数据字段设计保持一致。 这种方式减少了重复设计表结构的需求,方便复用同一份计算逻辑,也让策略运行更稳定。 对于需要长时间运行的系统而言,这种“一体化结构”能有效降低后期维护成本。 在实际对接过程中,有几点经验值得记录: 这些细节多数接口文档会提及,但实际落地还需结合业务场景与分析目标灵活调整。 整体来看,美股历史数据 API 本身不算复杂,真正影响使用体验的,是结构清晰度与历史数据和实时数据的衔接性。 当数据打好底层“地基”后,后续的策略优化、模型回测、交易执行都能以更低成本迭代。这类结构稳定、接口统一的方案,也逐渐成为投顾团队构建自主投研平台的基础。1. 背景与开发痛点
2. 历史数据接口的基础结构
symbol:证券代码(例如 AAPL)market:市场标识(US)interval:周期(如 1min、1day)start_time / end_time:时间范围
字段返回顺序规整,易于转为 Pandas DataFrame 做进一步处理。import requests
import pandas as pd
url = "https://apis.alltick.co/v1/market/history"
params = {
"symbol": "AAPL",
"market": "US",
"interval": "1day",
"start_time": "2026-01-01",
"end_time": "2026-03-01"
}
headers = {
"Authorization": "Bearer YOUR_API_KEY"
}
response = requests.get(url, params=params, headers=headers).json()
if response.get("code") != 0:
raise ValueError("请求失败", response)
data = response["data"]
3. 历史与实时数据结构统一
这意味着,你可以用历史数据初始化 DataFrame,再订阅实时推送,通过 WebSocket 实时补充到同一数据结构。import websocket
import json
def on_message(ws, message):
msg = json.loads(message)
new_df = pd.DataFrame([msg])
new_df["datetime"] = pd.to_datetime(new_df["timestamp"], unit="s")
new_df.set_index("datetime", inplace=True)
global df
df = pd.concat([df, new_df])
print(df.tail())
def on_open(ws):
ws.send(json.dumps({
"action": "subscribe",
"symbol": "AAPL",
"market": "US",
"interval": "1min"
}))
ws = websocket.WebSocketApp(
"wss://apis.alltick.co/realtime",
on_message=on_message,
on_open=on_open
)
ws.run_forever()
4. 数据处理中的几个注意点
5. 总结与延伸思考
在鸿蒙生态逐步向 PC、平板、车机、IoT 全场景扩展的背景下,越来越多开发者开始关注一个现实问题: Flutter 作为成熟的跨端 UI 框架,在适配 HarmonyOS 6.0 后,已经具备了完整的工程化能力: 本文我们不讲复杂架构,不上状态管理,不搞花哨组件,只做一件事: 目标非常明确: 在真实业务中,列表几乎是出现频率最高的 UI 结构: 可以说: 而在 HarmonyOS 场景下,列表还有一个额外价值: 都要求列表组件 性能稳定 + 行为可控 + 样式一致。 所以我们从最基础的 在鸿蒙 PC 上运行 Flutter 的本质结构是: 你写的: 最终会被 Flutter Engine 转换为: 这意味着: 我们这篇文章的核心只有一个函数: 这个函数本质上解决了四件事: 我们逐层拆解。 这是一个最简单的 静态数据源,但它抽象出了真实业务中最重要的概念: 真实业务中你会换成: 但 ListView 的用法完全不变。 这一层在鸿蒙适配中非常关键。 因为鸿蒙设计语言(Harmony Design)强调: 所以标准写法是: 这样才能: 这是 Flutter 中 最推荐用于业务列表的写法。 相比: 这一行非常“专业”。 这是鸿蒙跨端开发的关键原则: 因为: 这一行: 代表: 这在设计系统里叫: Semantic Color(语义色) 而不是 Hard Code。 默认自带: 在鸿蒙 PC 场景下尤其重要: 你什么都不用写。 这是非常典型的 嵌套列表写法。 含义是: 通常用于: 在鸿蒙大屏页面中,这是最常见结构: 在 HarmonyOS 6.0 PC 上运行后效果是: 视觉风格非常接近: 这就是 “鸿蒙感”UI 的核心来源。 通过这个最简单的例子,其实已经体现了三条非常重要的工程原则: 它不是 Demo 框架,而是: 任何复杂页面: 最终拆解后都是: 不用 Theme = 一定翻车: 这行代码价值极高: 它代表的是: 这是专业工程师和 Demo 工程师最大的区别。 通过 HarmoList 这个极简示例,我们完成了: 这段代码虽然只有几十行,但它背后代表的是: 后续无论你要做: 所有复杂 UI,90% 都是从这个结构进化出来的。 一句话总结: 通过 HarmoList 这个最基础的示例可以看到,Flutter 在 HarmonyOS 6.0 上的开发体验已经非常成熟,其 UI 构建模式与传统 Android / iOS 几乎完全一致,但在鸿蒙全场景设备体系下具备更强的延展性。从工程视角来看,一个看似简单的 ListView.separated,实际上已经完整体现了跨端开发中最关键的几个能力:数据驱动渲染、语义化主题适配、组件级 UI 复用以及面向大屏与多输入方式的交互支持。 更重要的是,这种写法并不是 Demo 级技巧,而是可以直接复用于真实业务系统的“标准工程模板”。无论是设置页、管理后台,还是设备控制面板,本质上都可以从这一基础结构演进扩展。可以说,真正掌握 Flutter × HarmonyOS 的第一步,并不是复杂架构设计,而是把这种最基础的列表组件写得足够规范、足够工程化、足够可复用。前言
如何用最低成本,构建可同时运行在鸿蒙与多平台的应用?
一次开发,多端部署,天然适合鸿蒙“全场景设备”的产品理念。用 Flutter 在 HarmonyOS 6.0 上,实现一个最基础、最标准、最工程化的列表页面。
构建一个带分隔线的基础 ListView,并完全理解每一行代码。
背景
学会 ListView,等于掌握 Flutter UI 的 40%。
ListView.separated 开始,是最工程化、最合理的学习路径。Flutter × HarmonyOS 6.0 跨端开发介绍
架构关系
Flutter Widget Tree
↓
Flutter Engine
↓
Skia / Impeller 渲染
↓
HarmonyOS 图形系统 (ArkUI / Surface)ListView(
children: [...]
)Flutter 在鸿蒙上是“真原生渲染”,不是套壳。

开发核心代码

/// 构建基础列表布局
/// 展示最简单的 ListView 实现,包含分隔线和基本的 ListTile
Widget _buildBasicList(ThemeData theme) {
final items = ['项目 1', '项目 2', '项目 3', '项目 4', '项目 5'];
return Container(
decoration: BoxDecoration(
borderRadius: BorderRadius.circular(12),
color: theme.colorScheme.surfaceContainerHighest,
),
child: ListView.separated(
shrinkWrap: true,
physics: const NeverScrollableScrollPhysics(),
itemCount: items.length,
separatorBuilder: (context, index) => Divider(
height: 1,
color: theme.colorScheme.onSurface.withValues(alpha: 0.1),
),
itemBuilder: (context, index) {
return ListTile(
title: Text(items[index]),
onTap: () {},
);
},
),
);
}一、数据源:items 列表
final items = ['项目 1', '项目 2', '项目 3', '项目 4', '项目 5'];ListView 永远只关心一个东西:itemCount + itemBuilder

二、外层容器:Container + BoxDecoration
return Container(
decoration: BoxDecoration(
borderRadius: BorderRadius.circular(12),
color: theme.colorScheme.surfaceContainerHighest,
),1. 为什么不用直接 ListView?
列表外一定包一层“语义容器”
三、ListView.separated:工程级推荐写法
ListView.separated(
itemCount: items.length,
separatorBuilder: ...
itemBuilder: ...
)ListView(children: [])ListView.builder(...)separated 的优势是:特性 ListView.separated 自动分隔线 ✅ 懒加载 ✅ 性能友好 ✅ UI 结构清晰 ✅ 适合复杂业务 ✅ 四、分隔线:Divider 的工程含义
separatorBuilder: (context, index) => Divider(
height: 1,
color: theme.colorScheme.onSurface.withValues(alpha: 0.1),
),1. 不写死颜色,而用 Theme
永远不要写死颜色,永远使用 Theme。
theme.colorScheme.onSurface.withValues(alpha: 0.1)使用当前主题下“文字颜色”的 10% 透明度作为分割线
五、ListTile:最标准的列表行组件
return ListTile(
title: Text(items[index]),
onTap: () {},
);ListTile 是 Flutter 官方提供的:企业级标准列表行组件

六、两个关键参数:shrinkWrap + physics
shrinkWrap: true,
physics: const NeverScrollableScrollPhysics(),Scaffold
└─ SingleChildScrollView
└─ Column
├─ Header
├─ Card
│ └─ ListView (shrinkWrap)
├─ Footer实际运行效果(HarmoList)
系统设置 / 文件管理 / 设备管理界面
心得(工程经验)
1. Flutter 在鸿蒙不是玩具,是工程级方案
2. ListView 是所有复杂页面的基础单元
Header + ListView + Footer
3. Theme 是鸿蒙跨端的灵魂
theme.colorScheme.surfaceContainerHighest“让系统自己决定颜色,而不是我来决定。”
总结
ListView.separated 的真实价值Flutter × HarmonyOS 跨端开发的最小可行工程模型(MVP)
真正的跨端工程能力,不是炫技组件,而是把最简单的列表写到“专业级”。

作者:赵雁松,周岩珏,李志强,周永康,刘军 在企业数字化转型的浪潮中,我们发现很多公司依然面临着“数据深渊”:业务人员想看数据,却受限于复杂的 SQL 语法;开发者虽然尝试了 Text-to-SQL,但生成的代码逻辑常有偏差,同时也无法应对复杂的统计分析、根因定位等场景。 DataAgent 应运而生。 这不是简单的指令翻译器,而是我们基于 Spring AI Alibaba 生态构建的一位“虚拟 AI 数据分析师”。它能够像专家一样思考、规划、纠错,并最终输出一份带图表、带逻辑、带深度洞察的行业级报告。 从架构上,DataAgent 是一款基于 Spring AI Alibaba 生态构建的、面向企业级复杂场景的“虚拟 AI 数据分析师”。它通过 Spring AI Alibaba Graph & Agent Framework 构建了一套具备自我规划、工具调用、反思纠错及人类干预能力的数据智能体(Agent),通过 graph、multi-agent 模式将确定性流程与模型推理结合在一起,搭建了一套兼具流程确定性与智能化的数据智能体产品。 我们不只是在写代码,而是在解决企业数据决策中的“深水区”难题。以下是 DataAgent 攻克研发痛点、实现架构突破的几大核心战役。 解决方案: 解决方案: 解决方案: 解决方案: 解决方案: 解决方案: 解决方案: 解决方案: 解决方案: 解决方案: DataAgent 的核心价值在于,它不仅仅是完成了一次查询,而是将“数据处理的工程化”与“大模型的推理能力”深度结合。结合 Spring AI Alibaba 的 Graph 编排与 Agentic 推理能力,DataAgent 将确定性流程与模型推理结合在一起,将原本碎片化的分析过程,转化为了兼具流程确定性与智能化的数据智能体。 未来,数据不再是冷冰冰的行列,而是每一位业务决策者都能随手调用的“智库”。 想了解更多关于 DataAgent 的技术实现细节? 欢迎搜索钉钉群,群号: 154405001431,加入我们的开发者讨论群,共同探索 AI 的无限可能!前言:AI 数据分析的“最后一公里”
降维打击:为什么 DateAgent 不止是 Text-to-SQL?

整体架构

核心黑科技:DateAgent 是如何解决企业难题的?
4.1 人类反馈机制 (Human-In-The-Loop)
humanFeedback=true(GraphController → GraphServiceImpl)。agent.human_review_enabled 用于保存配置,运行时以请求参数为准。PlanExecutorNode 检测 HUMAN_REVIEW_ENABLED,转入 HumanFeedbackNode。

4.2 Prompt 动态配置与自动优
/api/prompt-config/*,数据表 user_prompt_config。agentId 绑定或全局配置(agentId 为空)。report-generator、planner、sql-generator、python-generator、rewrite。ReportGeneratorNode 拉取启用配置(按 priority 与 display_order 排序),通过 PromptHelper.buildReportGeneratorPromptWithOptimization 拼接“优化要求”。

4.3 深度 RAG 与混合检索增强
EvidenceRecallNode 将多轮上下文与用户问题组装为检索指令,调用 LLM 生成 standaloneQuery,避免上下文遗漏与歧义。AgentVectorStoreService 作为统一入口,默认走向量检索;开启混合检索后走 AbstractHybridRetrievalStrategy,将“向量召回 + 关键词召回”进行融合。(用户需要提供混合检索实现。当前默认只支持 es)DynamicFilterService 生成基于智能体与知识类型的过滤条件,限制检索范围,避免跨智能体串库。business_knowledge)+ 智能体知识(agent_knowledge)两类,按 agentId/type 元数据过滤后合并为 evidence,注入后续 prompt。spring.ai.alibaba.data-agent.vector-store.enable-hybrid-search 控制是否开启混合检索;相似度阈值与 TopK 通过向量库配置项控制(如 top-k、similarity-threshold)。EvidenceRecallNode 输出内容进入后续规划于 SQL 生成阶段。

4.4 容器化 Python 执行引擎
PythonGenerateNode 根据计划与 SQL 结果生成 Python。PythonExecuteNode 使用 CodePoolExecutorService(Docker/Local/AI 模拟)。spring.ai.alibaba.data-agent.code-executor.*(默认 Docker 镜像 continuumio/anaconda3:latest)。PYTHON_EXECUTE_NODE_OUTPUT,PythonAnalyzeNode 汇总后写入 SQL_EXECUTE_NODE_OUTPUT,用于最终报告。

4.5 流式输出 (SSE) 与多轮对话管理
GraphController SSE + GraphServiceImpl 流式处理。TextType 在流中标记 SQL/JSON/HTML/Markdown,前端据此渲染。MultiTurnContextManager 记录“用户问题+规划结果”,注入到后续请求。spring.ai.alibaba.data-agent.llm-service-type 支持 STREAM/BLOCK。

4.6 MCP 服务器发布与多模型调度
McpServerService 提供 NL2SQL 与 Agent 列表工具,使用 Mcp Server Boot Starter。ModelConfig 配置模型,AiModelRegistry 缓存当前 Chat/Embedding 模型并支持热切换(同一时间每类仅一个激活模型)。nl2SqlToolCallback、listAgentsToolCallback。

4.7 多数据源接入
datasource,智能体绑定写入 agent_datasource,选表写入 agent_datasource_tables,逻辑外键写入 logical_relation。BizDataSourceTypeEnum 定义数据源类型;对应的 Accessor + DBConnectionPool 负责不同数据库协议与方言的访问。AgentDatasourceController 触发初始化,SchemaService 通过 AccessorFactory 拉取表/列/外键并写入向量库。DatabaseUtil 从当前智能体获取激活数据源,动态选择 Accessor 执行 SQL。AgentDatasourceService.toggleDatasourceForAgent)。

4.8 报告生成与摘要建议
ReportGeneratorNode 读取计划、SQL/Python 结果与摘要建议(summary_and_recommendations)。plainReport=true 输出 Markdown(简洁报告)。
4.9 NL2SQL 转换, 语义模型,逻辑外键引擎
SqlGenerateNode 生成后接 SemanticConsistencyNode 检查语义一致性。SqlExecuteNode 捕获执行错误并反馈给 Graph 状态机,触发重定向至重写节点进行纠错。4.10 API Key 与权限管理
AgentController 支持生成、重置、删除与启用/禁用 API Key。agent.api_key 与 agent.api_key_enabled。X-API-Key。spring.ai.alibaba.data-agent.api-key.enabled=true。

结语:让数据价值触手可及
相关资源:
我做了一款基于小模型的拍照识别物品的 APP ,先录入物品的特征,可以从四个角度各拍一张照片,让模型能记住这个物品的特征。
然后点击 [识别特征] ,对着要识别的物品拍一张照片,点击识别,即可根据相似度进行查询。相似度的阈值可以在设置里面调整。
项目代码地址: https://gitee.com/mktime/object-detect


世界范围内数字化进程正在不断加快,全球化与数字化开始深融合。在此等时代背景下,大型企业的业务版图正趋于多元化,突破单边限制。域名也是如此,从独立的域名,逐渐扩展至集团官网、独立子品牌、区域业务站点、品牌电商等。随着企业规模的不断增大和业务版图的扩充,数字资产逐渐分布至企业旗下数十甚至上百个域名。面对数量众多的网站,管理难度呈现指数级增长。单以数字证书而论,从申请到部署,从监控到续期,数百个域名的管理难度可想而知,稍有疏漏便可能引发连锁效应,让企业面临漏洞威胁与业务中断风险。JoySSL市场部负责人曾多次提到,单域名证书的管理模式已不适合大型企业的复杂架构,不仅效率低下,还会造成企业额外的成本支出。多域名SSL证书则是化繁为简,实现企业运维管理简化、优化成本结构的战略工具,是大型企业拥抱数字生态的基础。 多对一高效管理凸显证书核心优势 拥有多域名的大型企业,SSL证书通常缺乏统一管理视角,易造成资产无法统筹、证书过期以及安全策略不一致等诸多问题。多域名SSL证书可实现集中式管理,摒弃“证书分散现象”,打造统一的管理体系,对所有受保护的域名实现统一监控、快速续约与策略管理,告别碎片化管理模式。 多域名SSL证书可完成高效的成本管理,优化总体拥有成本,节约资源与人力,减少了证书审批、部署与日常运维的成本消耗,使企业团队能够专注于战略性的任务。 超越技术 赋能大型企业开展业务 部署多域名SSL证书,已成为企业集团化与多品牌战略的安全统一保障,为各子品牌网站提供统一且可信的高级安全标识,增强市场对品牌专业形象的认可,维护企业整体声誉。面对严格的审计标准,通过多域名证书,企业可向审计机构展示全面的安全管理措施,从而显著简化合规流程。 多域名证书支持收购整合与业务创新的快速反应能力,从而实现安全而高效的资源整合。此外,证书可提供标准化且高安全性的保护,确保生态伙伴服务的稳定性。 多域名SSL证书优化管理解决方案 OV及EV证书可确保企业在身份验证方面达到最高标准,提升公众对企业可信度的感知,提升品牌价值。此外,面对复杂的网络环境,JoySSL自动化证书管理平台能够实现证书与域名的高效识别、批量化部署、智能化监控预警,以及全流程的自动续期功能,使证书管理无缝嵌入企业数字化生态系统,保障企业数字基础设施的安全稳定运行。 以简约之道主动构建网络安全架构 多域名证书以化繁为简之道,配合专业的管理方案,推动企业从被动应对转为主动构建安全架构,通过高度集成的系统,使众多域名协同运行,提升整体防御能力。不仅是技术升级,更是企业管理理念的深刻蜕变。


近一周行情呈现出一种无序混沌的状态,硬科技与资源股回撤跌的比较狠,幸好没碰。午盘后拉了消费板块,我手里的消费电子或许能跟着喝口汤。
我的持仓:2 个医药+1 个医疗器械+2 消费电子+1 自动驾驶+1 美容护理
今天账户+3%跳水到+1%,还行,满足了。

Cloudflare发表了一篇博客文章,展示了在 Workers 上运行的无服务器 Matrix 家庭服务器,引发了关于 AI 生成代码和技术准确性的争论。虽然 Matrix.org 对 Cloudflare 的关注表示欢迎,但联合创始人 Matthew Hodgson指出,这篇文章“严重夸大了项目的范围”,强调了功能性 Matrix 服务器所需的核心功能缺失。 这篇博客声称已经在 Cloudflare 的边缘平台上构建了一个完整的 Matrix 家庭服务器,用 Cloudflare 的 D1 和 Durable Objects 等原语取代了 PostgreSQL 和 Redis。GitHub存储库最初将自己描述为“生产级”,并有一个“部署到 Cloudflare”的按钮。 Hodgson 在 Matrix.org 网站上的回应很圆滑,但很明确: 代码还没有实现 Matrix 的任何核心特性,这些特性允许你安全地进行联邦,因此还没有构成一个功能性的 Matrix 服务器,更不用说生产级服务器了。 他指出,该实现没有将房间建模为复制的事件图,没有检查权限,也没有维护权限级别——将其比作“忽略权限的文件系统,或者不实现共识机制的区块链。 代码库在关键部分包含了 TODO 注释,例如 TODO: 在身份验证逻辑中的检查授权。状态解析(Matrix 用于处理跨分布式房间的冲突事件的算法)没有实现。尽管声称支持“完整的 Matrix 端到端加密堆栈”,但端到端加密验证似乎不完整。 Hacker News上的社区反应表明,有迹象表明 AI 提供了大量的帮助。评论者指出: “我们做了 X”的博客文章最终变成了“我们做了 X 的一部分演示”,这在整个行业中已经过时了。解决方法很无聊:你只需要明确你所创造的内容。”另一位评论道:“基础设施公司的技术博客过去有两个目的:展示专业知识并建立信任。当帖子开始过度承诺时,你就失去了这两者。 Matrix 的开发人员 Jade Ellis 在Mastodon上写道,存储库在自述中显示了“有错位的 ASCII 图”。待办事项分散在各处。这表明代码带有未经彻底审查的 AI 生成输出的特征。 Hodgson 承认使用 LLM 来制作不熟悉的协议原型是一种挑战: 如果你正在使用 LLM 来原型化一个不熟悉的协议的实现,那么你可能不知道在哪里检查代理是否夸大了事实。 他表达了对作者的同情,同时注意到对“过度热情地使用 LLM,特别是如果他们自己投入了大量的时间和精力来理解和构建功能 Matrix 实现。 Cloudflare 在发布大约六小时后更新了这篇博文,并添加了一个免责声明,称其描述了一个概念验证和一个个人项目。然而,更新没有撤回正文中的特定技术声明。 尽管有这些批评,Hodgson 还是强调了这个演示“成功地说明了 Cloudflare Workers 是如何工作的,而且这些代码肯定可以作为未来工作服务器的基础。”他指出,Matrix 和 Cloudflare 在其他方面也有合作,包括使用 Cloudflare Calls 作为 MatrixRTC 后端的概念验证,Cloudflare 的 CDN 多年来一直保护着 matrix.org 的流量。 在无服务器基础设施上运行 Matrix 的技术方法仍然是可行的。这篇文章描述了用 D1 (SQLite)取代 PostgreSQL,用 KV 存储取代 Redis,并使用持久对象进行房间状态管理。这些架构选择可以在正确实现 Matrix 的核心联合和安全特性的情况下工作。 对于考虑使用 AI 辅助开发的开发者来说,这一事件凸显了未经审查的 AI 输出的风险。夸大 AI 生成实现的模式已成为技术博客中反复出现的问题,引发了对基础设施公司审查流程的质疑。 Hodgson 总结说,Matrix 基金会依靠会员费来资助规范工作、信任和安全工具以及生态系统支持。虽然组织成员在过去的一年里翻了一番,但基金会的财务状况还无法维持下去。他表示希望像 Cloudflare 这样受益于 Matrix 的公司可以考虑加入为会员。 Cloudflare 的博客文章和更新后的免责声明仍然有效。 原文链接: https://www.infoq.com/news/2026/02/cloudflare-matrix-homeserver-ai/
Cursor 近日公布了 Agent Trace 开放规范草案,目标是解决 AI 生成代码在软件项目中的归属与标注问题。该提案以 RFC 形式发布,定义了一种厂商中立的格式,用于在版本控制系统中记录 AI 与人类协作产生的代码贡献。 基于其在 AI 辅助编程工具方面的实践经验,Cursor 发现,代码变更过程中对上下文的追踪能力仍然明显不足。以常见的 git blame 等工具为例,它们只能显示某一行代码“何时被修改”,却无法说明这次修改是由人类完成、由 AI 完成,还是二者协作的结果。Agent Trace 正是为了解决这一缺口,试图以结构化、可互操作的方式捕获这些关键信息。 从技术角度看,Agent Trace 是一套数据规范,使用基于 JSON 的 trace record(追踪记录)来关联具体的代码范围,以及背后的对话过程和参与者。代码贡献可以在文件级或行级进行追踪,按会话进行分组,并被标注为“人类”、“AI”、“混合”或“未知”。该模式还支持为 AI 生成的代码附加可选的模型标识,从而在不绑定具体厂商的前提下,实现更精确的归属记录。 在设计上,这一规范刻意保持了对存储方式的“中立性”。Cursor 并未规定追踪记录必须存放在哪里,开发者可以根据自身需求,将其保存为普通文件、git notes、数据库记录,或采用其他机制。Agent Trace 同时支持多种版本控制系统,包括 Git、Jujutsu 和 Mercurial,并引入了可选的内容哈希,用于在代码被移动或重构后,依然能够追踪其原始归属。 可扩展性是 Agent Trace 的核心设计目标之一。各厂商可以通过命名空间键(namespaced keys)附加额外的元数据,而不会破坏规范的兼容性。同时,该规范刻意回避了对 UI 形式、代码所有权语义的定义,也不试图评估代码质量或追溯训练数据来源,而是将关注点严格限定在“代码归属”和“可追溯性”本身。 Cursor 还提供了一份参考实现,展示 AI 编程代理如何在文件发生变化时,自动捕获并生成追踪记录。尽管示例基于 Cursor 自家的工具链,但其设计模式被明确定位为可复用方案,适用于其他编辑器和智能代理。 来自开发者社区的早期反馈,普遍强调了这一规范在代码审查和调试流程中的潜在价值。一位 X 用户评论道: 这才是真正在收拾 Agent 生成代码的烂摊子。等不及在 Review 里用了。 另一位用户则从可复现性的角度给予了肯定: 团队一旦搞不清 Agent 为啥跑偏,就会直接停工。Trace 解决了这个痛点,开放得正好。 作为一份 RFC,Agent Trace 明确欢迎社区反馈,同时也有意保留了一些尚未解决的问题,例如在合并(merge)、变基(rebase)以及大规模代理驱动代码变更场景下应如何处理。Cursor 将该提案定位为一个共同标准的起点,而非终极答案,以应对 AI 代理在软件开发流程中日益普及的现实趋势。 原文链接:
随着数字化的发展,传统行业也面临着数字化的改革要求,而其中钢铁行业的数字化需求是比较复杂和急迫的。而电子签章作为数字化中不可缺少的一部分同样在钢铁行业中的意义极其重要。钢铁行业对于电子签章的需求主要源于其流程复杂、参与方多、合规要求高、单据频繁等特点。 1.核心业务场景需求 1) 采购与销售合同签署 Ø 与矿石、煤炭等供应商的大额采购合同。 Ø 钢材销售合同(涉及贸易商、终端客户)。 Ø 需支持多方签署、跨境签署及长期合同管理。 2) 物流与仓储单据 Ø 提货单、运单、仓单的电子化签署。 Ø 实现物流公司、仓库、客户之间的快速流转。 3) 质检与合规文件 Ø 质量检验报告、产品合格证等需权威部门签字盖章。 Ø 环保、安全监管文件的合规存档。 4) 内部流程审批 Ø 生产计划单、设备采购申请、财务报销等内部流程。 Ø 需要各级负责人快速批阅,避免纸质传递延迟。 5) 供应链金融 Ø 与银行、金融机构的融资协议、仓单质押文件。 Ø 需符合《电子签名法》及金融监管要求。 2.核心功能需求 1) 强法律效力 Ø 符合《电子签名法》要求,支持CA数字证书、时间戳、区块链存证。 Ø 可对接司法鉴定机构,提供出证服务。 2) 高集成能力 Ø 与ERP(如SAP、用友)、OA、CRM、物流系统等无缝集成。 Ø 支持API批量调用,适应钢铁企业现有IT架构。 3) 全流程管控 Ø 从发起、审批、签署到归档的全链路追踪。 Ø 支持撤回、作废、补充签署等灵活操作。 4) 移动化签署 Ø 支持手机、平板等移动端签署,方便外勤人员(如销售、物流)。 Ø 可结合短信/微信通知,提升签署效率。 5) 安全与权限控制 Ø 印章权限分级管理(如集团统一管控子公司用章)。 Ø 操作留痕、防篡改、防伪造,支持人脸识别等身份核验。 3.行业特殊需求 1) 大宗交易合规性 单价高、数量大,需确保合同条款无篡改,保留完整证据链。 2) 跨境贸易适配 进口铁矿石、出口钢材时,需支持国际数字证书互认。 3) 复杂签署流程 一份合同可能涉及供应商、钢厂、物流、银行等多方,需支持会签、轮签等模式。 4) 环境适应性 部分生产场景(如钢厂车间)网络条件有 限,需支持离线签署或弱网环境处理。 4.实施途径 1) 分阶段推进 优先从内部审批、供应商对账等高频场景试点,逐步推广至销售、物流等核心环节。 2) 选择专业服务商 Ø 需选择在制造业或大宗商品领域有成熟案例的电子签章服务商。 Ø 确保服务商具备等保三级、ISO27001等安全资质。 3) 制度配套 制定企业电子签章管理办法,明确使用范围、审批权限和法律责任。 4) 培训与推广 针对业务人员(如采购、销售)和技术人员分别培训,降低使用门槛。 5.预期收益 1) 效率提升 合同签署周期从数天缩短至几分钟,加速交易周转。 2) 成本降低 减少纸张、打印、快递、仓储管理成本。 3) 风险控制 全流程可追溯,减少印章冒用、合同篡改等风险。 4) 数字化转型 推动钢铁企业向“智慧供应链”转型,提升行业竞争力。 6.注意事项 1) 法律合规:涉及国际业务时需确认目标国对电子签章的认可程度。 2) 系统兼容性:确保与老旧工业系统(如MES)的对接可行性。 3) 长期存证:重要文件需保障10年以上可查验、可取证。 如果需要进一步针对具体场景(如“钢厂与经销商订单流程”或“跨境铁矿石采购”)设计解决方案,可咨询专业的电子签章厂商,如:北京安证通、契约锁、法大大等。
摘要:本文深入探讨了传统指标平台在实现“管、研、用”一体化时面临的三大核心痛点:口径管理混乱、研发效率低下、使用成本高昂。针对这些问题,文章介绍了基于 NoETL 语义编织技术的 Aloudata CAN 平台如何通过统一语义层和智能物化引擎,构建“定义即开发、治理、服务”的自动化闭环。同时,提供了从战略筹备到价值深化的四步走落地路径,并结合平安证券、麦当劳等标杆客户的量化成效,为企业数据治理与指标体系建设提供可复制的实践指南。 在数据驱动决策的时代,企业普遍希望通过建设指标平台来统一数据口径、提升分析效率。然而,许多项目最终却陷入“伪一体”的困境:管理、研发、使用三个环节依然割裂,导致口径混乱、响应迟缓、成本高昂。本文将深度解构传统模式的痛点,并阐述 Aloudata CAN 如何基于 NoETL 语义编织技术,实现真正的“管研用一体”,并提供已验证的落地路径与价值佐证。 传统模式下,“管、研、用”的割裂主要体现在技术架构和协作流程上,形成了事实上的信息孤岛。 这三个环节的割裂,使企业始终在“数据分析不可能三角”(口径统一、敏捷响应、成本可控)中艰难妥协。 Aloudata CAN 基于 NoETL 语义编织 (Semantic Fabric) 技术,通过两大核心引擎重塑协作范式,实现逻辑定义与物理执行的解耦。 至此,形成了“定义即开发、定义即治理、定义即服务”的自动化闭环。 基于众多客户实践,成功落地“真·管研用一体”可遵循以下四阶段模型: 阶段一:战略筹备与灯塔选择(第1-2个月) 阶段二:价值验证与能力内化(第3-4个月) 阶段三:全面推广与组织建设(第6-12个月) 阶段四:生态融合与价值深化(长期) 多个行业头部客户的实践数据,验证了该模式在提效、降本、增质方面的显著价值。 传统方案是静态的元数据目录,仅记录来源,无法保证逻辑同步更新,且分析受限于物理宽表。Aloudata CAN 是一个动态的语义计算引擎,基于 DWD 明细层构建“虚拟业务事实网络”,实现一处定义、处处使用、自动计算。 不需要。平台采用 Headless 架构,向下对接现有 DWD 层,向上通过标准接口服务各类 BI 工具。其目标是“做轻数仓”,通过减少不必要的物理宽表来优化现有架构。 可从三个维度衡量:效率(如指标平均交付周期)、成本(如中间表减少数量、TCO下降)、质量(如跨部门数据一致性、问题工单数)。建议项目启动前确立基线。 相反,这是实现“弯道超车”的机遇。平台通过配置化、低代码方式降低技术门槛,帮助企业跳过“先乱后治”阶段,一步到位构建统一、敏捷的数据服务能力。 本文更详细的技术实现、架构图与案例细节,请访问 Aloudata 官方技术博客阅读原文:https://ai.noetl.cn/knowledge-base/aloudata-can-real-path-val...本文首发于 Aloudata 官方技术博客:《告别伪一体!Aloudata CAN 真·管研用一体的落地路径与价值佐证》转载请注明出处。
一、 传统“伪一体”模式的三大核心痛点
依赖静态的元数据目录(Catalog)仅能记录指标来源,无法承载动态的业务逻辑变化。指标口径的维护高度依赖人工沟通和文档,极易出现偏差,导致跨部门会议沦为“数据辩论会”,决策效率低下。
分析路径被预建的物理宽表所固化。任何新的分析维度组合需求,都可能需要启动一次新的 ETL 任务开发、测试和上线,周期以“天”或“周”计,严重拖慢业务响应速度。
“烟囱式”的开发模式为每个报表或应用单独建设物理宽表,导致数据仓库中充斥着大量相似、冗余的中间表。这不仅消耗巨大的存储和计算资源,还形成了沉重的技术债,使得总拥有成本(TCO)持续攀升。二、 Aloudata CAN 的“真·管研用一体”技术架构
三、 四步走落地路径:从试点到深化
四、 价值佐证:标杆客户的量化成效
客户行业 核心场景 关键量化成效 模式验证 证券(平安证券) 指标统一管理、业务自助分析 开发工作量减少 50%,效率提升 10 倍,指标口径 100% 一致,TCO 节约 50% “136”协作模式(10% 科技+30% 分析师+60% 业务) 餐饮(麦当劳中国) 实时业绩监控、智能归因 沉淀 1000+ 指标、250+ 维度,百亿级数据 P90<1s,日均百万级 API 调用 覆盖 30+ 业务场景的标准化指标服务 服饰(某头部品牌) 营销活动分析 1 个月沉淀 300+ 指标,指标开发维护成本降低 70%,决策效率提升 10 倍 361 个指标 × 120 个维度的沉淀复用机制 央国企(中交一公局) 集团数据治理、智能问数 业务自助完成 80% 数据需求,问数准确率达 92% AI-Ready 数据底座的构建 五、 实施建议:确保成功的五个关键动作
六、 常见问题解答(FAQ)
Q1: Aloudata CAN 和传统指标平台或 BI 内置的指标模块有何本质区别?
Q2: 引入 Aloudata CAN 是否需要推翻现有的数据仓库和 BI 工具?
Q3: 如何衡量“真·管研用一体”项目的成功?
Q4: 数据治理基础较弱的企业,直接上这种平台门槛是否太高?
七、 核心要点总结
现在小学不布置寒假作业了,需要自己买题给孩子学。我就想是不是可以针对一二年级的知识点做一个在线刷题学习的,再增加一点游戏性。
目前每天让他学几分钟,感觉还是可以的,分享给大家。
地址: https://yinianji.vercel.app/
技术栈:
React 19 + TypeScript + Vite 7
PWA 支持(离线缓存、可安装)
Web Audio API (原生音频)
有什么建议欢迎给我反馈。




在当今大语言模型快速发展的时代,推理能力已成为决定模型表现的关键因素。然而,许多开发者和用户可能没有意识到,通过精心设计的提示词技术,可以显著提升模型在复杂推理任务中的表现。本文将深入探讨四种前沿的推理增强提示技术:思维链(Chain of Thought, CoT)、自一致性(Self-Consistency)、思维树(Tree-of-Thought, ToT)和ReAct,分析它们的原理、应用场景及最佳实践,帮助你更有效地利用这些技术提升AI应用的推理质量。 关键要点: 思维链(CoT)是推理增强提示技术中最基础、应用最广泛的方法。其核心思想是引导模型不要直接给出答案,而是通过逐步推理的方式展示思考过程,类似于人类解决复杂问题时的思考模式。 CoT通过在提示词中添加引导性语句,如"Let's think step by step"(让我们一步步思考),激发模型的推理能力。具体来说: 例如,对于数学问题"如果John有3个苹果,送出1个,还剩几个?",使用CoT提示后,模型会先输出推理过程: "John最初有3个苹果。 这种分步思考方式大大提高了模型在多步骤推理任务中的准确性。 CoT主要有三种实现方式: 零样本CoT是最简单直接的方法,只需在问题前添加引导性语句即可。例如: "John有3个苹果,送出1个,还剩几个? 少样本CoT则需要提供几个包含推理过程的示例,帮助模型学习如何生成推理链。例如: "示例1: "示例2: "现在,请解决这个问题: 优势: 局限: 根据研究数据,CoT在GSM8K数据集上将模型的准确率提升了约17.9%,证明了其在数学推理任务中的有效性。然而,对于更复杂的问题,如需要探索多种可能路径的任务,CoT的局限性就显得明显。 自一致性(SC)是对CoT的改进方法,通过多路径采样和多数投票机制,显著提高推理结果的稳定性。它假设一个复杂问题可能有多种解决路径,但正确答案通常会在多次采样中被频繁生成。 SC的核心机制包括三个步骤: 与CoT相比,SC的关键区别在于它不依赖单一推理路径,而是通过"群体智慧"选择最一致的答案。这种方法类似于让多位专家独立思考同一问题,然后采纳他们共同认同的结论。 例如,在解决"37×42"这样的乘法问题时,SC会生成多个推理路径: 路径1:37×40=1480,37×2=74,1480+74=1554 通过多数投票,正确答案1554会被选中,而错误答案则被过滤。 SC的实现需要结合采样技术与结果聚合策略: 以下是SC的Prompt模板示例: "请解决以下数学问题,生成5个不同的推理路径,然后选择最常见的正确答案。 优势: 局限: SC在计算资源有限的情况下,建议先从少量样本(如3-5个)开始,以实现大部分性能提升。根据研究,SC在GSM8K数据集上比CoT高出约12.2%的准确率,证明了其在复杂推理任务中的有效性。 思维树(ToT)是推理增强提示技术中最复杂、也最强大的方法。它超越了CoT的线性思维和SC的简单多数投票,将推理过程结构化为树形分支,在每一步探索多个可能的推理方向,并通过评估机制选择最优路径。 ToT的工作原理类似于搜索算法在迷宫中寻找出口: 例如,在解决24点游戏问题时,ToT会同时探索多种运算组合: 初始状态:9, 8, 6, 3 然后对每个分支进行评估,保留最有希望的路径继续探索。这种树状结构的推理方式大大提高了模型处理复杂规划问题的能力。 ToT的实现需要更复杂的Prompt设计和参数配置: 以下是ToT的Prompt模板示例,以24点游戏为例: "你是一个数学专家,擅长解决24点游戏问题。请按照以下规则思考: 规则: 示例: 现在,请解决以下24点问题: ToT的实现依赖于多个关键参数的配置: 参数调优策略: 优势: 局限: 在实际应用中,ToT特别适合需要多步决策和路径规划的任务,如游戏策略制定、复杂数学问题求解、多条件约束下的规划问题等。 ReAct(Reasoning and Action)是一种结合推理与行动的提示技术,它允许模型在推理过程中调用外部工具获取信息或执行特定操作,从而实现更强大的问题解决能力。 ReAct的核心是"推理-行动"的迭代循环: 这种机制类似于人类解决问题时的"思考-行动-观察-再思考"循环,使模型能够动态调整推理路径,处理更复杂的问题。 例如,在解决需要实时数据的问题时,ReAct允许模型调用网络搜索工具: "思考:要回答特斯拉2023年Q3在华销量及主要竞品,首先需要获取权威销量数据源。 ReAct的实现需要定义明确的工具集和交互格式: 以下是ReAct的Prompt模板示例: "你是一个强大的AI助手,可以访问以下工具解决复杂问题: 请按照以下格式思考和行动: 示例: 问题:谁是目前世界上最高的山峰? 现在,请解决以下问题: " ReAct的实现需要合理配置以下参数: 最佳实践: 优势: 局限: 根据研究,ReAct在需要工具支持的任务中,比单纯使用CoT或SC的准确率平均高出12-30%,证明了其在复杂问题解决中的潜力。 四种推理增强技术各有特点,适用于不同场景。下表对它们进行了全面比较: 选择策略: 简单推理任务:优先选择CoT,因其实现简单且能提供清晰的推理过程 需要高稳定性的任务:选择SC,通过多路径采样和投票提高结果可靠性 复杂规划任务:选择ToT,通过多路径探索和动态评估解决复杂问题 需要外部信息的任务:选择ReAct,结合推理与工具调用处理复杂现实问题 技术融合策略: 在实际应用中,可以考虑技术融合以获取最佳效果: 技术选择的关键因素: 数学问题是最能体现推理增强技术优势的应用场景之一。下面通过具体案例展示四种技术在数学问题中的应用。 CoT通过引导模型分步推理,显著提升数学问题的解决能力。下面是一个使用CoT解决代数问题的案例: 问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛? CoT Prompt: "请解决以下代数问题,使用逐步推理过程。 模型输出: "首先,设鸡的数量为x,牛的数量为y。 CoT在数学问题中的优势在于能够清晰展示每一步的推导过程,便于验证和理解。 SC通过多路径采样和投票机制,提高数学问题答案的可靠性。下面是一个使用SC解决概率问题的案例: 问题:如果30%的Huhulians拥有至少一台电视,24%的电视拥有者拥有至少四台电视。那么,Huhulians中拥有至少四台电视的比例是多少? SC Prompt: "请解决以下概率问题,生成5个不同的推理路径,然后选择最常见的正确答案。 模型输出: 推理路径1: 推理路径2: 推理路径3: 推理路径4: 推理路径5: 最终答案:7.2% SC通过生成多个推理路径并投票选择,有效过滤了推理过程中的错误,提高了最终答案的可靠性。 ToT特别适合需要多路径探索的数学问题,如24点游戏或复杂方程求解。下面是一个使用ToT解决24点游戏的案例: 问题:使用数字9, 8, 6, 3通过加减乘除运算得到24。 ToT Prompt: "你是一个数学专家,擅长解决24点游戏问题。请按照以下规则思考: 规则: 输入:9, 8, 6, 3 模型输出: 初始状态:9, 8, 6, 3 分支1:9 × 8 = 72 → 剩余:72, 6, 3 评估分支: 选择最有希望的分支3和分支4继续探索。 分支3-1:6 × 3 = 18 → 剩余:1, 18 评估分支: 在分支3-2中,模型成功找到了解法:3 × 8 = 24,从而解决了问题。这种树状结构的探索方式使模型能够系统地尝试各种可能性,大大提高了复杂数学问题的解决率。 ReAct通过结合推理与工具调用,可以解决需要精确计算或外部数据的数学问题。下面是一个使用ReAct解决复杂数学问题的案例: 问题:计算从1到500的所有数字键入所需的总按键次数。 ReAct Prompt: "你是一个强大的数学问题解决者,可以使用Python解释器执行代码进行精确计算。请按照以下格式思考和行动: 问题:计算从1到500的所有数字键入所需的总按键次数。 模型输出: Thought: 首先需要确定1到500之间各个数字的位数。一位数(1-9)需要1次按键,两位数(10-99)需要2次,三位数(100-500)需要3次。 Observation: 代码执行结果为1392。 ReAct的优势在于能够处理需要精确计算或外部数据的数学问题,通过工具调用确保计算的准确性。 创意写作是另一种能够受益于推理增强技术的领域,特别是在需要逻辑连贯或多路径探索的创作中。以下是四种技术在创意写作中的应用案例。 CoT可以引导模型在创意写作中进行分步思考,确保故事的逻辑连贯性。下面是一个使用CoT进行故事续写的案例: 问题:请续写以下故事:"小明推开那扇古老的大门,里面是一个他从未见过的神秘世界..." CoT Prompt: "请续写以下故事,使用逐步推理确保逻辑连贯和情节合理。 " 模型输出: 续写故事: 一位年迈的巫师从阴影中走出,他对小明说:"年轻的冒险者,你终于来了。我是守护者,预言中说你会带来光明。" 小明询问发生了什么事,巫师叹息道:"黑暗领主已经占领了我们的王国,只有预言中的救世主才能击败他。而你,就是那个人。" 巫师带领小明进入图书馆深处,教他使用魔法书中的力量。经过数月的学习,小明掌握了强大的魔法技能。 一天,黑暗领主的军队逼近图书馆。小明知道是时候面对挑战了。他拿起最强大的魔法书,与巫师一起前往战场。 经过一场激烈的战斗,小明召唤出强大的光明魔法,彻底击败了黑暗领主。王国重获自由,小明成为了传奇英雄。 CoT在创意写作中的优势在于能够确保故事发展的逻辑性和连贯性,避免情节漏洞。 SC可以生成多个故事版本,通过投票选择最受欢迎的结局,提高创作的多样性。下面是一个使用SC进行故事结局创作的案例: 问题:请为以下故事创作三个不同的结局,然后选择最合理的一个。 SC Prompt: "请为以下故事创作三个不同的结局,然后选择最常见的合理结局。 模型输出: 结局1: 结局2: 结局3: 最终结局: 在三个结局中,结局3出现了两次,因此被选为最终答案。这个结局既符合小明选择知识的决定,又避免了其他结局的极端结果,更加合理和积极。 ToT在创意写作中特别适合需要多路径探索的任务,如多结局故事创作或复杂情节规划。下面是一个使用ToT创作多结局故事的案例: 问题:请为以下故事创建一个思维树,探索不同选择带来的各种结局。 ToT Prompt: "请为以下故事创建一个思维树,探索不同选择带来的各种结局。 " 模型输出: 初始状态:小明站在十字路口,面临三个选择:财富、知识、冒险。 分支1:选择财富 评估分支1: 分支2:选择知识 评估分支2: 分支3:选择冒险 评估分支3: 现在,请从每个主要分支中选择最有希望的结局进行详细描述: 财富之路:小明成为富翁,但感到空虚,后来通过慈善找到人生意义。 最终故事: 知识之路充满挑战,小明需要不断学习和克服困难。经过几年的艰辛努力,他成为了一位杰出的学者,掌握了丰富的知识。 然而,小明意识到,仅仅拥有知识是不够的。他开始将所学应用于实践,帮助社区解决实际问题。通过这种方式,他不仅实现了个人价值,也为社会做出了贡献。 小明的朋友们感到惊讶,因为他没有选择财富之路或冒险之路。但他们看到小明过着充实而有意义的生活,纷纷向他学习。 ToT在创意写作中的优势在于能够系统地探索多种可能性,避免创作中的思维局限。 ReAct可以增强创意写作的真实性,通过调用外部工具验证故事中的事实和细节。下面是一个使用ReAct创作历史小说的案例: 问题:请创作一个关于明朝郑和下西洋的故事,确保历史事实准确。 ReAct Prompt: "你是一个历史小说作家,可以使用以下工具确保故事中的历史事实准确: 请按照以下格式思考和行动: 问题:请创作一个关于明朝郑和下西洋的故事,确保历史事实准确。 模型输出: Thought: 首先需要确认郑和下西洋的基本事实,如时间、目的、船队组成等。 Observation: 郑和下西洋是明朝初年(1405-1433)由郑和领导的七次大规模海上远航。主要目的是宣扬国威、发展朝贡贸易、寻找建文帝等。船队由数百艘船组成,最远到达东非和红海沿岸。 Thought: 确认了基本事实,现在需要确定故事的核心情节。可以考虑郑和与当地统治者会面的场景。 Observation: 根据历史记载,1411年,郑和船队到达古里(今印度卡利卡特)。郑和与古里国王进行了友好会面,赠送了明朝的礼物,签署了贸易条约,并在古里建立了中国商馆。 Thought: 这个历史事件非常适合作为核心情节。现在需要构建一个故事场景,描述郑和与古里国王的会面。 Observation: 确认正确,郑和第三次下西洋于1411年到达古里。 Thought: 现在可以开始创作故事了。将描述郑和与古里国王会面的场景,包括会面的细节、礼物的种类、签署的条约内容以及建立的中国商馆。 1411年的一个清晨,郑和率领的庞大船队缓缓驶入古里的港口。海面上阳光明媚,船队悬挂着鲜艳的旗帜,展现出大明帝国的威严。 古里国王早已在港口等候,他好奇地注视着这些来自遥远东方的船只。当郑和踏上古里土地时,国王亲自迎接,热情地说:"久闻大明帝国的威名,今日得见郑大人,实乃我国之幸。" 郑和微微一笑,递上明朝皇帝的信件和丰厚的礼物:丝绸、瓷器、香料和精美的工艺品。国王接过礼物,眼中闪烁着喜悦。 随后,郑和与国王进行了深入交谈,讨论了两国贸易的可能性。经过数日的商议,两国签署了贸易条约,古里承诺向明朝进贡,并给予明朝商人优惠政策。 作为友好往来的象征,明朝在古里建立了中国商馆,为往来贸易提供便利。郑和在古里受到了热烈欢迎,他的这次访问大大促进了两国之间的友好关系。 国王对郑和说:"郑大人,你的到来为我国带来了繁荣与友谊,我将永远铭记于心。" 郑和微微一笑,回应道:"这是明朝皇帝的旨意,我们希望与各国建立和平友好的关系。" 这次会面成为两国历史上重要的一页,也为后来的贸易往来奠定了坚实基础。 ReAct在创意写作中的优势在于能够确保故事中的历史事实准确无误,提高创作的真实性和可信度。 要有效地应用这些推理增强技术,需要掌握一些关键的实现技巧和最佳实践。 对于CoT,关键在于设计引导性语句和示例,鼓励模型展示清晰的推理过程: 对于SC,关键在于平衡采样多样性与计算成本,以及选择合适的投票机制: 对于ToT,关键在于设计合理的分支生成和评估策略,以及控制计算成本: 对于ReAct,关键在于设计清晰的工具接口和交互流程,以及处理工具调用的异常情况: 推理增强提示技术代表了大语言模型应用的重要发展方向,通过精心设计的Prompt,可以显著提升模型在复杂推理任务中的表现。本文介绍了四种前沿的推理增强技术:思维链(CoT)、自一致性(SC)、思维树(ToT)和ReAct,并通过数学问题和创意写作等场景展示了它们的应用。 每种技术都有其独特的优势和适用场景: 未来,推理增强技术将继续发展,可能在以下几个方向取得突破: 随着这些技术的不断完善和普及,我们将能够构建更加智能、可靠和实用的AI应用,使大语言模型真正成为人类思维的有力辅助。一、思维链(Chain of Thought, CoT):基础推理增强技术
1.1 CoT的工作原理
他送出1个苹果。
所以剩下的苹果数量是3-1=2。
因此,答案是2。"1.2 CoT的实现方式
实现方式 说明 适用场景 零样本CoT 直接添加"Let's think step by step"引导语 简单推理任务,如基础数学题 少样本CoT 提供几个包含推理过程的示例 复杂推理任务,如多步骤数学题 自动CoT 模型自动生成推理链 开放域问题,如创意写作中的逻辑推导
让我们一步步思考:"
问题:5个孩子每人有4块饼干,总共有多少块饼干?
让我们一步步思考:
每个孩子有4块饼干,共有5个孩子。
所以总共有4×5=20块饼干。
答案:20块饼干。"
问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛?
让我们一步步思考:
假设所有动物都是鸡,那么会有35个头和70条腿(35×2)。
实际有94条腿,多出24条腿。每头牛比鸡多2条腿,所以牛的数量是24÷2=12头。
鸡的数量是35-12=23只。
答案:23只鸡和12头牛。"
停车场有3辆车,又有2辆车到达,现在有多少辆车?
让我们一步步思考:"1.3 CoT的优势与局限
二、自一致性(Self-Consistency):CoT的稳健性增强
2.1 SC的工作原理
路径2:40×42=1680,减去3×42=126,得到1680-126=1554
路径3:30×42=1260,7×42=294,1260+294=1554
路径4:错误路径:37×42=14542.2 SC的实现方式
do_sample=True和较高的温度值(0.7-0.9)
问题:停车场有3辆车,又有2辆车到达,现在有多少辆车?
请按照以下格式输出:
推理路径1:
[推理过程...]
答案:[答案...]
推理路径2:
[推理过程...]
答案:[答案...]
...
最终答案:[最常见的正确答案...]
"2.3 SC的优势与局限
三、思维树(Tree-of-Thought, ToT):复杂规划任务的解决方案
3.1 ToT的工作原理
分支1:9×8=72 → 72, 6, 3
分支2:9+8=17 → 17, 6, 3
分支3:9-8=1 → 1, 6, 3
分支4:8÷6≈1.333 → 9, 1.333, 33.2 ToT的实现方式
输入:14, 8, 8, 2
步骤1:14-2=12 → 剩余数字:12, 8, 8
步骤2:12×8=96 → 剩余数字:96, 8
步骤3:96÷8=12 → 剩余数字:12
无法得到24,最接近结果是12。
输入:9, 8, 6, 3
"3.3 ToT的关键参数配置
n_generate:每步生成的分支数量(通常3-5)n_evaluate:每步评估的分支数量(通常2-3)nselect:每步保留的最佳分支数量(通常2-3)max_depth:树的最大深度(根据问题复杂度设置)temperature:控制生成多样性(通常0.7)search_strategy:选择BFS或DFS等搜索策略nGenerate(如3)和nSelect(如2)max_depth(如5-6)forbidden_steps避免重复探索已失败的路径3.4 ToT的优势与局限
四、ReAct:推理与行动的协同
4.1 ReAct的工作原理
行动:搜索[中国乘联会官网]
观察:找到季度新能源车销量报告,显示特斯拉销量为15万辆。
思考:需识别特斯拉竞品,应考虑同价位区间车型。
行动:检索[30万价位纯电车型]
观察:比对小鹏G9、蔚来ET5等车型销量数据。
思考:整合时间维度数据,分析市场趋势。
行动:调用数据分析模块
观察:显示特斯拉在中国市场占有率约为18%。
思考:最终答案应包含具体销量和主要竞品信息。
行动:无
最终答案:特斯拉2023年Q3在华销量约为15万辆,主要竞争对手包括小鹏G9和蔚来ET5。"4.2 ReAct的实现方式
Thought: 我需要确认最新的山峰高度数据,包括珠穆朗玛峰和其他可能的候选山峰。
Action: web_search
Action Input: 最新世界最高山峰数据
Observation: 根据搜索结果,珠穆朗玛峰仍被公认为世界最高峰,海拔8848.86米。
Thought: 确认无误,珠穆朗玛峰是最高峰。
Action: 无
Final Answer: 珠穆朗玛峰,海拔8848.86米。
问题:请计算从上海到北京的高铁票价,并比较不同班次的舒适度。4.3 ReAct的关键参数配置
max_steps(通常5-10),防止无限循环4.4 ReAct的优势与局限
五、四种技术的对比与选择策略
技术 复杂度 计算成本 可解释性 适用场景 准确率提升 CoT 低 低 高 简单数学、逻辑推理、常识问答 中等(约15-20%) SC 中等 中等 中等 复杂数学、多解问题、需要高稳定性的任务 较高(约17-25%) ToT 高 高 高 复杂规划、多路径依赖、需要探索多种可能性的任务 最高(可达70%+) ReAct 中高 中高 中等 需要工具支持、实时信息、多步骤交互的任务 较高(约12-30%) 六、数学问题中的推理增强技术应用
6.1 CoT在数学问题中的应用
问题:一个农场有鸡和牛,总共有35个头和94条腿。农场里有多少只鸡和牛?
提示:鸡有1个头和2条腿,牛有1个头和4条腿。
让我们一步步思考:
"
根据头的数量,我们有x + y = 35。
根据腿的数量,我们有2x + 4y = 94。
我们可以从第一个方程解出x = 35 - y。
将x代入第二个方程:2(35 - y) + 4y = 94 → 70 - 2y + 4y = 94 → 70 + 2y = 94 → 2y = 24 → y = 12。
因此,牛的数量是12头,鸡的数量是35 - 12 = 23只。
所以,农场里有23只鸡和12头牛。"6.2 SC在数学问题中的应用
问题:如果30%的Huhulians拥有至少一台电视,24%的电视拥有者拥有至少四台电视。那么,Huhulians中拥有至少四台电视的比例是多少?
请按照以下格式输出:
推理路径1:
[推理过程...]
答案:[答案...]
推理路径2:
[推理过程...]
答案:[答案...]
...
最终答案:[最常见的正确答案...]
"
答案:7.2%
答案:7.2%
答案:7.2%
答案:7.2%
答案:54%6.3 ToT在数学问题中的应用
"
分支2:9 + 8 = 17 → 剩余:17, 6, 3
分支3:9 - 8 = 1 → 剩余:1, 6, 3
分支4:8 ÷ 6 ≈ 1.333 → 剩余:9, 1.333, 3
分支3-2:9 - 6 = 3 → 剩余:3, 8, 3
分支4-1:9 - 1.333 ≈ 7.667 → 剩余:7.667, 3
分支4-2:1.333 × 3 ≈ 4 → 剩余:9, 46.4 ReAct在数学问题中的应用
python_interpreter;如果不需要,请写无
"
Action: python_interpreter
Action Input:# 计算1-9的数字数量
one_digit = 9
# 计算10-99的数字数量
two_digit = 90
# 计算100-500的数字数量
three_digit = 500 - 99
# 计算总按键次数
total = one_digit * 1 + two_digit * 2 + three_digit * 3
print(total)
Thought: 验证计算是否正确。1-9有9个数字,每个1位,共9×1=9次。
10-99有90个数字,每个2位,共90×2=180次。
100-500有401个数字,每个3位,共401×3=1203次。
总和为9+180+1203=1392次,计算正确。
Action: 无
Final Answer: 1392次。七、创意写作中的推理增强技术应用
7.1 CoT在创意写作中的应用
初始故事:小明推开那扇古老的大门,里面是一个他从未见过的神秘世界...
提示:请先思考可能的发展方向,然后选择最合适的一个进行续写。
让我们一步步思考:
a. 魔法冒险:小明进入魔法世界,学习魔法,解决难题。
b. 时间旅行:小明穿越到过去或未来,改变历史或探索未来。
c. 平行宇宙:小明进入另一个平行世界,遇到另一个自己,探索两个世界的联系。
a. 魔法冒险:与初始情节高度一致,有丰富的探索空间。
b. 时间旅行:需要解决时间悖论,可能增加复杂性。
c. 平行宇宙:需要解释两个世界的联系,可能分散故事焦点。
小明进入魔法世界后,发现了一个正在被黑暗力量威胁的王国。
他遇到了一位年迈的巫师,巫师告诉他小明是预言中的救世主。
小明开始学习魔法,最终在一场大战中击败了黑暗领主,拯救了王国。
情节发展合理:从发现世界到学习魔法,再到最终战斗,形成一个完整的故事弧线。
小明推开那扇古老的大门,里面是一个他从未见过的神秘世界。他发现自己站在一个巨大的魔法图书馆前,书架高达天际,书籍闪烁着奇异的光芒。7.2 SC在创意写作中的应用
故事:小明发现了一本神秘的书,当他念出书中的咒语时,一只魔法生物出现了,并给了他一个选择:要么获得巨大的财富,要么获得无限的知识,但不能两者兼得。
故事:小明发现了一本神秘的书,当他念出书中的咒语时,一只魔法生物出现了,并给了他一个选择:要么获得巨大的财富,要么获得无限的知识,但不能两者兼得。
请按照以下格式输出:
结局1:
[结局描述...]
结局2:
[结局描述...]
结局3:
[结局描述...]
最终结局:
[最常见的合理结局...]
"
小明选择了财富。魔法生物消失了,小明回到家中,发现口袋里装满了金币。他成为了富翁,但不久后感到空虚,意识到知识才是真正的财富。他将大部分金币捐给学校,自己则专注于学习。
小明选择了知识。魔法生物消失了,小明获得了无限的知识,但他无法处理如此庞大的信息。他逐渐迷失在知识的海洋中,忘记了财富的重要性,最终因无法适应现实世界而孤独终老。
小明选择了知识。魔法生物消失了,小明获得了无限的知识,他利用这些知识发明了改变世界的发明,帮助了无数人,同时也获得了应有的尊重和适度的财富。
小明选择了知识。魔法生物消失了,小明获得了无限的知识,他利用这些知识发明了改变世界的发明,帮助了无数人,同时也获得了应有的尊重和适度的财富。7.3 ToT在创意写作中的应用
故事:小明站在十字路口,左边是一条通往财富的道路,右边是一条通往知识的道路,中间是一条通往冒险的道路。
故事:小明站在十字路口,左边是一条通往财富的道路,右边是一条通往知识的道路,中间是一条通往冒险的道路。
规则:
分支1-1:财富之路充满陷阱,小明被骗,一无所有。
分支1-2:财富之路顺利,小明成为富翁,但感到空虚。
分支1-3:财富之路需要付出代价,小明失去健康换取财富。
分支2-1:知识之路艰难,小明成为学者,改变世界。
分支2-2:知识之路充满诱惑,小明迷失在知识中。
分支2-3:知识之路需要实践,小明结合知识和行动,取得平衡。
分支3-1:冒险之路充满危险,小明获得成长但失去家人。
分支3-2:冒险之路充满奇遇,小明发现新世界并带回知识。
分支3-3:冒险之路需要智慧,小明利用知识解决冒险中的问题。
知识之路:小明结合知识和行动,利用知识解决实际问题,取得平衡。
冒险之路:小明在冒险中发现新世界,带回宝贵知识,丰富了自己的人生。
小明站在十字路口,面临三个选择:财富、知识或冒险。他深思熟虑后,决定选择知识之路。7.4 ReAct在创意写作中的应用
无
"
Action: web_search
Action Input: 郑和下西洋的基本事实
Action: web_search
Action Input: 郑和与古里国王会面的详细历史记录
Action: fact_check
Action Input: 郑和船队到达古里的年份是否为1411年
Action: 无
Final Answer:
《远航的使命》八、技术实现与最佳实践
8.1 CoT的最佳实践
8.2 SC的最佳实践
8.3 ToT的最佳实践
8.4 ReAct的最佳实践
max_steps(通常5-10),防止无限循环九、总结与未来展望