作品

我從真實問題出發,把複雜流程做成可用的產品

01

核心產品案例

三個案例分別體現三種能力:端到端交付產品、依據使用者反饋持續迭代,以及從行業痛點出發重構工作流。

  1. №01

    能力 完整產品負責能力:流程設計、前後端交付、上線運營與 Agent 迭代

    一個從產品定義、前後端開發到上線運營完整落地的三語實驗招募平台,並以持續校準的審核 Agent 輔助內容治理。

    場景 香港高校實驗招募散落在院系網站、社交媒體、群組與線下海報。研究者缺少連續管理發布、報名審核、排期、補償與口碑的工具;參與者則需在分散來源間反覆核對資格、時間與報酬。

    策略 我為研究者、參與者與管理員設計同一套運營閉環:研究者發布研究、管理時段與審核報名;參與者瀏覽、報名、完成研究並互評;管理員治理外部來源與發布申請。Agent 從來源頁和海報抽取結構化證據,判斷時效、重複與發布風險,再把建議送入對應審核隊列,由管理員作出業務決策。

    評測 採用 2026-07-04 同一口徑的生產數據快照評測:14 次 Agent 運行產生 31 項審核建議,27 項完成閉環,其中 22 項採納、5 項拒絕。一次補償金額誤判被歸因到字段語義,並沉澱為金額拆解規則與 policy gate。

    成果 線上平台現管理 81 項研究(41 項已發布、38 項已完成、2 項已取消)、20 個啟用來源、11 個官方域名與 54 個平台帳號。下一階段將面向高校實驗室與研究團隊開展 B 端推廣。

    項目截圖
    UniExp HK 實驗港首頁,展示研究者與參與者入口
    線上三語實驗招募平台首頁。
  2. №02

    能力 設計完整的雙邊使用流程,並把內測與使用者反饋轉化為產品迭代

    一個面向求職者與招聘者的雙邊決策產品:幫助求職者整理匹配證據,也讓招聘者快速核驗判斷依據,並透過內測與使用者反饋持續迭代。

    場景 求職者需要把職位要求與分散的經歷證據對照,梳理優勢和待確認差距;招聘者則需要在不通讀整個作品集、不依賴黑箱分數的情況下,快速核驗候選人為何可能匹配。雙方共用證據,但承擔不同決策。

    策略 產品接受貼上或上傳的 JD,檢索站內可驗證證據,整理為直接匹配、可遷移經驗、待確認差距與追問,並用來源卡片讓每個結論可回查。求職者用簡報準備投遞與面試,招聘者則基於同一證據繼續自主判斷。

    評測 我圍繞首次進入、JD 提交、簡報生成、Agent 追問和聯絡行動設計內測觀察,並結合招聘者反饋降低首次使用門檻、補充簡報後的行動入口、縮短首屏等待;同時針對空 JD、超長 JD、安全風險和第三方招聘連結等情形完善來源綁定與護欄。

    成果 公開產品已三語上線,支持文字與文件輸入、帶來源的匹配簡報、Agent 追問與清晰後續行動;私有候選人內測在不改變公開流程的前提下,進一步驗證知情同意、材料、報告與反饋閉環。

  3. №03

    能力 識別未被充分解決的行業痛點,把隱性專業判斷轉化為可治理的產品工作流

    一套由創作者主導的創作意圖操作系統,把難以言傳的創意沉澱為可追溯知識,並跨素材、劇本、鏡頭、剪輯與質檢持續傳遞。

    場景 一部電影由一連串相互依賴的創作決策組成:素材理解、故事、劇本、鏡頭、表演與剪輯。單次模型呼叫無法在整條鏈上保留導演權威、前後連貫、素材來源與修訂歷史。缺少製作治理,後續產出容易偏離已核准意圖,也難以說清哪一版被接受、改了什麼、為什麼。

    策略 Director Intent OS 把整條創作鏈視為同一場可追溯、可審查的製作:素材保留來源並被抽取為候選知識,知識經人工簽核後才成為創作依據;故事由創作提要發展至劇本與分鏡;電影中間表示層(Cinematic IR)和不綁定特定模型的鏡頭製作包,把已核准意圖帶入鏡頭規劃;鏡頭裝配計劃(Assembly Plan)協調離線製作;選定的候選鏡次(Takes)再進入修復、剪輯、本地渲染與以證據為基礎的品質檢查。

    評測 以固定的本地多模態流程對 24 個鏡頭形成 168 條原子觀察,鎖定知識抽取與提示行為;這組離線測試驗證知識審核邊界,不將其包裝為成片質量驗證。

    成果 本地創作鏈與離線製作工作台已能在同一項目中持續使用:工作可跨階段恢復,故事可在劇本與分鏡之間延續,鏡頭規劃可一路推進至候選鏡次、修復、剪輯、本地渲染與品質檢查。下一階段將以合格的影片生成模型延伸這條鏈,加入真實鏡頭生成與成片組裝。

