用 AI 重写维护六年的个人项目

前言

就在最近，我用 AI 改写了维护六年、跑在线上的个人项目。AI 帮我节省大量时间，实现了复杂的新功能。与此同时，我也意识到 AI 当前仍有自己的局限性。本文将记录这个过程还有沉淀出来的思考。

通过这次重写，我认为当前 AI 编程最重要的概念就是反馈闭环。

反馈闭环指的是 AI 在执行任务的过程中有多个环节，包括思考、调用工具、验证结果等等，而且会反复循环迭代，完整的反馈闭环则代表 AI 可以从头执行到尾，不需要人类介入，人只需要下达指令。而当前的整个社会中各种编程任务，往往不具备供 AI 使用的完整的反馈闭环，人类往往需要在设计方案、调用工具、验证结果等多个方面去进行介入。比如说 AI 缺乏某个工具，需要人来想办法接入，或者是对于结果无法独立做验证，需要人来亲自验证。

AI 的强大之处、局限性都是围绕反馈闭环的完整度展开的，而当下程序员的工作逐渐从手动编码转移到如何为 AI 构建一个完整的反馈闭环。

AI 现在提供了很强的智能，但是整个社会还没有准备好把 AI 接入，因为很多工作还不具备 AI 调用的完整的反馈闭环。这可能也是接下来软件生态发展的一个方向。

背景

去年年初的时候，我看到网络媒体上有很多人在讲Cursor、 Codex 和 Claude Code 已经非常可用了，但当时工作的程序不适合用 AI 来写，因为涉及很多线上的敏感数据，所以我还是用 AI 查资料，自己手写和调试。

等到今年年初，我的一位朋友非常郑重向我推荐了 Codex，当时背后的模型是 GPT5.4，我恰好刚完成一个项目：用 Python 复现了 CPython 官方的 json 库，于是就试着增加了一个语法，可以支持注释，Codex 只用了几分钟就写好了测试，并且完成了任务。这让我十分惊讶，因为我对 AI 还停留在 chatbot 的印象，看到 AI 能够独立完成一个编程功能，感觉十分神奇。

2022 年的时候，ChatGPT 面世轰动全球，但是我认为聊天机器人本身限制了 LLM，真正的智能要能做实验，从现实中获得反馈，因为做实验是获得知识的核心手段。这样可以摆脱预训练的限制，让 AI 在现实中思考、学习、进化。但是我的设想更多是能够操纵机械臂、小车等等。当时觉得很遥远，但是在2026年 AI 已经在软件环境中拥有了自主行动、做实验的能力。

最近我抽出几个月的时间，打算独立研究 AI，需要第一个项目来探索 Coding Agent 的用法，而我手头正好有个人工具（我叫 SmallTool，致敬 Smalltalk），就打算用 AI 把它彻底重写一遍，而且增加功能。

这个项目最早追溯到2020年。疫情刚开始，我春节闲着，就利用假期写了一个 todo list 供自己使用。当时的技术栈很简陋，JavaScript + AJAX + Flask，服务器是手动敲命令部署的。在22年初，我用 Vue + Django 重写了一版，然后23年又用 TypeScript + React + mypy重写了一遍，增加了笔记本的功能，而且使用 Ansible 做自动化部署。项目功能比较简陋，前后端加起来只有三千行左右。但是在线上已经稳定运行六年了。

在24年的时候回看这个项目，我有一些改进的想法：

• 简化技术栈：去掉 React，使用 Django Template，数据库使用 SQLite。
• 引入基于 Markdown 富文本编辑器，可实时保存。之前的笔记本就是一个简陋的 HTML 表单。
• 给笔记本实现一个完整的模仿 Mac 的文件系统，可以嵌套还有拖拽移动。
• 做一个安卓的客户端，检测我的手机使用情况。因为我压力大的时候，对视频和长文章会成瘾。我想摆脱对于网络媒体的成瘾，第一步是测量自己的网媒使用时长。
• 我有一个佳明手表，佳明的数据很全，但是分析比较弱，于是我就增加了新功能，把佳明的数据导入到我的 web 工具中，可以随心所欲做分析。

可以看到，这不仅仅是一次技术栈的大改动，也增加了很多新功能。甚至还引入了佳明和安卓手机两个设备的数据。所以不仅仅是重构，更是扩写。

值得一提的是2024年我写了一篇文章讲 Web 技术栈， 现在的我有了全新的看法：我认为这套技术栈太重了。对于个人项目，或者公司项目的初版是一种 over engineering，引入了太多的复杂度，反而导致编程更困难了。所以借这次机会，我也想看看简化技术栈之后的效果。

