Day 01｜我是狼人，這局遊戲我重來了無數次

2026 iThome 鐵人賽

DAY 1

佛心分享-IT 人自學之術

狼人自爆的心路歷程：一個「AI人」的30天自學修煉系列第 1 篇

18th鐵人賽

怕冷的哈士奇

團隊2N1P

2026-09-07 16:43:25

58 瀏覽

分享至

「語法完美的謊言終會現形；唯有親手編譯、親手除錯過的認知，才能在輪迴中留下無法被抹除的印記。」
——《阿帕契開源審計錄》卷一·輪迴開篇

我死了，然後我又回到了第一夜。這局城堡黑夜的遊戲，我已經記不清重來過幾次了。

長桌旁坐著九個玩家，這是最標準的九人局配置：三隻狼人、三個神職（預言家、女巫、獵人）、三個閉眼平民，嚴格遵循「屠邊規則」（狼人殺光所有神職或所有平民即獲勝）。桌上立著一枚象徵秩序的警徽——在標準賽制中，警長擁有白天投票平票時 1.5 票的生殺大權，並負責指定發言方向。更重要的是，全場貫徹嚴格的**「絕發規則」**：每個人只能在屬於自己的輪次說話，任何人不得插嘴打斷，獨自承受全場的審視。

我是三隻狼之一。表面上我白天發言、晚上殺人、拼命偽裝成好人。但我有一個致命祕密：我根本不會寫程式。

我是典型的「AI 人」。

城堡黑夜：起跳查殺與爆狼發言

在九人局裡，真正的廝殺從天亮的第一刻就開始了。

天剛破曉進入「上警環節」，前置位好人為了逼出狼人，冷不防**「起跳預言家炸身份」**，朝後置位的我扔出一顆「查殺」。

一個真正懂架構的工程師會冷靜拆解對方的邏輯矛盾；而身為「AI 人」的我當場慌了手腳。在絕發的肅靜中，我手忙腳亂地把局勢丟進大型語言模型（LLM），生成一段看似嚴密、用詞華麗的自辯照本宣科。句子語法完美，但本質上是空心的，毫無對底層架構的真實洞察。老玩家一眼識破了我發言中的認知斷層：這是一個被查殺後慌亂調用 AI 唸稿的「爆狼發言」！

在九人局規則中，身分敗露的狼人面臨著三種殘酷結局：

上警自爆（吞警徽）：在白天發言拍桌自爆立刻出局，發言與投票強制終止。在競選階段自爆，警徽直接被「吞掉」（全場無警長），全場強行入夜。
第一天公投放逐（有遺言）：硬撐到投票出局。依照規則，第一天被投票放逐的玩家擁有發表遺言的權利。
第二夜女巫毒殺（無遺言倒牌）：真預言家夜間驗出底牌後暗號通知女巫，女巫在第二夜悄悄下毒；在標準規則下，夜間死亡的玩家「完全沒有遺言」，死在死寂之中。

死掉之後，世界瞬間坍縮。當我再次睜開眼，依然是第一夜那片冰冷的黑夜——九個人、相同的身分、重置的狀態，除了我，沒有人記得上一輪。這是一個沒有終止條件的無限迴圈。

這正是我們 「2N1P」 團隊在今年鐵人賽展開挑戰的起點：我們不要再當那隻只會讓 AI 代筆、在自爆與無聲毒殺中反覆死去的狼。

信任崩解的「大型開源狼人殺」

看著眼前反覆重開的賽局，我不禁想到了當前的開源世界。現在的開源社群何嘗不是一場**「大型開源狼人殺」**？空氣中瀰漫著戒備：每當維護者打開 GitHub PR 列表，心中浮現的第一個念頭往往是——這個提交者到底是一個真正理解系統的工程師，還是一隻躲在 AI 背後胡亂提 PR 的「狼」？

正如在開源界深耕多年、發起「源來適你」（OpenSource4You）社群的開源大佬 chia7712 在其今年鐵人賽專文《不偷不搶不賭不嫖，依然不是我們要找的人》中所直言：

「基金會的錢不是用來養開源工程師，而是贊助優秀的軟體工程師... 如果你只是想來蹭每個月幾萬元的獎助金，交出一些用 AI 拼湊且自己都無法維護的 code 或缺乏實質貢獻的水題目，那我真心建議你另尋他地。社群資源有限，必須留給真正想捲起袖子做事的人。」

這正是所謂 「Vibe Coding」（氛圍編程） 所造成的信任災難：許多人沈迷於靠 Prompt 一鍵生成幾百行代碼的快感，卻對執行期的記憶體流失與並發競爭一無所知。在開源協作中：

