-
本文完整记录如何使用 Agents 实现“报表组跨报表实现连续页码”的复杂报表。 一、环境准备： 1、润乾报表设计器（20260916 版本） 2、润乾内置的智能体技能 rpx-agent-t ..
-
策略逻辑 本策略核心思想是把 “成交量均线” 和 “OBV 能量潮” 两套量能体系结合，实现 “成交热度 + 资金流向” 双重确认。 第一重信号：5 日均量线上穿 20 日均量线（量能均线金叉 ..
-
一、 概述 在实际业务中，报表导出的文件（如 Excel、PDF、Word）可能包含敏感数据。为了防止文件被无关人员读取，润乾报表提供了文档密码保护功能。设置密码后，用户双击打开导出的文件时， ..
-
需求背景 在润乾报表的默认行为中，通过 JSP 页面导出 Excel 或 PDF 时，文件名取自报表文件本身的名称。若业务要求导出的文件名由报表内容动态决定（例如取报表标题行 A1 单元格的值 ..
-
AI编程Agent+润乾报表的Vibe Coding实践 AI 编程眼下正热得发烫，一夜之间，写代码这件事都被大模型接管了。但如果你恰好身处复杂报表开发的一线，大概会有另一种体感：这股红利，似 ..
-
很多软件都有开源版本，从操作系统到数据库，从开发框架到 AI 工具，开源生态蓬勃发展，用开源能省钱也是常识 但报表工具却是个例外——虽然也有开源产品，但流行度却不高，只有在需求极度简单的场景下 ..
-
AI 对话式自助报表现在很火，说句话就能出报表，听起来确实方便，很多企业都想试试，但现实是，市面上的 AI 自助报表产品大多基于 LLM 实现，而不少机构对数据安全和合规有严格要求，不允许调用 ..
-
[图片] 智能问数赛道，“准确率”一直是各家厂商的必争之地。从 70% 到 90%，再到 95%，数字一路走高，用户的困惑却从未减少：为什么演示时百发百中，一到真实业务场景就频频出错？为什么明 ..
-
很多智能问数厂家在谈方案时都会强调一致全面的语义层以保证准确率，把做好数据治理作为建设智能问数的前置步骤，也以把大量技术力量用于如何解决数据治理。 智能问数是否有效确实相当大程度依赖于数据治理 ..
-
AI 浪潮之下，各类开发工具纷纷拥抱 AI，报表工具也不例外 但市面上大量打着 AI 报表旗号的产品，实际只是 ChatBI ，ChatBI 属于传统 BI 的 AI 化延伸，受限于 BI 原 ..
-
[图片] AI 写 SQL 很快，但你敢直接上线吗？ 目标是“找出连续三个月交易额递增的信用卡客户”，AI 秒给一段 CTE 加 LAG，语法没错、能跑出结果，可逻辑对吗？没人敢说“我看懂了” ..
-
[图片] 写完 SQL，半年后自己看不懂，这种事谁都遇到过。 窗口函数嵌三层，业务逻辑全藏在语法里。靠注释？改了代码不改注释，比代码还不可信。让 AI 写，跑通了，提交了，留下的还是一段看不懂 ..
-
[图片] AI 写 SQL，快是快了，可调试确认并不简单，好不容易弄对了，这代码又怎么传承呢？三个月后交接，对话记录早没了，只剩一坨没人敢动的 SQL。越往后，越没人敢碰，最后只能推倒重来。 ..
-
[图片] 写 SQL，最怕的不是语法，是复杂度。需求一复杂，SQL 就失控——CTE 套 CTE，窗口函数叠窗口函数，几十行代码揉成一团。错了？改一处崩三处。 有人说不就是 SQL 吗，学学就 ..
-
[图片] 当初写的两百行 SQL，两个月后自己都看不懂了。偏偏又来了新需求，硬着头皮回去读——这个 JOIN 为什么这么写？那个 CASE 的逻辑是什么？注释也有，还是看不懂。 不改？需求卡在 ..
-
[图片] 同事走了，留下一堆祖传 SQL。动不动几百行，CTE 套窗口函数，没人看得懂，更没人敢改。新需求来了，没人敢接。 重写？业务逻辑早丢了，谁说得清那堆 SQL 到底算了些什么。硬着头皮 ..
-
[图片] 工单查询，看起来简单，做起来谁做谁知道。 业务部门要个数据，IT 排期三五天。好不容易写出来了，下个月需求微调，当初写的 SQL 自己都看不懂。200 行嵌套，十几个 CTE，改一个 ..
-
这两年 DuckDB 已经成了不少数据分析场景下的热门选择，轻量、好上手、易集成，也适合搞本地分析的程序员，直接用 SQL，省心省力。 不过光“写着舒服”还不够，跑得快，优化智能，也是决定体验 ..
-
数据存储本质上是在灵活性、性能、易用性之间找平衡。DuckDB 和 esProc SPL 都提供自有的二进制存储形式，但在数据组织上有很大不同。 DuckDB 仍然是常规数据库机制，数据组织在 ..
-
DuckDB 和 esProc SPL 都能嵌入到应用作为计算引擎，这里比较一下哪个更轻量一些。“轻量”不仅指体积大小，也体现在开发维护的简洁性上。 DuckDB 用起来确实方便，Python ..
-
DuckDB 和 esProc SPL 都支持多样数据源处理，这里比较一下两者的差异。 支持的数据源种类 DuckDB 支持的数据源类型覆盖了常见的文件格式（如 CSV、Parquet、JSO ..
-
esProc SPL 处理多层 JSON 数据要比 DuckDB 方便很多，尤其需要保留 JSON 层次以及进行复杂计算时。 DuckDB 的 JSON 处理能力还是不错的，read_json ..
-
DuckDB 可以直接读取 CSV、Parquet、JSON 等常见文件，只用一句 SQL 就能完成文件加载和查询，例如SELECT * FROM 'data.csv' WHERE price ..
-
DuckDB 风头正劲，这不是没道理的。作为桌面分析工具的当红明星，它把 SQL 玩得贼溜，CTE 递归查询、窗口函数套三层、复杂 JOIN，样样拿得出手。甚至跑个亿级数据的聚合统计，甩个SE ..
-
对于桌面数据分析用户，如果说 DuckDB 是轻巧灵活的 'SQL 瑞士军刀'，那 esProc SPL 简直就是自带 Python 技能的 '全能工具箱'，既保留 SQL 的便捷，又突破 S ..
