30 天迭代 13 个版本：WorkBuddy 协作开发桌面应用的完整复盘（一次差点泄露客户名单的事故）

引子：2026 年，AI 编程的最大问题不是"能不能用"

2026 年 7 月，如果你打开任何一家技术社区，AI 编程相关的内容几乎能把你淹没——GitHub Copilot、Cursor、Claude Code、通义灵码、Trae、WorkBuddy……每个工具都能在 30 秒内吐出 200 行能跑的代码。

但我真正想搞清楚的问题，从来都不是"AI 能不能写代码"。

我想搞清楚的是：当一个不懂底层技术的人（我）想用 AI 协作做出一个能用的、稳定的、能分发给同事使用的桌面应用，AI 协作这条路到底走不走得通？走得通的话，需要怎么搭这条流水线？

这篇文章，是一份完整的 30 天实战复盘。我把从 0 到 1.3.13 版本的过程里踩过的坑、做对的决策、以及一次差点砸招牌的隐私事故，原原本本写下来。文章里不会出现任何真实客户名、行业术语，所有案例都已脱敏。但所有教训，都是真金白银换来的。

适合读者：

• 想用 AI 协作做点东西但不知道如何开始的非技术背景从业者
• 担心"AI 写代码会不会不安全"的中小企业主
• 正在评估"要不要把工具外包开发 vs 自己用 AI 搭"的产品经理
• 对 AI 协作流程化感兴趣的全栈工程师

一、为什么选 AI 协作，而不是外包或自学

1.1 三条路的对比

我选 AI 协作的根本原因只有一个：我需要的不是"一款产品"，而是"一个能跟着我的业务持续演化的工具"。

业务场景是清晰的——一家小型会计师事务所，合伙人的日程比普通员工更碎、更杂、随时被打断；同时承接的专项项目多，每个项目都有独立的"重要紧急"维度需要排序。市面上的现成产品要么太重（钉钉日历、企业微信日程），要么太轻（系统自带日历），没有一款能精准切中"个人 + 专项项目"这个交集。

外包做？这块业务如果成了，3 个月后乙方交完代码，我想加个番茄钟、想换主题色、想把"待办"改成"四象限"，得重新发起需求。这种依赖关系我会疯掉。

自学？我做过技术背景调研，Electron + Vite + React 这套对非科班出身的人来说，学 3 个月能做出来不难，但要做出"稳定能分发的"中间隔着至少半年工程化经验的鸿沟。

最后选了 AI 协作。

1.2 第一次和 AI 对话的心得

第一次和 AI 协作，我上来就把需求写得事无巨细。5000 字的需求文档甩过去，期待 AI 给我一份可上线的代码。

结果 AI 给了我一份结构完美但完全跑不起来的代码。

为什么？三个原因：

1. AI 没有"本地环境"概念，写出来的代码里 path 用的是 Linux 风格，Windows 跑不起来；
2. AI 不了解我电脑上装了什么库、哪些版本兼容，写出来的 package.json 安装必报错；
3. AI 给我的"测试通过"只是"代码语法没问题"，不是"在我机器上能跑"。

第一次尝试失败后，我反思了 3 天，重新设计 AI 协作流程。这 3 天学到的东西，比后面 30 天的所有技术细节加起来都重要。

二、SOP 团队协作流：把 AI 当"虚拟团队"用

2.1 核心思路：代码 = SOP(团队)

我的核心洞见是：AI 协作最大的浪费不是 token 成本，而是"上下文每次都得重新说一遍"。

我前面 5000 字的需求文档，AI 给我的第一版代码就吃掉了我所有的耐心。但等我想加个新功能时，AI 已经忘了上次我们怎么约定的——文件结构、命名规范、视觉风格、依赖管理方案……

这就好比每次开工都得重新招一个新员工，什么都不记得，每件事都得从头教。

我的解决方案是：让 AI 扮演"虚拟团队"，按 SOP 流程协作。

具体做法是，我把一个完整的开发流程拆成 4 个固定角色：

