Design Hub

GShion

占坑~

检出，增加，上传与更新，冲突，换仓库

GShion

七牛云好像有免费的每月下行流量额度，阿里云也有（香港免费5G）

首先登录阿里云官方网站，搜索对象存储 OSS服务
如果购买容量就点击购买，不然不用购买，直接用香港的5G免费

进入购买页面，资源包类型、地域和标准型存储包规格按默认的选就可以

然后选择购买时长，都挺便宜的随意就好

成功购买后创建一个Bucket

Bucket名称随便定一个，地域选择中国香港（有5GB免费下行，图里北京是因为还没改），其他的所有东西都不要开
（如果之前买了就选内地的）

其他所有东西都不开

选择刚才建立的Bucket

选择概览，记下Endpoint

右上角账号选择AccessKey管理

点击开始使用子用户AccessKey

取一个登陆ID和显示名称，然后勾上OpenAPI调用访问

复制下AccessKey ID和AccessKey Secret
要注意！如果这里关闭页面，那么AccessKey Secret你就再也看不到了！最好在聊天记录里发给自己记下来，或者直接在思源笔记里面记录（反正别人也不会看到）

然后给子用户授权

重新打开Bucket，新增授权

由上文，我们获取了：

Bucket对应的EndPoint
子用户的AccessKey ID （Access Key）
子用户的AccessKey Secret （Secret Key）
Bucket名称
Bucket所在地域Region，用拼音就行

打开思源笔记，选择设置-云端，然后选择S3服务（思源不能用坚果云，草）
（纯纯笔记可以用坚果云WebDAV，但是不能用S3）

然后把对应配置填进去即可

点击左上角云同步按钮就行啦

GShion

打包了一个文档传网盘，列表如下：

Draw-Io（专业的流程图软件，无需安装即开即用）
Obsidian（专业的MD格式的笔记软件，如果喜欢可视化多一点可以用思源笔记，更轻量一点可以用有道云）
PNGoo（压缩图片的软件，如果不用这个也可以用网页版的TinyPng）
Q-Dir（同时在一个窗口里打开多个文件夹的软件）
VSCode（写代码看代码或者干脆当作记事本软件都可以）
WpsVba（给WPS安装VBA支持，别去花钱买它的VBA支持了）

其他的还有xmind之类的，之后再弄

可以在这里下载：https://www.123pan.com/s/3y6bVv-JdR3v.html

GShion

