日常AI使用心得分享

AI使用背景

  • 使用 AI 辅助编程，我主要依赖 ChatGPT 的付费版本。这种长期使用让我感受到 AI 的强大功能和便捷，同时也逐渐形成了一些个人使用心得和偏好。

ChatGPT与Windsurf的比较

  1. ChatGPT的优势
  • 由于我使用的是付费版本，ChatGPT 在整体体验上更优，幻觉（生成错误信息）相对较少。
  • ChatGPT 在处理复杂任务和明确上下文时表现更稳定，能够更准确地满足需求。
  1. Windsurf的不足
  • 即使在上下文明确的情况下，Windsurf 仍然会产生较多幻觉（和chatgpt的4o网页版横向对比）。
  • 有时会生成错误或不存在的代码调用，导致需要额外验证和修正。

编写 Rustrpc_sdk Crate 的经验

项目背景

  • 我有一个 rpc_sdk 的 crate，其中大部分代码是结合了 AI 的辅助，进行多轮迭代最终完善的。

早期的一些prompt

  • 框架设计: 在项目开始前，需要明确需求并设计好整体框架。
  • Prompt 示例: 以下是当时使用的 Prompt：
这是我当前Cargo工程的状态，麻烦你更新一下记忆，我要基于这个工程，进行持续迭代


(这里会是我整理的一个txt，主要描述了相关的Cargo工程的初步设计)
(包括： 工程结构的 tree 输出)
(包括： 各个文件的初始版本API)

代码设计要求，请你牢记：
1、设计要优化，按照合理的软件工程设计方案
2、需要严格基于我给你的代码范围进行设计，增删改都可以
3、你需要严格的确认我的其他代码，规范地使用这些代码，如果你想要调用某些方法，要确认这些方法，在我的当前Cargo工程代码中，是否存在，不存在的话请不要凭空捏造它

关于代码生成，请你牢记：
1、如果你要生成某个文件的代码，请生成全量代码，按照每个文件进行罗列
2、没有修改的文件，可以告诉我你省略了这个文件的生成

关于沟通上：请牢记始终用中文和我沟通

我的需求是：

我希望基于当前Cargo工程设计进行RpcServer的实现，细节是这样的：

1、RpcServer应该有一个启动监听client连接的方法（以下是我的一些设想，如果你有更好的方案，也可以提出来）：
    它应该是一个循环
    它应该是接收工程中的RpcTransport这个特征对象，以便调用对应的listen方法
    它应该接收传入一个构建好的listener，以便在这个函数里，调用RpcTransport的listen方法时，传递进去
2、RpcServer 持有 RpcSession:
    RpcServer 创建并持有一个或多个 RpcSession 对象，这些会话对象管理与各个客户端的通信。
3、RpcServer 还应该能够管理这些连接过来的client，比如使用vec。当连接断开了，把他们移除

然后基于你的RpcServer的设计，完成main.rs的设计：
1、注意main.rs是作为rpc框架的使用者，它的任何设计都不应该沉入到rpc框架中，它是更高层的使用者
2、main.rs主要是完成server的创建，以及创建多个client进行通信，验证我的Rpc框架的使用


请你基于我当前的Cargo工程代码，进行修改设计。

后续解决问题的一些prompt

  1. 我在后续迭代的时候，会把我的整体工程的信息，在一个新的对话框里，做一下gpt的记忆更新：
  • 工程目录结构
  • 代码（甚至是全量代码）
  • 我要求的代码生成的规范
  1. 随后我会把这个 prompt 保存成一个txt，然后发给 gpt：
下面是我的Cargo项目的详细信息，有一些前提条件先跟你说明：

一下是表示代码的开始和结尾的格式
==========》start  xxx/xxx
==========》end  xxx/xxx


1. 当前Cargo项目的目录结构
rpc_sdk/
├── Cargo.toml
├── src/
│   ├── lib.rs
│   ├── main.rs
│   ├── transport.rs
│   ├── context.rs
│   ├── session.rs
│   ├── server.rs

==========》start  src/lib.rs
xxx代码
==========》end  src/lib.rs


==========》start  src/main.rs
xxx代码
==========》end  src/main.rs

==========》start  Cargo.toml
xxx代码
==========》end  Cargo.toml

==========》start  src/transport.rs
xxx代码
==========》end  src/transport.rs

