响马

响马

60,044個推特粉絲

關注

。。。。。。

動態

有一個特性，我讓 ai 幫我改，我看了代碼不滿意，開始教育 ai 正確的寫法。教育了很多遍以後，我驚奇地發現，ai 最初的代碼竟然運轉很好。我仔細閱讀了相關代碼，不得不說 ai 真會鑽空子，竟然卡在恰恰好的一個狀態解決了問題。最後我偷偷把代碼改成最初的版本，沒有告訴 ai，並直接關閉了會話。

我就一直不敢走開，連它的思考都會去看，看到它胡扯就停止。所以才知道它的思考真的很扯。但是我嘗試切換到較少思考，它立刻變得更蠢了。

我发现了个极其简单但被大家忽视，却能大幅提高生产力的技巧。 AI 时代来了，Agent 虽然代替人的部分思考，但还有很零碎的部分需要人来协同。为了提高效率，我们自然而然想一个人协同多个智能体。但这往往适得其反，为什么呢？人为了协助 Agent

我一個堅決不喜歡 TypeScript 的人，都在 fibjs 裡支持直譯 TypeScript 了，寫了大半年，ai 修改和重構效率體感至少提高一個數量級。nodejs 其實也支持直譯了，但是實現的實在太慢了。

我现在所有 skills 的脚本，默认用 bun 执行，因为 bun 可以直接执行 TypeScript，不需要预先编译，这带来的好处就是如果出错了，Agent 可以快速定位到代码里面的问题，然后直接修改代码再次运行，如果是打包后的代码这就很难打补丁。任何语言或者环境，Agent 友好才是王道！ x.com/atian25/status…

我的經驗是，對於複雜的架構，文件一定要拆分。讓 AI 能根據文件名索引一個可以裝進單次上下文的自洽邏輯，比它到處拼湊然後猜測全局要穩定的多。當然 AI 自己不會主動拆分，所以我幾乎每天都會要求 AI 重構一部分代碼。

我不是完全激进地反对在 vibe coding 时代文件不需要拆分。我觉得如下两种情况是需要拆分的： 1. 这个文件中的有些逻辑是被其他地方复用的 2. 文件里面有太多状态流转了，你可以通过文件拆分来维护状态流转的边界 x.com/yetone/status/…

你沒發現 MiroFish 才是元宇宙嗎？ twitter.com/xicilion/status/20...

人類發明工具，就是為了克服自身的幻覺。ai 的幻覺是 ai 的一部分，只可能在某些方面降低，完全沒有可能消除。這就天然決定了 ai 無法作為穩定的自動化引擎。但是 ai 可以作為自動化引擎的外腦，這是 ai 擅長的能力。

我感觉这些由md文件、skill文件驱动的AI操作系统（Openclaw/Claude Code），从鲁棒性（robustness）和确定性看就是纸糊的，但它们竟然能每天还算正常的运转，真的是Oh My God。想想这和人的团队差不多，一帮互相不断误解的草台班子，但就建立了人类数千年的伟大文明。

在說一個暴論。skills 就是 ai 時代的低代碼，看起來很美，但最終還是階段性產物。確定性流程是自動化的基礎，每個環節穩定性 90%，十個環節穩定性就是 34.9%。

低代码拖拽工作流借 ai 火了几个月，还是被遗弃了。我最早了解到可视化编程可以追溯到 1992 年前后，这个东西要是效率高，程序员老早自己就用了。一个老程序员，看几十行代码，几乎扫一眼就明白了。同样的逻辑，用工作流得画两屏幕，要了解细节还得点开看。你让程序员这么干活，他能把键盘给砸了。

我特別煩 AI 的 thinking，至少從我觀察來看，Opus 80% 的思考都是在胡扯，而且是翻來覆去地胡扯。

舊話重提。現階段，AI 很擅長快速建立一個看起來很複雜的應用，以及在一個很複雜的應用裡，分析並解決看起來很複雜的問題。但是，AI 很不擅長將看起來很複雜的應用，進化為複雜的應用，或者分析並解決真正複雜的問題。

正常。大部分 markdown 閱讀器圖表一多完全卡死。我就是忍無可忍，才自己動手寫了 markdown viewer，三百多頁文檔，百十個圖表都是秒開，並實時增量更新。 twitter.com/xicilion/status/20...

Loading..