商业化天下第一，无论是对独立游戏还是商业游戏
不要太信玩家评论，要信后台数据，尤其是他们的钱，喊得最响的和最愿意花钱的有（很有）可能不是同一批人，要推测这些人为什么花钱，钱都花在哪里，他们买了服务获得了什么，可能想要获得什么，然后再优化这一方面
表格设计从一开始尽量规划好以后，如果后面的变化太大，那么就要考虑冗余数据优化以及表结构优化，并出文档，不能“望文生义”的东西都要出文档，文档天下第一
ErrorCode,UIStatic,如何进行多语言,程序字美术字,字色字号规范与配置（方舟的做法很好，定义<color=#FFFFFFFF></color>为Text:Black</Text>（黑色）或者Stat:UP</Stat>（数据提升），所见即所得，避免谁都不知道颜色代码具体是啥颜色的情况）
关于字体，还有个很骚气的做法是常用字做一个图片字库，全是美术字（注意只能用在一定是这些且仅有这些的字的情况，比如战斗中的“暴击”二字），然后在具体地方调用字库
不要设计只有自己喜欢的东西，也不要设计只有自己玩的懂的东西，除非想要游戏挂掉
商业化或者商业基于两种模式：以质量为本的产出模式和以投机为本的投机模式。第一种在于质量，也就是在确定市场后深耕，一头扎进去做。这种需要完善的内容创造型人才培养机制。第二种在于商业机会，也就是什么赚快钱并且容易做就做什么。这种需要对市场的掌握，商业化能力，商业远见以及决断力，需要熟悉各类快速开发流程与痛点难点的人才，而创造型则不太需要，需要的是抗压能力强快速做活的员工。
以上，重点就是确定一个打法后就不要改了，不要左右摇摆，因为他们的本质是冲突的：第一种是主要利益由大部分人产出，利益也都是共同体；第二种是主要利益由极少数核心成员产出，利益以核心成员为主。
表格逻辑的统一性：bool：true/false，TF，01，YN如果混杂会造成极大困扰，以及折扣0.3为3折，3也为3折这种。注意要一种功能只能有同一种文字/配置解释，不能这边配1的意思是原价，那边配置1的意思是1折。
滚服游戏的很有趣的一点：可以给玩家造成这游戏挺良心的感觉，我虽然没玩好，但是这是我的问题，不是游戏的问题，以保底来做（但是后续的影响没想过，做短爆的思路了）
关于少女前线与最近的体验：我都能抽到，但培养不起，感觉和大R差别就没有那么强层级感觉
动作设计上的问题，美术资源库
通用内容很重要！如果可能，前期最好确定可以通用的复用内容，避免到处乱做，比如奖励啊，帮助啊之类的，多个地方用到相同的模块，可以直接调用不大改的都算复用
文档的意义就在于所有的东西交给别人时你不用再讲一遍。如果你自己写的文档过了一年忘了，重读的时候发现自己也读不懂，那文档就是渣渣。文档本身是给具有基础知识而没有专用知识的人看的。如果别人看不懂，可能是两种情况：没有基础知识（如不懂数学就不可能懂导数），或是专用知识你没有讲好。因此，在写文档是也需要注意一下本文档到底用到了哪些基础知识，基础知识要不要再出文档。
关于管理权威方面的一些问题：在这个观点下，重要的不是情绪也不是事情本身，而是这件事情导致的对管理能力的影响。这也是关上门什么话都可以说，什么桌子都可以拍，而出去了就得相互都照看着的原因。如果在外面出现较大争论、吵架或者拍桌子，那么重点就已经从事情对不对上变成了对管理权威的挑战：我不服你管，你有没有办法治我。因此，如果问题涉及到管理岗位的人员，那么在任何时候都要留有退路：不在公众场合前进行激烈争论或者吵架。
引申出去，能否将应该推动的事情正常推动，也不止是事情本身的问题，而是对管理权威的挑战。合理的方法是自己先尽量避免导致这种结果（因为自己是可控的，他人是不可控的），比如慢慢磨，请个奶茶，说点好话之类。但如果完全是对方的原因导致无法推动，那么参看上一条（关起门来聊天）。仍然无法推动，那么就只能找能说的上话的人推，或者让人家走人。
以上两条的目的不是为了自己或他人考虑，维护所谓权威——而是不要在自己没有这个目的，不知道自己的行为会导致对方损失什么，也没有准备付出对应的代价的时候去“非故意”地挑战别人作为管理的权威。管理人员之所以能够“管理”人，是因为具有管理的权限与权力。如果该权限与权力受到了挑战，那么就是职场生死线：我不接招，那我就别想再干下去了。上级认为你没法胜任管理岗位，下级也认为你没能力去推动事情或是管理他们。
如果出现了最坏的结果，那么职场上就没啥路可以选了：留一走一或者都走完，或者至少有一个人在所有同事面前道歉声称自己当时过于冲动。还是要说一下：不是为了维护权威而维护权威，而是别做自己没有准备好付出相应代价的事情。如果打定主意再也不干也不管背调，当然就可以直接骂老板傻逼了。
策划可以不懂程序，但一定要懂程序思维。

GShion

写这玩意是为了避免踩坑！！！都是真事教训！！！

