Agent落地项目小型活动（Skill）

type

status

date

slug

summary

一、我为什么想做这个东西

我想做的，不是一个“会聊天的 AI”，而是一个能在项目里稳定做事的 AI Agent。

在游戏研发里，很多工作表面上看是“开发”，实际上是很多固定动作的组合：

读策划案

读反馈表

找参考活动

定位项目里该改哪些枚举、脚本、界面、配置

实现代码

做风险检查

列测试点

做 review

最后补配置、联调、跑活动

如果这些动作每次都要从头想，AI 就很容易表现得像“看起来懂很多，但做起来不稳定”。

所以我真正想解决的问题，不是“让 AI 更聪明”，而是：

怎么把项目里已经存在的经验、规则、边界条件，变成 AI 可以稳定执行的工作流。

我选择的切入点，是一个很典型的业务场景：

无新增子活动、以复用为主的小型活动接入。

这个场景非常适合做 Agent 落地试点，因为它同时具备三种特征：

有明确输入：活动枚举、服务器对象、反馈表、参考活动

有固定改动面：枚举、脚本、界面、配置

有大量项目经验：哪些能复用，哪些必须问，哪些不能碰

换句话说，它天然适合被沉淀成 skill。

二、先说结论：Skill 到底是什么

很多人第一次接触 Cursor 的时候，会把 skill 理解成“一个提示词模板”。

这个理解不完全错，但不够本质。

Skill 的本质

Skill 本质上不是知识库，也不是代码生成器，而是：

一份给 Agent 的“项目内工作规程”。

它的作用不是告诉 AI“这个功能怎么写”，而是告诉 AI：

这个任务适用于什么范围

先做什么，后做什么

什么可以直接做，什么必须先问

哪些文件一定要改，哪些一定不能改

哪些错误是常见误判

任务完成后必须输出什么

如果把 AI 看成一个新来的开发同学，那 skill 就像是这个项目写给他的：

上手说明

操作手册

项目规范

防踩坑清单

所以从本质上说：

Skill 不是让 AI 获得知识，而是让 AI 在特定场景下按正确流程做事。

这是我后面所有迭代的核心出发点。

三、为什么一开始 Agent 总做不对

在真正落地之前，我其实也很自然地以为：

“只要把需求说清楚，AI 应该就能做。”

后来发现完全不是这样。

1. AI 会“看起来懂”，但不等于“知道项目正确做法”

比如我让它做一个小型活动，它可能会：

猜一个参考实现

开始改脚本

甚至直接跳过配置表

从语言上看，这些都很像“在推进任务”，但实际上它已经偏了。

原因很简单：

AI 擅长补全合理答案，不擅长天然知道你们项目里的隐含规则。

而游戏项目恰恰充满隐含规则，比如：

参考活动应该先从哪张表里确认

哪个子活动默认进 tab，哪个不进

哪些资源必须问，哪些可以复用

哪些文件是导表产物，绝对不能直接改

哪种改表方式和项目工具兼容，哪种不兼容

如果这些规则没写进 skill，AI 就会开始“合理猜测”。

一旦开始猜，稳定性就没了。

2. AI 容易把“能做”误判成“应该做”

另一个典型问题是：

它确实能直接改表，也能转表，也能继续改生成后的配置文件。

但“能做”不等于“项目里应该这样做”。

后来我们实际验证发现：

用通用方式去改 xlsx，和项目转表工具可能不兼容

直接改导表后的 .lua / .json，会破坏项目流程

就算表改成功了，稳定性和调试成本也很高

所以问题不在于 AI 不会改，而在于：

它不知道哪里是能力边界，哪里是项目边界。

3. AI 会在复杂链路里逐渐漂移

一开始我们想让它一条龙做完：

读反馈表

找参考活动

改代码

改配置

转表

校验

输出结果

这条链太长了。

链路一长，任何一个环节出现偏差，后面就会越走越偏。

最后你会发现，真正让 Agent 稳定的，不是“把所有事情都交给它”，而是：

把它放在最适合自动化的那一段。

四、这次小型活动 Agent 是怎么一步步迭代出来的

这套 skill 不是一次写成的，而是被真实问题“逼”出来的。

整个过程大致经历了四个阶段。

五、第一阶段：先把“要做什么”写清楚

一开始我们做的最基础动作，是把这个场景收敛成一个明确边界：

适用范围

纯客户端为主

无新增子活动

优先复用参考活动