钢钢更新

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

发表于 分类于 ， 本文字数： 1.1k 阅读时长 ≈ 4 分钟

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

当你在排查 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 管理页面

阅读全文 »

发表于 分类于 ， 本文字数： 2.9k 阅读时长 ≈ 11 分钟

小黑在 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 开始，浏览器不再是唯一现场。

阅读全文 »

发表于 分类于 ， ， 本文字数： 3.2k 阅读时长 ≈ 12 分钟

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

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

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

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

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

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

阅读全文 »

发表于 分类于 ， 本文字数： 3k 阅读时长 ≈ 11 分钟

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

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

声明式行选择

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

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

阅读全文 »

发表于 分类于 ， 本文字数： 1.7k 阅读时长 ≈ 6 分钟

本周更新的重点已经不是“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 最值钱的一类更新，恰恰是这些“不上头条、但每天都能省事”的声明式增强。

阅读全文 »

发表于 更新于 分类于 ， 本文字数： 2.8k 阅读时长 ≈ 10 分钟

如果你 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 工程管理体系”。

阅读全文 »

发表于 更新于 分类于 ， 本文字数： 588 阅读时长 ≈ 2 分钟

以下是截止至 2026.04.30收集的 Oracle APEX 最新博文，完整博文列表请移步这里：Oracle APEX Evangelion（EVA 补完计划）

常规 APEX 博文整理

发表于 更新于 分类于 ， 本文字数： 662 阅读时长 ≈ 2 分钟

以下是截止至 2026.03.31收集的 Oracle APEX 最新博文，完整博文列表请移步这里：Oracle APEX Evangelion（EVA 补完计划）

常规 APEX 博文整理

发表于 分类于 ， 本文字数： 543 阅读时长 ≈ 2 分钟

以下是截止至 2026.02.28收集的 Oracle APEX 最新博文，完整博文列表请移步这里：Oracle APEX Evangelion（EVA 补完计划）

常规 APEX 博文整理

0%