职业经历与 BBDbuy
从 2022 年开始的工作经历，以及借助 Codex 推进三端项目的实践。
工作经历概览
本人早前表示于 2022 年毕业。2026-10-07 又补充了以下真实工作与休息时间线；月份保留约数，不补齐未提供的具体日期。薪资仍沿用此前本人回忆的口径。
| 阶段 | 已知经历 |
|---|---|
| 2022 年 4 月—2024 年 3 月左右 | 第一家公司，工作接近两年；第一年薪资五千多元，第二年薪资六千多元 |
| 2024 年 3 月—6 月 | 离开第一家公司后休息约三个月；本人称这段时间在“躺平” |
| 2024 年 6 月—9 月 | 第二家公司，做了约三个月前端工作后离开；薪资约九千元 |
| 2024 年 9 月后—2025 年 4 月前 | 旅行约一个月，之后继续休息至进入第三家公司；旅行的具体月份未提供 |
| 2025 年 4 月起 | 开始第三份工作，起薪 14k |
| 2026 年年中 | 主动向老板提出涨薪，薪资调整为 15.4k |
第一份工作结束与休息开始都在 2024 年 3 月左右，月内边界尚未核对；旅行的准确日期也未提供。薪资税前/税后及奖金口径未统一。
本人于 2026-10-07 说明，2026-09-11 提供的简历为了删去空档期而调整了工作时间。该版简历中的任职日期和据此计算的工作年限不能替代本页新确认的真实时间线；项目开始日期仍需分别核对。
2026-10-17 新智慧工作职责更正
本人明确表示未参与新智慧前端从传统 MVC 向 React / Umi 的架构迁移。旧简历及此前改稿中的相关归功不作为个人经历依据，当前简历已删除该表述，保留 TMS 业务后台与仓库 PDA H5 页面开发、业务迭代、接口联调及上线问题处理。
我在 BBDbuy 中的参与
在阅读项目文档、讨论三端整合和工程建设后，我明确表示：
“几乎都是我做的，在借助 Codex 下。”
目前可以记为：我承担了 BBDbuy 的主要建设工作，借助 Codex 推进开发和工程演进。具体到每个模块的方案来源、负责程度、验证与上线过程，还需要结合实际经历补充。
2026-10-19，本人进一步强调：“我一手写过来的，基本知道得很深，包括整套业务。”这是本人对项目建设参与及业务熟悉程度的直接补充，后续可更明确呈现整体前端建设范围，并结合实际业务与方案选择展开。此前仅依据代码保留的职责待核实说明，不应被理解为否定本人此次对主要建设工作和整套业务熟悉程度的陈述；具体上线切换工作、界面改版范围及代表性决策仍可继续补充，不把前端建设范围自动扩大为后端或产品全部职责。
2026-10-19 代表项目、累计用户与上线背景
本人表示，BBDBUY 是自己约三四年前端经历中最有分量的项目。这是本人对代表项目的评价，不据此改写任职时间或计算精确工龄。
本人补充并进一步说明：
- 新系统于 2026 年 5 月正式上线，接替旧系统；该月份不自动代表项目开始开发或所有端同时上线的时间。
- 截至 2026-10-19，本人提供的平台累计用户规模约为 16 万。用户来源中可能有旧系统用户，也有公司投流推广引入的用户；各来源占比、旧用户计入方式及注册、去重等统计口径尚未细化。
累计用户数用于说明平台规模，不等同活跃用户、付费用户或并发量，也不记录为本人带来的新增用户。2026-09 简历存档中的“7 万+客户”保留原来源，不与本次累计用户直接比较或计算增长；本轮未查询运营后台或独立核对报表。
当前简历已补入正式上线月份和累计规模，具体表达与边界见“简历修改上下文”。本人后续补充的上线初期前端职责见下节；数据迁移方式及各端在当时的具体上线范围尚未单独展开，已有团队职责按各自来源保留。
2026-10-20 新系统订单与运单规模
本人补充订单约 49 万、运单约 4.5 万，并明确这是新系统自 2026 年 5 月上线至今的累计量。以本人于 2026-10-20 的陈述记录为截至 2026 年 10 月的新系统业务规模，不与平台新旧用户的累计口径混合，也不将其记录为个人带来的新增交易。
本次没有细分已支付、取消、已发货或已签收等状态，也未独立查询报表；后续按“累计订单”“累计运单”使用，不自动扩大为已完成交易、履约量、并发或性能指标。当前简历已补入这两项背景数字，个人前端职责与代表案例继续按各自来源说明。
2026-10-19 上线职责、线上排障与界面改版
本人进一步确认，新系统刚上线时，前端部分基本都是自己一人完成，包括前端开发、部署与自行测试。这比此前“承担主要建设工作”更明确地说明了上线初期的责任范围；后续团队扩充记录继续保留，不将初期一人的状态扩大为整个项目期间始终没有其他前端参与，也不把“自己测试”改写为所有自动化测试均由本人独立编写。
本人对代表经历补充如下：
- 实际难点判断： SKU 与库存联动可以作为难点；当前多数前端业务在模式跑通后并不觉得特别困难。支付的主要难度在后端，前端接入、计价展示与提交处理按实际范围保留，不包装为本人实现资金计算或账务系统。
- 真实线上排障： 曾遇到谷歌浏览器页面自动翻译后，React 重新渲染导致页面崩溃报错；增加埋点后才定位到原因。本人进一步说明，处理办法是禁止浏览器自动翻译，避免翻译改动页面 DOM 后 React 更新找不到原有节点。此处记录本人确认的线上经历与处理方式，不等同于完整监控平台或所有浏览器翻译问题均已解决。
- RN 双端适配： 本人认为 iOS / Android 的安全区、键盘遮挡等适配比较复杂。具体实现可结合底部操作栏、表单和聊天输入的键盘避让展开，不据此宣称所有设备和系统版本均已验证。
- 界面重写范围： 此前按 Figma 重写界面并复用业务逻辑的项目确认为 BBDBUY；PC 端几乎全部重写，M 与 RN 正在其他分支继续重写。PC 的已完成范围与移动两端进行中状态分别记录，不合并成三端 UI 重写全部完成。
- 设计取舍素材： 本人认为 Store 与 CSS Token 等设计有意思，希望结合项目继续梳理。可按代码中的接口缓存、跨页流程状态和组件本地状态分工，以及设计值、语义颜色和主题接入展开，不仅凭文件或配置推定全项目、三端或完整设计系统都已统一完成。
2026-10-20 三端界面改版范围补充
本人在逐条讨论简历时，指出 UI 改版不只涉及 PC，H5 与 RN 后续也进行了重构，并进一步说明尚未全部写好。此前 PC 绝大部分重写、移动两端在其他分支推进的记录继续保留，当前可以将工作范围概括为分阶段重构三端界面，不记为三端均已完成或上线。
此前本人确认借助 AI 根据外包设计师提供的 Figma 设计稿重写界面；本次“根据外包人员写的”没有单独说明外包是否交付前端代码，因此不新增外包写页面、本人接入业务的分工结论。当前简历第一条已扩大为三端界面改版，Web Token 与主题范围仍按既有实现记录。
2026-10-13 团队经历补充
本人补充，包包达前期只有自己一名前端，后来新增两名前端，团队由 1 人扩充至 3 人。在进一步询问中，本人确认参与招聘面试与候选人筛选，并承担新人带教、任务分配、技术方案把关和代码评审。
这些是本人实际承担的团队协作与技术把关职责，已补入当前求职简历的工作经历。简历中的岗位名称继续保留“前端开发工程师”；尚未确认公司是否授予负责人或管理职级，也未提供团队扩充的具体时间及可量化的交付成果。
项目文档反映的技术范围
以下是 2026-09-10 阅读本地项目文档和依赖配置得到的项目背景，不是个人技能熟练度评级。
| 范围 | 项目中的内容 |
|---|---|
| PC 与移动网页 | Next.js App Router、React、TypeScript、Tailwind CSS |
| 原生 App | Expo、React Native、Expo Router、NativeWind |
| 共享工程 | pnpm workspace、Turborepo，三端公共包 |
| 业务分层 | 公共 API、Query、Flow、类型和业务计算；各端负责 UI、路由和平台适配 |
| 数据和状态 | React Query、Zustand、账号切换清理、请求取消、缓存和错误反馈 |
| 业务范围 | 商品、购物车、订单、支付、钱包、仓库、运单等 |
| 多语言和共享 UI | 共享语言资源，PC/M 共享 Web 组件 |
| 交付与质量 | Git 协作规则、云效部署文档、RN 构建发布说明、业务及端到端测试文档 |
Monorepo 迁移归档记录为 2026 年 7 月完成。2026-09-02 再次阅读本地最新代码时，公共请求治理已经形成独立 @bbdbuy/request 包并接入 PC、H5、RN；可观测性平台、主题等后续方向仍不能写成已经交付。项目文档和代码能证明当前实现存在，但仍不能代替对个人设计、验证和上线责任的确认。
2026-09 公共请求层补充
本人明确表示最新一轮网络请求层优化由自己完成。代码快照可核对到：
- 公共业务不再直接依赖 Axios，而是接收平台无关的 Request Client。
- PC、H5、RN 分别创建独立 Transport，只注入地址、Header、FormData 和日志等端侧差异。
- 请求错误统一分为 business、unauthorized、network、timeout、cancelled、http、protocol 和 unknown。
authMode显式区分 public、optional-user 和 required；并发 required 401 在一个登录会话中只处理一次。- 读取 Query 使用
AbortSignal取消，并只对可恢复错误有限重试；Mutation 不自动重试。 - 日志只允许稳定 operation、method、状态码、业务码和 requestId，不记录完整 URL、参数、Body、Cookie 或 Authorization。
- 相关 Request 与 Query 策略测试覆盖响应协议、错误分类、401、重试和取消。
这项经历适合在面试中表述为“三端公共请求基础设施与错误治理”，不宜弱化为“封装 Axios”。当前没有可靠数据证明性能提升百分比，结果应描述为规则统一、职责清晰、会话竞态减少和敏感日志边界收紧。
2026-10 后台登录依赖与发布检查补充
本人于 2026-10-08 提供本地 Codex 对话“查看这份文档”，作为补充简历的项目依据。对话记录了本人请求通过 Codex 拆分后台登录与业务依赖，并提醒保留用户详情请求以识别已有登录会话。
只读核对本地后台仓库提交 794d3fd 和相关文件，可确认登录、会话服务入口拆分，头像组件、WebSocket 与客服服务按需加载，发布构建禁用 Source Map，以及制品脚本对映射文件和引用残留的失败检查。现有本地构建与 dev 制品没有检索到映射文件及引用残留；对话还记录了构建与本机模拟验证，真实后端联测和线上效果仍不能视为已确认。
这项经历在简历中表述为“登录依赖与发布检查”。分包控制代码加载时机，不能隐藏接口；后端逐请求鉴权、数据权限与静态资源下载限制在该对话中仍为讨论方案，不能写成已经落地的个人成果。完整来源、验证范围与取舍见“简历修改上下文”。
后台与 PDA 的简历素材补充
2026-10-08，本人指出后台与 PDA 在简历中被压缩过度，并提醒还有广播模式。后台当前代码的只读核对补充了包裹拖拽、扫码分箱与分配校验、Code 128 条码批量打印与补打、客服连接生命周期、退款批量处理及作业绩效展示等实现背景。实现存在不能自动证明每项均由本人独立设计或已验证线上效果。
2026-10-08，PDA 素材主要沿用旧简历，本人要求广播模式先保存在修改上下文，切换电脑后再补充。2026-10-09，本人提供本地 PDA 仓库并要求补充；只读核对代码后，已将广播接入及现场作业实现补入当前简历：
- 广播与作业控制： 通过 uni-app Native.js 接收 Android PDA 扫码广播，结合页面显示、隐藏与销毁管理监听；收货页使用输入、相机和广播的统一入口，入库上架页另有单件状态机、货位快照、异常阻断、结果待确认提示及复用请求编号的重试。被拦截的广播不排队，记录为未提交；本机分片日志和会话计件用于追踪作业状态。
- 影像采集与恢复： 商品媒体组件支持限并发队列、进度和手动重试；入库、出库照片有公共水印处理，入库 OSS 上传支持凭证刷新与指定错误重传，照片登记结果未知时先查询核对，再恢复处理。失败任务保留在当前页面，不据此写为离线持久化或断点续传。
- 请求与更新： 请求重试按方法与错误类型限制，通过请求编号关联本机诊断，日志按部分敏感字段名遮罩。WGT 检查发现更新后需要确认，普通安装等待下次冷启动，必要更新安装后确认重启；当前简历已收紧原“脱敏日志”“静默更新”的表述。
本次只证明本地实现存在，没有运行公司项目、调用业务接口或进行设备测试。代码注释提及 Mobydata M63 实机验证及后端幂等，但不能替代本次实测或服务端核验；个人负责范围、上线结果和业务指标仍待分别确认。具体来源文件、测试材料状态与简历取舍见“简历修改上下文”的 2026-10-09 PDA 补充。
上述为当时仅据代码核对的边界；2026-10-21 本人已补充确认具体幂等重试场景，见下文，不再将该场景的后端行为仅记作注释或待确认。
2026-10-13 PDA 原生水印补充
本人补充 PDA 还做了对接苹果与安卓的图片水印处理，并要求直接查看代码。只读核对本地 PDA 仓库后，技术名称确认为 UTS；本地模块通过 UTS 桥接 Android Kotlin 与 iOS Swift，分别利用 Android Bitmap / Canvas 和 iOS ImageIO / Core Graphics 等原生能力合成照片。
实现包括图片方向校正、二维码与图文水印、保留方向校正后的像素尺寸、按体积目标有限调整 JPEG 质量和生成缩略图。桥接传递本地文件路径与少量水印参数；原生模块有后台任务、取消和输出清理，调试页另有拍照、上传进度、回显及分阶段耗时记录。
本人于 2026-10-13 进一步确认，该原生水印模块当前已经实现，测试已跑通，暂未发现问题。验证状态以本人这次最新陈述为准。
本次核对的代码中，原生能力接入“原生水印测试”页，入库验货、出库打包页面仍调用原有 Canvas 水印链路。简历已按模块实现并完成功能验证记录“原生水印模块”，并在技术能力和 PDA 技术栈补充 UTS。
2026-10-21 写入重试规划与 PDA 实践补充
本人补充，BBDBUY 计划为写入重试配合幂等处理，但当前阶段尚未做好；PDA 项目已经实现过相应场景：首次提交因网络问题没有收到响应，重试携带相同请求 ID，后端返回相同响应。
BBDBUY 的对应能力按未完成规划保存，不改为已完成经历。PDA 的上述行为以本次本人确认记录，补足此前仅从客户端代码看到请求编号复用、尚未确认后端行为的来源；不扩大为全部写接口均有同一保证，也不由此新增后端实现职责、上线结果或本轮测试结论。简历表达与后续采用状态见“简历修改上下文”和“简历技能与项目对照”。
可以继续整理的项目经历
以下是候选题目，不表示已经核实每项都由我独立完成：
- 三端整合前的问题、共享业务的抽取边界与迁移步骤。
- 购物车中服务端列表、选择状态、编辑草稿和提交过程的协调。
- 登录与账号切换时，缓存、旧请求和页面状态如何处理。
- Web 与原生平台差异如何通过端侧适配隔离。
- 使用 Codex 时，我怎样判断方案、检查改动和定位问题。
每个题目按“原来的问题 → 我的职责 → 做过的选择 → 验证方式 → 实际结果”补充。没有测量数据时，用可证明的行为变化说明结果，不编写性能、效率或复用率数字。
待补充
过往项目中最熟悉的技术方向，以及两个能讲清楚的真实案例。暂不推断管理职级、团队负责人头衔或全部技术均已精通。
来源：本人此前的职业经历陈述、2026-10-07 补充的真实工作与休息时间线；BBDbuy 的 README、架构总览、迁移归档、三端 README、业务模块、优化与测试文档；2026-10-08 本人提供的本地 Codex 对话、对后台配置、制品脚本、静态产物及业务模块的只读核对，以及本人对 PDA 广播模式的补充提醒；2026-10-09 对本人提供的本地 PDA 仓库代码、入库拍照文档及测试文件的只读核对；2026-10-13 本人补充的团队职责、原生水印经历及模块已实现、测试跑通的确认，以及对本地 UTS 模块、Kotlin / Swift 实现、桥接控制器、调试页和业务调用入口的只读核对；2026-10-19 本人对代表项目、累计用户、新系统正式上线、初期开发部署自测职责、浏览器翻译故障、RN 适配和界面重写范围的补充。此处仅整理职业背景，不复制公司源码、内部地址或账号配置。