作品

我將想法推進到可用版本：軟件產品、研究工具與語言學習項目。

№01
UniExp HK 實驗港
打開線上項目
一個幫香港研究者發布實驗、招募參與者的線上三語平台。我獨立完成產品、運營流程與受控 AI 審查層；AI 只在證據核對與人工批准後協助提出更新。
問題香港高校的實驗招募散落在群組、表單、集合頁、海報與雙語來源頁裡；研究者難以招募足夠樣本，參與者與營運者也需要可核驗證據，才能安全發布。

成果已上線三語平台 · 115 個 merged PR（最新 #120）· 獨立設計、上線與運營

角色獨立創辦人與開發者 — 產品設計、前端、後端、上線、日常維護
技術

Next.js
TypeScript
Tailwind CSS

+6
項目截圖

線上三語實驗招募平台首頁。
案例詳情
查看案例

解法

我把產品做成兩條清楚流程：研究者發布並管理研究，參與者瀏覽、報名與評價；後台加入證據門控的 AI 審查層，讓自動化只提出候選，不直接改寫生產真相。

我的工作

研究發佈 + 時段排期 + 報名審核（研究者端）
瀏覽 / 篩選 / 報名 / 評價（參與者端）
全站三語 i18n（EN / 繁中 / 简中）
External Study Ops Agent，分層自主階梯：L1 shadow → L1.5 cross-check → L1.6 Codex replacement check → L2 proposal queue → L3 guarded write（每隊列每輪最多寫 1 條 pending）
多隊列 agent：單一對外入口，內部 supervisor + 四個 worker（new_study_lead / published_change / source_candidate / seed_candidate），各自只能寫一張指定的 Admin pending 表
定時守護審查：每日 VPS cron（22:05 UTC）跑 L1 shadow、輸出只讀證據、不寫生產——明確不是自主生產控制
Production Explore truth source、quality workbench、section-level evidence、signup freshness、visual/OCR/QR review 與 feedback-audit ledger

技術證據

Agent 安全模型：每條 queue proposal 過 deterministic evaluateQueueProposalPolicy() gate 蓋 writeEligible 章；L1 只寫 noProductionWrite=true 本地報告；自主權止於 Admin pending queue——experiments、source registry、approve/reject 仍由人工審核
Truth discipline：production Explore（已發布實驗）是唯一真相源；legacy pipeline、source/seed discovery 與 agent shadow report 都只是候選生成器，不能反向覆蓋 truth
評測與 readiness gate：daily-cron 證據區分 real_cron 與手動觸發；L3 readiness 要求 30 天內 reviewed proposal ≥10、acceptance ≥80%、stale/bad-source false positive 為 0、且無 production-write incident
Failure→gate：曾有 proposal 把 HKD 80 baseline 當成總報酬，修正後成為永久的 compensation-component policy check，把該類降級為 report-only
Reasoner 可靠性：Gemini reasoner 只允許返回結構化 JSON；壞輸出或失敗時回退到 deterministic reasoner 繼續只讀運行——模型參與不等於執行許可
自託管 Supabase（auth + Postgres + 維護）+ Cloudflare 邊緣加速與防濫用；獨立持續維護，累計 115 個 merged PR（最新 #120，Cloudflare deploy Node patch）
№02
han-dong.link — 空間化作品駕駛艙、基於來源的問答與職位匹配 agent
打開線上項目
職位匹配 agent 把貼上或上傳的 JD 轉成帶來源的契合簡報，面向招聘方快速核對；同一套 han-dong.link 也把即時問答助手與 Three.js 駕駛艙串起簡介、作品、研究與履歷。
問題公開作品集要同時服務招聘方、技術同儕與研究合作者，不能讓讀者自己猜每個主張背後有什麼證據。靜態頁面可以列出作品，但很少能回答職位相關問題，也很少展示網站本身如何組織證據。

成果已在 han-dong.link 上線 · 主頁駕駛艙入口呈現即時作品集數量 · 答案卡引用來源頁 · 可見回答軌跡 · 職位匹配把 JD 文字或文件轉成強項、相鄰證據、缺口與追問

