Unity 项目里有一类活,程序通常都不太爱手写。
就是导表工具。
比如:
- 读 CSV
- 转配置类
- 做字段映射
- 生成代码或 JSON
这类活说复杂也不至于高深。
但特别容易又长又碎,还充满重复劳动。
所以它天生就很适合让 AI 先起一版。
一、为什么导表工具特别适合 AI 起草
因为它有几个典型特征:
- 结构明确
- 输入输出清楚
- 模板代码多
- 规则可以写死
比如你很清楚要做的是:
- 读取某个 CSV。
- 第一行是字段名。
- 第二行是类型。
- 生成对应的 C# 配置类。
这种任务对 AI 很友好。
因为你不是让它猜业务,而是在让它补“机械代码”。
二、但导表问题最怕的,不是代码写不出来,而是协议被偷偷写歪
这是重点。
AI 特别容易在这些地方“看上去合理,实际上不对”:
- 字段类型映射错了
- 空值规则默认错了
- 枚举解析策略和项目约定不一致
- 主键处理方式和现有配置管线不一致
所以导表工具适合让 AI 起草,但不适合闭眼接收。
三、一个更靠谱的提示词例子
1 | 你是资深 Unity 工具链工程师。 |
这类提示词最重要的点,就是把“你们项目的表协议”说清楚。
别让 AI 自由发挥。
四、一个很适合先让 AI 起草的代码骨架
1 | using System; |
这段代码不长。
但它正好展示了这类任务最适合 AI 的地方:先把重复样板铺起来,再由你把项目特定协议收紧。
五、第二轮提示词,最适合让 AI 帮你补“项目约束”
我通常会继续问:
1 | 请继续扩展刚才的导表代码。 |
这样 AI 会更像在给你补协议实现,而不是重新发明一套新工具。
六、最后一句
CSV 导表这类活,真的很适合先交给 AI 起版。
因为它机械、重复、容易拖。
但你一定要守住一件事:
项目协议不能模糊。
不然 AI 写出来的不是工具,是另一套偷偷长歪的配置标准。