快手转正答辩文档

25分钟阅读

27届实习生转正答辩

1、个人概述

大家好，我是李承雨，预计 2027 年毕业于福建师范大学软件工程专业。自 5 月 20 日入职商业化技术部电商营销前端组以来，我的目标岗位是 AI Agent 全栈开发工程师。

实习期间，我主要负责磁力金牛与磁力小牛平台的前端及全栈需求、Node 服务调度和 AI 能力建设，累计参与 10+ 项业务与技术需求。其中，我作为核心研发参与了 Node 定时任务调度服务、AI 触点与运营看板建设，并从 0 到 1 主导、闭环了两个核心项目：磁力小牛 Agent 客服架构重构和规格驱动的 D2S（设计即交付）工作流建设。

这段实习中，我的成长主线是从“完成需求”转向“闭环解决问题”：不仅关注功能实现，也开始从业务目标、架构设计、跨团队推进、上线验证和长期复用等维度思考工作价值。

2、工作成果

核心成果概述

项目名称项目角色项目时间我的关键成果
定时任务调度 Node 服务
📄 金牛定时任务服务使用手册		主R：贺金圣
主S：李承雨		6月-7月
  • DX优化：将 LLM 解析用户画像等定时任务从星云平台迁至 Node 服务当中，大幅提升开发效率与排障体验。
磁力金牛 AI 触点+运营看板
📘 商业化产品需求：小牛-平台触点+AI素材一键修复		核心开发
主R：李承雨；高樊
主S：贺金圣		5月-7月
  • 业务上：围绕平台关键名词落地 10+ 个 AI 触点，打通“曝光－点击－唤起小牛－问题发送－回答反馈”全转化链路，支持触点动态调节与效果复盘
  • 技术上
  • 看板建设：搭建触点配置与数据看板，统一埋点上报规范与数据归集
  • 稳定性上：保障高并发唤起场景下系统稳定运行，建立异常降级与兜底机制。
磁力小牛 Agent 客服重构
📘 商业化产品需求：磁力金牛AI底层能力建设 第三期		主R：李承雨；高樊；罗晓红
主S：吕明睿；要宵萤；姜春宇		7月-9月
  • 业务上：通过新的小牛架构支撑了 3 个高优需求迭代上线，为电商侧提供组件，单个需求提效约 20%+
  • 技术上
  • 架构合理：通过合理架构设计和分工，向内支撑 D2S 基础设施建设及小牛日常迭代，向外提供完整业务卡片包
  • 协议重建：重构宿主与小牛通信协议，收流 Context/Command/Request/Event 4 类通道，消除无约束透传
  • 沉淀：沉淀 20+ 小牛原子组件、15+ 分子组件、65+ 业务卡片
  • DX优化：开发热更新反馈从 2~3 分钟缩短至秒级（< 1s）
  • UX优化：包体积由 24.5MB 降至约 11MB（-55%），LCP 由 7.1s 优化至 5.8s（-18%）
  • 稳定性上：面对重大架构重构，采用新旧链路物理隔离、宿主白名单灰度切换切流方式，核心功能逐步平滑迁移，至今 0 线上问题和反馈。
D2S（设计即交付）工作流
📄 磁力小牛 D2S：设计即交付		独立 Owner（主 R）：李承雨
协作方：王聪；张晓钰		7月-9月
  • 业务上：需求 P50 周期缩短 20%，人力投入减少 30% PD；单次 ESP-SDD 实践耗时约 25min，代码采纳率高达 95%
  • 技术上
  • 模式创新：自研 OpenSpec/SDD 规格驱动 AI 设计交付工作流，以可运行 React 组件替代静态 Figma 稿
  • 设计交付：设计侧直接交付 68% 原子组件与 40% 分子组件，消除二次翻译
  • 质量追溯：走查前移至本地 Docs 与线上代理预览，视觉决策结构化可追溯
  • 稳定性上：通过多 Gate 人工确认与自动化验证机制，保障生成代码高合规性与零破坏性变更。

核心项目一：磁力小牛 Agent 客服架构重构

1. 背景

  • 业务背景：磁力小牛作为磁力金牛面向广告主的 AI 智能助手，承载问答、主动触达、诊断、数据解读和营销等多元能力。
  • 技术痛点：旧版框架（ad-im-esp 1.0）经历 60 余次迭代后暴露出严重的系统性架构债务：
    • 首屏资源爆表：所有卡片全量打包进主 Bundle，首屏体积超过 25MB+ 且持续劣化，流水线多次因产物过大构建失败；引入第三方新组件只能走微前端，开发成本极高。
    • 开发体验极其脆弱：缺乏热重载（HMR），每次改动需要完整构建 2～3 分钟，构建过程脆弱易崩，频繁被打断开发节奏。
    • 宿主通信协议不透明：CanalRuntimeContext 上下文无约束直接透传，混杂数据、getter、宿主对象和反向注册，沟通成本极高。
    • 新功能扩展上限受限：历史会话、图片输入等能力缺乏独立的 Store 与状态管理，在旧架构上无法干净扩展。
  • 项目目标：从 0 到 1 建设一个跨端（PC/Mobile）、可扩展、可复用的 Agent 运行与交付底座，实现运行时与业务卡片解耦。