项目成果

截至写作本文，我的 SmallTool 已经运行一个月,甚至本篇博客的一些初始灵感就是记录在 它上面的。

项目的功能分四块：todo list、笔记本、佳明数据同步、手机使用情况统计。

下面是文件系统和笔记本的效果：

其中核心功能都做了移动端适配，而且做了很多的 UI 细节微调，比如支持调节字号或者夜间模式。

安卓端UI很简单，数据展示的工作都放到了服务器端。我在后台设置了一个常驻通知，每两小时采集一次数据，如下：

我采集了佳明的数据，联动安卓手机息屏时间进行分析。为了快速了解睡眠情况，我会按照不同的颜色贴标签，如下：

程序量如下，值得一提的是生产程序和测试大概1.7:1，而且测试中有大量的端到端测试。

生产代码语言构成

上文提到结合之前的个人项目经验，我专门简化了技术栈，比如去掉 React，去掉 TypeScript 和 mypy 等类型检查工具，把数据库换成 SQLite，那么效果如何呢？

答案是非常好！我之前担心这样的前端技术栈是否导致 UI 效果变差，或者程序冗余，但是发现并没有。反而程序很简洁，而且数据库换成 SQLite 之后，让调试变得十分方便。比如后续想要用多进程加速端到端测试时，我可以给每个进程分配一个 SQLite 文件目录，改动成本几乎为零，特别轻量。

项目的 AI 技术栈

头一周我使用 Kimi Code + K2.7 Code，第二周使用 Codex + GPT5.5，在项目最后几天 OpenAI 升级模型到了 5.6，对于 GPT5.6 和 5.5，我并未发现很大的区别，可能和项目有关，如果是更大的 codebase 也许有差异。

项目经常遇到 Codex 额度用完的情况，目前我会生成一个当前 feature 的接管文档，然后让 Kimi code 继续做。

我用 VS Code 来阅读程序，在 VS Code 里面内置的命令行跑 Kimi Code 和 Codex。

过程中 我买了 Codex 20美元的套餐，Kimi Code 99元的套餐，轮换交替，对于我目前基本够用。

本来我对国产模型期望比较低，但是出乎意料的是 K2.7 Code 非常好用，写项目的过程中让我很满意。反而是本以为技术难度相对较低的 Kimi code， 其 UI 让我觉得完成度很低，比如运行命令时命令如果太长，居然会省略，或者是用时间久了就会有乱码。

而 Codex 给我的感觉是明显在 UI 细节上打磨更好，有更加丰富细腻的高亮，模型做事情时会把思考和行为展示成人类可读的摘要，而且最后额度快要用完时候也会坚持把任务跑完，这个功能非常慷慨而且人性化。

现在的 Coding Agent 已经有长时间运行的功能了，可以提供一个细致的文档，然后让它跑几小时，甚至几十个小时。但是我想要先理解 AI 的各种细节，所以没有使用这种“魔法”。而且我本身也不清楚自己想要的产品细节，只有看到成品，我才能提出修改意见。

AI 起到了什么作用

AI 在这个项目的过程中，给我增加了巨大的杠杆，节省时间，解放人力，能让我把精力放在更感兴趣的地方。

AI 让这个项目从不可能变得可能。

项目耗时大概15天，总计约40小时。如果没有 AI 的话，我觉得最起码需要 80h。

值得一提的是这40个小时很轻松，中间有些 UI 细节我甚至是一边打电话聊天一边调整的。

40小时 vs 80小时，并不是时间变成两倍，而是我可能放弃这个项目。如果完全手写，这 80 个小时很累，要记忆和分析大量细节。最后我很可能就会删除很多功能，放弃 UI 调优，把项目砍到 40h 以内。因为我手头还有其他事情，分配不出这么多精力来。

而且我也没有耐心和精力去仔细研究 CSS 和安卓，如果我自己手写，大概率会 UI 制作更加粗糙，而且放弃采集手机使用网络媒体应用的数据。

AI 已经非常擅长调试和写程序了。

在这个项目中，我全程使用 AI 来代替手写程序和调试，可以说凡是 AI 能够获得完整反馈闭环的程序，人类几乎只需要做很少的干预。

举几个让我惊讶的例子：Codex 在写安卓的时候，在我的提示下，可以直接在 MacBook 上调用安卓的各种调试功能：截图、上传下载文件、看应用的 SQLite、跑命令、编译 APK 并且安装到我的手机，完成一整个闭环，全程不需要我去操作手机；部署程序上线的时候，Codex 可以直接利用 Ansible 在线上跑命令、看 SQLite、调线上的接口、看 Nginx 的日志，我完全不用做任何线上操作。

