时间片的优化有两个思路。
提升单位时间的收益其实就是提升时薪（但并不一定局限于按时薪支付的副业，其他形式可以折算成时薪），有几个简单的思路。
「切换地域」就是说，我们同样是干活，但如果服务对象所在的位置不同的话，单位时间的收益也是不同的。
比如你在重庆，给本地公司去做一些外包，那整个项目的基础价格就是参照当地程序员的人工成本来进行比价的。但如果是在重庆可以给北京的公司做外包，那发包方就会更多地参照北京的各种成本来进行相应的股价，这样我们就可以把自己单位时间的收益提升上去。当然，需要考虑沟通的效率和成本。
把这个思路扩大一点，就变成在国内做国外的业务了。
因为和国内相比，国外的人力成本通常会贵很多，如果你在二三线城市，那么成本又更低。这样就出现了一个价格差，如果能控制好这个价格差，我们就能挣到更多的钱。
当然前边也说过，这里边有竞争和外语沟通的问题，需要根据自己的实际情况来选择。
在没有建立起自己的知名度之前，非常单纯地去做外包，面对的往往是价格战的红海。地球那么大，总有人的时间比你不值钱。
而且外包它是一个开放性的需求，如果真要把很多雇主的需求细细做好的话，对技术栈的广度要求还挺高的。因为每一个项目它要求的技术栈可能不一样。项目做的越多，用到的偏门技术就可能越多。
所以我们要想办法解决竞争的问题。细分市场就是一个很好的思路，比如说我们可以给一些标准化的开源产品做二次开发来挣钱。
这其实不是什么特别新的思路，早在个人站长时代就有人专门给 Discuz！这个开源论坛软件写插件和定制功能挣钱,而且还真养活了不少小公司。
现在我们可以把这个思路更扩展开一些，比如说我们把从「支持国内项目」变成「支持国际知名的项目」。
这样的话，我们就能解决掉出海接活面临的大部分起步问题。
你看：
- 我们从什么地方来获得客户？直接从开源社区获取客户。
- 如何证明我们的开发能力？ 可以写一些高质量的开源插件，给大家免费使用，并作为我们的demo。
- 如何来获取比较高的收益？专门给一个项目写插件的团队并不是太多，选择够好的话，就可以成为这个细分领域的No.1，获得一些品牌上的溢价。
提升单位时间的效率对于按工作量支付的副业来说特别重要。
比如说我们现在有一个项目，交付后的收益是10万块钱。以原来的方式完成它，可能需要花100个小时。现在我们想到了一种新办法，把效率提升了10倍，那么原来100个小时才能完成的活，现在10个小时就能做完了，这就是效率的提升。
多出来的90个小时我们可以用到其他项目上，哪怕是用来休息，也是很好的。
当然，通过增强意志力来强迫自己去提升生产效率，其实是很难奏效的。
因为我们本来就是在利用工作之余的时间。在这个时间上，很难保证精力非常充沛。别说提升工作效率，能保证在做这些事情的时候尽可能的不被干扰，不让自己的生产效率降下去，已经是非常不错了。
但是非常幸运的是，我们是程序员。我们从事的工作，它本身就有一部分是由机器来完成的，所以我们可以引入自动化来提升效率。机器是使用电来工作，它的效率提升空间是非常大的，而且它也不需要休息，可以7×24小时地进行工作。
对于程序员的日常工作来说，最主要的自动化方式就是代码生成器。
但一说到代码生成器，就会听到很多反对声音。如果你用过一些比较早期的代码生成器产品，很可能你也会会有一些负面印象。
在大概十多年前吧，我当时所在的公司也就购买了一套代码生成工具。根据说明书，配置好业务逻辑，然后就可以同时生成ASP、PHP和JSP的代码。
公司买来以后就强制性行推广，但在硬推了两个月以后，发现推不动，只好放弃了。
最主要的原因是因为它没有办法处理我们特有的一些逻辑，加上每一个部门有自己独立的规范和周边库，在那个工具里边没法用上。之后很长的时间里，我们整个部门的人都对代码生成器非常反感。
但是后来还是经不住偷懒的诱惑，我自己一直在偷偷地不断尝试。渐渐地发现，其实要做一套全世界通用的代码生成系统可能会特别难；但是如果只是给自己做一个专用的代码生成工具却非常简单，只要遵循以下两个原则。
第一个原则是「只为自己设计」。
因为每一个公司，每一个部门甚至每一个岗位它所面临的需求是千差万别的，很难通过一个通用工具来解决，所以我们也很难买到为自己量身定制的工具。
但如果自己来开发工具的话，就完全不同了。我们可以完全按照自己的工作流程、按照每天写代码的需求来进行设计。我们非常清楚写代码的时候，元数据是存放到什么地方的、通过什么样的方式进行加工、以及最终要生成怎样的代码。所以可以开发出非常好用的自用代码生成工具。
第二个原则是「能自动化的自动化，不能自动化的半自动化」，后半句特别重要。
很多程序员在设计代码生成工具的时候，往往太过完美主义，老想着要做一个系统把所有的工作都做完，最好点一下按钮后，什么事情都不用去做了。
这当然是最理想的方式，但是我们的开发环境和其他的办公软件之间不一定存在交互接口，很多软件只有图形界面，不支持通过 API 进行数据交换。所以，很多时候我们就没法做成全自动。完美主义或者叫强迫症的同学就会说，既然这个东西不能完全自动化，那就直接手动来处理吧。
但我们开发代码生成器的根本目标并不是要做一个完整的自动化产品，而是要提升我们的生产效率。所以，即使有一些地方不能做到完全的自动化，我们也可以把它做成半自动化。
半自动化有两个思路。第一个思路是，我们可以通过交互方式来解决一些不能自动化，或者需要花很多时间去处理的细节问题。
举一个例子，这个例子发生的年代比较久远，现在可能已经不适用了。
我们当初在做网站的时候，有很多的资料都是编辑给的。那个年代还没有产品经理，都是由网站编辑给我们资料。他们都使用 office 软件来存放数据。
当时是没有比较好的 office 格式解析包的，所以很多同学都放弃了数据的解析，改为手工输入。我给了一个解决方案，就是直接在 office 里复制数据表格，然后再粘贴到一个 textarea 里，最后用 PHP 分析 tab 和换行符号，把数据分离出来。为了防止分析错误，还做了一个界面来进行确认和手动修正。虽然没能实现全自动，但是比起手工输入数据，这个方案效率的提升是几十倍的。所以不要过分纠结于全自动化，有的解决方案不完美，但也可以很精彩。
另外一个思路是，只对小操作做自动化，用来生成代码片段。比如说，我们在写输入处理的时候，往往需要根据数据表字段来对输入进行验证，这往往是一个重复劳动。所以，我就写了一个命令行的小工具，它可以直接读取数据表里边的字段和对应的注释，根据注释里的标记来判断对应的字段的验证信息，最后会自动生成验证部分的代码。我把这些代码粘贴到编辑器后，再进行相应的修改，就可以很快的完成验证工作。这没有什么技术含量，但是它可以切实提高我们的生产效率。
这些只是我想到的思路，当然还有很多其他的。比如有的同学是通过工具链，通过命令行交互，来实现自动化。
代码模板呢，只能解决相对比较死板的规则。但最近随着人工智能的进步，在某些特定的场景下，原来很多低效率的人工操作其实可以交给 AI 了。
现在，AI 的正确率确实达不到和人类同等水平。但是，还是前边那句话，「不能完全自动化的，可以考虑做成半自动化」。针对 AI 正确率不高的场景，我们可以通过人机结合的方式来处理。
比如说，我们要进行图片分类，之前可能需要花上十几个小时的人工。现在使用 AI 进行分类，只需要十几秒。但是它可能有20%的图片分类是错的。
我们就可以先让 AI 来进行分类，然后再人工确认一遍。确认花的时间可能是两个小时，但即使这样，比起之前的十个小时来讲，效率也提升到了五倍。
最近很多人工智能接口的品质已经不错了。比如说，熟悉我微博的同学都知道，我经常会用语音的合成和识别服务来提升内容生产效率。
比如我经常会发一些技术视频，但是又不想自己录音，于是就会使用人工智能来生成语音。而大家正在看的这本书里，至少有一半的内容我是通过语音识别APP，以每分钟100多字的速度记录下来，然后再二次进行修改、校正完成的。
所以不管你对 AI 有什么看法，它现在已经在实实在在地改变着我们的生活。我们要思考的是，如何更好地利用它。
如果服务足够可靠，我们就可以做成自动化服务，直接提供给最终用户；如果服务还不够可靠，我们可以把它放到中间流程里来提升效率。
比如，同样是代码生成技术，如果我们把它做成面向不懂技术的人群的产品，服务不是很可靠的话，最终效果就会很惨；但同样品质的接口，如果我们把它做成面向开发者的服务，而且是在编辑器里面实时地进行代码补全和建议的工具，它就会显得非常好用，可以极大地提升生产效率。