角色獨立開發者 — 互動駕駛艙 UI、Three.js 導航、問答與職位匹配 agent loop、帶來源答案卡、文件/JD 護欄、部署
技術

TypeScript
Astro
React

+7
項目截圖

空間化駕駛艙是作品集的預設入口。
案例詳情
查看案例

解法

我做了空間化駕駛艙，也保留正典閱讀頁，並把兩者連到同一組 Astro content collections，供問答與職位匹配共用。訪客可以打開簡介、作品、研究與履歷四個星球，也可以線性閱讀或透過帶證據的卡片提問。

我的工作

空間化作品駕駛艙：圍繞助手構建的 Three.js 體驗，以簡介、作品、研究、履歷四個星球呈現，並為減少動態、手機與無 WebGL 環境保留 read-mode 頁面
五個 typed tools（getProjects / getPublications / getStack / getTimeline / getContact），LLM 按問題自選，並有文字兜底
職位匹配 agent：獨立 `/role-fit` 頁面接受貼上的 JD 文字或 PDF/PNG/JPEG/WebP 上傳，輸出包含強匹配、相鄰證據、誠實缺口與招聘方追問的倡導式簡報——不做百分比打分或錄用/不錄用建議
Source-linked 生成式 UI：每個工具結果渲染成 React 卡片（項目卡、論文列表、工具標籤、時間線、聯絡），並連回對應來源頁
可見回答軌跡：助手把從站內內容檢索到答案卡生成的來源路徑顯示出來，讓訪客能看見回答為何成立
content collections 作為單一數據源——新項目自動進 agent，無需重訓、無需 embedding
誠實的說服：先講優勢、用一句簡短承認短板、絕不編造事實/頭銜/數字

技術證據

漸進增強的 Three.js 外殼：WebGL／減少動態／手機能力檢查、啟動序列、鍵盤與滾輪導航，以及從同一組 Astro content collections 顯示即時數量的駕駛艙儀表板
Agent loop：校驗輸入 → 從 collections 組裝 grounded system prompt → LLM 工具決策 → 工具調用去重 → 解析 typed tools → 渲染卡片 + 文字
Observable agent traces 讓 loop 可檢查：檢索到的 collection 記錄、選中的 tool cards 與最終文字保持可見連接，不會消失在純聊天回答裡
護欄：輸入校驗（長度上限、prompt-injection 正則、拒答越界與套取 prompt）加 per-IP 限流
職位匹配護欄：JD 專用校驗、拒絕而非爬取第三方招聘連結、PDF/圖片提取、證據白名單、數字/資質主張守衛，以及完整分析延遲時基於站內證據生成簡報
provider-agnostic LLM 整合 + 確定性 mock fallback，dev / 無 key 時完全離線可跑
Astro + Vercel 服務端渲染；三語（EN / 繁中 / 简中）；答案經 markdown 渲染
№03
Evidoc — 面向 agentic repositories 的文檔漂移控制
查看案例
一個公開、本地優先的開發者工具，用於檢查 README、docs、AGENTS.md、CLAUDE.md、examples、API notes 與源碼綁定文檔是否仍然描述當前真實 repo。它讓人工審查、CI 與 coding agents 在信任或修復過期上下文前，使用同一份 repo-local evidence。
問題 Agentic repositories 很容易累積過期指令：README commands 與 package scripts 漂移，AGENTS.md 和 CLAUDE.md 保留舊路徑，examples 不再匹配 API，而 coding agents 可能在檢查源碼前先信任這些說法。Evidoc 把這個信任問題轉成一套本地 evidence workflow。

成果公開 v0.3.2 · 已於 npm 以 @evidoc/evidoc 發布 · CLI、MCP server、Local Web UI、GitHub Action、Local Git Gate · CLI、core、dashboard、local app、MCP server、reports 與 review log package artifacts

角色獨立開發者 — 產品定位、CLI、MCP server、本地 Command Center、GitHub Action、Local Git Gate、release workflow
技術

