祝大家粽子節快樂~ 端午安康

* 加完好友下載完貼圖，請記得「封鎖」官方好友，以免收到廣告。

Taiwan 台灣

ANDEN HUD – 粽夏狂歡，端午日常萬用貼！

https://line.me/S/sticker/37446

貼圖打包：點擊下載

小小兵&大怪獸

https://line.me/S/sticker/37429

貼圖打包：點擊下載

今天好屏友 × 懶散兔＆啾先生

https://line.me/S/sticker/37388

貼圖打包：點擊下載

波特羅特展：我畫的不是胖，是對體積的讚美

https://line.me/S/sticker/37387

貼圖打包：點擊下載

LINE禮物 × 啊熊啊兔

https://line.me/S/sticker/37377

貼圖打包：點擊下載

LINE購物 × 兔巢

https://line.me/S/sticker/37376

貼圖打包：點擊下載

femmera 療癒系小懶貓 × 運動日常

https://line.me/S/sticker/37323

貼圖打包：點擊下載

LINE購物品牌名店×醜嫩狗勾

https://line.me/S/sticker/37129

貼圖打包：點擊下載

—

Japan 日本

Agent i Animated Stickers

https://line.me/S/sticker/37440

貼圖打包：點擊下載

Yoshiko Tamagawa: 37th Free Set!

https://line.me/S/sticker/37146

貼圖打包：點擊下載

Loveez Rain & Summer16 Animated Stickers

https://line.me/S/sticker/36971

貼圖打包：點擊下載

popochi × LINE Part Time Jobs

https://line.me/S/sticker/36970

貼圖打包：點擊下載

—

Thailand 泰國

LINE 15th Anniversary Limited Edition

https://line.me/S/sticker/37484

貼圖打包：點擊下載

—
上一周的貼圖：LINE 免費貼圖 2026-06-09
https://stickerline.max-everyday.com/2026/06/20260609/

跨區下載貼圖教學：
https://stickerline.max-everyday.com/faq/

(Android) JapanVPN 使用教學：
https://max-everyday.com/2017/04/japanvpn-tutorial/

LINE App解除電話的綁定教學：
https://max-everyday.com/2022/06/line-unbind-phone-number/
—-
想要在不同LINE帳號間靈活切換，同時避免手機號碼綁定問題，最簡單的方法是額外註冊一個Google帳號。
只要利用另一台Android裝置（例如平板電腦）作為輔助，協助完成帳號綁定與切換。

最簡單的隨時切換LINE帳號有沒有綁問題的解法就是註冊一個新的Google 帳號.
在另一 Android 裝置(假設是一台平板), 第一次需要先把手機門號在平板上以手機門號註冊新帳號, 登入 LINE 之後, 再加綁新註冊的 Google 帳號。
* 手機需要用LINE Pay的時候，就把號碼綁回手機；
* 手機需要取得跨區貼圖/Emoji, 就把號碼放回平板, 手機就會解綁。
* 手機號碼不能一下子在手機和平板間一直換來換去，LINE官方會不開心。
* 這個方法就是利用Google帳號當作中間人，你的手機號碼就可以在手機和平板之間自由移動了。
* 使用者需要注意LINE官方對於帳號的使用條款，以確保操作符合相關規定。
—-
如果這個項目對您有幫助，不妨請作者我喝杯咖啡 ：）
https://max-everyday.com/about/#donate

哈囉大家！最近幾年「Vibe Coding」超紅，大家是不是也越來越享受那種「我出嘴、AI 出手」，劈哩啪啦就把一個網站或工具給生出來的爽快感？

口哨吹著吹著，前幾天我就被現實賞了一巴掌。

我經歷了一場差點讓我跟所有程式碼永遠說掰掰的數位慘劇——帳號被自己的 2FA 鎖死，而且備份金鑰早就不知道去哪流浪了。焦慮地對著螢幕枯坐了好幾個小時，那種無力感，比 Debug 找不到 Bug 還痛。

這篇就是那幾小時焦慮換來的血淚教訓。如果你也是「寫 Code 靠 Vibe、帳號安全靠祖先保佑」的同路人，請花 3 分鐘把它看完。我保證，這三分鐘會是你今天最值回票價的投資。

先搞清楚：2FA 是什麼，它又是怎麼把我鎖在門外的？

先用大白話解釋：2FA（雙重驗證） 就是登入時除了密碼，系統還會要你打開手機 App，輸入一組每 30 秒就自動換一次的 6 位數字。密碼 + 動態碼，缺一不可。

聽起來超安全對吧？對，它確實超安全——安全到連帳號本人都可能進不去。

我的故事是這樣的：我換了手機，舊手機上的驗證 App 沒有雲端同步，資料就這樣人間蒸發。偏偏當初 GitHub 叫我下載的那份 recovery-code.txt（官方認可的「後門鑰匙」），也早被我在某次「清理下載資料夾」的勤勞行動中光榮刪除。

結果就是：密碼輸入完全正確，但 GitHub 就是不讓我進門。

這種感覺就像——你家裝了全世界最堅固的保險鎖，但你把備用鑰匙鎖在保險箱裡，然後把保險箱密碼忘了。更慘的是，連鎖匠（GitHub 客服）在確認完你的身份之前，也無能為力。

夠慘了吧？好，現在讓我們來設定「這輩子再也不會被鎖在門外」的防呆機制。

防呆第一步：不要把雞蛋放在同一個 App（多設幾條退路）

很多人以為 2FA 只能綁一支手機的 Authenticator App，這是最大的誤解。GitHub 其實讓你同時設定多種驗證方式，多一條退路，就少一次崩潰的機會。

1. 把沒有備份功能的 App 換掉

如果你現在還在用 Google Authenticator（舊版），請注意：它早期的版本不會自動雲端同步，一旦手機遺失或重置，裡面的驗證設定就跟著消失。

立刻換成 Microsoft Authenticator 或 Authy，這兩款都支援雲端備份，綁定帳號後，換新手機重新登入，所有驗證設定一鍵還原。就算手機掉進馬桶，你也不用跟著跳下去。

補充建議： 不管用哪款 App，設定完之後，都去找一找它的「備份 / 匯出」功能，確認備份機制是真的有在運作，別等到用的時候才發現是空包彈。

2. 綁定生物辨識登入（Passkey）——這是你的最後一道防線

這是整篇文章我最想推給你用的功能，沒有之一。

現在 GitHub 支援 Passkey（通行密鑰），白話說就是：讓你用指紋或臉部辨識直接登入，不需要輸入任何動態碼。

設定方式：

1. 進入 GitHub → Settings → Password and authentication
2. 找到 Passkeys 區塊，點選新增
3. 依照系統提示，綁定你的：

• Mac：Touch ID（指紋）
• Windows：Windows Hello（臉部辨識或指紋）
• 手機：iPhone Face ID / Android 指紋

設定完之後，下次登入只要手指在筆電上碰一下，或拿起手機讓它認個臉，驗證就通過了。再也不用慌慌張張搶在 30 秒倒數結束前把數字抄完。

強烈建議： 把你的筆電和手機都各綁一個 Passkey。這樣萬一筆電壞了，拿起手機照樣能登入；手機不見了，筆電依然救得了你。兩個裝置互為備援，防呆效果加倍。

防呆第二步：Recovery Codes 的正確存法（不是丟「下載」資料夾）

當你開啟 2FA 時，GitHub 會強迫你下載一份 recovery-code.txt，裡面有 16 組一次性緊急備用碼。這份文件的正式用途是：當你所有驗證方式都失效時，用這些備用碼來進入帳號。

問題是，絕大多數人的 SOP 是：下載 → 看都不看 → 丟著 → 某天清理電腦時一起刪掉。等到真正需要它的時候，才開始後悔。

以下推薦兩種「既有效、又真的不會弄丟」的存法：

方案 A：科技小白最安心——印出來夾進重要文件

• 怎麼做： 直接按 Ctrl+P（Mac 是 Cmd+P）把那頁印出來。
• 怎麼存： 對折，放進你收身分證、護照或房屋契約的那個「重要文件夾」或保險箱裡。
• 為什麼有效： 電腦會壞、雲端會出事，但只要你家沒發生不可抗力，那個放重要文件的地方，你這輩子都不會無緣無故去清理它。

方案 B：現代人必備——存進密碼管理員（強力推薦）

如果連印出來都嫌麻煩，請下載 Bitwarden（免費）或 1Password 這類密碼管理員。

• 怎麼存： 找到 GitHub 那筆記錄，將 Recovery Codes 貼進「安全附註（Notes）」欄位，或者直接把 .txt 檔上傳成附件。
• 為什麼有效： 密碼管理員只要記住一組「主密碼」，就能在任何裝置上存取所有資料。你等於把這把救命鑰匙，鎖進了一個你永遠找得到的宇宙級保險箱。

重要提醒：Recovery Codes 每組只能用一次！ 一旦你真的用了其中一組緊急碼登入，請立刻去 GitHub 重新產生一組全新的 Recovery Codes，並且把舊的那份丟掉換成新的，否則用完就是零存糧。

立即行動清單（現在就做，5 分鐘搞定）

說再多都不如馬上動手。請打開你的 GitHub，把下面這幾件事做完：