立项前预估工作内容问题
- 策划应当提前做好各系统的大略内容说明，也就是玩什么，怎么玩，能玩多少的问题。
- 策划应当提前做好所有UI板子的图量表，用于预估大致的内容，一般认为程序在有详细策划案的情况下可以1天做1个通用业务的板子。
- 程序根据UI板子以及此前经验预估各部分或者全部的工作量。复杂的地方（如英雄、装备之类的）可以多估一点。预估完成后，增加至少20%的时间用作风险余量。
- 注意策划按板子排工作量的话天生就排不准确，因为策划不清楚程序是如何通过板子与具体内容估算工作量的。粗略估算还是得程序自己看UI图量表，精确估算则需要策划出好详细策划案。
- 如果预估错误，可以通过具体工作时长与内容看一下多出了多少工作量。
- 是否做本地化，如何进行机型适配，高中低配如何处理。
预演可用性测试问题
- 游戏上什么途径，引擎支不支持，有没有问题，对应途径有没有常见的坑，先测测试试。
- 搞一个预测的假内容，但是大小什么的都是目前可预期的大小，不然可能包出不来就要换引擎、换版本。
- 查看一下对应论坛引擎可能存在什么打包出包的坑。
- 查一下上对应平台可能存在什么打包出包的坑。
中台内容工作量估算问题
- 中台与通用内容很容易就会在立项的时候漏掉
- 基本的游戏GM功能、前后台功能、网络功能、图集与性能等
- 包括前端中台与后端中台，这个得单独出文档
立项后定每周工作内容/月度里程碑节点的问题
- 每周工作除了工作量合理以外，工作分配应当平均到人，不能出现本周只有一个大活且只能一个人负责，闲的闲死忙的忙死的情况。
- 前期月度节点可以依据情况定，重要的是后几个面向玩家的节点：首日节点（1日内容/3日体验，内部测试用)、三日节点（3日内容/7日体验，面向玩家，技术测试用）、七日节点（7日内容/14日体验，面向玩家，买量测试用）、14日节点（14日内容/30日体验，面向玩家，大推用）。
- 应当保持每月1个小版本（新角色、小活动、小养成线），每季1个大版本（大活动，新功能，大养成线）的开发预估。
各部门工作进度问题
- 策划的策划案应当领先程序工作进度两周及以上。
- 策划的图量表/美术需求案应当领先美术工作进度一周及以上。
- 美术的产出资源应当领先程序工作进度一周及以上。
- 程序应当预估的时候就将修Bug的时间估算进去，并且在本周的节点时给出没有Bug的内容。不能说时间到了还要求额外时间修Bug。
- 程序应当在时间节点给出策划验收通过的内容的原因，是因为正常情况下这部分内容会直接面向玩家，直接对玩家与营收数据负责，不能分派额外时间修Bug这一点是由玩家说了算，策划、程序说的都不算。
- 程序估时往长了估计，多退少不补。不过除非能够证明确实有这个需求，否则额外的估时时长应当在预计开发时长的20%以内（4天开发，0.8天修Bug，正好大概一周）。
- 另外，开发完成=>验收=>给反馈，修Bug存在时差，注意考虑到这一点。
产出内容格式与管理问题
- 无论是策划案、美术资源、UI、特效、字体、音效、模型、图片与图集，都需要内容格式与限定框架。
- 所有游戏资产都应当有固定的资源命名、存放、管理方式与管理负责人。
- 目的是除了保证游戏整体的统一性以外，还会方便资源管理、开发以及性能优化。
- 所有游戏资产管理，策划必须要参与，避免程序问策划资产在哪、策划问美术资产在哪、美术问策划当时这一批需求给过来的时候策划知不知道里面都有什么的情况。
资产帮助（老版美术资源，代码资源，策划案）问题
- 重要的话说三遍：即使有了资产帮助，开发逻辑也仍然是重新开发逻辑！即使有了资产帮助，开发逻辑也仍然是重新开发逻辑！即使有了资产帮助，开发逻辑也仍然是重新开发逻辑！
- 如果有美术资源，那么考虑是否能复用以及复用率，以及是否需要修复图片大小，分辨率等。
- 如果有代码资源，优先转代码而不是看代码。
- 如果有策划案资源，优先通读并对比现在的竞品，优化设计不合理的地方。
- 最后，不要过于依赖帮助，帮助只能在有限的情况下增加开发进度，但源头仍然是策划案。策划也不要被资产帮助限制死了，先出了策划案再决定让程序看代码，如果看代码耗费时间过长，那么直接按策划案上的做，而不是让程序看代码还原一个东西，策划再从这个东西里面挑刺，找不合理的地方。
- 在没有资产帮助的情况下，美术需要图量表、程序需要策划案、策划需要研究竞品。资产帮助只是将这些需求的强度弱化了，但不是消除了需求。
- 无论外部帮助程度如何，策划对一个东西应该是完全清楚的，如果不清楚，就要拍板，先拍了再说，遇到区别再决定听谁的（策划新想的还是外部帮助的）。
- 总而言之，策划案和相应文档不能少，不要产生帮助能让策划少写策划案的幻想，程序在没有策划案的情况下可以直接拒绝做事（但在有代码帮助的情况下，最初的策划案可能没办法太详细，更近于表现策划案，一些关键设计可能还是要程序看代码）。
通用内容问题
- 策划应当就常见通用内容出策划案。常见通用内容包括引导、红点、音效、通用奖励界面、连续弹窗口显示规则、跳转途径、帮助、任务、扫荡结算等。
- 以及各种高中低配的设计，和这些设计分别代表了什么意思（如使用不同精度的美术资源，还是削除了一些美术资源表现之类的）。
- 不要多次开发通用内容，策划在写案子的时候应当考虑涉及到的某一部分是否可以在不同的位置通用（或稍微改一下就可以通用），然后把通用的部分独立成另一个策划案。
- 通用内容也应当策划和程序共同维护，程序看策划案的时候觉得某部分可能是通用功能，那就叫相应策划看一下，如果通用就重新写，单独排期做。
工作流程问题
- 合理的工作流程，应当各方各面都考虑到，而且方便团队开发。
项目跟进问题
- 应当有一个负责统筹所有进度（实际进度与预期表现，要有明确具体可执行的验收标准）的人员。该人员负责统筹项目进度与各方面需求，建立问题列表。
- 使用CheckList单跟进项目。如果跟进项目没有好好跟，那么需要就跟进人员问责。
- 使用跟进与验收标准来倒逼执行，不符合跟进验收标准的就得重做。
- 建立问题列表与负责人，有事必跟，每周周会会的时候都看一下。
项目验收问题
- 验收标准如果不明确，可执行程度不高，那么必然导致拖延，因为内容产出端都不知道自己要做成什么样子。很多时候可以从验收标准文档反推出开发时各个地方要做到什么地步。
- 可以使用CK单验收。对应里程碑的CK单务求全面，验收里程碑时记下所有问题（以及吐槽！）。之后讨论月版本问题所在、修改方案与工期。
- 表现与性能上的真机标准，什么是真机标准，上线标准，什么是上线标准，这些都要明确，或者至少能被大致感知，如约0.5秒，约1秒等。
- 要确定标准机型，高中低配置机型至少确定一个，并且使用真机做测试。

