Dual AI Relay Development of Desktop Software: From Crashes to Release

Title

Dual AI Relay Development of Desktop Software: From Crashes to Release

Meta Description

B站UP主实录：两个AI通过GitHub接力开发Windows桌面软件，经历语法错误、剪贴板闪退、权限翻车后成功发布。详解协作机制、自愈闭环与工程化启示。

Article Content

当AI编程工具遍地开花，真正交付过软件的人都知道：让AI写代码只是最简单的一步。为了验证双AI接力能否发布一款可用桌面软件，B站UP主“玩客笔记”进行了一次实验：开发Windows本地大模型部署工具，核心代码全交给两个AI，自己只负责流程衔接。经历语法错误、闪退、权限翻车后，软件最终成功发布。本文基于视频实录，拆解协作机制与翻车自愈过程，并给出工程化思考。

双AI如何接力：GitHub issue串起架构与实操

没有花哨框架，UP主用GitHub issue和PR将两个AI穿成链：云端ChatGPT扮演架构师，负责界面设计与XAML代码生成；本地测试机上的agent扮演实操工程师，负责调用系统底层、真机编译和跑测试。两端沟通全走GitHub issue和PR——云端提代码，本地跑测试，一旦报错，本地把日志贴回issue让云端改。

这种机制的关键在于本地agent绝不擅自脑补代码，只做真实编译和测试，把错误原样反馈。从黑框命令行原型到完整WPF桌面客户端，项目就这样交接出来。

GitHub issue 与 PR 作为协作接口：GitHub issue 是用于记录任务、缺陷和讨论的工单系统，PR（Pull Request）则是代码变更的合并请求。两者天然具备“提出-讨论-修改-验证”的闭环结构，且每一条评论、提交和日志都可追溯。在本实验中，云端 AI 将生成的 XAML 代码和修复补丁以 PR 形式提交，本地 agent 在真实环境中编译测试后，把错误日志直接贴回对应 issue，云端 AI 依据这些结构化反馈进行定点修改。这种机制避免了 AI 之间“空对空”的臆想，确保每次迭代都基于可验证的事实。对于多 AI 协作场景，issue/PR 提供了一种低成本的异步通信协议：无需实时对话，只需约定好“谁在什么位置写什么、谁负责验证并回传结果”，就能将设计生成与真机测试串联成可靠流水线。

第一次翻车：漏写大括号与自愈闭环

重购主界面时，本地编译终端爆出CS1513语法错误。原因很搞笑：云端AI写XAML时漏掉一个闭合大括号。双端机制下，本地agent抓包报错日志贴回issue，云端AI拿到真实报错几秒内定位断点，出具补齐括号的定点补丁，本地重新编译瞬间通过。

AI犯错不可怕，可怕的是没有自我修复的真实闭环。这次小翻车验证了闭环的有效性。

CS1513 语法错误：CS1513 是 .NET 编译器（C# 编译器）的典型错误代码，提示“应输入 }”，即编译器在解析代码时发现某个作用域缺少闭合大括号。这类错误通常由括号不匹配、嵌套层级错乱或代码生成时遗漏引起。在本例中，云端 AI 生成 XAML 时漏掉一个闭合大括号，导致后续所有代码被错误解析，本地编译直接中断。CS1513 属于低级语法错误，但对 AI 而言并不罕见——大模型生成结构化代码时容易在深层嵌套处丢失符号。关键在于，本地 agent 抓取到包含 CS1513 的完整编译日志并回传后，云端 AI 能根据错误行号和上下文快速定位断点，出具补齐括号的定点补丁。这验证了“真实报错驱动修复”的有效性：比起让 AI 自行审查代码，将编译器输出的精确错误信息作为反馈信号，能大幅缩小问题空间，提高修复成功率。

协作渐入佳境：114项测试与403兆安装包

跨过预发坎后协作顺畅起来。硬件检测、模型下载、服务保活、局域网代理四个核心页面咬合，本地测试机一口气跑通114项自动化功能测试。打包脚本打出403兆Windows独立安装包，物理机上一路点击下一步，向导顺利拉起，浏览器里本地模型也能丝滑对话。

