不会写代码,我做了一个能发给朋友用的软件

先说清楚一件事：我不会写代码。

但我做了一个软件。不是 demo，不是玩具，是真的能发给朋友、双击就能用的东西。

这篇文章不是技术文档，是我和 AI 编程助手 CodeBuddy 协作的真实记录。包括我指令说得不准、踩了小坑的部分——那才是最值得聊的。

（电脑端）

（手机端）

1痛点：我只是想要一个「不麻烦」的传文件工具

平时手机和电脑之间传文件，真实体验是这样的——

微信文件传输助手好用，但文件过了腾讯服务器，我不放心。大文件、批量传也很别扭。

网盘要登录。聊天工具要开网页。现成的互传工具要装 Java、装 .NET，或者本质上是 Electron 套壳，体积大、启动慢，换个电脑就用不了。

我想要的很简单，大白话说就是：

电脑上弹一个小窗口，手机扫个码就能互传文件。不装任何东西，不联网，拷到别的电脑上也能直接用。

很生活化的需求。但要变成软件，传统路子得找程序员、得懂 Go、得懂 Windows 窗口怎么画——我一样都不会。

我的处境：有清晰的产品想法和判断力，但没有把想法变成代码的能力。

CodeBuddy 的角色：把我的大白话翻译成能跑的软件，顺便替我补全那些我不懂但必须处理的工程细节。

2第一步：把需求说给它听

我给 CodeBuddy 的第一条指令，就是那段大白话的整理版：

做一个电脑端原生窗口的手机文件互传工具。不打开浏览器，不装运行库，单 exe 拷贝即用，手机用网页扫码连接，数据只走局域网。

它没有立刻动手写。先做了几件"站在我立场上替我想"的事：

识别我的真实约束——"不装运行库""单 exe 即用"，意味着不能选 Electron，不能依赖外部文件，必须做一个自包含的程序。

预判我不知道的坑——纯 Go 画 Windows 窗口有很多容易翻车的地方，它提前规划避开。

把需求拆成模块——窗口、网络服务、文件收发、手机网页端，各管各的。

这里我想诚实说一点：我的第一条指令其实并不准确。

比如我说"手机用网页扫码连接"，但没说清网页要不要做成可安装的 PWA、二维码里到底放什么地址。这些细节我当时脑子里是模糊的。

CodeBuddy 没有卡住问我一堆术语。它基于常识先给了一个合理默认，把能跑的版本做出来让我看。

这恰恰是不懂代码的人最需要的——你不需要一次把需求说完美，先说个大概，看它做出来再纠偏。

3第一版跑通后，我做了一件最关键的事

第一版跑通了。双击程序，窗口弹出，手机扫码，文件互传，列表实时刷新。

如果故事停在这里，就是"AI 帮我写了个工具"。挺好，但平平无奇。

真正让结果质变的一步，是我接着下了一条指令：

好了，我们的第一版完成了。请反审查整个项目，并进行代码逻辑优化。

这条指令里有两个词很关键：

"反审查"——让它扮演一个没有参与过开发的资深评审，把整个项目从头到尾挑毛病。

"逻辑优化"——不是加功能，是把已有的东西改得更稳、更合理。

为什么这条指令重要？因为我不懂代码，根本看不出第一版里藏着什么问题。我能感觉到"好像能用"，但不知道哪些地方现在不出事、以后会出事。

我需要的不是更多功能，是有人替我把关质量。

CodeBuddy 理解到了这层意思。它没有东改一点西改一点，而是通读了全部代码，按严重程度排了序。

【配图：反审查对话】

4它审出了什么问题？

下面几个是 CodeBuddy 反审查时揪出来的典型问题。我尽量用不写代码也能懂的话说。

问题 1："说明书上写了有，程序里其实没有"

问题

我在使用说明里写了"本工具只运行一个实例"。但 CodeBuddy 一查代码发现：这段功能根本没写进去。后果是用户手滑双击两次，会启动两个程序，互相抢端口、把连接弄乱。

修法

用操作系统的一个"命名锁"机制——程序启动时先看看有没有人已经拿了这把锁，有人拿就弹窗说"已在运行"然后退出，没人拿就自己拿着。

过程中它自己踩了个坑。第一版按常规写法判断"锁是不是已被占用"，结果在真实 Windows 上验证发现根本没生效——因为 Go 调用系统接口的一个细节会把错误状态清空，导致判断永远失效。

它没有把"编译通过"当成"做对了"。真机跑了一下，发现第二个程序没被拦住，换了一种更稳的判断方式，再验证，确认第二个程序真的 2 秒内退出了才罢休。

不迷信"看起来对"，要用"跑起来验证"来证明对。这点打动我了。

