实习总结 2026/01/31

1 前言

实习结束了，是时候进行一次全局的回顾了。

感觉下半的实习更多的是软技能，强调抽象的总结能力，这个可能比硬技能更加宝贵，因为这是经验堆出来的。

2 STAR 原则

我觉得我认识到的相对本质的东西就是这个：STAR 原则，帮助我们更好的分析所做的工作是什么，以及可视化一下实际的产出成果

• S — Situation： 情景，也就是背景是什么
• T — Task：任务，把目标量化为一个可验收的指标
• A — Action：行动，本步骤和决策的依据来一次写我做了什么
• R — Result：结果，必须量化 + 给出可复用产出

3 项目简述

其中我主要做的工作有 3 个：example 撰写，QA 测试样例撰写，以及一个完整的测试平台搭建（我认为这是最主要的工作这是最主要的工作）

3.1 Example & QA

example 撰写也就是通常说的写 demo，主要是协议内部已经写好的 api 去执行一个调用的操作，然后通过可以演示如何执行某种功能，我这个主要是为了进行芯片中的一个性能测试。

这一部分使用的语言是 C，而我其实对 C 的掌握并没有那么的扎实，这导致了我写完代码以后，提交 MR 的时候很艰难。因为有不少内存泄露问题，CI 审查结合 AI 复审了好久，前前后后改动很多。

这其中主要的收获应该是：

• 相对更加熟悉 C 这个开发流程，一定要千万小心内存泄露的问题，反复检查申请的内存是否有不释放的可能
• Git 操作更加熟练：这里面我主要就接触了 patch, cherry pick, rebase 等 Git 的操作，来了公司才真正使用到了多方协同开发，平时都是单人开发当做版本控制工具的

另外一个 QA 就是和 Example 对口的一个东西，主要也是用在测试实际的表现性能上的，已有的框架下搭建对应功能的工作

我觉得这两个工作有点无趣，有一说一，要是一直做这个方向是很无聊的。但是似乎也不能指望工作有什么有意思的地方了

3.2 测试平台

这是一个真正意义上我负责的一个项目，实际上的学习的东西可能不如之前多，但是这是一个实打实的完整项目开发经验，这里用 STAR 原则来整理一下

• S（情景）：测试流程依赖 IDF 框架、 Example 仓库与 QA 框架的协同，涉及多仓库分支切换、 submodule 、 IDF 版本、设备与配置文件等大量手工操作，流程冗长且易出错。
• T（任务）：构建一个网页化的自动化平台，打通代码更新、环境准备、构建烧录、测试配置与执行、日志留存的全流程，实现一键配置与快速测试。
• A（行动）：将关键步骤标准化为固定流水线（仓库同步、环境校验、构建、烧录、测试执行与产物收集）；提供表单化参数与可视化状态/日志；自动生成并校验测试配置；为每次运行归档配置快照、日志与结果，支持历史复用与持续迭代优化。
• R（结果）：跨仓库与分支切换从 3–4 分钟的手工操作收敛为一键流程；测试配置自动化显著降低错误率；日志与结果结构化归档，失败可快速定位与复现，整体测试效率与稳定性明显提升。

4 信息差

工作在岗位，另一个最重要的感觉就是自己时刻在技术一线，这是学校里不可能做到的：例如说 xx 公司出了一个 vibe coding 的模型，那我们基本都会去试一试，我们会从实际的应用场景来评判他的功能，可以从同事的应用效果上了解最新的信息。

要不是实习，我应该是跟不上最新的步伐。原来我还是一个喜欢手撸代码的人，但是来了公司后开始尝试了 cursor, claude 这类东西，极大地提升了工作的效率

到后来就只负责设计结构，撰写 spec ，review 代码，剩下的工作交给 ai 就行了。最近研究了下 mcp 和 Skills 更是让我大开眼界了，彻底改变了我们的工作流了

如果我是一个大四学生天天待在学校，恰逢没有什么课程压力，想必是两耳不闻窗外事，一心只管打游戏了。更别提什么最新的科技发展了。

离职前和 leader 做了一次比较深入的交流，收获很大。与其说是“被传授经验”，不如说是帮我把很多模糊的认识变成了更清晰、可执行的原则。我把这次交流的要点归纳为三个部分：筛选、项目、管理（含自我管理）。

5 感悟

