与ChatGPT合作开发软件：一种迭代探索的方法

图1. 作者绘制的情感锚点分析图。

本文继续探索使用ChatGPT进行软件开发的过程。它展示了人与AI之间的协作如何能够改进并加速解决问题。今天的文章强调了一种迭代互动的方式，结合了探索、选择性优化回应和同行评审解决方案。这种方法基于Yehonathan Sharvit关于认知跨度——记忆、注意力和结构的假设，这些是理解及操作代码的关键因素。这些“脑跨度”作为与生成式AI有效合作的视角，是理解及操作代码的关键，其中显式管理上下文和保持清晰度至关重要。

这种方法结合了人类直觉与AI的逻辑推理，平衡了人类直觉与AI的逻辑推理，尊重编程的认知挑战，并且这与讲故事的艺术相呼应——叙事在合作者之间相互交织。

之前我写过一篇文章，讨论了在软件开发中与生成式AI合作的重要性。在那篇文章中，我还介绍了代码生成任务的作用。

…说明人类与AI合作的重要性，强调当人类的专业知识提升AI的效果时所实现的协同效应。通过提供有针对性的知识和上下文，可以更好地引导模型输出到实际解决方案。这种协作展示了人类直觉和AI辅助如何能够相互补充，从而取得良好效果。

与“劣质科幻”协作软件项目进展相关的文章和链接位于 这个GitHub。正如该文章所述，项目因此得名，其目标是开发一个专门用于科幻小说分析的工具——这个工具将与生成式AI共同开发。

这篇文章是一份实干报告——一个让你深入工作并完成任务的机会。它还采用了探索性互动风格，我会根据情况选择合适的回应。虽然这需要一定的专业知识，但这样做更快且更高效。设计与编程相结合具有优势，尤其是在与人工智能合作时——无论何时需要，你可以随时跳入或跳出，以确保高效运转。

我和ChatGPT的软件合作一直非常有效，而且成效显著。正如我之前所说，我们合作中的关键在于互动：我提出很多问题，挑选那些引起共鸣的想法并加以提炼，然后重复这个过程。这种方法与依赖少数几个大型和详细的提示形成鲜明对比。

这里的迭代解决问题的力量得到了展示。我一开始有一个想要实现的想法，但其实现却是通过不断的优化、反馈甚至一些试错才逐渐成型。在这个合作过程中，我用ChatGPT来帮助充实我的想法，然后进一步探索和细化这个方法。

这次我自己动手做了更多的实施工作。软件和项目变得越来越复杂，使得有效的提示变得更加困难，因为这需要更精确的上下文。当接下来的任务比较简单时，我发现直接撸起袖子“动手干”往往更简单。然而，如后面提到的，让AI对重要的决策进行同行评审也是有好处的。

下面的提示是我最初的主意，它是我对ChatGPT的主要请求。这是我们的对话起点。我们花剩下的时间细化和调整，将结果逐步落实到实现中。

    请将以下Visual Studio C++ Windows GUI应用程序的源代码扩展，以显示以下内容：

1. 一个基本的文本编辑器。

2. 显示顶部的一行菜单。

3. 一个名为“获取文本内容”的下拉菜单。

4. “获取文本内容”下拉菜单下的一个子菜单选项，名为“从剪贴板”。

5. “获取文本内容”下拉菜单下的一个子菜单选项，名为“从文件”。

6. 一个名为“处理”的下拉菜单。

7. “处理”下拉菜单下的一个子菜单选项，名为“情感锚点”。

    我希望能够实现以下行为：

1. 当用户选择“获取文本内容”>“从剪贴板”子菜单
       然后客户端应用程序会获取Windows剪贴板的内容，并在文本显示中显示。

2. 当用户选择“获取文本内容”>“从文件”子菜单，则
       客户端应用程序会允许用户浏览文件系统以便选择要显示在应用程序中的文本文件。

3. 当用户选择“处理”>“情感锚点”子菜单，则
       客户端应用程序会处理文本显示中的文本内容，调用sentiment_main()函数（位于SentimentAnchors.cpp中），并传递给剪贴板文本或文件路径。

    （代码省略）

对于本文中描述的代码相关交互，我使用了ChatGPT o1-preview跨越多个长时间会话。对于涉及LaTeX的交互，我使用了ChatGPT 4o。

在我们的交流中，ChatGPT在编码方面帮了大忙，但在一些细节上表现得不够完美，特别是在我的Microsoft Visual Studio解决方案配置上。

大多数情况下，ChatGPT的配置错误可能是由于目标冲突引起的。我最初要求它将我现有的Visual Studio控制台应用程序转换为Windows图形界面应用程序。然而，它的指导却反复假设我会创建一个新的Windows图形界面项目。最终，我还是根据它的建议手动创建了一个新项目。

一旦我的新项目创建完成，我让ChatGPT根据原来的提示更新代码。图2列出了系统中的软件项目。BSF-AnchorClient 是一个现已弃用的Windows控制台应用程序，已被新的 BSF-WindowsAnchorClient 替代。

图2: 作者提供的这张图片。

