技能介绍

要解决什么

PowerData 的「动态表单 + 列表」有两套并存的运行时：5.x 走 ScriptContext、formModel、BDSJ/BDJSGJ/JB 脚本体系，4.x 走 DYNACODE、gridConfig、Common 横切 API。两个版本的同名概念（比如「列表脚本」）实际是完全不同的对象模型，混在一起查资料的后果通常是照着 4.x 的写法填 5.x 的钩子，然后编译器报错。

这个技能的定位是一个只读知识库：它不生成表单、不跑脚本、不做迁移改写，只负责把平台侧的权威行为收敛成一份可检索的 wiki，让构建类 skill 和迁移类 skill 有统一的参照点。

内容如何组织

双轨并列：5x/ 与 4x/ 各自独立成章，互不混写。4.x 到 5.x 的改写映射明确划给 pacp-migrate-4x-module，本 wiki 只保留两轨的纯知识。
按场景加载：reference 按任务类型分文件——表单脚本、列表脚本、组件目录、列定义与查询条件、平台 API、存储结构、平台机制、报错避坑、预览渲染。不会一次性灌入全量文档，避免污染上下文。
版本同源：内容直接来自平台源码（5.x 的 dynamic-render 与 service，4.x 的 platform-core、dynamic-form-design），而非二手转述；平台升级 PR 必须同步更新对应文档，并向下游 skill 维护者推送通知。

API 合法性怎么判

5.x 里用 HTTP 端点（ggdmj、findcommoncodes 等）还是 this.xxx ScriptContext，取决于你写的是表单脚本还是列表脚本；4.x 里则要看是 Common.xxx 还是 gridConfig.xxx。文档里给了捷径：先判断形态，再跳到对应那一篇，比通读全库快得多。

适用边界

纯查阅，不执行动作：没有 CLI 命令、没有 JSON 配置模板、没有运行时代码。要动手搭表单或列表，需要配合 pacp-build-list、pacp-build-form、pacp-design-* 等 skill。
不做 4.x → 5.x 改写：两侧知识都在，但「某个 4.x API 在 5.x 换成什么」的对照表不在这里。
不覆盖项目级知识：具体项目的样式包、业务约定不在范围内。

截图预览

使用场景

编写 PowerData 5.x 动态表单脚本时，需要确认 BDSJ/BDJSGJ 钩子的调用顺序、formModel 与子表字段的取值方式，避免照 4.x 写法误填生命周期。
排查 5.x 列表脚本中的平台报错，如 getcloumninfo、LX=2 三按钮缺失或主键 XH 未生成，对照 pitfalls 文档定位是端点用法还是列定义问题。
从 30 多种表单组件中挑选合适的输入控件时，需要确认各组件的 type、aliases 与核心属性，而非凭猜测拼接配置。
处理 4.x 存量列表模块，需要查 gridConfig 的 callback、queryOptions、dataConfig 等对象模型与 $scope 注入约定。

适合人员

负责 PowerData 5.x/4.x 动态表单与列表开发的工程师，需要在写钩子、配列定义或调平台 API 前确认权威行为，避免版本混用。
维护平台升级流程的技术负责人，需要在 PR 合并后检查知识库同步，并通知下游构建类 skill 的维护者跟进。
基于构建类 skill（pacp-build-list/form、pacp-design-list/form）工作的 AI Agent，需要在生成表单或列表脚本前查证生命周期、组件属性与 API 合法性。
排查动态表单或列表运行时报错的工程师，需要按报错关键字快速定位到平台机制、API 端点或避坑文档。

PowerData 动态表单与列表百科