记录一次我用AI帮我整理提示词的过程

背景

最近看了一些提示词工程的视频, 其中有两句话给我的感触很深

• 你无法表达大概率是因为这个需求在你的脑子没想清楚
• 这个在你脑子的需求能不能描述明白让AI明白? 所以,在向AI表达之前,最好是把需求好好梳理下,怎么梳理呢? 我觉得有两个方法
• 画图
• 和AI聊一聊,让AI扮演专家的角色,让他问你一些细节,你来回答, 这一问一答之间就能让你的需求更加清晰,最后可以让AI帮你生成提示词,你从提示词中找问题,看看他的输出和你的想法是否一致,这样就能提高AI回答的准确性,特别是使用类似Cursor较少拉扯的时间

下面是我让AI帮我梳理需求的一次实战

我的需求是: 我想改造 pomelo框架,要求从长连接变成短连接, 去掉master-worker模式, 但保留绝大部分pomelo的功能,特别是filter和component等

我有一个比较旧的项目,是使用pomelo这个游戏框架实现的,但这个框架已经很多年没维护了, 我们想做一些改进
1. 废弃master-worker模式, master-worker模式太笨重了, 可以使用redis作为中间件实现服务的注册和服务的发现
2. 废弃长连接, 于客户端使用http协议
3. 废弃现有服务器中间的rpc协议, 进程间使用http协议通讯即可
别的pomelo中的功能不用修改,特别是需要支持 filter和component
另外我希望通过pm2来管理进程
这是Pomelo框架的源代码:https://github.com/NetEase/pomelo
这是Pomelo框架的文档: https://github.com/NetEase/pomelo/wiki
现在我希望你站到一个专家的角度来问我问题,让我来确认细节

这里我让AI扮演一个专家的角色,让他向我提问, 让我确认细节 下面是他的回答

作为游戏服务器架构专家，我需要了解更多关于您计划的Pomelo框架改进细节，以便提供有针对性的建议。

## 关于废弃master-worker模式

1.  您计划使用Redis实现服务注册和发现的具体机制是什么？会使用哪些Redis数据结构？
1.  原master节点的管理功能（如启动顺序控制、监控、日志聚合）将如何迁移到新架构？
1.  服务器间的心跳和健康检查机制将如何设计？

## 关于废弃长连接转为HTTP

1.  原框架中的推送机制如何在HTTP模式下实现？是否考虑WebHook或轮询方案？
1.  游戏场景通常需要实时性，HTTP会带来什么延迟问题？您有什么应对策略？
1.  是否考虑在特定场景保留WebSocket作为补充？

## 关于服务间通信改为HTTP

1.  原有RPC调用的频率和数据量是什么级别？HTTP能否满足性能需求？
1.  服务间HTTP调用的路由和接口设计思路是什么？
1.  如何处理服务间调用的错误重试、超时控制和熔断机制？

## 关于保留功能

1.  Pomelo的filter机制如何在新架构中保持其工作流程？
1.  component系统需要哪些调整才能在新架构中正常工作？
1.  是否需要重新设计应用的启动流程和生命周期管理？

## 关于PM2集成

1.  如何设计PM2配置来替代原有的master进程管理功能？
1.  服务发现后，进程间如何建立初始连接？这与PM2的进程管理如何协调？
1.  计划如何使用PM2的监控和日志功能？

## 关于迁移策略

1.  您计划采用渐进式迁移还是一次性重构？有没有制定具体的迁移路径？
1.  如何确保在迁移过程中系统的稳定性？
1.  有没有计划编写兼容层来减轻迁移难度？

我很期待您的回答，这将帮助我们深入探讨可行的实现方案。

可以看到他提了不少的问题给我,我通过回答这些问题,更加明确了我的需求和目标

我来回答这些问题, 关于废弃master-worker模式: 第一: 去掉master的控制台, 监控,日志聚合功能 第二和第三: 服务发现和服务注册,使用一个通用的库即可, 不用太关心细节

关于废弃长连接转为HTTP: 暂时不考虑推送,可能会考虑客户端定时请求的方式来实现推送

关于服务间通信改为HTTP: 可以先使用HTTP, 后期考虑换成性能更高的协议,现在只是可行性的调研阶段,没必要弄的太麻烦