离职前和 leader 做了一次比较深入的交流，收获很大，帮我把很多模糊的认识变成了更清晰、可执行的原则。

鉴于本人不善表达，所以一下内容中，我用 AI 帮我明确表达了一下，但是核心思想是一致的

5.1 筛选（面试与用人视角）

这部分的重点在于：不同面试官看点不一样，但底层能力与价值标准相对稳定。

• 对候选人：核心看“解决问题的能力”

  面试不是复述简历，而是通过追问项目细节来验证候选人是否真的理解自己做过的事。通常会“深挖”你项目中没提前想过的边界条件、异常情况、指标取舍，甚至现场抛出一个新约束，看你如何拆解、如何权衡、如何组织思路。

• 对员工：产出是核心，但更强调“实际效用”而非纯数字

  leader 更关注“你做的东西有没有真正改变现状”，而不是只看产出数量。很多成果很难完全量化，但可以用“结果导向”的方式描述不是为了做而做，而是为了让事情变得更好、更稳定、更省成本。

5.2 项目（从“能做”到“做对、做久”）

这部分谈得最具体，也最能直接转化为行动方法。我总结为四条。

1. 前瞻性：优先做“能长久使用”的能力建设，而不是临时补丁

   很多功能短期能救火，但长期会变成维护负担。更理想的做法是把一次需求看作“能力缺口”的暴露：能不能顺势做成可扩展、可复用、可迭代的能力，而不是只解决当下。

   一个简单判断标准是：这件事未来是否会反复发生？如果会，优先做成“系统性解决方案”。

2. 评估能力：先判断价值与可行性，再进入实现

   不要“闷头干到底”，而是先做判断：

   • 价值评估：做完之后能带来什么变化？受益面多大？是否能替团队省时间/省风险？
   • 可行性评估：关键路径是什么？最大不确定性在哪里？依赖是否可控？

   然后做一个短期 demo / PoC 来验证最不确定的环节，用小成本换高置信度。

   重要的是形成节奏：阶段性总结 + 再评估，让项目始终处在可控轨道上。

3. 沉没成本：坚持“价值标准”，该停就停，该扛就扛

   • 如果验证后发现方向本质不可行，或者收益明显不匹配成本：要果断止损，不要被已经投入的时间拖着走。
   • 反过来，如果判断“长期价值明确且可达”，即使遇到困难也要坚持推进，投入是为了达成目标，而不是为了给投入找合理性。

   这里的关键是：判断依据必须来自价值与可行性，而不是情绪与投入大小。

5.3 管理（管理他人，也管理自己）

leader 提到的一个很实际的点是：管理并不是开会“统一思想”，而是让信息高效流动、让决策更快落地。

• 沟通方式：先一对一收集观点，再小范围对齐

  如果直接开大组会，很多人会因为顾虑或表达压力而沉默，效率也容易被发散讨论稀释。更有效的做法是：

  1. 先分别一对一了解每个人的想法和顾虑；
  2. 找到交错点和冲突点；
  3. 再拉一个小组会集中讨论关键分歧。

  小范围更聚焦，也更容易得到真实信息与可执行结论。

• 管理的对象也包括自己：管理时间、管理注意力、管理决策质量

  工程师常见的问题是陷入“按手册一步步做”的定式：遇到问题就不断加日志、不断试参数、不断堆补丁，但不一定真正靠近根因。

  更重要的是训练一种习惯：跳出定式，随时问自己一句——有没有更直接、更低成本、更可验证的路径？

• 如何做到跳出定式：靠复盘形成可复用的方法论

  复盘不是自责，而是建立“经验资产”。可以固定用一套简单模板：

  1. 我做了什么决策？当时依据是什么？
  2. 哪些环节是冗余/重复/低效的？能不能工具化、自动化、标准化？
  3. 这类问题能抽象成什么模式？能否归类到已有经验库？

  复盘的长期收益在于：你会越来越擅长举一反三，把零散问题归纳成可迁移的解决框架。

6 最后

接着写了，天下没有不散的筵席，我们终将离别。

很感谢乐鑫给我这一次实习的机会，尤其是在我临近推免的时候，面对推免一系列令人焦头烂额的时候，给我发了这一份 offer 。

实习是收获极大的，说实话学校里终究学不到什么东西。后面的读研我认为更大的收货是对意志的磨炼，也是项目经历的扩充。

我会带着学到的方法论，不断扩充我的解决问题的思路，一直走下去。