这套流程最大的价值不是"专业分工"，而是"上下文连续"。

每次新需求进来，都走这一条完整链路：产品经理先把需求结构化成 PRD，架构师再把 PRD 拆成可执行的任务清单，工程师按清单写代码，QA 验证后再交付。每个角色的输出都形成下一个角色的输入上下文，不会断档。

2.2 主理人最重要的三件事

我作为"老板"角色，在这条流水线里其实只做三件事：

这三件事里，最难的是第二件——"验收成果"。

我一开始以为"验收"就是"打开应用看看对不对"。但实际操作中发现，"对不对"的判断必须建立在"我想要什么样"的明确表述上。

举个例子。AI 第一版做出来的四象限拖拽功能，我打开一看："不对"。

是哪里不对？颜色不对？布局不对？交互不对？性能不对？

如果我说不清楚，AI 就会来回改 5 轮，每轮猜一个方向，浪费 3 小时。

后来我学会了一个表达模板："我看到的"+"我期望的"+"差在哪里"。

我看到的：拖完一项待办后，刷新页面才看到新位置。 我期望的：拖完立刻落位，不需要刷新。 差在哪里：当前的实现把 UI 改动和持久化拆开处理了，UI 先改但数据没同步，需要等数据写完再 render。

这样 AI 才能精准定位问题。

2.3 反馈回路：什么时候该让 AI 修，什么时候该自己扛

这条流水线最反直觉的设计，是它"不总是线性流动"。

AI 协作的成本结构里，"上下文切换"是最贵的。

每一次反馈回路的跳转，都要让 AI 重新"进入角色"——QA 角色跳回工程师角色，需要重新加载任务清单、源码位置、命名规范。这种切换每多一次，整体效率就掉一档。

所以我后来形成了一个习惯：反馈回路尽量在同角色内闭环。

比如：

• 工程师写代码时发现命名和架构师定的有出入 → 自己修，不返给架构师（架构师忙不过来）；
• QA 测试时发现是测试用例本身写错了 → 自己改测试，不返给工程师（工程师不用看测试代码）；
• 工程师发现需求里有两个地方矛盾 → 主动问老板（也就是我），不返给产品经理。

这条流水线的高效，靠的不是每个角色都专业，而是"上下游不互相打扰"。

三、技术深坑：四个让我崩溃又觉醒的案例

下面这四个坑，是 30 天里我印象最深的。每个坑都让我从"想放弃"到"理解了为什么 AI 写代码"再到"知道下次怎么避开"。

3.1 Electron transparent 窗口的 HTML5 DnD 陷阱

症状：四象限视图里，待办从一个象限拖到另一个象限，鼠标指针显示正在拖，但松手后啥也没发生。

第一次诊断：检查了 3 小时代码，发现事件监听器都挂上了，但 dragstart 之后 drop 事件死活不触发。

真相：在 Electron 里，如果 BrowserWindow 配置了 transparent: true（透明窗口），HTML5 原生的 drag-and-drop API 会失效。这是 Chromium 在 transparent 窗口下的一个长期已知 bug，搜遍 GitHub issues 都没有完美解。

修法：放弃 HTML5 DnD，改用鼠标事件自绘。

这个坑教会我两件事：

1. AI 给的"标准实现"不一定在所有场景下能用。HTML5 DnD 是 web 通用解，但在 Electron transparent 窗口下失效——AI 不会主动告诉你这个边界条件；
2. 几何命中 + 鼠标事件 是 transparent 窗口下唯一可靠的拖拽方案。看起来"土"，但稳定。

3.2 透明度：CSS rgba 变量 vs 主进程 setOpacity

症状：滑动"透明度"滑块从 0 到 1，背景变了但文字也跟着变淡。文字 0 透明度时几乎看不见。

诊断：我最初的实现是：用户调透明度时，把 --bg 这个 CSS 变量从 #0e1525 改成 rgba(14, 21, 37, 0.3)。这样背景半透明没问题，但所有用 var(--text) 渲染的文字也跟着半透明了。

