https://caio.ca/blog/what-coding-is-starting-to-lose

另一篇

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 写很快。”

最终做了一大堆项目当前阶段根本不需要的功能，致复杂度、工期和维护成本越来越高

使用 Ruby 实现的语言，最有名的应该是 Crystal 啦！

当然，那是很多年前了，后来 Crystal 就实现了自举，使用自己编译自己了。

但是初期，就是 Ruby 写的，然后交给 llvm 生成执行文件。

所以，DHH 来中国宣发，让你用基于 Arch 的 Omarchy, 我这十来年了，都忘记病毒长啥样子了。

superman 是一个好名字，哈哈

还有个问题，希望大家群策群力，帮忙想个名字。

我希望将这款工具发布到各大发布版的包管理系统，但是原始 Ruby 版本的维护者已经注册了 procodile 这个名字。

原始 Ruby 版本的维护者不活跃，我联系不倒他，我在考虑，是不是换个名字。

有好的建议吗？

好巧不巧，今天刚好有人在 Crystal 论坛提及 mojo.

https://forum.crystal-lang.org/t/mojo/5627

好久不关注排名了，大感意外，竟然超过了 BASH, Elixir, Erlang.

这个薪资，还要求 <口语流利必须流利（不要求口语多标准，只要能够互相听得懂，互相谈笑风生就没问题）>, 个人认为只能招一些菜鸟程序员了。

当然，也可能是我不太了解现在的行情，毕竟欧美大厂都开始裁人了，僧多粥少，卷的很。

但是我是有比较的，六楼提到的那家公司，我之前工作了一年多，按照那时（19 年的标准），比这家公司好很多。

話說在那條推上看到了熟悉的 ID……

难道楼主说的是我？哈哈

似乎 Rails 6 的 ClassLoader 抽成接口所以可以替换了。

是的，好像有一个配置，可以选择使用老的 Module#const_missing 实现和新的 zeitwerk 采用的 Module#autoload 实现。

扯个题外的，我之前和 @dsh0416 讨论利用这个和 Bootsnap 的原理做 Ruby 代码的预编译，甚至加上简单的 AES 加密，用来保护外包之类项目的源码

👍

自己的简单介绍换成了英文。

抱歉六年半后，挖了我自己坟贴 ......, 前几天在网上找到了一段 10 年前的 blog 文章，发现了解决类似问题的 lisp 代码，然后今天改了改，现在工作的蛮好，有用到的请自取吧。

@msg7086 , 我承认你说的大部分都是对的，反倒是我第一时间看到你的观点时，对你的有些话有些误解，这里我道歉。

其实我也用很多 GUI 工具，dbeaver 用来连接数据库，beyond compare 用来目录同步，文件比较，只是更倾向于不依赖于这些工具而已，可能是目前我的操作方式够用，没有更多的需求的缘故，如果到那个地步，又有足够易用的，让我心动的工具可用，我也会选择他。

对了，你提到你用了 update_base dev，请问这玩意儿支持 3-way merge 吗？能做成左 + 中+右 diff 界面吗？能高亮显示段落差异和行内差异吗？

以前用 Beyond Compare 执行 3-way 合并，现在也会在提交代码前，用这个工具 code review 一遍。

但是后来发现，其实不好用 (可能 bc4 这方面比较弱吧，常出错), 最快的方式反倒是直接用编辑器逐个文件编辑来的最快.(这也是 Ruby China 社区一个大牛曾经提醒我的，直接搜索 <<<<<<, 自己编辑解决冲突，效果不错)

本来只是来顶楼主小哥的，没忍住，歪楼了。

我不完全是这个意思，但是我觉得该说的我已经说了，能理解的人也应该已经理解了，不能理解的人不管说什么大概也不会理解，所以我不想再翻来覆去重复那些话了。如果大家想继续讨论的话当然没问题。如果有人还想杠的话我就直接 Block 得了。时间宝贵，不想浪费在无谓的争吵上。

我的观点是任何一个对 Git 有比较复杂需求的人都应该用 GUI 辅助而不是裸撸 CLI，从来不会犯错而且手速飞快 or 闲得没事干的人除外。

困了，睡了。

好吧，本来不想再说了，因为很多原因，我虽然加入 Ruby China 好几年了，也不常来，但是实在是不能忍了，从一开始，你定调的口气

