一个纯外行是怎么用 AI 做出软件的——我的工作流

我不懂任何编程语言。不是谦虚，是真的不懂。Python（一种编程语言）和 JavaScript（另一种编程语言）对我来说就是两个名字，哪个能干什么我完全说不上来。

但就是这样一个人，过去一段时间，做了几款能用的软件——有桌面陪伴应用、有公司内部用的工具、还有一个面向海外客户的企业官网。

靠的不是我自己学会了写代码。靠的是摸索出了一套跟 AI 分工合作的规矩。这套规矩让我一个外行也能把软件从想法变成能跑起来的东西。

它不是从书上学来的，也不是一开始就想好的。是踩坑踩出来的。

1. 工作流是怎么来的——先立规矩，再做项目

最早跟 AI 合作做东西的时候，我发现一个很烦人的问题：聊着聊着就乱了。今天改了哪里、为什么改、现在进度到了哪一步——隔两天回来全模糊了。

AI 的会话一关，上下文就丢了。下次打开，又得从头解释一遍。

所以我做的第一件事不是写代码，是写规矩。

5 月 19 号，我写了第一版全局指令，起名叫「工作偏好.md」。里面一条一条写清楚跟 AI 合作应该怎么来：

• 改任何东西之前先列清单，我确认了才能动手。我自己看不懂代码，不列清单的话，AI 改了什么我完全不知道。
• 一次只做一个任务。做完验证，才能做下一个。不堆叠不并行。
• 全程用中文交流，不用网络热词、不用表情。
• 报错 AI 自己消化。代码跑崩了、编译报错了，别把一堆英文错误码甩给我看。
• 改完代码必须同步改文档。只改代码不改文档，等于没做完。

这些规矩不是一次性想出来的。是每次遇到一个问题，就补一条。比如有一次 AI 改了一堆东西没跟我说，我打开一看完全懵了——从那之后就有了「改前先列清单」这一条。

2. 项目档案——AI 的”长期记忆”

规矩有了，但还有一个更根本的问题：AI 每次新会话都是”失忆”的。它不记得这个项目是干什么的、文件结构是什么样的、当前版本号是多少。

所以我给每个项目建了一个 CLAUDE.md，相当于这个项目的”身份证”。里面写了：

• 这个项目是干什么的
• 用的是什么技术栈
• 文件结构长什么样
• 版本历史和升级记录
• 有哪些关键的约定和注意事项

新会话的第一件事就是读这个文件。读完 CLAUDE.md，再看 TASKS.md 找当前要干什么，最后 git log 确认最新进度。整个过程花不了两分钟，但 AI 就能把上下文全部的捡回来。

后来项目多了，发现每个项目的 CLAUDE.md 格式都是一样的。我就把标准格式抽成了一个模板（CLAUDE模板.md），新项目直接套用，填空就行。

再到后来，我发现这个操作也可以再简化——定义了两句话的快捷指令：

说”初始化档案”，AI 就自动扫描整个项目，按模板生成 CLAUDE.md。说”更新档案”，AI 就刷新已有档案，追加版本记录。

这两句话背后有一整套逻辑：什么情况下才需要更新档案（版本大升级、文件结构大改、技术栈换了），什么情况下不需要（修个小 bug、改个变量名）。这些门槛也写进了规矩里，防止琐碎更新。

3. 不会 Git 命令，但有 Git 安全感

Git（一个版本管理工具）这个东西，我听说过的。但你要我敲 git 命令，我一个都记不住。

但我体会过一次丢了代码的感觉——改了一大堆东西，某一步出了问题，想回去却回不去了。那次之后我就知道，版本管理这件事不能省。

我的解决方案不是去学 Git 命令，而是让 AI 来做：

每次改任何代码之前，AI 自动执行快照提交——把当前状态完整的保存下来，然后才开始改。每次 commit（提交记录，相当于给当前进度拍个快照）之后，自动推送到远程，确保本地和云端都有备份。