2. 难点

我作为项目独立 Owner（主 R），负责从 0 到 1 的架构设计、全栈协议定义、核心模块实现、跨团队（产品/设计/后端/PC/Mobile 研发）协作以及平滑迁移与效果复盘。核心难点包括：

序号难点难点阐述
1架构分包与单向依赖解耦单体客服代码中 IM 核心、会话状态、卡片 UI 与 PC/Mobile 宿主深度交织，如何划清职责边界并保证单向依赖？
2通信协议与状态管理标准化宿主与小牛间无约束透传，如何设计统一、类型安全的通信协议？多会话隔离与流式响应如何进行状态解耦？
3开发效能（DX）与资源性能（UX）治理首屏 25MB+ 产物与 2~3min 构建等待严重影响 DX/UX，如何在不改动生产发布流程的前提下实现本地 HMR 与按需加载？
4大规模重构的平滑切流与风险闭环在高频迭代业务中全量重构核心客服系统，如何控制切流与回归风险，保障 0 线上事故？

图片

3. 我的解法

针对难点一：搭建 7 层单向依赖架构与分包解耦
  • 将单体仓库拆分为 7 个高内聚 npm 包：
    • @ad/esp-robot-core：IM SDK 集成、标准化 IM 模型；
    • @ad/esp-robot-runtime：实例生命周期、宿主上下文、会话、请求与流式客户端；
    • @ad/esp-robot-ui：L1/L2/L3 UI 组件库与设计 Token；
    • @ad/esp-robot-chat-content：消息解码与注册、会话渲染、输入区与欢迎页；
    • @ad/esp-robot-platform：PC/Mobile 宿主装配；
    • @ad/esp-robot-devtools：调试工具链、Chrome 扩展；
    • @ad/esp-robot-ecom-card-adapter：电商场景卡片适配层与独立 CDN 产物。
  • 制定严格的单向依赖规则：platform → runtime/chat-content/robot-ui → runtime → im-core → IM SDK，禁止反向引用。
  • 改动定位收敛：业务卡片改动限定在 robot-ui / chat-content，输入框与消息列表看 chat-content，容器宿主看 platform，连接与底层通信才进入 im-core。
针对难点二：标准化 Bridge 协议与 SessionStore 状态治理
  • Bridge 4 类通道重构：将混杂的 CanalRuntimeContext 拆解为四条明确通道：
    • Context：宿主拥有、Robot 消费的状态快照（账号、路由、功能开关）；
    • Command：宿主驱动 Robot 动作（open/close/sendMessage/showBubble）；
    • Request：Robot 请求宿主响应（navigate/feedback/updateAiCreate）；
    • Event：Robot 告知宿主已发生事实（containerClosed/entryClicked/runtimeError）。
  • 状态层解耦：拆分 GlobalStore（配置与容器形态）、ChatStore / SessionStore（历史会话列表与当前会话切换）、RuntimeStore，通过 EventBus 解耦通信。历史消息统一归一化为 NormalizedMessage 复用现有渲染管道。
针对难点三：双构建链路 HMR 提效与卡片按需治理
  • 开发效能（DX）：引入 Vite Dev Server 构建 pnpm dev 本地开发链路，支持 React Fast Refresh / HMR，代码改动到浏览器反馈从 2~3 分钟缩短至 < 1s；生产构建保持 pnpm build 不变，并支持环境变量一键回退。
  • 资源性能（UX）：
    • 卡片按需加载：创建 CardRegistry 卡片注册表配合 React.lazy 异步加载卡片；
    • 图标 CDN 化：60+ SVG/PNG 图标迁移至 CDN，不再打包进 JS Bundle；
    • 图表按需引入：大型图表库（mchart）仅在含图表卡片中动态加载，首屏包体积由 24.5MB 降至 11MB（-55%），LCP 由 7.1s 优化至 5.8s（-18%）。
针对难点四：新旧隔离与白名单灰度切流
  • 建立物理隔离的新项目承接重构，在宿主侧通过 Kswitch 白名单进行新旧子应用灰度切流，做到物理隔离、秒级回滚。
  • 按照“核心聊天流程 → 流式输出 → 各类卡片 → 主动触达 → 宿主联动”按优先级平滑迁移，每个模块独立自测回归。