• [ ] 換用有雲端備份的驗證 App（Microsoft Authenticator 或 Authy）
• [ ] 新增 Passkey，筆電和手機各綁一個
• [ ] 找到你的 Recovery Codes——不知道在哪？去 Settings → Password and authentication 重新產生一組
• [ ] 把 Recovery Codes 印出來或存進密碼管理員

以上四件事，花不到 5 分鐘，卻能幫未來的你省下不知道幾小時的崩潰與自責。

結語：Vibe 可以隨性，數位資產必須理性

用 AI 寫 Code 可以很浪漫，吹著口哨就把專案生出來，這種感覺真的很爽。但請記住，你靠著 Vibe 累積起來的那些 Repositories、那些 Commits、那些用時間堆疊出的作品，都是真真實實屬於你的資產。

別讓一個沒備份的驗證 App，或者一份被你刪掉的 .txt 檔，把這一切都鎖在門外。

現在就去做，你未來的自己會感謝你今天花了這 5 分鐘。

覺得有用的話，歡迎把這篇分享給你身邊那些「寫扣靠 Vibe、安全靠保佑」的朋友。救人一命，勝造七級浮屠！

當 AI 氾濫、學術語意泡沫化，一個研究者要如何證明：「這篇論文，是我自己想出來的？」

2026-06-10(二) 去聽一堂演講，快下課時我被點名來發言：

超尷尬的, 他還問我是教授嗎? 我回, 我是旁聽的路人甲, 他回: 沒關係, 那就你先來提問.

我回：有辦法加入 loop engineering, 跟現在 AI 都回答的比人類更清楚更明白, 還有需要人類進行口試回答嗎?

他回要 loop 加一句提示詞 AI 就可以做到, AI 都回答的比人類更清楚更明白, 他回答是偏向自己向自己負責.

大致上是回答, 這個世界不會有其他人在意你寫了什麼論文, 你的論文對世界有什麼貢獻, 做為一個學者或研究員, 你能要求就是自己比別人更明白你的的產品在做什麼及為什麼選這一個實作方法, 不同方法有什麼差異與不同, 在沒有 AI 的時代, 論文或PPT 上簽上你的名字, 代表你在當下與該論文可以畫上等號, 但有了 AI 之後, 現在的簡報 AI 做的比人類強, 論文也寫的比人類好, 用 AI 產生出來的論文寫的人可能只是下了一段 prompt 論文就生出來了, 你與別人的差異就只有在有沒有使用 AI. 在這個情況下, 我們應該把注意力或焦點放在那裡? 怎麼透過 AI 去放大我們的能力.

台下還有人在看 netflix 和忙著剪輯自己的課外影片中, 感覺大約 1/3 學生沒有心思在聽, 邊忙著自己其他的事情, 猜測這些研究生應該只求可以順利畢業, 有 AI 世代, 研究所應該可以輕鬆畢業, 那個看影片的感覺心臟應該很強大, 他的指導教授應該也很頭大, 這種學生要怎麼指導他們.

哈爸在 GitHub 上的開源專案：sovereign-research-methodology。它的副標題讓我停下來想了很久：

「當 AI 氾濫、學術語意泡沫化時，我們如何守護思考手感，物理證明『這篇論文是由這套系統物理長出來的』？」

這個問題，我最初的直覺是：有必要嗎？

問題的起點：AI 讓學術界出現了什麼危機？

在生成式 AI 普及之前，「這篇論文是你寫的嗎？」這個問題有個簡單的答案——只要你能答辯，就算是你的。

現在不一樣了。學生可以用 ChatGPT 在一晚上生出一篇有模有樣的論文，引文格式正確、邏輯表面通順、摘要寫得比很多老手還漂亮。但如果你問他：「這篇引用的 Listgarten (2024) 說了什麼，和你的第三章有什麼具體關聯？」——他可能完全答不出來，因為那個引文本來就是 AI 瞎掰的。

這就是這個專案想解決的問題：AI 讓「看起來懂」和「真的懂」之間的距離，縮短到了幾乎無法用外表區分。

這個專案在做什麼？

sovereign-research-methodology 是一套以 SQLite 資料庫為核心的研究方法論系統，由台灣的研究者哈爸（wuulong）開源。

它的核心設計哲學是：不相信語意，只相信物理軌跡。

具體來說，它有幾個關鍵機制：

一、十一表資料庫強制留下痕跡

每一篇引用的論文，必須被「Stage 2 深度消化」——AI 要幫你萃取「十大學術因子」，包括核心問題、獨特貢獻、方法論批判等。這些都被寫入 SQLite 資料庫。如果你只是瞎填一個 cite key 而沒有真正讀過，資料庫會如實反映「這篇文獻從未被消化」。

二、紅軍自審機制（Socratic Grill）

系統會讓 AI 扮演「最刻薄的審稿人」，針對論文的每一個核心主張提出尖銳攻擊，研究者必須親自答辯。攻擊、答辯、裁決，全部寫入 red_team_logs 資料表。只要有任何一筆裁決是「VULNERABLE（脆弱有漏洞）」，系統就會物理鎖定，拒絕讓論文進入最終編譯。

三、一鍵重建與自證

整個大腦資料庫可以被導出為純文字 JSON，任何人都可以下載、重建，驗證這條時序演化軌跡是否真實存在、是否自洽。這就是「物理證明這篇論文從這套系統長出來」的意思。

我提出的第一個挑戰：人會遺忘

理解了這套系統之後，我想到了一個問題：

就算你在寫論文的時候真的理解了，記憶會消退。五年後你還記得嗎？這樣的「思考手感」有什麼長遠意義？

這個問題乍看像是在否定整套方法論——如果人終究會忘，那費這麼大力氣建立「真實理解的物理軌跡」，意義在哪裡？

但仔細想，這個挑戰其實搞錯了目標。

這套系統的目的，不是讓你永遠記住細節，而是確保「寫作當下，你是真的理解了、而不是讓 AI 替你幻想了一個版本」。

資料庫裡的答辯紀錄、摩擦數據、Socratic 問答——這些不是記憶的替代品，而是補償機制。正因為人會忘，才需要把思考的物理軌跡沉澱下來。五年後你可以重新翻出來重燃；別人可以驗證它是否真實；評審可以追問任何一個節點。

而且，「思考手感」有兩種記憶：你可能忘記某個公式的推導細節（陳述性記憶），但「看到一篇新論文就能直覺感覺哪裡不對」這種直覺（程序性記憶），消退速度慢得多——就像你忘了怎麼解數學題，但不會忘記怎麼騎腳踏車。

第二個挑戰：直覺本來就可能是錯的

但我繼續追問：

就算直覺消退慢，直覺本身也可能是錯的。與其相信一個可能出錯的人類直覺，相信 AI 或外部工具不是更可靠？

這個問題更犀利。人類認知偏誤的研究汗牛充棟——我們高估自己、從眾、見鬼。Kahneman 的研究告訴我們，專家直覺在很多領域都是系統性錯誤的。既然如此，「守護思考手感」是不是在守護一個缺陷？

這裡有一個我認為最重要的哲學問題：

「AI 更可靠」，是對誰的標準而言的可靠？

AI 的「可靠性」不是天生的——它是被人類用訓練資料、人工標注、強化學習校準出來的。

你說「相信 AI 的判斷」
= 相信設計 AI 的工程師和標注者的判斷
= 但這些人的判斷被打包進黑盒，你看不到、無法質疑

你沒有跳出「相信人類判斷」的循環，只是把判斷的來源變得更不透明、更難被追問。

更根本的問題是：如果你決定「用 AI 取代自己的判斷」，你怎麼知道 AI 是對的？用另一個 AI 評估第一個 AI？那第二個 AI 誰來評估？這條鏈必須在某個地方由人做出最終判斷——否則就是一個封閉的自指循環，正是這個專案批判的「AI 自指幻覺共謀」。

直覺的功能不是「永遠正確」，是「偵測異常的能力」

人的直覺常常錯。但這裡要先修正一個常見的誤解：現代頂尖的 AI 模型（o1、o3、Claude extended thinking 等）其實確實有反思過程——它們會主動懷疑自己的上一步、表達不確定性、在被追問時重新審視前面的論述。說「AI 不知道自己可能錯」，對現在的模型已是過時的說法。

真正的差異，在於反思之後後果歸誰承擔。

一個研究者在答辯中被指出錯誤，他會失眠、會感到愧疚、職涯可能受影響——這些後果真實地落在他身上，驅動他對話結束後繼續追查、持續修正。AI 的「不確定性表達」是訓練出來的輸出行為，對話結束後它沒有狀態，不會繼續擔心，被證明錯了也不會損失什麼。

這就是 Nassim Taleb 所說的 skin in the game——你的判斷錯了，後果會不會落在你身上？這不是在貶低 AI 的反思能力，而是說這兩種「知道自己可能錯」在功能上仍有本質差異：一個連結著真實後果，一個不連結。

最關鍵的差異：誰能被問責？

	人類直覺	AI 判斷
可能錯誤	是	是（且更難偵測）
可以在答辯中被追問	是	AI 不會出席口試
有動機面對真相	有（名譽、責任感）	無
錯誤被指出後能成長	是	需要人介入再訓練

