我不是“只会写需求”的产品经理。 我是一个真正从 0 到 1 做出过 AI 系统，也能把技术翻译成用户价值的人。
华中科技大学电子信息硕士在读，主导完成 Gestar 项目：以 GNSS 卫星信号实现户外手势识别， 从用户调研、系统设计、模型训练，到 Android 双平台 App 交付全链路独立负责。 我希望成为一名真正能连接技术、产品与体验的 AI PM。
从技术可行性到用户价值，从研究论文到双端产品交付，我希望让“复杂 AI 能力”变成“可被用户感知的体验优势”。
学历与专业是我的底座，但让我真正有辨识度的，是我能把技术深度、产品思维和审美感知同时放进一个人身上。
在华科读研期间，我主导完成了 Gestar——一套利用 GNSS 卫星信号实现户外手势识别的端到端 AI 系统。 这不是一个单点技术实验，而是一段完整的产品实践：从发现问题、验证需求、设计方案，到模型训练、App 开发和硬件集成，我几乎独立走完了产品从 0 到 1 的完整链路。
这段经历让我意识到：AI 产品经理真正稀缺的能力，不是“懂一点技术”，而是能在技术约束、业务目标与用户体验之间持续做高质量判断。 我既能理解模型、数据、端侧推理这些底层约束，也能站在用户价值与商业可行性的角度，定义一个产品为什么值得被做。
除了技术与产品，我还拥有较强的视觉表达能力与团队领导经验。兼职模特、院女篮队长、校队足球经历，让我在审美、表达、协作和抗压上，都形成了比同龄 PM 候选人更立体的优势。
不是“把技术做出来”而已，而是从用户场景出发，定义一套原本不存在的交互可能性。
户外环境中，摄像头受光照和遮挡影响，毫米波和 WiFi 方案又存在覆盖与部署限制。 我发现了这一“非接触交互的户外空白”，并提出使用 GNSS 卫星信号进行手势识别的全新方案， 完成从需求定义、用户研究、技术路线设计，到轻量化模型与 Android 双平台 App 交付的全链路实践。
如果站在 AI 产品经理视角看，Gestar 的意义在于它验证了一个被低估的方向： 在传统感知方案失效的场景里，仍然可能存在新的交互基础设施。
这里放置 Gestar 的演示视频。鼠标移动到视频区域时自动循环播放，移出后暂停。
先从场景出发而非技术：现有手势识别在户外强弱光、偏僻地域中普遍失效，而 GNSS 卫星信号「天然覆盖、免部署、不受遮挡、不依赖摄像头」，可能是一个没人认真做过的感知入口。
我不是先从技术出发，而是先从场景出发。现有手势识别大多依赖摄像头、雷达或局域信号， 但在户外高光照或低光照、偏僻地域中使用时，这些方案都存在明显限制。 我意识到，GNSS 卫星信号具备"天然覆盖、无需额外部署、不受近距离遮挡影响、且不依赖摄像头数据采集保护用户隐私"的特征， 它可能成为一个此前没人认真做过的感知入口。
对 PM 来说，最重要的不是“技术能不能做”，而是先判断“这个问题是不是真的存在，而且值不值得被重新定义”。
为确认方向不是「研究者自嗨」，我主导用户调研，招募 33+ 名真实用户、覆盖 6 类户外场景，定义出用户最需要「非接触、低延迟、不依赖视觉」交互的具体情境。
为了确认这个方向不是“研究者自嗨”，我主导开展用户调研，招募 33+ 名真实用户， 覆盖运动、户外作业、导航、无障碍辅助等 6 类典型使用场景。通过任务拆解与场景归纳， 我进一步定义出用户在什么情境下最需要“非接触、低延迟、不依赖视觉输入”的交互方式。
GNSS 原始信号并不天然适合做手势识别。我主导设计 G-Map 表示法，把多颗卫星信号映射为二维热力图，让稀疏离散的时序信息变成 CNN 可学习的特征输入。
最大难点在于 GNSS 原始信号并不是天然适合做手势识别的数据形态。 我主导设计了 G-Map 表示法，将多颗卫星的接收信号映射为二维热力图， 让稀疏、离散的时序信息变成 CNN 可学习的特征输入。 这个过程本质上是在做一件 PM 常做的事：把抽象能力转换成可用结构。
真正好的方案设计，不是炫技，而是在技术约束里找到一个最能支撑用户价值的表达方式。
自研 CNN-LSTM + Attention 轻量化模型，在有限算力下完成高精度实时推理，并交付 Android 手机端 + Pixel Watch 2 手表端双平台 App，让项目真正「被用起来」。
我自研 CNN-LSTM + Attention 轻量化模型，结合深度可分卷积与滑动窗口注意力机制， 在有限算力与内存约束下完成高精度实时推理。 同时开发 Android 手机端与 Pixel Watch 2 手表端双平台 App，并集成商用硬件模块， 让项目真正具备“被用起来”的产品形态，而不是只停留在实验结果。
一段实习，三个模块：我从 Mira 团队核心成员做起，主导 Skill 技能生态这条线（治理 / 评测 / 安全），并参与 Task 任务能力打磨；
后来团队架构调整并入豆包企业版——一个全员开通、嵌在飞书里的产品，在这个底盘之上我们做了面向 TikTok 与海外同事的
豆包企业先锋，那是一次真正的 0→1；四个月里我独立上线了 15 个需求，
还发起并主导了 AI-native 研发提效平台 oh-my-mira。
（下面三个模块按「最近的放最前」排列：Pioneer → Mira → oh-my-mira。）
Mira 之后，团队并入豆包企业版——公司给每位员工都开通、直接嵌在飞书里，这是我们那条主线的规模化底盘。 在此之上我们做了豆包企业先锋，面向 TikTok 部门与海外同事。 这一次是真正的从零开始：国内那套工作流搬过去并不成立，「第一个版本该带什么上路」必须重新回答一遍。 第一个版本的范围取舍我从头跟到尾——把大半能力推到后面，只留一条最小闭环。
「先锋」这个名字本身就是节奏的证据——它比国内版快得多。 快是优势，也意味着没有试错第二遍的余量：摊子一铺开，失败就无法归因。 所以第一个版本最关键的产出不是加了什么，而是敢让哪些东西不出现。
Mira 团队架构调整后并入豆包企业版——一个全员开通、嵌在飞书里的产品。在这个底盘之上，我们为 TikTok 与海外同事做了豆包企业先锋，这次是真正的 0→1。
两段经历性质完全不同，我不想把它们混成一件事：在 Mira，我是在一个已有相对完整形态的产品里把 Skill 这条线做深—— 不能推翻已有设计，还得照顾住已经在用的人；Pioneer 才是真正的从零起——没有存量用户、没有既定形态， 第一版的边界要自己划。前者考验的是在约束里做深，后者考验的是在空白里做减法。
并入企业版让这条主线有了规模化的底盘，Pioneer 让我第一次面对「第一版该长什么样」这个问题。
用户从「字节全体员工」换成「TikTok 与海外同事」。他们每天用的工具、协作的方式和国内不是一套——「国内这么用」不能再当作论据，每条需求都要重新确认它对这批人是否成立。
最容易犯的错是把国内版的成功当成经过验证的结论直接搬。但一个功能在国内成立，靠的往往是国内特有的协作习惯与配套工具； 这些前提一换，同一个功能的价值可能直接归零。所以我们在讨论第一版范围时， 把「国内已经这么做了」从论据里划掉了——它只能作为线索，不能作为理由。
把别人的答案照抄过来最省力，但你就永远不知道这道题的题目其实变了。
摆在桌上是一份很长的能力清单，几乎每一项都「看起来该有」。我们把大半推到了后面，第一个版本只留一条最小闭环：能对话、能开一个带上下文的项目空间、能把重复的事挂成任务、能接外部工具。
做减法的理由不是资源不够，而是可归因。一条跑得快的线，功能越多反而越慢： 摊子一铺开，某个环节没人用，你分不清是方向错了、还是这一处没做好，下一版就只能靠猜。 所以第一版我们只保留一条能自证价值的路径——用户能进来、能把一件真实的事从头做完。 其余能力不是被否掉，是被排到了「等这条路径被验证之后」。
我博客里那句话就是这段时间攒出来的：平庸的人做加法，有品味的人做减法。真正花掉的功夫不在写多少，而在决定哪些不写。
几类同事装的是同一个包，进来却该走向不同的地方——有人该进这条线，有人手上另一个版本更合适，也有人纯粹是走错了。我们给走错的人做了一个中间页面，让他自己选往哪儿走。
这类路径的共同点是：它不该发生，但它一定会发生。在功能清单上它排不进前二十， 可它决定的是一个真实用户的第一印象——第一次打开就撞上报错，后面做得再好他也不会回来。 我在自己那套 AI Agent 的对照实验里也验证过同一件事： 质量差距几乎全在非主路径上，因为「主流程能跑」是一个太容易达到的完成标准。
主路径决定产品能不能演示，非主路径决定产品能不能被信任。
Mira 是面向字节全体员工的 AI 工作平台。我进组时它已经有相对完整的产品形态， 所以我做的不是从零起，而是在一个成型的产品里把一条线做深——这反而更难：不能推翻已有设计，还得照顾住已经在用的人。 我主要负责 Skill 技能生态（生态治理、模型适配评测、安全检测三件事），并参与 Task 任务能力打磨。 工作方式是「PM 主导产品与交互设计 + 前端为主、打通后端自交付」，跨团队的部分（安全业务方、运营侧研发）由我对接推进。 后来团队架构调整并入豆包企业版，同一条主线继续。
Mira 已经有相对完整的形态和真实用户，这意味着我的每个决策都带着约束： 不能推翻已有设计、不能弄坏已经在用的人的东西，还要把 Skill 这条线做到能规模化。 我在其中主导的，正是决定生态能否规模化的三件事——治理、评测与安全底座；跨团队的部分（安全业务方、运营侧研发）由我对接推进。 后来团队并入豆包企业版，同一条主线继续。
鼠标移动到视频区域时自动循环播放，移出后暂停。
把「发现 — 判断 — 安装 — 管理」这条任务链路系统性补齐，并用数据驱动生态治理。我的角色：PM 主导交互设计 + 前端为主、打通后端全栈自交付。已全量上线：用户从「滚动翻找、逐个操作、无从辨别」升级为「能搜、能排、能批量管、一眼识官方」。
目标是让用户找得到、信得过、管得动，同时让默认预装的生态保持精简。 我的思路不是零散加功能，而是把「发现 — 判断 — 安装 — 管理」看成一条完整任务链路， 缺哪一环补哪一环：搜不到就做语义搜索、判断不了就把官方身份显式化、管不动就做批量操作与个人频次排序。
技术上有一处我比较满意的收敛：排序功能最初的方案是新增 2 个接口， 我把它收敛成复用 skill list 接口扩展 need_personal_usage 参数 + 用户维度用量表—— 在一个已经有人在用的产品里，最小改动本身就是一种产品判断。前后端我自己写、自己推 PPE 验证上线。
另一半是治理：基于 TEA 埋点做全量调用频次分析，识别出「高频使用」和「凭直觉预装」之间的偏差， 产出《默认预装 Skill 精简方案》并推动下线低频预装项。预装决策从「拍脑袋」变成「看数据」。
好的方案设计不是加接口，而是在满足需求的前提下，找到最小改动、最可维护的那条路径。
从 0 规划「合规准入 + 多模型评测」两期架构，并按 Skill 的产出类型设计差异化评测方案，在有限算力下保证结论有效。我的角色：PM 独立产品设计，产出全场景可交互原型，对接运营侧研发。
一期（已上线）：合规准入 + 运营提效。搭建 47 项规范检查 + LLM 合规检测的静态准入检测器， 并把放行标准从「全项评分」优化为「关键项阻断 + 其余项提示」——不是所有问题都值得拦人， 这一改动显著降低了运营的审核成本。
二期（方案就绪，未开发）：多模型横评 → Top 3 推荐。核心设计是「选手 / 裁判分离 + 核验层」： 执行端产出客观 trace、固定裁判模型统一打分、有副作用的操作强制留 verify_token 回查， 用来解决模型自评偏差和「自报成功、实际没执行」的虚高成功率。 另外按 Skill 的产出类型做了差异化设计：功能型做兜底、效果型做 Top 3 推荐—— 因为算力有限，不可能所有 Skill 都跑满全模型，取舍本身是方案的一部分。 我产出了全场景可交互原型，并推动运营 / 算法 / 研发多方对齐。
这一期最终没有开发——赶上业务方向调整暂缓了。我把它照实写在这里： 方案对齐完成、原型交付、结论可复用，但它没有上线数据，我不想把它说成已经跑起来的东西。
让模型自己判断自己做得好不好，等于让考生自己判卷。把「执行」和「打分」拆开，是这套体系唯一真正重要的决定。
上架的 Skill 有审核，个人自建的没有——这是生态里最容易被忽略的一块。我对接安全业务方的接口设计检测链路，把风险在用户使用之前透明呈现。我的角色：PM 主导需求与方案，对接安全业务方与运营侧研发。
目标很明确：让未走上架流程的个人 Skill 也有安全兜底。我对接安全业务方的接口设计了检测链路， 并且没有停在「检测出来」——高风险技能要做风险标识管控、禁用分享等扩散动作， 检测结果直接展示在详情页上。关键判断是「在用户使用前」而不是「出事后回溯」。
我还以安全视角提出了回调鉴权的加固方案（HMAC / mTLS 验签 + 防重放 + task_id 校验）， 以及「上传即时触发 + 定时全量兜底」的双扫描链路。
一个开放生态真正的风险不在被审核过的那部分，而在没人管的那部分。
这条线不是我主导的，我参与其中若干能力的设计与交付：自定义 Bot 通知等，并提出「1 份共享底座 + 4 份角色差异层」多 Agent 协作框架，把球权交接、证据分级等隐性协议显式化。
交付自定义 Bot 通知（选择器 + 去重 + 灰度）、RUNNING 状态置顶、编辑态 status 误关 bug 修复； 基于竞品调研以「零配置 + 立即见效」为标准筛选并上线 6 个引流模板。 同时提出「1 份共享底座 + 4 份角色差异层」多 Agent 协作框架，将球权交接、证据分级、 停机条件等隐性协作协议显式化，保障多角色间协议一致。
在反馈群 oncall 一线支持用户，搭建每日跨群反馈自动归纳定时任务（去重 + 来源标识 + 台账/日报/周报/月报），让一线反馈可沉淀、可追溯。
在反馈群 oncall 一线支持用户，搭建每日跨群反馈自动归纳（去重 + 来源标识 + 台账 / 日报 / 周报 / 月报）定时任务；持续输出大厂动态追踪与产品 sense 沉淀，让一线反馈可沉淀、可追溯。
oh-my-mira 是我从一线痛点中发起并主导的独立 0→1 项目：一个面向公司内部研发团队的 AI-native 研发提效平台，目标是让「提需求」直接产出「可合并的代码」。 核心卖点很直接——一个算法背景、看不懂前端代码的 PM，靠 AI 也能交付前后端需求， 而我本人就是这个价值主张的活证明。
我发现的不是「某个需求难改」，而是 「每个跨端需求都难改」——这是会重复无数次的结构性成本。 让研发帮忙只解决一次，做成工具解决的是一类，还能复制给同样「想改却碰不动代码」的设计部门。
算法背景转产品，我靠 vibe coding 覆盖了前端改动，但很快撞墙：很多需求必须动后端，而后端仓库多又割裂，AI 一次只能看一个孤立仓库根本帮不上忙。
我是算法背景转产品。进组后接的第一类需求是前端改动，说实话前端代码基本看不懂， 但我用 vibe coding——在终端里用自然语言描述需求、让 AI 去改、我来判断改得对不对—— 居然基本覆盖了这些需求。可不到一周就撞了墙：很多需求光改前端不够，必须动后端， 而后端仓库又多又割裂，AI 一次只能看一个孤立仓库根本帮不上忙。
这不是我个人不熟业务的问题，而是结构性问题：工具的视野，被仓库边界切碎了。
我主动找 leader 提案：做一个能同时连接所有代码仓库的 AI Agent 跨前后端改动，入口做成飞书机器人，底层用 Claude 保证质量——一句话描述需求，自动提 MR。
我把痛点抽象成产品方案，主动找 leader 提案：做一个能同时连接所有代码仓库的 AI Agent， 让它跨前后端改动；入口做成飞书机器人，我不用在一堆终端和仓库间切换，直接在飞书上「派活」； 底层继续用 Claude 保证代码质量。目标状态——我一句话描述需求，它前后端一起改、自动提 MR， 我只在关键节点做决策。
方案落地为「调度层 + 全局代码上下文 + 协作层」三层架构。核心解法是把所有产品代码统一挂进 Agent 工作空间——我概括为「workspace 即上下文」，并为高风险变更设人工审核硬约束。
方案落地为「调度层 + 全局代码上下文 + 协作层」三层架构。我主导判断的核心点正是我最初的痛点—— 让 AI 拥有跨仓库的全局视野，解法是把所有产品代码统一挂进 Agent 的工作空间， 我把它概括为「workspace 即上下文」。同时为安全设硬约束： 高风险变更必须人工审核才能合入。
现成工具是「单仓库、补全级」，我需要的是「全局、交付级」。它不是更快的打字机，是会自己提 MR 的初级工程师。
「飞书提需求 → AI 跨仓库改代码 → 自动提 MR」全链路跑通，我亲自完成首个真实业务需求的全链路验证，达成 0→1 里程碑，还推广到了设计部门；后来 leader 在这套东西之上做了更进一步的产品，给机器人配上了类似「员工」的身份和权限。
「飞书提需求 → AI 跨仓库改代码 → 自动提 MR」全链路跑通，我亲自用它完成了第一个真实业务需求的 全链路验证，达成 0→1 里程碑。一个看不懂前端、不熟后端的算法背景 PM，现在能直接在飞书上把前后端需求 都跑出来，还推广到了设计部门——他们和我当初一样有明确诉求却碰不了代码，也能一句话上线自己的需求。 再后来 leader 在这套东西之上做了更进一步的产品，给机器人配上了类似「员工」的身份和权限—— 一个从个人痛点长出来的想法，最终沉淀成了组织级的基础设施。
我用三层判断兜住质量：结果验证 + 方案合理性判断 + 借力研发兜底，并清醒地把长期价值锚定在人机协作流程、安全边界与需求规范的沉淀上。
我不盲信 AI，而是用三层判断兜住质量：结果验证（改完看实际效果、有没有破坏其他功能）、 方案合理性判断（Agent 的实现思路方向对不对、有没有绕路，这是算法训练出的工程直觉）、 借力研发兜底（拿不准的去请教负责那块的同学）。我也清醒地知道： 流程编排是模型升级的中间态，长期价值要锚定在人机协作流程、安全边界与需求规范的沉淀上。
单个 Agent 最大的问题不是不够强，而是它既是执行者又是验收者，不会承认自己不行。所以我把它拆成五个角色（boss / pm / coding / qa / review），并用四组对照实验验证分工到底值不值——结论是：换更强的模型把 20 项验收从 12 项提到 16 项就停住了，加上分工才到 19 项。
实验怎么设计的（这部分比数据重要）。同一句话——「设计一个类似《我的世界》的游戏， 交付一个可以直接运行体验的 Web 版本」——发给四种配置，用我提前写死的 20 项验收用例打分，避免事后找理由。 关键是我特意加了「单个 Agent + 最强模型」这一组：不加这组，「分工有用」随时可以被一句「不就是模型更强吗」推翻。 这一组是用来否证我自己的假设的。
结果。单 Agent 配中等模型通过 12 项、4 个严重缺陷；换成最强模型到 16 项、2 个； 五角色团队到 18 项、1 个；按职责给不同角色路由不同模型的团队到 19 项、0 个严重缺陷。 两笔账要分开算：12→16 是模型的功劳，16→19 是分工的功劳。模型能补一部分，补不完。
差距在哪。剩下的问题几乎全在非主路径：出生点是否安全、放置方块时会不会占住自己身体、 窗口失焦后按键不释放、重开一局旧的计时器没清理。它们的共同点是—— 「项目能跑起来」的时候，这些问题一个都看不见。单 Agent 交付时项目确实能跑， 所以它认为自己做完了；它不是不会修，是没有立场发现——它的盲区和它的能力同源。 所以我还让 review 和 coding 用不同家族的模型：同一个模型既写又审，审不出自己的思维习惯。
代价与边界（我不想只讲好的一面）。团队最慢也最贵——同构团队三倍多 Token、无效调用占到 19%， 因为五个角色用同一个模型时，几个角色在重复分析同样的东西。所以我不会所有任务都开团队： 快速验证想法用单 Agent，十几分钟就有东西看；要交一个能演示的东西才值得开团队。 而且要开团队的话，优化模型路由比多加角色划算——同样五个角色，只改路由就省了两成 Token、还多过一项。 另外 19 和 18 只差一项，样本量不足以说统计显著，这一点我在自己的报告里专门标注了不要过度解读。
这套东西已经跑通并真交付过东西；这个思路后来也被当成一个方向，在 Pioneer 那边讨论过。
我一开始以为我在优化提示词，后来发现我在设计一套分工。
我持续深度使用 ChatGPT、Claude、Gemini、Kimi、豆包、DeepSeek 等主流 AI 产品。 对我来说，使用它们不是“尝鲜”，而是一种持续的产品观察训练。
很多 Agent 失败不是模型不行，而是任务边界不清、过程不可见、失败不可回退。我更关注「交付可靠感」的设计，而非「功能看起来很强」。
很多 Agent 产品失败，并不是模型能力不够，而是任务边界不清、中间过程不可见、失败不可回退、用户对系统状态没有信任感。 真正成熟的 Agent 产品，关键在于重新设计人机协作界面：哪些步骤应该自动化，哪些步骤必须可确认，哪些状态必须显式反馈。 我更关注“交付可靠感”的设计，而不仅仅是“功能看起来很强”。
AI 产品最关键的决策常常不是「选哪个模型」，而是在技术可行性、数据质量、成本与交付速度之间做平衡，在所有人都说「不能做」的地方找到「可以做成」的路径。
在 Gestar 项目中，我们遇到的最大困难，是如何在 GNSS 信号的极致"微弱"与"复杂"中，提取出足以支撑高精度 AI 识别的"稳定且有判别力"的手势特征。信号微弱、稀疏、噪声大，缺乏先例与经验，且难以将"物理现象"转化为"机器学习特征"。我们通过分布式感知与 G-Map 编码、精细的特征工程、数据与验证的循环迭代克服了这些困难。 这段经历让我更深刻地理解：AI 产品里最关键的决策，常常不是"选哪个模型"，而是如何在技术可行性、数据质量、成本约束与交付速度之间做平衡，在所有人都认为"不能做"的地方找到"可以做成"的路径。这也是为什么我认为懂训练数据与评估逻辑、理解技术边界、敢于在不确定性中做产品判断的 PM，会比只会写流程的 PM 更有长期价值。
我不把端侧 AI 看成云端的缩水版，而是另一套产品逻辑：当设备从手机延伸到手表、手环，交互方式需要重新设计，穿戴设备可以成为独立的输入入口。
很多人把端侧 AI 理解为云端能力的缩水版，但我更愿意把它理解为另一套产品逻辑：当设备形态从手机延伸到手表、手环等穿戴设备时，交互方式也需要重新设计。Gestar 的端侧部署经历让我相信，穿戴设备不应该只是手机的附属品，而可以成为独立的信息输入和交互入口。 通过利用 GNSS 等环境信号，我们可以在穿戴设备上实现手机无法完成的交互场景，如运动中的手势控制、户外作业的便捷操作等。同时，不依赖摄像头的技术路径也为隐私敏感场景提供了新的可能性。
我不把技术能力和产品能力看成两条平行线。对 AI PM 来说，它们应该彼此校准、共同决定判断质量。
好的产品人，往往不只是「会做产品」。真正有判断力的人，通常都有不止一种看世界的方式。
这些经历看似与 AI 产品经理无关，但它们共同塑造了我的判断方式：如何在高压下做决定，如何理解团队协同，如何感知体验细节，如何站在陌生用户的角度重新理解一个问题。
作为院女篮队长，率队夺得“华工杯”冠军，也参与高强度正式赛事。
校队与院队首发，参与长期体系化训练与比赛，理解“局部动作”如何服务整体战术。
足迹遍布7个国家，我喜欢把自己放进陌生环境里，观察细节与差异。
兼职拍摄百余套造型，从镜头、构图、风格与表达中理解“被感知”的重要性。
独立负责学术会议全流程策划，从议程、物料到现场体验，把复杂事情做到有秩序。
从通信工程到电子信息硕士，系统训练了我拆解问题、建立假设、验证结论的能力。
我习惯长期观察 AI 产品、记录感受与差异，把“使用体验”转化为“产品判断”。
无论是比赛、项目还是活动，我都习惯在关键时刻承担“连接者”和“推进者”的角色。
我想呈现的不是“在技术外围的产品执行者”，而是一个具备技术深度、能在不确定性中找到突破路径的未来 AI 产品决策者。
目前正在寻找 AI 产品经理 / 技术产品方向的校招机会。 如果你正在寻找一个既懂技术、又有产品判断力，同时具备表达与体验感知能力的人，欢迎联系我。
算法背景出身，做得出模型，也交付得了产品。 我能从模型训练、数据增强到端侧部署，独立跑通一整套 AI 算法系统， 也擅长借助 AI 工具把想法快速交付成可用的产品。
华中科技大学电子信息硕士在读。主导 Gestar：以 GNSS 卫星信号做户外手势识别， 自研轻量化 CNN-LSTM+Attention 模型（96.43% 准确率 / 5.81ms 推理），并交付 Android 双端 App（一作论文投稿 IEEE TMC，CCF-A）； 实习期在企业级 AI 助手 Mira 担任 PM（由算法岗调整而来），并独立发起 AI-native 研发提效平台 oh-my-mira—— 从痛点识别到方案设计，用 AI coding 把跨仓库的前后端需求一路交付上线。
从模型训练、数据增强、量化推理到端侧部署，我能独立打通 AI 算法系统的完整链路； 工程落地上，我用 AI coding 把算法能力延伸成可上线的产品。
通信/电子信息的科班底座，加上算法训练与端侧部署的实战，再加上「靠 AI 把想法交付上线」的能力，让我能独立扛下一个 AI 算法系统从模型到落地的全链路。
在华科读研期间，我主导完成了 Gestar——一套利用 GNSS 卫星信号实现户外手势识别的端到端 AI 系统。 我自研 CNN-LSTM+Attention 轻量化模型，设计 G-Map 信号表示法与 Diffusion/KDE 数据增强策略，把识别准确率做到 96.43%； 并把它工程化落地：Android 手机端 + Pixel Watch 2 手表端双平台 App、商用硬件（Ublox M9N）集成，实现 25Hz 实时推理。这套系统全部由我用 Python 完成算法与训练。
实习期我以算法岗进入企业级 AI 助手 Mira 团队，第一周做了岗位调整、转为 PM，主导 Skill 技能生态这条线（生态治理、模型适配评测、安全检测）的产品设计与推进，并参与 Task 任务能力打磨。 推进过程中涉及的前后端改动，我是靠 AI coding（Claude）辅助落地、并推 PPE 验证上线的。 同时我发起并主导了 AI-native 研发提效平台 oh-my-mira，用「workspace 即上下文」架构让 AI Agent 跨仓库改代码、自动提 MR—— 从痛点识别到架构设计再到 AI coding 落地，把跨仓库的前后端需求一路交付上线。
我相信 AI 时代的价值，不在于“会写多少行代码”，而在于能否理解模型边界、驾驭工具链、 并对系统质量与安全边界做出可靠判断。算法训练给了我工程直觉，AI-native 的交付方式让我把这份直觉变成真正能上线的东西。
从 GNSS 原始信号到端侧实时推理——一套我独立完成的算法设计、模型训练与工程落地全链路。
GNSS 原始信号稀疏、微弱、噪声大，天然不适合做手势识别。我设计 G-Map 表示法将多星信号映射为二维热力图， 自研轻量化 CNN-LSTM+Attention 模型，并用 Diffusion/KDE 数据增强解决稀疏样本问题， 最终在 Android 手机端 + Pixel Watch 2 手表端完成端侧部署与商用硬件集成，实现 96.43% 准确率、5.81ms 实时推理。
如果站在工程视角看，Gestar 的意义在于它是一条完整跑通的技术链路： 从数据表示、模型自研、训练调优，到压缩量化与端侧部署，每一环都由我独立实现。
这里放置 Gestar 的演示视频。鼠标移动到视频区域时自动循环播放，移出后暂停。
GNSS 卫星信号「天然覆盖、免部署、不受遮挡、不依赖摄像头」，但原始信号稀疏、微弱、噪声大，天然不适合做识别。第一步不是训模型，而是把物理现象建模成一个定义清晰、可学习、可验证的问题。
现有手势识别大多依赖摄像头、雷达或局域信号，但在户外强/弱光照、偏僻地域中普遍失效。 我判断 GNSS 卫星信号具备"天然覆盖、无需额外部署、不受近距离遮挡影响、不依赖摄像头"的独特优势， 于是把它定义成一个新的感知问题——核心难点在于原始信号稀疏、微弱、噪声大， 需要先解决"信号如何被机器学习"，再谈精度。
工程的第一步不是训练模型，而是把一个模糊的物理现象，转化成一个定义清晰、可被学习和验证的问题。
设计 G-Map 表示法把多颗卫星信号映射为二维热力图，让稀疏离散的时序信息变成 CNN 可学习的特征；针对样本稀疏，引入 Diffusion 增强 + KDE 分布生成，把准确率提升到 96.43%。
GNSS 原始信号并不是天然适合做手势识别的数据形态。我设计 G-Map 表示法，将多颗卫星的接收信号 映射为二维热力图，把稀疏、离散的时序信息转成 CNN 可学习的特征输入。 针对训练样本稀疏问题，引入 Diffusion-based 增强与 KDE 分布生成策略扩充数据分布， 并通过"数据—验证"循环迭代持续修正特征质量，最终把识别准确率提升到 96.43%。 这套稀疏数据处理思路，对大模型 SFT/RLHF 中的稀疏标注场景也有直接参考价值。
自研 CNN-LSTM + Attention 模型：深度可分卷积降参数、滑动窗口注意力捕捉时序依赖，在有限算力/内存约束下平衡精度与效率，模型压缩到 45.92MB。
我基于深度可分卷积（降低参数量与计算量）与滑动窗口注意力机制（捕捉手势时序依赖） 自研 CNN-LSTM + Attention 模型，在精度与算力/内存约束之间反复调优，最终压缩到 45.92MB。 这段经历让我对模型结构设计、参数量/算力/精度的三角权衡有了扎实的第一手工程经验。
真正的模型工程不是堆参数，而是在算力、内存和精度的三角约束里，找到那个最能落地的结构。
独立开发 Android 手机端 + Pixel Watch 2 手表端双平台 App（Kotlin），集成商用 GNSS 模块 Ublox M9N，把模型部署到端侧，实现 25Hz、5.81ms 的实时推理闭环。
我用 Kotlin 独立开发 Android 手机端与 Pixel Watch 2 手表端双平台 App， 集成商用 GNSS 硬件模块 Ublox M9N，将训练好的模型部署到端侧， 实现 25Hz、单次 5.81ms 的实时推理闭环，让整套系统真正"跑在设备上"，而不止于实验结果。 这段端到端落地经验，覆盖了从算法到 App 到硬件的完整交付链路。
一段实习，三个模块：我以算法岗入职 Mira、第一周转为 PM，主导 Skill 技能生态这条线（治理 / 评测 / 安全）、并参与 Task 任务能力打磨，靠 AI coding 辅助落地并推上线；
后来团队架构调整并入豆包企业版——全员开通、嵌在飞书里，在这个底盘上我们做了面向 TikTok 与海外同事的 豆包企业先锋，一次真正的 0→1；
四个月独立上线 15 个需求；期间独立发起 AI-native 研发提效平台 oh-my-mira。
（下面三个模块按「最近的放最前」排列：Pioneer → Mira → oh-my-mira。）
Mira 之后团队并入豆包企业版——公司给每位员工都开通、直接嵌在飞书里，这是这条主线的规模化底盘。 在此之上我们做了豆包企业先锋，面向 TikTok 部门与海外同事，这一次是真正的从零开始： 没有存量用户、没有既定形态，国内那套工作流搬过去并不成立。 第一个版本的范围取舍我从头跟到尾——把大半能力推后，只留一条最小闭环，让第一版的结果可归因。
「先锋」这个名字本身就是节奏的证据——它比国内版快得多。 快是优势，也意味着没有试错第二遍的余量：一次上线压太多变量，失败就无法归因。 所以第一个版本最关键的产出不是加了什么，而是敢让哪些东西不出现。
Mira 团队架构调整后并入豆包企业版——全员开通、嵌在飞书里。在这个底盘之上，我们为 TikTok 与海外同事做了豆包企业先锋，这次是真正的 0→1。
两段经历性质不同，我不想混成一件事：在 Mira 我是在一个已有相对完整形态的产品里把 Skill 这条线做深—— 约束是不能推翻已有设计、不能影响已经在用的人，改动必须向后兼容；Pioneer 才是真正的从零起—— 没有存量约束，但也没有任何东西替你划定边界。前者考验在约束里做深，后者考验在空白里做减法。
并入企业版让这条主线有了规模化的底盘，Pioneer 让我第一次面对「第一版该长什么样」这个问题。
用户从「字节全体员工」换成「TikTok 与海外同事」。他们的工具链和协作方式与国内不同——我们把「国内已经这么做了」从论据里划掉了，它只能作为线索，不能作为理由。
一个功能在国内成立，靠的往往是国内特有的协作习惯与配套工具；这些前提一换，同一个功能的价值可能直接归零。 照抄最省力，代价是你把一批未经验证的假设当成了地基——后面每一层都建在上面，等发现不对时返工成本已经不可控。
把别人的答案照抄过来最省力，但你就永远不知道这道题的题目其实变了。
一份很长的能力清单，几乎每一项都「看起来该有」。我们把大半推到了后面，第一个版本只留一条最小闭环：能对话、能开一个带上下文的项目空间、能把重复的事挂成任务、能接外部工具。
做减法的理由不是资源不够，而是可归因——这和做实验时控制变量是同一件事。 摊子一铺开，某个环节没人用，你分不清是方向错了还是这一处实现得不好，下一版就只能靠猜。 所以第一版只保留一条能自证价值的路径：用户能进来、能把一件真实的事从头做完。 其余能力不是被否掉，是被排到了「等这条路径被验证之后」。
我博客里那句话就是这段时间攒出来的：平庸的人做加法，有品味的人做减法。真正花掉的功夫不在写多少，而在决定哪些不写。
几类同事装的是同一个包，进来却该走向不同的地方——有人该进这条线，有人手上另一个版本更合适，也有人纯粹是走错了。我们给走错的人做了一个可选择的中间页，而不是让他吃一个错误状态。
这类路径的共同点是：它不该发生，但它一定会发生。在功能清单上它排不进前二十， 但它决定的是一个真实用户的第一印象。我在自己那套 AI Agent 的对照实验里验证过同一件事—— 质量差距几乎全在非主路径上（出生点、失焦释放按键、重开清理计时器）， 因为「主流程能跑」是一个太容易达到的完成标准，执行者到这里就会认为自己做完了。
主路径决定产品能不能演示，非主路径决定产品能不能被信任。
Mira 是面向字节全体员工的 AI 工作平台。我进组时它已经有相对完整的产品形态， 所以我做的不是从零起，而是在一个有真实用户的产品里把一条线做深——改动必须向后兼容，不能弄坏已经在用的人的东西。 我以算法岗入职、第一周调整为 PM，主要负责 Skill 技能生态（生态治理、模型适配评测、安全检测三件事），并参与 Task 任务能力打磨。 工作方式是「PM 主导产品与方案设计 + 前端为主、打通后端自交付」，前后端改动靠 AI coding（Claude）辅助编码、推 PPE 验证上线； 跨团队的部分（安全业务方、运营侧研发）由我对接推进。后来团队架构调整并入豆包企业版，同一条主线继续。
在一个已经有真实用户的产品里做深，约束比从零起更硬： 改动要向后兼容、不能弄坏在用的功能，同时还得把 Skill 这条线做到能规模化。 我在其中主导的，正是决定生态能否规模化的三件事——治理、评测与安全底座；跨团队的部分（安全业务方、运营侧研发）由我对接推进。 后来团队并入豆包企业版，同一条工程主线继续。
鼠标移动到视频区域时自动循环播放，移出后暂停。
目标是让用户找得到、信得过、管得动，同时让默认预装生态保持精简。 思路不是零散加功能，而是把「发现 — 判断 — 安装 — 管理」当成一条完整任务链路，缺哪环补哪环。 我的角色是 PM 主导交互设计 + 前端为主、打通后端全栈自交付（AI coding 辅助编码、推 PPE 验证上线）。
技术上有一处收敛我比较满意：排序功能最初方案是新增 2 个接口， 我把它收敛为复用 skill list 接口扩展 need_personal_usage 参数 + 用户维度用量表—— 在一个已经有真实用户的产品里，最小改动本身就是工程判断。 治理那一半靠数据：基于 TEA 埋点做全量频次分析，识别「高频使用」与「凭直觉预装」的偏差， 产出《默认预装 Skill 精简方案》并推动下线低频预装项。
好的方案设计不是加接口，而是在满足需求的前提下，找到最小改动、最可维护的那条路径。
从 0 规划「合规准入 + 多模型评测」两期架构。 一期（已上线）是合规准入 + 运营提效：47 项规范检查 + LLM 合规检测的静态检测器， 并把放行标准从「全项评分」优化为「关键项阻断 + 其余项提示」——不是所有问题都值得拦人，这一改动显著降低了运营审核成本。
二期（方案就绪，未开发）是多模型横评 → Top 3 推荐，核心架构是「选手 / 裁判分离 + 核验层」： 执行端产出客观 trace、固定裁判模型统一打分、有副作用的操作强制留 verify_token 回查， 解决模型自评偏差与「自报成功、实际未执行」的虚高成功率。 并按 Skill 的产出类型做差异化设计（功能型做兜底、效果型做 Top 3 推荐）——算力有限，不可能所有 Skill 跑满全模型， 取舍本身是方案的一部分。我产出了全场景可交互原型，并推动运营 / 算法 / 研发多方对齐。
这一期最终没有开发，赶上业务方向调整暂缓了。我照实写在这里： 方案对齐完成、原型交付、结论可复用，但它没有上线数据，我不想把它说成已经跑起来的东西。
让模型自己判断自己做得好不好，等于让考生自己判卷。把「执行」和「打分」拆开，是这套体系唯一真正重要的决定。
上架的 Skill 有审核，个人自建的没有——这是开放生态里最容易被忽略的一块。 我主导需求与方案，对接安全业务方与运营侧研发：接安全方的接口设计检测链路， 把风险在用户使用之前透明呈现，并且没有停在「检测出来」—— 高风险技能做风险标识管控、禁用分享等扩散动作，检测结果直接展示在详情页。
同时以安全视角提出回调鉴权加固方案（HMAC / mTLS 验签 + 防重放 + task_id 校验）， 以及「上传即时触发 + 定时全量兜底」的双扫描链路。
一个开放生态真正的风险不在被审核过的那部分，而在没人管的那部分。
这条线不是我主导的，我参与其中若干能力的设计与交付：自定义 Bot 通知（选择器 + 去重 + 灰度）、RUNNING 状态置顶、编辑态 status 误关 bug 修复； 基于竞品调研以「零配置 + 立即见效」为标准筛选并上线 6 个引流模板。 同时提出「1 份共享底座 + 4 份角色差异层」多 Agent 协作框架，将球权交接、证据分级、 停机条件等隐性协作协议显式化，保障多角色间协议一致。
在反馈群 oncall 一线支持用户，搭建每日跨群反馈自动归纳（去重 + 来源标识 + 台账 / 日报 / 周报 / 月报）定时任务；持续输出大厂动态追踪与产品 sense 沉淀，让一线反馈可沉淀、可追溯。
oh-my-mira 是我从一线痛点中发起并主导的独立 0→1 项目：一个面向公司内部研发团队的 AI-native 研发提效平台，目标是让「提需求」直接产出「可合并的代码」。核心是一套 飞书 Bot 入口 + 跨仓库全局上下文 + Claude Agent 编排的工程架构， 让 AI Agent 能跨前后端仓库改代码、自动提 MR，我用它亲手交付了首个真实需求。
我发现的不是「某个需求难改」，而是 「每个跨端需求都难改」——这是会重复无数次的结构性成本。 让研发帮忙只解决一次，做成工具解决的是一类，还能复制给同样「想改却碰不动代码」的设计部门。
我是算法背景转产品。进组后接的第一类需求是前端改动，说实话前端代码基本看不懂， 但我用 vibe coding——在终端里用自然语言描述需求、让 AI 去改、我来判断改得对不对—— 居然基本覆盖了这些需求。可不到一周就撞了墙：很多需求光改前端不够，必须动后端， 而后端仓库又多又割裂，AI 一次只能看一个孤立仓库根本帮不上忙。
这不是我个人不熟业务的问题，而是结构性问题：工具的视野，被仓库边界切碎了。
我把痛点抽象成产品方案，主动找 leader 提案：做一个能同时连接所有代码仓库的 AI Agent， 让它跨前后端改动；入口做成飞书机器人，我不用在一堆终端和仓库间切换，直接在飞书上「派活」； 底层继续用 Claude 保证代码质量。目标状态——我一句话描述需求，它前后端一起改、自动提 MR， 我只在关键节点做决策。
方案落地为「调度层 + 全局代码上下文 + 协作层」三层架构。我主导判断的核心点正是我最初的痛点—— 让 AI 拥有跨仓库的全局视野，解法是把所有产品代码统一挂进 Agent 的工作空间， 我把它概括为「workspace 即上下文」。同时为安全设硬约束： 高风险变更必须人工审核才能合入。
现成工具是「单仓库、补全级」，我需要的是「全局、交付级」。它不是更快的打字机，是会自己提 MR 的初级工程师。
「飞书提需求 → AI 跨仓库改代码 → 自动提 MR」全链路跑通，我亲自用它完成了第一个真实业务需求的 全链路验证，达成 0→1 里程碑。一个看不懂前端、不熟后端的算法背景 PM，现在能直接在飞书上把前后端需求 都跑出来，还推广到了设计部门——他们和我当初一样有明确诉求却碰不了代码，也能一句话上线自己的需求。 再后来 leader 在这套东西之上做了更进一步的产品，给机器人配上了类似「员工」的身份和权限。
我不盲信 AI 生成的代码，而是用三层判断兜住质量：结果验证（改完看实际效果、有没有破坏其他功能）、 方案合理性判断（Agent 的实现思路方向对不对、有没有绕路，这是算法训练出的工程直觉）、 借力研发兜底（拿不准的去请教负责那块的同学）。我也清醒地知道： 流程编排是模型升级的中间态，长期工程价值要锚定在人机协作流程、安全边界与需求规范的沉淀上。
单个 Agent 最大的问题不是不够强，而是它既是执行者又是验收者，不会承认自己不行。 所以我把它拆成五个角色——boss / pm / coding / qa / review，各给独立 instructions， 并做了一次四组对照实验来验证分工到底值不值。同一句话（「设计一个类似《我的世界》的游戏， 交付一个可直接运行体验的 Web 版本」）发给四种配置，用提前写死的 20 项验收用例打分，避免事后找理由。
实验里我最在意的不是结果，是变量拆对了：我特意加了「单 Agent + 最强模型」这一组， 因为不加这组，「分工有用」随时能被一句「不就是模型更强吗」推翻——这一组是用来否证我自己的假设的。 结果两笔账分得很清楚：单 Agent 配中等模型通过 12 项（4 个严重缺陷），换最强模型到 16 项（2 个）后就停住了； 五角色团队 18 项（1 个）；按职责给不同角色路由不同模型的团队 19 项、0 个严重缺陷。 12→16 是模型的功劳，16→19 是分工的功劳，模型能补一部分，补不完。
差距几乎全在非主路径：出生点是否安全、放置方块会不会占住自己身体、窗口失焦后按键不释放、 重开一局旧的计时器和监听器没清理。它们的共同点是——「项目能跑起来」的时候一个都看不见。 单 Agent 交付时项目确实能跑，所以它认为自己做完了；它不是不会修，是没有立场发现， 因为它的盲区和它的能力同源。同理我让 review 与 coding 用不同家族的模型： 同一个模型既写又审，审不出自己的思维习惯——数据上就是同构团队还剩 1 个严重缺陷，异构团队是 0。
代价我也一起讲：团队最慢最贵，同构团队三倍多 Token、无效调用占到 19%，因为几个角色在重复分析同样的东西。 所以我不会所有任务都开团队——快速验证想法用单 Agent，十几分钟就有东西看；要交能演示的东西才值得开团队。 而且真要开，优化模型路由比多加角色划算：同样五个角色，只改路由就省了两成 Token、还多过一项。 另外 19 与 18 只差一项，样本量不足以说统计显著，这点我在报告里专门标注了不要过度解读。 这套东西已经跑通并真交付过东西；这个思路后来也被当成一个方向，在 Pioneer 那边讨论过。
我一开始以为我在优化提示词，后来发现我在设计一套分工。
我持续深度使用并拆解 ChatGPT、Claude、Gemini、Kimi、豆包、DeepSeek 等主流 AI 产品， 也在自己的项目里踩过坑。这些是我关于 AI 系统工程的一些第一手判断。
很多 Agent 产品失败，并不是模型能力不够，而是任务边界不清、中间过程不可见、失败不可回退、用户对系统状态没有信任感。 真正成熟的 Agent 产品，关键在于重新设计人机协作界面：哪些步骤应该自动化，哪些步骤必须可确认，哪些状态必须显式反馈。 我更关注“交付可靠感”的设计，而不仅仅是“功能看起来很强”。
在 Gestar 项目中，我遇到的最大工程困难，是如何在 GNSS 信号的极致"微弱"与"复杂"中，提取出足以支撑高精度识别的"稳定且有判别力"的手势特征。信号微弱、稀疏、噪声大，缺乏先例，且难以将"物理现象"转化为"机器学习特征"。我通过分布式感知与 G-Map 编码、精细的特征工程、数据与验证的循环迭代逐一克服。 这段经历让我更深刻地理解：AI 系统里最关键的工程决策，常常不是"选哪个模型"，而是如何在技术可行性、数据质量、成本约束与交付速度之间做平衡，在所有人都认为"不能做"的地方找到"可以做成"的路径。懂训练数据与评估逻辑、理解模型与算力边界、敢于在不确定性中做工程取舍——这是我认为一个 AI 工程师最有价值的能力。
很多人把端侧 AI 理解为云端能力的缩水版，但从工程角度看，它是另一套约束体系：算力、内存、功耗、延迟同时收紧，任何一项都不能牺牲太多。Gestar 的端侧部署经历让我直接面对这道题——用深度可分卷积和滑动窗口注意力把模型压到 45.92MB，同时保住 96.43% 的准确率和 5.81ms 的推理延迟。 这让我相信，端侧 AI 真正的门槛在于模型压缩、量化与部署的联合优化能力，以及对硬件约束的直觉。不依赖摄像头的技术路径也让它在隐私敏感场景里具备独特价值。这些正是我持续想深耕的工程方向。
以算法与模型为核心，用 Python 打通数据、训练、压缩到端侧部署；工程落地则靠 AI coding 把能力延伸到前后端。
好的工程师，往往不只是「会写代码」。真正能把系统做扎实的人，通常都有不止一种看世界的方式。
这些经历看似与技术开发无关，但它们共同塑造了我的工程判断：如何在高压下做技术取舍，如何理解团队协同与分工，如何感知细节与体验，如何站在使用者的角度重新理解一个系统该怎么设计。
作为院女篮队长，率队夺得“华工杯”冠军，也参与高强度正式赛事。
校队与院队首发，参与长期体系化训练与比赛，理解“局部动作”如何服务整体战术。
足迹遍布7个国家，我喜欢把自己放进陌生环境里，观察细节与差异。
兼职拍摄百余套造型，从镜头、构图、风格与表达中理解“被感知”的重要性。
独立负责学术会议全流程策划，从议程、物料到现场体验，把复杂事情做到有秩序。
从通信工程到电子信息硕士，系统训练了我拆解问题、建立假设、验证结论的能力。
我习惯长期观察 AI 工具与技术演进、记录使用感受与差异，把“使用体验”转化为“技术判断”。
无论是比赛、项目还是活动，我都习惯在关键时刻承担“连接者”和“推进者”的角色。
我想呈现的不是“会一堆语言的全栈工程师”，而是一个算法底子扎实、又能靠 AI 工具把想法真正交付上线的 AI-native builder。
目前正在寻找 AI 算法 / 模型工程 / AI 应用方向的校招机会。 如果你正在寻找一个算法底子扎实、又能靠 AI 工具把想法快速交付上线的人，欢迎联系我。