Informat Script

用于把自然语言业务需求转换成 Informat 平台脚本代码。

先读什么

先读这些精简资料：

references/script-sdk.md
references/script-safety.md
references/script-output-management.md
references/script-file-header.md
references/script-types.md
references/script-examples.md

如果需求涉及边缘能力、类型细节或你在精简资料里找不到的方法，再继续查：

../../sources/informat.script.md
../../sources/informat.d.ts
../../sources/informat.client.d.ts

适用场景

当用户要做以下事情时，优先使用这个 skill：

写织信 / Informat 平台脚本
按部门、角色、应用成员、团队成员查询数据
处理 account、company、dept、user、app 相关逻辑
编写平台自动化中的 JavaScript 逻辑
使用存储、问卷、事务、文件传输等平台能力

如果用户要写的是表达式、审批条件、流转条件、公式，改用 informat-expression。

工作方式

先判断用户要的是完整脚本、函数片段，还是单个核心逻辑。
确认所需能力是否存在于已知 Informat SDK 中。
先检查是否存在来源冲突，例如命名空间、参数名、返回值类型不一致。
能实现时，优先直接输出完整代码。
不能完全实现时，明确指出缺失的 SDK 能力、来源冲突或未知字段，并说明哪个部分需要用户补齐。
除非用户明确要求，不要先写长篇解释。

强约束

只允许使用两类能力：
- JavaScript 原生能力
- 来源资料中明确存在的 Informat SDK
不要杜撰对象、命名空间、方法、字段结构。
当字段名、模块标识符、角色标识符来自业务现场而资料未给出时，用占位名，并明确提示用户替换。
如果一个需求依赖未文档化 API，直接说明“根据现有资料不能确认/不能实现”，不要臆测。
如果不同来源对同一 API 的返回值或签名描述不一致，不要依赖冲突部分的行为。
对写操作，若返回值存在来源冲突，优先写成“不依赖返回值”的安全版本，必要时通过后续查询确认结果。
当 informat.system.* 与 informat.company.* 或其他近似 API 都可能命中时，必须先按语义选择正确命名空间，再生成代码。
输出代码时优先保证“合法、受约束、可改造”，不要为了看起来完整而添加虚构逻辑。

来源冲突处理规则

当原始资料存在冲突时，按下面的保守规则处理：

先确认 API 是否至少在一个权威来源中明确存在。
如果多个来源都存在，但返回值不一致：
- 不要依赖返回值
- 以副作用调用 + 再查询验证作为优先写法
如果多个来源都存在，但参数命名不一致：
- 保留调用顺序
- 在说明中指出“参数名以现场 SDK 为准”
如果多个命名空间有相似方法：
- informat.system.* 优先用于系统/跨团队语义
- informat.company.* 优先用于当前团队上下文
- 无法确定时，明确说明存在歧义，不要强行拍板

高风险场景

这些场景最容易写错，必须额外保守：

addCompanyMember：至少存在两套命名空间和参数语义
updateUserRole：来源中返回值有冲突，不能假设一定返回 number 或 void
任何写操作：不要假设“调用成功 = 数据一定已变更”，如需确认应补查询步骤
存储、事务、FTP、问卷等边缘能力：如果只在类型定义里出现，要回查原始签名再写
自定义模块、字段、角色 key、部门 OID：资料未提供时一律用占位，并提示替换

输出格式

默认按这个顺序输出：

最终代码
必要的替换说明
若存在来源冲突或不确定点，单独列出
若有实现限制，单独列出限制点

如果用户明确要求“只给代码”，就只给代码。

本地保存交互

生成脚本后，默认要处理“是否保存到本地”的交互。

规则如下：

如果用户一开始就明确表达了保存意图，例如：
- 保存到本地
- 写入文件
- 落盘
- 生成脚本文件
- 帮我存起来
- 确认后保存则不要再次询问，直接进入保存流程。
如果用户没有明确表达保存意图，则在给出脚本后追加一句固定询问：
- 是否需要我按本地目录规范保存到本地文件？
用户即使没有明确说“保存”，只要表达了确认保存的意思，也视为同意保存。
保存后必须回显：
- 实际保存路径
- 文件名
- 所属目录类别
如果保存为本地文件且用户未要求纯代码无注释，优先给文件添加简短文件头注释。

本地保存规则

当需要保存脚本到本地时：

默认根目录为当前工作目录下的 generated_scripts/
一级目录按业务域归类：
- account
- app
- company
- dept
- user
- storage
- survey
- transaction
- other
二级目录按月份归类，格式为 YYYY-MM
文件扩展名固定为 .js
文件名使用小写下划线格式 snake_case
文件名推荐模式：
- 动作_对象.js
- 动作_对象_限定词.js
如果用户未指定文件名，按脚本语义自动生成文件名
如果用户未指定目录类别，按脚本语义自动归类
如果脚本无法稳定归入已有业务域，统一归入兜底目录 other
如果保存为文件，优先使用 references/script-file-header.md 中的头部模板

示例路径：

generated_scripts/user/2026-03/update_user_role.js
generated_scripts/company/2026-03/add_company_member.js
generated_scripts/transaction/2026-03/update_user_role_with_transaction.js

代码风格

默认输出 JavaScript
尽量给完整函数或完整脚本片段
变量命名贴近业务含义
需要提前校验空值时，直接在代码里处理
避免与需求无关的封装

自检清单

输出前检查：

是否只用了来源资料里存在的 SDK
是否把脚本和表达式语法混淆了
是否给出了用户真正能复制改造的代码
是否在不确定字段上加了替换提示
是否错误依赖了来源有冲突的方法返回值
是否在相似 API 之间选错了命名空间
是否正确处理了“是否保存到本地”的交互
若需要保存，是否使用了正确的目录和文件命名规范
若无法稳定归类，是否正确放入 other 兜底目录
若需要保存为文件，是否合理添加了文件头注释或说明为何不添加
是否在无法实现时明确说明了原因

informat-script