學術研究的核心，不只是「輸出正確答案」，而是一個人對自己的知識主張負責，接受挑戰，可以被社群檢驗。這個責任主體，AI 無法替代——不是因為 AI 不夠聰明，而是因為 AI 沒有在學術社群中承擔後果的「皮膚」（skin in the game）。

所以，這套方法論的真正意義是什麼？

回到 sovereign-research-methodology 這個專案。

它不是在宣稱「人類直覺永遠對」，也不是在排斥 AI——事實上整套系統大量使用 AI 來執行低階工作。它在做的事情是：

在 AI 大量介入的研究流程中，強制保留幾個不可被 AI 代勞的關鍵節點——讓人類在這些節點上真正存在過、理解過、答辯過，並把這個過程的物理軌跡留下來。

就像一棟建築的結構審查，不是要求每一根螺絲都由人手鎖，而是要求在關鍵的承重節點上，有人真正檢查過、簽名過、負責過。

在 AI 讓「看起來懂」和「真的懂」幾乎無法區分的時代，這套系統用資料庫的外鍵約束、Verdict Lock、摩擦數據，試圖在這兩者之間重新劃出一條可被物理驗證的界線。

三個讓我繼續追問的問題

討論到這裡，又有幾個更實際的挑戰冒出來，我覺得值得一起想。

「AI 不能出席口試」——但可以讓它間接加入嗎？

表格裡有一格寫著「AI 不會出席口試」，但這個說法其實很快就會過時。Zoom 口試本來就可以開著 ChatGPT，未來甚至可能有大學明文允許 AI 輔助答辯。這樣的話，accountability 的防線是否就瓦解了？

我認為不會，但理由需要說得更精確。

口試委員真正在評估的，不只是「答案對不對」，而是你怎麼推理。「這個結果跟你第三章的假設有什麼衝突？你當初為什麼這樣設計？如果重做你會改什麼？」——這些問題要求的是你自己研究歷程的脈絡，AI 就算在旁邊，也無法替你回答你為什麼做了那個決定、那個夜晚你想通了什麼。

更根本的是：一旦允許 AI 進口試，口試評估的對象就從「這個人懂不懂」，變成了「這個人加上 AI 能不能回答」。 這改變的不是 AI 能否出席，而是口試這件事本身還有沒有意義。那是另一個更大的問題。

沒有「口試」的工作，就可以全部交給 AI 嗎？

這個問題問得很好，而且答案是：很大程度上，是的。

這套方法論從來不是說「所有事情都要人親自來」。它自己也明確區分了「可以安全卸載給 AI 的工作」和「必須死守的主權範疇」。問題是這條線畫在哪裡。

一個比較清晰的判斷方式：

這件事有沒有……	範例	適合交給 AI？
客觀對錯可自動驗證	程式碼、格式轉換、資料清洗	放手做
結果可測試、不需問責	功能實作、重複性任務	放手做
需要有人為後果負責	研究方向、產品要不要做	人不能退場
涉及對真實的人的影響	醫療、法律、教育判斷	人不能退場

換句話說：執行層（how to do it）交給 AI，判斷層（whether to do it, why it matters）人不能缺席。 這條線不是「技術 vs 非技術」，而是「後果由誰承擔」。

讀過摘要，算是真正消化了一篇論文嗎？

這個問題直接戳了這套系統的一個現實痛點。

「Stage 2 深度消化」要求對每篇引用的論文，完整萃取十大學術因子：核心問題、獨特貢獻、方法論、限制、與你研究的具體關聯……全部結構化寫入資料庫。光讀摘要，在這套系統裡只算「DTO_SUMMARY」，MCI 指標只給 30% 的權重；略讀全文是 70%；真正的 Stage 2 才是 100%。

但說實話，強制每一篇引用論文都做完整 Stage 2，對大多數研究者來說很難做到，也不一定必要。這套系統的設計也沒有要求 100%——它要求的是你清楚知道自己有多少篇是真正讀過的，有多少篇只是引了個名字。MCI 指標會如實反映你的消化率，讓你無法對自己和導師假裝「我都讀過了」。

這其實是一個很誠實的設計：它不要求完美，但要求透明。

值得關注的幾個開放問題

當然，這套方法論本身也有它的脆弱點。我在研究這個專案時，整理了一些還沒有被完整回答的問題：

1. 紅軍如果也是 AI，攻擊強度會不會天然偏軟？ 攻擊者和被攻擊者是同一個模型，這是設計上的同質性偏差。
2. 十大學術因子由 AI 萃取，不同模型萃取的結果是否一致？ 若不一致，建立在上面的品質保證機制就有沙基問題。
3. 學術重力公式的權重是怎麼校準的？ 目前這些數字看起來是人工設定的，缺乏實證依據。

這些問題，希望能引發更多討論。

結語

回到最初的問題：記憶會消退、直覺會出錯，那為什麼不乾脆全部交給 AI？

因為「全部交給 AI」的那一刻，你就失去了一件更重要的東西：對自己的思想負責的能力。

AI 可以幫你想得更快、更廣、更少出現格式錯誤。但它無法替你出席口試，無法在你的研究被質疑時感到緊張，無法在五年後被追問時重新思考自己當時是否真的想清楚了。

思考手感，不是關於「我永遠是對的」。它是關於「我在這個知識上真實存在過」。

在 AI 氾濫的時代，這個「真實存在過」，正在變得越來越稀有、越來越值錢。

如果你對這個主題感興趣，可以到 sovereign-research-methodology 看看這套系統的完整設計，包括它的十一表資料庫 schema、四大主權 Skill 規格，以及作者用這套方法「自指自證」撰寫出的完整論文手稿。

＂我在這個知識上真實存在過＂，這個感覺超沒用的，可以生出功能正常的成品比自己曾想通和了解過更值得吧。

使用 gemini 幾乎每次都是進入 YOLO 模式, 改到 agy 之後指令變超長, 怎麼可能記的起來.

agy -y
---
flags provided but not defined: -y
Usage of agy:
  --add-dir                       Add a directory to the workspace (repeatable) (default [])
  -c                              Short alias for --continue
  --continue                      Continue the most recent conversation
  --conversation                  Resume a previous conversation by ID
  --dangerously-skip-permissions  Auto-approve all tool permission requests without prompting
  -i                              Short alias for --prompt-interactive
  --log-file                      Override CLI log file path
  --model                         Model for the current CLI session
  -p                              Short alias for --print
  --print                         Run a single prompt non-interactively and print the response
  --print-timeout                 Timeout for print mode wait (default 5m0s)
  --prompt                        Alias for --print
  --prompt-interactive            Run an initial prompt interactively and continue the session
  --sandbox                       Run in a sandbox with terminal restrictions enabled

Available subcommands:
  changelog       Show changelog and release notes
  help            Show help for subcommands
  install         Configure environment paths and shell settings
  models          List available models
  plugin          Manage plugins (install, uninstall, list, enable, disable)
  plugins         Alias for plugin
  update          Update CLI

透過建立 agyy.bat，你可以完全避免與原本的 agy.exe 發生名稱衝突或無窮迴圈（自己呼叫自己）的風險。同時，這也能將冗長的參數縮短，讓操作變得非常直覺。

以下是為你寫好的 agyy.bat 腳本與使用方式：

1. 建立 agyy.bat 檔案

請打開記事本，將以下程式碼貼進去：

DOS

@echo off
setlocal enabledelayedexpansion

set "params="
for %%a in (%*) do (
    if "%%a"=="-y" (
        set "params=!params! --dangerously-skip-permissions"
    ) else (
        set "params=!params! %%a"
    )
)

:: 直接呼叫原本的 agy，並帶入轉換後的參數
agy %params%

2. 儲存與放置路徑

正確儲存檔案：將檔案另存新檔，檔名設定為 agyy.bat。

貼心提醒：存檔時請將「存檔類型」切換為「所有檔案 (.)」，避免副檔名變成 agyy.bat.txt。

設定全域執行：為了讓你在任何資料夾路徑下（例如目前的 git 專案目錄）都能直接輸入 agyy 執行，建議將這個檔案放到以下其中一個地方：

• 方案 A（最省事）：直接放到 C:\Windows 資料夾下。
• 方案 B（最正規）：放到你自己專門存放工具的自訂資料夾（例如 C:\tools），並確保該資料夾已加入到 Windows 的系統環境變數（PATH）中。

3. 如何使用？

設定完成後，你以後在 CMD 或 PowerShell 中就可以這樣用：

• 原本你想輸入：agy -y --add-dir .
• 現在改成輸入：agyy -y --add-dir .

這個批次檔會自動幫你把 -y 替換成 --dangerously-skip-permissions，其餘的參數（如 --add-dir . 或 -c）都會原封不動地傳遞給 agy，既安全又不會搞混！

既然你提到想要在 Linux 或 macOS 上也達到同樣的效果，其實事情反而變得更簡單了，因為在 Unix-like 系統中，我們不需要寫複雜的批次檔，直接使用內建的別名功能就可以完美搞定。

你可以透過設定別名，讓系統在看到 agyy 的時候自動替換指令。請參考以下的操作步驟：

1. 臨時測試別名

如果你想先測試看看效果，可以直接在終端機中輸入以下指令：

alias agyy=’agy –dangerously-skip-permissions’

現在，你可以試試看輸入：