4. 结果

  • 业务价值：支撑 3 个高优需求快速迭代上线，对外输出标准化卡片包，单个需求研发提效约 20%+。
  • 技术沉淀：建立 L1-L3 Robot UI 组件体系（20+ 原子组件、15+ 分子组件、65+ 业务卡片），定义 Bridge 规范与全埋点分级注入方案。
  • 效能与体验：本地热重载响应 < 1s，首屏包体积下降 55%（11MB），LCP 缩短 18%（5.8s）。
  • 稳定性：通过白名单灰度切流与高覆盖率单测/众测，重构全程 0 线上故障/0 线上反馈。

核心项目二：D2S（Design to Ship，设计即交付）工作流

1. 背景

  • 业务背景：磁力小牛需要持续交付主动推送、会话、诊断、成长任务等大量业务卡片。
  • 传统痛点：传统模式下设计师交付静态 Figma 稿，研发凭截图翻译成 React 代码。存在三大痛点：
    • 设计与研发概念断层：设计师按区域/页面划分组件，研发按状态管理/数据逻辑划分组件，概念不一致导致理解偏差。
    • 重复人力消耗与频繁返工：样式还原占用大量研发工时，且提测后的视觉走查通常需要 2~3 轮打回修改。
    • 硬编码与缺乏规范：研发为赶进度未使用 Token 和标准原子组件，散落临时硬编码变量，后续可维护性极差。
  • 项目目标：重新定义设计交付物——设计交付的不是生产组件，而是受设计系统约束、可在浏览器运行和验收的代码原型（可运行的 Figma）。自研规格驱动（OpenSpec/SDD）的 D2S 交付流程，把视觉走查前移至设计自验阶段，研发聚焦工程化拆分与业务逻辑接入。 图片

2. 难点

作为 D2S 工作流独立 Owner（主 R），负责流程定义、Agent 编排（OpenSpec）、Design Lab 工具链搭建、组件约束与跨团队（设计/研发/产品）推进。核心难点包括：

序号难点难点阐述
1认知与边界纠偏早期期望设计直接产出可合并的生产 L3 组件，但设计与研发对“组件”理解不同，如何合理重新划定交付边界？
2规格驱动与三维 AI 上下文约束仅依靠截图或自然语言，AI 容易盲猜样式与组件，如何将组件库、Token、图标和状态转换为结构化规格约束？
3工程化翻译与隔离开发环境（Design Lab）设计修改生产代码易引入接口/环境报错，如何建设隔离的预览自验环境（Design Lab）并支撑研发高效工程化接入？

3. 我的解法

针对难点一：重新定义交付边界——“设计交付代码原型，研发负责生产化”
  • 纠偏交付目标：明确 设计对最终可见结果与状态负责，研发对生产组件拆分与逻辑接入负责。设计师使用自然语言/Agent 产出可以在浏览器运行的场景代码原型（Scenario.tsx），替代静态 Figma。
  • 任务分流机制（Triage）：
    • patch：改颜色/间距/局部样式，小范围变更；
    • prototype：新卡片/新模块/新页面，进入 Design Lab 独立场景画布；
    • translate：根据截图/Figma 还原受约束的代码原型。
针对难点二：OpenSpec 规格生成与三维 AI 上下文约束
  • 结构化 OpenSpec 规格产出：
    • brief.md：收敛需求背景与场景范围；
    • spec.md：整合 state.md（正常/空态/加载/异常状态）、design.md（Token/颜色/间距决策）、domain.md（可复用的 L1/L2/图标资产）；
    • impl-plan.md：生成逐任务执行计划。
  • 注入 Prompt 上下文：把 @ad/esp-robot-ui 的原子组件、场景 Token、图标和 Demo 作为 Agent 提示词上下文，限制生成边界，确保 100% 优先复用既有 Token 和原子组件。
针对难点三：建设 Design Lab 隔离实验区与 Gate 校验机制
  • Design Lab 隔离区：在仓库中增加 design-lab/ 目录，设计直接在独立的场景画布（Scenario.tsx + fixtures.ts 模拟数据）中进行样式绘制与自验，不依赖真实接口；配合 DevTools 支持存量组件线上代理调试。
  • 单门控自验与 Handoff 交接：设置唯一正式门控 Gate 3（设计验收），设计师在浏览器查看真实效果，满意后执行 /d2s handoff 归档。研发接手代码原型，进行工程化翻译、拆分与数据逻辑接入。

4. 结果

  • 交付效能：D2S 适用需求 P50 交付周期缩短 20%，整体人力投入减少 30% PD；单次 SDD 实践耗时约 25 分钟，代码采纳率高达 95%。
  • 资产与交付占比：设计侧直接交付 68% 原子组件 与 40% 分子组件，消除 Figma 重新还原的二次翻译摩擦。
  • 协作与质量：视觉走查节点前移至设计本地自验，彻底解决提测后 2~3 轮打回痛点；视觉决策与 Token 取值 100% 结构化追溯。
  • 系统联动：与小牛重构相互支撑，重构提供的 L1-L3 组件库和 Token 成为 D2S 的土壤，D2S 则极大提升了组件资产的复用率。

