进入第一份开发实习后，我对真实项目协作的理解

刚开始时，我更关注自己改了多少代码

进入第一份开发实习后，我最先接触的是环境搭建、页面维护和 Bug 修复。那时我会下意识把一天的工作理解成文件数量、提交数量和功能列表：改了几个页面、跑了几次构建、提交了多少代码。

继续参与跨平台项目后，我发现这些数字很难说明真正的工作。一次提交可能只是把来源分支合入当前版本，主要代码来自其他同事；一个只改几行的修复，也可能需要先弄清 Ionic 缓存、系统手势和原生生命周期。协作中的可信度来自边界清楚，而不是把所有变化都算成自己的成果。

多人项目经常需要把公共功能、平台适配和当前任务放到同一分支。合并完成后，Git diff 会同时出现许多文件，但这不代表这些功能都由执行合并的人开发。

我现在会先区分三类内容：

提交前，我会检查父提交、改动范围和工作区状态，精确暂存业务文件。这样既能保护同事的成果，也能避免把本地配置、锁文件或个人计划带入公司提交。

这种区分同样适用于作品集。公开描述里可以写“参与整合并保护平台差异”，却不能把来源分支中的广告、埋点、插件或其他同事完成的功能都写成个人实现。

一些问题从页面看像是 Bug，继续沟通后才发现它们取决于产品规则。

聊天语音就是一个例子。纯旁白没有生成结果，最初可以从多个方向处理：修改文本提取、继续向后端请求、增加失败提示，或者直接隐藏入口。最后确认产品规则是“纯旁白不生成语音”，前端的职责才变得清楚：会话级开关决定功能是否开放，消息内容决定当前入口是否出现，请求层继续保留安全校验。

签到奖励也类似。页面上只是一个数字，但它可能表示非会员宣传值、不同订阅档位的每日权益，或接口返回的实际领取结果。如果没有先确认数据来源，直接把数字写进两个组件，只会制造下一次不一致。

我逐渐接受了一件事：暂停修改并等待规则确认，不代表没有推进。只要已经把问题、数据来源和可选方案整理清楚，这本身就是协作的一部分。

跨平台项目里，代码验证和场景验证证明的是不同事情。

生产构建通过，可以说明类型、依赖和打包链路没有被破坏；定向测试可以证明某些纯逻辑和状态分支；浏览器探针能观察 DOM、路由和样式时序；iPhone 或 Android 真机才能确认系统手势、WebView 媒体播放、安全区与 App 生命周期。

我曾经遇到页面代码已经更新，但真机仍运行旧 Web Bundle。只看构建输出会误以为修复无效，检查打包复制时间后才发现原生工程没有加载最新资源。

所以现在的复盘会明确写：

把未验证项写出来不会削弱结果，它能防止下一位协作者把阶段性完成误认为完整闭环。

项目里经常存在与当前任务无关的基线问题，例如全量测试引用了已经删除的示例页面，或 ESLint 配置本身无法加载。它们确实需要处理，但不适合在每一次业务修复里顺手修改。

我会先用定向测试、构建和静态检查验证当前范围，再把基线阻塞单独记录。如果为了让“全量通过”看起来更完整而同时改测试配置、路由和业务页面，审查者就很难判断真正的修复是什么，回滚也会变得困难。

范围控制不是只改最少的行数。一个缓存页面问题可能需要增加状态门禁、请求版本或生命周期清理；只要这些修改都服务于同一个根因，它仍然是聚焦的。相反，顺手重构无关模块，即使代码更漂亮，也会增加协作成本。

整理一项工作时，我会尽量留下六部分：

这套方法帮助我在团队交接、简历和面试之间保持同一份事实。日报可以保留当天过程，项目页展示公开案例，技术文章再讲完整机制；三者不需要复制同一段文字。

真实项目协作不是一个人把所有问题都解决，而是让每个问题有清楚的归属、证据和下一步。知道代码来自哪里，知道当前结论能证明到哪一层，知道什么时候需要产品确认，知道哪些文件不应该进入提交，这些事情和写出功能同样重要。

我仍在学习如何更快地沟通和估算，但至少已经不再把“提交完成”自动等同于“工作完成”。