实习马上就要结束了，趁还没忘干净，简单记录一下这段经历。
入职前
都说第一份实习最难找——没有实习经验就拿不到实习，拿不到实习就没有实习经验，经典死循环。不过我运气似乎还不错…? 只投了五六家，就拿到了面试机会。
给到面试的有两家：一个是腾讯的产品经理岗（一面挂了，毕竟产品经历确实薄弱…），另一个就是现在这个岗位。
岗位方向是 AI 音乐相关的后端开发，主要涉及 Python 后端、数据处理，以及 AI 生成系统的工程支持。虽然我的主力技术栈是 C#，但之前做过一些音频相关的小项目，加上有一定乐理基础，这些经历在面试中帮了不少忙。
从投递到入职大概一个月左右，整体推进得挺快的。面试偏工程实践和项目经验，基础知识也有考察。居然没有手撕算法环节。
印象最深的是二面，面试官对我用 WinUI3 做的音频编辑器挺感兴趣，我直接打开项目现场演示了一波（笑）。演示了音频可视化、播放控制、效果器这些功能，面试官追问了 EQ 均衡器的实现细节——具体来说是怎么处理原始音频数据、不同频段的滤波是怎么做的。我回答用的 NAudio 库解析音频流，直接操作 buffer 数据，EQ 部分是对不同频段通道调用了 NAudio 提供的滤波函数。感觉这一段对面试推进帮助挺大的。
入职后
工作地点在上海，办公环境挺好的，园区内吃喝配套齐全。日常作息也比较规律，弹性工作制，对实习生来说节奏比较稳定，不会有那种一来就被赶鸭子上架的感觉。公司在住宿、餐饮这些方面也提供了支持，基本不用操心生活上的事，能把精力集中在工作上。
总的来说，这段实习在生活成本和时间成本上都挺友好的，省了不少心。
工作内容
我做的是一个服务于内部团队的 AI 音乐生成系统的后端开发。在我加入之前，系统已经完成了初步搭建，我主要负责后续的功能扩展和优化。
如果用一句话总结这段实习最核心的体验，其实不是”做了哪些功能”，而是：怎么在一个已经上线、正在被使用的系统上，做增量修改与演进。
一个系统跑着跑着，就会开始出毛病：
- 逻辑分支越来越多，维护成本蹭蹭往上涨
- 新需求想接入，但又怕动到已有逻辑
- 数据结构逐渐承载了当初设计时没考虑到的东西
后面的工作，本质上都是在这些约束下做权衡和改造。挑两个印象比较深的聊聊。
已有工作流的重构
系统中有一个”类型”的概念，用来控制 AI 生成内容的风格和策略。最初的实现很直接：用 if/else 分支区分不同类型，走对应逻辑。系统初期这么写没问题，但随着类型不断增加，代码开始变得难以维护：
- 分支越来越多，可读性直线下降
- 加个新类型就得改已有代码，碰一下就怕出问题
- 不同逻辑之间互相耦合
直觉上的解法是：重新设计数据结构，对不同类型做规范建模。但在已有线上系统中，结构变更成本较高（需要走审批发布流程，且会影响已有数据），因此需要选择更轻量的扩展方式。
最终我的方案是：利用表中已有的一个 JSON 扩展字段，在不改表结构的前提下完成扩展。新的类型通过配置扩展字段实现动态分流，同时调整了工作流的路由和调度逻辑，让不同任务按配置自动分配到对应的处理流程。
在兼容性上，读取时做了 fallback 处理：如果 JSON 解析失败（字段为空或缺少新 key），会 catch 异常，回退到默认类型，保证老数据不受影响。
上线后效果还不错，团队后续新增类型只需要加配置就行，不用再动代码，维护成本明显下降了。
不过说实话，这本质上是刻意引入的技术债。选择这个方案是因为：
- 受限于线上环境，这是当时最快速安全的办法
- 扩展字段的查询场景有限，主要是写入和按主键读取，不需要对 JSON 内部做复杂查询
- 类型数量不会无限增长，预期规模可控
但也有明显的改进空间。比如我没做 schema version，如果重新来过，我会在 JSON 里加上 version 字段：
{ "version": 1, "type": "C", "data": { ... }}这样未来格式变化时可以按 version 做兼容解析。
另外我也给自己设了几条”迁移红线”：
- JSON 字段内的 key 超过 5–6 个，或者出现嵌套结构 → 该做 schema migration 了，维护成本已经超过迁移成本
- 需要对 JSON 内部字段做查询或索引 → 必须迁移，JSON 字段没法高效查询
- 多个模块都开始依赖 JSON 里的某个 key → 说明它已经不是”扩展”了，而是核心字段，必须正式建模
在我当时的场景下，JSON 里只有 2–3 个 key，只做写入和主键读取，短期是合理的。但不会无限制往里塞——技术债嘛，在维护成本开始反噬开发效率的时候就该还了。
权限系统的扩展
系统最初面向小团队内部使用，权限控制很简单，基本靠默认约定。但随着功能逐渐细分，不同用户对功能的访问需求开始出现差异，原来那种”大家都能用”的方式就不太行了。
我没有引入完整的 RBAC 或 ACL 模型——对这个规模的系统来说那属于过度设计了。取而代之的是一套轻量级、可渐进扩展的权限方案，核心分三层：
1. 业务线粒度的权限划分
把系统功能按业务线拆分，每条业务线作为最小权限单元，定义读/写两类基础权限。
好处是简单直接，能快速覆盖”某人能不能操作某功能”的绝大多数场景，也避免了过早引入复杂角色体系带来的 role explosion 问题。代价就是权限表达能力有限，做不了特别细粒度的控制。
2. 可见性控制与黑白名单
除了”能不能操作”，还有”能不能看到”的问题。
我单独设计了一层可见性控制，支持按个人、按组织层级、以及黑白名单组合来配置，并定义了明确的优先级规则。
目的是在不搞复杂权限系统的情况下，实现灰度放量和精准控制。实现上做了一些简化处理，比如组织匹配没有做严格的树结构解析，而是用了更轻量的方式。好处是不用依赖额外的服务，落地快；代价是精确度有一定损失，但在当前场景下是可接受的。
3. 动态配置
除了权限判断，系统里还有不少历史遗留的硬编码配置。我加了一套动态配置系统，把这些配置存到数据库，更新后同步到运行时内存。
这样运营调整参数的时候不用发版，也为后续做灰度策略留了口子。
但这部分本质上是弱约束结构——schema 不固定，缺乏类型约束，长期来看有变成”配置垃圾堆”的风险。
写在最后
回头看这段实习做的这些东西，本质上没有一个是”最优解”，都是在现有约束下的折中：
- 没有改数据库结构 → 避免高成本变更
- 用 JSON 承载扩展能力 → 换取灵活性
- 没有引入完整权限模型 → 避免过度设计
核心思路就一句话：先让系统可控，再逐步规范。
这段实习给我最大的感受是，在一个已经在跑的系统上做开发和维护，跟从零开始写是完全不同的体验。你得学会跟技术债共处——知道什么时候该引入它，也知道什么时候到了该还的临界点。这个分寸感，可能比写出多漂亮的代码都重要。