这样我既不需要记任何命令，也不需要了解分支合并什么的。万一出了什么问题，我只需要说一句”回退到上一个版本”，AI 就帮我恢复了。

这套机制的核心不是技术，是安全感。你不知道代码怎么改回去，但你知道永远有路可以退。

4. 文档同步——给自己留条后路

我有个习惯，或者说是一条规定：改代码的地方，必须同步改文档。

理由很简单。这个项目是我和 AI 一起做的，代码是 AI 写的，我看不懂。如果改了代码不更新文档，那过几周之后，不止我搞不清楚状况，连 AI 自己都看不懂当时的逻辑——因为上下文已经丢了。

所以我把这个要求直接写进了工作流：只改代码不改文档，等于这个任务没完成。

每个版本的 commit 日志就是项目简史。什么版本加了什么功能、修了什么 bug、改了什么架构——全都有记录。长远来看，这份历史比代码本身还值钱。

5. 会话存档——AI 会话快超长了怎么办

跟 AI 合作做项目，有一个很实际的限制：对话有长度上限。聊到一定程度，AI 会开始”忘记”前面说过的东西。

这个问题我处理的方式很直接——不说废话，直接存档。

当我觉得对话快到极限了，就说一声”存档”。AI 会自动做三件事：

第一，更新 TASKS.md，标记哪些任务做完了、当前进度在哪、还有什么没做。第二，如果有架构变化，同步更新项目的 CLAUDE.md。第三，git commit，把当前状态完整的保存下来。

新会话打开，先读 TASKS.md 看进度，再看 git log 确认最新状态，然后直接接着干。全程不需要我重新解释一遍”我们在做什么”。

这个机制看起来简单，但实际上它是整个工作流里让我最省心的一环。因为它解决了 AI 合作最大的痛点——上下文丢了就全白干了。

6. 两条命换来的经验——废弃项目才是最好的老师

前提：我本来就喜欢创作东西。在一些游戏工坊（比如守望先锋工坊）做过游戏模式，享受那种从零到一做出一个能玩的东西的成就感。所以当我想尝试做一款自己的游戏时，主要目的不是赚钱——我就是想体验一下”自己做的东西别人能用”的感觉。享受创作和解决问题的过程本身。

这条路我试了三次。前两次都失败了。但每次失败都让我更清楚下一步该怎么走。

第一次尝试：废土终端

我想做一个废土题材的文字游戏。AI 用了 Python——一种简单好上手的编程语言——做出了一整个命令行版本。能跑，有剧情，有等级。

但玩了几分钟我就发现问题了：纯文字加黑底白字的终端界面，交互太单一了。我想象中的”陪伴感”，在命令行里完全感受不到。这更像一个老式电脑游戏，而不是一个能陪在身边的软件。

判断：方向不对。放弃。

第二次尝试：AquaTray

我换了个方向——做桌面宠物。AI 这次选了 Rust 加 Tauri。Rust 是一种性能很强的编程语言，但环境配置很麻烦，改一行代码要等好几分钟编译。Tauri 是一个做桌面软件的框架，底层用 Rust，遇到问题很不好查。

做了鱼缸、换了精灵图、试了 AI 生成美术素材。来来回回重构了好几次。但每次折腾完都觉得——太沉了。想改个按钮大小，要经历改代码、等编译、看效果、不满意再改、再等编译。这个节奏太折磨人了。

最后整个项目精简成了一个纯文本状态面板。说实话，做到这个份上已经说明问题了——这套技术路线走不动。

判断：这条路也走不通。放弃。

第三次尝试：Idel-DreamMaker

这一次，AI 一开始选的还是 Rust 加 Tauri。做着做着，之前 AquaTray 碰到的问题又来了——Tauri 依赖 Windows 系统自带的一个叫 WebView2 的组件来显示界面，而我电脑上的 Edge 浏览器版本太新，跟 Tauri 不兼容，界面根本打不开。

