7 月 24 日，我第一次真正开始接触 AI 自然语言编程。

到今天，满打满算也就二十多天。

这二十多天回头看，做出来多少功能、写了多少代码，反而已经不是我觉得最有意思的事情了。真正让我有点意外的是：我一个原本完全不做程序开发的人，居然在不停地折腾 AI、改程序、部署、出 Bug、再修改的过程中，慢慢自己悟出了一些软件开发和项目管理最基础的逻辑。

而且这些东西，一开始根本没人教我。

都是被项目逼出来的。

一开始，我只是觉得：原来程序真的可以“说出来”

7 月 24 日，我最开始其实没有什么宏大的计划。

只是想做一个能解决自己实际需求的小工具。

那时候我对所谓 AI 编程的理解非常简单：

我把需求告诉 AI，它把代码写出来。

甚至第一次看到一个原本只是脑子里的想法，被 AI 一点点写成可以运行的页面、后台、数据库时，那种感觉是相当震撼的。

以前我一直觉得，软件开发和我之间隔着一道很高的墙。

你得学语言，学框架，学数据库，知道服务器怎么运行，还得掌握一大堆我连名字都叫不出来的东西。

AI 出现以后，这堵墙突然矮了很多。

我不需要先学会怎么写 PHP，才能告诉 AI：

这里应该增加一个按钮。

我也不需要先搞懂 SQL，才能说：

这个数据我希望保存下来，以后可以统计。

我只需要把我要什么、为什么要这样做、实际使用时应该是什么感觉，说清楚。

AI 就能去完成大量过去必须依赖程序员完成的工作。

所以一开始真的很容易上头。

功能越做越多，想法也越来越多。

第一个项目很快教会我：做出来，和能用，是两回事

最早真正持续迭代的是 ChenTW RSS。

从 7 月 24 日确定方向，到 25 日、26 日连续修改，Build 很快就排到了几十个。

一开始我关注的是功能。

RSS 能不能抓。

AI 能不能筛选。

后台能不能运行。

OPML 能不能导入。

栏目能不能分类。

页面能不能在手机上正常显示。

但很快我发现一个问题：

“这个功能已经写出来了”，和“这个东西实际很好用”，根本不是一回事。

可能 RSS 地址 technically 是对的，但真正丢到 Inoreader 里面体验并不好。

可能某个后台功能已经有了，但实际操作起来非常别扭。

可能 PC 页面看起来正常，手机上一打开就完全不是那么回事。

还有很多 Bug，并不是 AI 不会写，而是我一开始根本没有想到实际使用时会发生这种情况。

于是我开始明白：

AI 可以极大降低“实现”的门槛，但它不能替我判断这个产品到底应该是什么样。

产品判断还是我的。

AI 负责的是把我的判断变成程序。

这大概是我第一次真正意识到：自然语言编程并不是“我什么都不用懂了”。

恰恰相反，我开始必须更清楚地知道自己到底要什么。

然后问题来了：AI 太能改了

项目继续往下做，很快出现了第二个问题。

AI 写代码很快。

快到什么程度呢？

快到你一个需求说下去，它可能同时改七八个文件。

如果再说第二个需求，又会继续改。

刚开始看着很爽。

但很快就出事。

我开始搞不清楚：

现在服务器上到底是哪一版？

刚才那个 Bug 是哪个版本修好的？

这个文件为什么被改了？

上一个功能到底有没有正式部署？

AI 说“已经完成”，到底是代码写完了，还是测试完了，还是已经上传到生产环境了？

甚至有时候，解决一个问题的时候，会顺手把原来已经正常的东西改坏。

这时候我第一次真正感受到：

一个软件项目真正可怕的，并不是代码写不出来，而是项目开始失控。

于是我很自然地开始给版本编号。

开始记录 Build。

开始写 Changelog。

开始区分“已经开发”和“已经部署”。

开始要求每次修改必须知道到底动了哪些文件。

后来又引入 Git。

