iintothewind

@deplives thumb.db 和 desktop.ini 跟.DS_store 一样每个文件夹里面都有吗？
windows defender 能删除，kernel_task 你给我删一个？
windows 升级后对 app 兼容性比 mac 可好太多，mac 还想碰瓷这个？
没错，windows 不仅有安装反安装专用界面，连 winget 都是官方的，homebrew ？
我没说 powershell 好啊，咋的 powershell 做的差能证明苹果那套 genu 就好用？
windows 还真有安装反安装功能，苹果就是没有，你说破天就是没有啊，
PC 还真有很多软件是 x64 的而且无论从数量还是种类都不 arm 平台多，你这样反问倒是挺能颠倒黑白的。
你这是专业抬杠啊？

其实难用的是下面这些:

.DS_Store 满天飞：到处都是，永远清理不完，git 提交时总得手动删一遍

Finder 就是个摆设：终端根本不适合开发，还得配一堆第三方工具才能勉强用

kernel_task 发疯：CPU 占用突然飙到 100%，根本不知道它在干啥

强制升级地狱：过 1-2 年就逼你升级，兼容性问题一堆：不升则新应用打不开，升了旧应用又崩溃

没有 Homebrew 就是裸奔：macOS 的软件安装体验是个毛坯房，各种 pyenv 、nvm 、rbenv 搞得乱七八糟

bash 不是 GNU-Bash：跟 Linux 完全不通用，alias 、history 的行为都不一样，命令行工具经常要改参数

App Store 的封闭生态：不在 App Store 里的软件就不算"应用"了吧？而且 App Store 里好用的必须付费，免费的肯定有广告，又好用又免费的几乎没有

没有真正的卸载：装个软件，卸载后一堆垃圾残留，还得手动去/Library/Application Support 里清理

ARM 架构的坑：很多 x86 软件跑不起来，或者只能用 Rosetta 转译，性能损失严重

闭源驱动不支持：打印机、扫描仪、USB 设备经常识别不了，还得专门去找驱动

标题和正文对不上。

少调用和并行是两条不同的优化思路：一个靠减少交互次数，一个靠单回合批量塞活。前者省往返，后者省的是串行等待、代价是单回合决策变重。你标题要前者，正文吹后者，俩叠一块，既不省决策也不省理解——到底想优化哪头？

感觉逻你的引流简述的逻辑有点混乱,就不想点开看了.

是谁这么想在赛博炼狱享受永恒折磨呢?

我觉得按一辈子的长度的话, 100w 其实不多, 但是你真的有 100w, 对普通人, 那可是不少的钱了. 而且是单身一个人, 想躺平一会怎么就不行, 躺平又不是进棺材, 中国人也不是只能有一种活法.

个人理解的,agent 设计上 工具能力的优先级排序，

**我的排序：build-in tools > Skills > CLI > MCP**

几个理由：

**1. build-in tools 理应最高优先级**

Agent 的 built-in tools 是它的「母语」—— 调用约定、返回值结构、错误处理全是原生默契。如果 built-in tools 在性能、token 效率或可操作性上不如外部方案，那该反省的是 Agent 本身的实现质量。作为使用者，如果发现一个 Agent 的 native tool 能力弱到需要频繁绕道外部工具，可能该考虑换个 Agent 了。当然长尾领域不可能全部覆盖，这是现实限制，但当 native tool 能覆盖时，优先用它。

**2. Skills > CLI**

Skill 本质上是经过提纯和定制的 CLI 能力 —— 把 CLI 用法、参数说明、输出格式、注意事项打包成一个按需加载的 markdown 文件。它比裸 CLI 多了「怎么用」的说明，Agent 读一次就知道怎么调，不需要试错。所以它优先于 CLI 。

**3. CLI > MCP**

CLI 虽然不完美 —— 非结构化输出需要 Agent 自己 parse 、管道链组合对模型推理能力要求高、交互式 CLI 基本不可用 —— 但至少轻量，不需要常驻进程。MCP 的问题在于：
- 全量 schema 灌进 prompt ，上下文膨胀
- 需要后台维持 server 进程/连接
- 很多时候你只想要一个 tool ，但一装就是一整组

MCP 的理论优势是标准化和动态发现，实际代价偏高。

**CLI 内部也有分化**：带 `--json` 输出的 CLI 接近 MCP 的结构化程度；管道链组合对模型是认知负担，因为没有类型检查的「胶水代码」；交互式 CLI 基本跟 Agent 无缘。

**MCP 不算完全鸡肋**，有一个 Skills 和裸 CLI 都做不到的事：返回结构化类型数据，Agent 不需要从文本里 regex 提取结果。但它的适用场景更偏向「动态变化的数据源」（实时 API 、数据库查询），而 Skills 更适合「静态固定的操作」（特定 CLI 工具的用法）。两者场景不完全重叠。

---

跟主楼的关系：这不算反驳，更像是补充一个执行层面的视角。主楼分析的是某些 Agent 产品实际上怎么处理冲突（工具名覆盖、注册表优先级），上面说的是我个人理解的在 Agent 设计上应该怎么定优先级。两者可以对照着看。

白妞谈恋爱玩玩可以, 结婚尤其是不能带回国内的, 大概率男人会很惨.
就我观察, 和白妞结婚, 能 10 年以上, 能存住钱, 好好过日子的, 反正身边我是没见着.

@moudy #11 我觉得这个视频作者借那个小女孩问的问题:
Did you decide what it tastes like?
Did you decide what goes in it?
Did you decide what it looks like?
是想说明, 你应该关注的是交付物(Deliverables)的质量, 而不是工具和制作过程.
因为很简单, 写代码这件事情因为生成式 AI 的发展使用 coding agent, 这是既成事实.

你如果真的在意, 你就应该更加关注最终结果, 你改变不了工具和只做过程已经改变的既成事实.

这个问题可以无限延伸, 直到那个无解的哲学问题, 就是到最后生命的存在形式(碳基和硅基)以及人的主体性问题(工具太强大导致人的主体性丧失).

不想简单的回复,也不想阴阳怪气,引用一个视频吧,我认为能反应当前 AI 创作的现状, keep cooking:
https://m.youtube.com/watch?v=C4d9csB5mLg