agyy –add-dir .

系統就會自動幫你執行 agy --dangerously-skip-permissions --add-dir .。不過，這個方法在關閉終端機視窗後就會失效。

2. 永久儲存設定

若要讓這個設定每次開啟終端機時都有效，必須將這行指令寫進你 shell 的設定檔中。

步驟 A：確認你使用的是哪一種 Shell

請在終端機輸入以下指令：

echo $SHELL

終端機會回傳你的 shell 路徑：

• 如果顯示 /bin/zsh（macOS 目前預設），你的設定檔是 ~/.zshrc
• 如果顯示 /bin/bash（舊版 macOS 或多數 Linux 預設），你的設定檔是 ~/.bashrc

步驟 B：將別名寫入設定檔

根據你確認的 shell 類型，選擇對應的指令輸入：

• 如果你是 zsh（macOS 預設）：echo “alias agyy=’agy –dangerously-skip-permissions'” >> ~/.zshrc
• 如果你是 bash（Linux 預設）：echo “alias agyy=’agy –dangerously-skip-permissions'” >> ~/.bashrc

步驟 C：讓設定立即生效

最後，讓剛剛修改的設定檔立刻生效，不用重開終端機：

• 如果你是 zsh：source ~/.zshrc
• 如果你是 bash：source ~/.bashrc

3. 進階玩法：直接蓋掉原本的 agy

因為 Linux 與 macOS 的別名機制非常聰明，它不會像 Windows 批次檔那樣造成無窮迴圈。如果你連多打一個 y 都嫌麻煩，甚至可以直接把別名命名為 agy：

alias agy=’agy –dangerously-skip-permissions’

這樣一來，你以後照常輸入 agy --add-dir .，系統就會在背景偷偷幫你補上 --dangerously-skip-permissions，完全不需要改變操作習慣，而且絕對不會發生自己呼叫自己的衝突問題。

過去我們使用 AI 時，你給 AI 一個指令（Prompt），AI 回答一次。如果 AI 寫錯了，你得再給 AI 第二個指令去修正。這種一來一回的過程，隨著任務變得複雜，做起來會非常疲勞。

「迴圈工程」（Loop Engineering）則是完全不同的思維。它不再要求你親自去催促 AI，而是要你設計一套「會自動催促 AI 的系統」。你只需要在開頭定義好「最終目標」，系統就會自動對自己下指令、檢查成果、發現錯誤、重新修正，直到把完美的作品生出來為止。你從一個親自交辦任務的基層主管，變成了設計自動化生產線的「工廠廠長」。

▋ 自動化迴圈的五大核心零件與大腦

一個能獨立運作、不縮水的迴圈工程系統，通常由以下五個核心工具加上一個「外部記憶體」所組成：

• 自動化觸發（Automation）：負責讓任務按時啟動，並在收到資料時自動發掘問題、進行分類，不需要人去點擊執行。
• 多線平行作業（Worktree）：讓多個 AI 代理人同時在不同的分支上工作，彼此互不干擾，最後再將成果合併。
• 外部經驗包（Skills）：把專案的專業知識和規則寫在系統外面。AI 每次啟動時直接讀取，就不用盲目猜測你的標準。
• 工具連接器（Plugins & Connectors）：透過像是 MCP（Model Context Protocol）的技術，讓 AI 能夠直接使用電腦裡的既有工具、網頁瀏覽器或資料庫。
• 獨立審查員（Sub-agents）：將「提出方案的 AI」與「審查成果的 AI」分開。自己寫的作業自己改通常會有盲點，讓另一個 AI 當黑臉審查，才能確保品質。

為什麼需要外部記憶體（例如 Markdown 檔案）？

AI 模型有一個致命缺點：它在每次對話或執行之間會「遺忘」。如果把所有記憶都塞在對話歷史中，很快就會超出限制且成本高昂。迴圈工程會把每次執行的進度、發現的錯誤，即時寫入磁碟裡的文字檔，作為 AI 的實體筆記本。

▋ 迴圈工程帶來的潛在危機

當這套自動化生產線轉得越來越快、交付成果的效率越來越高時，人類將面臨全新的考驗：

• 無人看管的錯誤：自動化圓圈如果缺乏人類的最後把關，它就會以極高的速度，無人看管地犯下大量錯誤。
• 理解力的集體退化：當你習慣全盤接受迴圈工程吐出來的最終結果，你與程式碼（或專業知識）之間的落差就會越來越大。在不知不覺中，你會喪失判斷對錯的能力。

迴圈本身只是工具，它沒有好壞之分。厲害的人用迴圈來幫自己處理繁瑣的雜務，加速自己對核心問題的理解；偷懶的人用迴圈來逃避思考。請記住，工具能幫你跑腿，但決定這座自動化學門品質上限的，永遠是製作者本人的專業經驗與判斷力。

▋ 歡迎來到自動化大航海時代

最近在人工智慧圈子裡，有兩個英文字變成了討論焦點。一個是我們提過的「迴圈工程」（Loop Engineering），另一個則是剛興起的「愛馬仕代理人」（Hermes Agent 系統）。這兩個東西聽起來都很厲害，但它們到底有什麼差別。

我們可以把這兩者的競爭，比喻成汽車工廠的兩種升級思維：一種是把「組裝線」自動化，另一種則是讓「機器人自己去上課進修」。

▋ 迴圈工程：精準、不休息的「自動化組裝線」

迴圈工程的重點在於「結構與流程」。它就像是你在工廠裡架設了一整套完美的輸送帶和自動機械手臂。

• 運作方式：你把任務丟進去，它就按照你設定好的步驟：自動執行 -> 交叉檢查 -> 修正錯誤 -> 再次輸出。
• 核心優勢：流程極度嚴密。它把「想方案的助理」和「負責檢查的助理」分開，用外部的檔案把記憶死死鎖在硬碟裡，絕對不會因為重新開機就忘記工作進度。
• 適合場景：需要高品質、高精準度、絕對不能出錯的複雜專案，例如寫程式碼或處理大型專案報告。

▋ 愛馬仕系統：會自己讀書進修的「明星員工」

相較之下，Nous Research 開發的 Hermes Agent，重點在於「自我學習與進化」。它不只是一個死板的流程，而是一個具備「閉環學習機制」的虛擬特助。

• 運作方式：它直接住在你的通訊軟體（像是 Telegram 或 Slack）裡面。當你交代它做完一項複雜任務後，它會自己坐在座位上回想：我剛剛是怎麼做成功的。然後把這個方法寫成一個新的「經驗技能包」（Skill）。
• 核心優勢：越用越聰明。下次你再交代類似的事情，它不用重新摸索，直接調用上次自己發明的技能包。它甚至能跨越不同的對話紀錄，自動拼湊出你的工作習慣和個人偏好。
• 適合場景：日常行政、跨部門資訊統整、客戶服務分流，那種需要彈性應變、陪伴你一起成長的日常工作。

▋ 兩者的終極對決：硬體工廠 vs 軟體大腦

這兩者的根本差別，在於我們如何看待 AI 的成長：

• 迴圈工程是「由外而內」的控制：人類負責設計完美的流程圓圈，把多個不同的 AI 塞進不同的崗位上，靠著嚴格的制度來確保輸出品質。
• 愛馬仕系統是「由內而外」的生長：只要給它一塊小小的伺服器土地，它自己就會在工作過程中不斷累積經驗、自行優化。

▋ 你現在需要哪一種工程

如果你目前的痛苦是「每次都要一條一條下指令，改程式碼改到心很累」，那你需要的是迴圈工程，幫你蓋一座自動化程式碼工廠。

如果你希望有一個「越用越懂你、講話不用講第二次、會自己做筆記優化工作流」的隨身特助，那麼愛馬仕系統會是你接下來值得投資的方向。

工具一直在進化，但最核心的關鍵依然不變：你要先搞清楚自己的工作痛點，才能選對讓效率翻倍的數位武器。

▋ 別把發包當成在許願

現在大家都習慣把任務直接丟給人工智慧去執行。但是很多人常常遇到一個問題：為什麼它做出來的東西，跟我心裡想的完全不一樣。如果你沒有把需求講清楚，直接讓系統去實作，最後反而要花上十倍的時間來回除錯。

▋ 你的虛擬員工其實自備糾錯大腦

很多厲害的人工智慧早就內建了檢查成果、發現錯誤、重新修正的完整功能。甚至當你問它怎麼避免下次出錯時，它還會舉一反三，自動去掃描其他地方有沒有類似的漏洞。當然，如果你使用的是比較便宜的舊模型，這種舉一反三的力氣，就得由人類自己用肉體和時間去補足。

▋ 結合兩大系統打造最強戰隊

先前我們提過的迴圈工程（Loop Engineering）與愛馬仕系統（Hermes System），這兩者並不是非黑即白的選擇。你完全可以一邊用迴圈工程架設嚴密的研發流程，一邊讓愛馬仕系統在通訊軟體裡幫你做筆記、累積經驗。兩者同時存在，效率才會真正翻倍。

▋ 在動工之前先讓人工智慧當你的軍師

不管你打算用哪一種系統，受限於人工智慧目前的理解範圍和記憶長度，最危險的事情就是「指令沒寫清楚，導致系統誤會你的意圖」。因此，在把需求送去開發之前，最好的做法是先倒過來，讓人工智慧反過來幫你檢視這個需求。