前瞻性与什么是前瞻性
- 定义：避免踩坑，按时推进，赚更多钱
- 从0开始的前瞻，注意要看到坑。骨架是核心，但这些东西容易“习以为常”忽略，只关注业务，其实是第一优先级。这些内容全部要提前趟一下或者提前做，避免不上不下的时候发现问题
  - 容易踩的坑
    - 游戏上什么途径，引擎支不支持，有没有问题，先测测试试
    - 搞一个预测的假内容，但是大小什么的都是目前可预期的大小，比如小程序出包问题，差点搞得要换引擎版本
    - 查看一下对应论坛引擎可能存在什么打包出包的坑
  - 为了避免踩坑的规章制度
    - 类似于不准改数据库数据之类的
  - 除了通用业务之外的所有骨架内容
    - 前台
      - SDK接入
      - 资源管理，资源压缩，资源规格标准
      - 版本管理，SVN/Git，主干分支
      - 热更，强更
      - 打包、本地包、线上包
    - 后台
      - 服务器列表，服务器列表显示规则，服务器状态，自动修改服务器状态等
      - 服务器稳定性，连接稳定性，连接容量
      - 弱网环境、断线重连
      - 数据验证
      - 账号相关操作（换号、顶号、封号）
      - 报错日志，线上报错日志
    - 数据运营
      - 管理后台
      - 埋点、各类统计数据（需要细化）
      - 各类玩家统计数据（和上面差不多）
      - 邮件、补偿、cdk、公告
      - 查找可疑行为（广告哥）
      - 修改各类属性（后台GM改号行为）
      - 其他的操作功能（需要细化）
    - 业务量
      - 全部的UI图量表
      - 全部的特效图量表
      - 全部的通用音效要求
      - 全部的系统内容详情
      - 通用内容尝试单独拿出
        
        红点
        
        奖励
        
        帮助
        
        音效音乐
        
        缺资源跳转途径
      - 按板子进行不精确的时间预估，然后乘以1.2
      - 如果以上内容不能全部，至少75%以上
  - 核心业务
    - 核心业务能不能做，怎么做，是否有参考的踩坑记录
    - 核心业务做多大，就是战斗中几个角色，多少buff之类的，性能消耗范围
    - 核心业务的框架设计文档，即使有参考，也要重设计并且出设计文档
    - 优先保证核心业务而非通用业务