TypeScript
Node.js
MCP

+5
案例詳情
查看案例查看源碼

解法

我把信任檢查包成一套本地工作流，覆蓋 CLI、MCP server、本地 Web UI 與 GitHub Action。每個入口都先把文檔主張對照 repo 證據，再提出修復建議或阻斷 gate。

我的工作

CLI 工作流：檢查 drift、運行 doctor diagnostics、生成 repo-local reports，並在命令行執行 local gates
面向 coding agents 的 MCP server，把 drift status、scans、diagnosis、doc-fix suggestions 與明確 review logging 作為受控 tools 暴露
雙語 Evidoc Command Center / Local Web UI，用於 repository health、triage、repair prompts 與 local-gate visibility
GitHub Action 支持 CI-side drift checks、PR feedback、changed-file focus，並能檢測舊 DriftGuard action references 的相容性
v0.1.0 release 完成 DriftGuard -> Evidoc rename，覆蓋 CLI、npm packages、.evidoc state、MCP、GitHub Action、local app 與 docs
v0.3.x 以 npm scoped package @evidoc/evidoc 發布，承接 Evidoc namespace 遷移、topological npm publication 與 0.3.2 發布加固

技術證據

Repo-local evidence model：先對照 commands、paths、symbols、package scripts、frontmatter source bindings、API surfaces 與 changed files，再信任文檔 claims
Agent-safe defaults：預設 read-only checks，review logs 與 repair proposals 有明確寫入邊界，且不依賴遠端項目知識
Repair workflow 把 evidence、diagnosis 與 patch suggestions 分開，使 generated fixes 保持可審查，而不是靜默改寫 repo truth
Release hardening 覆蓋 doctor readiness、scoped package artifacts、GitHub Action behavior，以及與當前 scoped npx 和 local GUI paths 對齊的 docs
№04
D-academic-agent — 學術證據核驗工作區
查看案例
一個本地優先的學術證據核驗工作區，用確定性 NLI judge 對照來源證據審查論點與引用。它提供 Electron 桌面 app 與 MCP-capable core，外部 scite / Consensus 證據檢索則保持明確 opt-in。
問題大規模文獻審查容易出錯：LLM 虛構 supports 關係；詞彙 judge 無法識別矛盾，所謂 'supports' 毫無意義。每條 claim 需要可溯源的定位器，而非模型猜測。

成果 317 個離線測試 · 42 條人工標注 gold set · 最新打包版本覆蓋 macOS arm64 / x64 / universal

角色獨立開發者 — 架構、核心管線、Electron app、MCP server、評測框架
技術

TypeScript
Electron
MCP

+9
項目截圖

對照已導入來源證據檢查引用。
案例詳情
查看案例查看源碼

解法

我做了一條本地優先流程：導入論文、檢索證據、用確定性 NLI 判斷論點，並把裁定、片段與定位器一起呈現。外部證據檢索保持 opt-in，私有草稿與文獻庫預設不外發。

我的工作

