先描述一下我自己：我不会写代码。
不是那种"会一点 Python 但不太熟"的程度。是真的——你让我从零写一个 Hello World 我都得查半天的程度。我能看懂 JavaScript 大概的结构，知道 git 是干啥的，仅此而已。
但下面这个开源项目 MDEditor 是我做出来的，用 Tauri 2 + React 19，已经发了 v0.1.4，Windows 和 macOS 都有安装包挂在 GitHub。99% 的代码是 Trae 写的。
我做了什么？
决定做什么、不做什么，决定什么时候算做完，以及——这一点比想象的重要——项目唯一的人肉测试员。
这篇文章不讲技术细节。我讲不明白，讲了也只是复制AI的答案并且会被评论区按在地上摩擦。如果你想看 技术细节，这篇真的不是。但如果你也不想写代码或者和我一样、又一直想做点东西的人——我猜不少——这篇文章可能有点用，因为我只想讲我的坑和代码白痴的经验。
起点：我只是受够了 ## 和 **
事情的起因特别简单。我是 AI 重度用户，为了降低AI写材料挖掘素材等各种工作的幻觉，我用的是最简单粗暴的方法，同时开4个不同AI的窗口，三个用来问同样的问题，一个用来总结三个AI的答案或者针对三个AI的答案进行挑错。每天在 ChatGPT、Claude、DeepSeek、KIMI之间复制答案做存档。问题是 AI 输出全是 Markdown——## 二级标题、**加粗**、> 引用，复制到 Word 或者笔记软件就是一坨原始字符。实在是有点头疼，要AI直接输出我要的格式，也不是每个AI都能做到。
试过 Typora，14.9美金，用着感觉真挺好，终于打算付钱了，专门找了一张Marstcard,结果连续两次付钱付不出去，这是有钱都不乐意赚啊，大概是嫌弃我的钱；试过 VS Code，太重，那是程序员的军刀，我不是程序员，看着真的有点头痛，我只想要一把水果刀；浏览器插件不解决我"本地存档"的需求。
于是有一天我想，干脆我自己做一个好了，我知道我需要什么样的，于是我跟 Trae 说："我想做一个 Markdown 编辑器自己用。"
它问："桌面还是 Web？要本地存储吗？要导出吗？技术栈倾向？"
我答："我不懂什么是技术栈倾向，我需要的是桌面，本地存储，要能导出 Word，技术栈你来挑，总之我希望轻量一点。"
它推荐了 Tauri 2 + React 19。我没问为什么不用 Electron——反正我也不懂，但两个月下来，我大概懂了，知道是因为 Tauri 打出来的包小很多（最终 50MB 左右，Electron 同样东西要 150MB+）。
这就是这个项目全部决策起点。我不需要懂 Tauri 是什么、为什么不是 Electron。我只需要会描述需求和约束。
在 AI 时代，我不需要懂底层的螺丝是怎么拧的。我只需要会说清楚要建什么样的房子。
我和 Trae 的真实分工
这两个月，平均下来给到MDeditor的时间大概每天最多1-2个小时，分工是这样：
我做产品决定——做什么、不做什么、什么时候够好可以发了。这件事我发现 AI 反而做不好，它总倾向于给我堆功能，不喊停它能给你写到天荒地老。说"不做这个"是我这种人最重要的决策之一。
我做需求翻译。这个比我想象的要重要的多。Trae 能写代码，但它不会主动想到："国内很多用户点 GitHub release 链接可能大概率打不开，需要蓝奏云或者夸克的备用下载。" 它也不会主动想到："Windows SmartScreen 弹的那个红色警告会吓跑一半小白用户，要不要做个数字签名？" 这些是真实使用场景里才有的问题，需要一个真实使用者去提。
我做手测。这一段下面单独讲，因为它是这篇文章的重心，也是我最花时间的所在。
Trae 做了剩下所有的事。代码、调试、选库、写 CI、写 commit message、写 release notes 草稿。它甚至比我更主动地维护项目质量——经常写完一个功能它会主动说"我顺手加了个错误处理"或者"这里我建议改成 X 写法因为更稳"。
这应该就是大家所俗称的 Vibe Coding，我觉得叫法挺贴切的。我只管 vibe（感觉、方向、品味），代码归 AI。
"AI 没有用户感"——这件事我想单独讲
这是我做完整个项目后，最想分享的一句话。
Trae 写代码的能力真强。它能写对、能修 bug、能通过自测、能写漂亮的错误处理。但它不知道用户会怎么乱点。
它不知道用户会反复切语言找语言切换的快感（反正我会这么干）。
它不知道用户会在编辑文档到一半的时候去切主题。
它不知道用户拖一张图进编辑器的同时电脑还连着断断续续的 WiFi。
它不知道有人会"明明保存了文件还要再按一次 Ctrl+S 确认一下"。
它不知道一个小白用户看到 Windows SmartScreen 的红色警告会理解离开这个软件，甚至直接关掉电脑重启一遍，反正听说“重启解决90%的问题”。
这些都是 AI 自测覆盖不到的地方。而这些恰好是MDEditor bug 的高发区。
所以我的体会：我以为自己最大的劣势是不会写代码，所以我只能让 AI 写。但其实——我最大的优势恰恰是我是真实用户。这个身份 AI 永远代替不了。
我"测"出来的三个 bug
发 v0.1.4 之前，我花了两天纯手测。下面三个 bug 都是我点出来的，Trae 的所有自动检查全都通过了。这一段是这篇文章我特别想让你看的部分，不是让你看有什么BUG，想让你看到我作为真实用户的真实优势。
Bug 1：菜单点一次，对话框弹两次
我把 UI 从中文切到英文，按 Ctrl+S，文件保存对话框弹了两次。再切回中文，再切到英文，再保存——弹了三次。可能是手贱，也可能是习惯，总之我猜想这可能不是大多数人的习惯，可我不自觉的就这么干了。
于是我把这个现象告诉 Trae。它分析了半天得出结论：Tauri 框架的菜单事件注册是"叠加"的而不是"替换"的，每切一次语言就在菜单上多绑一层监听器。其实，我不是很在意，反正修了，这个BUG不在了。
这里我想插一句：我描述这个 bug 的时候只说了"我切英文之后保存对话框弹两次"，没说"我觉得是事件监听有问题"。这一点很关键。描述现象，让 AI 自己诊断；不要替它诊断——你一旦给方向，它会顺着你的方向找，可能错过真正的根因。这是我踩过几次坑之后总结出来的协作守则。
Bug 2：英文 UI 下，导入文件后弹中文提示
我把 UI 切英文，导入了一个 Word 文档。导入成功的提示弹出来——是中文的。
但同样在英文 UI 下，导入失败时的错误信息又是英文的。同一个流程，成功路径和失败路径语言不一样。作为用户我立刻就觉得不对——这就像你进了一家西餐厅，服务员上菜前用英文报菜名，上完菜突然来一句"请慢用"。违和感拉满。
Trae 说这是"前端的 stale closure 问题"——我不太懂那是啥，但它解释的大白话版本是：菜单监听器在创建的时候"记住了"那一瞬间的语言设置，后面切了语言它也不知道。要么用一个永远反映当前语言的方法，要么在显示提示的那一刻再去算文案。
Bug 3：英文 UI 下切主题，菜单上的勾选不动了
UI 切英文，点 Theme → Night。界面变成夜间模式了，但菜单上的勾选还停在 Github 主题上。再点 Pixyll 主题，界面变了，勾选没动。
我截图发给 Trae。它一看："这是 Bug 2 的同一个模式，只不过这次发生在 Rust 那边——菜单切语言时被重建了，但事件处理函数里记的还是旧菜单的引用。"
修这个比 Bug 2 麻烦。涉及到 Rust 的什么内容，我真没记住。我能做的就是保证Trae有足够的TOKEN去烧，Trae 写了几版才搞定。我每一版都点一遍：切语言、切主题、看勾选；再切语言、再切主题、再看勾选。机械地、固执地、像 QA 那样。
给我总结说本质都是同一类问题——某个东西被注册的时候"拍了张照"，环境后来变了它不知道。我听个大概，记不住术语。
但我想强调的是：Trae 在第一次踩到这类问题时，并没有意识到这是个普遍模式。它只是修了 Bug 1。等我用同样的操作（切语言）又测出 Bug 2，它才提示"这两个有点像"。等 Bug 3 出现，它才主动去全局排查类似模式还在哪里。于是我给了Trae一个指令，要求它总结这些Bug出现的原因，并且写一个文档，我思考的是不管未来用不用得到，失败的坑要留好，尽量避免下次踩同一个坑。
我同时发现的是：AI 不会主动从一个 bug 推广到一类 bug，但人会。我虽然不懂 stale closure 是什么，但我会问"既然这里有这个问题，别的地方会不会也有？"——我发现这种问法对 AI 触发联想效果极好。这是一种很纯粹的直觉，跟懂不懂技术没关系。
那次差点让我心脏停跳的 git 事故
发 v0.1.3 那会儿，我差点把整个项目搞砸。
我想清理一下 git 历史里混进去的本地文件——AI 讨论日志、未发布草稿、私人测试用的 markdown。让 Trae 重写历史，它用了一个git filter-repo的工具。
结果它执行得太"勤快"，顺手把几个公共文档也当垃圾删掉了。我没仔细看，直接 force push 到 GitHub。
打开 GitHub 一看，仓库少了几个文件。当时心都凉了。
幸好——幸好——动手前我让 Trae 建了一个备份。这是我做对的最关键的一步。最后花了半小时从备份里把误删的文档抠回来重新合上去。
教训特别简单，但不踩一次可能永远记不住：
任何会改 git 历史的操作，先建备份分支，一行命令的事；强推之前最后看一眼推上去的文件列表；AI 给你的"我已经搞定了"，并不等于真的搞定了。最后这一条最反直觉——你和 AI 协作久了会下意识相信它说的"已完成"，但它的"已完成"只是"AI跑通AI以为的流程"，不等于"你预期的事情真的发生了"。
最后，几句总结
不要让 AI 替你做产品决定。它会无止境地给你堆功能，必须学会说"不"。
像用户那样思考，像老板那样验收。代码怎么写是它的事，好不好用是唯一要操心的。
bug 报告描述现象，说"这里弹了两次"，别说"我觉得是事件监听问题"——给了方向反而容易把它带进沟里。
我还是要持续学习一下 git 以确保有机会可以自救。不写代码可以，但 commit、branch、stash、reset 这几个基本操作必须会——这是我的撤销键，是我的项目保险绳。
从小项目起步。我做这个之前先用 AI 做过几个 Python 小脚本，熟悉了协作节奏才敢上桌面应用。
最后一条最重要——给项目设个止损信号。我的第一个 AI 协作项目只给自己 3 天期限，3 天没跑通就放弃。MDEditor 是因为 3 天内核心读写跑通了我才决定继续做的。AI 有无限耐心，但我的时间是有限的，不能让 AI 的无限耐心变成我的无限投入。
项目地址 & 下载
- GitHub Release：github.com/guolilixjp/…
- 夸克网盘：
- Windows：pan.quark.cn/s/a2862dc6f…
- macOS：pan.quark.cn/s/dfd330237…
- 蓝奏云：
- Windows：wwbjq.lanzoub.com/iL7573ol20i…
- macOS：wwbjq.lanzoub.com/iMOjQ3ol1zp…
- 仓库主页：github.com/guolilixjp/…
- License：GPL-3.0
欢迎下载试试，star 一下。
有 bug 或者建议：直接打开软件，点「帮助 → 反馈」（中英双语），不爱用表单的也可以来 GitHub 提 issue。
最后想问问你
这篇文章其实不是想推 MDEditor，是想看看如果你用一款轻量的markdown编辑器，你还希望有些啥功能？
