作品

我从想法做到可用版本的软件产品、研究工具与语言学习项目。

№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
后台 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 网页工具，基于香港教育大学对照表，自行完成粤拼化、音频录制与面向学习者的快速移动端查询界面