02

學術提效工具包

兩款完整、本地優先的 macOS App,分別服務證據型論文寫作與答辯準備。

  1. №04

    能力 把反覆出現的論文寫作摩擦拆解為完整、重視私隱的桌面產品

    一個本地優先的學術證據核驗工作區,以可重現的 NLI 判斷器對照來源,審查論點與引用。它提供 Electron 桌面應用與支援 MCP 的核心;只有使用者主動選擇時,才會透過 scite 或 Consensus 檢索外部證據。

    場景 大規模文獻審查容易出錯:LLM 可能虛構「支持」關係,基於詞彙匹配的判斷器也無法識別矛盾。每條論點都需要可追溯的原文片段與定位資訊,而不能依賴模型猜測。

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

    評測 以 42 條人工標注論點與 317 個離線測試檢查產品,並把它實際用於本人論文寫作流程;迭代依據是證據缺口、誤導性判斷與操作摩擦,而不是模型展示。

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

    技術
    • TypeScript
    • Electron
    • MCP
    • +9
    項目截圖
    D-academic-agent 引文核驗工作區,展示證據判定
    對照已導入來源證據檢查引用。
  2. №05

    能力 把來源材料轉化為練習、反饋與複盤的階段化學習工作流

    一個面向論文答辯準備的私有桌面 app。它把學生自己的論文轉成帶來源的練習題、評分與修訂任務,同時把論文文件與練習記錄留在本機。

    場景 現有答辯準備工具要麼是通用閃卡,要麼每道題都要手打。真正的瓶頸是 grounding:AI 考官只有在問題能追溯到論文原文時才有用;判分只有在能引用所用證據時才可信。

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

    評測 我在真實論文答辯準備中持續使用,檢查問題能否回到論文原文、反饋能否形成具體改進,以及薄弱回答能否進入可執行的複盤隊列。

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

    技術
    • Next.js
    • TypeScript
    • AI SDK v6
    • +5
    項目截圖
    D-viva-assistant-agent 練習工作區,包含考官問題、評分與帶來源複盤
    本地優先的論文答辯練習,包含評分與複盤任務。

03

AI Coding 與開源協作

