这些是我真正
花时间做过的事。

面对 Agent 日志、信息过载或 GIS 代码,我会先找到真正阻塞结果的环节,再决定该做流程、评测还是工具。下面三个案例记录了这个过程。

TB2 Diagnostics
TRACECAUSEFIX

Agent 失败诊断系统

TB2 Diagnostics

把冗长的 Agent 失败轨迹,转成带证据的错误类型和修复优先级,降低人工复盘成本。

为什么值得做结构化诊断把“感觉这个 Agent 不行”变成“哪一层失败、证据是什么、先修什么”,让研发和评测人员能基于同一套口径复盘。

我在里面做了什么负责失败样本分析、分类框架、证据链设计、LLM-as-Judge 流程与人机一致性验证。

阅读完整案例 ↗
FOMO Firewall
LEARNLATERIGNORE

信息分诊与学习助手

FOMO Firewall

为知识工作者做的信息分诊原型:把不断收藏,变成“现在学、稍后看、忽略”三个可执行选择。

为什么值得做如果分诊有效,用户会减少无效收藏,更快进入学习;系统也能从接受和改判中校正偏好,而不是替用户永久做决定。

我在里面做了什么独立完成问题定义、交互路径、分诊逻辑、记忆分层与验证设计。

阅读完整案例 ↗
GeoAgent
SEARCHRUNVERIFY

可验证的 GIS 代码助手

GeoAgent

把 GIS 代码生成从“一次性回答”,改造成检索文档、生成、执行、报错修复和评测的闭环。

为什么值得做把外部知识、执行反馈和评测接进生成链路后,错误能回流到具体环节,用户也能判断结果是否真的可运行、可修复、可交付。

我在里面做了什么聚焦 RAG 知识库、任务数据、评估分析,以及从自然语言到代码生成的路径设计;项目为协作研究。

阅读完整案例 ↗

高精地图实习生

天翼交通科技 · 苏州

调研 GeoJSON、OpenDRIVE 等格式边界,实际交付以 SHP/QGIS 道路要素处理、现场变化核验和平台替换测试为主;一次道路变化在三天内完成修正与验证,并制作 QGIS 插件演示与操作文档。