用 AI 重写一个维护六年的个人项目：我摸索出的「反馈闭环」
作者用几个月时间，借助 AI 把一个线上跑了六年的个人小工具彻底重写并扩写。他从中得出一个核心判断：AI 编程的关键不只是模型有多强，而是能不能给 AI 搭起一个完整的「反馈闭环」。本文记录了重写的过程、踩到的局限，以及由此延伸出的思考。
前言：AI 编程的关键是「反馈闭环」
最近我用 AI 改写了一个维护六年、至今仍在线运行的个人项目。AI 帮我省下大量时间，也让我实现了不少复杂的新功能。但与此同时，我也清楚看到它当下的边界，并逐渐摸出了和它协作的方法。这篇文章既记录过程，也记录沉淀下来的想法。
绕完整件事，我认为当前 AI 编程里有一个很重要的概念：反馈闭环。
什么是反馈闭环？简单说，AI 执行任务时会经过多个环节——思考、调用工具、验证结果——并且要反复循环迭代。一个完整的反馈闭环，意味着 AI 能从任务开头一路跑到结尾，人只需要下达指令，中间不必插手。但现实中大多数编程任务都很难给 AI 提供这样完整的闭环，人还是得在设计方案、接入工具、验证结果这些环节反复介入。比如 AI 缺某个工具，需要人想办法给它接上；又或者 AI 无法独立判断结果对不对，必须人来亲自确认。
AI 强在哪里、弱在哪里，其实都围绕反馈闭环的完整程度展开。而程序员的日常工作，也正逐渐从亲手写代码，转向为 AI 构建一个完整的反馈闭环。
模型本身已经足够聪明，但整个社会还没准备好把 AI 接进各类真实工作里——因为很多工作尚不具备让 AI 完整闭环的条件。这可能也是接下来软件生态发展的一个方向。
背景：从「不敢用」到「被震惊」
去年年初，网上已经有很多人在说 Cursor、Codex、Claude Code 已经相当可用。但我当时手上的项目涉及大量线上敏感数据，不适合让 AI 直接写，所以我还是让 AI 帮忙查资料，代码自己手写、自己调试。
转折发生在今年年初。一位朋友非常郑重地向我推荐了 Codex，当时背后的模型是 GPT-5.4。我刚好完成了一个小项目：用 Python 复刻 CPython 官方的 json 库。于是顺手给它加了个功能，支持注释写法。结果 Codex 只用了几分钟就写好测试、完成任务。这让我相当惊讶——我对 AI 的印象还停留在聊天机器人，亲眼看到它能独立完成一个编程功能，感觉很神奇。
回头说一段旧想法。2022 年 ChatGPT 面世时轰动全球，但我当时认为聊天机器人这个形态本身就限制了 LLM。真正的智能应该能做实验、从现实中获得反馈，因为做实验是获取知识的核心手段。只有这样，AI 才能摆脱预训练的限制，在现实中思考、学习、进化。不过我当时设想的载体更多是机械臂、小车之类，觉得还很遥远。到了 2026 年，AI 已经在软件环境里拥有了自主行动、做实验的能力。
最近我抽出几个月时间，打算独立研究 AI。需要第一个项目来探索 Coding Agent 的用法，而我手头正好有个个人工具——我叫它 SmallTool，向 Smalltalk 致敬——就打算用 AI 把它彻底重写一遍，顺便加功能。
这个项目最早可以追溯到 2020 年。疫情刚起，我春节闲着，用一个假期写了个 todo list 自用。当时技术栈很简陋：JavaScript + AJAX + Flask，服务器还是手动敲命令部署的。2022 年初，我用 Vue + Django 重写了一版；2023 年又用 TypeScript + React + mypy 重写一遍，加了笔记本功能，并用 Ansible 做自动化部署。功能其实很简陋，前后端加起来也就三千行左右，但在线上已经稳定运行六年。
站在 2026 年回看这个项目，我列了几条改写方向：
- 简化技术栈：去掉 React，改用 Django Template，数据库换成 SQLite。
- 引入 Markdown 富文本编辑器，支持实时保存。之前的笔记本只是个简陋的 HTML 表单。
- 给笔记本做一套完整文件系统，模仿 Mac，支持嵌套目录和拖拽移动。
- 做一个安卓客户端，监测我的手机使用情况。我压力大的时候容易对视频和长文章上瘾，想戒掉对网络媒体的依赖，第一步就是先测量自己到底刷了多久。
- 接入佳明手表数据。佳明数据很全，但自带分析偏弱，所以我把数据导入到自己的 web 工具里，想怎么分析就怎么分析。
可以看到，这已经不只是技术栈的大改，还加了很多新功能，甚至引入了佳明和安卓手机两个设备的数据源。所以它与其说是重构，不如说是扩写。
顺带说一句，2024 年我写过一篇文章谈 Web 技术栈，如今我的看法完全变了：这套栈太重了。对个人项目，或者公司项目的初版而言，它是一种过度设计，引入太多复杂度，反而让开发更困难。所以借这次机会，我也想验证一下简化技术栈之后的效果。
项目成果
截至本文写作时，SmallTool 已经运行一个月，甚至这篇文章的一些初始灵感就是记在它上面的。
目前项目功能分四块：todo list、笔记本、佳明数据同步、手机使用情况统计。
下面是文件系统和笔记本的实际效果：
核心功能都做了移动端适配，UI 细节也做了不少微调，比如支持调节字号、夜间模式等。
关键要点
- 作者用 AI 重写了维护六年、仍在线运行的个人项目 SmallTool，技术栈从 React + Django 简化为 Django Template + SQLite。
- 核心观点是「反馈闭环」：AI 能否独立完成从思考、调用工具到验证结果的全流程，决定了它的能力上限与局限所在。
- 程序员的工作重心，正从亲手编码转向为 AI 搭建完整的反馈闭环。
- 项目不仅是重构，还新增了 Markdown 实时保存、仿 Mac 文件系统、安卓手机使用统计、佳明数据同步等功能。
- 作者反思：此前那套较重的 Web 技术栈对个人项目而言属于过度设计。
安卓端与数据采集
安卓端的界面本身很简单，数据展示的活儿都交给了服务端。我在后台挂了一个常驻通知，每两小时自动采集一次数据：
采集的是佳明手表的数据，再和安卓手机的息屏时间联动分析。为了快速判断睡眠状况，我按不同颜色给数据打上标签：
代码量的统计结果如下。值得一提是，生产代码和测试代码的比例大约是 1.7:1，其中测试里包含大量端到端测试。
生产代码的语言构成（略）
前文提到，我参考以往做个人项目的经验，专门简化了技术栈：去掉 React，去掉 TypeScript 和 mypy 这类类型检查工具，数据库换成 SQLite。效果怎么样？
非常好。我原本担心这么精简的前端技术栈会让界面变丑，或者代码冗余，结果都没有发生。程序反而很简洁，而且换成 SQLite 之后调试变得特别方便。比如后来想用多进程加速端到端测试时，只要给每个进程分配一个独立的 SQLite 文件目录就行，几乎零改动，非常轻量。
项目用到的 AI 工具
第一周我用 Kimi Code 搭配 K2.7 Code，第二周换成 Codex 搭配 GPT-5.5。项目最后几天 OpenAI 把模型升级到了 5.6，但实际用下来，5.6 和 5.5 没有感受到明显差别——可能和项目规模有关，如果代码库更大，差距也许才会显现。
过程中经常遇到 Codex 额度用完的情况。我的做法是先生成一份当前功能的交接文档，再交给 Kimi Code 接着做。
读代码我用 VS Code，直接在它内置的终端里跑 Kimi Code 和 Codex。
中间我买了 Codex 每月 20 美元的套餐，以及 Kimi Code 99 元的套餐，两个轮换着用，对我目前的用量基本够。
本来我对国产模型预期不高，但 K2.7 Code 出乎意料地好用，写项目的过程中让我相当满意。反倒是原本以为技术难度更低的 Kimi Code，界面完成度让我觉得很低：命令太长时居然会被省略，用久了还会出现乱码。
Codex 的界面细节明显打磨得更好，语法高亮更丰富细腻；模型执行任务时会把思考过程和行为整理成人类可读的摘要；而且额度快用完时，它也会坚持把当前任务跑完，这个设计很慷慨，也很人性化。
现在的编程智能体（Coding Agent）已经支持长时间运行：给一份细致的文档，它能自己跑几小时甚至几十个小时。但我想先弄清 AI 的各个细节，所以没有用这种“魔法”。另一方面，我自己也说不清想要的产品细节——只有看到成品，才能提出修改意见。
AI 到底起了什么作用
AI 在这个项目里给我加了巨大的杠杆：省时间、省人力，让我能把精力放到更感兴趣的地方。
它让这个项目从“不可能”变成了“可能”。
项目总共花了约 15 天，累计大约 40 小时。如果没有 AI，我觉得至少要 80 小时。
更关键的是，这 40 小时很轻松，有些界面细节我甚至是一边打电话一边调整的。
40 小时和 80 小时，差别不是时间翻倍，而是我很可能直接放弃这个项目。如果全部手写，这 80 小时会非常累，要记住和分析大量细节，最后大概率会砍掉很多功能、放弃界面调优，把工作量压回 40 小时以内——因为我手头还有别的事，挤不出那么多精力。
而且我也没有耐心去细啃 CSS 和安卓。真要我手写，界面多半会更粗糙，手机使用网络媒体应用的数据采集也大概率会被放弃。
AI 已经非常擅长调试和写程序了。这个项目里我全程用 AI 代替手写代码和调试。可以说，凡是 AI 能拿到完整反馈闭环的程序，人类几乎只需要做很少的干预。
举几个让我惊讶的例子：
- 写安卓时，在我的提示下，Codex 可以直接在 MacBook 上调用安卓的各种调试功能——截图、上传下载文件、查看应用的 SQLite、跑命令、编译 APK 并安装到我的手机，整个闭环全程不需要我碰手机。
- 部署上线时，Codex 可以用 Ansible 在线上跑命令、查看 SQLite、调用线上接口、看 Nginx 日志，我完全不用做任何线上操作。
我的感受是：只要我能给 AI 一个清晰的目标，并且 AI 有能力完成验证，整个过程就能高度自动化。这种场景下，人只需要给一个比较精确、准确的指令，然后等验收结果就行。
而且 AI 已经表现出一些宏观层面的决策品味。比如 Kimi 在写文件树的时候，会建议先做不带嵌套功能的版本，验证完再尝试做嵌套。这是很典型的迭代思维——先做个实验验证想法，而不是一上来就雕琢细节。
当前 AI 的局限
AI 目前还做不到覆盖任务全流程，用户反馈反而成了瓶颈。
有几处，AI 做的技术决策存在问题：
开发过程中暴露的几个现实问题
先看几个具体案例，它们能说明 AI 协作开发到底卡在哪里。
自动保存的冲突检测，AI 一开始没做好。后来我直接给出算法和界面方案：针对我自己的使用场景，客户端在提交笔记时附上保存时间戳；如果发现提交的时间戳已经落后，就提醒用户刷新。此时用户复制刚写的内容、刷新一次，就能继续正常编辑，不会丢数据。
回收站功能，AI 最初想用状态值来标记被删除的文件，结果越改越多，最后自己绕晕了。我换成复用文件夹的思路：把某个文件夹命名为“回收站”，设为系统专用。改动很小，实现也快。
安卓端调试，AI 无法让安卓应用直接调用 Web 接口，调着调着就开始往安卓底层工具里钻。我感觉不对，提醒它之前调试是正常的，可能是 host 配置之类的基础问题，它很快修正了。
用户反馈本身成了瓶颈。程序虽然是 AI 写的，但 AI 需要我（也就是用户）不断给反馈。我导出 Codex 的 session 文件分析过，平均每个任务大约跑三分钟，最慢的一次跑了一小时二十二分钟——那是因为 OpenAI 把模型降级到了 GPT-4o mini，我没及时调回来。不过很多 prompt 其实是在讨论技术方案，真实耗时肯定比三分钟更长。
整个项目做了四十小时，大部分时间是我在给反馈，AI 再根据反馈调整。换句话说，用户反馈成了当前流程的瓶颈。比如 AI 的初稿把删除按钮放在保存按钮旁边，这很不安全；我先把它挪到别处，后来干脆去掉，改用回收站。
还有一个更严重的事件：写项目的过程中，Codex 产生了一个线上级别的 bug——它会频繁写入大量日志。如果长时间开着大量 Agent，会严重缩短固态硬盘寿命，网上已经有不少用户的 MacBook 硬盘中招。这属于能直接损坏硬件的严重问题。这件事恰好印证了我的观点：有些 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 去做。