AI 编码助手：有帮助还是有害？
Source: Dev.to
Denis Tsyplakov 关于 AI 编码代理的“黑暗面”
Denis Tsyplakov，DataArt 解决方案架构师，探讨 AI 编码助理较少被提及的一面。虽然它们可以提升生产力，但也会带来容易被低估的风险。
在一次简短的实验中，Denis 让 AI 代码助理解决一个简单任务。结果令人深思：如果没有扎实的编码技能和对系统架构的深刻理解，AI 生成的代码很快会变得过于复杂、低效且难以维护。
对 AI 编码助手的复杂感受
- 有些人认为它们是革命性的。
- 另一些人根本不信任它们。
- 大多数工程师介于两者之间：谨慎但好奇。
成功案例很少有帮助。像“我的5岁孩子在15分钟内完成了这个”的说法常被视为营销夸大。这样的怀疑减缓了采纳，但也凸显了一个重要观点：这些工具的好处和局限都需要现实的认识。
供应商面临的市场压力
- 质量下降 – 产品带有错误或不稳定的功能发布。
- 开发决策受炒作驱动，而非用户需求。
- 路线图不可预测 – 今天可用的功能明天可能会失效。
实验：AI 编码能走多深？
我进行了一项小实验，使用了三款 AI 代码助手：
- GitHub Copilot
- JetBrains Junie
- Windsurf
任务
一个简短的面试式问题，用来检验候选人阐述技术架构的能力。
对于资深工程师来说，正确的做法通常只需 3–5 秒 就能给出方案。我们已反复测试，结果始终是瞬间完成。（本文发布后，我们会再为候选人准备另一个任务。）
- Copilot‑类工具 在算法类任务上历来表现强劲。
- 当你让它们实现一个带有明确文档方法的简单类时，通常能得到相当不错的结果。
- 问题出现在需要做出架构决策时——即到底该如何实现。
Junie、Copilot 和 Windsurf 的表现相似。下面是 Junie 提示的逐步拆解。
提示 1 – “实现类逻辑”
结果不会通过代码审查。
逻辑对给定任务来说过于复杂，但总体上是可接受的。
假设我不具备 Java 技术架构的技能，并接受这个方案。
提示 2 – “让它线程安全”
助手给出了技术上正确的解决方案。
但任务本身仍然很简单。
提示 3 – “实现 List getAllLabelsSorted()，该方法应返回按距离点 [0,0] 的接近程度排序的所有标签”
- 这时问题开始显现。
- 代码可以更简洁。
- 大语言模型在算法任务上表现出色，但 原因并不理想：它把一个
long拆成两个int，并在每次调用方法时进行排序。 - 我本期待它使用
TreeMap，因为它会存储所有已排序的条目，并为插入和查找提供 O(log n) 的复杂度。
提示 4 – “我不想每次调用方法时都重新排序标签”
天哪！！！缓存！！！还能更糟吗？！
随后我尝试了多种提示，目标是得到一个使用类似 TreeMap 结构并配合比较器记录的规范解（不直接提及 TreeMap，假设我不熟悉它）。
结果： 没有成功。提问越多，解决方案越乱。我最终得到 三屏几乎无法阅读的代码。
期望的简化方案
- 使用特定的类。
- 线程安全。
- 不 存储过多数据。
是的，这种做法带有主观色彩。它的复杂度为 O(log n) —— 正是我想要的。
关键洞察： 只有当我已经掌握至少 50 % 的解决思路并能用技术语言描述时，AI 才能给出这段代码。如果在对期望结果没有清晰认识的情况下直接使用 AI，输出基本上是随机的。
可以指示 AI 代理使用正确的技术架构吗？
- 你可以让它们使用 records（记录），例如，但无法教会它们 常识。
- 你可以创建一个
project.rules.md文件来覆盖特定规则，但不能把它当作每个项目的通用解决方案。
最大的问题：可维护性
- 代码可能能运行，但其质量往往值得怀疑。
- 难以维护的代码也难以更改——这对需要频繁更新的生产环境是个严重问题。
有些人期待未来的工具仅凭需求就能生成代码，但这仍然是 遥遥无期。就目前而言，可维护性才是关键。
当 AI 编码助手把你的代码变成难以阅读的乱七八糟
| Reason | Consequence |
|---|---|
| Instructions are vague | 生成不相关或过于复杂的代码 |
| Results aren’t checked | 错误和架构缺陷会悄然出现 |
| Prompts aren’t fine‑tuned | 输出变得随机且难以维护 |
这并不意味着你不该使用 AI。
这只是说明你需要 审查生成代码的每一行，这需要强大的代码阅读能力。问题在于，许多开发者缺乏这种经验。
AI‑辅助编码能快多少？
- 根据语言和框架不同，速度提升可达 10–20×。
- 仍然需要阅读和审查代码。
AI 助手的优势
- 在结构严谨的语言（如 Java、C#、TypeScript）中，生成稳定、传统且合规的代码。
AI 的局限
- 缺乏强编译或验证的代码库。
- 软件开发生命周期的某些环节，如 代码审查，AI 生成的代码常常出现问题。
实用要点
- 在向 AI 请求代码之前，先明确你要构建的内容。
- 熟悉当前最佳实践（例如，不使用 Java 11，不使用 Angular 12）。
- 阅读你收到的代码——把 AI 输出视为草稿，而非可直接投入生产的代码。
- 将 AI 助手用于编写样板代码或探索性原型，但不要依赖它们进行代码审查或最终实现。
在我看来，助手已经在编写代码方面很有用，但它们尚未准备好取代代码审查。这可能在未来会改变，但今天还不行。
很快。
考虑到所有这些挑战，以下是你应关注的重点：
- 在合适的场景下开始使用 AI 助手。
- 如果不是在你的主要项目中，尝试在其他地方实验，以保持相关性。
- 彻底审查你的语言规范。
- 通过实践提升技术架构能力。
如果审慎使用，AI 能让你加速；如果盲目使用，最终会拖慢你的进度。