Draft Citation Audit — 逐句審查：每條引用解析到來源、判定（supports / weakly_supports / unsupported / contradicts / unclear），附原文片段、字符跨度定位器、置信度與建議改寫；語料庫反例自動浮現
Thesis Review — 論文拆解 → 檢索 → 逐條判斷 → 共識裁定（supported / contested / refuted / insufficient），附比例、決定性指數與支持/矛盾證據圖
混合檢索 — BM25 + 稠密向量（本地 ONNX：all-MiniLM / bge-small / nomic，角色感知）+ reciprocal-rank fusion；定位器從頁面追蹤到字符跨度
離線優先 judge — 確定性 DeBERTa-NLI（零外呼）為預設；OpenAI-compatible 與 Ollama 一鍵預設支持雲端/本地 LLM judge
持久化文獻庫 — PDF 拖入（GROBID 章節感知 + unpdf fallback）；本地 SQLite（Source / Chunk / vectors）；切換 embedder 自動重索引
迭代 agent-loop checker — 頂層證據不確定時，審查次級候選並追蹤步驟；failure mode 量化後作為診斷指標暴露
三軸評測：準確率（macro-F1 + 分類 + 混淆矩陣）、忠實度（answer_groundedness）、治理（policy_compliance：grounded-locator 率 + snippet-only 率 + 外發字符數）
Provider ablation runner — 橫向對比 hash+mock / all-MiniLM+NLI / agentic 在三軸的表現；本地 vs 雲端、單輪 vs agentic 的取捨，有數字為證
寫作台（Writing Desk）— 貼入一個段落：拆分並分類每條 claim（因果 / 比較 / 方法⋯），對照文獻庫標記 needs_citation / overclaimed / contradicted，並給出更穩妥的改寫；可針對每條論點，用一段可編輯、已告知的查詢詞查找外部證據
外部研究與引用健康（可選）— 在 app 內檢索 scite / Consensus 以獲取候選外部證據；並把 scite 的引文分析呈現為風險徽章（無明顯問題 / 存在一些反駁 / 值得注意的問題 / 已撤稿或嚴重通告），附支持 / 反駁 / 提及計數與撤稿通告，覆蓋三處：檢索結果、已導入的文獻庫論文（在引用前就抓出被撤稿的文獻），以及一篇論文經 GROBID 解析出的參考文獻
可複用的 MCP OAuth — 基於 MCP SDK 的 OAuth 2.1 PKCE + 動態客戶端註冊（DCR）瀏覽器登入，用於需 OAuth 的 MCP server：127.0.0.1 回環流程，token 僅存於鑰匙串，worker 除一個 bearer access token 外什麼都拿不到
桌面發布管線 — 最新公開 release 已打包 macOS arm64 / x64 / universal，讓審查者可直接以真實 app 方式檢視，而不只依賴 source checkout

技術證據

共享核心，兩個接口：純 TS 引擎在 src/（ingest · retrieve · check · plan · eval · trace）；MCP server 與 Electron app 是薄適配層——src/ 不 import Electron
確定性來自離線 mock（HashEmbedder / MockJudge / MockPlanner）；模型加載測試加 env gate，CI 全程離線
Gold set：42 條人工標注 claims，附 integrity-gated sources.lock.json；gold 必須人工標注，絕不讓被測模型自評
可選的出站，且邊界嚴格 — 外部呼叫僅在明確動作下觸發，且只送出查詢詞或公開 DOI，絕不送出語料庫或草稿（唯一例外：寫作台的證據檢索，送出一段可編輯、已告知的查詢詞）；OAuth token 留在鑰匙串，僅以一個 bearer 標量抵達 worker，並在每個邊界被脫敏
密鑰存 OS keychain（Electron safeStorage）——不進 config/git/trace/日誌；317 測試覆蓋 retrieval / check / eval / trace 與外部研究層，全程離線（live 網絡冒煙測試以 env gate 隔離）
Electron 打包覆蓋最新 packaged release 的 macOS arm64 / x64 / universal 產物，同時保留非 macOS 目標的 source-run fallback
№05
opencode-plugin-cc — 在 Claude Code 裏使用 OpenCode
查看案例
官方 openai/codex-plugin-cc 介面的 Claude Code port，改為驅動本機 OpenCode CLI。它讓 Claude Code 可把受控 review、adversarial-review、rescue、transfer、status、result、cancel、setup 與可選 stop-time review 工作交給 OpenCode；OpenCode 可接 Anthropic、OpenAI、Google、open-weight 與免費 zen 模型。
問題 Claude Code 需要一種受控方式使用第二模型，同時不離開本地工作流、不丟失 context ownership。風險在於把過多 scope 交給另一個工具。

成果公開 v0.1.1 · 官方 codex-plugin-cc 介面的 port · 多 provider 第二模型委派 · 可選 stop-time review gate

角色 Claude Code port 的獨立適配與維護者 — OpenCode CLI 接線、命令介面、job ledger、隱私邊界、stop-time gate
技術

JavaScript
Node.js
Claude Code Plugin

