之前看到大家最近无论群里、还是社区，都在讨论 DHH 发的推，具体不在此详述，仅在此发表一点我的看法。
首先，脏活、累活，让 AI 帮我们做，效率提高很多，这个应该没有什么争议吧？
前端、测试现在让 AI 写，就算不堪，我感觉争议也不大。
我觉得，主要争议是，业务逻辑用什么语言，写的代码你自己会不会看，对吧？
这个问题分两个方面看。
- 如果你不打算看代码，什么语言重要吗？完全不重要。
- 如果 AI 写了，你还打算自己认真 code review, 后期还要继续维护，又有什么理由不采用 Ruby 这种更具有表达力的语言吗？
现在 AI 时代了，做个 一次性的小项目 用什么语言还有那么重要吗？
除非你要做一个长期维护的项目，你肯定希望选择你最熟悉的语言，当然，考虑维护，最好更具表达性的语言，而且不考虑项目，让语言自己考虑内存回收总是更省心。
仅代表我个人的观点：我认为 AI 时代已经到来了，无论你是否接受，都是如此。
但是 AI 真正比的不是：
- 你一周用多少 token
- 你一周产出多少
- 你用 AI 写代码写的多 high
而是，如果长期（在 AI 的辅助下) 维护一个项目，比如说，一个长期项目，你在 AI 辅助下开发连续开发半年，而且仍旧能保持平均效率，那才是真的牛。
所以，到了人家 DHH 的层级，就算一行代码都不看，也许真能做到呢？
让我们拭目以待。
我个人现在也在实践，在 https://github.com/crystal-china/website 开发过程中使用 AI 辅助编码，感觉速度肯定比以前快，但是真说快多少，也没觉得， 因为即使聪明如 GPT 6.1 sol, 大部分情况下写下的代码需要返工、或通过不断地交互调整，这还是在如下前提下：
- 测试我不看。 （虽然我曾经自诩很擅长 TDD, 但是这技艺，感觉基本上废了，和 AI 比甘拜下风）
- 前端 tailwind 刚开始还能 follow, 后来完全跟不上，所以现在也完全不堪，最多瞅一眼页面结构。
- Crystal 代码我会 code review, 我自知没有 DHH 那样的掌控力，需要花很多时间让 AI 拉回来，不要太飘。
- 我还会做很多重构，简单的，我自己动手，麻烦点的，那就告诉 AI 精确该怎么做，确保项目不会失控。
如果您也用 AI, 3, 4 同样完全不做，那我不发表置评，咱用 AI 的方式不一样，就像 DHH 做法一般人也 follow 不了。
但是，不得不说，实打实的一个优点，就是可以做的事情比以前多得多了。
就拿旅游来做比喻吧，
- 走路，可能只能在生活区周边几公里，
- 开车，你可以全国跑，
- 坐飞机你可以去全世界任何地方。
AI 带给我们的最大优势就是，你现在敢做、也能轻易做到很多之前 不知道怎么做， 嫌麻烦，不愿意做，没有资源、时间去做 的事情。
用 AI 就是比的一周用掉多少 token 呀，否则你定了 OpenAI Pro 账号，交了 100 美刀，用不完不是吃亏了 
AI 没有给古法程序员带来任何优势，但是 AI 强制古法程序员从更高层思考，因为底下干活已经有 AI 了。
不过古法程序员有个现在 builder 再也无法得到的技能，就是架构，或者从另外一个角度看，现在 AI 都能直接做出人类无法做出的数学题了，智力绝对是够的，但是为啥到一个具体项目，有些项目效果好，有些就是不好呢？这还是人的问题啊！你要识别出干的不好的地方，有毒的地方，给 AI 机会（这里就是 prompt+token）改进啊！
AI 会自己找问题，但是 AI 由于训练的问题，很难给人指出问题，如果 builder 看不到问题，那显然问题就无法解决咯。
半年后效率掉下去，我这边常见的不是语言选错，而是测试把一次偶然行为写成了规格。
测试不看的时候，红的会被改成绿，绿的断言其实在保护错误实现。后面改业务，先要跟这组测试搏斗，review 业务代码也拉不回来，因为 CI 站在错误的那一侧。
所以我现在不按「前端不看、后端看」来切，按「这个改动有没有一条我能讲出来的不变量」来切。讲不出来，就先让它补一个现在会失败的例子，再看 diff。语言表达力还是有用，但挡不住一套在保护错行为的测试。
https://forum.crystal-lang.org/t/what-are-you-cooking/9048/8?u=zw963
我觉得这个帖子的观点很有代表性，大概就是两个概念：
AI slop
一个 AI assistant 被优化的目标基本是：
满足你现在提出的 request。 例如你说： 帮我做一个健壮、可扩展的模块。 AI 就会认真帮你完成。
但真正的软件工程师，在项目中的价值不应该只是“帮忙写代码”。
软件工程师更重要的身份应该是：
arbiter——裁决者。
工程师应该优化的是：
这个系统经过几个月、几年演进以后是不是仍然合理。
所以两者目标其实不同：
AI：
把当前 request 做得尽可能好
工程师：
为了整个 system 的长期健康，
有时候应该拒绝当前 request 中看似“更好”的方案
而现有模型主要训练在第一种目标上。
你让 AI：
做得 robust 一点。
AI 很容易给你：
一个只有一个实现的 abstraction；
一堆实际上永远没人会改的 configuration options。
这些东西单独看每一个决定都完全说得过去。
比如：
“以后万一换实现呢？”
“以后万一用户需要配置呢？”
问题是它们不断累积：
抽象
+ 配置
+ 扩展点
+ wrapper
+ interface
+ 更多通用化
...
最后就得到：
一个没有任何人能完整装进脑子里的代码库。
这才是 pure vibe coding 很危险的地方。
引用一句法国常说的话，大概相当于
“完美是好的敌人。”
AI 在 planning mode 里非常乐意给你“最好、最通用、最 robust”的方案。
pure vibe coder 看到：
听起来真专业！
然后全盘接受。
最终却可能：
把自己的项目搞残。
即使 AI 每一次写出来的代码都 100% 正确且能运行，系统最终仍然可能很糟。
原因就是：
真正的成本不会在任何一次单独决策中爆出来。
而是：
100 个各自“合理”的决定
→ 一年后形成不可维护的系统
AI 每次只处理眼前一个决定，因此很难感受到这个累计成本。
这就是 AI slop, 通常指 AI 批量生成的低质量内容。看起来完整、漂亮，实际空泛、重复，缺乏判断和细节。slop 原意有“泔水、糊状废料”的意思，是个贬义词。
在代码和界面里，常用来形容：不顾实际需求，堆满模板化设计、冗余抽象、注释和样板代码。但不是所有 AI 生成的东西都叫 slop，重点是低质量和缺乏取舍。
feature creep.
因为 AI 把开发成本降低以后，人会不停想：
“这个也加一下吧，反正让 AI 写很快。”
最终做了一大堆项目当前阶段根本不需要的功能，致复杂度、工期和维护成本越来越高
