当心：软件团队使用 AI 的真实风险
2026 年 9 月 30 日
以下内容都是亲身经历换来的警示，写给工程负责人、管理者、CTO，也写给那些知道（或怀疑）重度依赖大语言模型（LLM）工具做软件开发存在重大弊端的在职工程师。同样写给我自己，算是坦白我作为工程负责人的失误，希望别人别重蹈覆辙。
▶ 观看本文的闲聊视频版。
当心团队开发出自己都看不懂的功能。一旦出问题，聊天机器人也搞不定，那就是灾难。
当心在人际沟通中使用大语言模型生成的内容。这类文字总是啰嗦得要命，还通常毫无用处。AI 写的内部沟通信息，没有半点好处。
当心功能臃肿。人们要的是聚焦、可靠、快速、稳定、能用的软件。
当心用聊天机器人替代人与人之间的协作对话，把初级工程师孤立起来。新人上手和导师带教依然至关重要，聊天机器人替代不了。
当心新员工被孤立，只能去问聊天机器人。
当心初级工程师根本没搞懂生成的代码。常有人说，工程师的职责就是判断 AI 生成的代码哪里错了——可如果整整一代开发者都看不懂这些代码，他们又怎么判断对错？
当心成本不断攀升：新模型层出不穷，用量门槛说变就变，而几大厂商在以前所未有的速度烧了多年钱之后，开始更多地考虑盈利。
当心过度依赖 AI 代码审查来发现安全漏洞和泄露问题。再多的 AI 代码审查，也替代不了那些勤勉、经验丰富、了解整体架构和各个环节、知道哪里可能出问题的开发者。
当心 AI 代码审查的误报。它给出的信息总是说得斩钉截铁，但至少以我的经验，大约一半都是错的。
注意，大语言模型生成代码时，本该复用的代码往往没有被复用。它们没有真正的记忆，也不会因为三个月前把某段代码提取成一个函数而感到满足，自然也不会记得去用那个新函数。它们常常会重复造轮子，在只该有一条路径的地方搞出多条新路径。就算你把 Markdown 文件写得再完美，也挡不住这种事发生。
当心自动化盲区——面对成千上万行由大语言模型生成的代码，很难发现真正的问题。这不是某个人的失职，而是人类的局限。
关注团队的心理健康。随着他们越来越多地用 AI 生成代码，要明白过度依赖这些工具可能导致冷漠情绪，尤其是那些曾经以软件开发这门手艺为傲的人。多和团队沟通，问问他们的感受和经历，问一些用心、有关怀的问题。
当心其他部门内部搞出来的“凭感觉写”的工具，现在可能落到你团队头上要维护。它们可能用各种五花八门的技术栈和编程语言写成，可能包含敏感数据，也可能存在安全漏洞。
当心那些连接了大语言模型的编码工具，它们会执意去读取 .env 文件和其他重要的密钥，不管你写了多少 Markdown 文件和 JSON 配置明确禁止都没用。
当心大语言模型走一些奇怪的捷径，根本没有完整实现功能。
当心依赖膨胀，引入一堆其实用不上的包。
当心追踪和在意那些虚假指标——对业务、组织、团队乃至整个世界其实毫无意义的数字。把“刷 token 用量”当荣耀，是糟糕的管理。
当心把软件开发当成工厂。更多代码、更多功能，并不总能换来更多收入。记住，软件开发是知识工作，开发者是技术娴熟、富有创造力的问题解决者，他们的任务是理解、构建、扩展和修复复杂的系统。
当心用互发 AI 生成的原型取代真正的人际协作。
把接了编码工具的大语言模型（LLM）连到关键服务、系统和基础设施上，这件事要当心。它们已经做过、以后还会做出无法预测、具有破坏性的操作。
非工程人员向聊天机器人提问时，如果没交代完整背景，得到的实现方案有时是错的，这也要当心。
在流水线的每一步都过度信任 AI，要当心。
全自动模式要当心——让编码工具和 LLM 完全放权，直接在你电脑上跑 shell 命令。正如 Cal Newport 所说，这就像把割草机绑在狗身上去割草坪，结果必然是一片混乱。
LLM 生成的大量单元测试要当心，那些看起来「不错」、实则几乎没用的端到端测试也要当心——它们并没有覆盖关键路径。
输出速度的预期会不断被抬高，这一点也要当心。只要有聊天机器人能飞快吐出一行行代码，背后还有几十亿美元的营销造势，这种心态转变就不可避免。
「再来一个提示词」的诱惑要当心。用 LLM 驱动的编码工具，很容易导致过度工作和职业倦怠。
代码行数快速膨胀要当心。日积月累，它会一点点拖慢一切。
财务团队改预算要当心。今天的不限额支出，明天可能就变成有限额度，还没到月底就用超了。
靠「感觉」写代码（vibe coding）实现的功能，以后要维护好几年，而那些功能本来用现成的工具或集成就能解决——这也要当心。维护代码始终是有成本的。
代码库和技术栈分裂要当心，有时只因一个人想走一条和团队其他人不同的路。监督变少、速度变快，都可能引发混乱。
为了加快合并 PR 而想取消人工代码审查，这种念头要当心。把改动内容和原因在团队里共享，既能传递知识背景，也让人觉得自己和团队是连在一起的。
重度依赖一项尚未定型的技术要当心——它的成本、模型和预算一直在变。现在用这些工具的方式，几个月或几年后很可能就完全不一样了。
警惕 AI 公司、鼓吹者以及其他不怀好意的人炒起来的 AI 热潮。认真想想其中的危害，评估实际影响，和团队聊聊，再做出深思熟虑、可持续的决策。
警惕聊天机器人带来的心理健康风险——它造成的影响和伤害，人们才刚刚开始正视。
别为了跑得更快，就丢掉基本原则。
警惕工程师技能退化的问题。毕竟生成的代码，最终还得由他们负责。
警惕团队文化和士气被一点点侵蚀。
好，你已经警惕过了……那接下来呢？作为工程负责人，这正是你要想清楚的事：怎么把一项技术融入团队，让它真正有用、可持续，并且尽量少带来冲击。上面这些风险，有些或许能减轻或规避；也可能业务本身就能接受这些风险。也许意味着减少 AI 的使用量，也许意味着只在特定任务上用，也许意味着干脆不用。你可以开个会，跟团队聊聊他们的真实体验；可以起草一份内部规范，明确什么叫「负责任地使用」，把预期讲清楚；也可以明确告诉工程师：选择不用 AI 完全没问题。这样他们就不会因为拒绝这项技术，而担心头顶悬着一把达摩克利斯之剑。
我不了解你的目标、业务和面临的压力。但我知道，用 AI 做软件开发牵扯到的风险相当多——更别提那些更宏观的伦理和环境问题了。
当然，你也可以不用它。就像过去几十年写代码那样。你可能会觉得「不得不用」，否则就要出事。但未来并没有被决定，实际上它相当不确定。带团队的经历让我相信：行业现在这套做法，对团队不好，对软件的用户不好，对软件本身不好，对业务不好，对行业不好，对社会不好，对地球也不好。
延伸阅读
- Nikhil Suresh 的《AI Mania Is Eviscerating Global Decision-Making》
- Humancrafted Forum 的 Work 分类
如果觉得有帮助，欢迎请我喝杯咖啡，或者订阅我的 YouTube 频道，算是对我的支持。感谢阅读！