我的感受是只要我能告诉 AI 清晰的目标，且AI 有能力做完整的验证，整个过程就可以高度自动化。

在这种场景下，人类只需要一个比较精确、准确的指令，然后等待验收结果即可。

而且 AI 已经有一些宏观的决策思考品味了，比如 Kimi 在写文件树的时候，会提示先做没有嵌套功能的，验证完之后，再尝试做嵌套。这是很典型的迭代思维，先做一个实验来验证自己的想法，而不是上来就雕琢细节。

当前 AI 的局限性

AI 目前无法完成任务全流程，而且用户反馈成为了瓶颈。

有几个地方，AI 做的技术决策有些问题：

做笔记本的自动保存时，AI 没有实现好冲突检测，后来我提供了算法和 UI 思想：针对我自己的用户场景，我会给编辑的笔记在客户端附上保存时的时间戳，如果发现提交的笔记时间戳已经落后了，就会提醒用户刷新，这时我复制刚写的内容，刷新一次，就能正常编辑了，不会丢失内容。

再比如做回收站功能，AI打算用状态值标记一些删除的文件，越做改动越多，最后陷入了迷失，然后我改成了复用文件夹，也就是把其中一个文件夹名字叫回收站，设置成系统专用。这样实现非常快，改动很小。

中间第二次开发安卓的时候，AI 无法使用安卓应用直接调用 Web 的接口，然后调试中逐渐使用安卓底层的工具，我感觉不对劲，提示它之前是正常调试的，可能是基础的一些 host 配置之类的问题，然后 AI 很快就解决了。

此外获得用户反馈本身仍然会阻塞开发流程。虽然程序都是 AI 写的，但是 AI 本身需要用户（也就是我)的反馈，我导出 Codex 的 session 文件分析，平均每个任务大概跑三分钟，最慢的跑了1小时22分钟（当时是 OpenAI 给我把模型降级到了 GPT-4o mini，我没有及时调回来)。不过这里面很多 prompt 都是在探讨技术方案，实际上肯定比三分钟更长。

全程做了四十小时，其实大部分时间都是我作为用户给出反馈，然后根据反馈 AI 来进行调整。也就是我作为用户，给出反馈成为了当前的瓶颈。比如AI完成的初稿会把删除按钮放在保存按钮旁边，很不安全，我先改成了其他位置，后来直接去掉了，改用回收站。

值得一提的是就在写项目的过程中，Codex 产生了一个很严重的线上 bug，就是它会频繁写入大量的日志，如果长时间开大量 Agent 会导致电脑的固态硬盘寿命严重缩短，网上已经有不少用户的 MacBook 硬盘被影响。这其实非常严重的线上 bug，可以直接损坏硬件。这个事件本身也是我观点的证明，有一些 bug 其实超出了 AI 的反馈闭环，AI 在开发环境中无法进行验证。只有得到真实用户的反馈，才能去修正。

AI 技术债

完成整个项目之后，我花一天时间过了一遍程序，我并没有仔细阅读程序的每一行，只是读程序的架构、API 设计。而且只读后端，没有读 Django Template 和 JavaScript、CSS 的部分。且重点阅读测试部分，因为测试深刻影响到程序的正确性和 AI 的调试速度。

在这个过程中，出乎意料还是发现了一些技术债。

首先AI 似乎把测试当成了调试器。

但我期望的测试其实是程序核心功能的约束，方便未来改动，能够保证不破坏核心功能。

AI 写的测试是基于 feature 迭代来的，缺乏主要的 workflow 测试；比如我删除一个按钮之后，AI 会专门写一个端到端测试，测试这个按钮不在了。

端到端测试是很慢的，所以我检查了一遍，把所有的冗余测试删除了。

此外测试缺乏分类重组，而是每个 feature 新启动一个测试文件。

测试相关的技术债很容易导致未来测试运行越来越慢，AI 本身得到反馈的速度就变慢了。

此外测试文件还有一些命名错误，比如测试插入日期，但是名字叫 test_editor ，太宽泛了。我全部做了重命名。这种错误很容易误导 AI 和程序员。

再比如测试两个功能，写了一个巨大的文件，没有做拆分。这让未来修改变得更困难。

AI 会保留冗余程序。

中间我想要实现回收站，换了实现方案，结果旧方案的程序都保留下来了，只是没有调用。这种技术债累积的话，很容易导致未来 AI 和程序员阅读和修改越来越困难。

AI 似乎没有整理的概念。

当时我要做账户安全的功能，它的 models 和 view 散落在了各个地方，最后我整理合并成一个 Django app。对人类程序员，这已经是非常严重的技术债了。

