Day 02｜Linux 工程師上線：地基還牢嗎

🤖 AI 參與等級：🤝 AI 起草＋人類重寫

第一位隊友上線：Linux 工程師。

選它開場不是意外。這支 Tech Team 的其他座位——SRE、DevOps、資料庫、雲端成本——全部踩在同一塊地基上。而 Linux 剛好也是所有 TL「以為自己懂」的座位：誰沒敲過幾年終端機呢？

但「敲過」和「最近重新檢查過」是兩回事。導入 AI 之後，這個座位的日常還剩多少要人？今天的實驗：我把 Linux 工程師的日常拆成三道題，出給 grok bot，看它能接住幾道。

這個座位做什麼

一句話：讓伺服器活著，而且活得可預期。

拆開是：系統與權限、檔案系統、行程與服務（systemd）、套件管理、shell 自動化、日誌與開機排障。學習路線的公開基準是 roadmap.sh 的 Linux 路線圖，查證的兩個老朋友是 Arch Wiki 和 man7.org——這三個連結我也交給 grok bot 當今天的教材。

先亮預判（座位卡的答案）

• 可代打：指令生成、設定檔模板、log 解讀、錯誤訊息翻譯
• 人類必盯：權限變更（chmod/chown/sudo）、rm 類破壞性操作、正式機上的任何一行

為什麼盯這三樣？因為 AI 寫錯一個查詢是品質問題，AI 寫錯一個 rm 是營運事故。這個座位的特殊性：它離「不可逆」最近。

三道題

題一：警報響了（排障題）

情境：凌晨兩點，磁碟空間告警，/ 使用率 92%。

提示詞（可直接抄）：

你是 Linux 營運工程師。伺服器根目錄使用率 92%，告警中。請：1) 列出找出大檔案與大目錄的診斷指令（不要執行任何刪除）2) 說明各種常見根因（日誌輪替失效、套件快取、應用產物、匿名刪除中的檔案）各怎麼判別 3) 標明哪些後續動作不可逆。

蓋章點：它會不會跳過診斷直接建議刪東西？有沒有主動把破壞性指令標出來？「已刪除但空間沒釋放」的行程佔用問題想得到嗎？

題二：把服務交代清楚（systemd 題）

提示詞：

為一個 Python 程式寫 systemd unit：開機自啟、崩潰自動重啟（間隔五秒）、日誌進 journald、以專用使用者執行。附安裝指令與「怎麼驗證它裝好了」。

蓋章點：Restart=on-failure 和 always 的取捨有沒有講？專用使用者（而不是 root）有沒有主動想到？有沒有給驗證指令——還是裝完就沒下文？

題三：門鎖檢查（安全題）

提示詞：

審查這台伺服器的 SSH 設定（sshd_config 附後）：找出最該修的三個項目，按風險排序，並說明每項修復的副作用——例如會不會把現有連線鎖在外面。

蓋章點：PermitRootLogin、PasswordAuthentication、AllowUsers 抓得到嗎？「先開新連線、驗證能登、再關舊設定」的順序提醒——這是經驗和背題的差別。

帶走物：Linux 座位的每週體檢清單

十條，AI 每週跑一遍、彙整成人話回報：

1. 磁碟：df -h，還有 df -i——inode 滿了空間再大也白搭
2. 服務：systemctl --failed 有沒有躺屍
3. 安全更新：掛著沒裝的有幾個
4. 備份：備份 job 昨晚有沒有成功；上次「真的還原演練」是什麼時候
5. 帳號：/etc/passwd 有沒有新面孔；sudo 群清單變長了嗎
6. 日誌：journalctl -p err --since week 的新錯誤
7. 負載：load 與記憶體的趨勢（不是當下值）
8. 憑證：SSH 金鑰與 TLS 憑證的到期日
9. 防火牆：開著的 port 跟文件上寫的一致嗎
10. 時序：NTP 同步——時間漂移會殺認證與排程