修法：拆成两件事——

这个坑教会我："哪些状态该由谁来管"，比"代码怎么写"重要 10 倍。背景透明度天然属于"窗口级"概念，归主进程管；文字可读性天然属于"渲染级"概念，归 CSS 管。强行用 CSS rgba 实现整窗透明，把两个层级的责任混到一起，必然出问题。

3.3 字体可读性：text-shadow 的双刃剑

症状：UI 重塑后整体粉嫩可爱，但中文文字虚影严重，每个字像糊了两层。

根因诊断（这一条让 AI 排查了 2 轮）：

• 我给 html, body 加了 text-shadow: 0 1px 2px rgba(0,0,0,0.85)，原意是在高透明度时给所有文字加深色描边，确保在任何背景上都清晰；
• 但粉嫩主题是浅底，深色阴影 + 浅底 = 严重双影；
• 同时 ZCOOL KuaiLe（设计就粗的"可爱体"）再叠 font-weight: 500，每个汉字都糊成块。

修法：三处联动：

这个坑教会我："为某个场景设计的样式，不一定能迁移到另一个场景"。text-shadow 在暗色透明场景下是好汉，到了浅色粉嫩场景下就成猪队友。样式不能"无脑复用"。

3.4 拖拽后弹窗的合成 click

症状：日历视图里拖动日程块改时间，拖完松手后日程编辑弹窗也跟着打开。

根因诊断：

mousedown 事件里我加了 e.preventDefault()，以为能拦住 click。但浏览器在 mouseup 之后会合成一个 click 事件——preventDefault 拦不住这个合成 click。结果是：每次拖完，弹窗都"顺带"被打开。

修法：

这个坑教会我："用户实际体验"和"代码逻辑"之间永远有 gap。AI 给的代码逻辑上正确，但忽略了"鼠标事件链"这个真实用户行为模型。

四、隐私铁律：一次差点砸招牌的事故

这一节是全文最严肃的部分。如果你只想看技术不想看故事，可以跳过——但这是 30 天里我最该早早建立认知的一件事。

4.1 事故经过

迭代到 v1.3.11 时，应用已经能跑、能拖、能设主题。我和 AI 协作得很好，进度飞快。

有一天我突然意识到一件事：应用安装包里有个"种子数据"功能——首次启动时如果本地没数据，会自动种入 10 条示例待办。这 10 条示例是 AI 从我之前的工作清单里"借鉴"过来的，全是真实业务场景：

• 某医院运营分析项目
• 某城改办汇报材料
• 某地产尽调
• 某金融业务对账
• 某政府客户咨询
• ……

我当时图方便，觉得"反正用户可以自己删"。但我完全忽略了一件事：这个安装包是要分发给同事的。

只要分发出去，任何拿到安装包的人，用 asar 工具解包 app.asar，进 js/store.js 一搜就能看到这些客户名和项目名。如果是 win-unpacked 绿色版直接打开 .js 文件就能读——完全明文泄露。

4.2 事故处理

我立即停发 v1.3.11 / v1.3.12 两个版本，v1.3.13 紧急清空种子数据，发布"干净版"安装包。

回想起来，这件事暴露了 AI 协作的一个根本性风险：

AI 不会主动告诉你"这个文件会进安装包，会被分发出去"——因为 AI 不知道你的分发计划。这是真人必须把控的盲区。

4.3 沉淀的隐私铁律

事故之后，我在自己的跨项目记忆里加了一条最高优先级规则：

任何代码里的 seed / sample / placeholder / 默认值 / 示例数据，绝对禁止使用老板真实业务内容。 错误案例：把老板清单里的真实工作项直接写进 seed 函数，打进安装包里。安装包一旦发给其他人，asar 一解、源码一搜，客户名全部明文泄露。 正确做法：示例一律用通用占位（"开会"、"写报告"、"学习"），不能识别出任何真实业务线索。 同时：在写代码前要意识到"这部分内容会进安装包"——安装包是可分发的制品，里面不能有任何用户真实信息。