把反覆出現的開發摩擦沉澱為公開工具、協作契約、上游貢獻與平台交付經驗。

  1. №06

    一個公開、本地優先的開發者工具,檢查 README、操作指南、agent 指令、範例與 API 說明是否仍與目前程式碼庫一致。它讓人工審查、CI 與編程 agent 在採信或修復過期內容前,共用同一份本地證據。

    場景 AI 原生程式碼庫很容易累積過期指令:README 中的命令與 package scripts 不一致,AGENTS.md 和 CLAUDE.md 保留舊路徑,範例不再匹配 API,而編程智能體可能在檢查源碼前就採信這些說明。Evidoc 將文件可信度問題轉化為一套本地證據核驗流程。

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

    成果 公開發布 v0.3.2,並透過 npm 提供 @evidoc/evidoc;交付 CLI、MCP server、本地 Web UI、GitHub Action、Local Git Gate,以及核心庫、儀表板、報告和審查日誌等構件

    技術
    • TypeScript
    • Node.js
    • MCP
    • +5
  2. №07

    一個公開的個人 skills 倉庫,把反覆使用中的多智能體 coding 實踐寫成明確的操作規則。四條已命名工作流覆蓋實際在用的配對 — Claude-Codex 互評、Codex-OpenCode、Codex-Grok 與 Codex-Antigravity — 每條都固定同樣幾個問題:什麼可以委派、什麼保持私有、誰負責 git,以及第二 agent 的意見在成為被採納的改動前必須通過哪些檢查。三條之中有兩條跑在 Codex CLI 裡,編排的是我自己那組六插件矩陣中的插件;第三條跑在 Claude Code 裡,編排的是一個第三方插件。

    場景 多智能體 coding work 如果範圍、隱私、審查權限與驗證責任不明確,很容易失控。第二個 agent 只有在職責範圍受控,且其結論被真實 repo 驗證時才有價值。而真正耗時間的失敗很少是推理出錯,多數是運行時出錯:一個讓第二 agent 啟動即死且沒有有效報錯的配置值、一個只回 id 的長任務、一個被 wrapper 靜默丟掉的參數。

    策略 我把反覆使用中的協作實踐整理成 skills:限制第二個 agent 能看什麼、做什麼,設置審查關卡,並在交付前逐條對照 repo 驗證 — 對方是被委派方時用任務包,對方是同儕時則用一份被評審過的 spec 與 plan。每個運行時失敗都連同症狀、真正成因與確切恢復步驟一起記下,讓下一次會話認得它,而不是重新踩一遍。

    成果 公開 skills 倉庫 · 四條已命名工作流,兩種形態 — 一條同儕互評、三條受控委派 · 實測失敗記錄跨 2026-07 與 2026-08 累積 · 三條委派 skill 以已安裝插件的當前 contract 為準,不釘版本號

    技術
    • Codex
    • Claude Code
    • OpenCode
    • +4
  3. №08

    官方 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 交給另一個工具。

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

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

    技術
    • JavaScript
    • Node.js
    • Claude Code Plugin
    • +2
  4. №09

    官方 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 追蹤。

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

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

    技術
    • JavaScript
    • Node.js
    • Claude Code Plugin
    • +2
  5. №10

    這是 opencode-plugin-cc 的 Claude Code port;後者本身是官方 openai/codex-plugin-cc 介面的 port,改為驅動 Google 的 Antigravity CLI(agy)。它保留 review、adversarial-review、rescue、transfer、status、result、cancel、setup 命令面與可選 stop-time review gate。agy headless 沒有 read-only mode,因此 review 使用一次性工作樹副本,而非真實倉庫。獨立項目,與 Google 或 OpenAI 無隸屬關係。

    場景 Claude Code 需要一條受控路徑使用 Antigravity 側的第二模型,但 headless agy 不能在允許讀取時禁止寫入;能讀倉庫的 reviewer 也能寫。

    策略 這個 port 保留命令面,但把 read-only review 做成文件系統邊界:一次性工作樹副本沒有 .git,真實工作樹在前後都會 fingerprint。這道邊界只適用於只讀 review — 可寫的 rescue 運行是刻意拿到真實倉庫的。Claude Code 保留文件、git 與最終判斷。

    成果 公開 v0.1.0 · 經 opencode-plugin-cc 移植 codex-plugin-cc 介面 · 鏡像式 read-only review · 可選 stop-time review gate

    技術
    • JavaScript
    • Node.js
    • Claude Code Plugin
    • +2
  6. №11

    一個公開的 Codex plugin,讓 OpenCode 直接在 Codex 內參與代碼審查、排障與任務交接。長時間任務可查看進度或取消,可見對話與私有上下文則保持分隔。

    場景 Codex 與 OpenCode 各有優勢,但手動切換通常會丟上下文,也讓審查難以追蹤。這個項目的目標,是把 OpenCode 變成 Codex 裡可控的協作方,並保留清楚的 job control 與窄隱私邊界。

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

    成果 公開 v0.2.3 · 十一個 typed MCP tools 共用同一個 response envelope · Codex 內的 OpenCode 審查支援

    技術
    • TypeScript
    • Node.js
    • MCP
    • +3
  7. №12

    一個公開的 Codex plugin,讓 Codex 在不交出隱藏上下文的前提下,調用本機 Grok CLI 執行限定範圍的代碼任務、審查、故障診斷、對抗式檢查、工作階段檢視與背景工作。

    場景 Grok 可以提供另一個工程視角,但手動切換工具會讓 scope、session history 與審查責任變得難控。這個項目的目標,是讓 Codex 能請 Grok 協助,同時仍由 Codex 掌握文件、測試、git 與最終判斷。

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

    成果 公開 Codex plugin · 0.3.0,在 typed MCP 介面上報告 contract version 3,並帶 explicit workspace roots · Codex 內的 Grok review 與 rescue · 受控第二 agent 工作流

    技術
    • TypeScript
    • Node.js
    • MCP
    • +3
  8. №13

    這是一個含 MCP server 與 vendored Skill 的 Codex plugin,是 opencode-plugin-codex 與 grok-plugin-codex 的 sibling。agy adapter 依據量測過的 runtime contract 編寫:docs/AGY-RUNTIME-CONTRACT.md 的每項行為主張都有對應 probe 命令,而非按別的 CLI 類比。獨立項目,與 Google 或 OpenAI 無隸屬關係。

    場景 agy 忽略進程 cwd,而且只是「被告知」--add-dir 指向的那個目錄 — 它跳過權限提示運行,並不被限制在該目錄內;即使 --add-dir 指向不存在的目錄,agy 仍可能返回 SUCCESS,並在錯誤位置執行任務。它不能分開讀寫權限,且自報 outcome 與 exit code 獨立。

    策略 plugin 在 spawn 前驗證工作樹,無法解析就回傳 typed refusal。read-only review 取得一次性工作樹副本,只有 resultComplete 才表示任務完成;exit code 仍作為失敗分類依據記錄,但不用於判斷任務是否完成。

    成果 公開 v0.1.0 · 附公開 probe 的量測 agy runtime contract · 文件系統隔離的 read-only reviews · restart-safe 背景 jobs

    技術
    • TypeScript
    • Node.js
    • MCP
    • +3
  9. №14

    一個給日常使用多個 AI coding 帳號的人用的 macOS menu-bar 工具。它把帳號池、剩餘額度與被限流狀態放在眼前,避免任務執行到一半才發現額度或限流問題。

    場景 AI coding 任務常因額度或帳號池狀態不可見而中途受阻,直到 provider 限流才發現問題。選單列上的精簡信號能在工作停下前給出預警。

    策略 我開發了一款原生 macOS 選單列應用,定時取得額度與帳號狀態,並在選單列集中呈現關鍵信號,讓使用者在任務因限流中斷前切換帳號池。

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

    技術
    • Swift
    • macOS
    • Developer Tools
    項目截圖
    relaybar macOS 選單列面板,顯示 AI coding 帳號用量與額度狀態
    面向日常 AI coding 的選單列額度與帳號池狀態。
  10. №15

    對 Go 多智能體平台 Memoh 的開源維護貢獻;它用隔離環境運行 coding agents。已合併的 PR 讓錯誤診斷更清楚、Docker 部署文檔更可用,也減少 fork CI 對貢獻者造成的意外行為。

    場景 多智能體開發平台的容器配置、Docker 部署說明、分支倉庫 CI 和故障診斷等外圍環節容易出錯;貢獻者需要能夠直接指向下一步操作的報錯和配置路徑。

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

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

    技術
    • Go
    • Docker
    • GitHub Actions
    • +1
  11. №16

    Power Minder(满电!)由我獨立開發,於 2025 年春以付費工具 App 形式全球上架 App Store(中國區定價 ¥1),現已下架。它按裝置管理家庭充電節奏,支援每日、每周指定星期、每月指定日或每 N 天提醒,並記錄上次充電時間與電量狀態。SwiftUI、本地通知與 CloudKit 同步支援 en/zh-Hans 雙語使用。我獨立完成從 HTML 原型到 App Store 審核材料的全流程,包括內嵌私隱政策與服務條款頁。

    場景 相機電池、Switch 等家庭裝置需要各自的充電節奏與記錄。以裝置為單位可把上次充電時間和電量狀態與每個提醒放在一起。

    策略 裝置檔案把週期性充電提醒與上次充電和電量狀態記錄配對。本地通知驅動節奏,CloudKit 同步與本地持久化保存資料。

    成果 於 2025 年春以付費工具 App 上架 App Store · en/zh-Hans 雙語 · 現已下架

    技術
    • Swift
    • SwiftUI
    • iOS
    • +3
    項目截圖
    Power Minder 截圖,展示裝置詳情、提醒列表與裝置列表

