钢钢更新

用行动改变世界,做个有情怀的技术宅

一个 APEX 按钮,把任务交给 Hermes 搜索并带回依据

做 APEX 开发,我们很熟悉这样的过程:建一个页面,放几个输入项,写一段 PL/SQL,点击按钮,业务就往前走一步。

但如果按钮背后的需求变成“帮我查一查这个主题最近发生了什么,再整理出值得关注的变化”,该怎么实现呢?

用户没有告诉我们去哪个网站,也没给出搜索关键词,更没有指定先读哪篇文章。程序需要根据目标找资料,判断结果是否相关,继续读取,再组织答案。每一个动作都能调用 API,但把这些动作接起来,需要有人作判断。

APEX 能不能保留我们熟悉的页面和业务逻辑,同时借用 AI Agent 的能力,完成这种过程不完全固定的任务?

APEX 真实页面:输入主题后得到摘要和主要发现

阅读全文 »

An APEX button sends Hermes to research a task and bring back evidence

As APEX developers, we know the routine: create a page, add a few items, write some PL/SQL, and make a button move a business process forward.

But what if the request behind that button becomes “Find out what has happened recently on this topic, and summarize the developments worth paying attention to”? How would we implement that?

The user has not specified a website, search keywords, or an article to read first. The program needs to find information based on the goal, judge its relevance, read further, and put together an answer. Each action can call an API, but deciding how to connect those actions requires judgment.

Could APEX keep its familiar pages and business logic while borrowing an AI agent’s ability to handle tasks whose steps are not fully known in advance?

Real APEX page: a topic followed by a summary and key findings

阅读全文 »

小黑把社区讨论筛成带出处的答案

当你在排查 ORDS、REST API 或页面问题时,真正耗时间的常常不是写代码,而是把散落的经验找出来、判断能不能用,再整理成自己的下一步。apexcn-cli 做的事很朴素:让本地 AI 能够使用 APEX 中文社区。

一个 ORDS 认证失败,通常不是搜不到答案,而是答案分散在不同话题里。你会打开社区、搜索、跳转、读几段回复,再把关键信息带回正在工作的 AI 对话。这样做当然没错,只是每次都要重复。

apexcn-cli 把这段路缩短了。

它是一个运行在本机的命令行工具,但真正的使用者不必是命令行熟手。只要你在使用 Codex、WorkBuddy、千问办公这类能够执行本机命令的 AI 工具,就可以让 AI 在后台调用它:查社区、读话题、整理答案,并把原始链接一并带回来。

先从社区开始

APEX 中文社区按问题求助、新手入门、进阶技巧和建议反馈组织内容。它仍然是阅读原帖、参与讨论的地方;apexcn-cli 做的是让 AI 能更快抵达这些内容,而不是另起一套页面。

APEX 中文社区首页与内容栏目

从一句安装请求开始

项目唯一官方仓库是 wfg2513148/apexcn-cli。安装时,不需要在一堆同名仓库里赌运气,也不需要把 API Key 交给 AI。

在 AI 工具里发出下面这句话即可:

请从官方 GitHub 仓库 https://github.com/wfg2513148/apexcn-cli 在本机安装 apexcn-cli。只使用该仓库的官方安装器;安装后运行 apexcn --version 并告诉我结果。安装阶段不要向我索取、记录或显示 API Key。

安装完成后,apexcn 会成为本机可用的全局命令。第一次配置 API Key 时,用户只需打开一次终端,完成保存和检查;

API Key 在社区账号菜单中的 API Key 管理 页面获取。复制后按 README 的步骤配置本机 CLI;不要把完整 Key 发到普通聊天、帖子或截图中。

APEX 中文社区 API Key 管理页面

阅读全文 »

小黑在 App Builder、APEXlang 与 Git 之间搬运 APEX 应用定义

过去做 APEX 项目,开发入口几乎只有一个:App Builder。

页面、区域、Dynamic Action、Validation、Shared Components,都在浏览器里配置。改完刷新页面,结果马上出现。这个反馈速度很难替代,也是许多人喜欢 APEX 的原因。