这条铁律和"投资分析要极度谨慎"同级，每条代码改动时都要带。

4.4 装包分发的边界感

更进一步，我开始想"装包分发"这件事本身的可信边界：

AI 协作开发最容易踩的坑，就是把"本机自用"的安全标准误用到"公开发布"。这两者的隐私边界差了至少 10 倍。

五、复盘：AI 的边界与真人的核心价值

5.1 AI 协作能做什么、不能做什么

30 天迭代 13 个版本之后，我对 AI 协作的边界有了一个相对清晰的认知：

最关键的一点是：AI 没有"分发场景"概念，没有"隐私边界"概念，没有"我的用户在哪儿"概念。这些都必须是真人主动告诉 AI 的。

5.2 真人最不可替代的三件事

如果只让我总结 30 天里真人最不可替代的 3 件事，我会列：

1. 拍板"做什么、不做什么"：AI 会给你 10 个方案，但"哪个值得做"永远需要人来判断；
2. 验收"做到了什么程度"：AI 写的代码可能语法正确、可能逻辑自洽，但**"用户实际使用体验"只有人才能感知**；
3. 守住"分发边界"：AI 不知道你的东西会流向哪里，这条铁律必须人来把控。

5.3 我的工作流现状

现在的日常工作流大致是这样的：

每天大约有 2-3 小时用在 AI 协作上。这 2-3 小时的产出，相当于以前 1-2 周的工作量。但这有个前提——前面 30 天的"搭流程"和"踩坑"是无法省略的沉没成本。

六、给想试 AI 编程的同行

如果你看完上面的故事，也想试一下"用 AI 协作做点东西"，我给 5 条具体建议：

6.1 不要第一次就做"产品"

先做"工具"——给自己用的工具，分发不出去也没关系。AI 协作最珍贵的是"零成本试错"，你不需要一开始就考虑"会不会被外面的人用到"。

6.2 把 AI 角色化

不要直接和 AI 说"帮我做个 XXX"——把 AI 当作"虚拟团队成员"用，按角色分配任务。这样 AI 的输出会更专业、更结构化、上下文也更容易保持连续。

6.3 准备一个"跨项目记忆"

AI 没有长期记忆——每次新对话都从零开始。你需要有一个人自己维护的"铁律清单"，每次写代码前先扫一遍：

• 隐私铁律
• 命名规范
• 视觉风格约定
• 不允许的示例内容

这个清单越详细，AI 协作的"翻车率"越低。

6.4 第一次反馈一定要"具体"

不要和 AI 说"这个不对"——说"我看到的 / 我期望的 / 差在哪里"。三个要素缺一个，AI 就要多猜一轮。

6.5 严格把控"装包分发"边界

写代码前先想"这部分内容会进安装包吗"——只要会进，所有示例、所有 placeholder、所有 seed，都必须用通用占位。这一条铁律，比任何技术细节都重要。

结语

2026 年 7 月底，AI 编程的话题已经从"AI 能不能写代码"演化到了"AI 怎么用才能不出事"。这篇文章记录的，是后者。

我用了 30 天，把一个"想法"变成一个"能分发的桌面应用"，v1.3.13 已经能稳定跑在 10 多个同事的机器上。这在 5 年前至少需要 20 万外包 + 3 个月工期；现在我用 2-3 小时的日均投入，30 天搞定了。

但代价是什么？代价是我付出了一次种子数据泄露事故、数不清的"AI 猜错方向"重做轮次、无数个"验收不通过要返工"的晚上。

AI 协作的真实价值，不是"省时间"，而是"让我一个不懂底层技术的人，能在合理的成本内做出东西来"。

AI 协作的真正风险，不是"AI 写错代码"，而是"我以为 AI 知道它不该知道的事"。

把握住这两点，AI 协作这条路就值得走。把握不住，不如老老实实外包。