每日工作日程
【周一】2025/10/27
上午开会：
- 交接进度比较缓慢，需要分析具体原因和情况，主要精力在核心功能板块的问题解决
- 强调内部关系和谐，沟通是必须的，必须禁绝不沟通交流导致项目实现延期的问题
- 明确项目的主导责任关系，之前的林李江就不用来了
- 公司目标是在一年内，以
Tiktok shop的半托全托为主，发展起来，前期不盈利或少盈利 - 年前（剩下三个月左右），会对工作态度、责任心、担当设立考核门槛，实行岗位股份调整
按照技术部4个人，客服2个人，销售2个人来设立决策位置，不搞一言堂，用投票方式确定决策 - 优先完成
AI实现图生图、图生标题、图生视频功能 - 客服那边的问题，优先自行解决，对于需要记录汇总修复的问题，需要统计客户影响/需求人数
超过20%~30%才需要技术那边修改
开完会之后，涛哥对具体的业务流程给我们做了一个分析讲解。然后将之前给小龙提的一些需求重新给我们复述了一下
【周二】2025/10/28
跟进灵图的技术沟通问题，确认图片提取标题接口的限制问题
上午涛哥给讲解需求，要做一个仓库管理的一个新的模块实现。库存统计的展示
今天差不多中午签合同
合同默认模板是写着工资固定2500元的，这个我跟两位老板沟通过，重新给更换过合同内容，写成实际工资了
前端和测试的同事也重新签了劳动合同
然后下午再实际试用了火山引擎的豆包的模型。使用的是1.6版本，试用之后估计错了那个调用量。
实际是可以实现传入一张图片的base64字符串以及一个提示语的内容，然后返回商品标题文本
赠送了25万的token，调用流程还是蛮简单的
后面来了一位老板叫的朋友。估算了一下实际运算最高的话，一张图2分钱，最低不到1分钱
今天最后把这个库存管理统计模块的需求分析和简易原型图输出成文档。给到涛哥确认
火山引擎的账号在直接登录成功了，但是企业认证还没有做完，需要一些资料，明天找吉哥协助
【周三】2025/10/29
一早上过来完成了企业认证，创建了角色，准备接入STS授权接口
学到了一手，日志量级太大，就把今天以前的日志进行tar压缩，只保留当天的日志作为可直接查看的日志
原先日志文件5个G，压缩之后一个G，甚至不到一个G
排查出来那个仓库名称不存在的问题了——TUME返回的数据里不包括这部分仓库名称，只有仓库id和收件人名称
原先20250717的时候，小龙就修改过这个部分的接口，原本查询发货台的接口，改为大仓收货地址查询v2
因为这个查询发货台的接口当天返回的字段里的receiveWarehouseId和receiveWarehouseName都是Null
而大仓收货地址查询v2这个接口返回的receiveWarehouseId和receiverName，并没有返回receiveWarehouseName字段
所以就造成数据库里为空
而第二天来查看的时候发现，昨天的数据已经全部同步正常了！
我认为问题就出现在Tume返回的数据上，当天的“查询发货台的接口”，应该就是一直无法返回正常的，而第二天就正常了
解决方案应该是在当天的这个“大仓收货地址查询v2”接口里，想办法搞到仓库名称即可！
【周四】2025/10/30
早上过来，特地早点过来，想着把昨天这个问题实际解决一下，结果早出发反而堵车……
确认昨天问题的那个代码文件实际是没有插入仓库名称的
\serv.daishuerp.com\apiService\temuApi\bg.shiporder.receiveaddressv2.get.php
我看到这里有相应的仓库表存储数据，所以有仓库id，就去表里查询一下，我补充了一个查询方法，直接查询出来名称
实际业务逻辑是：
1. 定时任务调用：automatically_create_jit_invoices_v2_process.php
2. 并发分发，automatically_create_jit_invoices_v2.php
【周五】2025/10/31
早上要了个验证码，登录火山引擎的网站，想使用STS服务生成用户临时授权信息
结果发现他们本身的这个功能死活生成不了用于火山方舟的STS信息
找了商务拉群的技术，没想到人家十点才上班，根本没人回答，我只好去找官网的在线客服沟通
客服给了一个新的链接给我，这个才是临时授权的接口，
然后用这个接口调用火山方舟的AI对话：
然后检查了相关的Temu相关接口更新，检查到有不少接口都有更新，其中包含：
- temu.goods.labelv2.get 改为 bg.glo.goods.labelv2.get
- temu.goods.add 改为 bg.glo.goods.add
- temu.goods.list.get 改为 bg.glo.goods.list.get
- bg.goods.add 改为 bg.glo.goods.add
而且有一个很坑的事情，Temu的接口文档改动速度非常快！
- 中午11:50，小龙给截图的Temu文档部分，还是只支持一个接口地址的
- 16:55截图的效果，这个接口兼容了旧版接口，两个都支持了！
按照原先技术部的规矩，是十点上线的，，但为了保险，还是打算今天晚上十二点做版本升级，上线后端和前端的代码
把上面修改的接口地址都修改好了，然后准备发布到production分支
但是这时候遇到了两个问题：
1. 生产服务器本地有修改内容，并没有进入git代码仓库里
2. git仓库的默认分支是master分支，我错误的认为是稳定的
然后我就做了两步操作：
1. 直接将稳定的production分支合并到master分支上
2. 【不正确的】将不稳定的master分支合并到production分支里，造成生产的内容不稳定了
晚上跟涛哥吃饭
然后在production分支（此时已经不稳定了），部署在测试服务器上，给到彭梅测试
测试下来，除了在上款的时候出现了type not exists.这样的错误以外，就没有别的问题，包括登录接口及常用接口
出现这个错误的时候，已经到了十二点左右了，我和增鸿开始执行上线流程
开始进行上线之前，进行代码备份和数据确认，然后开始操作
cp复制整个serv目录- 确认
serv目录下的暂存区工作区内容 - 将未暂存的部分单独备份到家目录下
然后开始上线
1. 将暂存区内容工作区内容完全丢弃
2. 执行git pull --rebase命令
结果开始测试时马上发现登录接口出现问题
我检查了这句话，只有crm项目当中才有这部分内容，而这次内容只修改了serv项目当中的代码，并没有涉及到这部分改动
所以常规的方式应该是无法解决的，我第一时间就把之前的备份给恢复上去了。
这次后端上线就宣告失败了，前端的代码打包上线倒是很稳定，没有任何问题
【周六】2025/11/01
由于昨晚熬到差不多一点多才从公司走，送完他俩到家，我到家都已经差不多三点了。
周六过来就只能睡到自然醒来，然后过来公司已经是下午了
看到早上吉哥在群里说阿里云审核没过，因为那个底部备案号的前面主办单位名字写错了，不应该是“广州点橙科技有限公司”
应该是“点橙（广州）科技有限公司”
过来先远程协助增鸿把这部分的内容进行修改并且上线
然后涛哥过来用他的电话，我跟小龙电话沟通了下，他提到交接文档当中有一句，“以生产为主”
我这才找出来之前这个没当一回事的文档：
找到这一句，哦，原来我昨天犯了这么大的一个错误！
然后马上跟增鸿沟通这个问题，确定我们之前合并进production分支的那个提交，考虑回退或者撤销掉这部分
考虑提交历史的完整性，就没有使用“强制回退+强推”的方式
而是找到目标提交，用git revert commitId来撤销
由于这个提交还是一个合并提交，所以还需要用-m参数指定需要保留哪个主分支来进行撤销！
git revert d34c112 -m 2
然后进行生产分支的推送，六七点的时候进行上线！
一切正常
然后我和丹霞对这些接口变更的功能进行测试，包括：
- 店铺授权绑定和修改（重新绑定）
- 店铺的模板数据同步
- 紧急备货单和普通备货单数据查询
- 备货单的拣货单、商品条码功能检测
- 工具箱当中的批量上款功能测试
- 合规图和商品实拍图上传
授权功能也是没有开授权，但那个让丹霞去测试过了
但是这里面有一个“JIT虚拟库存编辑”功能，这个功能由于我Temu账号没开JIT权限，所以就无法测试
（这个问题有客户反馈出现了问题）
这里不该是0任务，0成功，0失败的
涛哥说第二天才给权限，所以只能第二天再测试了。
【周日】2025/11/02
早上起来，赖铮就说出现了大面积的打单失败问题
具体表现就是打印商品条码的时候，显示条码同步失败
我到公司之后就开始排查相关信息，问赖铮这边要了相关的店铺信息、备货单号，然后去排查
这个地方我发现是数据库当中的label_product没有这条skc数据，导致条码输出的时候没有拉取到对应的信息
然后排查写入的位置，找到是定时脚本（apiService\temuApi\job\purchase_order_syns_process.php）启动起来调起的
temuApi/job/product_barcodes_sysn_v2.php
这个文件当中实现具体的写入的。
这里有两个问题：
- 订单在客户点击“打印已完成”后，订单状态已经变成4（装箱发货）了，脚本内的条件就不满足了，也就不会再去同步条码
- 获取
Temu服务当中的api，上次更新遗漏了，造成这个接口依然请求的旧api，授权就不足了
所以我的解决方法是：
- 写了个
test.php的脚本，将状态4的订单也进行同步条码，临时跑一下，解决紧急问题 - 将脚本当中请求旧接口的部分，改为新接口
这样执行了几次之后，就可以正常获取同步到条码了。
但是这里的部分还是存在问题：
- 脚本本身有严重的性能问题！用了查询的方式一点不经济，会造成严重的时间浪费
- 如果用户没有权限请求接口，应该有一套通知体系，而不是由客户自己反馈回来，而是系统有自己的反馈体系
本周感受及提升
体会
入职的第二周，感觉这周的强度比上周强很多，上周很多的开发工作还只是循规蹈矩的
这周，周一开会和周五晚上吃饭，都强调我这边对接交接的重要性，很多紧急、线上问题都是这周砸上来的
对我而言，难度不是特别大，但是交接起来，实际工作起来会特别麻烦，特别是这套系统的三层逻辑体系
给我的开发和排查造成了很大的麻烦！
反思
想当然认为惯例就是对的
在周五周六上线的这个事情里，我认为我做事还是不够妥当，特别是master合并到production这里
可以说是十分的不妥！
想当然认为master就是最稳定的，并没有根据事实去确定，也没有把交接文档当一回事，这个是我最大的错误，犯了轻视的错误
缺少总结和整理性的思维
在排查时，并没有总结好相关的排查问题，特别是针对临时，大量，客户猛催的情况下，没有足够的冷静
一着急起来，很多东西就很难排查清楚，特别是参数，错一点就是全错！
文档要做好留存记录
关于Temu和Tk的相关接入文档，除了防止平台变更以外，还需要防止一些网路原因或别的原因打不开
所以要根据时间进行备份，规整，免得这些资料紧急要用的时候打不开，用不上
提升
- 日志压缩储存的思路
- 火山引擎，AI对话的接入经验