Hi there 👋, this is a place where I share things with the world.

简介 从头到尾过了一遍OpenClaw作者的访谈(https://www.youtube.com/watch?v=8lF7HmQ_RgY)，其实有很多点感觉都还挺有意思的，用个AI工具能把大纲都总结出来，我就不重复工作了。实际上我觉得前面一段讲述个人经历，以及体现出的一些对人生和社会的理解，也蛮值得品味品味的，不过还是把重点放在「生产力」上，谈谈我对Peter如果使用AI实现爆炸性生产力提升（一天能提600个commits）的理解，篇幅应该不会太长，可能会有从「道」到 「术」的理解递进。当然这个访谈里也有很多Peter其他观点以及这个项目本身的愿景，这些我们持保留意见，暂时不做讨论。 人的主观能力性 其实我觉得这个才是最重要的 愿意思考 保持好奇心和热情 持续学习 不怕犯错 … 有这些属性的人才有可能对真正提升生产力有追求，不然我们再怎么追求「工具」、「方法论」、「最佳实践」都是没有用的。 因为世界在不断变化，我们面临的问题也在不断变化，这个世界唯一不变的就是变化，只追求表面上的东西很可能演化成巨大的流程或技术债务，让大量生产力浪费在没有意义的事情上。 聚集有共同理想的人，并创造利于培养/保持这些品格的人的环境，其实可能在组织/公司上，可能才是最重要的。 道：开发模式的转变 最重要的，Peter认为开发模式应该有一个转变，从传统手写，到Agentic Engineering，我理解为基于Agent的整套工作流，而不只是编码本身。 如果只说编码，实际上我们平时做的大量工作是「缝合代码」，用他的话来说，是「Plumbing Code」，这部分工作其实大量是纯粹的苦活，完全可以由AI来搞定。 但目前的LLM，最大的问题就是它们是概率模型，对输出的结果的「正确性」无法保证，那么我们怎么提升Agent的协作与生成效果，减少频繁的返工和堆屎山呢？他说他最大的技巧在Close the Loop，即「闭环原则」上。 代码场景之所以现在比较火，是因为这个场景更容易构建compile-lint-execute-verify这一整套闭环，让AI自己在实现一些功能后，自我验证、发现错误、迭代修改，不断循环，直到事情完成。 普通小白当然感受不到这个，但他们其实可以通过现在的AI工具了解这些东西，取决于人是否愿意思考、愿意学习，门槛真的没有那么高，可惜自媒体们忙于夸大事实和割韭菜，并不会说这个。 在这个基础上，他建议我们改变一些思维方式，从一个代码的编写者，转变成为架构和系统的思考者（但用他的话来说，他更愿意用Builder这个词而不是Architect）。 所谓的不review代码，并不是真的一点都不看，而是不一行行看代码的具体实现逻辑，把正确性的保障尽可能交给「闭环」。 而我们作为Builder，应该更认真去思考架构，如何设计测试，如何指导AI让他们生成合理的测试，如何对工具层下指令等等等等。 这些是真正的Skill Issue，在以前人主力编码的时代也是存在的，只是Manager和所谓的架构师们根本不care，出问题了就让干活的人背锅。 现在生成式AI的大发展给当前的生产关系带来了冲击，这些问题会被摆到明面上，以更深刻的代价来冲击组织架构、交付方式等等。我们需要让自己能够「放手」，让方向/架构本身不出现问题，而不是纠结于一些细枝末节。 而问「对的问题」的能力，是需要人的主观能动性的。 不断学习，实际上和LLM/Agent不断对话的过程，也是一个学习的过程。我们会在学习过程中不断修正自己对系统的理解，大模型也是一样的。 这也是他认为所谓的spec driven可能行不通的原因，它就像是人类软件工程以前的「瀑布模型」。用他的话来说： “How can you even know what you want to build before you built it? You learn so much in the proess of building it that will go back into your thinking of how the system actually will end up being. ...

许多水平很高的人，都对AI Coding抱有更客观的态度 像Geogre在他的这篇博客上提出了和tsoding在X上发的 一篇推文发表了类似的观点，即LLM只是更差的编译器而已，而自然语言（这里主要是English）是非常差的「编程语言」，所以他们不看好， 但这并不代表他们完全不看好AI的发展。反而是有些日常只做着平庸工作（不等于不挣钱）的人，只会重复纺织机与旧纺织工人的故事， 嘲笑别人不会使用「先进工具」 I’m not against AI at all, I’m pro recognizing its strengths and limitations as a tool, and once you do that, if it makes sense for your workflow by all means use it. I also think AI will continue to improve at a careful and steady pace. What I’m against is hype. 这篇文章本身不长，也没有用很多高科技词汇（刻意为之的），并不难理解，推荐去读一下，随便摘录几句我觉得值得思考的 In my old age I’ve mostly given up trying to convince anyone of anything. Most people do not care to find the truth, they care about what pumps their bags. Some people go as far as to believe that perception is reality and that truth is a construction. I hope there’s a special place in hell for those people. ...

在2025年的今天，「AI」作为一个概念实在是太火了，所有人都在讨论LLM和AI，不同的人观点也不一样：乐观的、悲观的、利益相关的鼓吹、真正考虑AI作为生产力的、对自己的生产任务有着深刻认知的、在编码/软件编程领域只是初步体验的。我不想说谁对谁错，只想尽量中立地列几点自己的一些想法，没有什么逻辑，可能涵盖多个立场 AI作为新工具，确实能很大程度上帮助我们提升一些效率，我确实经常使用 模板文章 次抛脚本 文档格式整理 对话激发灵感 接触新领域 简单给自己的产品出个可用的前端 …. AI或许可以帮助人类（特别是牛马们）更深刻地思考生产力、效率、生产关系与幸福生活的关系，在更长远的时间范围内，激起社会变革，哪怕它如《全球通史》所说的，经常落后于技术变革 「生产力」提升了，毕竟目前的生成式LLM更的很擅长「流畅地生成一些看起来正确的东西」，你的效率真的提升了吗 哪怕效率提升了，你真的更早下班了吗，挣更多钱了吗 你真的在AI的加持下，离自己的梦想、或者梦想中的生活更进一步了吗 AI这个概念被窄化和炒作的太多了 AI不等同于生成式AI，更不等同于LLM大模型 现在的LLM，我仍然不认为它具备真正的「推理」或「思考」能力。它或许很擅长从语料中发现一些「模式」(pattern)，这些模式的表现形式远远超过传统机器学习/模式识别所能做到的，但这应该不是所谓的「智能」，除非你认为，擅长模仿就等于更高的智能 拿LLM产出的东西作为圭臬，包括但不局限于解决一些特定领域的问题、上网和人对线等等 AI在软件工程上的应用 软件工程并不仅仅是编码，还包括用户需求理解、沟通、测试、集成、性能优化、迭代等等等等，目前的AI显然不能全部做到 如果一个项目只有你一个人维护，你自己对整个项目负责，那么完全没有问题；不然的话，就不要让AI快速拉💩然后让别人去擦，这是对项目里的其他人非常非常不负责任的行为，也是对产品不负责任的行为 所谓Vibe Coding，如果你接受Vibe后就要一直Vibe，一直给Anthropic/OpenAI们持续送钱的同时，自己一步步失去去项目的理解（功能、安全性、性能等等），那当然也没问题，我只能说: Good Luck… AI是要用数据训练的，人们是真的不在意自己的数据被随意获取和利用啊… 谁真正用AI挣到钱了 老黄、卖课的 哪怕是OpenAI/Anthropic等等，现在也正处在烧钱的阶段 独立开发者的作品们，且不说有没有实现盈利，就算实现了，它真的是「AI」相关的功能带来的吗

前言 仅做简单记录和对比 X11 + i3 双显示器的切换支持非常好 i3 会默认将workspace 1 放在primary显示器上，2放在另一个显示器上，当然你也可以通过i3 config进行自定义的设置，不配置的话，默认行为类似： workspace 1 output <output 1> # <output 1>为你想workspace 1放置的显示器 workspace 2 output <output 1> 通过切换workspace在各个显示器间切换时，鼠标也会跟着进行聚焦，非常方便 可以用arandr工具进行图形化的配置与指令生成，它是xrandr的一个GUI封装 高分(3840x2160)支持一般 通过设置~/.Xresource 里的Xft.dpi: 192来进行4K显示器下合适的缩放，但是: 所有显示器都会使用一样的dpi设置，也就是你的内建显示器如果原本是一个分辩率没那么高的屏幕，字会变得很大 不是所有应用都遵循一样的缩放原则，比如你可能要单独设置GDK_SCALE或QT_SCALE_FACTOR等环境变量来指定缩放比例，或者像Firefox/Chromium这样的应用都提供了图形化或者启动时传递参数的办法，指定缩放倍数，如--force-device-scale-factor=1.5等等。根据你使用应用所使用的GUI框架，可能要按需设置 不支持分数缩放(fractional-scaling)或支持得不好 通过xrandr --output xx --scale 0.5来进行缩放，全局会放大，但是应用内的渲染，像文字什么的，很可能经是有点糊的 如果对高分的设置有较强的需求，可以考虑使用Waylnad 如swaywm, Hyprland等。 Wayland是更先进的图形协议，正在不断发展，老的X11架构支持很有限了。 但是Wayland目前可能还有一些兼容性问题，例如对N卡的驱动支持上面，如果是N卡场景或者是用XWayland进行兼容的话，有时候性能可能还没老的基于C-S架构的X11好，按需使用吧。 我的配置文件仓库 https://github.com/ChaosNyaruko/dotfiles

主要参考资料 Arch Wiki: Fcitx5 Arch Wiki: Rime Rime Wiki 安装fcitx5 fcitx, ibus也可，后续的操作思路应该是差不多的，可能目录和一个GUI的包有差异，但我没有尝试，fcitx5应该是最新的吧 $ pacman -S fcitx5 fcitx5-qt fcitx5-gtk fcitx5-rime fcitx5-configtool 启动fcitx5 ，并设置启用Rime 在/etc/environment 或 ~/.pam_environment 中 设置环境变量 我使用X11+i3，不同的桌面环境需要设置的不一样，具体参见Arch Wiki: Fcitx5 或Fcitx官方Wiki GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx XMODIFIERS=@im=fcitx SDL_IM_MODULE=fcitx # 如果你使用基于SDL2的应用，主要是游戏的话，设置这个 GLFW_IM_MODULE=ibus # 据说只有用kitty才有可能需要设置这个 完成基本设置 最好是重启你的桌面环境或系统，这时候应该就可以在各个应用里使用输入法进行中文（或其他语种）的输入了 五笔支持（其他方案同理） 下载或用pacman安装rime-wubi 为你的Rime增加新的schema，通常为将你的schema和dict文件复制到~/.local/share/fcitx5/rime/下(ibus/fcitx可能是~/.config/rime/fcitx(ibus))，并在default.custom.yaml的scheama_list段落下插入schema: wubi86。如果你还需要其他输入方案，例如拼音，在后面增加就好了。 修改完后，重新部署Rime(比如点击托盘->Deploy) 你可以使用ctrl+`来切换不同的「输入方案」，各种快捷键都可以自定义 文件结构示例: Rime ├── default.custom.yaml #自定义修改主文件 ├── emoji_english.schema.yaml #emoji方案 ├── extended.dict.yaml #emoji码表 ├── wubi86.dict.yaml #86五笔的码表 ├── wubi86.schema.yaml #纯86五笔方案 ├── wubi_pinyin.schema.yaml #五笔拼音方案 └── wubi_trad.schema.yaml #繁体五笔的方案 # default.custom.yaml 文件 patch: schema_list: # 對於列表類型，現在無有辦法指定如何添加、消除或單一修改某項，於是要在定製檔中將整個列表替換！ - schema: wubi86 - schema: luna_pinyin - schema: emoji_english 设置fcitx5自启 我是在i3配置里加了一行，视你使用的发行版/桌面环境自行决定 ...