04

更多作品

延伸同一套問題發現與產品交付方法的其他產品和學習工具。

  1. №17

    職位匹配 agent 把貼上或上傳的 JD 整理成附來源的職位匹配報告,供招聘方快速核對;同一套 han-dong.link 也把即時問答助手與 Three.js 駕駛艙串起簡介、作品、研究與履歷。

    場景 公開作品集要同時服務招聘方、技術同儕與研究合作者,不能讓讀者自己猜每個主張背後有什麼證據。靜態頁面可以列出作品,但很少能回答職位相關問題,也很少展示網站本身如何組織證據。

    策略 我做了空間化駕駛艙,也保留標準閱讀頁;兩種入口與問答、職位匹配共用同一套站內內容。訪客可以打開簡介、作品、研究與履歷四個星球,也可以線性閱讀或透過帶證據的卡片提問。

    成果 已在 han-dong.link 上線 · 主頁駕駛艙入口呈現即時作品集數量 · 答案卡引用來源頁 · 可見回答軌跡 · 職位匹配把 JD 文字或文件整理成直接匹配、可遷移經驗、待確認差距與追問

    技術
    • TypeScript
    • Astro
    • React
    • +7
    項目截圖
    han-dong.link 駕駛艙,包含四個星球、導航、問答助手與職位匹配 JD 流程
    空間化駕駛艙是作品集的預設入口。
  2. №18

    一個輕量學習工具,用來並排比較粵語與普通話讀音。它把香港教育大學的對照資料轉成學習者可用的查詢路徑,加入 Jyutping、錄音與移動端界面。

    場景 粵語學習者常要在密集對照表、拼音說明與音頻來源之間來回切換,才能理解一個普通話讀音如何對應到粵語。

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

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

    技術
    • JavaScript
    • Jyutping
    • Language Education
    項目截圖
    粵語—普通話學習對照工具使用說明,解釋查詢模式與功能
    使用說明解釋雙向查詢、漢字檢索、音頻播放與簡繁切換。
想知道這些作品是否符合職位要求?貼上或上傳職位描述,即可生成有證據支持的匹配報告。 前往「職位匹配」→