我最开始只是从 GPT 网页复制代码
我第一次真正把 AI 用到写代码里，并不是 Codex，也不是现在常见的 Coding Agent。
那时候的流程很简单：
遇到问题，打开 ChatGPT。
把代码复制进去，把报错复制进去，再补上一句：
这段代码为什么有问题？
或者：
帮我实现一下这个功能。
GPT 给出一段代码，我再复制回 IDE。
运行。
如果报错，就把新的报错继续贴回 GPT。
于是，一个最早期的 AI Coding 工作流就形成了：
代码 / 报错 ↓ 复制到 ChatGPT ↓ 生成答案 ↓ 复制回 IDE ↓ 运行 ↓ 继续报错 ↓ 再复制给 ChatGPT现在回头看，这种方式甚至有些原始。
但对当时的我来说，它已经极大地改变了写代码的方式。
1. 一开始，我只是把 GPT 当成更强的搜索引擎
过去遇到一个陌生 API，通常是这样的：
搜索关键词 ↓ Stack Overflow ↓ 官方文档 ↓ 博客 ↓ Github Issue ↓ 不断筛选答案有了 GPT 之后，这个过程突然被压缩了。
比如我忘记某个 JavaScript API 的用法，不再需要在多个网页之间跳转，只需要直接问：
Array.prototype.reduce 怎么用？遇到报错，也可以直接把报错贴进去：
Cannot read properties of undefined甚至可以把一整段代码丢进去，让它帮我解释。
这种体验第一次让我感觉：
获取技术信息的方式发生了变化。
以前是：
我去互联网中寻找答案。
后来变成：
我直接描述问题，让模型帮我组织答案。
但那个阶段，我其实还没有把它理解成今天所说的 AI Coding。
它更像是：
一个可以对话的 Stack Overflow。
2. 后来，我开始让 GPT 直接写代码
很快，我发现只让 GPT “回答问题”有些浪费。
既然它知道怎么实现，为什么不直接让它写？
于是我的问题开始从：
这个 API 怎么用？变成：
帮我写一个防抖函数。再变成：
这是我现在的 React 组件， 帮我增加一个搜索功能。再后来甚至会直接把一大段业务代码复制过去：
这是现在的实现。 需求是 XXX。 帮我修改。这个阶段，AI 给我的感觉已经不只是“搜索工具”。
它开始成为一个代码生成器。
尤其是在一些边界明确的问题上，它非常好用：
- 写一个工具函数
- 补一段类型声明
- 写一个简单组件
- 解释一段陌生代码
- 根据报错分析可能原因
- 生成 Demo
- 提供一个实现思路
很多过去需要搜索十几分钟甚至更久的问题，几分钟就可以得到一个可运行的版本。
这是我第一次真正体会到 AI 对开发效率的提升。
3. 但问题也很快出现了
用得越多，我越发现一个问题：
GPT 很会写代码，但它并不知道我正在开发什么。
例如我问：
帮我给这个组件增加一个 loading 状态。它可能会给出一个完全正确的 React 实现。
但真实项目可能使用的是：
MobX而不是：
useState项目里可能已经有统一的 Loading 组件。
可能已经存在一个公共 Store。
可能有自己的请求封装。
可能有 ESLint 规范。
可能有历史兼容逻辑。
甚至这个组件真正的状态来源，根本不在当前文件里。
这些信息 GPT 都不知道。
于是我开始不断补充上下文：
我们项目使用 MobX。 这个状态是在父组件维护的。 请求函数在这里。 这是相关类型定义。 这是另一个类似组件的实现。 这是报错。 这是调用链。然后新的问题来了：
我要复制的东西越来越多。
4. 我逐渐变成了 GPT 和代码仓库之间的“接口”
那段时间我的工作方式经常是这样的。
先从 IDE 里复制：
A.tsx贴给 GPT。
它发现缺少一个函数。
于是我再找到：
utils.ts复制过去。
它又发现一个类型不知道。
我继续复制：
types.ts然后它给出修改方案。
我再把代码复制回 IDE。
运行以后出现新的错误。
再复制错误信息。
再复制相关代码。
整个过程实际上变成了：
Codebase ↓ 我 ↓ ChatGPT ↓ 我 ↓ Codebase现在回头看，我当时其实承担了一个很有意思的角色：
我就是 GPT 和代码仓库之间的 API。
AI 无法直接读取我的工程。
所以我负责把工程上下文传给它。
AI 无法直接修改代码。
所以我负责把结果复制回来。
AI 无法自己运行程序。
所以我负责执行。
AI 看不到报错。
所以我再负责把报错告诉它。
整个闭环里，大量工作并不是在“写代码”，而是在：
搬运上下文。
5. 这也是我第一次意识到：模型能力不是唯一的问题
最开始使用 AI 时，我经常把结果不好归结为：
GPT 还不够聪明。
但后来我逐渐发现，很多时候问题并不是模型不会写。
而是：
它根本没有足够的信息。
假设我要让一个开发者修改一个陌生项目。
但我只给他一个文件，然后告诉他：
把这个需求做了。
他同样很难做好。
因为真正的软件工程任务依赖大量上下文：
需求 + 代码结构 + 依赖关系 + 项目规范 + 历史实现 + 运行环境 + 测试结果 + 业务约束而我最开始给 GPT 的，可能只有：
一个代码片段 + 一句需求描述这两者之间存在巨大的信息差。
于是我开始慢慢意识到：
AI Coding 的关键，不只是让 AI 更会写代码，而是让 AI 获得足够的工程上下文。
这也是后来我开始关注各种 Coding Agent 的原因。
6. 从“复制代码”到“进入工程”
如果把那时候的使用方式画出来，大概是：
IDE ↑ 复制 ↓ 人 ↑ 复制 ↓ GPT 网页AI 和工程之间其实没有直接连接。
所有信息都要经过人。
后来 IDE 内的 AI 工具开始解决一部分问题：
AI ↓ 当前文件 ↓ 相关文件 ↓ 代码仓库再后来，Coding Agent 开始可以：
读取代码 ↓ 搜索仓库 ↓ 修改文件 ↓ 执行命令 ↓ 运行测试 ↓ 根据结果继续修改这个变化在我看来非常关键。
以前：
AI 给我代码。
现在：
AI 开始直接操作工程。
这两者看起来只差了一步，但实际是完全不同的交互范式。
7. 人的角色也开始变化
最早使用 GPT 时，我负责很多机械工作：
找代码 复制代码 描述上下文 粘贴答案 执行命令 复制报错随着工具能力越来越完整，这些事情开始逐渐被 Agent 接管。
人的职责则开始向另一边移动：
定义问题 ↓ 提供约束 ↓ 设计方案 ↓ 判断结果 ↓ Code Review ↓ 风险控制也就是说：
人逐渐从“上下文搬运者”，变成了“任务定义者和结果审核者”。
这也是我目前理解 AI Coding 非常重要的一条变化。
8. 为什么我要重新记录这段过程
现在我已经开始使用 Codex，也开始研究：
- Coding Agent
- AGENTS.md
- Rule
- Skill
- MCP
- 多 Agent
- Git Worktree
- Context Engineering
- Agent Evaluation
但如果直接从这些东西开始记录，很容易产生一种错觉：
好像 AI Coding 天生就应该是现在这样。
实际上不是。
至少对我来说，它是一步一步演进过来的。
我的起点并不是什么复杂的 Agent Workflow。
只是：
打开 GPT 网页。 复制代码进去。 再把生成的代码复制出来。所以我想把这段过程完整记录下来。
一方面记录自己作为一个校招生，在 AI 快速发展的几年里，开发方式到底发生了什么变化。
另一方面也想借这个过程重新理解一个问题：
AI 到底是怎么一步一步进入软件工程的？
写在最后
如果一定要给我最早的 AI Coding 阶段做一个总结，我会写成：
第一阶段： AI 会写代码， 但 AI 不在工程里。所以那个阶段真正连接 AI 和工程的人，是开发者自己。
而后面所有 Coding Agent、Context、Skill、MCP 甚至 Multi-Agent 的演进，本质上都在不断解决同一个问题：
怎样让 AI 更深入地理解并参与一个真实的软件工程。
这也是这个 AI Coding 系列接下来想记录的事情。
AI 开始进入 IDE
这一阶段本质上不是工具的变化，而是context的变化。
从：
“这是我的代码: xxx，帮我改”变成了：
AI 自己读取当前文件 AI 搜索相关代码 AI 理解调用关系AI已经可以直接进入我们的项目、开发环境，自己分析依赖关系、指定方案、修改代码、执行测试、验证效果。
做开发者的我们都知道，代码其实只是开发的一部分，有时候最让我们头疼的其实是环境、依赖，这时候AI已经很好的解决了这部分问题，这也是后续好多开发者提出大仓概念的原因，包括很多大厂的业务结构调整，归根结底其实可以说是这时候AI coding的性质的改变，当然这都是后话了。
AI coding的演化其实我觉得也都是围绕着context的展开。
这时候AI终于和真实的工程连接起来
于是我的工作流发生了顺理成章的改变：
我提供 Context ↓ AI 处理 逐渐变成： 我描述问题 ↓ AI 主动寻找 Context ↓ AI 分析问题我逐渐意识到，决定效果不仅仅是模型能力，并不是模型足够强大就能解决一切问题，context也是非常重要的变量。这也启示我们：
** 要学会维护自己专属的知识库** （这里我做了一定的探索 有时间分享给大家）
还是举个简单例子：
给我加个埋点
之前的web问答式由于上下文不够，会给出自己觉得最优的方案。
但是我们知道：
** 局部最优不一定全局最优**
他不知道的是，也许我们的项目中引用了封装的sdk，也许我们有固定的工具包？所以正确的代码放到工程里可能是错误的。
因为工程会有项目规范、会有模块之间的调用链、会有架构设计…
这时候我们把我们的认知工作，一部分外包给了AI。
为什么说外包给了一部分给AI，因为整体流程还是我们人为控制的。
但是这时候依然存在一定的边界能力，只是看到工程，并不代表可以完成任务！
AI 开始操作IDE
这时候的变化其实是顺水推舟，AI理论上可以拿到整个环境，人为的反馈反而是降低效率，并且几乎没有意义的重复工作，我反复反馈结果，点击run，确定的东西是AI最拿手的，也是他最应该去做的，让人力从重复的机械行为解放出来。
于是新的阶段诞生了：
目标 ↓ 读取代码 ↓ 寻找上下文 ↓ 做出修改 ↓ 执行命令 ↓ 观察结果 ↓ 继续调整他从辅助代码，进化到了完成任务。
但是这个时候，好多时候还是需要我们介入，应用修改。
接下来我们聊** IDE Assistant 到 Coding Agent **
