IBM Bob Premium Package for Z（Bob PP4Z） 将专业的 IBM Z 知识直接引入 Bob。PP4Z 是构建在 Bob 智能体基础之上的高级功能，旨在帮助大型机团队应对更广泛的开发工作。
PP4Z 专为企业大型机开发的现实场景而设计：大型应用程序、紧密耦合的系统、晦涩难懂的变量名、长期积累的业务逻辑，以及必须安全、一致、具备深度架构意识才能推进的现代化改造工作。
本文解释了为什么大规模大型机环境会将通用 AI 编码工具推至极限。文中涵盖结构化元数据和数据字典在原始源代码检索之外的价值，模型增强如何将回答锚定在经 IBM 认可的文档中，以及 PP4Z 如何将 Bob 的模型驱动推理与确定性 IBM Z 分析和验证工具相结合。
IBM Z 开发的高级体验
现代 IBM Z 开发涵盖了远超编写新代码的广泛活动：理解现有应用程序、追踪变更在大型系统中的影响传播、记录数十年积累的业务逻辑，以及做出既安全又可被辩护的现代化决策。
PP4Z 正是为支持这种广度而设计的。它构建于 Bob 的智能体基础之上，充分利用 Bob 的 skills、子代理和 workflows，并在此之上扩展了 IBM Z 开发所特需的能力：对大型互联应用环境的结构化知识、面向 COBOL、PL/I 和汇编语言的确定性分析工具，以及根据大型机团队工作方式调优的 Z 专用模式。
深入洞察应用程序的本地及企业元数据
一个大型大型机应用程序可能由数万个相互关联的程序组成，横跨 COBOL、PL/I 和汇编语言，由批处理调度程序协调，并与 Db2、CICS、IMS 等子系统集成。模型无法仅凭上下文对整个环境进行推理。在回答问题之前，它需要先判断哪些程序和关系是相关的。
这正是原始源代码检索的瓶颈所在。设想要求一个通用 AI 找出所有调用共享日期处理工具的程序（这类例程在大型 COBOL 环境中可能被数十个程序调用）。静态文本搜索能找到显式调用语句，但会漏掉动态调用——程序名存储在变量中、运行时才被解析的情况。同一查询执行两次，模型可能每次选择不同的搜索策略，返回不同的结果。回答看起来合理，但并不可靠。
PP4Z 的应对方式是在 AI 推理开始之前构建应用程序的结构化、可查询表示。本地扫描器直接从工作区填充元数据。这些扫描器与 Z Understand 容器中使用的扫描器相同，无需上传步骤即可使用。元数据以模型可精确查询的形式捕获程序关系、调用层次、控制流、数据流、SQL 使用情况、事务定义和资源依赖关系。
对于企业级分析，团队可以将 PP4Z 连接到 Z Understand 容器。这使 Bob 能够访问涵盖更广泛应用程序组合的结构化元数据，包括开发者本地工作区之外的关系。开发者随后可以向 Bob 提出如下问题：
- 哪些程序调用了某个特定工具？
- 哪些程序读取了某张特定的 SQL 表？
- 如果这个字段的大小发生变化，会影响什么？
Bob 查询元数据以识别相关程序和关系，再在需要深度分析时检查对应的源代码。回答建立在一致、可查询的应用数据之上，而非对原始源文件的概率性搜索。
模型增强：弥合 IBM Z 知识鸿沟
大多数 IBM Z 应用程序代码存放在私有的企业代码仓库中。通用模型无法访问这些系统的源代码、规范或业务上下文，也必须在比主流语言和框架少得多的公开示例下运作。
PP4Z 通过模型增强来解决这一问题：精选的 IBM Z 参考资料经过分析和索引后提供给 Bob 使用，从而确保涉及 IBM Z 语言和中间件的回答以 IBM 文档中实际记载的内容为依据。增强层对 IBM Z 文档进行处理，使其中的信息可直接用于回答开发者提出的特定类型问题，例如调用约定、字段结构、中间件行为和文档中记载的边界情况。通用模型由于对这些环境了解有限，可能会在这些方面出错，而且错误很难察觉。
实际差异体现在开发者编写或修改与 IBM Z 中间件交互的代码时。通用模型可能生成语法上看似合理、却违反 IBM 明确定义的严格接口契约的代码。借助模型增强，PP4Z 在生成回答时以 IBM 实际规定的内容为依据，而不是仅凭训练阶段对这些环境的有限了解尽力作出近似推断。
借助数据字典实现业务感知 AI
每个代码库中都存在变量名不清晰的问题，但 IBM Z 应用程序以不同的规模和形式呈现了这一难题。在许多长期运行的 COBOL 应用程序中，业务逻辑与应用逻辑紧密交织。含义被编码进简短的字段名、copybook 布局以及几十年来在没有统一规范下积累的命名惯例中。请看这段 WORKING-STORAGE SECTION：
01 WK10.
10 WK10-QUDISP PICTURE 9(10)
VALUE ZERO.
10 WK10-QUPIL PICTURE 9(3)
VALUE ZERO.
10 WK10-QUDIS PICTURE 9(15)
VALUE ZERO.
10 WK10-QUMYD PICTURE 9(10)
VALUE ZERO.四个数值累加器位于名为 WK10 的组中。无论是字段名还是 PICTURE 子句，都无法告诉开发者或模型它们各自代表什么。没有额外上下文的模型可能会注意到 WK10-QUDISP 和 WK10-QUDIS 都是数值字段，从 QU 和 DIS 片段推测它们可能与距离有关，并猜测它们用途相似。这个猜测是错误的。两者之间那一个字符的差异，就是全部的故事。
有了 PP4Z 生成的数据字典，区别就一目了然。WK10-QUDIS 是所有飞行员飞行距离的累计总和。它在飞行记录处理过程中持续递增，并用于最终的平均值计算。WK10-QUDISP 则是每位飞行员的独立累加器。它在每位飞行员的处理块开始时被重置为零，并与该飞行员的标识信息一起显示。一个在每位飞行员处理时重置，另一个从不重置。混淆两者的解释或影响分析会给出关于程序行为的错误答案。
PP4Z 通过静态分析每个变量在程序中的参与方式来生成这些条目。分析覆盖控制流、I/O 操作、计算和数据移动。它不试图记录每个字段，而是识别对程序行为影响最大的变量——那些一旦命名就能让程序其余部分变得清晰可读的变量。数据字典条目可以在本地管理，也可以通过 Z Understand 容器管理，支持批量生成、审查以及跨团队同步。
文档、解释与重构
关于元数据、数据字典和模型增强的几个章节介绍了 PP4Z 如何建立对应用程序的整体认识。本节介绍开发者如何利用这些信息。
文档化与业务规则提取能够大规模地产生持久的应用知识。团队可以为 COBOL、PL/I 和汇编语言程序生成结构化文档，涵盖程序逻辑、数据流和内嵌的业务规则。可以使用本地扫描器元数据进行聚焦范围的分析，或使用 Z Understand 容器处理整个应用程序。业务规则作为这一过程的组成部分浮现出来，让技术团队和现代化利益相关方无需手动追踪每个段落，就能获得关于应用程序功能的可读记录。
这些程序级文档现在可以编译成一个应用程序视图——一个包含图表和交叉引用页面的结构化站点，覆盖整个应用程序。单个程序文档回答关于某一程序的问题。应用程序视图则为团队和现代化利益相关方提供整个应用程序的全局地图。
全面解释会从与当前任务最相关的视角——架构师、开发者或业务人员——生成程序的详细解释。PP4Z 利用应用元数据、数据字典条目和模型增强层，使解释以程序的实际行为为依据。
重构利用收集到的上下文，在保留功能的同时将现有代码重构为模块化、可复用的服务。Refactor COBOL or PL/I program workflow 识别可提取候选项，映射其依赖关系，并引导完成转换。这为团队提供了一条无需完全重写即可提升可维护性的实用现代化路径。
集成的开发、质量与调试能力
开发者工作流的某些部分有确定性答案：代码是否符合某项规则、特定变量在程序中经过哪条路径，或者 PERFORM 之后控制权转移到哪里。PP4Z 通过专用工具处理这些问题。模型在开发者所要完成目标的上下文中解读由此得出的事实。
在 PP4Z 自定义模式 Z Code 中，Z Code Scan 为 COBOL 和 PL/I 程序提供快速的基于规则的静态分析。其 linter 式反馈无需概率推断即可发现问题。自定义模式 Z Architecture 提供控制流和数据流分析，包括执行如何在程序中流转，以及数据在段落和 copybook 之间流动时如何被转换。无论问题如何表述，这些工具都能产生一致、可重复的结果。
模型与这些工具的输出协同工作。它可以在提议的变更上下文中解读扫描结果，或追踪数据流以回答关于程序行为的特定问题。确定性分析处理有规则约束的内容，AI 则处理需要判断力的内容。
PP4Z 还包含 IBM Debug for z/OS 和代码覆盖能力，团队可以在同一环境中直接从 AI 辅助开发切换到执行级别的验证。
面向企业特定知识的 Skill Builder
应用元数据、数据字典、模型增强和确定性分析共同构成了 PP4Z 提供的 IBM Z 基础。Skill Builder 则让组织能够在此基础上加入自身知识。
借助 Skill Builder，团队可以创建自定义 skills，捕获并应用企业特定知识，例如编码规范、命名惯例、技术模式、业务术语和环境特定指南。这些 skills 帮助 Bob 理解某一特定组织内部的开发方式，减少通用假设，提升 AI 生成回答的相关性。当 skills 与用户的请求和代码上下文相关时，可被自动采纳并动态调用，直接集成到现有的 PP4Z workflows 中。
融会贯通
规模、语义密度和专有上下文使大型机开发对通用 AI 工具来说颇具挑战。PP4Z 直接针对这些因素提供解决方案：以结构化元数据应对规模问题，以数据字典呈现业务含义，以模型增强涵盖 IBM Z 文档，并以确定性工具执行基于规则的分析。
在这种方法中，AI 推理与确定性知识相互强化。Bob 从结构化元数据出发，借助精选文档，并解读基于规则的工具输出。开发者在关键业务环境中按回答行动之前，可以检查这些证据。
要开始的话，从团队一直回避的一个程序入手——也许是因为其用途不明，或者其业务逻辑多年未被触及。运行本地扫描器构建其元数据，并为关键变量生成数据字典。使用解释 workflow 了解程序的功能，再运行文档化 workflow 将这些知识保存到你的工作区。从那里开始，同一套基础便可支撑影响分析、重构和质量验证。团队从一个现在已经理解了的程序起步。