作品

我从真实问题出发,把复杂流程做成可用的产品

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
    项目截图
    粤语—普通话学习对照工具使用说明,解释查询模式与功能
    使用说明解释双向查询、汉字检索、音频播放与简繁切换。
想知道这些作品是否符合职位要求?粘贴或上传职位描述,即可生成有证据支持的匹配报告。 前往「职位匹配」→