如何整理一次实习问题，让它以后能写进简历和面试

日报记录了过程，但面试需要一条主线

实习日报很容易写成修改文件清单：调了几个样式、加了一个监听、跑了构建、修了一个真机问题。这样的记录对当天交接有用，过几周再看却很难回答三个问题：为什么这样改、如何证明判断成立、这件事体现了什么能力。

整理近期移动端 WebView 问题后，我逐渐形成了一个更适合长期沉淀的结构：

问题现象
  -> 关键约束
    -> 证据链
      -> 方案取舍
        -> 验证结果与未完成项

它不是为了把普通工作包装得更复杂，而是把真正发生过的判断保留下来。

第一步：把“改了什么”改写成“解决了什么”

例如“修改 MainFooterTabs.vue”只是文件事实，不能说明工作价值。更完整的描述应该是：统一接入系统回顶意图，并根据不同页面的真实滚动模型选择策略，同时过滤 Ionic 缓存页面中的隐藏容器。

文件名可以作为证据，但不应该成为主语。主语应该是用户遇到的问题和系统受到的约束。

同样，“调整模块高度”也过于模糊。真正的问题是虚拟列表的占位高度小于组件真实高度，导致下一模块提前定位。修复需要同时调整组件文档流和虚拟列表高度配置，而不是简单增加一个 CSS 数值。

第二步：保留能排除错误方向的证据

排查异步生成视频时，页面最终展示错图，并不代表前端选图一定有问题。有效证据应该沿着同一个任务建立关联：

用户当前选择
  -> 创建任务 payload
    -> taskId
      -> 任务状态
        -> 最终资源
          -> 页面展示

在移动端 WebView 中，Chrome DevTools 不一定能完整显示 Capacitor 原生 HTTP 请求，因此我补用 Android Studio Logcat 查看真实的 CapacitorHttp.request。确认请求中的图片 URL 指向用户选择的非首图后，才有依据把排查边界继续向异步队列和视频生成服务移动。

这类“排除了什么”很值得写进复盘。它说明我没有看到结果异常就直接改前端，而是先保护已经被证明确认正常的链路。

第三步：记录没有采用的方案

工程判断往往体现在没有做什么。

视频 Feed 回顶部时，我尝试过动态时长动画，但 Swiper virtual、视频暂停与播放、首帧加载会同时发生，真机出现短暂卡顿或黑屏。最终视频 Feed 直接跳到第一屏，普通列表仍保留平滑滚动。

聊天历史加载中，分批渲染和滚动锚点补偿改善了体验，但 3000 条消息压测后，根本瓶颈仍然是 Android WebView 中的大量 DOM。动态高度、多媒体消息、流式输出和底部自动滚动让虚拟列表改造具有较高风险，因此没有为了“彻底解决”而仓促重构。

这些取舍比一句“优化体验”更容易在面试中展开，也能证明我理解方案成本。

第四步：把验证分成代码验证和场景验证

构建通过只能证明代码满足构建链路，不代表真机交互正确。我的复盘会把验证拆成两层。

代码层：

lint、类型检查或生产构建是否通过；
多语言 JSON 是否能够解析；
是否残留冲突标记；
git diff --check 是否通过；
修改范围是否只包含预期文件。

场景层：

iOS 和 Android 是否分别验证；
不同 Tab、分类和缓存页面是否覆盖；
长列表、视频流和普通页面是否使用正确容器；
用户中断动画、重复点击和多弹窗并存是否正常；
未完成的 build 或真机测试是否明确标注。

只有两层都写清楚，后续才不会把“代码没报错”误记成“问题已经完整解决”。

第五步：区分修复、阶段性优化和边界确认

近期工作里有三种不同结果：

已修复：例如固定 footer 遮挡滚动内容、虚拟列表模块重叠；
阶段性优化：例如聊天历史加载的锚点保持，体验改善但没有消除大量 DOM 的成本；
边界确认：例如外部 Web 页面未本地化、后端任务未使用请求图片，本次没有修改主应用代码。

把三者混写成“已解决”会夸大结果，也会给后续协作制造错误预期。写清未完成项并不会削弱复盘，反而能体现问题边界意识。

简历和面试分别怎么使用

简历只需要压缩后的结果，例如：

负责 Ionic + Capacitor 移动端交互与性能问题排查，完成跨平台弹窗返回分层、缓存 Tab 回顶、虚拟列表高度修复，并通过真机与构建验证控制影响范围。

面试时再展开其中一条完整链路：问题如何复现、最初假设是什么、怎样收集证据、为什么选择当前方案、验证覆盖了什么、还剩哪些风险。

简历不是日报摘要，面试也不是提交记录朗读。两者都需要从真实过程里提取工程判断。

我现在使用的复盘模板

以后整理一项工作时，我会尽量写全这些字段：

现象与稳定复现步骤；
影响平台、页面和用户操作；
真实滚动容器、状态来源或请求链路；
已验证事实与仍然只是推测的部分；
尝试过但放弃的方案及原因；
最终修改范围；
自动化检查、真机验证和未验证项；
如果继续推进，下一位开发者需要什么证据。

这样整理出来的笔记既能服务团队交接，也能在几个月后帮助我准确复述自己的工作，而不是只记得“当时好像修过一个很麻烦的 Bug”。