这是一篇关于使用大型语言模型（LLMs）进行编程的个人经验总结，涵盖了使用 LLMs 的背景、日常编程中的三种方式（自动补全、搜索、聊天驱动编程）、为何使用聊天、聊天式 LLMs 的最佳应用场景、额外代码结构的优势、一个示例以及未来的发展方向等内容：

• 背景：对新技术好奇，LLMs 能生成复杂响应和编写程序部分，感觉像 1995 年接入互联网，想探索其在日常工作中的价值。

• 日常编程中的方式：

  • 自动补全：可节省大量重复打字时间，标准产品也比无任何辅助好，是首先可尝试的方法。
  • 搜索：在复杂环境中询问问题，LLMs 比传统搜索引擎能提供更好答案，虽有时会出错但可接受。
  • 聊天驱动编程：虽最有价值但也最令人困扰，需学习并调整编程方式，原则上不喜欢这种非确定性服务，但目前致力于逐步解决问题，目前记录为每两小时编程接受超 10 次自动补全建议、进行一次类似搜索任务和一次聊天编程。
• 为何使用聊天：在一天中知道需要编写什么但缺乏精力创建新文件和查找库时，LLMs 可提供初稿，包含一些好想法和依赖，修复错误比从头开始更容易。适用于产品开发类编程，不断在不同环境和语言间切换。

• 聊天式 LLMs 的最佳应用场景：

  • 避免创建使 LLM 困惑产生坏结果的复杂模糊情境，如在 IDE 中效果不佳，更喜欢通过网页浏览器使用以获得空白 slate 来提出明确请求。
  • 要求易于验证的工作，如让 LLM 重写测试以利用重新工作成本低的优势，使用前需通过编译器和运行测试。
• 额外代码结构的优势：LLMs 影响代码结构的权衡，更多更小的包使 LLM 能更易给出完整隔离的工作上下文，且独立编译测试，对 LLM 开发周期有帮助。
• 一个示例：以编写浮点数四分位数的蓄水池采样器为例，展示了包结构选择、LLM 生成代码及后续改进，包括修复编译错误、添加更好的测试等，过程中体现了 LLM 能在工具错误时做出有用进展，有时无需人工干预。
• 未来的发展方向：过去 10 - 15 年编程倾向于更注重权衡，现在更容易编写更全面的测试，语言特定的 REST API 包装器可能更倾向于自定义客户端，未来可能有更专业化的代码、更少的通用包和更易读的测试，一些人已构建早期原型[sketch.dev]，旨在为 Go 编程提供围绕编辑包和测试、带有聊天界面等功能的环境，将其视为“Go IDE for LLMs”，仍有很多工作要做，如集成 git、更好的测试反馈等。