一键导入
weaver-workflow
泛微OA(Ecology 9)流程创建通用技能。当用户需要创建任何泛微OA流程(如差旅费报销、员工入职、采购申请等)时触发。提供流程发现、表单探测、选项查询、附件上传、草稿创建、审批发起等能力。针对特殊流程(如差旅报销)通过 rules/ 目录下的规则文档提供业务约束。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
泛微OA(Ecology 9)流程创建通用技能。当用户需要创建任何泛微OA流程(如差旅费报销、员工入职、采购申请等)时触发。提供流程发现、表单探测、选项查询、附件上传、草稿创建、审批发起等能力。针对特殊流程(如差旅报销)通过 rules/ 目录下的规则文档提供业务约束。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | weaver-workflow |
| description | 泛微OA(Ecology 9)流程创建通用技能。当用户需要创建任何泛微OA流程(如差旅费报销、员工入职、采购申请等)时触发。提供流程发现、表单探测、选项查询、附件上传、草稿创建、审批发起等能力。针对特殊流程(如差旅报销)通过 rules/ 目录下的规则文档提供业务约束。 |
脚本负责能力,规则负责约束,AI 负责理解和决策。
当用户要求创建流程时,第一步不是查表单,而是:
# 1. 如果用户没说清楚要创建哪个流程
node scripts/index.js list-workflows --user <userId>
# 2. 拿到 workflowId 后,读对应的规则文档
读取 rules/{workflowId}-*.md
# 如果该 workflowId 没有专属规则文档,读 rules/default.md
规则文档的 YAML front matter 是机器可读的配置(字段映射、计算公式),正文是自然语言补充说明。两部分都要读。
遇到下拉框(html_type=5)或浏览按钮(html_type=3)字段时:
select-options / browser-options / data-source 等命令拿选项列表value 字段作为传参禁止直接问"请输入费用类型代码"、"请输入部门ID"这种填空题。
泛微附件不是单独接口上传,而是:
filePath 是 URL 或 /weaver/ecology/filesystem/ 路径 → 直接使用filePath 是本地路径或 base64 → 先调用 upload-file 命令拿到 docidfieldValue 传 docid,docid,docid 逗号分隔字符串autoSubmit: false,流程创建后停在草稿状态form-info 返回的每个字段带完整属性(类型、必填、隐藏等),这是唯一的字段信息来源。
规则文档(rules/*.md)不重复声明字段信息,只写业务规则(公式、联动、条件逻辑)。
核心约束:
form-info)为基准,将表单中的有效字段一一列出,去填充已有的信息给用户展示,并清晰指出还需要补充哪些字段。mandatory: true → 必填,AI 必须追问用户或从已知信息推断mandatory: false → 选填(也应尽量收集,如缺失应由用户确认无需填写)hidden: true → 隐藏字段,不传值skip: true → 废弃字段(label含"废弃"),不传值likely_system: true → 必须填充,禁止跳过! 这只是标记"系统可能自动回填",但 AI 必须主动填充。优先从 user 命令返回的数据中获取(phone_number、job_title_name、job_title_id 等),如果数据源中没有该字段,必须向用户询问,绝不允许留空。form-info 返回的 detailTables 是数组,可能有多张明细表(如员工入职流程 173 有 6 张明细表)。
AI 要根据规则文档判断每张明细表的语义,分别组装数据。
如差旅报销的超标公式 MAX(0, fyje - zrs × sjtw × je),这类公式写在规则文档的 YAML 里,AI 严格按公式计算,不自己发明。
浏览按钮(html_type=3)的选项列表通常有联动过滤——它的过滤 SQL 依赖其他字段的值。
例如:费用类型浏览框的过滤条件是 WHERE zj = $sqrzj$(按申请人职级过滤)。
如果 API 创建流程时没有传 sqrzj(申请人职级),那用户在网页端打开草稿、点击费用类型修改时,选项列表会是空白的。
AI 必须检查规则文档的 autoFill 部分,确保所有联动依赖字段都有值。
form-info 返回的字段带 likely_system: true 标记的是"可能系统回填"的文本字段。但 AI 绝不能依赖系统自动回填而跳过填充!
强制规则:
likely_system: true 的字段 100% 必须填充,除非规则文档的 skipFields 明确列出user 命令返回的数据中获取:phone_number(手机号)、job_title_name(岗位名称)、job_title_id(岗位ID)、work_code(工号)、dept_name(部门名称)等user 返回数据中没有对应字段 → 必须向用户询问,禁止留空这是最容易违反的规则。 当用户要求批量创建多条流程(或一条流程含多行明细)时,AI 容易在处理第一条后"偷懒",对后续条目使用默认值或凭记忆填写。这会导致严重的数据错误。
绝对禁止的行为:
必须遵守的流程:
自检清单(每条明细都要过一遍):
□ fylx1 的值是否来自 custom-browser 查询结果的 value 字段?
□ fybz/je/sx 是否来自该费用类型对应的 raw 数据?
□ cbje 是否按公式独立计算过?
□ 是否有任何字段使用了硬编码的默认值?(如果有 → 错误)
用户:"帮我创建一个差旅费报销-测试流程,马田,RH0758"
↓
AI: 1. 读取 rules/309-差旅费报销.md(知道差旅报销流程 ID=309、有哪些特殊字段)
2. node scripts/index.js user 马田 RH0758
→ 拿到 person_id, dept_id, job_title_id, job_level
3. node scripts/index.js form-info 309
→ 拿到所有字段定义 + 必填属性
4. node scripts/index.js select-options 309
→ 拿到"报销公司"等下拉选项
5. node scripts/index.js custom-browser feiyongbiaozhun1fy --filter zj=4B
→ 拿到该职级下的费用类型选项
6. node scripts/index.js related-requests --keyword 出差 --user 399 --days 30
→ 拿到近30天可关联的出差流程
7. 向用户追问:
- 报销公司?(展示选项让用户选)
- 费用明细?(费用类型从选项选,填金额、人数、天数、地点、发票日期)
- 出差报告附件?
- 关联哪条出差流程?(展示选项让用户选)
8. AI 严格按规则文档的公式算超标金额,超标时让用户填原因
9. 附件先上传拿 docid
10. 组装 input.json,调用 node scripts/index.js submit input.json
11. 默认草稿模式(autoSubmit=false)
所有命令统一用 node scripts/index.js <command>,输出都是 JSON。
| 命令 | 说明 |
|---|---|
list-workflows --user <userId> | 列出用户能创建的流程 |
form-info <workflowId> | 查表单结构(主表+多明细表+必填属性) |
user <name> <workCode> | 查申请人信息 |
select-options <workflowId> | 查所有下拉框选项 |
browser-options <workflowId> | 查所有浏览按钮选项(按 fielddbtype 分派) |
data-source <fielddbtype> | 手动查某种数据源(hrm/dept/jobtitle 等) |
custom-browser <browserName> [--filter k=v] | 查自定义浏览按钮 uf_xxx |
related-requests --keyword <kw> --user <id> --days <n> | 查关联流程 |
upload-file <path> | 上传附件,返回 docid |
submit <input.json> | 提交流程(默认草稿,加 --auto-submit 发起审批) |
diagnose | 探测关键表结构 |
见 rules/README.md。
如果用户要创建的流程没有规则文档,AI 读 rules/default.md 按通用步骤处理。遇到搞不定的特殊字段(如陌生的浏览按钮),向用户求助而不是猜。