+2
案例詳情
查看案例查看源碼

解法

我把官方命令介面 port 到 OpenCode CLI，並保留明確的 job control、stop-time review 與隱私邊界。Claude Code 仍負責文件、git、驗證與最終判斷。

我的工作

Claude Code 命令：review、adversarial-review、rescue、transfer、status、result、cancel、setup
對 OpenCode 的受控委派，覆蓋 Anthropic、OpenAI、Google、open-weight 與免費 zen 模型選項
背景 job ledger、status / result / cancel 控制，以及可選 stop-time review gate
配合 Dong-skills 協作工作流使用，但不把最終 ownership 移出 Claude Code
№06
grok-plugin-cc — 在 Claude Code 裏使用 Grok
查看案例
官方 openai/codex-plugin-cc 介面的 Claude Code port，改為驅動本機 Grok CLI headless mode。它鏡像同一套受控 review、adversarial-review、rescue、transfer、status、result、cancel、setup 與可選 stop-time review flow，並加入 grok:grok-rescue subagent。
問題 Claude Code 需要一條受控路徑請 Grok 做 review 或 rescue，但不能讓 Grok 成為本地文件或 git 的 owner。手動切換工具會削弱 scope 與 evidence 追蹤。

成果公開 v0.1.1 · 官方 codex-plugin-cc 介面的 port · Grok CLI headless 委派 · 可選 stop-time review gate

角色 Claude Code port 的獨立適配與維護者 — Grok CLI headless 編排、命令介面、grok:grok-rescue、job ledger、邊界
技術

JavaScript
Node.js
Claude Code Plugin

+2
案例詳情
查看案例查看源碼

解法

我把官方命令介面 port 到 Grok CLI headless mode，加入 job controls、grok:grok-rescue subagent、stop-time review 與明確邊界。Claude Code 保留驗證與交付判斷。

我的工作

Claude Code 命令：review、adversarial-review、rescue、transfer、status、result、cancel、setup
整合 Grok CLI 原生 headless mode，用於受控第二模型 review 與 rescue
grok:grok-rescue subagent，加上 status / result / cancel 控制，讓 jobs 可檢查
可選 stop-time review gate，讓 Claude Code 保留最終驗證責任
№07
opencode-plugin-codex — 在 Codex 裏使用 OpenCode
查看案例
一個公開 Codex plugin，讓 OpenCode 能在 Codex 裡支援代碼審查、問題排查與交接任務。它用 job 狀態、取消能力與收窄的隱私邊界，讓協作保持可控。
問題 Codex 與 OpenCode 各有優勢，但手動切換通常會丟上下文，也讓審查難以追蹤。這個項目的目標，是把 OpenCode 變成 Codex 裡可控的協作方，並保留清楚的 job control 與窄隱私邊界。

成果公開 Codex plugin · 已測試 MCP tools · Codex 內的 OpenCode 審查支援

角色獨立開發者 — Codex plugin 打包、MCP tool surface、OpenCode CLI 編排、transcript 邊界、測試
技術

TypeScript
Node.js
MCP

+3
案例詳情
查看案例查看源碼

解法

我把 OpenCode 包成 Codex 裡的 MCP 工具，加入能力檢查、後台 job 狀態、取消能力與 transcript 邊界。OpenCode 可以審查或排障，但文件、git 與最終驗證仍由 Codex 控制。

我的工作

Codex plugin 暴露 OpenCode MCP 工具：check、run、continue、rescue、review、adversarial review、transfer、status、result、cancel
Background OpenCode job 編排，讓長時間 review 可在 Codex 內輪詢、檢查或取消
有意識的 transcript 隱私邊界：opencode_transfer 預設只傳可見 user/assistant 對話，不傳隱藏 system、developer 或 tool output
Review 與 adversarial-review helper，讓 OpenCode 可作為 diff 發出前的第二輪工程審查者
加入 prompt before file 的訊息順序處理、file attachment guard，以及對要求 OpenCode 檢查 Codex private runtime paths 的提示阻擋指引

