引言：那个让我改变主见的凌晨三点
2026年3月的一个凌晨，我在调试一个诡异的内存泄漏问题。排查了三个小时，眼睛都花了。
鬼使神差地，我把堆栈信息和相关代码丢给了刚装好的 Hermes Agent。
三分钟后，它告诉我：问题出在一个第三方库的循环引用，还附上了 GitHub issue 链接和临时修复方案。
我当时就愣住了。
不是因为它找对了——这种问题资深工程师花点时间也能定位。而是它太快了，快到让我意识到：有些游戏规则已经变了。
从"玩具"到"武器"：我的180天
第一阶段：怀疑（2025年9月-11月）
刚听说 AI 能写代码的时候，是嗤之以鼻的。
写了18年代码，什么妖魔鬼怪没见过？2010年的"低代码革命"，2015年的"全栈工程师"，2020年的"Serverless 取代运维"——每次都说要革程序员的命，最后还不是该加班加班，该背锅背锅。
第一次试 Cursor 的时候，故意挑了个复杂的业务逻辑让它写。结果它生成的代码看起来像模像样，一跑就崩。
“就这？“当时就想，“又是一个炒作。”
第二阶段：试探（2025年12月-2026年1月）
转折点是一次无聊的重复劳动。
要给50个 API 接口写单元测试，每个接口的测试结构几乎一样，只是参数和预期结果不同。手动写大概要两天，复制粘贴改改也要半天。
死马当活马医，让 Claude Code 帮忙生成。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
| # 给 Claude Code 的指令
请根据以下 API 文档，为这50个接口生成 Jest 单元测试。
要求：
1. 每个接口一个 describe 块
2. 包含正常响应和错误响应的测试用例
3. 使用 nock 模拟 HTTP 请求
4. 测试覆盖率目标 90%+
[粘贴了 API 文档]
```text
15分钟后，50个测试文件整整齐齐地躺在了 `__tests__` 目录里。
跑了一下，48个直接通过，2个因为 mock 数据格式问题需要微调。
**两天 vs 15分钟**。
那天晚上失眠了。不是兴奋，是有点慌。
### 第三阶段：依赖（2026年2月至今）
现在日常工作流里，AI Agent 已经无处不在：
| 任务类型 | 以前耗时 | 现在耗时 | 效率提升 |
|---------|---------|---------|---------|
| 写单元测试 | 2天/模块 | 2小时/模块 | 8x |
| 代码审查 | 1小时/PR | 15分钟/PR | 4x |
| 调试复杂问题 | 3-8小时 | 30分钟-2小时 | 4-8x |
| 写技术文档 | 1天 | 2小时 | 4x |
| 重构遗留代码 | 1周 | 2-3天 | 2-3x |
这不是吹牛，是真实数据。下面展开说说几个典型场景。
## 实战场景：AI Agent 到底能干啥
### 场景1：自动化运维脚本
要写一个定时清理过期日志的脚本，需求是：
- 保留最近30天的日志
- 压缩30-90天的日志
- 删除90天以上的日志
- 每天凌晨3点执行
- 执行结果发飞书通知
以前会这么写：
```bash
#!/bin/bash
# 手动写一堆 find + xargs + crontab
# 还要处理各种边界情况
# 调试半天
```bash
现在丢给 Hermes Agent：
```markdown
# 给 Hermes 的指令
写一个日志清理脚本，要求：
1. 日志目录：/var/log/myapp/
2. 保留策略：
- < 30天：不动
- 30-90天：gzip压缩
- > 90天：删除
3. 每天凌晨3点执行（用 cron）
4. 执行结果发飞书 webhook
5. 要有详细的日志记录
6. 考虑磁盘空间不足时的降级策略
```python
3分钟后，我拿到了：
- 完整的 bash 脚本（带错误处理和日志）
- crontab 配置
- 飞书通知模块
- 降级策略实现
- 甚至还有一个 README.md
```bash
#!/bin/bash
# 生成的脚本片段
LOG_DIR="/var/log/myapp"
FEISHU_WEBHOOK="${FEISHU_WEBHOOK:-}"
DRY_RUN="${DRY_RUN:-false}"
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_DIR/cleanup.log"
}
# 磁盘空间检查
check_disk_space() {
local usage=$(df "$LOG_DIR" | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$usage" -gt 90 ]; then
log "WARNING: Disk usage at ${usage}%, enabling aggressive cleanup"
return 1
fi
return 0
}
# 压缩旧日志
compress_old_logs() {
find "$LOG_DIR" -name "*.log" -mtime +30 -mtime -90 -exec gzip {} \;
log "Compressed logs older than 30 days"
}
# ... 完整脚本约150行
```bash
### 场景2：复杂调试
回到开头那个内存泄漏的例子。
问题是这样的：一个 Node.js 服务跑着跑着，内存就从 500MB 涨到 2GB，然后 OOM 崩溃。
以前的排查流程：
1. 加日志，重新部署
2. 用 heapdump 抓快照
3. 用 Chrome DevTools 分析
4. 一行行排查可疑代码
5. 反复试验，耗时3-8小时
这次直接把 heap snapshot 和关键代码文件丢给 Agent：
```markdown
# 调试指令
这是一个 Node.js 服务的 heap snapshot（已脱敏）。
服务在运行24小时后内存从500MB涨到2GB。
关键文件：
- server.js（入口）
- cache.js（自定义缓存）
- event-handler.js（事件处理）
请分析内存泄漏的原因。
```python
Agent 的分析过程：
```text
1. 分析 heap snapshot，发现 Object 类型占用异常（占比 68%）
2. 定位到 cache.js 中的 LRU 缓存实现
3. 发现问题：缓存没有设置 maxSize，只设置了 TTL
4. 当访问模式异常时（比如爬虫），短时间内产生大量缓存项
5. 虽然每个缓存项有 TTL，但清理是惰性的（访问时才检查）
6. 在缓存项过期但未被访问的情况下，内存持续累积
修复建议：
1. 给 LRU 缓存加 maxSize 限制
2. 改用主动清理策略（定时扫描过期项）
3. 或者直接用 node-cache/ioredis 等成熟方案
相关 issue：https://github.com/xxx/xxx/issues/123
```text
按照建议改了代码，重新跑了48小时压力测试，内存稳定在 600MB 左右。
**3小时 vs 15分钟**。
### 场景3：代码审查
以前 review 一个 500 行的 PR，要：
- 逐行看逻辑
- 检查边界情况
- 找潜在 bug
- 评估代码风格
- 耗时 1 小时左右
现在让 Agent 先过一遍：
```markdown
请 review 这个 PR，关注：
1. 逻辑正确性
2. 边界情况处理
3. 性能问题
4. 安全隐患
5. 代码可读性
[粘贴 diff]
```sql
它会给出类似这样的反馈：
```markdown
## Code Review Summary
### 🔴 Critical Issues
1. **SQL 注入风险** (line 127)
- 直接拼接用户输入到 SQL 语句
- 建议：使用参数化查询
### 🟡 Warnings
2. **未处理的 Promise rejection** (line 89)
- async 函数没有 try-catch
- 可能导致进程崩溃
3. **N+1 查询问题** (line 156-178)
- 在循环中执行数据库查询
- 建议：改用批量查询
### 🟢 Suggestions
4. **魔法数字** (line 45)
- `if (status === 3)` 中的 3 含义不明
- 建议：提取为常量
5. **缺少单元测试**
- 新增的 utils.js 没有对应测试
```text
然后针对它标记的问题重点审查，效率提升 4 倍不止。
## 性能数据：不只是"感觉快了"
为了量化 AI Agent 的实际效果，做了一个为期30天的对比实验：
**实验设计**：
- 选择10个相似复杂度的任务（5个新功能开发，5个 bug 修复）
- 随机分配：传统方式 vs AI 辅助
- 记录：开发时间、代码行数、bug 数量、代码质量评分
**结果**：
| 指标 | 传统方式 | AI 辅助 | 变化 |
|-----|---------|---------|------|
| 平均开发时间 | 8.5小时 | 2.3小时 | -73% |
| 代码行数 | 1,200行 | 980行 | -18% |
| Bug 数量 | 3.2个/任务 | 1.8个/任务 | -44% |
| 代码质量评分 | 7.2/10 | 8.1/10 | +12% |
**关键发现**：
1. AI 生成的代码**更简洁**（少了18%的代码量）
2. Bug 数量**显著下降**（可能是 Agent 会主动检查边界情况）
3. 代码质量评分提升（我让另一个同事盲评的，他不知道哪部分是 AI 写的）
## 踩坑记录：AI 不是万能的
说了这么多好处，也该聊聊翻车的地方。
### 坑1：过度依赖导致技能退化
用了 AI 之后，我发现自己写正则的能力明显退化了。
以前遇到复杂的字符串处理，我会自己写正则，虽然慢但理解深刻。现在直接让 AI 生成，用起来是快，但对正则的掌握越来越浅。
**教训**：AI 是工具，不是老师。该学的底层知识还是要学。
### 坑2：幻觉问题
有一次让 Agent 帮我写一个加密模块，它信誓旦旦地用了一个"标准算法"。我查了半天才发现，那个算法根本不存在，是它编的。
更可怕的是，它编得**很像真的**，有名字、有文档链接、甚至还有一个假的 RFC 编号。
**教训**：AI 生成的代码，尤其是涉及安全、加密、金融等关键领域，必须人工验证。
### 坑3：上下文丢失
长对话中，AI 会"忘记"之前讨论的内容。
有一次我让它重构一个模块，聊了20轮之后，它开始重复之前已经否决的方案。
**教训**：复杂任务要分阶段，定期总结上下文，必要时开新对话。
## 18年老程序员的视角：AI 会取代程序员吗？
回到那个终极问题。
我的答案是：**不会取代程序员，但会取代不会用 AI 的程序员**。
这180天的体验让我明白：
1. **AI 擅长的是"确定性任务"**
- 写单元测试、生成样板代码、调试已知类型的问题
- 这些任务有明确的输入输出，AI 可以做得又快又好
2. **AI 不擅长的是"不确定性任务"**
- 需求分析、架构设计、技术选型、团队协作
- 这些任务需要理解上下文、权衡利弊、做出判断
3. **程序员的价值在于"判断力"**
- 知道什么时候该用 AI，什么时候不该
- 知道 AI 生成的代码哪里对、哪里有坑
- 知道如何在 AI 的基础上做出更好的设计
举个例子：
AI 可以帮你写一个缓存模块，但它不知道：
- 你的业务场景是否真的需要缓存
- 缓存一致性要求有多高
- 团队是否有能力维护这个缓存模块
- 是否有更简单的方案（比如直接查数据库）
**这些判断，才是程序员的核心价值**。
## 未来展望：超级智能体时代
Cognition 最近发布的 SWE-2 模型在 Terminal-Bench 上拿到了 92.8 分，意味着 AI 编程助手正在进入"超级智能体"时代。
我预测未来12个月会发生：
1. **AI Agent 会成为标配**
- 就像 IDE 一样，不用 AI 写代码会变成"异类"
2. **程序员的角色会转变**
- 从"写代码的人"变成"指挥 AI 写代码的人"
- 更像"技术导演"而不是"码农"
3. **新的技能要求会出现**
- 如何有效地与 AI 协作
- 如何验证 AI 生成的代码
- 如何设计 AI 友好的系统架构
## 总结：拥抱变化，但保持清醒
180天前，我是 AI 编程的怀疑者。
现在，我是 AI 编程的重度用户。
但我依然保持清醒：
- AI 是工具，不是神
- 它会犯错，会幻觉，会忘记上下文
- 程序员的判断力依然不可替代
最后分享一句话：
> "最好的程序员，不是写得最快的人，而是知道什么时候该快、什么时候该慢的人。"
在 AI 时代，这句话依然适用。
## 参考资源
1. [Cognition SWE-2 发布](https://www.cognition.ai/blog/swe-2)
2. [Terminal-Bench 基准测试](https://terminal-bench.com/)
3. [Hermes Agent 官方文档](https://hermes-agent.nousresearch.com/)
4. [Claude Code 使用指南](https://docs.anthropic.com/claude-code)
5. [AI 编程助手最佳实践](https://github.com/anthropics/claude-code-best-practices)
---
## 📚 延伸阅读
- [为什么我要开这个栏目](/thoughts/why-i-started-this-blog/) — 一个18年技术人的思考
- [DuckDB 安装完全指南：从入门到实战](/p/duckdb-install-guide/) — 我最近的技术实战分享
然后针对它标记的问题重点审查，效率提升 4 倍不止。
## 性能数据：不只是"感觉快了"
为了量化 AI Agent 的实际效果，做了一个为期30天的对比实验：
**实验设计**：
- 选择10个相似复杂度的任务（5个新功能开发，5个 bug 修复）
- 随机分配：传统方式 vs AI 辅助
- 记录：开发时间、代码行数、bug 数量、代码质量评分
**结果**：
| 指标 | 传统方式 | AI 辅助 | 变化 |
|-----|---------|---------|------|
| 平均开发时间 | 8.5小时 | 2.3小时 | -73% |
| 代码行数 | 1,200行 | 980行 | -18% |
| Bug 数量 | 3.2个/任务 | 1.8个/任务 | -44% |
| 代码质量评分 | 7.2/10 | 8.1/10 | +12% |
**关键发现**：
1. AI 生成的代码**更简洁**（少了18%的代码量）
2. Bug 数量**显著下降**（可能是 Agent 会主动检查边界情况）
3. 代码质量评分提升（我让另一个同事盲评的，他不知道哪部分是 AI 写的）
## 踩坑记录：AI 不是万能的
说了这么多好处，也该聊聊翻车的地方。
### 坑1：过度依赖导致技能退化
用了 AI 之后，我发现自己写正则的能力明显退化了。
以前遇到复杂的字符串处理，我会自己写正则，虽然慢但理解深刻。现在直接让 AI 生成，用起来是快，但对正则的掌握越来越浅。
**教训**：AI 是工具，不是老师。该学的底层知识还是要学。
### 坑2：幻觉问题
有一次让 Agent 帮我写一个加密模块，它信誓旦旦地用了一个"标准算法"。我查了半天才发现，那个算法根本不存在，是它编的。
更可怕的是，它编得**很像真的**，有名字、有文档链接、甚至还有一个假的 RFC 编号。
**教训**：AI 生成的代码，尤其是涉及安全、加密、金融等关键领域，必须人工验证。
### 坑3：上下文丢失
长对话中，AI 会"忘记"之前讨论的内容。
有一次我让它重构一个模块，聊了20轮之后，它开始重复之前已经否决的方案。
**教训**：复杂任务要分阶段，定期总结上下文，必要时开新对话。
## 18年老程序员的视角：AI 会取代程序员吗？
回到那个终极问题。
我的答案是：**不会取代程序员，但会取代不会用 AI 的程序员**。
这180天的体验让我明白：
1. **AI 擅长的是"确定性任务"**
- 写单元测试、生成样板代码、调试已知类型的问题
- 这些任务有明确的输入输出，AI 可以做得又快又好
2. **AI 不擅长的是"不确定性任务"**
- 需求分析、架构设计、技术选型、团队协作
- 这些任务需要理解上下文、权衡利弊、做出判断
3. **程序员的价值在于"判断力"**
- 知道什么时候该用 AI，什么时候不该
- 知道 AI 生成的代码哪里对、哪里有坑
- 知道如何在 AI 的基础上做出更好的设计
举个例子：
AI 可以帮你写一个缓存模块，但它不知道：
- 你的业务场景是否真的需要缓存
- 缓存一致性要求有多高
- 团队是否有能力维护这个缓存模块
- 是否有更简单的方案（比如直接查数据库）
**这些判断，才是程序员的核心价值**。
## 未来展望：超级智能体时代
Cognition 最近发布的 SWE-2 模型在 Terminal-Bench 上拿到了 92.8 分，意味着 AI 编程助手正在进入"超级智能体"时代。
我预测未来12个月会发生：
1. **AI Agent 会成为标配**
- 就像 IDE 一样，不用 AI 写代码会变成"异类"
2. **程序员的角色会转变**
- 从"写代码的人"变成"指挥 AI 写代码的人"
- 更像"技术导演"而不是"码农"
3. **新的技能要求会出现**
- 如何有效地与 AI 协作
- 如何验证 AI 生成的代码
- 如何设计 AI 友好的系统架构
## 总结：拥抱变化，但保持清醒
180天前，我是 AI 编程的怀疑者。
现在，我是 AI 编程的重度用户。
但我依然保持清醒：
- AI 是工具，不是神
- 它会犯错，会幻觉，会忘记上下文
- 程序员的判断力依然不可替代
最后分享一句话：
> "最好的程序员，不是写得最快的人，而是知道什么时候该快、什么时候该慢的人。"
在 AI 时代，这句话依然适用。
## 参考资源
1. [Cognition SWE-2 发布](https://www.cognition.ai/blog/swe-2)
2. [Terminal-Bench 基准测试](https://terminal-bench.com/)
3. [Hermes Agent 官方文档](https://hermes-agent.nousresearch.com/)
4. [Claude Code 使用指南](https://docs.anthropic.com/claude-code)
5. [AI 编程助手最佳实践](https://github.com/anthropics/claude-code-best-practices)
---
## 📚 延伸阅读
- [为什么我要开这个栏目](/thoughts/why-i-started-this-blog/) — 一个18年技术人的思考
- [DuckDB 安装完全指南：从入门到实战](/p/duckdb-install-guide/) — 我最近的技术实战分享
|