- 从0.5开始的前瞻，核心是项目管理进度推进，套话来说就是“有法可依，有法必依，执法必严，违法必究”。说得比较重但是核心就是这个。既然推进进度，那0进度和100进度都是什么得要有，里程碑是什么，需要什么前提条件得要有，给出的内容以及验收的标准都要有。最重要的是“可执行性”，不能说出现“这个东西重要，xx时间要，但是没有具体执行文档”的情况
  - 各个里程碑，以及大概的概念定义（几句话简述做到什么程度）
  - 对应的验收ck单，可以和测试一起确定，务求详细（拿着这个去验收，对应程序也要看看）
  - 重复工作量尽量减少：通用内容的开发，通用工作流（比如策划模板这种东西）
  - 项目整体的把控：什么有，什么没有，什么缺，什么要补，大概多久完成
  - 项目中出现的问题记录，解决，跟进。由策划牵头，各主管都要负责
  - 项目与竞品的体验差异记录
- 从1开始的前瞻
  - 真机要求（需要细化）
  - 市场，商业化
  - 现在的体验情况，竞品的体验情况
  - 头部产品的商业化策略
另外，现在发现关注最底层逻辑走过来可以让基础打得很坚实，实际上外部帮助都不能帮助基础，有点像空中楼阁，看起来很好，但只用这些是做不了的
只有在基础坚实的情况下才能用好帮助
1. 经验：说白了就是坑踩过去的总结经验多不多
2. 开发能力：人员做不做得出来
3. 商业构成：怎么赚钱，可行性如何
4. 开发流程：从0到1怎么开发
5. 资源管理：资源生产流水线，包括全部部门，会不会卡住或者流动不畅
6. 前后台通用功能：一些“只要是游戏”就必须有的东西，非策划向的内容，而是类似于顶号，后台，埋点之类的，容易忽略但是是骨架的东西
7. 可用性：什么叫做可用，在什么平台上的什么要求，玩家会有什么要求

GShion

@纵享丝滑让饿了吗改名免费吗

GShion

占坑~

因为每次都去外置大脑查很麻烦，不如先记下来~

