我不懂代码,却开始用两个AI做软件工程了

我不懂代码，却开始用两个AI做软件工程了

—— 我正在尝试用AI，做一套自己根本不会写的软件

写这篇文章的时候，电脑上的软件工程还在继续。65个实施任务中，A00“实施基线与风险冻结”已经完成，A01“项目骨架与本地配置”已经完成，A02“统一领域数据规范”正在运行。

所以，这不是一篇成功总结。软件最后究竟能不能按照我的设想完整跑起来，我现在也不知道。

但过去这几天发生的事情，已经让我相当震撼。因为我第一次发现：一个其实不会写现代代码的人，也可能借助AI，把一个复杂的软件想法，按照真正的软件工程方式一步一步做出来。注意，我说的是“软件工程”，不只是“让AI帮我写代码”。

一、先说实话：我现在其实不会写代码

我本科是学计算机的。但那已经是三十多年前的事情了。今天让我面对一个现代Python项目，里面的自动测试、进程管理、沙箱、接口、签名验证、版本控制，我很多代码根本看不懂。

但是偏偏，我现在的研究越来越离不开软件。我想做的是一套茶叶加工在线参数采集与智能分析软件。它不是一个简单的小工具。它需要连接现场的VOC、温湿度、氧气、二氧化碳等传感器；需要接入摄像头；需要运行机器视觉模型；需要对茶叶加工过程进行实时判断；需要显示实时曲线；需要保存和查询历史数据；需要PC版、大屏版和手机版；以后还要考虑云端同步、模型升级、数据反馈和持续优化。

前面我已经做过几个版本。也正因为真正用过，我越来越知道旧版本的问题在哪里。哪些功能必须保留，哪些地方不好用，哪些技术方案应该放弃，新版真正应该增加什么。

所以我现在处在一个很有意思的状态：我要什么，我越来越清楚；但是怎么把它写成程序，我不会。过去，这中间需要一支开发团队。现在，中间多了AI。

二、这一次，我没有让AI一上来就写程序

这是我这次做软件最大的变化。以前用AI修改程序，很容易陷入一种模式：“这里加个按钮”“这里增加一条曲线”“这里报错了，帮我改一下”。一个小程序这样干问题不大，但是软件越来越复杂以后，今天改一点，明天补一点，很快就会乱。

所以这一次，我决定先不写代码。我花了几个小时，和电脑端的AI编程工具反复讨论新版到底要做什么。我把前面几个版本的情况一点一点告诉它：现场设备是什么、实际使用流程是什么、哪些数据要采、哪些旧功能必须继续保留、原来的哪些方案已经证明不合适、机器视觉准备怎么接入、过程模型以后输出什么、PC端、大屏端、手机端分别需要看到什么、云端以后又准备做到什么程度。

有些需求，我自己一开始也没有完全想清楚。所以这个过程实际上不是我单方面“发命令”，而是来回讨论。几个小时以后，需求才逐渐变得清楚。我后来越来越觉得：这一阶段可能比写代码本身还重要。因为AI现在写代码已经很快。如果需求本身是错的，它只会更快地把一个错误的想法变成程序。

三、第一个AI开始做设计，我第一次看到“软件工程”到底是什么

需求逐渐稳定以后，我让第一个AI开始设计整个新版软件。这时候，它做的事情已经不是简单的“生成代码”了。它开始拆系统、拆模块、拆依赖关系、拆任务顺序。设备怎么接、数据怎么定义、多个传感器之间怎么对齐、数据怎么保存、机器视觉怎么独立运行、模型怎么升级、模型升级失败以后怎么回滚、网络断开怎么办、设备掉线怎么办、历史数据怎么兼容、PC、大屏和手机三端的数据结构怎么统一。

然后继续往下拆：每一步做什么，先做哪一步，哪一步依赖前面的结果，做到什么程度算完成，失败以后怎么办，后面应该怎么验收。最开始，整个新版软件大概被拆成45个比较大的任务。后来经过进一步设计和质检，又继续拆分，最后变成65个实施任务。

