上个月 refactor 一个老项目，顺手让 AI 帮忙重写了一个工具函数。
它给了一版代码，看起来很优雅：用了最新的语法，链式调用，函数式风格。我 copy-paste 进去，测试通过，心想这效率真高。
三天后线上报警。
那个"优雅"的函数在特定边界条件下会无限递归。我盯着堆栈看了半小时才发现问题——AI 用了一个我没注意到的隐式假设。
这种事发生过几次之后，我开始怀疑一件事：我们是不是太相信 AI 写的代码了？
数据不会说谎
Taskade 今年发布的《State of Vibe Coding 2026》报告显示，开发者对 AI 生成代码的信任度从 2023-2024 年的 40% 下降到了 29%。
29%。
这意味着超过七成的开发者对 AI 写的代码持怀疑态度。
这个数字让我愣了一下。不是因为低，而是因为我自己就是这 29% 的一部分。
回想 2023 年刚用 Copilot 的时候，那种感觉像是发现了新大陆。写个正则表达式，它直接给你补全；写个数据处理函数，它连边界条件都考虑到了。我当时跟同事说"这玩意儿能顶半个初级工程师"。
现在？我连它写的单元测试都要自己跑一遍。
快和好的悖论
AI 编程工具确实快。
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
| # AI 生成的代码，看起来很完美
def process_user_data(users: list[dict]) -> list[dict]:
return [
{**user, "full_name": f"{user.get('first_name', '')} {user.get('last_name', '')}".strip()}
for user in users
if user.get("is_active")
]
```sql
这段代码用了字典解包、f-string、列表推导式，一行搞定。看起来很 Pythonic。
但问题是：
1. 如果 `first_name` 或 `last_name` 是 `None` 而不是缺失，`f"{None}"` 会输出 `"None"`
2. 如果用户没有 `is_active` 字段，`get("is_active")` 返回 `None`，这个用户会被过滤掉
3. 没有类型检查，`users` 里混入非 dict 会直接报错
这些都不是"错误"，而是**假设**。AI 假设了数据格式、字段存在性、边界条件。而这些假设往往和我的业务场景对不上。
手动写的话，我会先问自己：数据从哪来？有没有脏数据？需不需要 defensive programming？这些思考过程 AI 跳过了，它直接给了一个"看起来对"的答案。
## 信任是怎么流失的
不是一次大事故，而是无数次小失望。
**第一次**：让它写个日期处理函数，它用了 `datetime.strptime` 但没处理时区。生产环境跑在 UTC，用户在上海，时间差了 8 小时。
**第二次**：让它优化一个 SQL 查询，它加了个 `JOIN`，逻辑上没问题，但没考虑索引。查询时间从 200ms 涨到 2 秒。
**第三次**：让它写个错误处理，它用了 `try-except` 但捕获了所有异常（`except Exception`），把真正的 bug 也吞掉了。
每一次都不是"AI 不行"，而是"AI 不够了解上下文"。它不知道我们的部署环境、数据规模、团队规范。它只知道"常见的最佳实践"，但最佳实践不等于适合我的实践。
## Vibe Coding 的疲劳
Steve Yegge 今年提了个观点：AI 编程应该限制在每天 3 小时以内。
当时看到这句话我觉得他在搞笑。代码写得快还限制时间？
但后来想了想，他说的不是"效率"，而是"认知负荷"。
用 AI 写代码的时候，大脑其实在做两件事：
1. 理解 AI 给的代码
2. 判断这代码对不对
第一件事很快，因为代码"看起来"合理。第二件事很慢，因为要验证假设、检查边界、考虑上下文。
一天下来，眼睛累了，脑子也累了。不是写代码累，是"审查代码"累。
我现在的方式是：
```python
# 先写伪代码，明确意图
def process_user_data(users):
"""
输入: [{"first_name": "张", "last_name": "三", "is_active": True}, ...]
输出: [{"first_name": "张", "last_name": "三", "full_name": "张三", "is_active": True}, ...]
规则:
- 只处理 is_active=True 的用户
- full_name 不能包含 "None"
- 缺失字段用空字符串
"""
# 然后让 AI 实现，但我自己写测试
```text
先把意图写清楚，再让 AI 填充实现。这样它知道我要什么，我也知道它做了什么。
不是完全信任，也不是完全不信任，而是**有边界的信任**。
## 开源社区的转向
Debian 社区最近投票通过了"允许在项目中负责任使用生成式 AI"的提案。
注意用词：**负责任使用**。
这不是禁止，也不是放任，而是"可以用，但你要负责"。
我觉得这就是成熟的态度。AI 不是银弹，也不是洪水猛兽。它是一个工具，和 IDE、Linter、Formatter 一样。工具好不好用，取决于怎么用。
GitHub 上最近 trending 的 `mattpocock/skills` 项目也在做类似的事：把 AI 的行为封装成可复用的"技能"，而不是每次都从零开始 prompt。
这说明大家在从"让 AI 随便写"转向"让 AI 按规矩写"。
## 我的新工作流
现在写代码，我会这样做：
1. **先写测试**：不管 AI 怎么写，测试是我的。它过不了测试，代码就不对。
2. **Review 每一行**：AI 给的代码，我会逐行看。不是看语法，是看逻辑和假设。
3. **小步提交**：不让 AI 一次写 500 行。一次 50 行，跑通测试，提交，再来。
4. **记录踩坑**：建了个文档，专门记 AI 写的 bug。不是为了骂它，是为了下次 prompt 更精准。
```bash
# 我的 git 提交习惯
git commit -m "feat: add user processing (AI-generated, reviewed)"
git commit -m "fix: handle None values in name fields (AI missed this)"
git commit -m "perf: add index for user query (AI optimization was slow)"
```text
每个 commit message 都标注了 AI 参与的部分，方便回溯。
## 信任是挣来的，不是给的
回到开头的问题：为什么信任度下降了？
不是因为 AI 变差了，而是因为我们更了解它了。
2023 年的时候，AI 像是个神秘的黑盒，偶尔给出惊艳的答案，我们觉得它无所不能。
2026 年，我们知道了它的边界：它不懂业务上下文，它不知道部署环境，它不考虑团队规范。它能写出"正确"的代码，但不一定是"合适"的代码。
信任度下降不是坏事。这说明我们从"盲目崇拜"走向了"理性使用"。
就像我们不会完全信任一个刚入职的初级工程师一样——他会写代码，但我们需要 review 他的代码，告诉他业务的上下文，教他团队的规范。
AI 也是这样。它是个很强的工具，但工具需要人来驾驭。
## 写在最后
如果你也在用 AI 编程，我的建议是：
别完全信任，也别完全不信任。
把它当成一个很快但需要指导的助手。你负责方向和判断，它负责速度和实现。
这样既能享受效率提升，又不会在半夜被报警电话叫醒。
---
**参考资源：**
- [Taskade State of Vibe Coding 2026 Report](https://www.taskade.com/) - AI 代码信任度数据来源
- [Steve Yegge on AI Fatigue](https://www.businessinsider.com/) - 关于 AI 编程疲劳的讨论
- [Debian AI Usage Proposal](https://www.debian.org/) - 开源社区对 AI 的态度转变
- [GitHub Trending: mattpocock/skills](https://github.com/mattpocock/skills) - Skill-oriented AI 工具
每个 commit message 都标注了 AI 参与的部分，方便回溯。
## 信任是挣来的，不是给的
回到开头的问题：为什么信任度下降了？
不是因为 AI 变差了，而是因为我们更了解它了。
2023 年的时候，AI 像是个神秘的黑盒，偶尔给出惊艳的答案，我们觉得它无所不能。
2026 年，我们知道了它的边界：它不懂业务上下文，它不知道部署环境，它不考虑团队规范。它能写出"正确"的代码，但不一定是"合适"的代码。
信任度下降不是坏事。这说明我们从"盲目崇拜"走向了"理性使用"。
就像我们不会完全信任一个刚入职的初级工程师一样——他会写代码，但我们需要 review 他的代码，告诉他业务的上下文，教他团队的规范。
AI 也是这样。它是个很强的工具，但工具需要人来驾驭。
## 写在最后
如果你也在用 AI 编程，我的建议是：
别完全信任，也别完全不信任。
把它当成一个很快但需要指导的助手。你负责方向和判断，它负责速度和实现。
这样既能享受效率提升，又不会在半夜被报警电话叫醒。
---
**参考资源：**
- [Taskade State of Vibe Coding 2026 Report](https://www.taskade.com/) - AI 代码信任度数据来源
- [Steve Yegge on AI Fatigue](https://www.businessinsider.com/) - 关于 AI 编程疲劳的讨论
- [Debian AI Usage Proposal](https://www.debian.org/) - 开源社区对 AI 的态度转变
- [GitHub Trending: mattpocock/skills](https://github.com/mattpocock/skills) - Skill-oriented AI 工具
|