技術證據

TypeScript 編寫的 bundled stdio MCP server，打包為 Codex plugin
OpenCode CLI 發現、版本檢查、背景進程管理、job ledger、timeout handling 與結果取回
按設計收窄 context transfer：除非未來有明確接口支持，plugin 不把 tool output 與隱藏指令傳給 OpenCode
公開後的安全加固：任務文本保持在 prompt before file 的順序中，file attachment guard 拒絕把提示詞當文件傳入，Codex private runtime paths 不進入 OpenCode 的讀取範圍
用 Vitest 覆蓋 MCP tools 與 transcript-transfer 邊界
№08
grok-plugin-codex — 在 Codex 裏使用 Grok
查看案例
一個公開 Codex plugin，讓 Codex 可調用本機 Grok CLI 做受控 repo 任務、代碼審查、救援分析、對抗式檢查、session 檢視與背景任務，同時不交出隱藏的 Codex context。
問題 Grok 可以提供另一個工程視角，但手動切換工具會讓 scope、session history 與審查責任變得難控。這個項目的目標，是讓 Codex 能請 Grok 協助，同時仍由 Codex 掌握文件、測試、git 與最終判斷。

成果公開 Codex plugin · 0.2 typed MCP contract 與 explicit workspace roots · Codex 內的 Grok review 與 rescue · 受控第二 agent 工作流

角色獨立開發者 — Codex plugin 打包、MCP tool surface、Grok CLI 編排、隱私邊界、背景任務、測試
技術

TypeScript
Node.js
MCP

+3
案例詳情
查看案例查看源碼

解法

我把 Grok CLI 包成 Codex 裡的 MCP 工具，加入能力檢查、受控 run / review / rescue 包裝、session 列表與匯出、背景任務 status / result / cancel，以及針對隱藏 context 與 private runtime paths 的明確保護。

我的工作

Codex plugin 暴露 Grok MCP 工具：check、models、run、continue、rescue、review、adversarial review、sessions、export、status、result、cancel
受控 review 與 rescue helper，讓 Grok 可以作為第二雙眼睛，但不成為改動 owner
Background Grok job 管理，包含 status / result / cancel，讓長時間 review 可先檢查再採信
0.2 typed MCP contract 將 session 列表與匯出保留為明確 evidence surfaces，同時仍刻意不聲稱已有 Codex-to-Grok transfer 路徑
0.2 release 變更：breaking typed MCP contract、explicit workspace roots、restart-safe background workers、atomic job lifecycle、經 fd3 的 private prompt staging，以及更嚴的 path、symlink、env、session、cancel 邊界

技術證據

TypeScript 編寫的 bundled stdio MCP server，打包為 Codex plugin，包含 plugin manifest、skill、MCP config、privacy policy、terms 與 security policy
Grok CLI 發現、版本檢查、可選 model probing、foreground JSON run、streaming background run、job ledger，以及保守的 result completion 判定
按設計收窄隱私邊界：prompt 不接收 Codex hidden context、tool output、secrets 或 Grok auth token；private runtime path 請求默認拒絕，除非明確允許
驗證腳本覆蓋 build、typecheck、unit tests、MCP smoke checks、documentation drift checks，以及可選的 authenticated live Grok smoke
№09
Dong-skills — 智能體協作工作流
查看案例
一個公開的個人 skills 倉庫，為 Claude Code、Codex、OpenCode 與 Grok 整理智能體協作紀律，包含受控範圍、審查關卡與明確驗證。它保留 Claude-Codex 互評、Codex-OpenCode 與 Codex-Grok 工作流作為已命名的可復用操作規則。
問題多智能體 coding work 如果範圍、隱私、審查權限與驗證責任不明確，很容易失控。第二個 agent 只有在拿到受控任務包，且其結論被真實 repo 驗證時才有價值。

成果公開 skills 倉庫 · 覆蓋 Claude Code、Codex、OpenCode 與 Grok 的協作工作流 · skills 已對齊 plugin contract v2