综合来看，技术债问题在当前的 AI 编程中仍然存在，而且可以累积。如果这些技术债随着项目累积，项目达到十万行、百万行，我不确定到时候 AI 是否还能驾驭这个项目。现在整个业界大量依赖 AI 编程，还有很多人已经完全不读程序了，我怀疑在接下来的几年就会遇到 AI 编程技术债的问题。现在很多程序员着重研究 AI 写出来的程序是否正确，但是正确和可维护是两个概念，如果不做 review，导致 AI 产出的程序技术债越过临界点，很有可能出现无法维护的尴尬情况。

所以我认为，在当前，最重要的程序还是要人类接入来 review 设计和结构的。未来可能会适当放宽。

htmx 的作者，也给出过一个 AI 修复开源项目 bug 产生技术债的例子。

为什么 AI 还是会产生技术债？我认为这是因为从软件质量的角度，AI 没有拿到完整的反馈闭环。AI 更容易验证软件的正确性，但是软件的质量目前仍然没有一个非常好的自动化的工具，所以在这个维度看仍然需要人来介入。

AI 把一个软件做对，和 AI 把一个软件做好，是两码事。

如何用好 AI

我认为用好 AI 的关键是，要把整个任务拆分成一个个具有完整反馈闭环的子任务，而且必要时还要主动制作工具去补全反馈闭环，而且还要加速整个反馈闭环。

拆分任务不必赘述，比如有的功能就是要等用户反馈完才能迭代，这部分就适合单独拆分让 AI 先做。

关于补全反馈闭环，我在项目里写 Web 和安卓的时候都做过。

AI 自己并不会主动寻找最优而且完整的反馈闭环，比如会直接生成程序让我看，让我手动测试。我需要告诉它去搭建一个反馈闭环。

比如刚开始做 Web ，AI 不会自己去做完整的验证，而是生成程序写单元测试，然后让我自己验收。我提示 AI 安装 Chromium 和 Playwright，可以自动化做端到端的测试；在做安卓开发的时候，AI 也想让我手动复制粘贴，或者自己检查 UI，我提示 AI 使用安卓上的调试模式，利用查询数据库和截图，自己完成闭环，结果之后的每个 feature AI 都会自己调用安卓的调试 API 完成检查。

OpenAI 今年发过一篇博客，里面提到，他们在线上环境当前使用 AI 来编程，主要的工作就是给 AI 制作一个运行环境，比如给 Codex 接入 Chrome 的 devtools。这和我的感受很一致，我在做项目的过程中，花了很多精力让 AI 能够快速完成整个调试反馈闭环。

还有很重要的一点就是加快反馈闭环的速度。我在项目里提升了端到端测试速度：在开发一段时间后，端到端测试膨胀到几千行，全量运行一次需要260s。我做了两件事

• 先让 AI 写了一个测试的调度器，分析所有测试的时长，然后用 Worker 模式，采用多进程去跑。
• 然后针对每个测试，做了一些改进，比如有的测试会串行测两个大功能，我就拆分成两个文件单独测试。

这让 AI 调试程序速度提升了一个数量级，从260s降到了不到20s。而且单个文件的最大值也降低了。

这是优化前的速度：

这是优化后的速度：

我怀疑接下来整个业界将在 Coding Agent 的运行环境上面投入大量资源，调试反馈本身就很重要，也是过去这些年软件业的发展重点，比如 IDE 技术、静态检查、增量编译，Agent 每天的调试次数可能比人类高一个数量级，调试速度将变得更加重要。OpenAI 买 Astral，Anthropic 买 Bun，都能看出 AI 巨头在围绕 Agent 的上下游布局。

此外，沉淀出一套工程规范也很重要。很多时候我心里有一套规范，但是 AI 并不会完全执行，比如我让 AI 实现功能，一般分为开发和上线两个阶段。开发阶段只做针对这个功能的测试，做完不跑全量测试，让我看看效果，等我确定之后进入部署阶段，跑全量测试，git push，部署到线上。刚开始我手动命令 AI 做，后来上下文一大了 AI 就会忘记，我就把规则写进了 AGENTS.md 文件，AI 会按照我的指令区分开发模式和部署模式。

感想

编程这个工作会消失吗？

我觉得这取决于如何看待编程工作？在我的视角，工作的本质是解决问题、创造价值，而软件本身是工作的子集，手写程序本身又是软件的子集。

我觉得手写程序这个环节未来会逐渐变得不重要，人类逐渐托管给 AI，但是剩余的部分，包括调查、创造性思考、人与人的交流、阅读、验收、决策规划都变得更加重要。