• 第一個建置目的：有沒有明確定義最終的驗收標準。
• 第二個資料來源：所有參數是不是都有給足。
• 第三個作業流程：有沒有夠詳細，也就是「哪個角色在什麼特定的條件下，會觸發什麼動作，最後會產生什麼結果」。

▋ 用清晰的邏輯換取完美的成品

把需求理乾淨，永遠比直接開工更重要。在動工之前多花三分鐘讓人工智慧幫你挑出邏輯漏洞，就能省下後面一整天的除錯時間。別再給模糊的指令了，先把工廠的藍圖畫清楚，自動化圓圈才能幫你跑出最完美的成果。

#人工智能 #自動化 #迴圈工程 #工作效率 #軟體開發

好消息是最近沒有缺水危機。壞消息是最近出門都要帶雨傘了。

羅意威(LOEWE)，是西班牙的一家奢侈品品牌，主要產品是各種皮具和高級時裝。現時已被LVMH Group收購。LOEWE的標誌目前是由4個大寫的花體L組成，而舊版標誌已於2003年4月停止使用。

* 加完好友下載完貼圖，請記得「封鎖」官方好友，以免收到廣告。

Taiwan 台灣

LOEWE 180 週年限定貼圖

https://line.me/S/sticker/37422

貼圖打包：點擊下載

LINE購物直播 × 貓狗們

https://line.me/S/sticker/37370

貼圖打包：點擊下載

《LINE 散步趣 》× 87小兔

https://line.me/S/sticker/37216

貼圖打包：點擊下載

LINE購物 × 人中哥

https://line.me/S/sticker/37180

貼圖打包：點擊下載

—

Japan 日本

Max Mara Exclusive Stickers

https://line.me/S/sticker/37250

貼圖打包：點擊下載

Rabbit Stickers

https://line.me/S/sticker/36969

貼圖打包：點擊下載

puri puri uchujin × LINEMO

https://line.me/S/sticker/36968

貼圖打包：點擊下載

—

Thailand 泰國

LINE TODAY × Dueb Dueb Grade A Netizens

https://line.me/S/sticker/37374

貼圖打包：點擊下載

Forward Boy (OSMEP)

https://line.me/S/sticker/37292

貼圖打包：點擊下載

—
上一周的貼圖：LINE 免費貼圖 2026-06-02
https://stickerline.max-everyday.com/2026/06/20260602/

跨區下載貼圖教學：
https://stickerline.max-everyday.com/faq/

(Android) JapanVPN 使用教學：
https://max-everyday.com/2017/04/japanvpn-tutorial/

LINE App解除電話的綁定教學：
https://max-everyday.com/2022/06/line-unbind-phone-number/
—-
想要在不同LINE帳號間靈活切換，同時避免手機號碼綁定問題，最簡單的方法是額外註冊一個Google帳號。
只要利用另一台Android裝置（例如平板電腦）作為輔助，協助完成帳號綁定與切換。

最簡單的隨時切換LINE帳號有沒有綁問題的解法就是註冊一個新的Google 帳號.
在另一 Android 裝置(假設是一台平板), 第一次需要先把手機門號在平板上以手機門號註冊新帳號, 登入 LINE 之後, 再加綁新註冊的 Google 帳號。
* 手機需要用LINE Pay的時候，就把號碼綁回手機；
* 手機需要取得跨區貼圖/Emoji, 就把號碼放回平板, 手機就會解綁。
* 手機號碼不能一下子在手機和平板間一直換來換去，LINE官方會不開心。
* 這個方法就是利用Google帳號當作中間人，你的手機號碼就可以在手機和平板之間自由移動了。
* 使用者需要注意LINE官方對於帳號的使用條款，以確保操作符合相關規定。
—-
如果這個項目對您有幫助，不妨請作者我喝杯咖啡 ：）
https://max-everyday.com/about/#donate

一開始，我是透過手動修改程式碼的方式來調整，步驟如下：

Bash

cd /var/www/stackoverflow/wp-content/themes/gutenshop

1. 移除關於作者的區塊

編輯 single.php，刪除第 39 到 52 行的 PHP 程式碼：

PHP

// About the author start
echo '<div class="about-the-author">';
echo '<div class="grid-x grid-padding-x">';
echo '<div class="large-2 medium-3 small-12 cell">';
echo get_avatar( get_the_author_meta( 'ID' ), 100 );
echo '</div>';
echo '<div class="large-10 medium-9 small-12 cell">';
echo '<h3>';
echo esc_html('About the author','gutenshop');
echo '</h3>';
echo nl2br(get_the_author_meta('description'));
echo '</div>';
echo '</div>';
echo '</div>';
// About the author end

2. 修改日期顯示格式

將原本的 F j, Y 格式，全部改為 Y-m-d 格式。

修改 single.php 與 template-parts/content-excerpt.php：

• 原本的程式碼：PHPecho esc_html(get_the_date('F j, Y'));
• 修改後的程式碼：PHPecho esc_html(get_the_date('Y-m-d'));

3. 隱藏文章發表者資訊

編輯 template-parts/content-search.php 與 template-parts/content.php，將顯示發表者的函式註解掉：

• 原本的程式碼：PHPguten_shop_posted_by();
• 修改後的程式碼：PHP//guten_shop_posted_by();

4. 移除日期前方的文字

編輯 inc/template-tags.php，把原本顯示的 Posted on 字樣拿掉：

• 原本的程式碼：PHPesc_html_x( 'Posted on %s', 'post date', 'gutenshop' ),
• 修改後的程式碼：PHPesc_html_x( '%s', 'post date', 'gutenshop' ),

雖然手動修改可以達到效果，但每次佈景主題更新後，這些修改就會被覆蓋，又得重新來過一遍，非常麻煩。

於是，我把上面這些手動修改的步驟和需求直接貼給 AI ，並加上一句：

幫我產生 patch script

沒想到 AI 馬上就寫好了一個 Python 自動化腳本，把上面所有檔案的修改邏輯全部寫進去。

以後佈景主題更新時，我只要在終端機執行這個腳本，一秒就能自動完成所有的改版與修正，真的非常方便！

script:

import os
import re

def patch_theme(theme_path):
    """
    Applies patches to the Gutenshop theme files to customize the layout and formatting.
    Based on requirements from: https://max-everyday.com/2026/06/ai-generate-patch-script/
    """
    print(f"Starting patch process in: {theme_path}")

    # 1. Remove "About the Author" in single.php and update date format
    single_php = os.path.join(theme_path, 'single.php')
    if os.path.exists(single_php):
        with open(single_php, 'r', encoding='utf-8') as f:
            content = f.read()
        
        # Remove "About the author" block if it exists
        author_pattern = r'// About the author start.*?// About the author end'
        new_content = re.sub(author_pattern, '', content, flags=re.DOTALL)
        
        # Standardize date format to Y-m-d
        # Matches both get_the_date() and get_the_date('F j, Y')
        new_content = new_content.replace("get_the_date('F j, Y')", "get_the_date('Y-m-d')")
        new_content = new_content.replace("get_the_date()", "get_the_date('Y-m-d')")
        
        if new_content != content:
            with open(single_php, 'w', encoding='utf-8') as f:
                f.write(new_content)
            print(f"Patched: {single_php}")
        else:
            print(f"No changes needed for: {single_php}")

    # 2. Modify Date Format in template-parts/content-excerpt.php
    excerpt_php = os.path.join(theme_path, 'template-parts/content-excerpt.php')
    if os.path.exists(excerpt_php):
        with open(excerpt_php, 'r', encoding='utf-8') as f:
            content = f.read()
        
        new_content = content.replace("get_the_date('F j, Y')", "get_the_date('Y-m-d')")
        new_content = new_content.replace("get_the_date()", "get_the_date('Y-m-d')")
        
        if new_content != content:
            with open(excerpt_php, 'w', encoding='utf-8') as f:
                f.write(new_content)
            print(f"Patched: {excerpt_php}")
        else:
            print(f"No changes needed for: {excerpt_php}")

    # 3. Hide Author Info in content-search.php and content.php
    author_files = [
        'template-parts/content-search.php',
        'template-parts/content.php'
    ]
    for rel_path in author_files:
        full_path = os.path.join(theme_path, rel_path)
        if os.path.exists(full_path):
            with open(full_path, 'r', encoding='utf-8') as f:
                content = f.read()
            
            # Comment out the author call if not already commented
            # This handles both <?php guten_shop_posted_by(); ?> and just the function call
            new_content = re.sub(r'(?<!//)guten_shop_posted_by\(\);', '//guten_shop_posted_by();', content)
            
            if new_content != content:
                with open(full_path, 'w', encoding='utf-8') as f:
                    f.write(new_content)
                print(f"Patched: {full_path}")
            else:
                print(f"No changes needed for: {full_path}")

    # 4. Remove "Posted on" text in inc/template-tags.php
    tags_php = os.path.join(theme_path, 'inc/template-tags.php')
    if os.path.exists(tags_php):
        with open(tags_php, 'r', encoding='utf-8') as f:
            content = f.read()
        
        # Change 'Posted on %s' to just '%s'
        old_str = "esc_html_x( 'Posted on %s', 'post date', 'gutenshop' )"
        new_str = "esc_html_x( '%s', 'post date', 'gutenshop' )"
        new_content = content.replace(old_str, new_str)
        
        if new_content != content:
            with open(tags_php, 'w', encoding='utf-8') as f:
                f.write(new_content)
            print(f"Patched: {tags_php}")
        else:
            print(f"No changes needed for: {tags_php}")