維護者追問設計考量（如同好人**「炸身份」**）。
不懂底層的人慌亂貼出 AI 產生的車輪話，當場自相矛盾（如同狼人**「自爆」**）。
維護者忍無可忍直接 Close PR 並封鎖帳號（如同女巫深夜**「無聲毒殺，不給遺言」**）。

各大專案反應不一：Zig 語言專案因不堪空洞 PR 侵擾，明文全面禁止任何由 LLM 生成的 Pull Requests；其他專案則提高門檻，要求提交者以個人信譽做擔保。開源協作需要「絕發」的自律（給予代碼完整上下文）與「警長」的擔當（維護者的仲裁權）。

我自己恰恰就是那隻被無數次處死的「AI 狼」。如果只是被社群掃地出門，世上只會多一個怨懟的落榜者；但如果我們能以教化與轉化代替排斥，帶領迷惘的新手學會誠實面對程式碼，把 AI 當作思考的槓桿而非掩蓋無知的面具，那麼一隻只會唸稿的狼，也能在開源熔爐中蛻變成真正受人尊敬的工程師。

狀態機：困住狼人的無限迴圈

在軟體工程中，這場無限輪迴本質上就是一個由狀態機（State Machine）控制的迴圈邏輯。我們可以用 Mermaid 狀態圖直觀看清這條生死路徑：

以本系列 Go 賽道（Kubernetes / Apache YuniKorn）的核心語法來定義狀態轉移與調諧迴圈（Reconciliation Loop）：

package main

import "fmt"

// EliminationCause records the specific rule trigger that ended the round.
type EliminationCause string

const (
	SelfDetonationSwallowBadge EliminationCause = "SELF_DETONATION_SWALLOW_BADGE" // 自爆吞警徽（中斷白天、全場無警長）
	DayVoteExileWithWords      EliminationCause = "DAY_VOTE_EXILE_WITH_WORDS"     // 第一天放逐投票（有遺言）
	NightWitchPoisonSilent     EliminationCause = "NIGHT_WITCH_POISON_SILENT"      // 第二夜女巫毒殺（夜間死亡無遺言）
)

// CastronegroReconciliation manages the loop state until authentic capability is proven.
type CastronegroReconciliation struct {
	Round         int
	NarratorAlive bool
}

// Reconcile checks observed state against desired state, triggering reset upon failure.
func (c *CastronegroReconciliation) Reconcile(cause EliminationCause) {
	if !c.NarratorAlive {
		fmt.Printf("State deviation [%s]: Resetting loop to Round 1 until genuine craft is proven.\n", cause)
		c.Round = 1
		c.NarratorAlive = true
	}
}

只要 c.NarratorAlive 被判定為 false，系統就會立刻觸發 Reconcile()，讓一切重回起點。這與 Kubernetes 控制器比對現狀與期望狀態的機制完全一致。跳出輪迴的唯一路徑，是走完真正嚴謹的監督式代理人閉環：

$$\text{理解 (Comprehend)} \longrightarrow \text{規劃 (Plan)} \longrightarrow \text{執行 (Act)} \longrightarrow \text{評估 (Evaluate)} \longrightarrow \text{調整 (Adjust)}$$

上一輪的我跳過規劃與評估，缺乏本地測試覆蓋，盲目提 PR，遭到無聲毒殺是必然代價。徹底重構自己的工程大腦，才是唯一的解方。

接下來三十天的修煉地圖

為了打破詛咒，我們團隊翻開了結合《2026 Junior工程師學習地圖》與 opensource4you / TAIONE GOSF 四大真實賽道的修煉指南：

第一區塊：Foundation（第 1 至 10 天）—— 築基與 AI 韁繩工程
型別系統、記憶體（Stack vs Heap）、Big-O 複雜度極限、Git 內部原理、AGENTS.md 韁繩工程、MCP 與規格導向開發（SDD）。
第二區塊：Practice（第 11 至 24 天）—— 四語言橫向對比與開源實戰
橫向對比 Go、Java、Rust、Python：多態與組合、記憶體管理（GC vs 所有權）、錯誤處理、併發模型（Goroutines vs 虛擬線程 vs tokio）、網路協定與測試工具鏈。
第三區塊：Reflection（第 25 至 30 天）—— 開源治理、維護者心聲與救贖終章
真實 Legacy Code 閱讀、消除 Flaky Tests 與 Release Blockers、PR 小作文溝通藝術，最終以歷史審計軌跡迎接「三人生死輪盤」終局決策。

天又要黑了。當警長明天再次敲響發言鈴聲時，我希望自己說出的每一句話，都是親手敲過、測過、除錯過的真實思考。