ChatGPT修改的代码在Windows GUI/Visual Studio环境中构建得很完美，除了一个小尾巴（即缺少一个标准头文件）外无需任何修正。ChatGPT在我的一个源文件中添加了一个不存在的头文件引用（见图3）。

图3。作者提供的图片。ChatGPT被提示纠正生成标准头文件时的一个疏忽。

在 ChatGPT 明显倾向于让我从一个新的 MSVC++ Windows GUI 项目开始之前，我明确地询问了它将我现有的 MSVC++ 控制台应用程序转换为 Windows GUI 项目步骤。我按照它的步骤操作，但遇到了困难。经过大约 15 分钟的故障排除，我最终决定还是按照 ChatGPT 的建议，手动新建一个项目。

我怀疑ChatGPT更偏向于在训练过程中多次遇到的方法。虽然它可以被引导到其他方法，但由于这些路径上的训练样本较少，因此这些路径可能带有更大的风险。

以下是一些该工具的关键功能：

• 文本预处理步骤：Python 情感服务器通过移除停止词和分词来预处理文本窗口和情感标志，以提高分析的准确性。
• OpenAI 的词嵌入：服务器使用 OpenAI 的词嵌入来计算文本窗口和情感标志之间的语义相似性，确保情感判断的准确性。
• 通过 HTTP 输出图像。它还会输出原始数据为 CSV 文件。

图4展示了整个系统的更新架构。它是由ChatGPT o1根据附录中的源代码和之前的架构图生成的LaTeX代码。主要的三个软件组件是：一个C++客户端，一个Python服务器以及一个Python可视化器。

图4。作者的图片。ChatGPT 4生成了LaTeX代码，在overleaf.com上进行了渲染。

更新的 Windows 图形界面客户端取代了之前的命令行版本。它可以从中获取 Windows 剪贴板中的输入文本，并允许用户使用 Windows API 浏览文件系统中的文件。如图 5 所示，Windows 图形界面客户端在 Visual Studio 开发环境中运行。

图5。新Windows GUI客户端在Visual Studio开发环境中运行。显示的文本为测试数据。

创建一个新的Windows GUI客户端项目并使用ChatGPT更新的源代码（详见附录A）更新其代码后，我测试了整个应用程序或系统。在测试过程中发现了一个问题：

    临时文件路径：C:\Users\natha\AppData\Local\Temp\temp_text.txt（例如）  
    临时文件已写入。  
    调用 sentiment_main 函数。  
    在 BSF-WindowsAnchorClient.exe 中于 0x00007FFE8A32FA4C 处抛出异常：std::runtime_error（内存位置：0x0000008F14D4DE28）。  
    sentiment_main 函数执行完毕。  
    线程 19168 已退出，退出码为 0（十六进制表示为 0x0）。

输出没有提供太多有用的信息。我将错误和源代码分享给了ChatGPT，并问它有没有解决的建议。它提供了一个可能性列表——一个它认为我应该检查的事项清单。首要建议确定了实际原因：因为它的相对路径不正确，一个内部数据文件无法读取。

我让ChatGPT增加调试信息后确认了原因。

    你能把下面的函数更新一下，使其通过OutputDebugStringA输出进度？

我不明白为什么之前一直可以正常工作的相对路径突然无法使用了。然而，通过更详细的调试信息，我很快找到了根本原因。错误是由新版Windows GUI客户端的一个奇怪的行为引起的。当我从菜单中选择输入文件时，它会把程序的工作目录改到我选择文件的位置。

那时，我计划将我的系统中的所有相对路径改为绝对路径。然而，我请 ChatGPT 帮忙看看该问题，来确认我的方法是否正确。它给出的建议基于对 Windows API 的深入理解，提出了一个更好的解决方案。我给它的提示内容如下：

    以下是我为Windows Anchor客户端GUI编写的C++代码。
    我遇到的一个问题是，当我运行客户端并使用文件选择器（菜单选项）时，它会将工作目录变为文件选择器最后访问的目录。
    这会影响使用相对路径指定锚点文件的能力："./resources/sentiments.txt"

    我不想切换到绝对路径。有没有什么解决方法？

    (代码已移除)

图6展示了ChatGPT的解决方案，该方案是在Windows API调用中加入了OFN_NOCHANGEDIR标志。

图6。作者的图片。ChatGPT o1-preview 评估了一个解决方案并进行了优化。

经过进一步的测试，我注意到系统性能不稳定——有时候运行迅速，有时候却异常缓慢。我让ChatGPT升级了核心服务器的日志记录，它顺利完成了。这使我能够识别出瓶颈：远程访问OpenAI的API。有时这些调用几乎没有延迟，但其他时候却慢很多。我让ChatGPT增加更多的日志记录以便更好地追踪问题，还问它有没有什么建议或想法。

    你能更新下面的代码以包含高层次的指示——在每次调用时输出进度信息。在连接到OpenAI较慢的情况下，有什么提高性能的建议吗？   

    # 定义用于文本分析的API端点  
    @app.post("/analyze", response_model=AnalysisResult)  
    def analyze_text(data: AnalysisRequest):  

    此处省略代码