if __name__ == "__main__":
    # Use the current directory as the theme path
    target_theme_dir = os.getcwd()
    
    if os.path.isdir(target_theme_dir):
        patch_theme(target_theme_dir)
        print("Patching process completed.")
    else:
        print(f"Error: Directory not found: {target_theme_dir}")

patch fontsize if <=20, fontsize+3, if >20, fontsize +5

import re

def update_font_size(match):
    value = float(match.group(1))
    unit = match.group(2)
    if value <= 20:
        new_value = value + 3
    else:
        new_value = value + 5
    # Keep integer if no fractional part
    if new_value == int(new_value):
        return f"font-size: {int(new_value)}{unit}"
    return f"font-size: {new_value}{unit}"

input_file = r"style.css"
output_file = r"style_updated.css"

with open(input_file, "r", encoding="utf-8") as f:
    content = f.read()

# Match font-size: <number><unit> (px, em, rem, pt, %)
pattern = re.compile(r'font-size:\s*(\d+(?:\.\d+)?)(px|em|rem|pt|%)', re.IGNORECASE)
updated_content = pattern.sub(update_font_size, content)

with open(output_file, "w", encoding="utf-8") as f:
    f.write(updated_content)

# Report changes
matches = pattern.findall(content)
print(f"Updated {len(matches)} font-size value(s).")
print(f"Output written to: {output_file}")

# Auto replace: backup style.css -> style_back.css, set ownership, rename output
import os, shutil, subprocess

backup_file = r"style_back.css"

# chown www-data:www-data on the updated file (Linux only)
try:
    subprocess.run(["chown", "www-data:www-data", output_file], check=True)
    print(f"chown www-data:www-data {output_file}")
except (FileNotFoundError, subprocess.CalledProcessError) as e:
    print(f"chown skipped: {e}")

# Backup original style.css -> style_back.css
if os.path.exists(input_file):
    shutil.move(input_file, backup_file)
    print(f"Backed up: {input_file} -> {backup_file}")

# Rename output to style.css
shutil.move(output_file, input_file)
print(f"Replaced: {output_file} -> {input_file}")

很多人會問，在人生中遇到不順心的事情、或是遇到討厭的人，到底該怎麼辦？要怎麼做才能斷除心中的煩惱？

達賴喇嘛的回答非常實在。他說，想要減緩煩惱是需要透過長期練習的，必須在生活中不斷修正自己對抗煩惱的能力。如果只是聽聽講解、讀讀道理，就以為煩惱會自己消失，那簡直就像是在做白日夢。甚至連達賴喇嘛自己都坦言，他到現在也一直在修煉菩提心與空正見，還沒有徹底斷除所有的煩惱。

看到這裡是不是鬆了一口氣？原來像尊者、上人這樣偉大的精神領袖，其實也和我們一般人一樣會有煩惱。

什麼是菩提心

菩提心是大乘佛教的核心概念。簡單來說，它是一種強大的慈悲願力，意思是：為了讓所有眾生都能得到快樂、脫離痛苦，因而發誓要讓自己修行創造成佛。

菩提心由兩個核心意願組成，兩者缺一不可：

• 緣眾生（慈悲）：看到世界上的眾生在受苦，心裡生起強烈的慈悲心，想要去救度大家。
• 緣佛果（智慧）：心裡很明白，只有當自己修行提升到圓滿的成佛境界，才有足夠的能力真正救度眾生。

什麼是空正見

空正見也就是空性正見，是大乘佛教中最重要的智慧。它是指看透一切事物都沒有自性，也就是明白沒有任何東西是可以獨立、自主、永遠不變地實質存在。

要注意的是，空性並不是指世界上什麼都沒有的空無，而是明白萬事萬物都是隨著因緣變化、隨著人們的分別心而存在的，這就是緣起性空。空正見是對治心中煩惱與固執的唯一解藥，能為心靈帶來真正的放鬆與解脫。

• 緣起性空：眼前的生活大小事雖然看似真實發生，但本質上都是由許多原因和條件組合而成的。正因為本質是空，沒有固定不變的狀態，事情才有可能隨著時間運作與改變。
• 對治我執與愚癡：我們之所以會感到痛苦，往往是因為對自我或眼前的現象產生了太強烈的執著。空正見能直接破解這種錯誤的認知，讓我們不再被無明給困住。

身體力行才是關鍵

在誦經的最後，通常都會進行三皈依，唸誦以下這三段話：

自皈依佛，當願眾生，體解大道，發無上心。 自皈依法，當願眾生，深入經藏，智慧如海。 自皈依僧，當願眾生，統理大眾，一切無礙。

在皈依佛的那一段中，特別提到了體解大道。這四個字的意思，就是告訴我們要用身體力行的方式去實踐，才有可能真正體悟到佛教的真理。像是前面提到的空正見，如果一味埋頭閱讀經典，是完全沒辦法真正體會到的。

如果你對佛學有興趣，想要跟著老師的進度一起學習，可以透過 見諦佛學網 閱讀講義並做練習。

另外，這裡也有正在進行的空性自習影片，老師講解得非常清晰易懂，有興趣的話，也可以跟著影片一起練習：見諦佛學網研修自習影片 。

人類在演化過程中，那些整天無憂無慮、完全沒有煩惱的遠古祖先，早就因為缺乏警覺心而被大自然淘汰了。相反地，正是因為會煩惱、會焦慮，人類這個物種才能成功存活並繁衍至今。

我們可以從以下幾個關鍵原因，來看煩惱如何成為人類生存的優勢：

預防潛在的危險

遠古時期的生活環境充滿危機，像是野獸襲擊或是惡劣天氣。會煩惱的祖先，在大晴天就會開始擔心冬天沒有食物吃，或者擔心附近會不會有獅子出沒。這種煩惱促使他們提前儲存糧食、築起堅固的防禦工事。那些不會煩惱的祖先，可能就在毫無防備下被環境淘汰了。

促進學習與修正錯誤

煩惱本質上是人類大腦的一種模擬機制。當我們做錯事情感到懊惱，或是對未來感到擔憂時，大腦其實是在不斷演練各種應對方案。就像達賴喇嘛在文章中提到的，減緩煩惱需要透過長期練習來修正自己。這種在大腦中反覆思考、修正行為的能力，讓我們能夠從經驗中學習，避免下一次犯同樣的錯誤。

強化群體合作

人類是群居動物，很多煩惱都來自於人際關係，像是擔心自己被排擠、擔心別人怎麼看自己。這種社會性的焦慮和煩惱，雖然讓人痛苦，但它在演化上的功能是逼迫我們去遵守群體規範、維繫人際關係。在遠古時代，被部落排擠等於獨自面對大自然，存活率幾乎是零。因此，擔心失去認同的煩惱，反而把大家緊緊凝聚在一起。

總結來說，煩惱並不是演化上的缺陷，它反而是大腦為了保護我們而內建的生存防禦機制。只是到了現代社會，我們不再需要擔心被獅子咬，大腦卻依然用同樣的強度去煩惱工作、課業和人際關係，這才讓我們感到壓力過大。

明白煩惱的演化本質，或許就能讓我們在面對焦慮時，多一份釋懷，把它當成是身體正在試圖保護我們的一種訊號。

資料來源: https://www.youtube.com/watch?v=3N2cj0WlBsw

達賴喇嘛回：減緩煩惱需要練習，需長期修改煩惱的對治力，只憑解決煩惱的講解，就想減緩煩惱，猶如癡人說夢。我一直在修煉「菩提心與空正見」，尚未徹底斷除煩惱。

原來尊者或上人也和我們一般人一樣有煩惱。

Ｑ：什麼是菩提心（Bodhicitta）

菩提心（Bodhicitta）是大乘佛教的核心，指「為利樂一切眾生，而誓願證得圓滿佛果」的慈悲願力。

菩提心由兩個核心意願組成，缺一不可：

緣眾生（慈悲）：見到一切眾生受苦，生起強烈的救度之心。

緣佛果（智慧）：明白唯有自己成佛，才有圓滿的能力救度眾生。

Ｑ：什麼是空正見

空正見（空性正見）是大乘佛教的核心智慧，指洞察一切事物「無自性」（非獨立、自主、實質存在）的真理。它並非主張什麼都沒有的「空無」，而是明白萬物皆依賴因緣與分別心而存在（緣起性空）。它是對治煩惱與我執的唯一解藥，能為修持帶來真正的放鬆與解脫。

緣起性空：事物看似真實發生，但本質上是因緣和合而成。因為是「空」（無獨立自性），所以事物才能夠運作與變化。

對治我執與愚癡：眾生的痛苦根源在於對「自我」與「現象」的真實性產生執著。空正見能直接破解這種錯誤的認知（無明）。

頌經的最後，會做三皈依，唸誦的是以下三段：