这个数字对一个专业软件团队也许很普通，但对我来说非常震撼。因为在我脑子里原来只是“我要做一个新版茶叶监测软件”，到了AI这里，它竟然逐渐被拆成65件明确的事情。这时候我第一次很直观地感觉到：AI给我的可能不仅是“编程能力”，它还在补我缺少的软件工程能力。

四、但马上出现一个最麻烦的问题：AI说自己做对了，我凭什么相信？

我不会代码，这是整个项目绕不过去的问题。第一个AI完全可以告诉我：“已经设计完成”“测试全部通过”“可以开始实施”。问题是，我没有能力自己逐行检查。

如果仍然让同一个AI来告诉我“我写得很好，我检查过了，没有问题”，本质上就是自己出题、自己答题、自己阅卷，最后自己宣布满分。显然不行。

所以我想了一个最朴素的办法：再找一个AI。我另外开了一个完全独立的AI对话。它不参与前面的设计。我给它安排了一个非常明确的身份：质检工程师。第一个AI是“施工队”，负责设计、写代码、整改；第二个AI是“质检”，只做一件事：找问题。而且只允许检查，不允许帮施工队修改代码。发现问题就打回去，由原来的施工AI重新改。改完再送回来质检。

五、第一次独立质检，直接给了一个NO-GO

第一次真正进行独立质检以后，我本来以为最多就是提一些修改意见。结果完全不是。质检AI直接给出了NO-GO：不能启动。一次找出了18个问题。

里面很多技术细节，说实话我根本看不懂。但是我要求AI必须把关键问题翻译成普通人能理解的语言。比如一个问题大概是：两个程序有可能同时去抢一个资源。原来的设计相当于两个人进一个房间之前，都先看看里面有没有人；两个人几乎同时看，都发现没人，于是两个人一起进去了。后来修改成：谁先拿到唯一的一把钥匙，谁才能进去。

还有一个问题我一听就明白。原来的施工AI离自己的验收规则太近，理论上它既可以写答案，也可能影响“考试题”。那这样的测试有什么意义？所以后来把关键验收标准单独放出去，做成一个独立裁判。施工AI可以修改自己的代码，但是不能修改裁判的标准。这些代码我不会写，但这里面的逻辑我完全能理解：施工的人不能自己决定自己合格。

六、质检以后，45个任务被重新拆成了65个

第一轮质检以后，施工AI根据18个问题重新整改。在整改过程中，一些原来太大的任务又被继续拆分。最后整个软件实施计划变成了65项。

为了让手机阅读舒服一些，我不在正文里放一张非常宽的六列表格，而是按阶段拆开。这样导入公众号以后，即使在手机上看，也不需要左右拖来拖去。

第一阶段：工程基线、设备和采集

第二阶段：存储、工艺事件与时间体系

第三阶段：摄像头、模型与过程判断

第四阶段：历史数据与三端界面

第五阶段：云端和手机版

第六阶段：模型管理、集成、测试和最终验收

七、比65个任务更让我意外的，是AI又给我设计了6道“人工作业闸门”

我原来想得很简单：既然已经有65个任务，那就让AI一个接一个自动跑下去。结果经过质检以后，系统又多了一套机制：人工闸门。意思是，即使AI自己认为“前面全部通过”，到了某些真正关键的位置，它也必须停下来，等人批准。

这六道闸门不是为了拖慢进度，而是为了把关键决策重新交回人。AI可以越来越多地执行，但最终责任不能交给AI。

八、两个AI能干活以后，我又发现：难道我还要一直守在电脑边？

施工和质检的机制建立起来以后，还有一个现实问题。两个AI在那里干活，我怎么办？难道我必须一直坐在电脑前看着？如果还要这样，自动化的意义其实就少了一半。

前一天，我其实很早就回家了。但是电脑上的工程还在继续。半夜醒来，我又想知道：现在跑到哪一步？有没有卡住？有没有触发重试？是不是需要我再发一条指令？这时候，我把豆包加进来了。