Git 你需要一个牛逼的 GUI。光用命令行，几乎干不了什么复杂的事情。

我觉得就已经把整个 Ruby China 社区受众的理解能力的 level 降低了不止一个档次，这种话如果你实在一个 巨硬 产品主导的社区发出来，可能会大受赞赏，但是却偏偏在一个命令行操作挺多，而且 Ruby 语言本身其实和 CLI 很有渊源的一个语言之上谈这个，就有点小瞧社区的大众了。

我说的是 用命令行，几乎干不了什么复杂的事情，主语是人，说的是人类的能力无法达到充分利用命令行赋予的功能。

我只能说越解释越黑，很明显你也拉低了 linus 的智商，你写这么复杂的 git 功能干嘛？是让人用的吗？

但是我觉得该说的我已经说了，能理解的人也应该已经理解了，不能理解的人不管说什么大概也不会理解，所以我不想再翻来覆去重复那些话了。

我真的觉得，只有你自己在认为，和你争论的这些人不理解。

如果大家想继续讨论的话当然没问题。如果有人还想杠的话我就直接 Block 得了。时间宝贵，不想浪费在无谓的争吵上。

好吧，也许你时间宝贵，但是你不这样自我的将自己的那一套 GUI 工具当作使用 git 的救世主来这里传教，没人愿意花费时间和你争论。

请问你最后的图每次合并分支都是通过 rebase 吗？能分享下你们是按照怎么样的流程走的呢？

这位小哥，我猜的没错的话， @msg7086 在合并代码前，会要求 feature 代码的开发者，做 rebase 然后重新强推一下。

假设，你要合并 feature/new_feature 到 dev 分支，你需要首先 checkout feature/new_feature 分支，然后运行 update_base dev(参见之前回帖写的那个函数), 解决冲突 (如果有), 然后强推 git push --force origin feature/new_feature

emacs 的 magit 算 git 的 GUI 吗？

这玩意儿超级强大的，因为太强大，所以我一直没敢用，还在用一个很老的包 (git-emacs) + 自己的 hack,

我说的是 用命令行，几乎干不了什么复杂的事情，主语是人，说的是人类的能力无法达到充分利用命令行赋予的功能。

感觉这个还是反的，最复杂的事情，都一定要通过命令行来自动化，如果 git 的标准命令你觉得有点麻烦，你可以写个 bash wrap 起来，我自己写了大把的类似的脚本，只是为了让我操作 git 时提供便利，这就是为什么有了 git, 还有 git-flow, 有个 docker, 还有 docker-compose.

客观而不带任何偏见的讲，如果你的话是对的，Linux/BSD/Unix 真的没有存在的必要了，每个人工作方式不一样，你喜欢 IDE, 习惯工具，却认为别人用命令行干不了复杂的事情，有点以偏概全了。

为了增加信服力 (不是我信口雌黄), 贴一下 git 相关的脚本目录：(虽然不是每个脚本都常用，其实就是心血来潮，写个脚本，当作笔记而已)

 abort*               cob@       fork*    gitb*                      gitdiff@                    gitll@                         gitv*           push*           skip*
 add*                 cofile*    fork1*   git-bcompare*              gitdiffc@                   gitls*                         gitzip@        'push!'@         stash*
 add_key_to_github*   com@       gc*      gitc*                      git-diff-wrapper*           gitls1@                        merge*          rebase*        'stash!'@
 anno*               'com!'@    'gc!'@    gitcat*                    git_find_big_files*         gitm*                          merged*         rebase_log*     stashp@
 clean*               commit*    gca@     git_clean_merged_branch*   git_find_blob_commit*       gitrm*                         merge_dev*      reflog*         submodule*
'clean!'@             cont*     'gca!'@   gitcp*                     git_find_dangling_object*   gits*                          merge_ours*     remote*         swap*
'clean!!'@            cor@       gcp*     gitd*                      git_find_delete_file*       gitsize*                       merge_theirs*   reset*          track*
 clean1@              cov@       gd@      gitd1@                     gitfsck*                    git_squash_branch_to_commit*   mergetool*     'reset!'*        unreset*
 co*                  drop*      gd1@     gitdc@                     github_create_repo          gitss*                         pop*            show*           up*