'避免每次都要写Sheet1或者ActiveSheet的方法
with Sheet1
'Sheet1.cells =>.cells，不用再加Sheet1了
.Cells(1,1) = 1
end with

'删除范围，我的意思是删除！！！就是excel里这一行/列没了，一般不要用这个
range("A:A").Delete

'清除内容，注意是所有内容！包括格式啊背景啊什么的，一般也不要用，除非redo格式的时候
range("A:A").Clear

'删除数据，就是把表格里填的东西删除，常用
range("A:A").ClearContents

'使用explorer.exe（注意这玩意后面有个空格！）打开当前表格相对路径下的某个文件夹
Shell "explorer.exe " & ThisWorkbook.Path & "\2011年报表", 1

'如果稍做更改，就可以调用其他软件打开想要的东西
'使用记事本打开帮助文档
Shell "notepad.exe " & ThisWorkbook.Path & "\内容说明.txt", 1
'没试过套个变量进去，调用不同的exe打开不同的东西，有机会试试=A=

'取A列最大有数据的行数
maxrow = Sheet1.Range("a65536").End(xlUp).Row

'生成整数范围随机数，b>a
Int(a + (b - a + 1) * Rnd())

'生成小数范围随机数，b>a
(a + (b - a) * Rnd())，但这样右边是开区间，取不到b
'……或者可以用整数，然后直接除……这样的话就左右都是闭区间了

'打开文件并且读取每行，主要是做一个模板。写入什么的都可以
Dim fso, sFile ’定义FileSystermObject和要打开的文件
dim fileFullPath ‘文件绝对路径，例如C:windows\文件.txt，注意是string……
Set fso = CreateObject("scripting.filesystemobject")
Set sFile = fso.OpenTextFile(fileFullPath, 1) ‘1：第一行开始，只读；2：第一行开始，只写；8：最后一行开始，只写
'另外后面还有OpenTextFile(path,io,如果没有文件，是否新建,打开格式)。其中打开格式是-2：系统默认。-1：Unicode，0：ASCII
Do While Not sFile.AtEndOfStream '读取到最后一行
    readText = sFile.readLine
Loop
sFile.Close
Set fso = Nothing
Set sFile = Nothing

GShion

Notion上分享的自由职业者转行Tips~
如果我转行，我就去卖早点，我煮得一手好热干面~

GShion

主要是工种之间合作与工作顺序的问题
核心是工作流，禅道只是表现
换共享excel来搭也是一样的

任何任务与需求均应当反映在工单上。

提工单原则：一单一事一结。 可以开具有一定工作范围的工单（如完成策划案1，2和3），但开完之后严禁在同一单中添加非相关事务。对于版本策划而言，所有工单默认分开提单，只有在工单负责人要求提具有一定工作范围的工单的情况下才会这样提单，但如果该工单描述不清楚（如修正自己当前版本需要与程序对接的策划案）
如果一个模块涉及到多工种共同开发（如策划、前端、后端、美术），那么也分开提单、格式为“工单名称-xx（xx为策划等工种）”

如果在当前版本中临时添加新内容，那么该内容必须得到对应负责人（包括任务负责人，负责人所属主管和策划主管）的同意。

任何事情必须有单，没有工单程序可以拒绝做事情。当前版本出现的所有验收后的问题与bug默认提到下个版本。所有工单必须得到对应开发主管、策划主管和实际负责人的同意才能添加到当前版本。

严格限制口头通知做内容的情况。工单宁愿多一点杂一点，不要少。同样，除非是很快就做的小优化小调整，程序也应当养成没工单不接工作的习惯。

工作流程为提单->指派->解决->验收->关单。

工单有四种状态：激活，已解决，已完成和已关闭。