它在整个软件工程里并不是“第三个程序员”，也不是核心质检。它更像一个远程值班员。因为我发现，它连接手机端和电脑端这件事情做得比较顺。于是出现了一个挺有意思的场景：我人在家，电脑还在跑。半夜醒来以后，我拿手机问一句“现在运行到哪里了？”豆包去看电脑端状态。如果没问题，我不用做任何事情；如果需要新指令，我直接在手机上说几句，再让它把指令传到电脑端，然后继续睡。

而且还有一点很重要：豆包如果只是帮我读取状态、看日志、传递指令，本身并不需要频繁调用真正负责写程序的高成本AI。这样，那些宝贵的额度就可以尽量留给真正需要复杂推理的事情：设计、写代码、整改和独立质检。

九、这么新的事情，哪能一帆风顺呢

整个过程当然遇到了不少问题。但我并不觉得奇怪。我要做的是一件自己以前从来没有做过、身边也很少有人这样干的事情，哪能一帆风顺呢。

中间有不少挺有意思的小插曲。AI额度突然用完，那就等额度恢复以后继续。质检会话跑得太久，上下文塞得太多，最后自己“想爆了”，那就重新开一个干净的会话，只给它真正需要检查的材料。

还有一次，为了安全，我们把AI启动的子程序网络权限限制得非常严格。结果限制过头了，顺手把负责施工的AI自己的网络也断了。第一个任务连续三个30分钟都超时。最后查了半天才发现：不是AI不会干，是施工队根本进不了工地。

现在回头看挺好笑。但是这种事情也让我越来越理解：AI工程真正难的地方，并不是让AI写出几行代码，而是让整个系统在真实环境里稳定、可控、能够发现问题、失败以后能够恢复，而且关键时候能够停下来等人。每解决一个这样的问题，整个项目就更像真正的软件工程。

十、我第一次真正理解：软件工程和写代码，根本不是一回事

过去我很容易觉得：做软件，就是会编程。现在越来越觉得不是。代码只是其中一个环节。真正的软件工程至少还包括需求分析、系统设计、任务拆分、版本管理、测试、质量控制、异常处理、安全边界、失败恢复、现场验证、发布，以及出了问题以后怎么退回去。

我不会写现在这些程序。但是借助AI以后，我竟然第一次比较系统地接触到了这些事情。这反而是这几天最让我震撼的地方。AI给我的，并不只是一个“代替我写代码的人”。它开始让我有机会去做过去因为不会编程，根本不敢想的软件工程。

十一、现在，才完成两个半任务

写这篇文章的时候：A00完成，A01完成，A02还在运行。后面还有六十多个任务。所以现在远远不到宣布成功的时候。

最后的软件到底会变成什么样？设备能不能真正稳定运行？机器视觉能不能正常工作？模型输出能不能真正帮助茶叶加工？PC、大屏和手机三个端能不能顺畅配合？跑几天以后会不会又出现以前没想到的问题？我都不知道。也许后面还有很多坑。

但我现在反而很期待。因为这已经变成了一次很有意思的实验：一个几乎不会写现代代码的人，加上几个各司其职的AI，到底能不能真正完成一套复杂软件？

我负责提出需求；一个AI负责施工；一个AI负责质检；豆包帮我远程值守；自动测试负责提供证据；到了关键节点，AI停下来，我签字，然后再继续。

如果最后真的能跑通，我觉得最值得记录的，也许还不是这套茶叶监测软件本身，而是：不会写代码的人，也开始有机会用软件工程的方法，把自己的想法真正做出来。65个任务，现在才刚刚开始。希望后面还有更多惊喜，也希望一切顺利。等软件真正跑起来以后，我再写第二篇，看看这65个任务，最后究竟做出了什么。

附：如果你也想用这种方法做项目，我觉得最关键的是四件事

·先把需求说清楚，不要急着让AI动手。

·让不同AI承担不同角色，最好把“施工”和“验收”分开。

·高成本模型留给设计、编码、复杂质检；状态监控、消息传递尽量交给低成本助手。

·关键节点一定要有人签字，最终责任不要完全交给AI。