我在 2026-07-20 嘗試著讓 AI 去將微軟的 microsoft/markitdown專案改寫成 golang。
這是以下是個人紀錄
環境
AI
使用的 AI 是 Github Copilot 免費方案，Modal 選擇 Auto。這次是這個帳號本月第一個 Github Copilot任務
φ(゜▽゜*)♪ 很高興看到 Firefox 不再努力往AI瀏覽器前進～
Starting with Firefox 148, which rolls out on Feb. 24, you’ll find a new AI controls section within the desktop browser settings.
—Ajit Varma, «AI controls are coming to Firefox»
As our CEO beautifully puts it: "We spend our engineering time on stability and features users actually requested. Not on AI assistants that hallucinate answers, while training on your private browsing history. Novel idea, apparently." 🎯 pic.twitter.com/xKp9M1Knqv
— Vivaldi Browser (@vivaldibrowser) February 3, 2026
最近看到這兩個蠻有趣的瀏覽器新聞
- Firefox 要新增關閉 AI 的功能
- Vivaldi 還是不願意轉型成 AI 瀏覽器
✍️(◔◡◔) 紀錄一下最近用 AI 最舒服的一次經歷
拜託AI做的事是：「清理註解掉、沒有用的CSS」
這件事情的緣由是我在幫前人寫的畫面重構。
因為要改的東西很多，所以很多 code 都是用「先註解掉」的方式處理，以便我可以和原本的畫面進行對照。
在經歷過各種波折，終於改完後，註解掉的不用的 code 也多如牛毛了……(￣┰￣*)
這時拜託 AI 幫我把這些清理掉。
✍️(◔◡◔) 看到 redit 的某篇留言有感而發
Comment
byu/Ambitious_Credit_591 from discussion
inlearnpython
看完這個留言很有感
雖然很多人在那裏說 AI 取代ＯＯ什麼的
但實際上，我自己用 AI 的感覺是：AI還是有所限的，你想用 AI 寫程式的話……算了吧，大師兄……
AI如果寫簡單的東西還行。
目前用起來，最好的是幫我把已知物件轉成 interface / struct
至於寫程式，別說複雜了，有時候連簡單程式都有問題
舉幾個自己遇到的例子
- 我今天有個 javafx 的 code，但他沒用 FXML，我請 AI 幫我將之轉換，經常會改完後就出現一堆 bug
- 我的 typescript 專案，請 AI 幫我根據要求的 API 建立 function，API會寫出一個包含一堆多餘 code 的 function。例如
const response = await fetch("API URL", { method: "POST", headers: { 'Authorization': token, 'Content-Type': 'application/json', 'Accept': 'application/json', 'Cache-Control': 'no-cache', 'Pragma': 'no-cache' }, body: JSON.stringify(params), cache: 'no-store' }) if (!response.ok) { const errorText = await response.text(); console.error('無法取得資料', errorText); throw new Error(`無法取得資料: ${response.status} - ${errorText}`); } const data = await response.json(); // 檢查 data 類型 if (Array.isArray(data)) { /* 中略 */ } else if (typeof data === 'object' && data !== null) { /* 中略 */ } else { console.error('資料格式錯誤', data); throw new Error('資料格式錯誤'); }
……等等
這種情況下，你要我怎麼相信 AI 啦
連幫我省時間都做不到，還增加我時間……
┗|｀O′|┛ 9/26 發現的 Chromium Base 瀏覽器的 Bug：headless 無法擷圖
最近在用 Vivaldi、Edge、Google Chrome……等 Chromium Base 的瀏覽器時遇到一個 Bug——headless 無法擷圖
在 112 版時，Chromium 的 headless模式做了調整
根據官方文件說明（詳見Chrome for Developers: Chrome Headless mode），之所以要修改，是因為原本的 headless 模式其實是由獨立的程式執行。
這就導致有些狀況是 headless 的程式獨有；有些是瀏覽器獨有。
修改後， --headless 參數默認使用新版 headless
模式；舊版則是要用 --headless=old。
Google 有在 Chromium 有塞一條後門!?
今天看到以下訊息：
So, Google Chrome gives all *.google.com sites full access to system / tab CPU usage, GPU usage, and memory usage. It also gives access to detailed processor information, and provides a logging backchannel.
This API is not exposed to other sites - only to *.google.com.
— Luca Casonato 🏳️🌈 (@lcasdev) 2024年7月9日
This is interesting because it is a clear violation of the idea that browser vendors should not give preference to their websites over anyone elses.
— Luca Casonato 🏳️🌈 (@lcasdev) 2024年7月9日
The DMA codifies this idea into law: browser vendors, as gatekeepers of the internet, must give the same capabilities to everyone.
For those interested: this is done through a built-in Chrome extension that can not be disabled, and does not show up in the extensions panel. Source code is here: https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/resources/hangout_services/
It is unclear whether the same extension also ships in other Chromium derived browsers.
— Luca Casonato 🏳️🌈 (@lcasdev) 2024年7月9日
Update: in Microsoft Edge this capability is also available exclusively to *.google.com domains
— Luca Casonato 🏳️🌈 (@lcasdev) 2024年7月10日
And for everyone that keeps saying "Use Brave!!!":
Brave also has the same behaviour as Chrome and Edge here. The extension that allows Google to retrieve this information exclusively from *.google.com is also pre-installed in Brave.
— Luca Casonato 🏳️🌈 (@lcasdev) 2024年7月10日
這可不是簡單的事耶
簡單說，Google 在 Chromium 有塞一條後門，只要進去 Google 的網站，Google 就能使用這條API讀取某些資訊，而且僅 Google 自家網站能使用這條API。
( ͠° ͟ʖ ͡°) 《作文還重要嗎？》讀後感
聊一下作文，雖然我覺得它的重要性在降低，但在某些重要場景，它依舊會相當重要。
不重要的原因是，現在已由文字到了多媒體的時代，不論是以『圖片』為主的IG，或是『短影音』為主的抖音，其實這二者所涵蓋的受眾群一定更廣。
況且，即使習慣讀文字的人，也會看圖片或短影音，相反地，習慣看短影音的人，很難去閱讀一篇長文。
簡言之，對於影響人群的數量來說，文字是愈來愈不重要了。
由於作者關閉部落格，目前只能從 web archive 找到https://web.archive.org/web/20230605174341/https://mapleduh.pixnet.net/blog/post/50321284。
覺得挺感慨的。現在在網路上，你要找到關於新知的教學，絕大多數都是教學影片。
當然，文字的也有，像是我最近要看關於 AI （例如Stable Diffusion）的內容，有 Ivon Huang 的 Blog可以看。
但你還是不能否定絕大多數的新內容都是以影片為主體。
( •̀ .̫ •́ )✧ 更新了 robot.txt
今天我更新了 blog 的 robots.txt 了
更新成
User-agent: Mediapartners-Google
Disallow:
User-agent: *
Disallow: /search
Allow: /
User-agent: GPTBot
Disallow: /
User-agent: ChatGPT-User
Disallow: /
Sitemap: https://shiyou-blog.blogspot.com/sitemap.xml(´。＿。｀) 來談談網路廣告吧
今天逛Youtube時，看到藏壽司全球旗艦店的廣告
真的覺得這廣告真的做得不錯，明明只是在拍建築而已，卻讓人的的會想去……
但同時也讓我想到，最近的 Youtube 廣告……爛到 Youtube 給一★都嫌太多呀……
來談談「個人網站」這件事
近幾年有個現象，除了技術性的內容外，搜尋出來的結果十之八九是以下幾類
- 社交網站（例如FB）
- Google地圖之類的結果
- 百科（大多是維基百科，少數是獨立性的百科，像是遊戯王カードWiki）
舉例來說，我今天想找間餐廳，搜尋出來的結果可能這間餐廳只有 FB 專頁，連用個 weebly 做的簡單網站都沒有。
但當我今天想要搜尋技術內容，例如 Java 的 Spring MVC 的教學，最前面的搜尋結果，由於是程式方面，所以可能有 Stockoverflow ，但剩下來的結果絕大多數都是 Blog 文章或論壇貼文。
( ￣ー￣)φ＿ 淺談自己對 🦊 Firefox 瀏覽器的感覺
最近看到這篇文章：《你還在用 Firefox 嗎？Chrome、Edge 強勢進攻 Firefox 瀏覽器使用者近兩年大減 5,000 萬人》。
裡面對 FF 之所以失去使用者歸於
- 更新聚焦在介面調整、額外功能整合
- 有更多瀏覽器主打隱私，使FF主打隱私這點的優勢減少
- Chrome、Edge、Safari……等等都有硬體將之設為默認瀏覽器
( ˘•ω•˘ ).oOஇ 談談一款動作遊戲到底要針對背景說明多少才行？
想談談一款動作遊戲到底要針對背景說明多少才行？
最近從 switch 下載一款叫做 Nevaeh 的2D卷軸動作遊戲（遊戲也可以從 Steam 上下載，連結放在最下面）
(`・ω・´) 中時的網站居然會有如此基本的錯誤！
今天在中時看到一個很詭異的網頁：https://www.chinatimes.com/Search/result.htm?chdtv。
這個網頁呢，是點擊搜尋「民調」關鍵字相關文章時出現的頁面。
很明顯可以看出來，這網頁的後台有很大問題。
來談談HTML5製作的遊戲的使用者體驗吧
再過⅔個月左右，《金色のガッシュベル Golden Memories》就要結束營運了。
就趁這機會，來談HTML5遊戲好了。
眾所周知，Golden Memories是HTML5遊戲，沒有手機APP，完全得靠瀏覽器來玩。好處是不用在乎平台，無論是電腦、平板、手機，只要有瀏覽器（而且不要太舊）就能玩。
但是如果是一般APP就算了，我想談的是對手機使用者而言，這樣製作遊戲是個好的做法嗎？
雖然都是瀏覽器，但手機和電腦是有差的（無論哪款手機；哪款瀏覽器都是，例如同為 Mozilla Firefox，手機上使用和電腦上使用的感覺是有差的）！
最大的差異就是網址列。對手機而言，為了讓網頁內容能夠最大化，網址列會隱藏起來，除非你滑動頁面；電腦沒這需求，所以網址列，除非使用者有特別設定，否則都會一直放在那。
如果是一般網頁，其實這種差異影響度很低，但是對遊戲而言就不同了。
由於智障智慧型手機是用手指操作的，如果因為不小心手指拖曳頁面導致網頁捲動，就會跑出網址列，這絕對影響使用者體驗。
此外，網址列如果不小心點到導致你網頁重整、跳出之類那又更麻煩了。
所以，要設計給手機玩的話，網頁遊戲真的適合嗎？
手機還有一個對遊戲來說是缺點的事，那就是旋轉，要設計給網頁的話，手機要室選轉整個網頁樣式可能會跑掉，就算沒跑掉，還是會有部分內容變成得滾到下方才能看到了……但這很好避免，關閉手機自動旋轉功能即可。
在這不得不提 Ameba 的《ガールフレンド（仮）》、《ボーイフレンド（仮）》等，他們不只有網頁版，還有另外製作一個APP（雖說那個APP也只是一個沒有網址列的瀏覽器罷了），可以避免上述問題。這好像也是以這種方式製作的遊戲最適當的解答吧……
但HTML55也不是完全不行，畢竟這是目前最容易跨平台的製作方式，而且現在HTML5也夠強大，有 Canvas、SVG、Web GL等技術能用，瀏覽器現在也比較不需要考慮瀏覽器差異的問題了（現在年輕人可能不懂，但以前製作網頁，一想到IE就是個痛！不提IE，光是 Firefox 和 Chrome 就有些許顯示差了，更不提還沒使用 Blink 的 Opera 12）。
總的來說，如果只是開發遊戲，HTML5當然是個很好的開發方式。但是如果你的遊戲有設計給手機玩的話，就得好好考慮許多額外問題，或者可以像 Ameba 那樣另外做一個 APP。
就趁這機會，來談HTML5遊戲好了。
眾所周知，Golden Memories是HTML5遊戲，沒有手機APP，完全得靠瀏覽器來玩。好處是不用在乎平台，無論是電腦、平板、手機，只要有瀏覽器（而且不要太舊）就能玩。
但是如果是一般APP就算了，我想談的是對手機使用者而言，這樣製作遊戲是個好的做法嗎？
雖然都是瀏覽器，但手機和電腦是有差的（無論哪款手機；哪款瀏覽器都是，例如同為 Mozilla Firefox，手機上使用和電腦上使用的感覺是有差的）！
最大的差異就是網址列。對手機而言，為了讓網頁內容能夠最大化，網址列會隱藏起來，除非你滑動頁面；電腦沒這需求，所以網址列，除非使用者有特別設定，否則都會一直放在那。
如果是一般網頁，其實這種差異影響度很低，但是對遊戲而言就不同了。
由於
此外，網址列如果不小心點到導致你網頁重整、跳出之類那又更麻煩了。
所以，要設計給手機玩的話，網頁遊戲真的適合嗎？
手機還有一個對遊戲來說是缺點的事，那就是旋轉，要設計給網頁的話，手機要室選轉整個網頁樣式可能會跑掉，就算沒跑掉，還是會有部分內容變成得滾到下方才能看到了……但這很好避免，關閉手機自動旋轉功能即可。
在這不得不提 Ameba 的《ガールフレンド（仮）》、《ボーイフレンド（仮）》等，他們不只有網頁版，還有另外製作一個APP（雖說那個APP也只是一個沒有網址列的瀏覽器罷了），可以避免上述問題。這好像也是以這種方式製作的遊戲最適當的解答吧……
但HTML55也不是完全不行，畢竟這是目前最容易跨平台的製作方式，而且現在HTML5也夠強大，有 Canvas、SVG、Web GL等技術能用，瀏覽器現在也比較不需要考慮瀏覽器差異的問題了（現在年輕人可能不懂，但以前製作網頁，一想到IE就是個痛！不提IE，光是 Firefox 和 Chrome 就有些許顯示差了，更不提還沒使用 Blink 的 Opera 12）。
總的來說，如果只是開發遊戲，HTML5當然是個很好的開發方式。但是如果你的遊戲有設計給手機玩的話，就得好好考慮許多額外問題，或者可以像 Ameba 那樣另外做一個 APP。
訂閱：
文章 (Atom)