流水线优化修改

1、打包中的候选包抽检环节，一般每个产品出1~2个候选即可
2、打包过程中的预选包和正式打包的MTG抽检和UN抽检均由我来亲自审查
3、整个任务过程中，希望尽可能地只进行一次PR和tag的版本推送，所以在进行PR的过程之前一定要认真根据脚手架和规范仓库对项目进行检查和修复，尽量不要出现PR之后出问题的情况
4、当产品中存在MTG渠道时，需在出候选包时按照脚手架规范进行MTG打点和打点信息的记录，MTG的打点是针对项目的，而不是针对产品的。
5、MTG分组打包过程中，如果遇到预先设计的包数无法满足5MB的门禁的话，优先选择低于15个包的包量增加，而不是直接进行质量压缩。
6、正式打包和交付前不用执行发布登记库 catalog的登记，我们也没有权限，直接进行打包和交付过程，管理员会在后续进行发布登记库 catalog的登记
7、关于MTG的打点Mintegral 官方进度点收到、ThinkingData／ETL 后台，都需要你自己去查验，如果没有的话，想出解决办法，注意这个都是要在正式发布PR和tag之前做的，而不是正式打包的时候再来问我有没有搞定，我哪知道
8、在流水线运行的过程中，记录下每一步行为和步骤，确保如果在某个阶段断掉流水线，复工时可以及时续上，或者及时检测到当前运行的步骤而不用从头进行
9、飞书发布消息的模板按照我们之前多次调整和记录过的来，但是如果fl-playbook仓库有更新的话还是要及时比对，优化更新的部分，并告知我优化了哪里。
10、收集统筹了各个mession的情况后，发现Mintegral／ThinkingData 后台收数核验这一块没有找到可直接复用的后台查询办法，因此直接继续工作。
11、推送PR申请时，应当依照脚手架规范，同时更着重更近新版本和新产品的推进。可以多多参考曾经的那些mession的文案
12、PR前的收口和复审的时候要严格按照脚手架进行更正和审查，防止步骤遗漏和不匹配。
13、现在写的文档容易让人理解产生歧义，从而无法通过PR审核，例如明明是你重复抽检候选了，但是却在文档中说我不让你候选，让人产生歧义，在审查文档的时候要避免这种带有歧义的话出现。
14、经常出现这个问题，tag 内产品仍为 pending，正式打包工具会拒绝执行；原候选验证也因源码指纹变化无法直接补登记，以后做收口的时候多注意ready登记是否完成，防止遗漏