在2023年4月时，我曾在工作上搞过一次当时的AI辅助开发调研，调研对象是Github Copilot X及ChatGPT，彼时我的结论是Copilot的代码提示与补全可以一定程度提高软件开发效率。
但当时的模型幻觉频次较高且智能程度有限，让我觉得LLM（Large Language Model，大语言模型）的代码补全甚至不如LSP（Language Server Protocol）补全来的实际有效，所以23年到现在这三年里，大部分时间LLM在我的开发场景中是扮演着一个高级Google的角色。
时间来到了2025年12月，工作上的的一些脚本类工作让我又捡起了AI辅助开发，在使用了一两个月之后，我想我需要写些东西聊聊当前大模型时代下的软件开发。
Contrast 对比
Previous Status 旧时
2023年4月，AI辅助开发处于对话+单次代码生成的阶段，也就是每次代码生成都需要与LLM对话。在这个阶段，AI辅助开发的作用是有限的，一是人工干预的地方多，二是当时LLM受限于上下文大小、智能程度、幻觉等因素。
虽然LLM在经验上有着超越绝大部分开发者的优势，但在实际开发场景下，这个阶段的AI辅助对开发效率的提升是有限的。如果你在这个阶段使用过AI辅助开发工具，会发现此时AI对于通用问题有着很好的“直觉”，但对已有代码的理解有限，解决现有代码问题能力较弱。
Current Status 当前
2026年2月，此时的AI辅助开发来到了智能体Agent阶段，AI辅助开发智能体可以理解为大模型循环（相对于event loop）+工具调用的自动化程序，开发者仅需单条对话即可完成大量任务。这个过程大致过程可以描述为：
graph LR
A[用户需求提出] --> B[agent环境感知]
B --> C[任务规划]
C --> D[代码生成]
D --> E[测试编译]
E --> F{捕获反馈}
F -- 存在问题 --> G[LLM修复]
G --> D
F -- 任务完成 --> H[输出报告]
style A fill:#d4f0f0,stroke:#333
style H fill:#d4f0f0
AI辅助开发智能体是很自然的想法的产物，23年彼时AI辅助开发比较像是在指挥一头蒙眼的驴子，开发者需要不断的挥鞭子，这头驴子才会亦步亦趋的前进。
智能体程序则是接管了挥鞭子抽LLM的工作，同时智能体还拥有了文件编写、终端命令执行等能力，让代码开发从手动时代迈向了自动化时代。
相比23年，此时的LLM拥有更大的上下文宽度、更精准的文本检索能力、更好的逻辑推理能力，这使得现在的智能体可以理解并编辑整个项目内多个文件。
Experiment 实验
TinyMCP是我个人的一个实验性项目，它是从Qihoo360 TinyMCP fork出来由我续写开发的，C++编写的MCP（Model Context Protocol）小型SDK。
2025年我在工作上开发MCP协议相关代码时，由于当时缺少MCP协议相关资料，我曾参考过这份实现（MCP官方C++ SDK缺失）。原项目在开发完基础的stdio模式后就停止更新了，我fork了一份续写了http模式、实现了原版本未实现的MCP协议内容，这个项目会成为今后我用以与MCP协议标准进行对齐测试的项目，如果你对这个项目有兴趣欢迎指正。
在TinyMCP里我大量使用了AI辅助开发，使用基于Claude4.5模型的智能体，目前为止新代码里大概1/5的代码是我手动编写的，其余皆是AI生成，所以你可以在代码中看到AI的影子。从实现结果来说，个人还是比较满意于当前AI生成代码的，逻辑功能正常、代码风格一致，开发效率上保守地说提升了1倍。但是，啊，这里应该有个但是…
This Illusion 幻觉
原谅我这个老二次元用了这个英文小标题…咳咳，claude 4.5模型是当前最先进的一批Coding模型（当然现在有了claude 4.6），它在理解现有代码及解决问题上有着相当好的“直觉”，这种“直觉”是只有丰富经验的开发者才拥有的。但如果你放任其编写大量代码、牵扯多个文件时，其生成代码会出现一些“怪味道”，这种“怪味道”有逻辑问题、效率问题、设计问题，逻辑问题可能会在智能体的不断循环中得到修正，但效率问题、设计问题如果不经开发者进行提示大模型自身较难发现。
开发TinyMCP时我发现claude生成的代码存在问题，主动提示了智能体去修正，一些经过多轮对话后claude能正常修复，但也有一些不行。比如我提示TinyMCP示例中的MCPServer在接收到停止信号时无法正常退出，尝试了多轮对话也没有解决，最后我手动修复了这个不算复杂的问题。
关于AI生成代码如何进行测试或者review，2025年业界也有了很多讨论，也有了一些方案比如再引入AI去做评判等，这里不展开。我想说的是，人在当前这个AI辅助开发的阶段中（或者说今后的软件开发中），仍然或者说应当是那个拿着鞭子的主导者。
Introspection 一个老软工人的自省
软件工程领域有两篇著名文章，《人月神话 The Mythical Man-Month: Essays on Software Engineering》和《没有银弹 No Silver Bullet—Essence and Accidents of Software Engineering》，都写于上世纪七、八十年代，主旨是说软件开发是个十分复杂且困难的过程，这个复杂性包含了计算机自身的复杂性、软件自身逻辑的复杂性、开发过程中的复杂性，作者Fred Brooks（1999年图灵奖得主，IBM OS/360 主导者）在1986年的《没有银弹》中得出一个结论:
as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity.
我们预见，从现在开始的十年之内，将不会看到任何银弹，无论是在技术上或管理上，都不会有任何单一的重大突破，能够保证在生产力、可靠度或简洁性上获得改善，甚至，连一个数量级的改善都不会有。
在1986至今的这四十年里，Brooks的预言可以说是应验了的，至少我个人是这么认为的。高级语言、面向对象编程、图形化编程、自动化测试这些在《没有银弹》中论述过的技术，都没有成为真正意义上的杀死软件开发复杂性这个“Vampire”的“Silver Bullet”。
彼时Brooks在《没有银弹》也论证过Artificial Intelligence、Expert Systems、Automatic Programming的一些可能性，只是老爷子在40年前想不到此时的AI会以概率+程序的形式出现在世人面前，那么此时的AI会成为那个“Silver Bullet”吗？这个问题目前我还不好回答，但是我明确的感受到软件开发的变革时间节点已经来临，目前的AI会重塑软件开发的形态。
Essence of Software Development 软件开发的本质
大多数软件开发活动可以概括为“复用已有技术解决实际需求”，这其中的关键字包含“重复”、“已有”，所以目前的AI是天然适合于解决这部分软件开发问题的。
以上述TinyMCP为例，我的一个需求是新增http传输层，使用到的httplib是现有技术，开发过程就是将名为httplib的积木搭建成名为http传输层房子的过程，这整个过程都有旧物可以参考的。
但也有少数软件开发是“创造性”的，比如设计新算法，设计新的系统架构，目前的AI在这种场景只能起到一个启发式的作用，不过to be honest，这部分的软件开发活动大概只占全部软件开发活动的10%。
Persona of Developer 开发者的角色
Nvidia（为什么一提起Nvidia我总会想到竖着中指的Linus…） CEO黄仁勋在2024年迪拜世界峰会上说道：
It is our job to create computing technology that nobody has to program and that the programming language is human, Everybody in the world is now a programmer.
我们的工作是创造出一种不需要编程的计算机技术，让人类语言成为编程语言，现在，世界上每个人都是程序员。
某种程度上来说皮衣刀客的话成真了，现在只需几句提示词谁都可以生成一段代码。但就目前的AI来说，编写中大型软件、解决一些稍复杂的问题仍然需要“Programmer”来干预。在这个时代下，开发者的角色更多的是回归到设计者上，实际大部分编码工作可以交由AI来完成。
那么问题来了，在这个时代，一个不具备计算机软件相关知识的人可以成为合格的软件开发者吗？----想屁吃呢
Epilogue 结语
相比23年，目前的AI智能体让我真实感受到了生产力的提升，打一个不太好的比方，对于我们“码农”来说，原先是需要手工播种、灌溉、除草、收获的时代，而现在出现了各种自动化机械，甚至能自动完成从播种到收获的全流程，那生产力自然是上升了一个级别，但是种什么、如何保证收获的质量仍然是需要“码农”这个主体去决定的。
以上仅为我个人观点，如果你有不同见解，欢迎指正交流，本文全文纯手敲。