现在回头看，这些东西对真正的软件开发人员来说可能都属于常识。

但我当时不知道。

我只是觉得：

不这样搞，我自己已经管不过来了。

再后来，我开始给 AI 立“基本法”

功能越来越多以后，又遇到了一个更麻烦的问题。

AI 没有长期记忆。

或者更准确地说，它每一次工作时能够掌握的项目背景都是有限的。

一个新聊天开始以后，它可能根本不知道为什么这里以前要这么设计。

更危险的是，它可能看着现有代码觉得：

这个地方好像可以“优化”。

然后一优化，把我前面花了很多时间才确定下来的核心业务逻辑改掉了。

这对我刺激很大。

所以我后来开始不断要求项目建立一些不能随便动的文件。

项目规则。

核心逻辑。

技术基线。

当前状态。

变更记录。

我当时甚至开玩笑把其中一些东西叫“宪法”或者“基本法”。

后来正式文档当然不会真的这么写，但这个比喻我一直觉得很准确。

因为我要解决的问题就是：

AI 可以自由开发，但有些东西不能因为换了一个聊天、换了一个模型、换了一个执行器，就重新解释一遍。

项目必须有自己的记忆。

这时候，我的开发方式已经慢慢从：

我告诉 AI 一个需求，AI 去修改代码。

变成了：

先确认现有规则是什么，再判断这个需求会不会影响基础逻辑，然后决定改哪些地方，最后记录这次变更。

这个变化其实非常大。

只是当时我自己没有意识到。

我甚至开始规定：先别动代码

后来我又形成了一个现在看来很有意思的习惯。

很多需求，我不会再让 Codex 一上来就开发。

而是先说：

第一阶段，只读审计。

你先告诉我现在项目是什么状态。

准备改哪些文件。

会影响哪些逻辑。

有没有和现有规则冲突。

不要修改。

等方案确定以后，再正式开发。

为什么会形成这个习惯？

还是被坑出来的。

因为 AI 最大的问题之一，就是太勤快。

你只是想讨论一下，它已经帮你改完了。

但真正的工程项目里，有些问题首先需要判断“该不该改”，而不是“怎么改”。

这件事情让我后来突然想到了施工管理。

施工现场也不可能谁觉得这里应该改一下，就直接拿机器上去干。

先有设计。

设计有变更。

变更有依据。

施工以后还要验收。

出了问题，要知道是谁什么时候改的。

软件开发其实也是一样。

代码就像实体工程。

Git 像施工留痕。

Build 像版本节点。

项目文档像图纸和技术交底。

Changelog 像施工日志。

测试和生产验证就是验收。

而项目里面那些不能随便变化的基础规则，其实就像设计规范。

我老板是搞工程管理的，我天天接触的也是项目管理。结果没想到，我最后居然是拿施工管理的思维，把软件开发这件事情给理解了。

到了 8 月，我已经不满足于让一个 AI 干活了

后来项目越来越多。

RSS、知乎推荐流、ResearChen、小程序、一些小工具……

一个很现实的问题又出现了：

如果所有事情都依赖同一个聊天窗口，那么这个聊天窗口本身就变成了项目风险。

上下文越来越长。

信息越来越多。

换窗口以后又要重新交接。

于是我开始折腾“双执行器”。

一个负责真正开发。

另一个负责理解项目状态、检查、归档、交接。

我甚至花了不少时间研究：一个 Agent 怎么把信息可靠地交给另一个 Agent；一个已有线程到底能不能真正被另一个系统接管；resume 和重新复制上下文，本质上到底有什么区别。

有些实验成功了。

有些最后证明没有必要继续折腾。

但这件事让我开始意识到一个更深的问题：

未来的软件开发，可能根本就不是“一个人使用一个 AI 写代码”。

而是一个人管理多个 AI，让不同 AI 分别承担规划、开发、审核、测试甚至资料管理。

这个感觉，已经越来越像真正的项目管理了。