关于保留功能: 处于老项目的原因, 我希望 filter 和component 保持原来Pomelo相同的功能,同时我希望还有pomelo之前的功能 ,比如通过服务器类型来添加独有配置什么的,这样我的老项目代码能最小范围的改动

关于PM2集成: PM2提供最简单的进程管理方式就可以了,我希望很直观的看到进程信息,CPU内存是否重启等信息,服务发现和注册也不需要和PM2有什么关系 如果没有别的问题的话,帮我生成Cursor使用的提示词

在回答了这些问题后,我让他帮我生成Cursor的提示词

但他好像还没有确认完细节,向我提了更多的问题

1.  关于filter和component：

    -   您希望保持原有filter链式处理请求的方式不变，对吗？
    -   component的生命周期（如start、afterStart等）是否需要完全保持一致？

1.  关于服务路由：

    -   在没有master的情况下，前端服务器如何知道应该将请求路由到哪个后端服务？
    -   服务器类型和服务器ID的概念是否保留？

1.  关于会话管理：

    -   既然转为HTTP，Pomelo原有的session管理将如何处理？
    -   用户认证和会话状态将如何保存？

1.  关于配置管理：

    -   Pomelo的app.configure()配置方式是否需要保留？
    -   服务器类型的差异化配置如何设计？

1.  关于项目结构：

    -   是否仍需要保持Pomelo的目录结构（如app/servers/...）？
    -   是否需要支持类似pomelo start/stop的命令行工具？

根据您的回答，我将为您生成一个详细的Cursor提示词，用于指导实现这个改进版的Pomelo框架。

我回答了他的问题

关于filter和component filter和component,要和pomelo一致

关于服务路由： 第一,请求的时候会有参数标记是哪一个后端进程,比如/user/get_info 就是请求user进程 第二,服务器类型和ID可以保留,在记录日志的时候可以输出这个ID,方便日志的追踪

关于会话管理： 不要Session了, 认证方式改为Token认证, 原来放到Session中的参数,需要客户端请求时再传一次

关于配置管理: Pomelo的app.configure()配置方式是否需要保留:保留 服务器类型的差异化配置如何设计: 请求总是发送到前端进程然后被转发到后端进程

关于项目结构: 保持原来的目录结构 命令行工具不需要支持了

接下来,他帮我生成了Cursor的提示词

我需要基于Pomelo游戏服务器框架(https://github.com/NetEase/pomelo)创建一个轻量级改进版本，主要变更如下：

## 核心改进点
1. 废弃master-worker架构，使用Redis实现服务注册和发现
2. 将客户端通信协议从Socket.io改为HTTP
3. 将服务器间RPC通信改为HTTP通信
4. 使用PM2管理进程替代原master进程管理

## 必须保留的功能
1. Pomelo的filter链式处理机制，保持接口和使用方式完全一致
2. Component系统及其生命周期(start, afterStart等)
3. 服务器类型(serverType)和服务器ID概念
4. app.configure()配置方式，支持按服务器类型配置
5. 原有的目录结构(app/servers/...)

## 技术实现细节
1. 服务路由：请求URL包含后端服务器类型，如/user/get_info路由到user类型服务器
2. 认证机制：使用Token认证替代Session，客户端需在每次请求中传递认证信息
3. 服务注册发现：使用通用Redis方案，不需关注具体实现
4. 日志系统：需记录服务器类型和ID便于追踪
5. PM2集成：提供基础进程管理，展示CPU/内存使用情况

## 主要实现模块
1. 应用初始化和生命周期管理
2. HTTP服务器和路由系统
3. 服务注册与发现
4. 前端到后端的请求转发
5. filter链处理机制
6. component系统
7. PM2配置文件

请保证代码实现简洁、模块化，并确保与原Pomelo项目的接口兼容性，使老项目代码能最小范围地改动。

可以发现他帮我生成的就很细节和具体了, 我把这个提示词贴到Cursor中,去生成的结果也不错.

总结

让AI扮演专家的角色,帮我们梳理需求, 其实是一个自我整理的过程,特别是一个比较大的需求的时候,AI看得懂生成出来的代码质量就高,而模糊的需求终究会换来的是模糊和低质量的代码, 其实这也反映了脑子里的需求并不明确,或者是脑子里的需求没有很好的映射成文本. 我一直有一个感觉, AI的水平就是自己的水平.