问题出在项目变大以后。两三个人同时修改同一个应用,Git 里只留下一份导出 SQL,评审者很难看清某个按钮为什么换了位置、某个 Authorization Scheme 是否被误改。再把 AI Coding Agent 拉进来,麻烦会更明显:它能写 SQL 和 PL/SQL,却很难从安装脚本里还原整套应用结构。

APEX 26.1 给出了新的解法。APEXlang 把应用元数据表达成结构化、可读的 .apx 文件;SQLcl 提供生成、导出、验证和导入命令;Blueprint 把规格先变成可试用的应用骨架;Oracle 提供的 Skills 则告诉 Coding Agent 怎样理解和修改这些文件。[^oracle-apexlang-new]

我更愿意把它看成一次开发入口的扩建。App Builder 还在,而且仍然重要。只是从 26.1 开始,浏览器不再是唯一现场。

阅读全文 »

过去一年,很多开发者已经习惯了一个新现实:AI 工具不仅能补代码、写 SQL、生成页面文案,甚至可以根据一段需求描述搭出一个应用系统的雏形。

于是一个问题自然出现:如果 AI 已经能生成应用了,我们还需要重新学习 Oracle APEX 吗?

钢哥的答案恰好相反:正因为 AI 已经可以生成应用系统,现在更有必要重新审视 Oracle APEX。

原因并不复杂。AI 正在把“生成第一版应用”的门槛迅速拉低,但企业应用真正困难的部分,从来不只是第一版能不能跑起来。开发者要看懂它、审查它、维护它;企业管理者要确认它是否符合数据、安全、权限、流程和交付规范;业务用户要能尽早试用、反馈和验证它是否真的解决问题。

也就是说,AI 解决的是“生成”的一部分问题,而企业应用还必须回答另一个更现实的问题:生成出来之后,谁来负责?放在哪里运行?怎么审查?怎么治理?怎么交付?

这也是我这次翻译和整理 Oracle APEX Developer’s Companion 时最强烈的感受。它不是一本普通的功能说明书,而是在 AI 生成应用越来越容易的今天,提醒我们重新理解 APEX 作为企业应用平台的价值。

阅读全文 »

交互式报表是许多 APEX 应用展示和探索数据的核心。Oracle APEX 26.1 引入了对交互式报表的自然语言支持,为用户提供了一种以对话方式优化报表的新途径。本文将重点介绍本版本中的其他增强功能,这些功能使交互式报表对开发者更灵活、对最终用户更有用,并且更适合生成更丰富的报表输出。

这些增强功能包括声明式行选择、列级 CSS 类、限制显示行的更好方法、从自定义控件直接访问交互式报表对话框,以及针对更大更复杂报表的改进渲染。

声明式行选择

Oracle APEX 26.1 为交互式报表引入了内置的声明式行选择功能。用户现在可以使用复选框选择行,开发者可以直接在页面设计器中配置整个交互过程,无需编写自定义代码。

这使得批量审批、批量更新、导出以及其他多行操作等场景更加容易实现。所选行的值可立即用于动态操作和页面进程,从而简化下游处理流程。

阅读全文 »

本周更新的重点已经不是“APEX 26.1 发布了什么”,而是“这些能力怎么真正进入开发工作流”。本周新增37篇文章,最值得看的是 APEXlang + Git merge、IR 行选择器、Quick Select、Interactive Grid 交互和安全/工具链补课。

最值得关注的主线有三条:

  1. APEXlang 开始从概念走向工程实践:讨论已经进入 Git merge、工作副本替代、导出验证导入这些现实问题。
  2. APEX 26.1 的声明式能力开始落到交互细节:IR 行选择器、Quick Select、字体/视觉/UI 改动,都是“看起来小,实际每天都要用”的能力。
  3. AI 叙事在降温,工程化叙事在升温:站内不是没有 AI,但更有价值的内容,已经开始转向边界、安全、可验证、可协作。

1)APEXLang,工作副本的继任者?如何与GIT Merge配合使用?

