本页目录
可以科技 KEYi · AI 产品经理实习项目
Cortex-Agent
让桌面伴侣机器人，迈向具身办公生产力 Agent
Loona DeskMate 将 iPhone 与可转动底座结合，通过语音、表情和动作与用户多模态互动。Cortex-Agent 是其中的 Agent 运行时，连接邮件、日历与项目协作工具，支持信息检索、任务规划与主动简报交付。
EXECUTIVE SCORECARD主要工作与成果总览 (Major Initiatives)
以「运行时架构治理」与「主动服务闭环」为双核主驱动，配套办公生态接入与评审工具赋能。
ToolHub 成本与调度确定性治理
核心挑战：122 个工具全量注入导致 1.5万 Token 描述膨胀与模型选择幻觉超时
PM 核心动作：主导「同类能力聚合 + 业务域路由 + 按需动态挂载」分层调度方案
DeskMate Daily Brief · 晨间智能工作简报
核心挑战：现场多轮 ReAct 时延过长、离线预生成算力空转滞后、通用记忆高噪混杂
PM 核心动作：原型实验论证并推行「代码并发预查 + 场景化记忆剪枝」，构建三层质量闭环
5 项核心办公应用落地与标准接入 SOP
业务目标：从 0 到 1 拓展机器人办公能力，确立高危防错红线与 6 步标准接入规范
PM 核心动作：主导 5 项办公工具从协议设计到落地闭环，确立「高危必确认、缺参必反问」交互红线与 SOP
多模态交互评审工作台 (Web Mock 工具)
协作价值：语音、表情、动作与卡片交织，突破静态原型限制，对齐多模态时序节奏
PM 核心动作：自研前端可播放评审工具，支持关键帧暂停批注与理想链路配置导出交付
01 核心攻坚 · 运行时架构
ToolHub 治理：从全量注入到分层按需挂载
问题背景与矛盾从线上日志发现：工具越多，Agent 越容易超时
随着桌面机器人接入的办公应用增多，可用工具迅速膨胀至 122 个。观测线上日志发现：122 个工具的全量描述每轮都被注入 Planner，仅 Schema 描述就占用 15,000+ Token。更严重的是，多平台间同类工具（如 Google 日历 vs Outlook 日历、Notion 检索 vs 本地检索）语义高度重叠，导致模型频繁发生「工具选择幻觉」与重复误调用，最终引发超时、任务失败。
我的职责：主导本次运行时治理的产品方案设计，定义能力聚合粒度与调度协议，协同研发落地 Router 预选机制，并通过 136 条覆盖全量工具的基准用例验证成本与成功率收益。
方案权衡工具按什么粒度聚合？在参数复杂与选择困惑间寻找平衡
按平台独立封装大工具
一个平台对应一个或一组工具，直接保留底层 API 原始结构。
致命缺陷：增删改查（CRUD）混在一起，Schema 极度臃肿复杂、多态嵌套难以规范定义；导致模型选参和必填项判断难度陡增，传参错误与入参校验失败频发。
按业务域合并粗粒度工具
邮件、日历各收归为一个巨型工具，通过内部 action/method 参数做分支调度。
代价：虽然减少了工具名数量，但选工具变成了复杂的内部方法与参数嵌套选择，依然加重模型推理负担。
能力语义抽象 + Router 快筛动态挂载
将跨平台同类能力拆解为原子语义工具（如 calendar.create、calendar.query）；由 Router 在提示词目录中轻量快筛，仅向 Planner 挂载命中的具体 Schema。
收益：每个工具 Schema 纯粹单一、入参零歧义，同时为 Planner 减少 70%+ 无关上下文干扰。
调度架构对比全量平铺注入 vs 分层按需挂载
将工具选择前移至轻量 Router，Planner 摆脱全量负担，实现轻装规划。
展开查看该用例各阶段模型调用与 Token 审计清单
| 阶段 / 模型 | 挂载 Schema 数 (前 → 后) | 输入 Token (前) | 输入 Token (后) | 变化与归因 |
|---|---|---|---|---|
| RouterGemini 3.1 Flash Lite | 0 → 0 | 7,003 | 8,661 | +1,658判断为新任务，并提前选出 search_docs；工具目录放在提示词中，不作为 Schema 注入。 |
| Planner · 第一次Gemini 3.7 Flash | 122 → 7 | 43,088 | 19,670 | -23,418在提前筛选后加载的 7 个工具 Schema 范围内，调用 Notion 文档搜索。 |
| Planner · 第二次Gemini 3.7 Flash | 122 → 7 | 47,888 | 24,470 | -23,418根据返回的 20 条文档信息回复；本轮仍注入 7 个工具 Schema。 |
* 审计说明：Router 增加 1,658 Token 用于承载工具目录的文本快筛；而在随后的两轮 Planner 规划中，分别减少 23,418 与 23,418 Token，任务整体净削减 45,178 Token (-46.1%)。
02 核心攻坚 · 主动智能闭环
DeskMate Daily Brief 晨间智能工作简报
场景定义与痛点在坐下工位的第一分钟，帮用户快速看清今天重点
在多项目并行的日常办公中，大家早晨坐上工位，最繁琐的往往不是着手干活，而是「理清头绪」——昨晚群里没结的讨论、被排满的日程会议、跨团队项目的各色进展，往往要花上 10 来分钟翻找各个应用，才能弄清楚今天到底该先跟进什么。
基于桌面机器人的硬件形态，我们希望给用户一个贴心的小助手体验：当用户早晨坐到工位、随手将手机贴到底座时，设备能极快地整理出「今天最需要关注的几件大事」，让用户在一上工就能看清主线、轻松进入工作状态。
方案权衡与取舍决策技术选型：两个正交问题的原型实验与工程取舍
主动服务的技术方案不能将“何时计算”与“输入什么”混为一谈。我们将其解构为两个独立的工程决策：
DECISION 01 · 计算机制决策一：执行机制权衡（何时与如何计算）
现场 Agentic ReAct（原型验证）
做法：用户上座后，模型自主多轮串行调用日程与待办工具。
核心优势：逻辑灵活，无需预设固定取数管道。
瓶颈 / 代价：串行耗时长达 30~40s 且步骤不稳定，无法满足早间即时扫读需求。
全量定时离线预生成（Cron 批处理）
做法：每日清晨脱离用户状态，通过定时任务批量调模型生成静态简报。
核心优势：现场完全 0 延迟，用户上座后卡片秒开。
瓶颈 / 代价：未上座用户产生大量无效算力；且无法感知早间突发日程取消，内容易失效。
触发即并发取数 + 模型单轮生成
做法：用户上座触发瞬间，代码并发拉取实时日程与工作记忆（0.5s）；模型仅负责单轮提炼（3~4s）。
核心优势：数据 100% 实时且零无效算力；时延由 30s+ 压缩并稳定至 4~5s。
瓶颈 / 代价：需预设明确的字段契约，但换取了极高的执行确定性与秒级响应。
DECISION 02 · 输入范围决策二：输入范围裁决（输入哪些上下文）
全量复用 LiveMem 通用记忆
做法：直接复用系统按天沉淀的 32 类通用记忆（含日常闲聊、生活偏好）全量灌入 Prompt。
核心优势：直接复用既有模块，无需二次过滤。
瓶颈 / 代价：1.5万 Token 成本高昂，且琐碎闲聊严重掩没真正重要的工作卡点与承诺。
场景化白名单剪枝 + 画像人际基准
做法：基于底层按天更新的 LiveMem，在消费端设白名单仅放行工作承诺；保留画像基准阻断闲聊。
核心优势：记忆输入削减 92%（1.5万 → 1,200 Token），核心工作卡点信噪比大幅提升。
瓶颈 / 代价：引入两阶段流水线，增加了前置抽取与过滤的工程复杂度与状态管理成本。
坚持现场按需生成，由工程代码与大模型明确分工——“确定性归代码，提炼性归模型”
LiveMem 场景化白名单剪枝
全量注入 LiveMem 导致上万 Token 膨胀且混杂海量闲聊。虽然 LiveMem 本身按天异步离线更新，但若无过滤直接消费会淹没工作主线。我们改为在消费端引入场景化白名单投影：仅放行核心工作字段（承诺、阻塞、计划），并保留用户画像与人际协作背景作为噪音隔离基准锚点；以增加前置抽取与过滤流水线复杂度为代价，物理阻断生活琐碎，记忆输入从 15,000 降至约 1,200 Token。
上座即并发取数，模型单轮生成
针对现场多轮 ReAct 调工具的长尾时延（30–40s）与离线定时预生成的算力空转/动态失效，我们将取数时机确立为用户上座事件到达瞬间，由工程代码并发（约 0.5s）并行拉取实时日程与 LiveMem 当日工作承诺，组装精简输入快照。大模型免除一切工具调度负担，仅负责单轮归纳、优先级重排与口语化生成（约 3~4s），端到端实测稳定控制在约 4~5s。
具身动作与扫读体验协同
手机吸附到底座瞬间，机器人立即触发转头眨眼与开场问候（约 3~4s），问候与动作和后台数据预查、单轮生成完全并行，大幅弱化体感等待；卡片立现可交互，语音播报无缝切入。语音严格约束 ≤25 字单焦点播报，卡片通过 A2UI 结构化呈现供 5 秒快速扫读。
展开查看完整字段映射表：长期记忆 32 类字段场景化剪枝规则（工作记忆、画像与人际背景白名单 vs 闲聊偏好物理隔离）
他人承诺交付的待办，以及核心联系人协作关系（用于责任判定与主体对齐，识别谁是谁、该找谁催办）
日常人设偏好与语气风格（仅适用于日常闲聊对话，晨报直接阻断）
自身到期行动、主线目标，以及用户岗位与业务边界（作为噪音隔离与责任判定的基准锚点，用于识别哪些事项与本人直接相关）
个人生活习惯偏好与日常碎碎念（晨间聚焦场景的纯粹干扰项）
核心项目推进中的阻断卡点、延期风险、待决决策与关键行动
远期项目流水账与陈年背景说明（对当天行动决策无增量价值）
实际交付体验交付契约与真实 A2UI 渲染
A2UI 交互原型 / 真实运行渲染
Daily Brief 晨间交付态DELIVERY CONTRACT
晨间主动推送，如何决定取舍？
早晨面对 10+ 项备选信息，桌面卡片与语音口播严格按优先级阶梯呈现：
右侧为真实 A2UI 渲染结果 · 可在卡片区域左右滑动切换
评测闭环与归因迭代以质量评测守住内容底线，以用户反馈验证简报价值
晨间简报需要在有限篇幅内提炼今日重点，质量保障依赖真实闭环而非单点碰运气。我们推行「代码门禁 + 异步质检 + 价值验证」轻量分层机制；更完整的大模型评测体系、自动化批跑与版本门禁能力，详见配套建设的 Cortex-Eval 评测平台 ↗。
CORE DEFECT REVIEW · 核心排障案例
01 典型缺陷复盘：从「48h 误删未结承诺」看端到端排查
在自身深度内测使用时捕获该典型缺陷：3 天前记录了自身承诺 “周五前完成表格翻译”（归属于多语言支持项目），但周五早晨生成的简报中该承诺完全消失。第一反应容易主观归咎于“模型遗漏”，但调取同次生成的 InputBundle 评测快照证实，模型根本没有收到该条输入。
根因与修复：上游提取规则简单将 updated_at ≤ 48h 作为时序过滤器，导致 3 天前记录但今日到期的未结承诺被误判为历史噪音丢弃（信息新鲜度 ≠ 任务有效性）。我们重构了筛选逻辑，使今日到期待办穿透时间窗保活，并将该缺陷固化为固定防劣化回归用例。当前回归集中未再重现同类遗漏，多用户场景仍需依赖线上持续观测收集长尾异常。
修改前（仅按 48h 更新时间截断）
遗漏自身核心到期承诺 · 模型无从感知评测平台对齐：用例差异卡点待确认，今日 15:00 参加评审。
其他待办：18:00 前提交实习生日报。
（多语言支持项目中，3 天前记录的“周五前完成表格翻译”因超过 48h 未更新被上游截断切除，导致该项目及到期承诺完全漏报！）
修改后（近期动态 + 今日到期未结待办）
准确召回到期承诺 · 项目归类清晰评测平台对齐：用例差异卡点待确认，今日 15:00 参加评审。
多语言支持：今日到期：您需在周五前完成表格翻译。
其他待办：18:00 前提交实习生日报。
展开查看该 Case 评测质检表：严格对照 Gate 1 代码门禁与 Gate 2（D1—D3）三元裁决核验凭证
| 质检门禁 / 评测维度 | 核验要点（Rubric 规则对照） | 修改前裁决 | 修改后裁决 | 评测判定依凭（Force Quote 原文定位） |
|---|---|---|---|---|
| 端到端 · 用户感知 真实待办完整履约 | 今日到期承诺必须提醒，不得发生严重业务漏项 | FAIL 真实漏事：表格翻译未提醒 | PASS 精准召回：保活到期待办 | "多语言支持：今日到期：您需在周五前完成表格翻译" |
| Gate 2 · D2 时间有效与时序过滤 | 对照输入核查事项时效；过滤历史失效与无关噪音 | PASS Judge盲区：输入缺失误判通过 | PASS 输入补全：核验真实合规 | "输入快照核验无失效事项" |
| Gate 2 · D3 项目归并依据 | 事项依上下文关联归并；散碎待办按保守规则独立展示，不强猜 | PASS 符合规则：散碎待办独立列出 | PASS 符合规则：项目分流清晰 | "其他待办：18:00 前提交实习生日报" |
| Gate 2 · D1 事实保真 (Force Quote) | 主体、时间、条件严格一致；必须提供输入原文定位依据 | PASS 要素保真：时间与事项忠实 | PASS 要素保真：时间与事项忠实 | "评测平台对齐：用例差异卡点待确认，今日 15:00 参加评审" |
| Gate 1 代码门禁（口播硬限） | 语音口播严格 ≤25 字单焦点播报；A2UI JSON Schema 校验合规 | PASS 口播 18 字（符合 ≤25 字硬限） | PASS 口播 20 字（符合 ≤25 字硬限） | "口播提炼：“早！今天重点跟进多语言表格翻译。”" |
归因方法：沿输入、生成与评测三个环节排查，避免甩锅给模型
Evaluation Framework · 质检体系
02 业务质检分工与三层机制
呈现与确定性约束
- 结构与口播硬限：A2UI JSON Schema 校验，语音口播严格 ≤25 字（仅 1 句话），卡片结构化呈现供 5 秒快速扫读。
- 模态一致性：语音使用被选事项同一短文本字段，从数据结构上避免两份文本相互矛盾。
- 单焦点与日程时效：语音关联单一有效事项；按当前时间、时区和取消状态过滤已结束日程。
对照输入核查（LLM Judge 异步抽检）
- D1 事实保真：主体/时间/状态有输入支持，Force Quote 凭证；删除条件或放大确定性即判失真。
- D2 时间有效与降噪：过滤失效与闲聊，但不将大群广播一律视为噪音；未结承诺保留。
- D3 项目归并：只核查归并依据，不测主观重要性；项目未知独立展示，多项目不强猜。
业务效果闭环：验证是否真正减负
- 有用性与归因：端侧收集“有帮助／部分／没帮助”分布与具体原因（漏重点/不相关/打扰）。
- 早期打断率：播报开始后 3 秒内打断比例（区分停止与追问，不盲目将打断视为负反馈）。
- 后续行动率：交付后发起后续执行指令比例；结合案例访谈验证核心减负目标。
展开查看 Gate 2 语义裁决机制与 3 类典型边界判定非黑即白一票否决 · 歧义主动暴露待复核 · 不强猜不捏造
| 判定 | 使用条件 | 后续处理 |
|---|---|---|
| 通过（PASS） | 本次检查未发现明确违规（仅代表本次检查未发现问题，不证明完全正确） | 记录自动检查结果，正常计入交付基线 |
| 不通过（FAIL） | 有明确事实冲突、无依据断言、失效或无关内容、错误项目归并 | 返回问题片段、输入证据和原因，进入问题复盘 |
| 待复核（REVIEW） | 来源冲突或上下文歧义，无法可靠裁决（必须有具体原因，不能只写“模型不确定”） | 说明具体冲突或缺失信息，供 PM／研发抽样查看 |
反思复盘阶段成果与下一步（Outcomes & Next Steps）
实测端到端耗时稳定控制在约 4~5s（并发预查 + 单轮直出）；修复已发现的 48h 误切漏报并纳入回归库（当前回归集中未再重现同类遗漏）；严格守住语音口播 ≤25 字单焦点物理防线，卡片通过 A2UI 结构化呈现保障 5 秒即时扫读。
目前主要完成自身深度内测与内部种子用户的日常 Dogfooding。面对不同职能岗位（如咨询、商务、运营）的多样化工作节奏，主动推送是否能在多用户场景下稳定实现心理减负（Mental Offload），仍需长周期验证。
推进长期线上持续观测（结合打断率、停留时长等行为指标），持续收集真实场景中的长尾 Bad Case，闭环驱动上游数据供给与时序剪枝规则迭代。
03 办公能力接入 · 生态落地
办公能力接入：5 项核心办公应用落地与标准接入 SOP
给桌面机器人接入真实办公能力，最大的挑战不是打通接口，而是让用户真正放心把工作交给它。发错一封邮件、订错一场会议都会瞬间摧毁信任。我负责 5 项核心办公能力的需求定义与交互设计，制定「高危必确认、缺参必反问、异常说人话」的产品红线，并将经验沉淀为覆盖需求到验收的 6 步标准接入 SOP。
负责 5 项核心办公应用能力接入与落地
负责 Gmail、Outlook 邮件/日历、Microsoft Todo、ClickUp 等 5 项高频办公能力的需求定义、接口映射与上线验收，推动机器人从陪伴对话真正迈向办公办事场景。
- Gmail邮件
- Outlook Mail邮件
- Todo待办
- Calendar日历
- ClickUp项目协作
产品交互规范给 AI 办事立规矩 · 3 条核心设计原则
连通接口容易，但让用户放心把工作交给 AI 很难。发错一封邮件或订错一场会议都会摧毁信任。我主导确立了 3 条人机协作原则，在「操作丝滑」与「安全可控」之间守住边界。
坚持体验与安全分级：查邮件、看日程等只读操作静默完成，保障交互流畅度；发邮件、删日程等具备外部影响的操作，确认由执行引擎强制拦截，模型不能绕过，绝不依赖大模型概率性的自主判断。
用户口语表达往往简短模糊。确立产品防错红线：收件人、会议时间等核心参数必须在上下文中有据可查；只要关键信息缺失，必须主动反问对齐，严禁模型凭空脑补发错人或订错时间。
遇到账号未授权、权限过期或时段冲突时，严禁模型掩盖错误虚假汇报“已搞定”；必须把真实阻断原因翻译成清晰的人话，并直接给出可操作的下一步指引（如一键前往授权绑定）。
Outlook 日程「跨时区创建」：从口语指令到确定性闭环
真实场景下用户的一句口语指令，背后隐藏着时区错位、日程撞车与误触外部通知三重风险。看 PM 如何通过交互规则化险为夷。
看似简短，但若涉及向外部参会人发送会议邀请，一旦时间订错不仅造成打扰，还会产生额外的沟通与重新对齐成本。
- 时区相差 13 小时（以美东冬令时 EST 为例）：若对接美东团队 (UTC-5)，北京时间下午 14:00 对应的美东时间为同日凌晨 01:00，对方正值深夜；若 AI 默认按本地建会，会议完全错位。
- 隐式日程撞车：目标时段用户很可能已有既定安排，盲目创建会造成日程冲突与重叠。
- 触达外部参与者风险：创建日程伴随正式日历邀请，错误操作会产生额外沟通成本。
未指明参会人所在具体城市或时区时，约束 AI 必须反问确认（如“请问是美东时间还是北京时间”），严禁擅自脑补。
涉及外部邀请，确认由执行引擎强制拦截，模型不能绕过；弹卡醒目双轨对照「北京 14:00 vs 美东 01:00 (同日凌晨)」，把时差直接暴露在用户眼前。
检测到已有既定安排时，卡片标红提示“与已有日程冲突”，交由用户决定是改期还是坚持创建，绝不静默覆盖。
针对跨时区换算、夏令时边界、时段冲突与模糊表达，建立 12 组离线测试用例：
不再把问题当成单点补丁，而是将排障经验固化为全团队的通用设计红线：
- 固化安全红线：涉及外发邀请等产生外部影响的操作，确认由执行引擎强制拦截，模型不能绕过。
- 固化交互规范：涉及时区、敏感人选等关键参数，信息不足必须触发反问对齐。
沉淀 6 步标准化能力接入 SOP
从散装对接走向标准化交付：将经验固化为覆盖「功能定义 → 安全红线 → 交互策略 → 界面呈现 → 文案规范 → 体验验收」的 6 步产品流程，让后续新能力接入有据可依。
能力定义与权限分级
梳理工具在桌面场景下的使用频度，严格界定「只读操作」与「高危写操作」权限，形成首期支持的功能边界与数据字典。
安全确认与拦截机制
凡涉及发送、修改、删除等不可撤回的操作，定义专属交互确认卡与二次核对机制，杜绝 AI 自主决策越权执行。
意图理解与追问策略
设计用户在口语模糊、参数缺失时的对话引导策略；制定反问对齐规则，严禁模型在信息不足时擅自猜测。
界面卡片与状态设计
设计「执行中、待确认、成功完成、异常失败」四类界面卡片展示规范，确保信息布局简洁、关键结果一目了然。
多语言与交互文案规范
统一系统与用户的对话语气，全面抽离中英双语提示语，确保错误提示与确认话术克制、礼貌且不产生歧义。
场景验收与用例回归
穷举覆盖正常办理、缺参追问、账号未绑定、用户中途取消等极端分支，将实测缺陷沉淀为团队标准测试集。
04 基础设施 · 交付提效
多模态交互评审工作台 (Web Mock 工具)
基于 Web 的前端交互评审工具（Mock 多模态时序，非端侧固件代码）。针对具身 Agent 涉及语音、表情、动作与卡片在传统静态原型中无法评审时序节奏的痛点，0→1 搭建可播放的动态交互评审工作台，支持关键帧暂停批注与理想链路配置导出交付。
Agent 多模态交互评审工作台 (Web Mock)
传统静态原型无法评审语音、表情、动作、等待时延与 A2UI 卡片交织的时序节奏。我主导需求定义、交互设计并完成前端实现，构建首个支持动态播放与关键帧批注的评审工作台。
多模态时序动态播放
按预设 Case 动态模拟用户输入、处理等待时延、语音口播节奏与卡片弹出时序，核对先后等待关系。
可播放的动态时序链路关键帧暂停与批注
在任一关键时序节点暂停或快进，将文案表述、卡片字段或节奏体验问题直接标记在对应时间帧。
帧级批注与整链评审意见理想链路一键导出
完成文案与时序调优后，一键导出规范的理想链路 JSON 配置文件，无缝交付研发作为联调依据。
理想链路 JSON 标准配置05 项目复盘 · 认知沉淀
项目复盘：三条 AI PM 核心思考
在桌面机器人落地真实办公能力的实践中，沉淀关于工具治理、主动交互与质量闭环的三项产品思考。
这段经历沉淀的三条 AI PM 核心思考
确定性归系统，提炼性归模型：划清 Agent 的安全边界
Agent 的自主权必须与任务风险严格挂钩。大模型擅长的是语义理解与信息提炼，而权限拦截、参数校验与执行确认必须交给确定性的规则与代码。AI PM 的核心职责是划清人、模型与工程的分工红线，在成功率、响应时延与推理成本之间做出可量化的取舍。
主动智能的最高优先级，是保护用户的稀缺注意力
真正高级的主动服务，不是看模型能多频繁地蹦出来，而是能否真正减少用户的认知负荷。信息保真只是及格线，时序过滤、场景剪枝与极简呈现，共同决定了推送是“贴心助手”还是“噪音打扰”。将用户注意力视为最宝贵的稀缺资源，始终为用户保留拒绝与打断的掌控权。
离线评测保底线，真实使用验证价值：建立持续迭代的质量闭环
一次单点回答正确不代表系统稳定，通过了离线测试也不代表用户真正受益。质量验证需要沿输入、调度到输出端到端归因，用回归集筑牢防劣化防线；价值验证则需要结合行为遥测指标与真实反馈，让暴露的用户痛点精准转化为修复动作并沉淀为发版门禁。