直到今天看到 Harness，我才突然知道自己这段时间到底在折腾什么

今天看了一篇关于 DeepSeek Harness 的文章。

文章非常专业，很多术语我其实也看得很累。

但看完以后，我突然觉得有点熟悉。

因为它讲的很多东西，我这二十多天其实已经用一种很原始、很人工的方式在做了。

模型只是其中一部分。

模型外面，还需要有项目规则、工具、上下文、状态、任务流程、测试、记录、权限和不同 Agent 之间的协作。

以前所谓 AI 编程，大家最关心的是：

哪个模型写代码最厉害？

但我现在越来越觉得，未来真正重要的问题可能会变成：

你怎么组织这些模型干活？

模型就像施工队。

施工队当然要有能力。

但一个大型工程最终能不能做好，显然不取决于某一个工人砌墙是不是特别快。

真正决定项目质量的是一整套体系：

设计、计划、材料、施工、资料、变更、成本、验收、责任划分。

AI 软件开发可能也正在走向这个阶段。

二十多天前，我甚至不知道 Git 到底有什么用

这可能是整件事情最让我有成就感的地方。

7 月 24 日的时候，我只是觉得 AI 太神奇了。

原来我只要说话，就可以让它写程序。

到今天，我已经开始在意：

代码是不是唯一事实基线。

Git 工作区是不是 clean。

Build 编号是不是连续。

这次修改有没有影响核心逻辑。

生产环境到底运行哪个版本。

项目文档和实际代码是不是一致。

开发前是不是应该先只读审计。

修改以后有没有经过测试。

不同执行器之间怎么完成可靠交接。

这些东西，我二十多天以前基本都不知道。

而且我并没有专门系统学习过什么《软件工程》。

大部分道理，都是一个 Bug 一个 Bug撞出来的。

一个版本一个版本乱出来的。

一次次 AI 把东西改坏以后逼着我补出来的。

所以现在回头看，我反而觉得这二十多天最大的成果，并不是 RSS 做出来了，不是知乎产品做出来了，也不是小程序跑起来了。

这些当然都挺有意思。

但真正让我觉得有点不可思议的是：

我居然开始建立了一套属于自己的软件项目管理直觉。

而且这套直觉，还是从我原本熟悉的工程管理经验里面自然长出来的。

AI 降低的也许不是编程门槛，而是“参与创造”的门槛

以前我大概不会把自己和“软件开发”联系起来。

因为我不会写代码。

现在我仍然不会像真正的程序员那样写代码。

但我已经越来越不觉得这是什么根本性的障碍了。

因为 AI 以后会越来越擅长写代码。

真正稀缺的可能反而变成：

你到底想解决什么问题？

你能不能把需求说清楚？

你能不能判断 AI 做出来的是不是你真正要的东西？

一个项目变复杂以后，你能不能控制它，而不是被它拖着走？

出现冲突的时候，什么应该坚持，什么可以修改？

怎么让一个今天开始的项目，三个月以后依然还能继续开发？

这些问题，好像已经不是“会不会写代码”能够回答的了。

所以我现在反而觉得，“AI 自然语言编程”这个词可能有点把事情说小了。

它不是简单地让一个不会编程的人也能写程序。

它真正改变的可能是：

过去很多人连参与软件创造的资格都没有，因为代码是门槛；现在代码这个门槛正在迅速降低，于是人的判断、经验、管理能力和对真实需求的理解，开始进入软件开发过程。

对我来说，这才是这二十多天最有意思的事情。

从 7 月 24 日开始，我原本只是想让 AI 帮我做几个工具。

结果做着做着，我开始学会管理版本，管理规则，管理 AI，甚至开始理解为什么一个软件项目必须有自己的制度。

这么看，这二十多天确实还挺不错的。

至少下一次再有人告诉我：

“AI 编程不就是跟 AI 说几句话，让它帮你写代码吗？”

我大概会说：

刚开始的时候，确实是。

做到后面，就不是了。