我最开始只是从 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 AgentAGENTS.mdRuleSkillMCP多 AgentGit WorktreeContext EngineeringAgent 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 **