问题 2："后台悄悄把你想看的话覆盖了"

问题

窗口底部有一条状态提示。你刚点完"发送"，它会显示"已推送到手机，等对方保存"——这本该停留几秒让你看到。但程序里有个每 2 秒跑一次的后台检查，会把它强行刷回"等待手机扫码"。结果你永远看不到那条"已推送"的反馈。

修法

把"临时提示"和"常驻状态"分开管理——临时提示优先显示，几秒后自动让位给常驻状态，两边不再打架。

根因一句话：两个地方在抢着写同一块显示区，谁后写谁赢。修法不是打补丁，是从根上拆开。

问题 3："别人传个带歪心思的文件名，可能跑出文件夹"

问题

手机传文件时会带一个文件名过来。如果有人故意构造一个像 ../../机密.txt 这样的名字，处理不当就可能把文件存到本该存的地方之外。

修法

无论对方给什么名字，落盘时都只取最末尾的纯文件名。路径穿越的口子直接堵死。

这类问题，不懂代码的人是绝对发现不了的。但 CodeBuddy 在反审查时主动把它当成必须修的级别处理。

5不只是改完就交差，还补了"证明"

反审查收尾时，CodeBuddy 没有说"我改好了你试试"。

它给关键逻辑补了自动化测试，真的把程序跑起来验证：单实例是不是拦得住、文件名清洗是不是安全。最后给我一个明确结论：

构建、检查、测试全部通过。第二个实例确实会被拦掉。

这一步对不懂代码的用户意义重大：你不需要自己会测，但你需要一个助手能告诉你"我证明它改对了"，而不是"我觉得改对了"。

6老实讲：我的指令也不是句句精准

想真实，就不能只夸。复盘下来，我作为用户的指令有几个不够准的地方：

第一版需求里混了"想要"和"必要"。我说"手机用网页扫码连接"，但没想清楚网页端要做到多完整。CodeBuddy 按合理默认先做了，我后面才逐步纠偏。好在协作支持"先看再做后改"。

提"反审查"时，没具体说审什么。但 CodeBuddy 没追问一堆术语，自己定义了审查范围：正确性 > 健壮性 > 整洁度。这恰恰降低了对用户"指令精度"的要求。

有时用口语化表达，比如"冲掉""逻辑优化"。CodeBuddy 能结合上下文准确理解成工程动作，而不是字面执行。

结论：你不需要成为会编程的人，也能用好 CodeBuddy。但你越能在关键节点给出"方向性指令"——比如"反审查一遍""这里体验不对"——产出的质量上限就越高。

指令的"准确性"更多体现在说清你想要什么结果，而不是说清怎么实现。后者本来就是 AI 的活。

7给"不会编程但想做软件"的人的操作指南

把我跟 CodeBuddy 的协作抽象成一套普通人能复用的方法：

• 1用大白话讲清痛点和想要的样子
  不用管技术。就说"我想要个 XX，用来解决 XX 麻烦，最好能 XX（比如不安装、不联网）"。CodeBuddy 会替你补全技术决策。
• 2先看它做出来，再纠偏
  不要追求第一次就说完美。让它先出个能跑的，你实际用一下，哪里不对就说什么不对。比反复在脑海里雕琢需求高效得多。
• 3功能跑通后，下一条"反审查"指令
  不要急着加功能，而是说：请反审查整个项目，找出现在不出事但以后会出事的问题，并优化。这一条，往往比十条零散的"帮我改这个 bug"带来更大的整体提升。
• 4要求它"证明改对了"
  直接说：改完请跑一下验证，告诉我结果。合格的 AI 协作应该给你可验证的结论，而不是"我觉得好了"。
• 5把方向交给自己，把执行交给它
  你负责判断"好不好用、对不对路"，它负责把判断落地成代码并兜底那些你不懂的细节。

8CodeBuddy 真正不一样的点

回顾全程，值得被收录的不是"它写了个工具"，而是它展现出的几种能力：

💡 送给同样不会编程、但心里有产品想法的人

你不需要先学会编程才能做软件。你需要的是把一个真实痛点讲清楚，并在关键节点敢于说"请帮我审一遍"。剩下的，交给像 CodeBuddy 这样的搭档。

以上就是一次真实的协作记录。人负责方向，AI 负责执行。方向对了，剩下的交给它跑就行。

—— 杨欢 / i杨欢

/////////////////////////////////

还没完，上面这篇文章，不全是我写的，是用codebuddy让他总结我们的对话，我又拿到workbuddy上面，让他按照我ima知识库里内容的写作风格，写的这篇文章。我只修改了配图部分，下面是我的对话要求，也是通过两三轮对话出来的内容。