'co!'@                fetch*     gdc@     gitdd@                     gitinit*                    gitsub*                        pull*           shown*          upa@
 coa@                'fetch!'@   gg*      git_delete_big_files*      gitl*                       gittar*                        pullups*        show_restore*

再贴的你应该懂的最常见的命令：

function update_base () {
    branch=${1-develop}
    git checkout "$branch" &&
        git pull origin "$branch" --rebase &&
        git checkout - &&
        git rebase "$branch"
}

咳咳，我觉得你说的的确是反的，只有 UI 做不到的，没有 命令行做不到的，UI 都是调用命令行。

下面是普通的 git 命令行输出，不是一样有你截图的效果？(添加 --graph 参数即可)

 1  *   16299e9 - (HEAD -> develop, origin/develop, origin/HEAD) Merge branch 'release/1.6.0' into 'develop'(29 hours ago,tracy)
 2  |\
 3  | * 38cd519 - (origin/release/1.6.0, release/1.6.0) 🐛 修复feed物理删除引发的问题(29 hours ago,tracy)
 4  | * b890266 - Fix clazz.grade bug(30 hours ago,Billy.Zheng)
 5  |/
 6  * c9efa4f - update graphql_controller(31 hours ago,Billy.Zheng)
 7  * 54142be - refactor graphiql_basic_auth(31 hours ago,Billy.Zheng)
 8  *   1fd379a - Merge branch 'feature/update_1.8' into 'develop'(31 hours ago,Billy.Zheng)
 9  |\
10  | * 2c408a8 - (origin/feature/update_1.8) comment test(31 hours ago,Billy.Zheng)
11  | * 6417971 - refactor feed_connection(31 hours ago,Billy.Zheng)
12  | * 32e8141 - Fix test(31 hours ago,Billy.Zheng)
13  | * 738b3be - Add schema.grahpql(32 hours ago,Billy.Zheng)
14  | * 74a538a - delete recruit_image api(32 hours ago,Billy.Zheng)
15  | * 0aaa961 - delete delete_image api(32 hours ago,Billy.Zheng)
16  | * 8ee8140 - update fields to 1.8(32 hours ago,Billy.Zheng)
17  | * 54b3428 - fix query name(32 hours ago,Billy.Zheng)
18  | * b7a59f9 - remove all require in graph folder(32 hours ago,Billy.Zheng)
19  | * 19553b6 - replace @context to context(32 hours ago,Billy.Zheng)
20  | * 456cfa6 - replace @object to object(33 hours ago,Billy.Zheng)
21  | * 03789db - remove loaders require(33 hours ago,Billy.Zheng)
22  | * 38457a6 - update enums(33 hours ago,Billy.Zheng)
23  | * d8fab81 - move global constant to initializer(33 hours ago,Billy.Zheng)
24  | * e909d23 - Update sequel config(33 hours ago,Billy.Zheng)
25  |/
26  *   f508b67 - Merge branch 'release/1.5.0' into develop(33 hours ago,Billy.Zheng)

这个帖子必须支持！

我们也招聘 Ruby 工程师哦。

https://ruby-china.org/topics/34607

针对公司 Ruby 方面的技术细节，我再做一些补充：

1. 我们毫不吝啬的，并且持续不断升级或使用最新技术，GraphQL, Sequel(更快的 ActiveRecord), Rails 5.2 哦。
2. 我们使用 TDD(虽然不见得总是测试优先), 开发过程中，代码持续重构进行中。
3. 我们正在逐步拆分到微服务架构，因此，会有很多机会，拆分出一个单独的项目或 Gem, 独立部署，独立运行。

我们是一家很新的公司，虽然我们开发进度很紧张，但是 TEAM 每个人很有活力，遇到问题也决不妥协，不将就， 加入我们，你一定你会有一种不一样的感觉。

欢迎大家踊跃面试交流哦！

支持一下！

酷酷酷～ 说得真好！

报名。

就我了解，以及这几年所见，绝大多数人是不肯在编辑器上多花时间的。

我是用了多年之后，把一些之前高度定制的快捷键回归默认了，但这绝不是因为默认的好，只是考虑在别人机器上操作，线上部署，等等一个折中操作尔。

最后说一句，你竟然不 map capslock 和 Ctrl，👍