我是没什么编程基础的普通人。

去年开始接触 vibe coding，用 AI 工具写了几个文档处理工具。在这个过程中踩了很多坑，但也真的写出了能用的产品。今天把我的经验分享出来，不是什么大神经验，就是一个普通人的真实记录。

如果你也想用 AI 帮你写程序，这篇内容应该能给你一些参考。

第一次写程序：想法很丰满，现实很骨感

第一次写的是一个文档转换工具，想实现 word、excel、ppt 和 md 之间的互转。

那天下班后七点半开始，用 Trae 打开一个窗口，直接开干。我的想法很简单：让大模型自己去想有哪些转换需求、需要什么技术依赖、怎么处理格式。我就像个甩手掌柜，全部交给 AI 去完善。

结果呢？

到凌晨两点钟终于写完了。但问题也随之而来——打包总是出错。把错误信息贴给 Trae 让它调整，它改完还是出错，反反复复，光打包就折腾了一个多小时。

测试的时候问题更多。主要测的是 word和md互转的格式问题，md转换为word时经常格式错乱，改完这个问题又出那个问题，我把问题描述清楚发给 AI，让它改。改好了再测，测完再改，反反复复。

那时候我用的比较多的模型是 GLM4.7 和豆包 code，根本没考虑什么格式映射关系、图片存储路径这些问题。但大模型确实帮我考虑了——它把文档里的图片自动提取到一个单独文件夹，在 md 文件里用关联路径引用。

这个版本后来被我弃用了，源代码也删了。不是说不能用，是改到最后自己都改了什么东西都不知道了，一团糟。

写出来的程序长这样：

第二次写程序：我学会了先”纸上谈兵”

第一次失败后，我反思了一下：这样不行，不能一上来就让 AI 闷头写。

第二次我重写了 docx 和 md 互转的工具。这次学聪明了——先不动手写代码，而是先问。

我先和豆包聊了很久，问了她很多问题。比如 doc 格式和 docx 格式有什么区别——被她科普了 doc 是 2003 年以前的旧格式，docx 是新版。而且 office 可以直接把 doc 转成 docx，所以技术上只做 docx 转 md 就够了。

这次我按照一个正规项目来开发。让豆包帮我写了完整的内容：

• 项目需求说明
• 技术依赖列表
• 技术路线规划
• 多格式映射方案
• 研发阶段划分
• UI 设计方案
• 检查测试计划

我还问了 gemini 帮我补充，看看有没有遗漏的地方。

一系列项目开发计划写出来之后，我突然意识到一件事——这不就是后来我才知道的”复利工程”吗？规划、执行、审查，形成了一个工作循环。而且我那好几个文档模板是可以直接复用的，这就是”复利”啊。

文档都写好了，这时候才开始让 Trae 来写代码。

我把文档发给 Trae，告诉它按我的阶段来划分——开始 P1 阶段、开始 P2 阶段、开始测试。它就分阶段帮我完成开发任务。这次顺利太多了，我只需要告诉它”开始 P1″就行了，不需要一遍遍回答它那些我根本听不懂的技术问题。

最后我自己拿到打包好的 exe 文件，测试了一下，工具就出来了。界面也比第一次好看很多，还加了 LOGO。

这个 md2docx 工具是我近期使用频率最高的工具。用的时候也发现过问题，比如表格嵌套会造成格式转换混乱，类似问题我直接把问题描述给 Trae，让它帮我改，改完重新打包就好。

这就是 vibe coding 的好处——迭代快，改得快。

第三次写程序：只用一个需求文档就够了

这次我想把工具能力完善起来——做 word、excel、ppt 和 md 的相互转换。

这次我用了两个工具：Cursor 和 Trae。

先用的 Cursor，配上 gpt5.5 模型。结果 50 美元的 token 额度，半天就没了……但基础框架确实是 Cursor 完成的，剩下的部分让 Trae 来补充。

这次我只写了一个需求文档，但把格式要求、技术路线、阶段规划都写清楚了。比上次精简很多，基本就是一个文档走天下。

断断续续写了一天都不到，工具就出来了。测试了一下，ppt 和 excel 的格式保留得都不错。当然我不是什么专业测试人员，测试范围有限，反正能转。

后来我还写了文本批量提取工具、查重工具、属性清除工具等等。用的是同样的方法——先规划，再执行。

我总结的 vibe coding 几个心得

1. 会提问比会编程重要

这是我最大的感受。你不需要会写代码，但你需要会描述问题。你要能把一个模糊的需求变成清晰的问题，AI 才能帮你解决。

比如第一次我只能说”帮我做个文档转换工具”，AI 写得一塌糊涂。后来我会说”帮我规划一下这个项目的技术路线，重点关注格式映射和图片处理”，AI 给出的方案就专业很多。

2. 先想清楚再动手

我以前总觉得 vibe coding 就是想到了就问，问了就要答案。后来发现，磨刀不误砍柴工。

先花时间把需求文档写好，把技术路线想清楚，把可能遇到的问题预判一遍，真的能省很多时间。AI 写代码很快，但帮你思考的时间需要你给它。

3. 迭代比一步到位靠谱

别想着一口气写出一个完美的工具。先写个能跑的版本，测试，发现问题，改，再测试，再改。

我这几个工具都是这么迭代出来的。第一次写的版本虽然弃用了，但我在那个过程中学到了很多——比如打包会遇到什么问题、格式转换会有哪些坑。这些经验都变成了下一版本的养分。

4. 工具在精不在多

我也试过很多 AI 工具，Cursor、Trae、豆包、gemini、GLM……用了一圈下来，我的体会是：每个工具都有擅长的领域。

Cursor 搭框架快，Trae 改代码溜，豆包聊天最接地气能帮我理解概念，gemini技术能力强。关键不是哪个最强，而是知道什么时候该用哪个。

写在最后

没什么编程基础又怎样？大模型时代，会提问、会规划、会迭代，普通人真的能做出有用的工具。

我现在用的最顺手的 md2docx 工具，就是这么一点点磨出来的。每次发现问题就改，每次改完就打包，打完包就测试。不是什么高大上的开发流程，就是最朴素的”发现问题，解决问题”。

如果你也想尝试 vibe coding，我的建议是：先从小工具开始。不要一上来就想做个大系统，先做一个能解决一个小问题的工具。在这个过程中，你会慢慢学会怎么和 AI 沟通，怎么规划项目，怎么迭代改进。

工具会了，流程通了，后面做什么都会越来越顺。

另外针对我们这些写程序非常少的人群来说，虽然cursor里的国外高级模型好用很多，但是我觉得用trae我觉得足够了，毕竟模型都是免费的。

最后的最后，如果你想要这些工具，可以直接私聊：“工具”，系统会自动发给你。程序不完美，使用中发现问题可随时反馈，我来改。