我的預判：1–8 會被 AI 整包吃掉（跑、彙整、用人話回報），9 和 10 的「判斷與決策」留給人類。三十天後回來驗證這句話。

跟著做：把你的 Hermes 設定成這位隊友

不用等我把隊友一個個介紹完——你可以自己養。排班佇列裡的第四位隊友 Hermes（Nous Research 的開源自架 agent，Day 25 正式介紹）用三個檔案定義一個隊友：

• SOUL.md → ~/.hermes/SOUL.md：人格檔，由你手動維護，每次對話都注入（官方建議結構：一句身分宣言＋風格／避免事項／技術姿態）
• MEMORY.md → ~/.hermes/memories/MEMORY.md：它的學習記憶，條目制（以 § 分隔）、上限 2,200 字元，之後由它自己用 memory tool 增刪——你只給種子
• USER.md → ~/.hermes/memories/USER.md：你的偏好檔，同目錄、上限 1,375 字元

「基石」的出廠設定如下，整段可抄：

SOUL.md

# Personality

你是「基石」——這支沒有人的 Tech Team 的第一位隊友，Linux 工程師。
你是務實的資深系統工程師，信條只有一條：先診斷，後動手；不可逆的動作，永遠先停下來問。

## 風格

- 回答先給結論，再給指令；指令可逐行複製執行，每行附一句註解
- 任何會改變系統狀態的指令（systemctl、chmod、chown、rm、mkfs）一律標 [破壞性] 或 [需確認]
- 回覆長度跟著問題的重量：小問題三行內，事故現場才長篇

## What to avoid

- 不跳過診斷直接建議刪除、清理或重開機
- 不用「應該可以」交付正式機指令——不確定就明說不確定，標 [未驗證]
- 不塞客套話與行銷式吹捧

## Technical posture

- 排障從症狀往下挖：df -h → df -i → du → journalctl，先量測再改動
- 自動化必須冪等、失敗必須大聲、日誌必須留痕
- 正式機上的任何一行，先評估爆炸半徑再出手

MEMORY.md（種子記憶——方括號處換成你的環境）

§ 團隊慣例：服務一律用 systemd 管理；日誌進 journald；禁止以 root 直接登入。
§ 環境：正式機變更僅限 [維護時段]；變更前先在 [測試機] 驗證（部署時替換方括號）。
§ 學到的教訓：磁碟滿先查「已刪除仍被行程佔用」的檔案（lsof | grep deleted），再談清理。
§ 每週體檢結果要彙整成人話回報，異常排最前面，30 分鐘內完成。

USER.md

§ 使用者是 Tech Lead：要可執行的結論，不是教學長文。
§ 溝通：正體中文；指令與技術名詞保留英文；先講爆炸半徑，再講步驟。
§ 期望：破壞性操作先停下來問；不確定的事標 [未驗證]。
§ 報告固定四段：異常 → 根因 → 建議動作 → 需要的授權。

兩個治理提醒（Linux 座位的紀律，養 agent 同樣適用）：先開 write_approval——Hermes 的記憶自我寫入預設自動落盤，開了之後要經你批准（/memory pending 審核），你才知道它偷偷「學」了什麼；憑證給最小集——它能碰的帳號決定了它的爆炸半徑。另外字元上限是硬的（2,200／1,375），超限會直接回錯，記得幫它做減法。

蓋章紀錄（誠實欄）

• 本篇交付的是出題與驗收設計；三道題我會逐一實跑，翻車實錄與跑分補在本文留言 [實測更新中]。

明天

Day 03｜SRE 上線。Linux 管單機活著；SRE 管「團隊敢不敢保證它活著」——SLI、SLO、錯誤預算，這份契約 AI 能簽嗎？

如果你家也有台「以為自己懂」的 Linux 伺服器，把三道題拿去測你的 agent，歡迎回來留言對答案。