角色獨立作者 — 工作流設計、安全邊界、審查協議與文檔
技術

Codex
OpenCode
Grok CLI

+4
案例詳情
查看案例查看源碼

解法

我把反覆使用中的協作實踐整理成明確 skill workflow：先定義任務包，限制第二個 agent 能看什麼、做什麼，設置審查關卡，並在交付前逐條對照 repo 驗證。

我的工作

Claude-Codex 互評工作流：讓一個 coding agent 審查另一個 agent 的 diff，但不轉移最終責任
Codex-OpenCode 工作流：包含能力檢查、受控委派、review / adversarial-review 入口與結果驗證
OpenCode collaboration guidance：任務文本放在 prompt、文件作為附件、避開隱藏 runtime context，並要求 Codex 驗證每個發現
Codex-Grok 協作工作流：使用 grok-plugin-codex 做能力檢查、受控 run、review / rescue / adversarial review、session export、background jobs，並保留 Codex 最終驗證
OpenCode 與 Grok collaboration skills 於 2026-07 對齊 plugin contract v2，同時保留三條已命名工作流

技術證據

操作安全規則：第二 agent 不執行破壞性命令、不 commit / push、不讀 private runtime paths，也不直接採信未驗證結論
可復用任務包結構：目標、驗收標準、精確 scope、約束、驗證命令、期望輸出與風險
審查紀律：OpenCode 與 Grok 可以提供第二輪 review 或 adversarial review，但 Codex 仍負責讀 diff、跑測試並決定是否交付
№10
relaybar
查看案例
一個給日常使用多個 AI coding 帳號的人用的 macOS menu-bar 工具。它把帳號池、剩餘額度與被限流狀態放在眼前，避免任務執行到一半才發現額度或限流問題。
問題 AI coding 任務常常因為額度或帳號池狀態不可見而中途受阻，直到 provider 限流才發現問題。用戶需要的是一個很小的提前預警界面，而不是另一個需要常開的 dashboard。

成果 MIT 開源 macOS menu-bar 工具 · 面向日常 AI coding 帳號池監控

角色獨立作者
技術

Swift
macOS
Developer Tools
項目截圖

面向日常 AI coding 的選單列額度與帳號池狀態。
案例詳情
查看案例查看源碼

解法

我做了一個原生 macOS 選單列 app，輪詢額度與帳號狀態，把關鍵信號放在一點即開的位置，讓用戶能在任務卡住前切換帳號池。

我的工作

選單列即時顯示跨 provider 的帳號池與剩餘額度
某個池耗盡或被限流時清楚顯示，可在任務受阻前切換
低打擾、常駐的選單列界面

技術證據

原生 Swift 選單列應用；按間隔輪詢各 provider 額度接口
從每天用 Codex / Claude Code / Antigravity 的視角做——真正的痛點是帳號池輪換、額度耗盡與多 provider 上下文，而非模型質量
MIT 開源；一個小而專注的 macOS 工具，把日常遇到的帳號限制變成可提前判斷的狀態信號
№11
Memoh — 開源貢獻
查看案例
對 Go 多智能體平台 Memoh 的開源維護貢獻；它用隔離環境運行 coding agents。已合併的 PR 讓錯誤診斷更清楚、Docker 部署文檔更可用，也減少 fork CI 對貢獻者造成的意外行為。
問題多智能體開發平台常在邊緣環節出問題：container setup、Docker 說明、fork CI 與模糊 diagnostics。貢獻者需要的是能指向下一步的錯誤與設置路徑。

成果 3 個 upstream PR 已合併 · 改進 diagnostics、Docker docs 與 fork-safe CI

角色貢獻者（非維護者）
技術

Go
Docker
GitHub Actions

+1
案例詳情
查看案例查看源碼

解法

我向上游提交了幾個小而實用的修復：diagnostics 顯示 container failure，Docker 文檔對齊當前部署方式，fork CI 不再嘗試 publish images。

技術證據

