从今年年初到现在,一直在使用Cursor进行辅助编程, 一边感叹着Cursor的强大, 另一边又陷入了一种极端: 我想让AI帮我实现全部的功能. 这是一种"矫枉过正"的想法, 在没有AI辅助编程前全是手搓代码,有了AI辅助编程后又想全部的代码都由AI来帮我完成.
超长提示词
我所在的是一个老虎机项目,在业务上主要是以定期的推出"机台"和"活动", 我在用AI辅助编程时为了让AI来实现功能时总会写很长的提示词, 下面是我的一个完整的提示词
## 必要信息:
配置文件: @subject_tmpl_267.json
数据存储: @FrankenFortuneSpecial.js
symolIds: 是一个二维的数组,类似: [[1001,1001,1001],[1002,1002,1002],[1003,1003,1003]], 我们把数组看成是一个表格每一个大项是列, 小项是行,例子中就是一个 3列3行
## 需求
### 全局定义
红色WILD图标ID=1
紫色WILD图标ID=1101
蓝色WILD图标ID=1102
### 累计Totalbet
添加`累计Totalbet`和 `累计Spin次数`的存储字段
每次SPIN都需要把TotalBet进行累计
### 生成角标
#### 配置
在配置文件中的 `tailConfig`字段中
#### 步骤
1. 通过配置中的`tailConfig.addCountProbs`概率获得生成角标的数量
2. 随机从`symbolIds`中找到对应角标数量的位置
3. 构建成`tailInfo`对象列表, 字段包括: pos
这个过程我们称之为在`symbolIds`中添加角标
#### 要求
1. 每一列最多只有一个`tailInfo`
### 角标小转盘
#### 配置
在配置文件中的 `tailWheelConfig`中
#### 步骤
1. 循环判断panel中的每一条赢钱线
2. 如果赢钱线经过了角标位置,则累计角标的数量,我们记为: `tailCount`
3. 旋转`tailCount`次小转盘
a. 确定概率配置: 通过判断`tailCount`的数量, 使用不同的配置,例如`tailCount`如果只有2个, 则使用`tailWheelConfig.wheelMultiProbConfig["2"]`的概率,第一次转小转盘使用`tailWheelConfig.wheelMultiProbConfig["2"][0]`的概率,以此类推
b. 通过概率获得对应`wheelMultiList`配置的倍数
c. 将倍数都记录到一个数组中,并进行累计:我们记为: `totalWheelMulti`
4. 判断是否需要re赢钱钱
a. 确定概率: 例如`tailCount`数量是2,则使用`tailWheelConfig.reConfig["2"]`,以此类推
b. 计算总赢钱: 我们把`totalWheelMulti` * `winRate` 得到本次的总赢钱,概率判断是否需要re掉,如果需要,则再次旋转`tailCount`次小转盘,并再次判断是否小re赢钱
### 收集wild
#### 配置
在配置文件中的 `pickConfig`中
#### 步骤
1. 添加存储字段,用于存储收集到的`wild`图标
2. 找到panel中的全部`wild`图标,并进行存储和累计
### PICK
#### 配置
在配置文件中的 `pickConfig`中, 其中`pickItems`字段表示PICK的备选项 ,正数代表倍数CHIPS, -1:金币 -2: 骷髅
#### 步骤
0. 添加存储字段, 用于存储PICK到的金币数量
1. 通过比较收集的`wild`的数量和配置`needWildCount`的数量,如果>=了则说明收集满了,则触发了PICK
2. 通过`configProb`概率选择配置, `configProb`下标是多少就用`configs`字段的哪一个配置,我们把真正使用的配置叫`config`
3. PICK: 第一次PICK使用`config`中的第一项, 以此类推, 构建成一个权重, 概率选中`pickItems`中的项,
- 如果是金币,就累计存储起来
- 如果是倍数CHIPS,则累计起来
- 如果是骷髅也累计起来,如果累计到了两个骷髅则PICK结束
#### 要求
构建PICK的整个过程
### 执行流程
flowchart TD
A["累计TotalBet和SpinCount"] --> B["生成角标"]
B --> C{"是否有角标在赢钱线上"}
C -- 是 --> D["触发角标小转盘玩法"]
n1["收集wild"] --> n2["是否收集满了"]
n2 -- 是 --> n3["PICK"]
D --> n1
我用三段式的提示词方法写了这么长的一段提示词,让AI去理解玩法, 去理解配置在什么地方, 应该怎么用等等(为了让AI理解我甚至给他弄了一张流程图)
长提示词生成的结果
优点
当然效果还是不错的, 生成出来的代码确实是已经到了能用的程度了, 写这么长的提示词当然也不是完全没有好处, 至少帮助我更深入的理解了业务
缺点
写提示词的时间基本上已经超过了我手写代码的时间了, 我们让AI辅助我们编程的目的是为了提高效率, 但从这里看来好像并没有提高多少. 另外一个问题是,对于长的代码在一些小的细节问题上很难发现.
开始反思
在开发一个比较复杂的机台时,我发现我很难通过书面语言来完整的给Cursor表达出来我的需求和玩法, 特别是遇到了一些 之前有过的功能 对我们来说,是代码的拷贝和一些细节的修改, 但我好像没有很好的办法来告诉Cursor,我应该在什么地方复制代码并改动一些小的细节. 于是就出现了, 我写自己写代码比我写提示词让AI帮我写代码省时省力很多. 是不是我用的方式不对呢? 是不是有点矫枉过正了?
怎么更好呢?
怎么用当然没有定论, 每一个人的用法不同, 但对于现阶段的我来说,我应该不会再写这么冗长的提示词了, 我更倾向于:流程我来控制, 在写代码时通过 "注释或唤起AI交互框的方式帮我实现逻辑和完善代码" 这样我发现更省力, 而且相比完整的生成代码来说更可控和安全,当然对于每一个人来说用法都不会相同,有的人倾向于写更完整的提示词,让AI组织代码, 有的人更倾向于流程自己把控,AI辅助. 这是现阶段的我更倾向于后者. 这也是我前段时间使用Cursor的一些思考吧.