ChatGPT给了我很好的建议。它建议将嵌入请求批量处理并缓存到OpenAI的API——这是一项策略，我记得API最初发布时读到过但后来忘记了。我立刻采用了这个建议。ChatGPT还提供了代码改动：

    # 步骤6：获取情感锚文本和文本窗口的嵌入
    logging.info("记录日志：步骤6，获取情感锚文本和文本窗口的嵌入。")

    # 嵌入缓存
    embedding_cache = {}

    # 合并锚文本和窗口以进行批量处理
    texts_to_embed = preprocessed_anchors + preprocessed_windows
    unique_texts = list(set(texts_to_embed))

    # 批量嵌入唯一文本
    text_embeddings = embeddings.embed_文档(unique_texts)
    logging.info(f"获取了{len(unique_texts)}个唯一文本的嵌入。")

    # 将文本映射到嵌入
    for text, embedding in zip(unique_texts, text_embeddings):
        embedding_cache[text] = embedding

    # 从缓存中获取这些嵌入
    anchor_embeddings = [embedding_cache[text] for text in preprocessed_anchors]
    window_embeddings = [embedding_cache[text] for text in preprocessed_windows]

    # 接下来继续进行相似性计算，就像之前的步骤一样

我们在OpenAI API中加入了批处理和缓存嵌入调用请求，这样问题就解决了。

工具的最后一个主要改进是增加了在浏览器中展示数据可视化的功能。Python服务器组件升级了一个实验性的HTTP端点（/visualize），可以在浏览器中访问。图1展示了该功能的一个示例输出。我正在探索替代之前生成CSV文件并使用Python脚本进行可视化的方案。提示如下。ChatGPT实现了一个新的REST端点，我可以轻松地将其整合进来。

    可以用另一个端点更新服务器吗？  
    我希望能得到一张显示分析结果（图表形式）的图片。  
    可以缓存分析的结果，在调用/visualize时，返回最近一次分析的图。  
    提供一个HTTP端点。

我们与ChatGPT的持续合作代表了在软件开发中，人类直觉与AI驱动问题解决能力结合的故事。今天的更新重点在于迭代和探索性的互动方式——通过目标导向的探索、精炼回应以及同行评审解决方案来提升结果。

我感觉到了 耶霍纳坦·沙尔维特关于认知跨度的假设 的回响——记忆、注意力和结构的方面。在与人工智能合作的过程中，发现尊重这些跨度对于理解和操作代码来说非常重要。人类指导和人工智能辅助之间的互动需要明确管理上下文、清晰沟通和具备适应性。

在这个过程中，编程变得像讲故事一样，协作伙伴之间的流畅交流就像故事中的节奏一样。让我们来看一下 Sharvit Yehonathan 的假设：

代码难以阅读是因为它不考虑我们的认知习惯。

记忆跨度。
注意力跨度。
结构跨度。

从这些有故事的特点中，Sharvit总结出三条基本原则：

保持你的函数简洁。
保持单一抽象层次。
给函数起有描述性的名字。

对于AI的角度，我会将“读”翻译为“理解和操控”，并强调高度交织的合作方式如何凸显了尊重AI界限和认知范围的重要性。比如Sharvit提出的AI提示语三条基本原则，

• 将任务分解成每个提示中的小而具体的块。
• 避免使用未明确定义的私人抽象或自定义术语。
• 利用 LLM 在训练过程中可能理解的广泛使用的抽象概念。
• 与 LLM 协同迭代，为你们使用的代码块引入描述性的名称和准确的注释。

通过生成式AI讲故事似乎也需要主动的“互动”。如果模型总是倾向于某些特定的解决方案，这可能并不意味着更好的方法，而是反映了它的训练模式——它在数据中接触到这些模式。虽然可以引导AI采用更非传统的途径，但这些途径可能伴随着更高的风险——你应该准备好应对这些风险，因为训练数据中支持这些方法的例子较少。

通过清晰沟通、细心迭代以及对AI和我们自身局限性的了解，我们可以在这种将人类直觉与大型语言模型（LLM）广阔而有结构的合作相结合的问题解决中发现新的见解。

更多详情请访问此GitHub页面 链接，可找到其他文章和博客的链接。

Sharvit, Y. (2023年10月23日). 编程中的故事讲述：如何清晰且有目的性地编写代码. Semaphore 博客文章. 访问 https://semaphoreci.com/blog/storytelling-programming，2024年11月23日获取.

升级软件:

• Windows GUI 客户端——替代命令行版本
• 客户端可以直接从 Windows 剪贴板读取文本内容，或允许用户通过浏览文件系统选择输入文件。
• 升级的 Python 服务器——提供图形。

更新后的源代码的主要部分链接为该 GitHub Gist：

2024年11月22日 代码更新：https://github.com/Nate-BadScienceFiction/Bad-Science-Fiction-Anchor-Tool/tree/new-windows-client

• 一些源代码文件：
• BSF-WindowsAnchorClient.cpp
• SentimentAnchors.cpp
• SentimentServer.py