PR #592：在 diagnostics 中暴露 container setup failure
PR #595：更新 Docker deployment guide
PR #671：避免 fork 環境觸發 Docker publish
貢獻重點：runtime diagnostics、deployment reliability、開發者回饋與 fork-safe open-source CI
№12
D-viva-assistant-agent
查看案例
一個面向論文答辯準備的私有桌面 app。它把學生自己的論文轉成帶來源的練習題、評分與修訂任務，同時把論文文件與練習記錄留在本機。
問題現有答辯準備工具要麼是通用閃卡，要麼每道題都要手打。真正的瓶頸是 grounding：AI 考官只有在問題能追溯到論文原文時才有用；判分只有在能引用所用證據時才可信。

成果已實裝本地優先論文答辯準備 app · 帶來源練習 · 隱私優先桌面使用

角色獨立開發者 — 產品設計、架構、數據庫層、LLM 整合、校驗與測試
技術

Next.js
TypeScript
AI SDK v6

+5
項目截圖

本地優先的論文答辯練習，包含評分與複盤任務。
案例詳情
查看案例查看源碼

解法

我做了一套私有桌面流程：論文先導入成 evidence blocks，練習題與評分都引用這些 blocks，低分回答進入複盤隊列。除非用戶主動選擇 provider，文件與歷史都留在本機。

我的工作

論文 ingest 管線 — PDF / MD / TXT → 段落 evidence block，附導入質量報告；所有下游 AI 調用 grounded 到 ingest 輸出，不靠模型先驗
AI 備考包生成 — 論文摘要、關鍵數字、方法問答、高壓問答、文獻卡；每條引用來源 evidence block，落庫前過校驗器
可編輯備考項、重新校驗、review queue，以及帶無 key 靜態 fallback 的 training plan 生成器
實時 AI 考官 — 從 evidence block 出題，對用戶回答做五維評分（準確性 / 深度 / 語言 / 方法論 / 沉著度），附診斷、英文改寫與追問
STT 練習閉環 — 錄音 → 轉寫（Browser Web Speech 或 Google Cloud STT）→ 判分；低分項進複盤修復板
Provider-agnostic LLM 層 — AI SDK v6 generateObject + Zod 結構化判分；支持 Gemini / Claude / OpenAI；無 key 時優雅降級（練習和轉寫仍可用）
Electron + electron-builder macOS 打包，把產品定位為私有桌面工具，而不是 hosted multi-user service

技術證據

本地優先數據模型：SQLite（better-sqlite3、WAL、FTS5）存論文、evidence block、備考包與練習記錄；DB 完全在本機
隱私設計：雲端 AI 是 opt-in 並明告「發什麼給誰」；API key 在 .env.local（gitignore）；日誌脫敏；錄音不同步
Next.js App Router，DB 僅服務端（runtime=nodejs 邊界、globalThis 單例、serverExternalPackages for better-sqlite3）；AI 調用 env 解析後啟用
測試預設注入 MockLlmClient；真實模型調用由 RUN_LIVE_AI=1 開關控制，且只對公開樣本論文運行
№13
粵語—普通話學習對照工具
打開線上項目
一個輕量學習工具，用來並排比較粵語與普通話讀音。它把香港教育大學的對照資料轉成學習者可用的查詢路徑，加入 Jyutping、錄音與移動端界面。
問題粵語學習者常要在密集對照表、拼音說明與音頻來源之間來回切換，才能理解一個普通話讀音如何對應到粵語。

成果開源學習工具 · 粵普對照查詢 · 支持 Jyutping 與錄音

角色獨立開發者兼學習工具設計者
技術

JavaScript
Jyutping
Language Education
項目截圖

使用說明解釋雙向查詢、漢字檢索、音頻播放與簡繁切換。
案例詳情
查看案例查看源碼

解法

我把對照資料轉成面向學習者的快速查詢路徑，加入漢字檢索、普通話到粵語映射、粵拼、錄音、簡繁切換與移動端支持。

技術證據

純 JavaScript 網頁工具，基於香港教育大學對照表，自行完成粵拼化、音頻錄製與面向學習者的快速移動端查詢界面