前提背景
我有6年的后端开发和7年左右的DevOps的经验。 我对前端的知识，还停留在10年前。 本文纯手打，不是AI生成的。

正文
在今年国庆的时候，我在电脑前喝着咖啡。我儿子跑到我旁边问：你在做什么？
我说，我在看AI写代码。
我儿子问出一个很多人都会问的问题：那公司还要你做什么？
我一下无法回答，带着些许不安，就说：我会干AI干不了的活。

国庆前，我只使用过GitHub CoPilot、Cursor、ChatGPT。我的使用场景是：
1.代码自动完成：比如AWS CDK的TS代码提示不太好；
2.实现某个我不熟悉的算法；P.S. 我认为面试考LeetCode的那些算法是过时，但是，我不认为算法是过时的；
3.白盒安全审计：问AI哪里存在安全漏洞。（直接这样问，它不会回答的，要换角度问）；

4.编译时不通过，我又看不懂时，我就让AI来解决。

国庆放假，大脑里有了一个idea。我写好需求和技术要求并提交给Claude Code + Sonnet 4。我专门选了我不熟悉的后端语言Golang和前端React。然后就发生了我儿子提问的场景。接着在10分钟后，AI就完成了我的最基本的需求。然后我开始以下循环来迭代需求：
1.手工测试
2.提出问题，给AI来解决

3.测试通过后再commit

这个过程中，有一两次的问题，它始终解决不了。我提出了我自己的解决方案，再让它写代码。最后也可以解决。这下好了，AI把我的前端短板给抹平了。有点幸灾乐祸，前端被AI代替似乎有些容易。最后，我再告诉AI：写Ansible脚本将应用部署到一个只开放SSH的远程机器上，并实现蓝绿部署。几分钟后，我阅读着作为DevOps才能写的Ansible脚本，我有些震惊。因为AI给出了一个不错的方案，并画出了部署流程图：

本地环境                    目标服务器
┌─────────────┐            ┌──────────────────┐
│ 1.构建镜像   │    ────►   │ 3.加载镜像         │
│ 2.保存为TAR │             │ 4.启动新环境       │
└─────────────┘            │ 5.健康检查        │
                           │ 6.切换流量        │
                           │ 7.停止旧环境      │
                           └──────────────────┘

作为一个有软件工程思维的程序员，连部署脚本也需要能在本地测试。接着AI开始写Vagrantfile、bash启动虚拟机。事后，我想过，对于没有软件工程思维的人，只要给他一个具有软件工程要求的Prompt，这个人是不是也就可以拥有软件工程能力了？当我真正想要部署这个产品到公网时，买服务器的过程，手工在浏览器上点点点操作时，我前一秒庆幸AI无法做到吧，后一秒又想：这个过程似乎AI也可以做到。只是时间问题。

到此，与AI共同协作共同完成了一个产品。虽然它在可维护上还不完善：
1.2000多行的Golang文件

2.没有任何单元测试 接手的人，可能也只能依赖AI来理解和修改。事后，我才想到，应该在prompt里就要求AI了。

上文中，AI一直是在给我解决问题。还是一个正向助手。我身边也有负向的案例：
案例1: 一个年轻程序员写代码出了问题，自己解决不了，然后找到团队里的老程序员。老程序员一看逻辑，写得乱七八糟的，一问，原来是AI写的。

案例2: 一个http网关，希望实现对response中的文本进行替换，同事让AI一顿输出一个非常复杂的lua脚本。作为leader，我很头大，因为这意味无法维护，出问题，也没有人能修。最后，团队里的一个同事提醒：Nginx本身就有这样的功能，不需要自己实现。

以下是AI对我的文章的总结，基本写出了我的想法：
回头看这次与 AI 协作的经历，我最大的感受是：AI 并不是取代程序员，而是放大程序员的能力边界。
过去，一个人要跨越后端、前端、运维，需要多年积累；而现在，只要能清晰地描述问题，AI 就能帮你搭起一座桥梁。它让我重新思考「工程师」的定义——不再是写多少代码，而是能否把复杂问题拆解为清晰的逻辑，再交给机器去执行。

当然，AI 写出的代码仍然稚嫩，可维护性、架构设计、测试思维都离不开人类的判断。但它已经在改变我们的开发方式：
未来，也许软件开发的门槛不再是写代码，而是理解问题与沟通思维的深度。