# AI 是坏的吗？

**Summary:** AI 可以让你更快、更懒、更有能力，也更依赖外部系统。真正的问题不是 AI 好不好，而是你选择外包哪部分知识，以及这笔交换是否值得。

- Canonical: https://markhuang.ai/zh/blog/is-ai-bad
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-05-22
- Section: AI 与 LLM
- Tags: AI 采用, AI 工具, 自动化, 工程, 生产力
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![工程师在衡量 AI 的收益和过度依赖的风险](https://cdn.markhuang.ai/blog/is-ai-bad/hero.webp)

*工程师在衡量 AI 的收益和过度依赖的风险*

AI 到底是不是个坏东西？

这问题现在满天飞。论坛、社区、群聊、周会、产品 demo、投资人 pitch——谁都能发表一通看法。

有一派人恨不得什么都往 AI 上靠。写代码用 AI，写作用 AI，总结用 AI，做计划用 AI，连思考都想让 AI 代劳。只要世上存在一种工作流，就有人想在前面塞一个 AI 助手。

另一派人躲得远远的。观望的、怀疑的、觉得 AI 让人变懒的、觉得 AI 会让你因为不碰基础而变蠢的——而且他们也不全错。

我自己是 AI 的坚定用户。我觉得 AI 有用、强大，而且已经强到足以改变工程师的工作方式。但它会让我变蠢吗？

看情况。

这答案听着像和稀泥，但我认为这是唯一诚实的回答。大多数技术都不是非黑即白。答案取决于你看重什么、愿意承担什么风险、拿到了什么好处，以及——有哪些知识你因为工具能代劳而选择不再深入。

## AI 并没有取消权衡

关于 AI 的讨论，最偷懒的论证是：

```text
AI 让我能做更多事。
所以 AI 是好的。
```

最偷懒的反驳是：

```text
AI 替我干活。
所以 AI 让我退化。
```

两边都太简单了。

真正的问题更接近这样：

```text
我把什么外包出去了？
我得到了什么？
我失去了什么？
这种失去，对我的人生或工作而言，真的要紧吗？
```

比如我用 AI 写一个一次性的 shell 命令，大概也就是少练了几个平时不常用的 flag。但如果我用 AI 设计 authentication 或支付逻辑，而我自己搞不懂安全模型——那就是完全不同的风险了。

AI 不会因为"降低了摩擦"就自动变成坏事。洗碗机降低了摩擦，计算器降低了摩擦，高级编程语言也降低了摩擦。真正的问题出在：你把那些必须自己理解才能做出好判断的东西，外包出去了。

聊到这里，讨论才开始有价值。

![友好的 AI 助手把天气数据连接到家庭灌溉工作流和草坪喷头](https://cdn.markhuang.ai/blog/is-ai-bad/irrigation-ai.webp)

*AI 把天气数据变成灌溉建议*

## 我的草坪不需要我成为草坪科学家

作为工程师、作为 AI 的早期用户，我一直反复问自己一个问题：

AI 到底能帮我把现实生活中的什么事情做得更好？

不是 demo，不是玩具，不是那种"看，AI 也能做这个诶"的炫技。我说的是那种无聊但真正实用的改善。

我自己搭了 N8N 服务器，家里有 Rain Bird 智能灌溉系统。在把 AI 引入这个工作流之前，我就已经有自动化了——调天气 API，拉当天预报，然后用硬编码的逻辑决定要不要浇水。

大概长这样：

```text
天气 API
  -> 降雨概率
  -> 预计降水量
  -> 温度
  -> 硬编码 if/else 规则
  -> 启动或跳过喷灌计划
```

能用，也够 deterministic，但判断太粗糙。

佛罗里达的天气不是几个简单规则就能搞定的。湿度、降水量、日照、最近下过雨没有、土壤干湿程度、季节、草坪健康状况——这些变量互相影响。我可以为其中一些写规则，但每加一个变量，就多一个要手动调的阈值，永远调不完。

所以我换了个思路：

```text
天气 API
  -> 当前湿度
  -> 降水预报
  -> 近期降雨
  -> 日照
  -> AI 角色：佛州专业草坪养护员
  -> 建议
  -> 确定性的安全限制
  -> Rain Bird API
```

重点不是"AI 控制了我的喷头"。重点是：在硬编码逻辑太僵硬的地方，AI 给我提供了一个能真正"判断"的层。

我可以问它：

今天该不该浇水？

如果该，浇多久？

理由是什么？

但因为工程素养告诉我不能裸奔，我在外面套了一层护栏：

- 正在下雨的时候绝不浇水。
- 限制单次最大浇水时长。
- 记录 AI 给出的理由。
- 支持手动覆盖。
- 天气 API 或 AI 响应挂掉时，默认不执行。

AI 的价值就在这里。它把一堆天气信号变成了一个靠谱的决策，而我不用花几个小时去学草坪养护的专业知识。

AI 让这件事变好了吗？

我觉得是的。灌溉计划更精准了，时间省了，对数据点的理解也够用了，结果确实更好。

那它让我变蠢了吗？

也可以说，在某个很窄的意义上——是的。我仍然没有深刻理解湿度、降水、日照、土壤行为和草坪健康之间的全部关联。如果 AI 给了一个自信但错误的答案，而我一直盲信下去，那是我自己的问题。

但我真的在乎到要在这个领域深耕吗？

说实话，不太在乎。

我在乎的是草坪健康、不浪费水、周末不用花时间去调阈值。我不需要成为那个能给人开讲座的佛州草坪科学专家。

这就是那笔交易。

![工程师选择哪些知识必须自己掌握，哪些专门任务可以委托给 AI 助手](https://cdn.markhuang.ai/blog/is-ai-bad/knowledge-tradeoff.webp)

*选择哪些知识必须自己掌握*

## 真正的问题是：哪些知识对你重要

很多人喜欢把"用 AI"和"自己学"对立起来。

其实它们不矛盾。

你可以用 AI 研究一个话题，也可以用 Google，可以读书，可以问领域专家，可以自己动手试。这些都是通往同一个目标的不同路径：拿到更好的信息，做出更好的决策。

问题不是"用 AI"在道德上比"手动搜索"更高尚还是更低级。问题是：这些知识，值不值得你自己拥有。

对我来说，知识分三档。

| 知识类型            | 我的原则                   |
| --------------- | ---------------------- |
| 职业核心            | 必须自己理解，哪怕 AI 能帮你跑得更快。  |
| 涉及安全、资金、系统安全或信任 | 要有验证、有约束，最好还要人 review。 |
| 有用但不核心          | 如果翻车代价不大，AI 可以多扛一些。    |

草坪灌溉对我来说属于第三档。

软件架构不是。

如果 AI 帮我写了代码，而我讲不清楚设计、failure mode、数据流、安全影响——那不叫生产力，那叫向机器借自信。

但如果 AI 帮我搭 N8N workflow、画 Rain Bird API 集成的草图、生成自动化初稿，而我在 review 和测试的过程中搞懂了每个环节——这就是工具的正确用法。

这个区别很重要。

AI 应该让浅层的活变便宜，而不应该让重要的思考变得不可见。

## 是的，AI 会冲击就业

AI 会让人丢饭碗。

真的。

我不想拿"新的工作机会会出现"这种话来轻描淡写——好像这么说就能缓解那些正在经历岗位缩减或被替代的人的痛苦。新机会出现需要时间，而眼下的人正在承受冲击。

AI 可以减少某些任务需要的人数。它可以让一个人干出一个团队的活。它可以在新的职业路径成形之前，先把入门级岗位砍掉。它可以让公司用更少的人要更多的产出。对开发者、工程师、设计师、写作者、客服、分析师，以及大量知识工作者来说，这种压力已经是现实了。

从宏观视角看，我理解为什么有人把 AI 形容得像病毒、像又一场砸向社会的疫情。如果 AI 爆发之前就已经在裁员、劳动力就已经过剩，那 AI 只会把这种失衡推得更猛。

乐观的说法是：社会最终会创造新的工作，人们会以不同的方式继续贡献。

也许吧。

但"也许以后会好"付不起这个月的房租。

这里有个很多人没意识到的错位：个人策略和社会影响，根本不是同一个问题。

社会层面，AI 确实会伤害到人。

个人层面，拒绝学这个工具也不会让工具消失。

这话不好听，但确实是事实。

![开发者从底层工具走向高级编程工具，再走向 AI 辅助工程](https://cdn.markhuang.ai/blog/is-ai-bad/tool-evolution.webp)

*工具抽象一直在演进*

## 我不怕 AI 取代我

经常有人问我：你怕不怕 AI 取代开发者？

说实话，不太怕。

不是因为我觉得开发者铁饭碗——我们当然不是。我认为软件开发是当下受冲击最猛的职业之一，因为我们的工作文本密集、工具密集，而且本来就围着机器转。

我不怕，是因为我把 AI 看作一次工具演进。

高级语言开始好用的时候，assembly 程序员也有理由慌。一些工作变了，一些技能不那么吃香了，有些人可能恨透了新的 abstraction——因为它把他们在意的细节藏起来了。

但如果我生在那个年代，我肯定去学 C。

不是因为 C 比 assembly 道德上更高尚。

而是因为它让我用更少的摩擦造出更多的东西。

AI 给我的感觉很像。它不完美，不是魔法。它会给出烂答案，会过度迎合，会误解上下文，会写出看着漂亮但边界情况就崩的代码。

它犯错的时候我照样会骂。工具烂的时候我照样说烂。但光骂技术本身不会让我活干得更好。

学会用它才会。

对工程师来说，真正值钱的能力不是"写 prompt"，而是知道 AI 应该出现在系统的哪个位置。

用 AI 做探索。

用 AI 打草稿。

用 AI 干那些无聊的胶水活。

用 AI 比较不同方案。

用 AI 生成测试——然后你自己检查。

用 AI 找盲点。

但该 deterministic 的地方，保留 deterministic code。失败代价高的地方，保留 review。架构的所有权自己握着。上线的东西你得能讲清楚。

这不是反 AI。这才是认真地用 AI。

## AI 会让你变蠢，如果你放任的话

这里怀疑派是对的。

如果你在需要理解的地方用 AI 替代了理解，它会让你变蠢。

它会让你接受那些"听起来挺对"的解释。

它会让你跳过基础。

它会让你不再看源码。

它会让你不再查文档。

它会让你觉得自己很高效，而判断力在悄悄退化。

这是真实的危险。

但反过来说也成立。如果你把 AI 当成互动老师，它能让你学得更快。它能让你接触到你根本不会主动去搜的想法。它能把一个模糊的话题变成一张知识地图。它能给你正例、反例、练习题。它能帮你发现自己理解错的地方。

工具不会替你选走哪条路。

你的使用方式才会。

让 AI 干活，然后自己从不看——你在把大脑外包出去。

让 AI 解释、挑战、比较、测试，帮你构建一个你仍然拥有的东西——你在延伸自己的能力边界。

这就是我在意的那条线。

![围绕 AI 的社区辩论，同时可见生产力收益和警示信号](https://cdn.markhuang.ai/blog/is-ai-bad/ai-debate.webp)

*围绕 AI 的社区辩论*

## 所以 AI 到底是好是坏？

我的答案还是那三个字：看情况。

AI 帮你拿到更好的结果、省下真正有意义的时间、减少无聊工作、让你接触到原本成本太高的知识——它是好的。

AI 隐藏风险、消解责任、在理解重要的地方替代了理解、或者让经济权力集中到伤害普通人的地步——它是坏的。

对我的浇灌系统，我很乐意让 AI 搭把手。我不需要成为草坪科学专家。

对我的工程工作，我希望 AI 无处不在，但不能让它控制一切。离我足够近来加速我，但也足够有批判性来挑战我——重要的东西外面要有测试、review 和 deterministic 的边界。

我现在的立场：

```text
积极用 AI。
有选择地信它。
在失败代价高的地方验证它。
决策权留给自己。
```

所以 AI 到底是好是坏？

你猜。

评论区见，来吵一架。