https://lucianonooijen.com/blog/why-i-stopped-using-ai-code-editors

LLM, FSD 这些东西对于我们生活的影响就像是吸毒，一旦产生依赖，就很难戒断。

其实类似这篇文章的反思一直都零零散散的出现过。身边也有程序员朋友很抗拒使用 LLM 写代码，但我司因为号称要追求极致的效率，且向来自诩为 AI Native，所以当然是强烈鼓励大家多多使用 LLM，甚至连 HR 等职能性部门都要求使用 LLM 来广泛用于工作。这样的激进，看似很接近时代的前沿，但也的确如这篇文章的作者忧虑的那样，可能我们并未清晰的意识到我们的代价是什么。

任何事情都不可能是没有代价的。

我深有同感的地方是：

  1. 我也离不开特斯拉了，让我换一辆车开，我会非常不适，几乎没有办法舒服的开。
  2. 离开 Cursor，我几乎无法写代码了。离开 ChatGPT，我几乎没有办法完整的思考。

但同样的，我还依赖搜索，如果没有准确的搜索引擎（上个时代是 Google，现在是 Kagi），我几乎也寸步难行。

同样的，还有历史上重度依赖的 StackOverflow。

我有近 15 年的 Coding 经验了，但在职业生涯的前五年，我基本没有对编程开窍。很大的一个原因是，我总是陷入细节的泥潭。

  • C 语言，我纠结 EOF 是什么就纠结了几个月。（发现所有书籍对此都语焉不详）
  • Java，我根本理解不了为什么一上来要有那么多抽象和封装，如 Struct ｜ Spring ｜ Hibernate，这些庞然大物都是什么？做了什么？
  • C++，我陷入了语言联邦的海洋，我几乎尝试了所有编程的范式，我纠结于每一个 UB，STL 里每一个容器的接口与底层实现。花了无数精力研究最佳实践，以及每一代 Standard 的差异。
  • 设计模式，我只是模模糊糊的感觉有好几套给我准备好的套子，我遇到任何问题，都兴奋的琢磨能套上哪一个。
  • JavaScript，无数奇技淫巧困扰着我，这东西灵活到有时候我总是不确定应该怎么写，但竟然随便写也偶尔能 work。

直到我遇到了 LLM，我才突然脱离了对这些细节的纠结。我发现 Python 不再那么令人恐慌（它过于简单反而让我觉得不安）。我发现 TypeScript 的条条框框反而是福音，因为我可以对 LLM 生成的代码有更多的掌控感（它有时也无法应对 Type 的各种限制）。我几乎没有认真学过 Golang，但丝毫不影响我上手写代码。

从那时起，我才真正花功夫开始思考业务逻辑究竟是怎样才合理，架构应该如何设计，完成一个功能究竟应该如何合理地分解迭代。

当然成就感也 Max，想到的功能，不会存在任何的拖延，几乎马上就去尝试，去实现。

所以我会愿意抛弃 LLM，专心打磨写代码的技能吗？就像，放弃特斯拉，甚至专门找一个手动挡，磨练自己的驾驶技术？

跳出来看到更大的世界后，我已经不愿意了。

人生苦短，早年看到的令人惊叹，值得为此奋斗一生的”技艺“，如今已觉得不再值得。君子不器，在这个时代的技术红利下，竟然成了可实现的理想。

我甚至不再希望骄傲的称自己为程序员。但这并不意味着我不对技艺的打磨失去了敬畏。无论机器如何进步，我对于传统手艺者的坚持与执着都是极其钦佩与尊重的。但这里的重点，是当作一种纯粹的爱好，而无关效率。

不排除有人就是喜欢 Coding 的感觉，手指尖跳舞的节奏，LeetCode 攻城略地的快感。但我在 35 岁这个档口，真的需要承认，我对此并没有那么感兴趣。

我更喜欢解决问题，而非单纯的磨练技艺。（我唯一希望自己磨练技艺的点可能是游泳了吧）

那么对于我这样的人 —— 这个大时代下，被效率裹挟，随大流的普通人。既然无法完全放弃 LLM 与 FSD，那么我们应该注意什么呢？

我有以下几点浅薄的建议：

  1. 对于 FSD，你要清楚自己不是用户，而是测试员。你要做好随时自驾的准备，且必须具备这样的技能。
  2. 对于 Cursor，架构你得自己想清楚，如果整个应用的都是它独立创造的，那么你可能会收获一个暂时能跑的屎山，终有一天失去对其的掌控。
  3. 对于 ChatGPT（or other 聊天类 LLM），你得清楚，它是你信息搜集的新工具（类似历史上的搜索引擎与互联网），但绝不能代替你思考。
  4. 细节有 LLM 来实现了（具体的函数、算法的实现），那么你一定要把省下的精力留给对原理的探索上，至少它是如何实现的，必须得看明白，且透彻理解。
  5. 工具可以让你走的更快，但往哪走，以及能走到哪里，它永远帮不上忙。

额外的一些启发：

https://royalicing.com/2025/test-driven-vibes

测试驱动我觉得非常非常适合 LLM Coding，但测试用例的确得完全有自己来设计清楚。这一点在 golang, python 中尤其方便。

更多高阶技巧:

https://manuel.kiessling.net/2025/03/31/how-seasoned-developers-can-achieve-great-results-with-ai-coding-agents/

启发：

  • 把架构设计也写在代码的 Markdown 中（可能来自于你与 LLM 的多轮对话），然后亲自整理概括，明确目标与规范。

如: https://github.com/dx-tooling/platform-problem-monitoring-core/blob/main/docs/REQUIREMENTS.md

起名叫 REQUIREMENTS.md 或者 SPEC.md 我觉得都很贴切。里面大概包含这些内容：

  1. 需求是什么（必须明确，清晰，一句话说清楚输入输出）
  2. 用例设计与背景信息（前因后果，业务流程现状）
  3. 功能要求
  4. 架构要求：技术栈，限制，性能要求
  5. 格式化、规范化
  6. 更详细的模块设计（每一个模块的输入、输出、职责）
  7. 代码质量要求与实践
  • 工具的保护

如: https://github.com/dx-tooling/platform-problem-monitoring-core/blob/main/Makefile

创建这样的 Makefile，供 LLM 使用。做好格式化、lint、各种静态扫描。

  • 接口要自己定
  1. 命名
  2. API 设计
  3. 核心代码框架先自己写出来