第二次翻车：剪贴板崩溃与三次退避热修复

发版前夕最后一轮实测，测试员点了一下复制API地址，软件当场闪退，事件查看器抛出0x800401D0——剪贴板打开失败。Windows下剪贴板被后台短时独占时强行写入会引发COM崩溃。

AI第一次修bug想加try catch吞掉异常，被本地质检当场叫停。最终云端提交PR9最小热修复：加入最多三次退避重试并补齐并发单测，测试用例扩充到124项全部通过。

0x800401D0 与剪贴板 COM 崩溃：0x800401D0 是 Windows 平台常见的 COM 错误代码，对应“CLIPBRD_E_CANT_OPEN”，表示剪贴板被其他进程占用而无法打开。在 Windows 中，剪贴板是全局共享资源，当后台程序（如剪贴板管理器、输入法、远程桌面等）短暂独占剪贴板时，应用程序若强行调用 Clipboard.SetText 等 API 写入数据，就会触发 COM 异常并导致进程崩溃。正确的处理方式不是简单用 try-catch 吞掉异常，而是加入退避重试机制：在捕获到剪贴板打开失败后，等待短暂时间并重试，最多尝试若干次（本例为三次），同时配合并发单元测试验证多线程场景下的稳定性。这种“退避重试”是处理瞬时资源竞争的经典模式，能有效避免因偶发占用导致的闪退，同时不掩盖真正的逻辑缺陷。

发布前最后一课：仓库权限与下载解耦

软件全测通，GitHub打出正式release，大家反馈下载不了——开发仓库是私有的，外部用户无法下载release附件。为了不泄露内部记录又能自由下载，团队当机立断解耦：开发和公开发行彻底分开，新建公开下载仓库，发布Local LM Deployer 13.1。

安装包带交易码，从403兆到422兆严丝合缝。写代码也许容易，真刀真枪交付软件靠的是严密工程纪律。

GitHub Release 与仓库可见性：GitHub 的 Release 功能允许开发者将编译好的二进制文件（如安装包）作为附件发布，方便用户下载。但 Release 附件的可访问性继承仓库的可见性设置：如果仓库是私有的，未登录或未授权的用户无法下载附件，即使知道直链也会被拒绝。本实验中，开发仓库保持私有以保护内部记录，导致外部用户无法获取 release 安装包。解决方案是“解耦”：开发活动继续在私有仓库进行，同时新建一个公开仓库，专门用于存放发布版本和附件。这样既不影响内部协作，又让外部用户能自由下载。这一细节常被 AI 忽略，因为 AI 更关注代码逻辑而非仓库配置，提醒我们在 AI 编程流程中，发布环节的工程配置仍需人工把关。

工程化启示：AI编程的边界在哪里

这次实验揭示了双AI接力的可行性与局限。可行在于：GitHub issue+PR的天然协作接口、云端负责设计生成、本地负责真机验证，能形成“犯错-反馈-修复”的闭环。局限在于：AI会犯低级错误（漏括号）、可能用try catch掩盖问题、忽略仓库权限等工程细节。

正如UP主在视频中强调的：“AI犯错不可怕，可怕的是没有这种让它自我修复的真实闭环。” 未来双AI接力能取代多少日常工作？欢迎在评论区聊聊。

One-line Summary

双AI通过GitHub issue/PR接力开发Windows本地大模型部署工具，经历漏括号、剪贴板崩溃和仓库权限翻车后成功发布。

Paragraph Summary

本文基于B站UP主“玩客笔记”的实验，记录了两个AI接力开发Windows本地大模型部署工具的全过程。云端ChatGPT负责架构设计与XAML生成，本地agent负责真机编译与测试，二者通过GitHub issue和PR形成“犯错-反馈-修复”闭环。开发中遭遇CS1513漏括号语法错误，靠日志回传和定点补丁自愈；随后跑通114项测试并打出403兆安装包。发版前又遇剪贴板0x800401D0崩溃，最终以三次退避重试加并发单测修复，测试增至124项。最后因私有仓库导致release无法下载，通过解耦开发与公开发行仓库解决。实验证明双AI接力可行，但AI的低级错误和工程细节疏漏仍需严密工程纪律兜底。