你有沒有算過自己花在調(diào)試CI/CD上的時間？

三年前的一個周二下午，我在Jenkins里折騰一段Groovy腳本，三小時過去，我突然意識到一件事：我不是在寫軟件，我是在給Jenkins打工。那一刻我決定，去他的，自己寫一個。

這就是Callahan CI的由來。

Jenkins的問題不用我多說。插件生態(tài)龐大但維護(hù)混亂，更新一個插件可能搞崩整個流水線；Groovy DSL功能強(qiáng)大但語法晦澀，跟日常開發(fā)完全是兩套思維；UI老舊到不只是難看，是根本看不懂當(dāng)前在跑什么；本地開發(fā)環(huán)境搭起來像部署服務(wù)器集群；配置分散在十幾個地方，沒一個直觀。

GitHub Actions改善了一些——YAML至少能看懂，應(yīng)用市場也規(guī)范些。但代價是全押云端，密鑰存在你看不見的地方，按分鐘計費(fèi)對 side project 來說不知不覺就超支。

我想要的東西很簡單：能在筆記本上跑，不上云，不需要 agent，沒有插件市場。代碼一推，自動構(gòu)建，出錯立刻知道。

Callahan CI是一個單文件Go二進(jìn)制?？寺}庫，執(zhí)行./start.sh dev，localhost:3000就有了完整的CI/CD平臺。API、流水線執(zhí)行器、WebSocket日志流、儀表盤，全在一個進(jìn)程里。狀態(tài)存在SQLite文件。

它讀取Callahanfile.yaml（語法兼容GitHub Actions，遷移成本低），把構(gòu)建步驟作為原生shell進(jìn)程執(zhí)行，實時流式輸出日志并存儲結(jié)果。

以上是基礎(chǔ)功能。真正讓我花心思的是AI層。

我不想做那種事后 bolt-on 的"AI助手"。我想要的是在流水線特定節(jié)點(diǎn)自動干活的 agent，不需要你開口。

一共四個：

架構(gòu)師（The Architect）

用 plain English 描述你的流水線，它自動生成Callahanfile.yaml——jobs、steps、部署階段、AI標(biāo)記，然后提交回倉庫。已有Jenkinsfile或GitHub Actions工作流？它也能遷移。

調(diào)試器（The Debugger）

構(gòu)建失敗時，點(diǎn)一下"AI Explain Failure"。它讀取失敗任務(wù)的日志和流水線配置，返回簡短根因和具體下一步。不用再半夜翻800行堆棧。

示例輸出：

DIAGNOSIS: Build failed because npm couldn't find package.json. The repo is a Go project — language detection fell through to the JS default. Replace the build step with: go build ./...

審查員（The Reviewer）

每次構(gòu)建自動運(yùn)行。讀取diff，檢查——