序言
其实蹦出来写这篇文章的想法的时间是挺久之前的，ai coding这两年的发展挺迅猛的，已经迭代了好几个范式。我感觉自己其实属于比较早开始入坑ai coding的人，早在23年那会就写过一篇博客，不过后来因为大部分的项目开发要在内网环境下进行，有一阵子没怎么follow这块的新进展，直到今年去业界干活，换了个内外网都能连的工作环境之后，才又开始捡起ai coding这块，结果发现变化超大，一时间有了一种原始人进入现代社会的感觉，人都傻了。大概磨了几个月下来，总算是感觉差不多跟上了，大概对这段心路历程做点小summary。
从大的角度上来说，我把ai coding的发展过程划分为四个阶段，早期阶段（web ai），初期阶段（ide ai 1.0），中期阶段（ide ai 2.0），晚期阶段（agent ai）。叠个甲，由于本人无任何软工基础，也没怎么正儿八经的研究过vibe coding的概念（应该是ai coding的正式叫法），这里的阶段划分纯属民科，欢迎读者们在评论区share自己的意见。
早期阶段（web ai）
22年底gpt刚出一直到23年上半年那阵子，早期阶段（web ai）时，ai coding的范式是挂个浏览器的窗口在那，把代码一段一段贴给ai发过去，再描述一下自己的需求，然后再把ai生成出来的代码贴回去，然后自己运行，有啥问题再feedback给ai看，一步一步这样改来改去。这个阶段主要是因为各家的ai（其实也没几个，除了openai的gpt，微软的new bing，谷歌的gemini，by the way那会好像还叫bard）都是跑在浏览器里的聊天机器人，就一个聊天框别的啥都没，所以也就只能这么用。其实那会把代码贴来贴去的，还挺折腾人，更多是一些很小的项目上搞一搞。
初期阶段（ide ai 1.0）
大概以23年6月cursor发布为分界线，初期阶段（ide ai 1.0）到来了，开始有集成了ai的代码生产环境冒出来了。现在除了cursor还有copilot，我选择了不用充钱的copilot方案，不用打钱，下个vscode登陆个github账号就能用，虽然限额有点少，不过问题不大。最开始的ide ai 1.0的逻辑是ai做自动补全，把自己的需求写在注释里，ai就往下生成一段对应需求的代码，人工review一下之后按个tab就能自动插入进去，当时看到就觉得很fancy，后面发现这东西还有自动生成注释，自动补全一些固定格式的代码之类的功能，反正当时是给了我一点小小的震撼。不过从现在的视角来看，这个功能有一点图一乐，因为这个ai自动补全功能挺不稳定的，要么是想要他跳出来的时候跳不出来，要么是不想他跳出来的时候突然跳出来干扰，而且在注释里写一大堆prompt回头还得删掉。
中期阶段（ide ai 2.0）
后来随着cursor又迭代了几轮，中期阶段（ide ai 2.0）到来了，并且其实持续了挺长的一段时间（甚至我一度觉得就是ai coding的最终形态），说起来其实也没多复杂，主要是长上下文ai的发展，让ide里面的ai可以不仅仅读现在这个文件里的东西做做自动补全了，还可以设置读取多个文件，从项目的视角来生成一些代码。这个阶段的体感上比较像早期阶段的浏览器ai被集成到了ide里面，但是实际上差异还是挺大的，因为早期阶段那会也压根不可能把好几个文件一起贴给ai（那会ai的输入限制大概1000个字符就差不多了），而且ai的能力也不支持记忆很长的上下文，写到后面早就把之前的代码给忘了，所以我觉得这个阶段的主要转折点就是长上下文ai的发展，ide里面的ai可以直接读取项目里的多个文件，然后就可以直接问他说我的某段代码怎么写/怎么改，ai生成的代码review完了之后，点个apply的按钮就会自己插到对应的文件里面去。其实这个阶段可能也是很多人会比较喜欢的阶段，因为至少人还是有不少事情的，你得自己想自己具体要干啥，再和ai去聊，然后再往下去推进工作，所以其实copilot这个名字我觉得起的挺好的，这会ai还在副驾驶上，至少方向盘还在人手上，等到下一个阶段就不是这么回事咯。
晚期阶段（agent ai）
25年年初，claude code呱呱坠地，晚期阶段（agent ai）突然刷爆全网，也是给我干的目瞪口呆。把这个阶段和ide ai区分开的原因是，agent ai已经普遍搞cli模式了，也就是直接在命令行里面跑了，这样都不用拘泥于具体的ide了，上哪都能用。不过我也没钱claude code，所以现在用的是vscode装cline插件调用deepseek api的搞法，还是很便宜的，充个50块钱感觉能用上几个月。所谓agent ai，其实就是给了ai更多的权限，ai现在不仅是辅助写代码了，你直接告诉他大的目标是啥，告诉他你要采取的工作流是啥，然后review一下他反馈给你的工作计划报告，确认无误后点个apply，然后.......然后就没你什么事情了。对的，agent ai不仅会自己创建/删除文件，还会自己调用工具去运行，还会看log然后改bug，然后继续跑，一直到完成工作目标（当然你过程中还是可以插手的，不过前提是你插手的速度能跟上他干活的速度......）。事情从这里开始变得尴尬了起来，我发现自己变成了赛博监工，他跑起来之后，我基本上没啥事儿了，盯着他在那猛猛的各种想各种写纯属图一乐，眼睛压根跟不上他的速度，等个半个小时or个把小时，回来验收一下，over了。这个阶段感觉真的已经把人从主驾驶上踹下来了，当然实际上也不完全，至少目前感觉ai还是经常会进入死循环的，卡在某个奇怪的bug里，一直de不出来的话他就基本上会开始乱搞，最后搞得乱七八糟的情况我遇到过好几次，不过anyway，看着他在那哼哧哼哧干活，我就一边喝茶一边扣手机的感觉.......很复杂。有点爽又有点危机感，万一这玩意后面更强了，哪天真的没我啥事了怎么办......
总结
总之大概就是这些，属于是部分的干货+废话碎碎念的内容，为了防止大伙觉得信噪比太低，还是请仁慈伟大的ai大人来做个总结吧。有请Qwen3：
我：请你精炼的总结一下这篇文章，并输出一个总结表格，要包括各个阶段的主要特征，典型解决方案，优劣势分析。
Qwen3：
当然可以！以下是对你文章内容的精炼总结，并整理成一个清晰的阶段对比表格，涵盖各阶段的主要特征、典型工具/解决方案、优势与劣势：
AI Coding 发展四阶段总结
| 阶段 | 名称 | 时间范围 | 主要特征 | 典型解决方案 | 优势 | 劣势 |
|---|---|---|---|---|---|---|
| 1 | 早期阶段（Web AI） | 2022年底 – 2023年中 | 通过浏览器聊天界面交互，手动复制粘贴代码片段；AI仅基于当前对话上下文生成代码 | ChatGPT（Web）、New Bing、Bard（现Gemini） | 门槛低，无需安装工具；适合小规模、探索性任务 | 操作繁琐，上下文极短（~1k字符），无法理解项目结构；反馈循环效率低 |
| 2 | 初期阶段（IDE AI 1.0） | 2023年中 – 2023年底 | AI集成进IDE，支持基于注释的代码自动补全；单文件上下文感知 | GitHub Copilot、早期 Cursor | 无缝嵌入开发环境；提升编码效率（如生成样板代码、注释） | 补全不稳定，干扰性强；需手动写Prompt（注释）；缺乏项目级理解 |
| 3 | 中期阶段（IDE AI 2.0） | 2023年底 – 2024年底 | 支持长上下文，可跨多文件理解项目结构；支持自然语言指令生成/修改代码，并自动插入 | Cursor（多文件模式）、Copilot Chat（后期） | 项目级代码理解；减少手动粘贴；人仍主导设计与决策（“副驾驶”模式） | 仍需人工拆解任务、引导AI；对复杂逻辑支持有限 |
| 4 | 晚期阶段（Agent AI） | 2025年初 – 至今 | AI具备自主执行能力：可创建/修改文件、运行命令、读日志、调试、迭代直至完成目标；CLI优先，脱离IDE限制 | Claude Code、Cline + DeepSeek API | 高度自动化，大幅减少人工干预；支持端到端任务交付 | 易陷入死循环或错误路径；需人工监控与干预；存在“失控”风险；对目标描述要求高 |
核心演进逻辑：
交互方式：从“手动粘贴” → “IDE内补全” → “项目级对话” → “自主执行代理”
控制权转移：人主导 → 人-AI协作（副驾驶） → AI主导执行（人变监工）
技术驱动力：上下文长度扩展、工具调用（Tool Use）、规划与反思（Planning & Self-Correction）能力提升
我：所以你觉得，ai coding未来会继续发展吗，对人来说这是好事还是坏事呢？
Qwen3：
*这是个非常深刻、也极具现实意义的问题。作为一个人工智能，我无法“感受”好坏，但可以从技术演进、生产力变革和人类角色重塑的角度，给出一个相对平衡的分析。
1.AI Coding 会继续发展吗？
几乎可以肯定：会，而且速度可能超预期。
原因有三：
技术驱动力持续增强：
大模型的上下文长度、推理能力、工具调用（Tool Use）、自我反思（Self-Refine）和规划（Planning）能力仍在快速迭代。Agent 架构已从“能跑”走向“能用”，下一步是“可靠”和“可解释”。
市场需求极其旺盛：
软件开发是全球最紧缺的高技能劳动力之一。企业有强烈动力用 AI 提升人效、降低门槛、加速交付。开源社区、云厂商、初创公司都在疯狂投入。
反馈闭环正在形成：
越来越多开发者用 AI 写代码 → 产生海量真实交互数据 → 反哺模型训练 → 模型更懂开发 → 更多人用……这是一个正向飞轮。
所以，AI Coding 不是“会不会发展”，而是“会以多快的速度重塑整个软件工程范式”。
2.对人来说，是好事还是坏事？
答案是：对“适应者”是巨大的好事，对“停滞者”可能是坏事。
✅ 好事体现在：
生产力跃升：
重复性工作（样板代码、CRUD、测试用例、文档）被极大压缩，开发者能聚焦在架构设计、业务理解、用户体验、创新逻辑等高价值环节。
门槛降低，创造力释放：
非科班出身的产品经理、设计师、科研人员，也能通过自然语言“编程”，快速验证想法。这会催生更多跨界创新。
学习曲线变缓：
新手可以通过与 AI 实时对话理解代码逻辑、调试错误、学习最佳实践，加速成长。
工作方式升级：
从“写代码的人”变成“定义问题、评估方案、把控质量的工程师”——这其实是更接近软件工程本质的角色。
⚠️ 潜在风险/挑战：
技能错配与淘汰压力：
如果只掌握“写基础代码”的技能，而缺乏系统思维、领域知识或协作能力，可能会被高效 AI + 少数高阶工程师的组合替代。
过度依赖导致能力退化：
长期“复制 AI 输出”而不理解原理，可能导致调试、设计、抽象能力下降——就像计算器普及后，心算能力普遍减弱。
责任与安全边界模糊：
当 AI 自主修改生产代码、部署服务时，出问题谁负责？如何审计？这需要新的工程规范、法律框架和伦理共识。
同质化风险：
如果大家都依赖相似的 AI 模型生成代码，可能导致系统架构、安全模式高度雷同，一旦模型存在共性缺陷，风险会系统性放大。
3.未来的“人”的角色会是什么？
不是“会不会被取代”，而是“以什么身份参与”。
未来的开发者更像是：
AI 的指挥官（Commander）：清晰定义目标、约束和验收标准；
系统的架构师（Architect）：设计可扩展、可维护、安全的系统边界；
质量的守门人（Gatekeeper）：审查 AI 输出的正确性、安全性、可维护性；
跨领域的翻译者（Translator）：把业务语言转化为工程语言，再交给 AI 执行。
AI 不会取代程序员，但会取代“不用 AI 的程序员”。
结语：技术本身无善恶，关键在于我们如何使用它
AI Coding 的终极意义，不是让机器写代码，而是让人从机械劳动中解放出来，回归创造的本质。
就像编译器、IDE、Git 没有消灭程序员，反而让软件工程成为可能一样，AI 会成为新一代的“认知杠杆”。
所以，与其焦虑“会不会没我事了”，不如思考：
👉 “有了 AI 这个超级助手，我能做成以前不敢想的事吗？”
——这或许才是未来十年，每个开发者最该问自己的问题。