@ligogid 微软的设计还是很有品味吧，只是 Win11 之后越来越印度化了。Windows Vista 和 7 的 Aero 、Windows 8 和 WP 的 MDL 、Windows 10 的 MDL2 和 Fluent Design （ Acrylic ），我个人感觉都是很有设计感的。

倒是 Google 的 Material You 跟中毒了一样，相比 Win11 的印度化有过之而无不及，连基本的耐看都做不到。

@AlynxZhou #60 感谢大佬亲自推荐。

我今天又研究了一下 Krdp 的问题，基本可以下结论：Krdp 在使用 KPipeWire 编码视频时，如果检测到 libva 的存在就会强行使用硬件编码（即使硬件不支持 H.264 编码），于是导致黑屏和断连。

可以安装 openx264 并给 krdp 服务添加环境变量 KPIPEWIRE_FORCE_ENCODER=libx264 来指定软件编码，从而解决黑屏问题。缺点是画面操作延迟会变得很高。不过算是勉强能用了。

我试用了一下 ReFrame ，似乎连接时会报错 Input: Failed to open uinput: No such device 然后 coredump ，不知道是什么原因？完整日志： https://0x0.st/PX89.txt

这是个连续谱啊。

- 只用 IDE 的传统智能补全算什么？
- 只用本地模型行内补全算什么？
- 只用 copilot/cursor 行内补全算什么？
- 只用 LLM 编辑单文件、生成代码片段算什么？
- 公司项目全手写，个人项目用 agent 算什么？

不提建议，纯来发牢骚。

Wayland 权限管理真的做得一坨，全靠 XDG Portal 来处理投屏，后者各家 WM/DE 的实现又基本没考虑过授权状态的存储，结果就是：Wayland 下除了第一方实现，基本没几个三方软件可以做到无人值守的远程控制。

别说 KDE 的 Krdp 了。今天试了一下 Krdp + aFreeRDP ，连接之后一直黑屏，但鼠标可以控制，过了一分钟左右就自行断开连接了。2026 年了，唉。

13. 那些成就他人工作的“幕后工作”虽然无价，却往往也是隐形的。

“胶水工作”（ Glue work ）——例如编写文档、新员工入职引导、跨团队协调、流程改进——是至关重要的。但如果你只是无意识地去做这些事，它可能会阻滞你的技术成长路径，并让你陷入职业倦怠。

这里的陷阱在于：你仅仅将其视为一种“助人为乐”，而不是将其视为一种经过深思熟虑、有边界且清晰可见的“影响力”。

你需要给这类工作设定时间窗口。尝试实行轮岗制。将其转化为实际的产出物：如文档、模板或自动化工具。

最重要的是，要让大家清楚地看到这是切实的工作成果，而不仅仅是「因为你的“性格好”，所以写文档」。

14. 如果每一场争论你都赢了，你可能正在积累无声的抵抗。

「人们不再反驳你，并不是因为你说服了他们，而是因为他们放弃了尝试」——他们会在后续的执行过程中，而不是在会议上，表达这种异议。

真正的“目标对齐”需要耗费更多时间。你必须真正理解他人的视角，吸纳反馈，有时甚至要公开修正自己的观点。

17. 你的职业人脉，比你任何一份工作都更长久。

在职业生涯早期，我只顾埋头工作，却忽略了经营人脉。回过头看，这是一个错误。

「工作不会伴随你一辈子，但人脉会」。在经营人脉时，请怀揣好奇心与慷慨，而不要带着功利性的交易心态。当你要开启职业生涯的下一段旅程时，往往正是这些关系为你敞开了大门。

深有同感。

@w568w 修正：

1. Ghostty 不支持 Windows ，记错了

2. ConEmu 有个包装版本叫 Cmder ，带了一些 Bash 环境常用工具，可以看看

3. WezTerm 主要支持了快捷键、多标签页之类的功能

Windows 下的第三方终端有非常多的问题，尤其是 ConEmu ，作者修了十几年越修越坏，各种 DLL Hack ，都修破防了。

只有 Windows Terminal 自家的最稳。右上角把 Bash 配置为 Profile 就行了

要找纯裸终端的话，看看 Ghostty （ Zig 写的）或 alacritty （ Rust ）