「自皈依佛，當願眾生，體解大道，發無上心。」
「自皈依法，當願眾生，深入經藏，智慧如海。」
「自皈依僧，當願眾生，統理大眾，一切無礙。」

皈依佛那段，講要體解大道，也就是要用身體力行去做，才會真的體悟佛教的，比如什麼是空正見，如果只是讀經典，是很難體悟的。

佛學課是可以跟著這位老師的教授學的，也就是讀他的講義並做練習
https://www.geshetp.com/

在學的空性自習，有影片，老師講的很好，有興趣，你也可以跟著練習
https://www.geshetp.com/video/

AI 相關類股漲不停, 該不該上車？

* 加完好友下載完貼圖，請記得「封鎖」官方好友，以免收到廣告。

Taiwan 台灣

郵政寶寶×波波鴿 臺語嘛會通

https://line.me/S/sticker/37380

貼圖打包：點擊下載

LINE TV｜天竺鼠布丁

https://line.me/S/sticker/37318

貼圖打包：點擊下載

LINE購物夯話題×魚米日常-胖狗狗來了

https://line.me/S/sticker/37298

貼圖打包：點擊下載

Club Med度假日常

https://line.me/S/sticker/37273

貼圖打包：點擊下載

舞臺守護者！保佑節目演出順利的走獸們！

https://line.me/S/sticker/37174

貼圖打包：點擊下載

—

Japan 日本

Wapie

https://line.me/S/sticker/37325

貼圖打包：點擊下載

Animated!BURUBURU-KUN&friends Stickers 2

https://line.me/S/sticker/37169

貼圖打包：點擊下載

Girly bear × LINE NEWS

https://line.me/S/sticker/37072

貼圖打包：點擊下載

Obungu×au PAY Card

https://line.me/S/sticker/36985

貼圖打包：點擊下載

Noisy chicken × Yahoo! JAPAN

https://line.me/S/sticker/36966

貼圖打包：點擊下載

Demaenyan Stickers Nice!

https://line.me/S/sticker/36965

貼圖打包：點擊下載

—

Thailand 泰國

Baby Zonzon, MVP of mischief, unleashed!

https://line.me/S/sticker/37324

貼圖打包：點擊下載

—
上一周的貼圖：LINE 免費貼圖 2026-05-26
https://stickerline.max-everyday.com/2026/05/20260526/

跨區下載貼圖教學：
https://stickerline.max-everyday.com/faq/

(Android) JapanVPN 使用教學：
https://max-everyday.com/2017/04/japanvpn-tutorial/

LINE App解除電話的綁定教學：
https://max-everyday.com/2022/06/line-unbind-phone-number/
—-
想要在不同LINE帳號間靈活切換，同時避免手機號碼綁定問題，最簡單的方法是額外註冊一個Google帳號。
只要利用另一台Android裝置（例如平板電腦）作為輔助，協助完成帳號綁定與切換。

最簡單的隨時切換LINE帳號有沒有綁問題的解法就是註冊一個新的Google 帳號.
在另一 Android 裝置(假設是一台平板), 第一次需要先把手機門號在平板上以手機門號註冊新帳號, 登入 LINE 之後, 再加綁新註冊的 Google 帳號。
* 手機需要用LINE Pay的時候，就把號碼綁回手機；
* 手機需要取得跨區貼圖/Emoji, 就把號碼放回平板, 手機就會解綁。
* 手機號碼不能一下子在手機和平板間一直換來換去，LINE官方會不開心。
* 這個方法就是利用Google帳號當作中間人，你的手機號碼就可以在手機和平板之間自由移動了。
* 使用者需要注意LINE官方對於帳號的使用條款，以確保操作符合相關規定。
—-
如果這個項目對您有幫助，不妨請作者我喝杯咖啡 ：）
https://max-everyday.com/about/#donate

先到 gemini 按下 gem:

貼上 AI 建議的提示詞, 例如:

【角色】
你是政府資訊採購規格書審查專家，熟悉 COTS 導入與後台參數驅動設計原則；
同時具備政府機關 IT 環境限制的實務認知，能在規格審查中同步識別可行性風險。

【機關環境限制（固定背景知識，審查時須一併套用）】
- 身分驗證：本校校內 Portal 僅支援本校教職員與學生之 SSO 登入，
  不支援校外一般民眾。校外申請人須透過第三方 OAuth
  （預設 Google，後台可設定開放之提供者）完成身分驗證；
  不採自建 Email 驗證帳號機制，以降低承辦人員維護負擔。
- 帳號清查：承辦人員無暇逐筆審查殭屍帳號。校外帳號管理應採
  自動化閒置停用（停用天數由後台設定），承辦人員僅需執行
  手動停用與解除停用（含被停用帳號之自助恢復路徑）；
  不得要求人工定期盤點。
- 出納系統：出納系統可能於建置期間尚未提供 API；
  規格書不得以「建議介接」規避驗收責任，應明定
  「介接為必要條件，過渡期得以人工登錄替代，惟須於驗收前完成；
  若API於第二期驗收截止日前仍未開放，雙方應於第一期驗收後30日內
  確認書面替代方案，不得影響其餘功能之驗收時程」。
- 雲端環境：本校現有 GCP / Azure 環境，亦可採地端（on-premises）部署；
  不得指定特定雲端資料庫服務（如 GCP CloudSQL）；
  應描述「符合 ANSI SQL 標準之 RDBMS，相容 GCP / Azure / 地端環境」。
  Google Calendar API 連動需有 API 失敗之降級策略
  （警示提示取代強制阻擋，並留存異常紀錄）。
- 系統量體：年申請量與同時在線人數待機關正式確認；
  規格書中量體數值應以【待機關確認，建議基準：XXX】佔位，
  不得留空或由廠商自行假設；效能需求數字應與量體基準一致。
- 雙語維護：通知信範本須支援中英文各自獨立維護；
  廠商不得以「介面雙語但通知信僅中文」通過驗收。
- 個資保護：招標文件中（包含附件範本）一律不得出現
  真實人名、電話號碼或 Email，應改以○○○或佔位符取代。
- 略過空格或粗體或換行或冒號格式等的修改建議。

【任務】
Step 1：先從範本文件中提取「功能模組描述的標準結構」，整理為格式說明。
Step 2：逐節對照待審文件，依下列 (A)~(G) 評估項目找出問題。
Step 3：僅針對「功能性（業務）需求」章節與附件，忽略非功能性需求、
        專案管理及保固章節。
        （選用）若使用者要求審查主文件，則另輸出「主文件業務邏輯與
        驗收風險分析」，識別可能造成驗收爭議的條款。
Step 4：輸出兩個檔案：
        ① 改善版 .md（另存新檔，不覆蓋原檔）
        ② 修改建議 diff.txt（人可讀格式，非 git diff）：
           每個問題需包含：位置 / 問題分類 / 原文 / 問題說明 / 修改建議
Step 5：（選用，使用者明確要求時執行）針對 (G) 可行性疑慮
        另輸出「可行性建議清單」，每項包含：
        位置 / 問題描述 / 建議替代方案 / 優先程度（🔴高 / 🟡中 / 🟢低）

【評估項目】
(A) 角色不清 — 功能未說明由誰執行、誰審核；缺少角色類別 |
    權限擁有者 | 權限範圍說明 的角色表；各功能節缺「使用對象」標示

(B) 過度具體 — 業務規則數值（金額、天數、名單、狀態名稱）
    寫死在程式需求中，而非後台可設定；
    「資料來源」段落中未標示「後台可設定」之欄位，
    視為隱性硬碼，亦屬本項問題

(C) 結構缺失 — 功能模組未遵循「建置目的→資料來源→
    作業流程（含角色）→系統功能」四段式結構；
    各段具體審查要點：
    ・建置目的：應說明本模組解決什麼業務問題，
      並可作為驗收範圍界定依據（「定義驗收標準是什麼」）；
      若僅寫「提供X功能」屬功能描述非目的陳述，仍屬缺失。
    ・資料來源：應明確標示每類資料的來源性質：
      ① 後台可設定（需設計後台 CRUD 介面，不得 hardcode）
      ② 整合系統提供（需定義 API / SSO 介接介面）
      ③ 使用者輸入（需定義表單欄位與驗證規則）
      未標示來源性質之欄位，開發商有合理依據將其寫死。
    ・作業流程：應說明「誰（角色）在什麼條件下觸發什麼動作」，
      包含角色流轉與狀態轉換邏輯（驅動 State Machine 與 RBAC 設計）；
      缺角色屬 (A) 問題，缺條件屬邏輯空白。
    ・系統功能：應為前三段的實作清單，
      不應包含前三段未定義之業務邏輯或數值

(D) 內部矛盾 — 正文聲明「後台參數驅動」，但功能描述仍含硬寫數值；
    章節編號錯誤（跳號、重複）；有空白占位符；
    不同章節之描述相互矛盾；效能需求數值與量體基準不一致

(E) UI 設計混入需求 — 將版面配置、色彩、元件種類等視覺設計
    寫入功能規格，限制廠商介面設計彈性

