1. 校招入职第一周，我发现隔壁工位的效率是我的三倍
刚入职那会儿，我还在用最原始的方式写代码：打开 IDE，翻文档，搜 Stack Overflow，复制粘贴，改改改，跑测试，报错，再搜。一天下来能提交两三个像样的 commit 就算不错了。直到有次我卡在一个跨模块的接口联调上，隔壁工位的同事看了一眼，说“你等我两分钟”，然后打开一个终端窗口，敲了几行命令，一个完整的接口适配层代码就生成出来了，连单元测试都带上了。我当时的第一反应是：这玩意儿靠谱吗？第二反应是：我得学。
后来我才知道，他用的就是Coding Agent这一类工具，把 AI 接入了从需求理解到代码提交的完整开发流程。注意，我说的是“完整开发流程”，不是“让 AI 帮我写个函数”这种碎片化用法。这两者之间的差距，大概相当于“用计算器算个加法”和“用 Excel 建一套财务模型”的差距。
这篇内容我想聊的，就是我作为一个校招生，怎么一步步把 AI Coding 嵌入到日常开发流程里的。不是那种“打开 ChatGPT 问一句”的入门玩法，而是从环境搭建、工具选型、工作流设计到踩坑排查的完整经验。如果你也是刚入行不久，或者正在琢磨怎么让 AI 真正帮上忙而不是添乱，那接下来的内容应该对你有用。
先说一下我的基本盘：后端方向，主力语言是 Python 和 Go，日常用 VS Code 和 JetBrains 系 IDE，团队用 GitLab 做代码托管，CI/CD 走的是标准流水线。在这个背景下，我尝试过市面上主流的几种 AI Coding 方案，最终沉淀出了一套自己用着比较顺的工作流。
2. 为什么大多数人用 AI 写代码，效果差得离谱
2.1 把 AI 当搜索引擎用，是最常见的浪费
我观察过身边不少同事用 AI 的方式：遇到报错，把错误信息复制到对话框里，问“这个怎么解决”；要写个函数，描述一下需求，让 AI 生成一段代码，然后复制到 IDE 里。这种用法不能说没用，但效率提升非常有限，因为你在做的事情本质上还是“搜索 + 复制粘贴”，只不过搜索源从 Google 换成了 AI。
真正的问题在于：AI 没有拿到足够的上下文。你给它的信息只有一段错误信息或者一句需求描述，它不知道你的项目结构、依赖版本、代码风格、已有工具函数、数据库 schema。在这种情况下，它生成的代码大概率需要你大幅修改，甚至完全重写。你花在修改上的时间，可能比自己从头写还多。
2.2 上下文缺失导致的三类典型翻车
我踩过的坑大概可以归为三类。
第一类是依赖版本不匹配。比如我让 AI 写一个 FastAPI 的接口，它用了某个新版本才有的语法，但我们项目锁定的版本比较旧，跑起来直接报错。AI 不知道你的requirements.txt里写的是什么版本，它只会按自己训练数据里最常见的写法来生成。
第二类是项目约定被忽略。每个团队都有自己的代码规范：命名习惯、目录结构、错误处理方式、日志格式。AI 生成的新代码如果不符合这些约定，code review 的时候会被打回来，你还得重新改。更麻烦的是，如果 AI 生成的代码和项目里已有的工具函数功能重复，就会造成代码冗余。
第三类是隐式依赖被遗漏。比如你让 AI 写一个数据库查询，它写了 SQL 语句，但忘了加连接池管理、忘了处理事务、忘了加索引提示。这些隐式依赖在简单场景下可能不出问题，一旦上量就会暴露。
2.3 正确的思路：让 AI 先“读懂”项目，再动手写
后来我调整了思路：与其让 AI 凭空生成代码，不如先让它理解项目。具体来说，就是把我正在处理的文件、相关的模块、依赖配置、甚至最近的 commit 记录都作为上下文提供给 AI，让它在这个基础上做增量修改。这样生成的代码，风格一致、依赖匹配、约定符合，基本可以直接用。
这个思路的转变，是我整个 AI Coding 工作流的核心。后面要讲的所有工具选型和操作细节，都是围绕这个思路展开的。
3. 工具选型：IDE 插件、CLI Agent 和 Chat 界面该怎么分工
3.1 三类工具的定位差异
市面上的 AI Coding 工具大概可以分成三类：IDE 插件、CLI Agent、独立 Chat 界面。这三类工具不是互相替代的关系，而是各有各的适用场景。
IDE 插件（比如 VS Code 里的 Copilot、Codeium 等）的优势是集成度高，补全和行内建议非常流畅，适合写代码时的实时辅助。但它的上下文窗口通常有限，很难拿到整个项目的全貌。
CLI Agent（比如 Codex CLI 这类工具）的优势是上下文管理能力强，可以读取项目文件、执行命令、查看 git 状态，适合处理跨文件的修改任务。缺点是交互方式偏命令行，上手有一定门槛。
独立 Chat 界面（网页版或桌面版）的优势是灵活，可以贴大段代码、讨论方案、做技术调研。缺点是脱离 IDE 环境，复制粘贴成本高。
3.2 我的分工方案
我目前的分工是这样的：
- 写新功能时：用 IDE 插件的行内补全，快速生成样板代码和重复性逻辑。
- 改现有代码时：用 CLI Agent，让它先读取相关文件，理解上下文后再做修改。
- 做技术调研和方案设计时：用 Chat 界面，贴相关代码片段，讨论几种实现方案的优劣。
- 排查复杂 bug 时：先用 CLI Agent 读取报错文件和调用链，让它给出排查思路，再结合自己的判断定位问题。
这个分工不是固定的，会根据任务复杂度动态调整。但核心原则是：让工具做它擅长的事，不要用一种工具硬扛所有场景。
3.3 环境准备中最容易忽略的几个细节
不管你选哪类工具，环境准备阶段有几个细节特别容易忽略，但会直接影响使用体验。
第一个是项目根目录的标识文件。很多 CLI Agent 需要你明确告诉它项目根目录在哪里，通常是通过一个配置文件或者启动参数。如果你在子目录里启动，它可能读不到完整的项目结构。
第二个是忽略文件的配置。项目里通常有大量不需要 AI 读取的文件，比如node_modules、venv、构建产物、日志文件。如果不配置忽略规则，AI 可能会把这些文件也纳入上下文，浪费 token 不说，还可能干扰判断。
第三个是网络和认证配置。部分工具需要登录账号或者配置 API key，如果网络环境有特殊要求，需要提前处理好。我遇到过好几次因为认证过期导致工具突然不可用的情况，排查了半天才发现是登录状态失效了。
第四个是IDE 与 CLI 的版本兼容性。有些 CLI Agent 需要特定版本的 IDE 或者运行时环境，版本不匹配会出现各种奇怪的问题。建议在安装前先确认版本要求。
4. 我的完整工作流：从接到需求到提交 MR
4.1 需求理解阶段：让 AI 帮你拆任务
接到一个需求后，我不会直接开始写代码。第一步是让 AI 帮我拆解任务。具体做法是：把需求文档（或者 Jira ticket 的描述）贴给 Chat 界面，让它帮我列出需要改动的模块、可能涉及的接口、需要新增的数据结构、以及潜在的边界情况。
这一步的价值在于：AI 可以帮你发现你没想到的角落。比如一个看似简单的“增加导出功能”的需求，AI 会提醒你考虑权限控制、大数据量下的分页、导出格式的兼容性、失败重试机制等等。这些点你自己想可能要花半小时，AI 几秒钟就能列出来。
当然，AI 列出来的东西不一定都对，你需要自己判断哪些是真正相关的。但作为一个 checklist 来用，效果很好。
4.2 代码定位阶段：用 CLI Agent 快速找到改动点
需求拆解完之后，下一步是找到具体的改动点。传统做法是一个个文件翻，或者用全局搜索找关键词。用 CLI Agent 的话，你可以直接问它：“这个项目里处理用户认证的逻辑在哪个文件？”它会读取项目结构，找到相关文件并告诉你路径。
更进一步，你可以让它读取某个文件，然后问：“如果我要在这里增加一个字段校验，需要改哪些地方？”它会分析调用链，列出所有需要同步修改的位置。这个能力在大型项目里特别有用，因为人脑很难记住所有调用关系。
我实测下来，这一步能节省大概 60% 到 70% 的代码定位时间。尤其是接手别人写的模块时，效果更明显。
4.3 编码阶段：让 AI 在完整上下文里做增量修改
这是整个工作流的核心环节。我的做法是：用 CLI Agent 打开目标文件，把相关的依赖文件也加入上下文，然后给出具体的修改指令。
举个例子：我要给一个 API 接口增加一个查询参数。我会这样做：
# 启动 CLI Agent，指定项目根目录 codex --project /path/to/project # 在交互界面里，先让它读取相关文件 > read src/api/user_handler.py > read src/models/user.py > read src/schemas/user_schema.py # 然后给出修改指令 > 在 user_handler.py 的 get_user_list 函数中增加一个 status 查询参数， 类型为可选字符串，默认值为 None。当 status 不为 None 时， 在数据库查询中增加过滤条件。同时更新 user_schema.py 中的请求模型。这样操作的好处是：AI 在生成代码时，已经知道了user_handler.py的现有结构、user.py里的模型定义、user_schema.py里的校验规则。它生成的代码会自然地融入现有代码风格，不会出现命名不一致或者依赖缺失的问题。
4.4 测试阶段：让 AI 生成测试用例并执行
代码改完之后，我会让 AI 生成对应的单元测试。指令大概是这样的：
> 为刚才修改的 get_user_list 函数生成单元测试， 覆盖 status 为 None、status 为有效值、status 为无效值三种情况。 使用项目现有的测试框架和 mock 方式。AI 会读取项目里已有的测试文件，学习测试风格和 mock 方式，然后生成匹配的测试代码。生成之后，我会让它在终端里执行测试命令，确认全部通过。
如果测试失败，我会把失败信息贴回给 AI，让它分析原因并给出修复建议。这个迭代过程通常很快，两三轮就能搞定。
4.5 提交阶段：让 AI 帮你写 commit message 和 MR 描述
最后一步是提交代码。我会让 AI 根据本次改动的 diff 生成 commit message 和 MR 描述。指令很简单：
> 根据当前 git diff 生成 commit message，遵循项目的 commit 规范。 > 同时生成 MR 描述，包括改动背景、改动内容、测试情况。AI 会读取git diff的输出，结合项目里已有的 commit 记录风格，生成符合规范的提交信息。这一步虽然看起来不起眼，但实际能省不少时间，尤其是当你一天要提交好几次的时候。
5. 踩坑实录：那些让我抓狂的报错和排查过程
5.1 配置文件解析失败：一个拼写错误排查了半小时
有一次我启动 CLI Agent 的时候，它报了一个错：
codex is ignoring 1 unrecognized configuration setting. check for typos or d...错误信息被截断了，只显示到 “or d”。我第一反应是配置文件里某个字段拼错了，但打开配置文件看了半天没发现明显问题。后来我把错误信息完整输出，才发现是model_provider字段写成了model_provder，少了一个i。
这个坑的教训是：配置文件里的字段名一定要仔细核对。AI 工具通常对配置字段的拼写很敏感，一个字母错了就会导致整个配置被忽略。建议配置完之后，用工具的校验命令检查一遍，或者直接看启动日志里有没有 warning。
5.2 模型不支持报错：版本匹配比想象中重要
还有一次，我配置了一个模型名称，启动后报错：
the 'gpt-5.6-sol' model is not supported when using codex with a...这个错误的原因是：我使用的 CLI Agent 版本和模型版本不匹配。工具本身支持这个模型，但当前版本还不支持，需要升级工具或者换一个模型。
这类问题的排查思路是：先确认工具版本，再确认模型名称，然后查官方文档看两者的兼容性矩阵。如果文档里没写，就升级到最新版本试试。我后来养成了一个习惯：每次配置新模型之前，先查一下当前工具版本的支持列表。
5.3 连接中断与重连：网络稳定性对工作流的影响
使用 CLI Agent 的过程中，我遇到过几次“正在重新连接”的提示。这种情况通常是因为网络波动导致连接中断，工具会自动尝试重连。大部分时候几秒钟就恢复了，但偶尔会卡住不动。
我的应对策略是：如果重连超过 30 秒还没恢复，就手动中断当前操作，检查网络连接，然后重新启动会话。另外，我会把重要的上下文信息（比如正在处理的文件列表和修改指令）保存在一个临时文件里，这样即使会话中断，重新启动后也能快速恢复工作状态。
5.4 登录状态失效：最容易被忽略的坑
有一次我正用得好好的，突然所有请求都返回认证失败。排查了半天才发现是登录 token 过期了。这类问题通常不会有明显的错误提示，只是工具突然不工作了。
我的做法是：把登录状态检查加入日常启动流程。每次开始工作前，先跑一个简单的测试命令，确认工具能正常响应。如果失败，就先处理认证问题，不要等到写到一半才发现工具用不了。
6. 让 AI 真正融入日常开发，而不是成为负担
6.1 建立自己的提示词模板库
用了一段时间之后，我发现很多操作是重复的：读取文件、生成测试、写 commit message、排查报错。每次都要重新组织语言很浪费时间。于是我开始建立自己的提示词模板库，把常用指令保存成文本片段，需要的时候直接调用。
比如我的模板库里有一条是“生成单元测试”：
读取 {file_path} 中的 {function_name} 函数， 参考 {test_file_path} 中的测试风格， 为 {function_name} 生成单元测试， 覆盖以下场景：{scenarios}。 使用项目现有的 mock 方式，不要引入新的测试依赖。用的时候只需要替换花括号里的内容就行。这个习惯让我每次操作能省下几十秒，一天下来就是十几分钟。
6.2 定期回顾 AI 生成的代码，建立自己的判断标准
AI 生成的代码不能无脑接受。我养成了一个习惯：每次 AI 生成代码后，先快速扫一遍，重点看几个地方：
- 边界条件处理：有没有考虑空值、越界、并发等情况。
- 错误处理：异常捕获是否合理，日志是否充分。
- 性能隐患：有没有 N+1 查询、不必要的循环、内存泄漏风险。
- 安全风险：有没有 SQL 注入、XSS、权限绕过等问题。
这个检查过程一开始比较慢，但做多了之后会形成直觉，几秒钟就能判断出代码能不能用。而且这个过程本身也在提升自己的代码审查能力。
6.3 把 AI 当成结对伙伴，而不是代码生成器
最后想说的是心态问题。我见过两种极端：一种是把 AI 当万能工具，什么都让它做，结果代码质量一塌糊涂；另一种是完全不信任 AI，觉得它写的代码不能用，宁愿自己从头写。
我的经验是：把 AI 当成一个知识面很广但经验不足的结对伙伴。它知道很多你不知道的 API 和写法，但它不了解你的项目细节和业务逻辑。你需要做的是：给它足够的上下文，让它发挥知识优势；同时保持审查习惯，用你的经验弥补它的不足。
这个定位一旦建立起来，你会发现工作效率的提升是实实在在的。我现在处理一个中等复杂度的需求，从理解到提交 MR，大概只需要以前一半的时间。省下来的时间可以用来做更有价值的事情：优化架构、写文档、学习新技术。
6.4 持续迭代自己的工作流
AI Coding 这个领域变化很快，工具在更新，模型在迭代，最佳实践也在不断演进。我每个月会花一两个小时回顾一下自己的工作流，看看有没有可以优化的地方：有没有新的工具值得尝试？现有的提示词模板能不能改进？哪些环节还是太慢？
这个习惯让我始终保持在一个比较高效的状态。毕竟，工具是死的，人是活的。真正决定效率的，不是你用哪个工具，而是你怎么用这些工具。
