多维表里写了个AirScript脚本,跑得好好的。结果换了个字段类型,脚本直接哑火——写入的数据变成了[object Object],公式也匹配不上。今天古老师把跟WPS灵犀Claw沟通的整个过程整理出来,看怎么用自然语言让AI帮你写脚本、改脚本、升级脚本,最后做到一个脚本通吃6种字段类型。
一、需求:工序二维转一维
业务场景很简单。工厂排程用的工序数据,二维形式存的,一行的MultipleSelect字段里塞了多个工序:生产单号 | 工序 | 工序数 |
PO-0001 | 工序1,工序3,工序5 | 3 |
PO-0002 | 工序2,工序3,工序6,工序5 | 4 |
生产单号 | 工序 | 工序顺序 |
PO-0001 | 工序1 | 1 |
PO-0001 | 工序3 | 2 |
PO-0001 | 工序5 | 3 |
二、第一轮对话:确认需求再动手
跟Claw说的第一句话很关键,不是直接说"帮我写代码",而是先给需求让它确认。加载我脚本相关技能,并参考,现在我的需求是:1.数据表:工序 - 二维 →是一个二维形式的数据2.数据表:工序 - 一维 →是一个一维形式的数据我需要用一个AirScript代码,把数据表1中的数据全部转换成数据表2的格式你先读取多维表格的结构,确认需求给我,再开始执行
为什么要这样写?因为AI不知道你的表结构、字段类型、记录数据。先让它读,确认了再动手,避免写出来的代码驴唇不对马嘴。Claw读完后返回了结构对比和转换逻辑,确认无误才回复1开始执行。读取了两个数据表的schema,发现源表"工序"是MultipleSelect类型,目标表"工序"是MultiLineText类型读取了实际记录数据,确认MultipleSelect返回的是数组格式这一步的核心价值:AI代替你做了字段类型分析和数据格式确认,你不用自己翻界面去看字段类型。
三、第二轮:增量升级
第一版脚本能跑了,但有个问题——每次运行都全量写入,数据越来越多。我需要的是只处理新增的记录。升级原来的AirScript代码条件加上:如果配置状态为空才开始配置,把配置为空的数据配置到数据表2中
同时我还让Claw在源表创建了一个XLOOKUP公式字段"配置状态",跨表查找一维表的生产单号,找到就显示"已配置"。=IF(XLOOKUP([@生产单号],'工序 - 一维'![生产单号],'工序 - 一维'![生产单号],"")<>"","已配置","")这样每次脚本运行后,新写入的记录会被公式标记为"已配置",下次运行自动跳过。增量同步的核心就是用一个公式字段当标记位。
四、第三轮:字段类型变了,脚本崩了
新建了一张测试表,把"生产单号"从文本改成了编号(CustomAutoNumber)。脚本一跑,写入的数据全变成了[object Object]。这个问题不是代码报错,而是静默失败——数据写进去了,但内容是错的。根因在哪?AirScript的GetRecords读不同字段类型,返回的值格式完全不一样:字段类型 | 读取值格式 |
文本 | "PO-0001" |
编号 | [{autoNumber:1, displayText:"20260622-001"}] |
数字 | 123 |
单选项 | {value:"选项值"} |
联系人 | [{id:"xxx", name:"张三"}] |
创建人 | [{id:"xxx", name:"张三"}] |
原来的代码直接拿到值就用,编号类型返回的是对象数组,直接写入就变成[object Object]。
五、讨论:一个函数通吃6种类型
发现这个问题后,我没有直接让Claw改代码,而是先跟它讨论:如果用户的属性还有可能是:数字、单选项、联系人、创建人,能否兼容,一个脚本通用?
Claw分析了各类型的返回格式,结论是:联系人和创建人返回{id, name}结构,没有displayText,当前代码会fallback到[object Object]。然后给出了一个extractText函数,按优先级逐层提取:function extractText(raw) {if (typeof raw === "string" || typeof raw === "number") return String(raw);if (Array.isArray(raw) && raw.length > 0) return extractText(raw[0]);if (typeof raw === "object") {return raw.displayText || raw.name || raw.value || raw.title || "";逻辑很直白:字符串或数字直接转,数组取第一个元素递归,对象按displayText → name → value → title优先级取。这就是跟AI讨论的价值——你提出可能性,AI帮你分析可行性,比你一个个试错快得多。
六、公式也得改:&""解决类型不匹配
脚本修好了,但XLOOKUP公式又出问题了。源表生产单号是数字123,脚本转成字符串"123"写入一维表。XLOOKUP拿数字123去找文本"123",严格类型匹配,直接找不到。配置状态一直为空,脚本每次运行都重复写入,增量逻辑失效了。这个问题最隐蔽——脚本不报错,数据也写进去了,但公式匹配不上。得仔细看公式返回值才能发现。解决方案很简单,XLOOKUP两边都加&""强制转文本:=IF(XLOOKUP([@生产单号]&"",'工序 - 一维'![生产单号]&"",'工序 - 一维'![生产单号]&"","")<>"","已配置","")
七、配置区参数化:换表只改6行
字段标题如果更改更改代码哪里?如生产单号→单号这个能否写在配置区?
// ========== 配置区(必改) ==========var SOURCE_TABLE = "工序 - 二维 - 编号测试";var TARGET_TABLE = "工序 - 一维 - 编号";var FIELD_PROD_NO = "生产单号";var FIELD_PROCESS = "工序";var FIELD_CONFIG_STATUS = "配置状态";// ===================================以后换表换字段,只改这几行,下面的逻辑代码一个字不用动。
八、踩坑总结
坑1:MultipleSelect返回数组不是字符串第一版就发现了。GetRecords读MultipleSelect返回的是数组,不是逗号分隔的字符串。加了类型判断兼容。CustomAutoNumber返回[{autoNumber:1, displayText:"20260622-001"}],直接用变成[object Object]。extractText函数解决了这个。数字和文本之间做XLOOKUP严格匹配会失败。&""强制转文本是最简单的解法。这个坑最隐蔽,脚本不报错数据也写进去了,但公式匹配不上。
九、跟AI写代码的沟通心得
先确认再动手。第一句话不是"帮我写代码",而是"你先读结构,确认需求给我"。AI读了表结构才知道字段类型,才知道MultipleSelect返回数组,避免写出有硬伤的代码。发现一个问题就讨论一个方向。发现编号类型不兼容后,不是只修编号,而是追问"数字、单选项、联系人、创建人能不能也兼容"。一次讨论解决一类问题,比一个个试效率高太多。把踩过的坑告诉AI。每次踩坑后让AI把经验更新到技能库里,下次遇到类似场景AI会主动避坑。比如&""这个技巧,现在已经写进技能的踩坑记录了。