==========》start  src/context.rs
xxx代码
==========》end  src/context.rs

==========》start  src/session.rs
xxx代码
==========》end  src/session.rs

==========》start  src/server.rs
xxx代码
==========》end  src/server.rs
4. 当前设计的思考
Transport 层: 提供了不同类型的传输方式，如 UnixSocketTransport、VSockTransport 和 InetSocketTransport。通过定义通用的 Transport trait，实现了 connect 和 bind 方法的统一接口，减少了代码重复。
上下文管理: 通过 RpcTransportCtx、RpcTransportCtxServer、RpcTransportCtxClient 实现了对传输上下文的抽象管理，使得 RPC 服务器和客户端可以方便地管理传输连接。
Session 管理: RpcSession 通过包装 RpcTransportCtxClient 来处理 RPC 会话的发送和接收逻辑，确保会话逻辑的整洁与可扩展性。
设计目标: 该设计旨在提供一个模块化、可扩展的 RPC 框架，具有清晰的职责划分，能够支持多种传输方式，并简化上下文管理和会话处理的代码复杂性。
通过 AI 的协助，我节省了大量时间，并能专注于代码的优化和迭代。

明确 Prompt 的重要性

  • 上面的我自己的经验就是：通过明确的 Prompt，可以显著提升 AI 生成结果的质量。以下是我的一个实践案例：
    • RPC_SDK的早期整体设计过程
      • 这是第一个版本的 RPC_SDK 的AI参与设计的过程其中的一些聊天迭代
    • ChatGPT 帮助解决日志解析的 Python 工具问题
      • 在这个案例中，我仅提供了问题描述，ChatGPT 便成功生成了解决方案，无需我深入研究相关代码。
      • 如果足够懒，持续在聊天中，给AI提供编译错误，AI可以debug（但因为幻觉的存在，还是会有需要看看逻辑，自己理解然后给AI提示问题关键点，能快速规避幻觉）

Prompt总结要点：

  1. 结构
问题是什么：
（明确描述你的问题，建议不要有太多主观表达）

代码是什么：
（贴代码）

错误是什么：
（如果有错误日志）

大模型需要注意什么：
（如：使用中文和我沟通等）

1. 生成代码需要按照xxx：
（生成代码是否需要全量代码）
（明确生成代码严格按照我发给你的，不要引入无关修改,Works well for me）
2. 不要长篇大论！！！
  1. 把需求拆细
  2. 把描述简单化成4-5点
  3. 原因：
    1. AI虽然可以处理很长的上下文token，从我的主观使用经验，prompt过多之后，它会漏掉很多内容
    2. 与其这样，不如少量多次给他喂prompt
3. 设计好你的架构：
  1. 当你需要AI帮你做细节设计的时候，最好设计好你的架构和API，让他补充细节，再去逐步完善
  2. 比如早期的rpc_sdk设计的prompt（关于我日常的一些AI使用心得）

关于幻觉：

  • 不论任何需求、语言（笔者试过：python、shell、rust、java、kotlin），都有幻觉产生：
出现问题1
问题1 log  -> 大模型
大模型 -> A方案
A方案 出现问题2
问题2 log -> 大模型
大模型 -> C方案
C方案规避了 问题2  重新引入 问题1
周而复始,直到你提醒他
  • 当出现幻觉，反复地在几个问题之间兜圈子是常见情况，直接介入修改代码是最佳路径

总结

  • 当前来看，AI作为辅助的细节设计工具，是非常适合的。当你有合适的框架设计之后，它能帮助你高效的实现细节
  • 幻觉的规避：熟悉代码，及时在聊天过程中协助AI完成关键问题定位
  • Prompt 优化（本质上这是文字编写能力，实际上这也是一种“编程”，卷到最后，就看作文能力）
  • 大模型可以扮演两个角色：
    • 阻塞问题帮你快速寻求解决方案的来源
    • 架构、思考设计帮你提效实现、验证的细节填充者

尚未验证的一些感受：

  • 大模型的不同，不确定是否有差异：
    • chatgpt目前支持跨聊天共享用户记忆，我不确定类似winsurf这种API调用大模型的相关方案，和网页版的差异有多大
  • 持续使用的web版，你的聊天是可以对这个模型产生一些微调（主观感受上会觉得它和你更默契一些）

 评论