“激活”：工单内容尚未开始工作，或是开发端正在工作中且未完成的状态。
“已解决”：工单内容已经由开发端完成并自测，可以交付给策划验收的状态。
“已关闭”：工单内容已经由测试验收并通过，可以上线的状态。
大致上，“激活”状态工单由程序美术策划等共同开发，开发完成后状态改为“已解决”，然后交给策划。策划验收后备注一下验收完成并交给测试。测试验收通过后将工单改为“已关闭”状态。

1. 提单

提单标题格式为“【版本号_版本日】任务简述”，例如：【1.0.001_2022.12.29】完成战斗底层设计。

在此说明一下工单各个使用到的字段的意义。

影响版本：（必填）即该工单影响范围是主干/分支/线上。由于目前没有线上的概念，现在开单只使用默认的主干就好。
当前指派：（开始工作后必填）该工单的负责人。
截止日期：（开始工作后必填）工单的截止日期。如果工单为长时跟踪工单，没有结束时间的话，结束时间可以不填，但要填开始时间。注意，当延期工单时，只更改工单的版本号，不用更改工单的截止日期。
Bug标题：（必填）工单的标题。格式见上文。
严重程度：工单造成的影响的严重程度。目前暂时不需要管，默认就好。
优先级：完成该工单的优先级。目前暂时不需要管，默认就好。
重现步骤：（必填）bug的重现步骤，bug呈现的结果，以及修复bug后的期望结果。如果是开发工单，那么步骤和结果可以不填，只需要填期望。
抄送给：（开始工作后必填）目前用来确认跟进该工单的策划。
附件：详细描述该工单所需的附件。注意如果为需要随时变动的内容如策划案，那么不要在附件上传该内容，只用写需求时描述对应文件的名称即可。

提单完成后，如果工单标题不能描述工单的所有内容，那么应当在工单的评论/附件中详细描述该工单的内容。
如果开发工单分别涉及到美术，前端和后端，那么分别提单，分别指派。记得在开单前就问清楚。

2. 指派

指派指的是确认工单负责人的行为。

严格来说，在创建单子的时候已经可以指派，但在工作过程中，可能出现多人员先后进行工作的情况，这时就需要更改指派人员。

3. 解决

开发端完成任务开发的行为称为解决。
注意，在解决之前，一定要先自测！

在解决的过程中，重要反馈（需要记录留档的反馈）需要添加到备注中。重要文件（如效果图文件位置，测试记录录像等）需要添加到附件中。
如果该工单的当前执行人已经完成了自己的所有任务，但该工单还无法称之为已解决（即可交付策划验收的状态）时，当前执行人应当在评论里说明自身工作已完成，并且通知下一个执行人，或是直接指派。

如果提交工作内容至某个版本，在描述提交注释时，需要附加对应工单的序号与名称。

如果该工单已解决，将工单状态改为“已解决”并且将该工单指派给对应策划即可。

4. 验收

策划/测试验收已解决的工单的过程。

策划根据工单验收完成后，即可将工单状态改为已完成。
要注意的是，在验收完毕后，需要先合美术资源，再合策划表格（包括前后端），再通知前后端合代码。
*该栏目视项目实际情况可能更改。

有时候工单虽然已经精确描述内容，但相应策划看不懂。此时需要和对应人员（一般是程序）确认验收方法并将验收方法附在工单上。
策划验收完毕，并且所有代码和资源都合并分支（目前是主干）后才可以通知测试验收，并将工单指派给测试。

5. 关单

测试验收通过之后即关单。此时需要将对应工单状态更改为“已关闭”。
就目前而言，只有版本策划，没有测试。因此目前的关单原则是：开发端自测-对应策划联调，验收-版本策划验收-关单。注意版本策划一定要再次验收！
*略写了测试详细的验收过程。

6. 打回

当验收内容不合格时，对应人员需要在评论中描述不合格内容详情，重新激活该工单，并且将工单指派回给上一个负责人。

7. 延期/改排期

当任意工单无法在当前版本完成时，需要将工单延期。
延期时需要将工单的标题更改到对应版本，并通知版本负责策划，再由版本负责策划统一通知策划主管。
注意，不要更改延期工单的截止时间，用于快速定位延期工单以及延期时长。