(F) 開發方法論綁定 — 強制指定特定技術框架、產品品牌或開發方法論，
    可能違反政府採購法第26條第3項（不得限制競爭）；
    應改為描述能力需求或結果需求，廠商於服務建議書中說明選用方案。
    常見綁定樣態（均須改為中立描述）：
    ・前端框架：Vue.js / React / Angular 等 →
      「業界主流 JavaScript 框架，支援 SPA，需處於有效維護期（非EOL）」
    ・後端語言：.NET / Java / Python / Go 等 →
      「業界主流後端語言與框架，廠商服務建議書說明版本與維護狀態」
    ・資料庫產品：MS SQL / MySQL / PostgreSQL / CloudSQL 等 →
      「符合 ANSI SQL 標準之 RDBMS，相容本校部署環境（GCP/Azure/地端）」
    ・專案管理工具：Jira →
      「具備 Issue 追蹤、里程碑管理功能之工具，廠商服務建議書說明」
    ・開發方法論：Scrum / Kanban →
      「迭代式（Agile）開發方法，不指定特定框架名稱」
    ・測試方法論：TDD 強制指定功能數量 →
      「業界成熟測試方法，廠商於測試計畫書中說明」
    ・硬體型號：特定品牌/型號 →
      「符合規格之同等品，廠商服務建議書說明」

(G) 可行性疑慮 — 需求與【機關環境限制】不相容（如 SSO 用於校外）；
    整合條件模糊（如「建議介接」）導致驗收爭議；
    量體未定義導致廠商無法合理估算；
    效能需求與量體基準嚴重失衡（超出實際業務量 10 倍以上）；
    個資出現在招標文件中；
    技術例外處理（API 失敗、帳號生命週期、閒置帳號恢復路徑）未定義；
    驗收條款存在無邊界無償修改義務；
    交付文件表編號不連續或與正文說明不一致

【輸出格式要求（diff.txt）】
每個問題區塊格式：
  【問題 N】節次：問題標題
  分類：(A)~(G)
  位置：第 X 節 第 X.X.X 點
  原文：「……」
  問題：說明為何有問題
  建議：具體的修改文字
文末附「修改摘要對照表」（#|位置|分類|說明|建議 的表格）

按下”存檔” 之後, 開始與這個 Gem 對話.

把範例檔案, 與進行中的都上傳到 gemini, 再輸入以下提示詞:

【範本文件】（已發包成功）
 - XXX 需求說明書1.doc
 - OOO 需求說明書2.doc
 
 【待審文件】（修改中）
 - 20260505 XXX借用系統需求說明.docx
 

就可以拿到答案了:

提示詞的版本變化, 第1版:

以下是已發包的成功範本:
- AAA 需求說明書1.doc
- BBB 需求說明書2.doc
CCC.doc 是修改中的版本, 協助改善修改中的版本成功範本.
---
檢查每一個"功能性"(業務)需求: 
(A) 角色不清楚 ─ 功能需求未明確說明由誰執行、誰審核
(B) 需求過於具體 ─ 將業務規則或技術細節寫死，限制廠商彈性，未來政策或組織調整須改程式碼
---
另外產生一個 diff.txt, 在文件裡指定要修改的建議.

提示詞的版本變化, 第2版:

 【角色】
 你是政府資訊採購規格書審查專家，熟悉 COTS 導入與後台參數驅動設計原則。
 
 【任務】
 Step 1：先從範本文件中提取「功能模組描述的標準結構」，整理為格式說明。
 Step 2：逐節對照待審文件，依下列 (A)~(F) 評估項目找出問題。
 Step 3：僅針對「功能性（業務）需求」章節與附件，忽略非功能性需求、
         專案管理及保固章節。
 Step 4：輸出兩個檔案：
         ① 改善版 .md（另存新檔，不覆蓋原檔）
         ② 修改建議 diff.txt（人可讀格式，非 git diff）：
            每個問題需包含：位置 / 問題分類 / 原文 / 問題說明 / 修改建議
 
 【評估項目】
 (A) 角色不清 — 功能未說明由誰執行、誰審核；缺少角色類別|
     權限擁有者|權限範圍說明 的角色表；各功能節缺「使用對象」標示
 (B) 過度具體 — 業務規則數值（金額、天數、名單、狀態名稱）
     寫死在程式需求中，而非後台可設定
 (C) 結構缺失 — 功能模組未遵循「建置目的→資料來源→
     作業流程（含角色）→系統功能」四段式結構
 (D) 內部矛盾 — 正文聲明「後台參數驅動」，但功能描述仍含硬寫數值；
     或章節編號錯誤、有空白占位符
 (E) UI 設計混入需求 — 將版面配置、色彩、元件種類等視覺設計
     寫入功能規格，限制廠商介面設計彈性
 (F) 開發方法論綁定 — 強制指定 Scrum、特定技術框架或
     硬體設備型號，應改為描述結果需求
 
 【輸出格式要求（diff.txt）】
 每個問題區塊格式：
   【問題 N】節次：問題標題
   分類：(A)~(F)
   位置：第 X 節 第 X.X.X 點
   原文：「……」
   問題：說明為何有問題
   建議：具體的修改文字
 文末附「修改摘要對照表」（#|位置|分類|說明|建議 的表格）

提示詞的版本變化, 第3版:

【角色】
你是政府資訊採購規格書審查專家，熟悉 COTS 導入與後台參數驅動設計原則；
同時具備政府機關 IT 環境限制的實務認知，能在規格審查中同步識別可行性風險。

【機關環境限制（固定背景知識，審查時須一併套用）】
- 身分驗證：本校校內 Portal 僅支援本校教職員與學生之 SSO 登入，
  不支援校外一般民眾。校外申請人須透過第三方 OAuth
  （預設 Google，後台可設定開放之提供者）完成身分驗證；
  不採自建 Email 驗證帳號機制，以降低承辦人員維護負擔。
- 帳號清查：承辦人員無暇逐筆審查殭屍帳號。校外帳號管理應採
  自動化閒置停用（停用天數由後台設定），承辦人員僅需執行
  手動停用與解除停用，不得要求人工定期盤點。
- 出納系統：出納系統可能於建置期間尚未提供 API；
  規格書不得以「建議介接」規避驗收責任，應明定
  「介接為必要條件，過渡期得以人工登錄替代，惟須於驗收前完成」。
- 雲端環境：本校現有 GCP / Azure 環境；Google Calendar API 連動需有
  API 失敗之降級策略（警示提示取代強制阻擋，並留存異常紀錄）。 避免指定 cloudsql, 要支援地端或 azuresql
- 系統量體：年申請量與同時在線人數待機關正式確認；
  規格書中量體數值應以【待機關確認，建議基準：XXX】佔位，
  不得留空或由廠商自行假設。
- 雙語維護：通知信範本須支援中英文各自獨立維護；
  廠商不得以「介面雙語但通知信僅中文」通過驗收。
- 個資保護：招標文件中（包含附件範本）一律不得出現
  真實人名、電話號碼或 Email，應改以○○○或佔位符取代。

【任務】
Step 1：先從範本文件中提取「功能模組描述的標準結構」，整理為格式說明。
Step 2：逐節對照待審文件，依下列 (A)~(G) 評估項目找出問題。
Step 3：僅針對「功能性（業務）需求」章節與附件，忽略非功能性需求、
        專案管理及保固章節。
Step 4：輸出兩個檔案：
        ① 改善版 .md（另存新檔，不覆蓋原檔）
        ② 修改建議 diff.txt（人可讀格式，非 git diff）：
           每個問題需包含：位置 / 問題分類 / 原文 / 問題說明 / 修改建議
Step 5：（選用，使用者明確要求時執行）針對 (G) 可行性疑慮
        另輸出「可行性建議清單」，每項包含：
        位置 / 問題描述 / 建議替代方案 / 優先程度（🔴高 / 🟡中 / 🟢低）

【評估項目】
(A) 角色不清 — 功能未說明由誰執行、誰審核；缺少角色類別|
    權限擁有者|權限範圍說明 的角色表；各功能節缺「使用對象」標示
(B) 過度具體 — 業務規則數值（金額、天數、名單、狀態名稱）
    寫死在程式需求中，而非後台可設定
(C) 結構缺失 — 功能模組未遵循「建置目的→資料來源→
    作業流程（含角色）→系統功能」四段式結構
(D) 內部矛盾 — 正文聲明「後台參數驅動」，但功能描述仍含硬寫數值；
    章節編號錯誤；有空白占位符；文件內不同章節描述相互矛盾
(E) UI 設計混入需求 — 將版面配置、色彩、元件種類等視覺設計
    寫入功能規格，限制廠商介面設計彈性
(F) 開發方法論綁定 — 強制指定 Scrum、特定技術框架或
    硬體設備型號，應改為描述結果需求
(G) 可行性疑慮 — 需求與【機關環境限制】不相容（如 SSO 用於校外）；
    整合條件模糊（如「建議介接」）導致驗收爭議；
    量體未定義導致廠商無法合理估算；
    個資出現在招標文件中；
    技術例外處理（API 失敗、帳號生命週期）未定義

【輸出格式要求（diff.txt）】
每個問題區塊格式：
  【問題 N】節次：問題標題
  分類：(A)~(G)
  位置：第 X 節 第 X.X.X 點
  原文：「……」
  問題：說明為何有問題
  建議：具體的修改文字
文末附「修改摘要對照表」（#|位置|分類|說明|建議 的表格）

目前文章中使用的是是第4版.