要找功能稍微完整一点的话，看看 WezTerm （ Rust ）

@wfg 是一样的。Android 这边是截图时提示当前页面禁止截屏，录屏时变为黑屏。

推荐阅读： https://davekilian.com/acquire-release.html

省流：余额 <= 30 刀不予提现

sublime text 感觉实在没什么人用了。

作为 IDE ，插件生态远远落在 VSCode 后面，启动流畅性比不过 Zed ；

作为编辑器，资源占用比不过 CudaText ，启动速度也不如 Windows 记事本、Notepad2 。

而且以上列出的所有竞争对手都是免费且开源的，Sublime Text 还收费 99 刀，拿什么比呢。我最后一次用 Sumlime 已经是快 10 年前了。

我第一次看它的文档，有类似的感觉，因为我看了一个下午都没看懂文档在说什么，而且我自己还是专门做 AI 方向的。

和同事讨论了一下之后，LangGraph 最大的一个问题就是：它希望实现一些很 nice 的理论特性，但是忽略了给 dev 过程带来的设计困难。

比如说 LangGraph 顾名思义地把你的整个 Agent 工作流构建成一个有向图 workflow 。但是线性的代码书写方式对于构建有向图是非常 awkward 的。比如说一个循环和分支结构，正常写代码就是：

while condition {
do A
do B
update condition
}

但写成有向图会变成：

# 创建节点
a = create_node(A)
b = create_node(B)
condition_update = create_node(ConditionUpdate)
end = create_node(End)

# 添加边
add_edge(a, b)
add_edge(b, condition_update)
add_edge(condition_update, a, end, cond=lamdba state: state.condition)

# 执行图
state = State(condition=True)
output = execute(state)

哪一种方式更易读？至少在这种场景下，显然是前者。那为什么 LangGraph 要选择后者呢？主要原因是它等于把控制流委托给 LangGraph 的引擎去做，这样就能自动支持状态存储/恢复、断点续行等特性，也就是说 LangGraph 是以一种设计复杂管线的思维在做 Agent 设计。

但现在的 Agent 果真有这么复杂吗？我的理解是：

- 如果在原型设计阶段，这种图模式不合适，因为修改成本高、和状态耦合太深。

- 如果是简单的工作流，根本没必要使用图模式，就像上面的例子。

- 如果是复杂的工作流，这种模式的上限也会制约系统的上限，尤其是关于状态管理和分支处理的部分。比如现在 LangGraph 为了支持错误 Node 重新执行，又搞出了钩子和中间件，系统复杂度被拔得太高了，学习成本也直线上升。那与其用这种框架，不如自己手搓适合业务的实现。这种情况下，LangGraph 也不适用。

所以 LangGraph 在大部分场景下真的是鸡肋，有点 Spring 之于 Java 的感觉。但他的 API 都是搞 AI 的人设计出来的，这帮人的工程能力我不好点评（因为我自己也是），能达到 Spring 的水准吗？不好说。

@f1ynnv2 > vchat 刚看了一下原来是指这类
是的

> 原来 app 的自动测试框架已经这么强了可以直接操作 app 而且还是系统层面的
因为要无障碍适配必然要支持系统的无障碍接口（ Windows 上是 UI Automation ，macOS 上是 Accessibility API ，Android 上是 Accessibility Service ，等等），所以大部分平台都可以读取甚至操作应用控件。

macOS 应该好办吧，直接读通知就可以收消息了

发消息比较困难，建议搞个 UI 自动测试框架来做

有点意思，和早年 Intel 、华硕、联想出过的电脑棒差不多

没点进来，我还以为有什么灾难性的经历要分享呢。

哦，原来就 [一个特定型号] 的 [特定国产系统] 的 [相册 App] 的 [特定功能] 在 [特定极端（ 400GB 图片）情况下] 不好用。这就是你说的「对国产安卓彻底失望」？

那我看也别选了。这种文章我一天能写十篇：「买了 macBook 发现 Finder 没法直接读 NTFS ，问了客服也不回复我，只会打太极，对所有苹果产品彻底失望了」。

最后 101 块收。你们多多买多多骂，骂名我来背