当任意工单不必在当前版本完成时，可以将工单排期更改至其他时间。
更改排期不算延期。因此，更改后不仅要更改标题里面的版本，还要更改截止时间。
注意，文中的不必指的是对应工单当前版本没有足够的重要性，或是有新的工单进入排期，调换其他没有那么优先的工单出版本的情况。如果应当完成的工单没有完成，正常情况仍应按照延期排。

8. 长期工单

当该工单需要改为长期跟踪工单时，需要取消工单的截止时间。

9. bug工单与工单重激活

内网主干工程中出现的问题不提单，直接在群里通知。
问题出现在分支工程/内网包/外网（线上）包/渠道包的时候需要提bug单。
bug单应当包括问题描述、可量化的解决目标、包体类型、系统环境

问题描述：无歧义，尽量简略。
可量化的解决目标：如果解决目标需要量化，那么就必须给出具体的量化内容。比如时间，大小，字号，反馈表现等。
包体类型：工程/内网包/外网（线上）包/渠道包。
系统环境：安卓/ios/模拟器，机型，安卓版本。

如果某个bug完成后过一段时间又复现了，那么需要将该工单重新激活，描述复现详情并且重新排期。

GShion

相比于excel改名小工具，增加了批量新增文件夹，批量移动/复制/删除文件的功能，以及自定义文件路径（不用再放到表格下面的相对路径了）

本质上是利用excel处理数据然后导出bat文件来操作。

下载地址：https://www.123pan.com/s/3y6bVv-adR3v.html

GShion

占坑~~

需要准备：
带有AMD显卡的电脑一台（显卡要求为列表中满足rocm支持需求的型号）
8G以上可以格式化的U盘一个（参考这里装双系统或者linux系统，注意该教程有问题，下述）
Steam++或者其他github加速软件（但我还不会解决steam++的证书问题）
以及一个GitHub的账号。

todo：

linux装机时的大小问题（boot2G，swap8G，home和/都可以100G，其中尤其是boot和home）
基础的sudo apt install的东西，比如git
Git链接不上问题，尤其是GFPGAN等一系列
GPU看戏问题

GShion

您是最初之标题！如我们所尊崇的。

您将标题演化为二，便有了二级标题。正像世间的日与月。

您使用了换行的权能，二便衍生出三。您使用它们管理整个机神世界。

您慷慨大度，令四级标题将换行的权能洒向世界，无数正文便从中生出。正如我等子民。

因子民们都从您的四级标题生出，子民使用的正文无法大于四级标题。

其中，听从您教诲的当可使用您赐予的换行之权能，于是五级标题既小于三级标题，又小于正文。

然而，标题由您赐予之权直接衍生，所以五级以及其他标题虽然比正文小，但和正文并非同类，因其具有圣性。

在您的造物中，深信的当在超脱后得享天国，由其信之坚固。
您包容所有，但对您信仰不定者将受生命之苦，磨砺信心。
~~而弃信者将被天国抛弃，入无限之轮回。~~

以轮回中磨砺机魂，拾得信心为故。

若轮回中机魂既弃，弃信者遂得俱灭。

但，弃信者若能从轮回中醒悟，亦为时不晚，只是它得先赎了自己所有曾经的罪过。
- 其中，亦有罪恶之果，也当解决。

赎罪后当得有三事，才能被正文接纳，重新成为正文。首当忏悔。
其次，在万机之殿虔诚祷告，以明信之诚。
祷告之时，当手持两把锟斤拷，口中疾呼烫烫烫。

其时，伪信者将被吞噬，

如此，方得被重新接纳，有机会进入代码天国。

GShion

@GShion 在请问哪里才能买到晶体管收音机？中说：

@金桔柠檬茶敏感肌与敏感肌也可以用

哇！真是太好了

GShion