前言
4月28日，公司组织了一场AI培训分享会。说实话，最近我也在用AI Agent工具——腾讯的Code Buddy，所以这场培训对我来说既是学习，也是一种”验证”：看看其他同事都是怎么用AI的，有没有我没想到的角度。
结果还真学到了不少新思路。
一、公司AI培训：同事们的新思路
培训中，几位同事分享了他们的AI使用经验，有几个观点让我印象深刻：
1. 双Agent协作模式
有同事提出使用两个Agent协作的开发模式：
- Agent A：负责代码修改和实现
- Agent B：负责代码审查和验证
这个思路很有意思。以往我用AI，都是”我提需求 → AI改代码 → 我检查”，现在可以考虑让AI自己扮演”审查者”角色，改完之后让另一个Agent去review，相当于AI之间的互相监督。
思考：这种模式特别适合需要高可靠性的场景，比如支付、权限相关的代码修改。
2. 压缩上下文（Context Compression）
另一位同事提到了上下文压缩的概念。
用AI Agent的时候，对话越长，上下文越大，响应越慢，成本越高。所以要学会”压缩上下文”：
- 把已经确定的需求整理成文档，而不是每次都重新描述
- 把改好的代码提交后，开启新对话，避免历史上下文干扰
- 用简洁的语言描述问题，避免冗余信息
这个点我之前确实没太注意。我有时候会在一个对话里聊很久，结果后面AI的响应越来越慢，现在想想，可能就是上下文太大的原因。
3. 改完代码让AI优化
这个点是最让我意外的：改完功能代码后，再让AI优化代码。
我之前的习惯是：AI改完代码 → 我检查一下逻辑对不对 → 打包发布。但同事提出的流程是：
- AI实现功能
- 人检查逻辑
- AI优化代码（性能、可读性、最佳实践）
- 人再次检查
- 发布
第3步是我完全没想到的角度。我一直把AI当成”实现工具”，没想到还可以让它当”优化工具”。
例子：AI写了一个能跑的函数，但可能命名不规范、有重复代码、性能不是最优。这时候让AI”优化一下这段代码”，往往能得到更干净的代码。
二、我的Code Buddy使用经验
说回我自己的使用经验。公司暂时没有统一购买AI工具，我自己则在试用腾讯的Code Buddy。
Code Buddy有三个模式：
1. Craft模式：简单问题的快速解决方案
对于简单的问题，我都是直接用Craft模式。
比如：
- “帮我写一个Python脚本，读取CSV文件并统计每列的平均值”
- “这段代码的bug在哪里？”
- “帮我格式化这个JSON”
Craft模式的特点是：直接动手改，不需要太多讨论，适合明确、简单的问题。
2. Plan模式：复杂需求和Bug的慎重处理
对于复杂需求或者棘手的Bug，我会用Plan模式。
Plan模式的工作流程是：
- AI先分析需求，提出几个可能的方案
- 我和AI讨论细节（比如技术选型、边界情况、性能考虑）
- 确定方案后，AI再开始实现
这样做的好处是：避免方向性错误。有时候我以为我要的是A，但和AI讨论完发现，其实B方案更合适。
实际案例：有一次我遇到一个Bug，表象是”接口偶尔返回500”。如果用Craft模式，AI可能会直接去改异常处理。但用Plan模式讨论后，发现根本原因是”数据库连接池配置不合理”，改的方向完全不同。
3. Ask模式：纯咨询，不改动代码
Ask模式我用得相对少一些，主要用于：
- “这个错误信息的意思是什么？”
- “XX技术的原理是什么？”
- “有没有更好的做法？”
就是不让我改代码，只是问问题、要建议。
三、Token管理与成本优化策略
自己使用AI Agent，还要注意Token消耗和成本控制问题。这部分是公司培训没提到，但我自己实践中总结出来的经验。
1. 不相关的问题，开多个窗口
用AI Agent的时候，我发现一个容易忽略的成本陷阱：上下文累积。
如果你在一个对话里聊了很久，即使后面问的是完全不相关的问题，AI还是会”读取”前面的所有内容（作为上下文）。这就意味着：
- Token消耗增加（前面所有的对话都要算钱）
- 响应速度变慢（上下文越长，处理越慢）
- 可能干扰AI的判断（旧信息可能误导新问题的处理）
我的做法：不相关的问题，开新的对话窗口。
比如：
- 窗口A：聊PHP环境配置的问题
- 窗口B：聊前端Next.js的Bug
- 窗口C：聊数据库优化
这样每个窗口的上下文都是”纯净”的，不会互相干扰，也不会浪费Token。
实际案例：有一次我在同一个窗口里，先让AI帮我配置PHP环境（聊了20轮），然后突然问它”帮我写一个Python爬虫”。结果AI的回复很慢，而且返回的内容里还提到了”PHP环境”（明显受到了前面上下文的干扰）。后来我开了新窗口重新问，速度快多了，回答也更精准。
2. 简单问题优先用便宜的模型，搞不定再切换贵的
Code Buddy支持选择不同的AI模型，有些模型便宜但能力弱，有些模型贵但能力强。
我的策略：简单问题先用便宜的模型，如果搞不定，再切换到更贵的模型。
比如：
- 简单问题（代码格式化、简单Bug修复、文档查询）→ 用便宜的模型
- 复杂问题（架构设计、复杂Bug排查、性能优化）→ 用贵的模型
这样做的好处是：
- 大部分简单问题，便宜模型就能搞定，省成本
- 只有真正需要的时候，才用贵模型，把钱花在刀刃上
例子：有一次我想让AI”帮我格式化这段JSON”。用了最便宜的模型，结果格式化后的JSON有语法错误（引号没转义）。于是我切换到更贵的模型，重新问了一遍，这次就对了。虽然多花了点钱，但总比一开始就用贵模型要划算。
3. 及时”总结”上下文，避免重复描述
这也是从”上下文压缩”延伸出来的技巧。
如果你在一个对话里聊了很久，积累了很多信息（比如需求背景、代码逻辑、Bug现象），可以考虑让AI帮你总结一下当前状态，然后把总结复制到新窗口继续聊。
这样做的好处：
- 新窗口的上下文很短（只有总结），Token消耗少
- AI能快速理解当前状态，不需要重新读前面的长对话
我的做法：
- 在旧窗口里问AI：”帮我总结一下当前的问题和进展”
- AI给出总结（通常几句话）
- 复制总结，开新窗口，把总结贴进去，继续聊
四、AI辅助开发环境配置：从”反复发布验证”到”本地快速迭代”
这部分是我自己摸索出来的用法，感觉其他同事提得不多：用AI帮忙配置开发环境。
痛点：PHP项目本地启动难
我之前主要做Java开发，对PHP不太熟悉。公司有一个PHP项目，本地一直启动不起来。
以前的流程是：
- 改代码
- 打包
- 发布到测试环境
- 测试
- 有问题，回到第1步
这个流程的问题很明显：反馈周期太长。改一行代码，要等打包、发布、部署，可能十几分钟就过去了。而且PHP的报错信息我不太懂，经常改了好多次都跑不起来。
AI解救：让Agent配置本地环境
后来我试着让Code Buddy帮我配置本地开发环境。
我的做法是：
- 把报错信息（包括堆栈、日志）扔给AI
- AI分析后，给出修改建议（比如php.ini配置、扩展安装、环境变量）
- 我按AI说的改，再把新的报错扔给它
- 反复几次，环境就跑起来了
现在这个PHP项目，我可以在本地启动了。开发流程变成了：
- 改代码
- 本地刷新浏览器，立即看到效果
- 有问题，立即改，立即验证
- 确认没问题，再打包发布
效率提升是质的飞跃。以前一天可能只能验证3-5次，现在一小时就能验证十几二十次。
不仅是PHP：其他环境的配置
这个思路其实不限于PHP。后来我用同样的方法，配置了：
- Node.js版本管理（nvm）
- 数据库本地连接
- Docker开发环境
核心思路是：让AI当”环境配置助手”，而不是自己去查文档、试错。
五、前端开发中的AI应用：从Vue到Next.js
我之前有接触过前端开发，主要是Vue.js。有了AI助手之后，维护Next.js前端项目，还算比较轻松。
Vue.js经验打底
因为有过Vue.js的开发经验，我对前端的一些概念（组件、路由、状态管理）比较熟悉。这让我在用AI维护Next.js项目时，能够：
- 理解AI生成的代码逻辑
- 判断AI的方案是否合理
- 提出更有针对性的需求
Next.js维护：AI负责”干活”
Next.js我不是很熟，但有了AI，这个问题不大。
我的做法是：
- 我描述需求（”这个页面需要加一个搜索框，搜索后过滤表格数据”）
- AI生成代码
- 我检查一下逻辑是否符合业务
- 如果没问题，就打包发布
大部分情况下，AI生成的代码是直接能用的。偶尔会有小问题，比如：
- 样式不对（AI用了Tailwind，但项目用的是CSS Modules）
- 接口调用方式不对（AI不知道项目的API封装方式）
这时候我会把错误信息（F12看到的console报错、网络请求失败信息）扔给AI，它通常能快速定位问题。
“奇怪”的Bug：F12大法
有些Bug比较”奇怪”，比如：
- 页面白屏，但没有任何报错
- 点击按钮没反应，但代码看起来没错
- 接口返回200，但数据不对
这种时候，我会：
- 打开F12（浏览器开发者工具）
- 看Console有没有报错
- 看Network看看接口请求和响应
- 把看到的信息告诉AI
大部分情况下，AI能根据这些信息定位问题。比如：
- Console报错
Cannot read property 'map' of undefined→ AI知道是数据没初始化 - Network显示接口返回404 → AI知道是API路径配错了
- 页面白屏但无报错 → AI可能会问”有没有用Suspense？有没有报React Error Boundary？”
六、效率提升与思考
用了AI Agent一段时间，感受最深的有几点：
1. 有更多时间思考”为什么”，而不是”怎么做”
以前写代码，很大一部分时间在查文档、试错、调试。现在这些”怎么做”的事情，可以交给AI。
我可以把更多时间花在：
- 这个功能真的必要吗？
- 有没有更简单的实现方式？
- 用户体验能不能更好？
2. 技术栈不再是障碍
以前遇到不熟悉的技术栈，第一反应是”这个我做不了”或者”得先学几个月”。
现在的心态是：”不懂没关系，AI懂就行，我负责判断对不对。”
当然，这不是说不需要学习。基础概念还是要懂的，不然你连AI对不对都判断不了。但至少，不需要”精通”才能上手了。
3. AI不是万能的
说了很多好处，也要说点局限。
AI现在的问题：
- 上下文长度限制：对话长了就慢，甚至遗忘前面的内容
- 幻觉问题：有时候会”自信地胡说”，比如引用不存在的API
- 依赖训练数据：太新的技术（比如昨天刚发布的框架），AI可能不知道
所以我的做法是：AI负责”初稿”，人负责”把关”。AI生成的代码，我一定会过一遍，确认逻辑没问题才发布。
4. 效率提升的”副作用”：从”被推着走”到”主动建议”
用了AI之后，开发效率提升是明显的。但这也带来了一个”副作用”——我开始有更多时间和精力去思考业务，而不只是赶进度。
以前的状态：
- 开发相对慢，经常被客户推着走
- 客户说啥就是啥，没时间思考”为什么要这样做”
- 交付压力大，质量有时只能妥协
现在的状态：
- 开发速度快了，有时间思考”这个功能真的合理吗？”
- 经常会主动给客户提建议：”这个地方可以这样做，用户体验更好”
- 甚至会咨询用户：”要不要试试改成XX方式？”
这种转变让我和客户的关系也变了。以前是”执行者”，现在是”顾问”。
但也有”烦恼”：
效率提升后，领导看我”有空”了，开始同时给我安排多个项目……
一开始还挺高兴，觉得自己能力提升了吗。结果项目一多，又开始忙了。不过好在，即使同时做多个项目，每个项目的交付质量还是比之前高。
反思：AI提升了个人效率，但如果没有配套的流程管理（比如项目排期、资源分配），可能会导致”效率越高，活越多”的怪圈。这可能是下一步需要思考的问题。
七、结语
这次公司AI培训，让我看到了同事们的不同用法，也让我反思自己的使用方式。
双Agent协作、上下文压缩、改完再优化、Token管理策略——这些是我之前没想到的角度，后续会尝试融入自己的工作流程。
AI Agent不是银弹，但它确实在改变开发方式。从”反复发布验证”到”本地快速迭代”，从”不懂就查文档”到”不懂就问AI”，效率的提升是实实在在的。
下一步，我打算试试让AI帮我做代码审查，看看能不能像同事说的那样，用双Agent模式提升代码质量。
写于2026年4月28日，公司AI培训后
