故事的起点：一句话的需求
朋友的需求很简单：上网课、开线上会议的时候，电脑里在放声音，能不能自动把声音变成文字，再总结讲了什么。
我把他的话原封不动丢给 AI：
"听取电脑播放的音频，实时把音频合成文字，最后再通过 AI 进行总结提炼要点。"
没有技术方案，没有产品文档，没有 "请使用 Python 的 multiprocessing 模块配合 WASAPI loopback……" 这种东西。
然后 AI 就开始干活了。
第一阶段：从一句话到能跑的软件
⏱ 约 1 小时
AI 先上网搜了一圈，告诉我大致的方案：
电脑声音 → 录下来 → 判断有没有人在说话 → 把说话的片段转成文字 → 用 AI 总结
然后它花了一个多小时，写了大概 10 个文件，一个能跑的软件就出来了。打开浏览器，点开始，播放一段音频，屏幕上真的出现了文字。
说实话，这就是 AI 开发的日常——你只管说人话，它自己会把搜索、设计、编码全干了。全程我就说了那一句话。
它能跑，离"好用"还差得远。接下来的半天才是关键。
第二阶段：修修补补，让它真正好用
⏱ 约半天
能跑是一回事，好用是另一回事。接下来的半天里，我发现了一堆问题，每发现一个就让 AI 改一个。
"Markdown 符号怎么跑到 Word 里了？"
AI 生成的总结是这样的：
- 市场部申请增加20%预算
- 研发部需要新增3个名额
导出到 Word 文档后，**、- 这些符号直接显示出来了，看起来乱七八糟。
我跟 AI 说："导出的文档里有一堆星星符号，能不能变成真正的加粗和列表？"AI 改了一版，** 变成加粗了，但列表前面还是有圆点符号。我再说："列表前面的圆点还在。"AI 又改了一版，终于正常了。
一个问题改一次，不要一次说 5 个问题。每次让 AI 集中修一个小问题，效果好得多。
"怎么一直显示静音？"
软件界面上显示 VAD：静音，但我明明在放视频。这说明软件根本没检测到我在播放声音。
这个问题查了很久。AI 尝试了各种方向都不行——检查录音没坏、检查模型加载了、检查数据格式也对。最后发现是少了一步数据处理：把声音数据喂给检测模型之前，需要先"加上一点前面的声音作为上下文"。就像你听别人说话，你也是连着上一句一起理解的，不会每半秒钟清空一次记忆。
这个 bug 修好之后，软件才真正能用了。
如果 AI 修了好几次都没修好，可能是根本思路不对。仔细观察现象，把看到的异常告诉 AI。"状态栏显示静音，但我明明在放视频" 比 "检测功能不正常" 有用一百倍。描述得越具体，AI 定位越准。
第三阶段：把软件打包，让别人也能用
⏱ 约 2 小时
代码在开发环境跑得好好的，不等于你能把它发给别人用。朋友需要的只是一个双击就能用的 .exe 文件。
第一次打包：失败
AI 说用 PyInstaller 打包。第一次打包出来 303MB 的文件——一个软件安装包跟一部高清电影一样大。
更惨的是，打包后的软件根本用不了。"开始监听"点了没反应。
打包工具把软件压缩的方式，和这个软件启动子程序的方式冲突了。开发环境好好的，一打包就坏。AI 也没想到这个问题，因为它在写代码的时候没有考虑"打包后怎么跑"。
修好这个问题后，软件能跑了，但还是很肥。
精简体积：303MB → 94MB
AI 分析了一下，发现最大的一块是一个叫 torch 的大块头库——它一个就占了近一半体积，但翻遍代码发现它只在一个语音检测的小功能里打了个酱油。我们用的阿里云在线识别其实根本不需要它。
换成另一个更轻量的替代品后，体积直接砍到 94MB。虽然还是不小，但至少正常了。
软件打包是一道完全不同于写代码的坎。开发环境能跑 ≠ 打包后能跑。每改一轮代码，先在开发环境测好了，再重新打包验证。
我是怎么跟 AI 沟通的——给纯小白的操作指南
第一原则：说人话就行
不需要学编程术语。你平时怎么说，就怎么跟 AI 说。我全程说的都是这样的话：
"导出到桌面，默认文件名用当前时间"
"启动不了，帮我看看是什么原因"
"docx 文件里有很多星星符号，把它变成真正的加粗"
AI 都能理解。它就像一个听得懂人话的程序员。
第二原则：一个问题一个问题来
这是最重要的经验。不要一口气说：
没用。AI 会乱。正确做法：
每次只做一件事，改完验证通过再做下一件。这样效率最高、出错最少。
第三原则：描述现象，别猜测原因
你不是程序员，不需要猜原因。把看到的、发生的说清楚就行。AI 自己会排查。
第四原则：相信自己的直觉
如果 AI 改了三轮还是不行，停下来。不要让它继续试——它可能走错方向了。
这时候你应该：① 换个角度描述问题 ② 提供新的信息（"我注意到错误日志里说了 XXX"）③ 让 AI 从零开始重新思考。
就像这次"一直显示静音"的问题，AI 查了硬件、查了格式、查了模型加载，折腾半天。最后是我让它"对照原版实现一行一行对比"，才发现少了一步数据处理。
第五原则：改完代码先试，再打包
这是血的教训。没验证功能是否正常就打包，结果打包出来不能用，浪费时间。
改代码 → 跑起来试试 → 确认没问题 → 打包 → 再试试打包后的版本
AI 擅长什么，不擅长什么
真实体验总结
- 写代码贼快——我说一句话，它一小时写出 10 个文件
- 修小问题很稳——"把按钮改成红色"一改一个准
- 知识面广——阿里云语音识别直接知道怎么接
- 不怕麻烦——逐个分析依赖包大小找替代方案
- "看起来差不多但其实不对"的错误——代码语法正确，运行不报错，结果全错
- 打包后的问题——不会主动想"打包成 exe 会不会有问题"
- 缺少直觉——有经验的程序员一眼能猜到的问题，AI 要穷举 10 种可能
把 AI 当成一个干活飞快、但经验只有一年的实习生。 你不需要告诉它每个细节怎么写，但你要检查它写的每一行。它会犯初级错误，也能给你惊喜。你的工作不是写代码，是做判断。
从这次经历学到了什么
1. 软件开发的门槛真的降低了
两年前朋友想要这个软件，要么自己学编程（至少几个月），要么花钱找人做（几千到几万）。现在，只需要会说人话，有一个 AI 工具，一天就做出来了。
这意味着：想法比技术更值钱了。每个人都能把自己的想法变成软件，关键在于你的想法有没有用，而不是你能不能写代码。
2. 但你还是要懂"一点"东西
完全不懂的话，你甚至不知道什么是"正常的"，什么该怀疑。我之所以能发现静音检测的那个隐蔽 bug，是因为我注意到状态栏一直钉在"静音"两个字上不动——不管放不放视频，它都不变。这不对劲。
不需要会写代码，但需要培养对"不对劲"的敏感度。
3. 把经验存下来很重要
每修好一个 bug，我都让 AI 记到项目文档里。下次遇到类似问题，AI 就能直接翻经验库，不用从零排查。这就好比你请了个实习生，每次犯错都让他写检讨。时间长了，他就不犯同样的错了。
4. AI 是一个放大器
它能放大你的能力——如果你懂一些技术，它会让你变强 10 倍；如果你完全不懂，它也能让你从 0 到 1。但 AI 不会凭空变出能力。它不能替你思考"这个软件到底解决了什么问题"、"用户会不会觉得难用"。这些永远是人的事。
如果你也想试试
需要准备什么
- 一个 AI 编程工具。我用的是 Claude Code，还有其他选择。重要的是找一个能直接写代码、能搜索、能改文件的。
- 一台 Windows 电脑。我做的这个软件只有 Windows 版（因为要采集电脑声音）。
- 一个语音识别服务的账号。国内有阿里云、讯飞等多家提供实时语音转文字服务，阿里云新用户有 3 个月免费试用额度，够你折腾的了。
- 一个 DeepSeek 账号。AI 总结也要钱，同样很少。
- 耐心。修 bug 的时候需要，特别是那种修了三次还没好的 bug。
第一步做什么
不要一上来就想做个大东西。先做个最简单的——比如"把我说的话转成文字"。跑通了再加功能。
我最开始的目标就是"能听到电脑声音并且显示文字"，这个目标一个多小时就达成了。后面的文档管理、Word 导出、提示词编辑器……都是一点一点加上去的。
最后
这篇文章不是教程，不是什么"30 分钟学会用 AI 编程"的速成攻略。它就是一个普通人的真实记录——我用 AI 做了什么，怎么做的，中间踩了什么坑，得出的经验是什么。
最有价值的东西不是代码，也不是技术方案，而是那段对话的方式——怎么问问题、怎么给反馈、怎么判断 AI 说的对不对。这些才是用好 AI 的关键。
如果你也想用 AI 做点东西——不管是软件、网站、还是自动化脚本——希望这篇文章能帮你少走一些弯路。
Author: FZL <fzl@ai-workbench>
Date: 2026-05-29 // 写于项目完成的第二天