3、个人贡献及影响力

业务贡献

  • 参与磁力金牛与磁力小牛 10+ 项业务及技术需求，覆盖广告创编、AI 触点、Agent 客服和运营分析等场景。
  • 落地 10+ 个 AI 触点，并打通从曝光、点击、唤起到问答反馈的分析链路，使 AI 入口具备配置、观测和复盘能力。
  • 主 R 磁力小牛 Agent 重构和 D2S 工作流，完成从问题识别、方案设计、跨团队协作到结果度量的闭环。

技术贡献

  • 建设可跨端复用的 Agent Runtime、会话、流式消息与宿主通信能力，为新增 Agent 场景提供统一底座。
  • 建设 L1-L3 Robot UI 组件、Token、图标与 Demo 资产，并通过卡片懒加载和资源治理改善性能。
  • 参与 Node 定时任务服务建设，将 LLM 数据解析等任务接入统一调度体系，补充后端服务实践。

流程与沉淀

  • 建设 D2S 规格驱动交付流程，推动设计、研发和 AI 从“静态稿—人工还原”转向“规格—可运行原型—工程化接入”。
  • 沉淀磁力小牛重构技术方案、D2S 流程规范和组件复用规则，使一次项目经验可以被团队后续需求复用。
  • 逐步建立以业务目标、过程指标和结果指标组织汇报与复盘的工作方式。

4、个人工作不足与反思

1. 技术深度与工程掌控力（从“借助工具”到“掌控全局”）

  • 短板反思：在面对历史重度堆叠的存量系统时，前期对 AI 辅助生成工具存在一定程度的惯性依赖，对部分深层上下游副作用及边缘隐患代码（如老的全局变量透传、流式阻断）审查深度不足。
  • 认知改进：建立了“先梳理架构依赖与边界，再借助 AI 辅助拆解与模块生成，最后严格通过类型断言、Diff 深度审查与单元/链路测试进行拦截验证”的工程闭环范式，确保对自己出的每一行代码 100% 掌控。

2. 业务全局观与北极星视角（从“交付功能”到“追踪业务价值”）

  • 短板反思：早期容易陷入“技术需求按期上线即代表终点”的工程师思维，对功能上线后的北极星业务指标（如触点的实际转化率、广告主提问采纳率、客服人力分流率）追问与持续闭环不够。
  • 认知改进：深刻理解“技术终将服务于业务”。在后续需求中主动使用“背景—目标—行动—结果—复盘（STAR+R）”框架，上线后主动关注埋点看板，用数据证明技术改动的业务增量价值。

3. 大型项目主 R 与跨团队推进力（从“单点执行”到“领航闭环”）

  • 短板反思：主 R 跨团队大型项目（如小牛重构、D2S 工作流）时，前期在多方（产品/设计/后端/测试）的依赖识别、优先级切分与风险对齐上仍有提升空间。
  • 认知改进：总结出“先跑通 MVP 最小可验证链路，再按模块解耦迭代，阶段性透明化风险，上线后建立监控与指标复盘”的复杂项目推进方法论，大幅提升跨团队沟通效率。

5、后续发展规划

短期（6个月内）：深耕 Agent 全栈架构与业务监控

  • 业务沉淀：深入广告创编、客户经营与小牛智能客服业务，建立曝光、点击、唤起、问题发送、回答采纳与客服排障等全链路指标的精准归因体系。
  • 技术进阶：继续深化 Agent Runtime 架构，打通前端流式渲染到后端服务编排，在工具调用（Tool-use）、长短期记忆（Memory）、上下文压缩与流式 SSE 协议上沉淀通用底座。

中期（1年内）：推进 D2S/SDD 工作流平台化与提效

  • 规模化落地：推动 D2S（设计即交付）工作流在商业化技术部更多项目/仓库落地，将设计直接交付率进一步提升。
  • 工程基础设施：完善 Agent 上下文知识库、代码评测集（Benchmarking）与自动化 CI 回归卡口，打造可审查、可复用、可持续迭代的 AI 驱动开发基础设施。

长期（2年内）：从“需求交付者”成长为“技术与业务突破的领航者”

  • 跨团队领航：提升架构设计、团队技术影响力与主 R 领航能力，能够独立承接高复杂度、跨领域的 AI Agent 核心架构项目。
  • 业务赋能：主动从技术和业务交汇点发现痛点，通过技术创新驱动商业化电商营销产品的体验与效率突破。