同样的墙，我又撞上一次。

但这次我做了不一样的决定。我没有直接放弃这个方向——我跟 AI 说，能不能把底下那层技术换了？

于是我们把框架从 Tauri 换成了 Electron。Electron 是另一个做桌面软件的框架，用的是 JavaScript——一种不用编译、改完保存就能刷新看效果的编程语言。整个迁移花了一些时间，但迁移完之后，开发节奏完全不一样了。不用等编译了，改完保存，刷新，就能看到效果。

回想一下前面的路：第一次用 Python 试了文字游戏——交互太单一，放弃。第二次用 Rust 加 Tauri 试了桌面宠物——技术太重，放弃。第三次同样遇到了 Rust 加 Tauri 的问题，但这次没有放弃项目本身，而是换了技术路线，绕过去了。

这三条路不是 AI 替我选的。是我在每个岔路口自己判断——这个方向对不对、要不要继续、是调整还是放弃。AI 只负责执行，决策在我。

说回这个做出来的东西到底是什么。

说人话就是：你坐在工位上，桌面的角落里有只像素小动物陪着你。不用喂不用管不用操作。你进入一个”世界”之后纯挂机，等级慢慢涨，每升一级解锁一段故事。

说的更直白一点——坐办公室摸鱼用的。上班的时候余光扫到屏幕角落，知道有个小东西在，偶尔弹出个故事，算是枯燥工作里的一点调剂。

做给谁用的？坐办公室的打工人，想要一点桌面陪伴但又不想多操心。

之后呢？我计划上架 Steam，让更多人能发现和用它。但当前的重心还是加内容。目前只有一个废土世界（500 级剧情），后续会用 ScenarioWriter 这个工具不断产出新的故事世界。

至于美术问题怎么处理的？

这是个绕不开的话题。

宠物精灵用的是 PetDex 社区的像素资源，不是我自己画的。我的处理方式是：应用不捆绑任何精灵文件，让用户自己下载放到本地文件夹。精灵版权归各自的创作者或 IP 权利人，应用里面也放了免责声明。

游戏本身是纯文字加像素精灵的组合，不做复杂美术——这是一个非技术背景的人面对版权问题时能想到的最务实的方案：不碰自己搞不定的东西，尊重别人的劳动成果。

7. 同一套工作流跑四个项目

目前我在做的项目有四个，玩法各不相同。

一个是 Idel-DreamMaker，桌面陪伴应用，面向普通用户。

两个是内部工具，为了解决公司工作流里的实际痛点做的——一个管产品资料和订单流程，一个管仓库发货。都是日常工作中”有这个工具能省很多事”的产物。

还有一个是企业官网，面向海外客户的品牌展示站。

四个项目，类型差很多。技术栈不一样、用户不一样、规模也不一样。但规矩是同一套。

Idel-DreamMaker 用这套规矩从零跑到 v2.7.5，两百多次提交。内部工具用这套规矩稳定迭代，按需加功能。官网用这套规矩从零起步。

工作流跟项目数量没关系。一个项目也这么管，十个项目也这么管。规矩立好了，规模变了也不怕。

8. 结尾：我的手拓展了

以前不会写代码等于不可能做软件。这个门槛是很实在的——你连”把这个按钮往右移五像素”都做不到，更别说做一个完整的应用了。

但现在不一样了。AI 把入场券发了——你不用写代码，你把想法说清楚，AI 帮你写。

但这张入场券不是免费的。它换了一个条件：你得知道怎么管这件事。

你没有代码理解力，看不懂 AI 写的代码是对是错，不知道怎么排查问题，也不知道哪些是简单的改动哪些是复杂的。那你就需要一套流程来弥补这些缺失的能力。

这就是我这套工作流的本质：用流程来弥补没有代码理解力这件事。你不需要看懂代码，但你得知道怎么管这件事。

AI 降低门槛，规矩兜住下限。两样都有，一个外行也能做软件。