https://oracleapex.cn/ords/f?p=100:14:::::P14_THREAD_ID:28579&cs=1J7QPc54Gh4PCZQzq53I2nao9ddCjkFB1tFvMGTJgIIDeEApfBMhJfRUnfMF-ZhtMp8Sqw6-ZZrSCU79eresZDQ

  • 为什么值得看:这不是“再讲一次 APEXlang 是什么”,而是直接把问题推进到团队协作现场:两个开发者分别在不同分支修改同一个 .apx 文件,最后怎么 merge,冲突怎么解,验证怎么做,能不能再导回 APEX。
  • 这对开发者意味着什么:如果说 APEXlang 真有资格成为 26.1 的底层变革,那它必须先过 Git 这一关。这个 thread 的价值,就在于它把 APEXlang 从“概念上很美”推进到了“工程上能不能活”。

钢哥点评:APEXlang 真正的分水岭,不是能不能导出,而是能不能被多人协作、能不能被 merge、能不能被 validate。

2)Oracle APEX 26.1 IR 行选择器

https://oracleapex.cn/ords/f?p=100:14:::::P14_THREAD_ID:28547&cs=1JMr6Pt8yJLMo9NKYA1q6QyTilbysYKyJET2e3jQgz7W-HriYIaZSpW95MmzezRgJQ-sZJMsjxSucHK6jl5ar9Q

  • 为什么值得看:行选择器看起来像“小功能”,但它直接决定交互式报表能不能顺滑地进入批处理、联动处理、下游动作。thread 明确展示了如何把选中的主键写入页面项,再驱动第二个报表或后续流程。
  • 这对开发者意味着什么:以前很多需求都得靠额外技巧拼出来,现在 26.1 给了更原生的路径。对做审批、批量操作、联动分析的人来说,这不是装饰,而是省工。

钢哥点评:26.1 最值钱的一类更新,恰恰是这些“不上头条、但每天都能省事”的声明式增强。

阅读全文 »

如果你 5 月只记住一件事,我建议不是“Oracle APEX 26.1 发布了”,而是 APEX 的开发方式开始变了。

以前大家谈 APEX,更多是在说页面怎么搭、表单怎么做、报表怎么配、流程怎么跑。但自从今年以来,社区讨论的重心明显挪了位置:开始谈文件化、版本控制、AI智能体、自然语言报表、DevOps、自动化测试、私有大模型接入、团队协作。说得再直白一点,Oracle APEX 已经越来越不像“拖拖拽拽把页面拼出来的低代码开发工具”,而更像一个 企业级应用敏捷开发底座。而且这个底座,开始自带 AI、自带工程化、自带协作感。这才是2026年5月最值得看的地方。

本次统计口径说明

  • 统计来源:oracleapex.cn
  • 统计范围:2026年5月收集的 APEX 博客译文
  • 最终纳入:72条

这72条里,5月最强的主线其实非常集中:

  • APEX 26.1 发布与工程化变革(16)
  • AI / Agent / LLM 能力(14)
  • 界面、交互与用户体验(14)
  • 报表、搜索与数据交互(8)
  • 安全、认证与会话控制(7)
  • 集成、插件、API 与扩展(7)
  • 工程化、测试与迁移(6)

这个月最重要的 7 条主线

1. APEX 26.1 不是一次小升级,而是在改开发方式

如果只看热度,5月像是在给 Oracle APEX 26.1 做集中庆典。但如果你把几篇核心文章串起来看,会发现它们讨论的不是“又多了几个功能”,而是 APEX 以后应该怎么开发、怎么协作、怎么进 Git、怎么和 AI 一起工作

最值得看的几篇博文如下:

钢哥解读:APEX 26.1 之后,最值得重新评估的,不是“能不能开发企业级应用”,而是“能不能进入更正式的 AI 工程管理体系”。

阅读全文 »

以下是截止至 2026.04.30收集的 Oracle APEX 最新博文,完整博文列表请移步这里:Oracle APEX Evangelion(EVA 补完计划)

常规 APEX 博文整理

0%