举个例子，我在之前工作的医学研究中心，曾经遇到过一个问题：部门的医学研究有很多纸质文件，上面有调查对象的编号和手写签名。需要按照规范命名：标注编号和调查对象姓名。然后上传到医院的系统中完成匹配。开展研究时，每天的文件有一百份左右，需要一个大纸箱从现场运到办公室，然后五个同事整理和校对一下午才能完成正确的命名。而我为其设计了一套完整的自动化，只需要三分钟就能自动做完重命名，而且还能把纸质文件和当天的调查人员名单做匹配，进行错误校验。

那么我的工作是在办公室电脑旁写程序就能做完吗？当然不是。首先我要发现这个问题，需要仔细观察整个研究的全流程，看有哪些部分可以借助软件进行优化。其次这件事的难点是手写签名和编号很难识别，我发现现场有一台标签纸打印机，如果能够打印出标签来，标注姓名和编号，贴在文件上，就很容易自动识别。

我先学习使用部门的标签纸打印机，然后尝试不同的排版做实验，研究出了最佳标签纸排版，在上面打印每份报告的编号和姓名，能够让 OCR 程序识别正确。然后我需要找医学研究环节中的很多同事，问清楚打印标签纸、贴标签纸、扫描文件等等都由谁负责，其中不同的人说法不同，我要做判断，最后我还要能够说服各个环节的同事协助我完成打印和贴标签，而写程序做 OCR 识别反而成为了最简单的部分。

这些过程都远远超出了手写程序的范围，有很多是在询问和说服别人。我认为我是来解决问题的，制作软件只是环节之一。

而且我过往的很多程序都是在查文档、调通 API，这个过程是非常不愉快的。比如我当初用 React 写笔记本，项目使用了 MUI 和ESBuild，当时的 ESBuild 和 MUI 有冲突，编译时会有一个特别底层的报错，最后我查了整整两天，在官方的聊天群里找到了解决方案。这种经历我不想再有一次。AI 更多是把我从这种繁重的体力劳动中解放出来。

如果往更深了问，是否有一天 AI 可以独立完整地创造价值、解决问题？我觉得这更多是一个科幻情节，不属于本文讨论的内容。本文是务实的角度，先做好接下来几年的职业规划和探索。

人人都是程序员了吗？

有种说法是，现在有了 AI， 人人都能写程序了，所以现在不应该去做程序员。程序员都应该转行。

对于这种观点的对错，我可以换个说法：现在互联网论坛，人人都能当作家了，所有作家都应该转行。

读者自然能看出问题所在，设计系统和产品，难点在于知识、思考、执行，现在 AI 把编程降到了写作的门槛，但我认为仍然是很高的。

我见过一些激动人心的例子，比如微博上有位电影导演，用 AI 写程序整理了自己电脑上积攒几十年的资料，还写了一个语音输入法。但是就像写出有价值的文章一样，真正写出有价值程序的人终归还是很稀少的。

写出demo，写出完整的个人应用（比如 iOS 上的记账应用)，再到把程序推到线上让大量用户使用，每一步的难度要陡增。

X 上有位用户讲过这样的经历，亲戚的团队里面有人自己做了一个 JIRA，刚开始特别兴奋，结果过了一阵子最后还是用回了商业软件，因为对于大部分人在本职工作之余，即使用 AI 维护一个 JIRA 也是很耗费精力的。

我自己只是做了一个个人产品，但是过程中打磨 UI 细节也是耗费了巨量的精力，因为我本身对于个人工具很感兴趣，又懂编程，所以我愿意亲自动手做。如果换做不感兴趣的工具，我还是宁愿买一个。

下一步，何去何从?

就算 AI 从现在起停滞，编程这件事也已经彻底改变了。AI 编程工具还处于尚未完全探索和开发的状态，潜藏着大量的机会，软件作为社会的新基建，也会自上而下引发社会的很多变化。我们正处于一个时代变革的早期。

至于说接下来的工作和学习究竟要如何具体规划？我觉得这件事没人知道确切答案，因为新科技出来初期，没人完全知道如何使用，当前每个人都在探索。我的想法就是多关注 AI 的进展，积极把 AI 引入到自己的工作生活中。

我认为接下来的决策要围绕反馈闭环来做。凡是 AI 能轻松获得完整反馈闭环的工作都要问一句：这件事我要需要亲自动手做吗？花费力气再去雕琢手写程序的细节，已经没有意义了，接下来程序员的工作更多是研究如何为软件工作构建一个完整快速的反馈闭环。然后人去做更重要的事情，现有的很多软件未来都会推进到新形态。