为什么不建议让AI用你不熟悉的语言和框架？

" 我是大树，一个还在折腾 AGI 学习与实践的普通开发者。 最近和一个朋友聊到一个挺扎心的话题—— 当 AI 能帮你快速写出任何语言的代码时，"听不懂"代价的那个瞬间，会在什么时候找上门？ "

你有没有过这种感觉——

AI 帮你写了一堆代码。跑起来了。Demo 展示很顺利。老板/客户很满意。

然后……要上线了。

这时候你突然发现：你根本搞不懂这段代码在干什么。

不是"不太懂"，是确切地不知道某个模块为什么这样写、那个配置为什么那样设、某个依赖为什么非更新不可。你试着改了一行——崩了。再改一个——又崩了。

然后你陷入了一个死循环：

• 要改好 → 需要了解这个语言/框架
• 要了解 → 需要花时间学
• 花时间学 → 项目 deadline 等不起

这让我想到一个词：“外卖的最后一公里”。

配送再快，最后一公里送不到手里，前面的速度全白费。

不是 AI 不够强，是交付层级变了

先抛一个我自己琢磨出来的框架。

用 AI 写代码这件事，按交付层级可以分成三个台阶：

有意思的地方来了——

AI 在前两个层级上，效率提升是碾压级的。

你想要一个 React + Tailwind 的落地页？描述需求，AI 30 分钟给你画出来。你要一个 Python FastAPI 后端？说清楚路由和数据表结构，AI 一小时搭好。你要从"看得见效果"变成"基本能用"？加些错误处理、补上基本的 UI 交互、连上真实数据——AI 仍然能帮你搞定大部分。

但到了"生产级"这个台阶，事情变得微妙起来。

"最后一公里"到底卡在哪？

说到这儿，得先问问什么叫"生产级产品"。

不是"能跑"就叫生产级。也不是"没有明显 bug"就叫生产级。至少包含这几个维度：

• 健壮性 — 边界情况、异常输入、下游挂了——你都想过吗？
• 可维护性 — 三个月后的你，或者接手的同事，能看懂这段代码吗？
• 可调试性 — 线上出了 bug，你能在合理时间内找到根因吗？
• 可扩展性 — 需求变化时，代码结构能优雅地适应，而不是推倒重来吗？
• 安全性 — SQL 注入、XSS、敏感信息泄露——这些坑你确认都避开了吗？

单独看每个维度都不算难。但同时满足所有维度，需要对技术栈有真正的理解。

AI 能帮你写出"满足基本功能"的代码。但当你需要在已有代码上做进一步决策时——

“这个异常应该在这层 catch 还是在底层 catch？” “这个函数是纯的还是带副作用的？这样写会不会埋雷？” “这个框架推荐的模式是什么？我当前这样写是不是在对抗框架？” “这笔配置放这里有没有安全风险？”

这些问题，AI 都能回答你。但问题在于——你根本不知道应该问这些问题。

这才是最致命的地方。

你缺的不是答案。你缺的是知道自己缺什么。

翻车经历

前阵子用 AI 写了一个工具，技术栈完全不熟——前端用的一个之前没碰过的框架，后端用 Node.js + Prisma（我之前的主力一直是 Java）。

Demo 跑通，用了 3 天。内部试跑，用了 1 周。感觉很兴奋，觉得自己有了 AI 简直"无所不能"。

然后当把这个东西给到客户侧用。

噩梦开始了。

• 用户上传了一个超大文件，前端直接无响应——他不知道这个框架有虚拟列表方案，更不知道怎么用
• 并发请求把数据库连接池打满了——我连 Prisma 有连接池配置这件事都不知道
• 安全审计指出接口没有做权限校验——他翻了半天代码才找到路由定义在哪个文件

" AI 帮我走完了 90% 的路。但那最后的 10%，我走了一个月。 每一步，都在补之前没交的学费。 "

比例因人而异。但核心逻辑是一样的：AI 帮你跳过了学习过程，但没有帮你跳过踩坑。学习可以跳过，踩坑不能。

那是不是就别用 AI 写不熟悉的代码了？

当然不是。

如果真的不能用，我也不会写这篇文章了。

关键在于判断：你写这段代码最终要服务什么，以及它值不值得你花时间去学这个技术栈。

我给自己列了个判断逻辑，分享出来参考：

适合用 AI 写不熟悉语言的场景：

• 一次性脚本 — 用完即扔，坏了也没关系
• 内部工具原型 — 给团队试水的 MVP，不涉及关键数据和权限
• 快速验证想法 — 先跑通看看效果，行再投入正式做
• 学习参考 — 让 AI 写出来，你一行一行读，边读边学（但这就不叫"不用学"了）

不适合用 AI 写不熟悉语言的场景：

• 面向客户的长期产品 — 你要长期维护和迭代，代码要陪着你很久
• 涉及安全/合规的系统 — 你不了解风险点在哪，AI 也不会主动告诉你
• 多人协作的核心模块 — 你的代码别人要读、要改，你自己都不懂，怎么配合？
• 你打算在这个方向深耕 — 如果这是你的职业方向，避不开的学习不如早点开始

那如果需要长期维护，怎么用 AI 帮忙？

这是我目前比较务实的态度：

让 AI 帮你写，但你要负责看懂。

什么意思呢？不是 AI 写完就收工了。而是：

1. 每一段 AI 生成的代码，你至少要能说出它为什么这样写。 答不上来的地方，追问 AI 解释——直到你真正理解
2. 关键模块自己手写一遍。 写过和读过的理解深度，完全不是一个量级
3. 让 AI 帮你梳理知识地图。 生成代码的同时，让它给你画一张这个技术栈的知识图谱——你才知道哪些东西是你还不懂的
4. 建立自己的"兜底"能力。 线上出了紧急 bug，AI 可能帮不上忙（网络问题、上下文不在、或者单纯就是来不及）。这个时候，能救火的只有你自己

" 长期维护要交的学费，要么现在交——边学边写。 要么以后交——出了问题花更大力气去补。 这笔账，省不掉。 "

更大的问题

写到这儿，我想到一个更大的话题。

AI 编程工具正在模糊一个重要的边界："能做到"和"能掌控"之间的边界。

你能让 AI 写一个你不懂的技术栈的代码，并且它"能跑"。这意味着你"做到"了——功能实现了，产品上线了。

但这不意味着你"掌控"了它。

你不知道它什么时候会出问题，不知道改一处会引发什么连锁反应，不知道性能瓶颈在哪。它像一个黑箱——能用，但不可控。

"能做到"满足的是短期交付。 "能掌控"才是长期可持续的竞争力。

对个人开发者如此，对团队和组织也是如此。

你可以用 AI 快速启动一个项目。但如果你要把它做成一个认真的、要长期运行的、对得起用户信任的东西——你最终还是要回到"理解"这件事上。

这也是为什么我觉得，真正优秀的开发者不会因为 AI 而变弱。

他们会变成另一种人：能用 AI 跨越语言的障碍快速起步，但不会在关键的地方依赖 AI 来代替自己的判断。

写完之后我又想了想——

其实这个"最后一公里"的困境，不只在写代码这件事上。在很多事情上都是这样。

AI 帮你走完了 90%，但那剩下的 10%，才是决定事情能不能做成的关键。

而且那份"掌控感"，不会因为你用了 AI 就自动拥有。