程序员想做副业先学会偷懒程序员这个群体聊起副业画风一般都很两极。一边是“接私活接到凌晨三点改需求改到怀疑人生”另一边是“副业月入过万主业还准点下班”。差别到底在哪我观察了很久发现多数副业做得痛苦的人问题不在技术不够硬而是太勤快了——勤快到把副业当成了第二份全职工作什么需求都自己扛什么流程都手动来硬生生把八小时外的时间全填满。而那些副业做得轻松的人脑子里装的全是“这事能不能自动化”“这需求能不能用现成的改一改”“这钱该不该赚、要不要拒绝”。说白了就是学会了偷懒。这里的“偷懒”可不是指打马虎眼、糊弄客户而是程序员的最高生产力把重复的事交给机器把复杂的事抽成模块把边界外的事干脆推掉。编程这行本来就是一门关于偷懒的学问。写代码是为了什么本质上是让人不必重复劳动。你自己做副业的时候不先偷自己的懒反而见一个需求就吭哧吭哧从头开始撸那不是勤奋那是自我消耗。这篇文章就聊聊我自己的体会程序员做副业到底应该怎么“偷懒”以及这套偷懒逻辑背后怎么拆、怎么落地、有哪些坑。适合那些想搞副业、正在搞副业、或者搞过副业却搞出一身疲惫的人。如果你是那种“宁可多写两行代码也不愿多陪家人一小时”的人可能更该看看。1. 副业的第一生产力不是技术而是目标感1.1 为什么有人副业越做越累有人越做越清闲先看一个常见场景。同样是接一个做官网的小单子A的做法是打开编译器新建项目从头写前端、调接口、配部署一套流程走下来至少三个晚上搭进去。B的做法是先问清楚客户要几个页面、有没有特殊功能然后翻出自己的模板库挑一套接近的改改文案、换个图、调一下颜色半天交付剩下时间用来跟客户打磨细节、收尾款。A和B的技术水平可能差不多但A是“用体力换钱”B是“用经验换钱”。A觉得副业累是因为他每次都在重复造轮子B觉得副业还挺轻松是因为他把每一次重复劳动都变成了下一次可以复用的资产。副业做得好不好第一层分水岭就在这你有没有一个明确的“偷懒清单”。这个清单不是任务清单而是反问自己三件事这个需求里面哪些步骤是我重复做过很多次的这些重复步骤里有哪些是可以用工具、脚本、模板来代替的哪些事情看起来是赚钱机会但其实是纯消耗我能不能直接不接很多人做副业从来没想过这三问看到需求就冲上去写代码结果越做越累最后还会得出一个错误的结论“副业不适合程序员太辛苦了。”1.2 先给副业定“品类”你是卖时间还是卖资产副业里的“偷懒空间”很大程度上取决于你的副业处于哪个品类。我习惯把程序员副业分成三类外包类接私活、做定制网站、写小程序、做爬虫、帮人调Bug。这一类本质是卖时间天花板低但启动快、来钱直接。产品类做开源项目、做小工具、做模板、写电子书、做SaaS。这一类前期投入大前期看不见钱但一旦跑通收益不依赖你个人的时间具备了“睡后收入”的雏形。流量类写博客、录视频、写技术专栏、做付费社群。这类短期变现弱但到后期它既能为前两类引流也能形成个人品牌壁垒。在“偷懒优先”的原则下重量级的建议是副业结构里一定要有“产品类”和“流量类”的资产沉淀不能全押在“外包类”上。否则你所谓的副业只是把八小时外的时间再卖给另一个老板而已。但现实是大多数程序员做副业第一步就是奔着外包去然后因为外包太累草草收场。我自己也经历过这个阶段。后面慢慢醒悟过来不是外包不能做而是你不能只做外包。接外包的同时你得偷懒地积累自己的东西——哪怕只是把一个通用登录页做成模板哪怕只是整理一套自己的部署清单这些都是在把“卖出去的时间”部分沉淀成“属于你的资产”。2. 偷懒第一步把重复劳动全面自动化2.1 判断哪些活值得自动化重复三次原则“偷懒”不是所有事都想着自动化那样反而会陷入过度工程的坑。我自己有个很朴素的标准叫“重复三次原则”一件事如果我在一周内手动做了三次我就必须想办法把它脚本化或者工具化。如果只是偶尔一次两次那我宁愿继续手动作因为自动化本身也有成本。举个例子。以前接爬虫类的私活时最烦的不是写爬虫本身而是调试过程中反复修改选择器、反复登录、反复验证验证码。Playwright这类自动化工具就帮了大忙。我最初用Playwright是接手一个需要模拟用户操作的数据采集项目。当时需求是每天去一个后台管理系统里用固定账号登录逐个点击菜单把某个报表页面的数据导出。客户给的价格不高但要求连续跑一个月。如果天天手动操作一次要十五分钟一个月就是七个多小时纯重复劳动而且很容易点错。于是我用Playwright写了一个脚本核心逻辑特别简单打开浏览器用Playwright的API输入账号密码定位登录按钮点击。等页面加载完用page.locator定位菜单项逐个点击。定位报表表格等待出现特定文本后提取数据并保存到CSV。设置异常重试如果某一步超时或找不到元素自动截图并重试三次三次失败后发一条通知到微信。这里最花时间的其实是“元素定位”。后台系统烂得很很多按钮没有稳定的id只能靠文本或CSS路径定位。我当时的做法是优先用文本定位await page.get_by_text(数据报表).click()这种写法虽然不够“工程严谨”但在对付老旧后台时往往比绞尽脑汁找稳定class更可靠。当然前提是页面上没有重复文本否则定位会撞车。脚本跑通之后那一个月我再也没碰过那个后台。客户那边每天准点收到数据文件我这边完全解放。这才叫“偷懒”偷到了点子上。2.2 给自动化脚本加“容错保险丝”用Playwright这类自动化工具有个绕不开的问题前端页面说改就改今天定位还好的元素明天 class 一变脚本就崩了。崩掉不可怕可怕的是你第二天没注意到它崩了导致数据漏了一天客户直接来找你。所以凡是跑生产环境的自动化脚本我都强制要求三件事异常捕获必须截图。不管是超时还是元素找不到先把当时的页面状态截下来排查时能省一半时间。必须有通知机制。脚本挂了要第一时间发消息提醒而不是等客户来投诉。用企业微信机器人或者Server酱都行几行代码的事。数据落盘必须带日期。哪怕今天跑挂了昨天的数据文件还在不至于全盘皆输。这三条是我踩过坑以后总结出来的。有一次就是没有通知机制脚本前一天晚上崩了第二天客户问为什么没数据我才发现。从那以后任何自动化脚本通知机制都是标配。2.3 定期巡检“自动化资产”自动化脚本跑起来之后别以为就一劳永逸了。外部页面改版是常态脚本的生命周期通常比你想的短。我自己的习惯是接的自动化类项目交付后第一周每天都瞄一眼运行日志第二周开始隔天看一次一个月后如果稳定就改为每周检查一次。检查频率和时间成本本身也要纳入你的“偷懒成本”里。如果一个自动化项目需要你天天盯运维那它反而占用了你更多时间已经违背了偷懒的初衷。所以接这类需求的时候我会直接在报价里包含第一季度的维护费用并且在合同里写明超出约定范围的需求变更需要重新议价。这不是算计而是给“偷懒”上保险。自动化解放出的时间如果又被无常的维护吞噬掉那这个副业就又在卖时间了。3. 偷懒的底层能力模块化思维胜过加班文化3.1 用“函数复用”的思路重构副业的交付方式程序员平时写代码讲究高内聚低耦合一个函数只干一件事多处调用。副业其实一模一样。我以前接单时容易累最大的原因是什么是因为我每次都把项目当成一个全新项目从零开始搭结构。后来我学会一个“偷懒”的姿势建一个属于自己的“私活脚手架仓库”。这个仓库里有什么说白了就是把那些重复出现的需求片段沉淀成模块用户登录模块包含标准登录页、JWT鉴权、手机号验证码登录、第三方GitHub/微信登录的demo。后台管理基础框架使用Vue或React搭好的布局包含侧边栏菜单、顶部导航、权限路由、暗黑模式切换。通用抓取脚本模板封装了Playwright的启动、登录、元素等待、截图、失败重试等基础动作。部署一键脚本包括Nginx配置模板、HTTPS证书申请命令、Docker Compose的编排文件。支付接入示例微信支付和支付宝支付的沙箱环境demo以及回调验签代码。有了这个仓库之后再来一个单子我的流程变成了看客户需求心里先过一遍这个需求涉及哪些模块从脚手架仓库里把对应模块拷贝出来。改改接口字段替换UI细节部署上线。听起来是不是很轻松实际上就是这么轻松。但前提是你得前期花时间把仓库养起来。很多人不愿意做前期投入觉得“这单客户又没给这个钱我干嘛花时间整理”结果就是每一次都在重复“从零开始”。等单子接多了反而每次都手忙脚乱。副业的偷懒其实是用前面几次的“不偷懒”换取后面无数次的“不费劲”。这个账要算清楚。3.2 class的用法类比模板和复用是副业的基本盘顺带说一个在Python里特别基础但特别核心的概念——class。因为很多程序员副业接触Python都是从写脚本开始的写习惯了函数式脚本之后一看到class就犯怵觉得没必要。但如果你做副业到了模块复用这个阶段class就是自然不过的进阶选择。一个最简单的例子封装一个配置读取类。import json from pathlib import Path class ConfigLoader: 配置加载器负责读取、校验、存取项目配置 def __init__(self, config_path: str config.json): self.config_path config_path self._data self._load() def _load(self): if not Path(self.config_path).exists(): raise FileNotFoundError(f配置文件不存在: {self.config_path}) with open(self.config_path, r, encodingutf-8) as f: return json.load(f) def get(self, key, defaultNone): return self._data.get(key, default) def set(self, key, value): self._data[key] value self._save() def _save(self): with open(self.config_path, w, encodingutf-8) as f: json.dump(self._data, f, ensure_asciiFalse, indent2)为什么要封装成class而不是写一堆函数原因很简单配置加载这个动作在爬虫脚本、自动化脚本、Web服务里都会用到。封装成类以后每次只需要cfg ConfigLoader(config.json) token cfg.get(auth_token)一处定义多处使用改配置逻辑只改一个地方。这种思维一旦形成你的副业代码就不再是一堆粘在一起的面条而是可以像积木一样搭来搭去的模块。其实class的核心价值跟副业中“模板拼装”的思路完全一致把状态和行为绑定在一起然后四处复用。你要是理解了这一点不就等于理解了“为什么有人做副业能同时并行三四个项目而你只做一个就喘不过气”。3.3 拒绝需求的技术把“好的”换成“我看看如何做更省力的方案”模块化和自动化解决的是“怎么做”的问题但副业里另一个偷懒大法是怎么去选“做什么”。程序员普遍脸皮薄客户说什么就答应什么。有一次一个朋友通过熟人找我说要做一个“简单”的问卷调查系统对方说得很轻松——“就几个页面很简单”。如果按照客户的原话去做这个项目确实不复杂但客户嘴里的“简单”通常只是表象。聊完才知道他想要的是带在线支付、多人协作、自动报表以及一套能对接微信公众号的会员体系。这种需求如果真的全盘照做后面就是无底洞。后来我学乖了遇到需求第一反应不是回答“好的”而是回答“我先理一下需求看看怎么做对你来说最省心”。然后把需求拆成“必做”和“可选”先做一个能用的最小版本再问客户要不要一步步加功能每加一个功能对应一份明确的报价和工期。这套“拒绝术”的关键不是直接拒绝而是把模糊需求转成明确边界。客户不一定抠门但他一定害怕被坑。你越是把需求理得清楚客户越信任你你后面的返工也越少这是双赢的偷懒。4. 偷懒的终极武器让代码和工具替你上班4.1 从Copilot到AI工具为什么程序员该“拥抱AI”而不是抗拒最近有个话题聊得挺热“为什么程序员大多都拥抱AI而音乐人却抗拒并隔离AI音乐池”我个人觉得这里面有个本质差别——程序员的日常工作中有大量的重复性劳动比如写模板代码、补测试用例、写正则、查文档这些活靠手动做既耗时间又没有乐趣。AI刚好把这类活接过去了程序员自然欢迎。音乐人抗拒AI音乐是因为AI直接威胁到了他们的最终创作产品本身。但程序员面对AI时焦虑程度没有音乐人那么高因为AI写出来的代码最后还得由人来审查、整合、维护、负责。AI是放大程序员偷懒能力的最佳工具。在我自己的副业流程里AI工具已经是标配GitHub Copilot写脚手架代码时按Tab就能补齐大段样板省去了大量敲键盘的时间。ChatGPT / Claude遇到不熟悉的库、看不懂的报错信息直接贴上去问比翻官方文档效率高得多。AI做需求分析把客户的原话粘进去让AI先输出一版需求理解、功能清单、排期估计我再人工调整。有朋友问我说AI生成代码质量不行是不是不能用。我的态度是AI生成的是初稿不是成品。你用它来偷懒偷的是“从空文档开始写第一行”的懒而不是跳过思考步骤的懒。你把AI当实习生写得不好你纠正它效率就能拉满你把AI当大神觉得它写啥直接用那翻车也正常。4.2 用AI工具快速定位页面元素Playwright的别样思路回到爬虫和自动化这个话题。很多人在写Playwright脚本时最头疼的就是元素定位。经常是看了网页源码好不容易找到一段长长得像天书的class结果运行起来一个反爬逻辑或者异步加载就能把一切搞崩。我在用AI辅助定位时有一个很顺手的流程把网页源码复制给AI然后描述“我想点击那个在右上角的‘重新登录’按钮帮我写出定位表达式”。AI很快会给我几个候选方案我再从中挑一个最稳定的放到脚本里。但这里有个细节必须提AI给的选择器不一定都可靠。尤其当页面里含有动态class属性时如classbtn-abc123这类哈希类名直接按class定位很容易挂。比较可靠的还是按角色、文本、或者相对位置定位# 按按钮文本定位 await page.get_by_role(button, name提交订单).click() # 按输入框占位文本定位 await page.get_by_placeholder(请输入手机号).fill(13800138000)这种写法不依赖class名只要页面文案不变就能稳定运行。这也是我在无数次定位失败后总结出来的优先定位用户可见的东西而不是程序员可见的class。用户可见的文本是给真实用户看的改动频率远低于内部代码样式类用在自动化场景里更皮实。4.3 交付环节的偷懒方法一键部署比什么手艺都值钱副业项目做到交付阶段很多程序员的痛点是代码写完了部署却要折腾人。买服务器、配Nginx、申请HTTPS证书、设置定时任务、处理日志轮转……这一套手动下来一两个小时就没了。如果你同时维护几个客户项目那每次部署都像过关。所以我很早就把自己的部署流程全部“脚本化”核心工具就是Docker Compose加一堆Shell脚本。比如一个典型的前后端分离项目我只需要在服务器上放一个docker-compose.yml内容大概长这样version: 3.8 services: frontend: image: nginx:alpine ports: - 80:80 - 443:443 volumes: - ./dist:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/conf.d/default.conf restart: always backend: build: ./backend ports: - 8080:8080 environment: - DB_CONNECTION${DB_CONNECTION} restart: always然后一个deploy.sh#!/bin/bash # 一键部署脚本本地构建前端后推送到服务器执行 set -e echo 1/5 构建前端 cd frontend npm run build cd .. echo 2/5 上传代码 scp -r backend dist docker-compose.yml userserver:/opt/my-project/ echo 3/5 重启服务 ssh userserver cd /opt/my-project docker compose up -d --build echo 4/5 清理过期镜像 ssh userserver docker image prune -f echo 部署完成部署一次的时间从一两个小时压缩到两分钟。而且因为是模板化的越用越熟练后面基本是复制粘贴改改项目名。这种偷懒方式才是真正把副业做成了长期生意而不是短期力气活。5. 偷懒式副业避坑指南哪些懒不能偷哪些活必须亲自干5.1 不能偷懒的硬性环节“偷懒”不是所有事都简化有些环节是必须亲力亲为、不能省流程的否则后患无穷。需求确认书必须写下来。口头聊得再清楚也要变成一份文字版需求清单发给客户确认。否则后期客户改口你连凭据都没有。这份清单本质上就是替你省去后期扯皮的麻烦它才是最大的偷懒。代码里的敏感信息必须脱敏。用脚本加密或者放到环境变量里绝不硬编码在代码中。出了泄露事故你偷的懒会直接变成事故。备份不能省。数据库、服务端的配置、自动化脚本统统要有备份。我吃过亏替客户部署的一个应用服务器到期后忘记迁移数据客户几年的内容直接没了。这种懒偷一次就够你后悔一辈子。合同或电子协议的雏形要有。哪怕只写清楚交付范围、维护期限、费用结算方式。没有边界的关系注定是被需求拖死的关系。有句话说得好偷懒要偷在流程里的重复环节而不是砍掉流程里的安全环节。这两者的界限决定了副业是越做越香还是越做越烂。5.2 常见问题与排查技巧副业做久了总会遇到各种幺蛾子。挑几个我碰到过、并且大概率你们也会碰到的问题统一整理出来问题一自动化脚本今天还能跑明天就报错“找不到元素”原因页面改版了。前端代码动了一下class或重构了DOM结构之前的选择器就完全失效了。排查思路先看脚本保存的截图确认页面实际形态再用开发者工具重新定位元素最后改为更稳定的定位方式比如按文本定位、按角色get_by_role或者加一个备用选择器。问题二客户需求越做越多项目永远“差一点完成”原因前期没有明确需求边界导致客户每次都有新的“小想法”。排查思路翻出最初的需求确认书和客户逐条对齐哪些是原范围哪些是新需求。明确告诉客户新增内容需要重新评估工期和报价。心软是最贵的成本。问题三部署到服务器后页面白屏控制台报API请求404原因前后端分离项目前端静态资源部署路径与后端API路径不一致比如后端挂在/api前缀前端却请求根路径。排查思路把前端请求地址改成后端实际前缀或者通过Nginxlocation /api/ { proxy_pass http://backend:8080; }做反向代理转发。问题四脚本在本地跑得好好的在服务器上就报编码错误原因服务器上文件读取编码和本地不一致比如Windows本地默认GBK服务器上是UTF-8。排查思路打开文件时明确指定编码open(file, r, encodingutf-8)一劳永逸。5.3 副业接单价格与服务范围的“偷懒定价法”定价这一块也完全可以“偷懒”。我的原则只有一条不做无差别的比价只按成本定价。成本包括三块时间成本预计投入的开发和调试时间折算成时薪。程序员时薪别按上班工资算要按你想达到的副业目标算。维护成本上线之后未来三个月预计要花的维护时间。沟通成本这个客户的需求是否清晰、是否好沟通。不好沟通的客户报价直接上浮30%-50%他是来买你的心力损耗。算完成本按“总成本乘以1.5到2”作为报价。一方面留出议价空间一方面也避免接下亏本单。还有一个经验贵一点的单客户往往更珍惜你的时间。报价太低客户会下意识觉得你时间不值钱于是什么小需求都找你。报价只要在合理范围内偏高一点反而能让双方保持边界感。要让客户知道你的时间是能被明确计价的他自然会收敛需求。5.4 心态层面的偷懒允许自己拒绝也允许自己休息最后这一点我想认真聊聊。副业本身是为了让生活更好但好多程序员做着做着就把副业做成了另一个“996”。晚上下班吃完饭坐到电脑前就开始写周末也不休息连陪家人都在想着那个Bug怎么解决。这不是努力这是透支。我自己也经历过这个阶段那时候白天上班晚上做外包周末继续扛。那段时间是我技术水平增长最快的时期但也是身体和精神状态最差的时期。后来我做了个决定每周至少留一天完全不碰副业手机开启免打扰让自己像一个正常人一样生活。神奇的是当我允许自己休息之后工作效率并没有下降反而提高了。因为脑子放松了再回来写代码的思路会更清晰过去卡壳的问题有时反而能迎刃而解。偷懒不是逃避责任而是优化系统。程序员写代码的时候知道要找性能瓶颈、要防过载你自己的时间安排为什么就不肯做同样的优化呢把自己当成一台长期运行的服务器副业是上面跑的一个服务如果你不给这台服务器留余量它早晚要宕机。学会偷懒是程序员做副业最重要的一门功课。把重复的交给代码把琐碎的交给工具把复杂的拆成模块把不该接的需求挡在门外——当你真正做到这些你才有精力去思考那些真正值得思考的事下一个副业方向是什么你的个人品牌怎么积累你未来三年想走到哪一步。这才是副业真正的意义它不该是一份压垮你的第二职业而应该是一个帮你探索自由、放大能力的练习场。省下来的时间才是你最终赚到的东西。 程序员副业偷懒指南：自动化与模块化让你轻松赚钱
程序员想做副业先学会偷懒程序员这个群体聊起副业画风一般都很两极。一边是“接私活接到凌晨三点改需求改到怀疑人生”另一边是“副业月入过万主业还准点下班”。差别到底在哪我观察了很久发现多数副业做得痛苦的人问题不在技术不够硬而是太勤快了——勤快到把副业当成了第二份全职工作什么需求都自己扛什么流程都手动来硬生生把八小时外的时间全填满。而那些副业做得轻松的人脑子里装的全是“这事能不能自动化”“这需求能不能用现成的改一改”“这钱该不该赚、要不要拒绝”。说白了就是学会了偷懒。这里的“偷懒”可不是指打马虎眼、糊弄客户而是程序员的最高生产力把重复的事交给机器把复杂的事抽成模块把边界外的事干脆推掉。编程这行本来就是一门关于偷懒的学问。写代码是为了什么本质上是让人不必重复劳动。你自己做副业的时候不先偷自己的懒反而见一个需求就吭哧吭哧从头开始撸那不是勤奋那是自我消耗。这篇文章就聊聊我自己的体会程序员做副业到底应该怎么“偷懒”以及这套偷懒逻辑背后怎么拆、怎么落地、有哪些坑。适合那些想搞副业、正在搞副业、或者搞过副业却搞出一身疲惫的人。如果你是那种“宁可多写两行代码也不愿多陪家人一小时”的人可能更该看看。1. 副业的第一生产力不是技术而是目标感1.1 为什么有人副业越做越累有人越做越清闲先看一个常见场景。同样是接一个做官网的小单子A的做法是打开编译器新建项目从头写前端、调接口、配部署一套流程走下来至少三个晚上搭进去。B的做法是先问清楚客户要几个页面、有没有特殊功能然后翻出自己的模板库挑一套接近的改改文案、换个图、调一下颜色半天交付剩下时间用来跟客户打磨细节、收尾款。A和B的技术水平可能差不多但A是“用体力换钱”B是“用经验换钱”。A觉得副业累是因为他每次都在重复造轮子B觉得副业还挺轻松是因为他把每一次重复劳动都变成了下一次可以复用的资产。副业做得好不好第一层分水岭就在这你有没有一个明确的“偷懒清单”。这个清单不是任务清单而是反问自己三件事这个需求里面哪些步骤是我重复做过很多次的这些重复步骤里有哪些是可以用工具、脚本、模板来代替的哪些事情看起来是赚钱机会但其实是纯消耗我能不能直接不接很多人做副业从来没想过这三问看到需求就冲上去写代码结果越做越累最后还会得出一个错误的结论“副业不适合程序员太辛苦了。”1.2 先给副业定“品类”你是卖时间还是卖资产副业里的“偷懒空间”很大程度上取决于你的副业处于哪个品类。我习惯把程序员副业分成三类外包类接私活、做定制网站、写小程序、做爬虫、帮人调Bug。这一类本质是卖时间天花板低但启动快、来钱直接。产品类做开源项目、做小工具、做模板、写电子书、做SaaS。这一类前期投入大前期看不见钱但一旦跑通收益不依赖你个人的时间具备了“睡后收入”的雏形。流量类写博客、录视频、写技术专栏、做付费社群。这类短期变现弱但到后期它既能为前两类引流也能形成个人品牌壁垒。在“偷懒优先”的原则下重量级的建议是副业结构里一定要有“产品类”和“流量类”的资产沉淀不能全押在“外包类”上。否则你所谓的副业只是把八小时外的时间再卖给另一个老板而已。但现实是大多数程序员做副业第一步就是奔着外包去然后因为外包太累草草收场。我自己也经历过这个阶段。后面慢慢醒悟过来不是外包不能做而是你不能只做外包。接外包的同时你得偷懒地积累自己的东西——哪怕只是把一个通用登录页做成模板哪怕只是整理一套自己的部署清单这些都是在把“卖出去的时间”部分沉淀成“属于你的资产”。2. 偷懒第一步把重复劳动全面自动化2.1 判断哪些活值得自动化重复三次原则“偷懒”不是所有事都想着自动化那样反而会陷入过度工程的坑。我自己有个很朴素的标准叫“重复三次原则”一件事如果我在一周内手动做了三次我就必须想办法把它脚本化或者工具化。如果只是偶尔一次两次那我宁愿继续手动作因为自动化本身也有成本。举个例子。以前接爬虫类的私活时最烦的不是写爬虫本身而是调试过程中反复修改选择器、反复登录、反复验证验证码。Playwright这类自动化工具就帮了大忙。我最初用Playwright是接手一个需要模拟用户操作的数据采集项目。当时需求是每天去一个后台管理系统里用固定账号登录逐个点击菜单把某个报表页面的数据导出。客户给的价格不高但要求连续跑一个月。如果天天手动操作一次要十五分钟一个月就是七个多小时纯重复劳动而且很容易点错。于是我用Playwright写了一个脚本核心逻辑特别简单打开浏览器用Playwright的API输入账号密码定位登录按钮点击。等页面加载完用page.locator定位菜单项逐个点击。定位报表表格等待出现特定文本后提取数据并保存到CSV。设置异常重试如果某一步超时或找不到元素自动截图并重试三次三次失败后发一条通知到微信。这里最花时间的其实是“元素定位”。后台系统烂得很很多按钮没有稳定的id只能靠文本或CSS路径定位。我当时的做法是优先用文本定位await page.get_by_text(数据报表).click()这种写法虽然不够“工程严谨”但在对付老旧后台时往往比绞尽脑汁找稳定class更可靠。当然前提是页面上没有重复文本否则定位会撞车。脚本跑通之后那一个月我再也没碰过那个后台。客户那边每天准点收到数据文件我这边完全解放。这才叫“偷懒”偷到了点子上。2.2 给自动化脚本加“容错保险丝”用Playwright这类自动化工具有个绕不开的问题前端页面说改就改今天定位还好的元素明天 class 一变脚本就崩了。崩掉不可怕可怕的是你第二天没注意到它崩了导致数据漏了一天客户直接来找你。所以凡是跑生产环境的自动化脚本我都强制要求三件事异常捕获必须截图。不管是超时还是元素找不到先把当时的页面状态截下来排查时能省一半时间。必须有通知机制。脚本挂了要第一时间发消息提醒而不是等客户来投诉。用企业微信机器人或者Server酱都行几行代码的事。数据落盘必须带日期。哪怕今天跑挂了昨天的数据文件还在不至于全盘皆输。这三条是我踩过坑以后总结出来的。有一次就是没有通知机制脚本前一天晚上崩了第二天客户问为什么没数据我才发现。从那以后任何自动化脚本通知机制都是标配。2.3 定期巡检“自动化资产”自动化脚本跑起来之后别以为就一劳永逸了。外部页面改版是常态脚本的生命周期通常比你想的短。我自己的习惯是接的自动化类项目交付后第一周每天都瞄一眼运行日志第二周开始隔天看一次一个月后如果稳定就改为每周检查一次。检查频率和时间成本本身也要纳入你的“偷懒成本”里。如果一个自动化项目需要你天天盯运维那它反而占用了你更多时间已经违背了偷懒的初衷。所以接这类需求的时候我会直接在报价里包含第一季度的维护费用并且在合同里写明超出约定范围的需求变更需要重新议价。这不是算计而是给“偷懒”上保险。自动化解放出的时间如果又被无常的维护吞噬掉那这个副业就又在卖时间了。3. 偷懒的底层能力模块化思维胜过加班文化3.1 用“函数复用”的思路重构副业的交付方式程序员平时写代码讲究高内聚低耦合一个函数只干一件事多处调用。副业其实一模一样。我以前接单时容易累最大的原因是什么是因为我每次都把项目当成一个全新项目从零开始搭结构。后来我学会一个“偷懒”的姿势建一个属于自己的“私活脚手架仓库”。这个仓库里有什么说白了就是把那些重复出现的需求片段沉淀成模块用户登录模块包含标准登录页、JWT鉴权、手机号验证码登录、第三方GitHub/微信登录的demo。后台管理基础框架使用Vue或React搭好的布局包含侧边栏菜单、顶部导航、权限路由、暗黑模式切换。通用抓取脚本模板封装了Playwright的启动、登录、元素等待、截图、失败重试等基础动作。部署一键脚本包括Nginx配置模板、HTTPS证书申请命令、Docker Compose的编排文件。支付接入示例微信支付和支付宝支付的沙箱环境demo以及回调验签代码。有了这个仓库之后再来一个单子我的流程变成了看客户需求心里先过一遍这个需求涉及哪些模块从脚手架仓库里把对应模块拷贝出来。改改接口字段替换UI细节部署上线。听起来是不是很轻松实际上就是这么轻松。但前提是你得前期花时间把仓库养起来。很多人不愿意做前期投入觉得“这单客户又没给这个钱我干嘛花时间整理”结果就是每一次都在重复“从零开始”。等单子接多了反而每次都手忙脚乱。副业的偷懒其实是用前面几次的“不偷懒”换取后面无数次的“不费劲”。这个账要算清楚。3.2 class的用法类比模板和复用是副业的基本盘顺带说一个在Python里特别基础但特别核心的概念——class。因为很多程序员副业接触Python都是从写脚本开始的写习惯了函数式脚本之后一看到class就犯怵觉得没必要。但如果你做副业到了模块复用这个阶段class就是自然不过的进阶选择。一个最简单的例子封装一个配置读取类。import json from pathlib import Path class ConfigLoader: 配置加载器负责读取、校验、存取项目配置 def __init__(self, config_path: str config.json): self.config_path config_path self._data self._load() def _load(self): if not Path(self.config_path).exists(): raise FileNotFoundError(f配置文件不存在: {self.config_path}) with open(self.config_path, r, encodingutf-8) as f: return json.load(f) def get(self, key, defaultNone): return self._data.get(key, default) def set(self, key, value): self._data[key] value self._save() def _save(self): with open(self.config_path, w, encodingutf-8) as f: json.dump(self._data, f, ensure_asciiFalse, indent2)为什么要封装成class而不是写一堆函数原因很简单配置加载这个动作在爬虫脚本、自动化脚本、Web服务里都会用到。封装成类以后每次只需要cfg ConfigLoader(config.json) token cfg.get(auth_token)一处定义多处使用改配置逻辑只改一个地方。这种思维一旦形成你的副业代码就不再是一堆粘在一起的面条而是可以像积木一样搭来搭去的模块。其实class的核心价值跟副业中“模板拼装”的思路完全一致把状态和行为绑定在一起然后四处复用。你要是理解了这一点不就等于理解了“为什么有人做副业能同时并行三四个项目而你只做一个就喘不过气”。3.3 拒绝需求的技术把“好的”换成“我看看如何做更省力的方案”模块化和自动化解决的是“怎么做”的问题但副业里另一个偷懒大法是怎么去选“做什么”。程序员普遍脸皮薄客户说什么就答应什么。有一次一个朋友通过熟人找我说要做一个“简单”的问卷调查系统对方说得很轻松——“就几个页面很简单”。如果按照客户的原话去做这个项目确实不复杂但客户嘴里的“简单”通常只是表象。聊完才知道他想要的是带在线支付、多人协作、自动报表以及一套能对接微信公众号的会员体系。这种需求如果真的全盘照做后面就是无底洞。后来我学乖了遇到需求第一反应不是回答“好的”而是回答“我先理一下需求看看怎么做对你来说最省心”。然后把需求拆成“必做”和“可选”先做一个能用的最小版本再问客户要不要一步步加功能每加一个功能对应一份明确的报价和工期。这套“拒绝术”的关键不是直接拒绝而是把模糊需求转成明确边界。客户不一定抠门但他一定害怕被坑。你越是把需求理得清楚客户越信任你你后面的返工也越少这是双赢的偷懒。4. 偷懒的终极武器让代码和工具替你上班4.1 从Copilot到AI工具为什么程序员该“拥抱AI”而不是抗拒最近有个话题聊得挺热“为什么程序员大多都拥抱AI而音乐人却抗拒并隔离AI音乐池”我个人觉得这里面有个本质差别——程序员的日常工作中有大量的重复性劳动比如写模板代码、补测试用例、写正则、查文档这些活靠手动做既耗时间又没有乐趣。AI刚好把这类活接过去了程序员自然欢迎。音乐人抗拒AI音乐是因为AI直接威胁到了他们的最终创作产品本身。但程序员面对AI时焦虑程度没有音乐人那么高因为AI写出来的代码最后还得由人来审查、整合、维护、负责。AI是放大程序员偷懒能力的最佳工具。在我自己的副业流程里AI工具已经是标配GitHub Copilot写脚手架代码时按Tab就能补齐大段样板省去了大量敲键盘的时间。ChatGPT / Claude遇到不熟悉的库、看不懂的报错信息直接贴上去问比翻官方文档效率高得多。AI做需求分析把客户的原话粘进去让AI先输出一版需求理解、功能清单、排期估计我再人工调整。有朋友问我说AI生成代码质量不行是不是不能用。我的态度是AI生成的是初稿不是成品。你用它来偷懒偷的是“从空文档开始写第一行”的懒而不是跳过思考步骤的懒。你把AI当实习生写得不好你纠正它效率就能拉满你把AI当大神觉得它写啥直接用那翻车也正常。4.2 用AI工具快速定位页面元素Playwright的别样思路回到爬虫和自动化这个话题。很多人在写Playwright脚本时最头疼的就是元素定位。经常是看了网页源码好不容易找到一段长长得像天书的class结果运行起来一个反爬逻辑或者异步加载就能把一切搞崩。我在用AI辅助定位时有一个很顺手的流程把网页源码复制给AI然后描述“我想点击那个在右上角的‘重新登录’按钮帮我写出定位表达式”。AI很快会给我几个候选方案我再从中挑一个最稳定的放到脚本里。但这里有个细节必须提AI给的选择器不一定都可靠。尤其当页面里含有动态class属性时如classbtn-abc123这类哈希类名直接按class定位很容易挂。比较可靠的还是按角色、文本、或者相对位置定位# 按按钮文本定位 await page.get_by_role(button, name提交订单).click() # 按输入框占位文本定位 await page.get_by_placeholder(请输入手机号).fill(13800138000)这种写法不依赖class名只要页面文案不变就能稳定运行。这也是我在无数次定位失败后总结出来的优先定位用户可见的东西而不是程序员可见的class。用户可见的文本是给真实用户看的改动频率远低于内部代码样式类用在自动化场景里更皮实。4.3 交付环节的偷懒方法一键部署比什么手艺都值钱副业项目做到交付阶段很多程序员的痛点是代码写完了部署却要折腾人。买服务器、配Nginx、申请HTTPS证书、设置定时任务、处理日志轮转……这一套手动下来一两个小时就没了。如果你同时维护几个客户项目那每次部署都像过关。所以我很早就把自己的部署流程全部“脚本化”核心工具就是Docker Compose加一堆Shell脚本。比如一个典型的前后端分离项目我只需要在服务器上放一个docker-compose.yml内容大概长这样version: 3.8 services: frontend: image: nginx:alpine ports: - 80:80 - 443:443 volumes: - ./dist:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/conf.d/default.conf restart: always backend: build: ./backend ports: - 8080:8080 environment: - DB_CONNECTION${DB_CONNECTION} restart: always然后一个deploy.sh#!/bin/bash # 一键部署脚本本地构建前端后推送到服务器执行 set -e echo 1/5 构建前端 cd frontend npm run build cd .. echo 2/5 上传代码 scp -r backend dist docker-compose.yml userserver:/opt/my-project/ echo 3/5 重启服务 ssh userserver cd /opt/my-project docker compose up -d --build echo 4/5 清理过期镜像 ssh userserver docker image prune -f echo 部署完成部署一次的时间从一两个小时压缩到两分钟。而且因为是模板化的越用越熟练后面基本是复制粘贴改改项目名。这种偷懒方式才是真正把副业做成了长期生意而不是短期力气活。5. 偷懒式副业避坑指南哪些懒不能偷哪些活必须亲自干5.1 不能偷懒的硬性环节“偷懒”不是所有事都简化有些环节是必须亲力亲为、不能省流程的否则后患无穷。需求确认书必须写下来。口头聊得再清楚也要变成一份文字版需求清单发给客户确认。否则后期客户改口你连凭据都没有。这份清单本质上就是替你省去后期扯皮的麻烦它才是最大的偷懒。代码里的敏感信息必须脱敏。用脚本加密或者放到环境变量里绝不硬编码在代码中。出了泄露事故你偷的懒会直接变成事故。备份不能省。数据库、服务端的配置、自动化脚本统统要有备份。我吃过亏替客户部署的一个应用服务器到期后忘记迁移数据客户几年的内容直接没了。这种懒偷一次就够你后悔一辈子。合同或电子协议的雏形要有。哪怕只写清楚交付范围、维护期限、费用结算方式。没有边界的关系注定是被需求拖死的关系。有句话说得好偷懒要偷在流程里的重复环节而不是砍掉流程里的安全环节。这两者的界限决定了副业是越做越香还是越做越烂。5.2 常见问题与排查技巧副业做久了总会遇到各种幺蛾子。挑几个我碰到过、并且大概率你们也会碰到的问题统一整理出来问题一自动化脚本今天还能跑明天就报错“找不到元素”原因页面改版了。前端代码动了一下class或重构了DOM结构之前的选择器就完全失效了。排查思路先看脚本保存的截图确认页面实际形态再用开发者工具重新定位元素最后改为更稳定的定位方式比如按文本定位、按角色get_by_role或者加一个备用选择器。问题二客户需求越做越多项目永远“差一点完成”原因前期没有明确需求边界导致客户每次都有新的“小想法”。排查思路翻出最初的需求确认书和客户逐条对齐哪些是原范围哪些是新需求。明确告诉客户新增内容需要重新评估工期和报价。心软是最贵的成本。问题三部署到服务器后页面白屏控制台报API请求404原因前后端分离项目前端静态资源部署路径与后端API路径不一致比如后端挂在/api前缀前端却请求根路径。排查思路把前端请求地址改成后端实际前缀或者通过Nginxlocation /api/ { proxy_pass http://backend:8080; }做反向代理转发。问题四脚本在本地跑得好好的在服务器上就报编码错误原因服务器上文件读取编码和本地不一致比如Windows本地默认GBK服务器上是UTF-8。排查思路打开文件时明确指定编码open(file, r, encodingutf-8)一劳永逸。5.3 副业接单价格与服务范围的“偷懒定价法”定价这一块也完全可以“偷懒”。我的原则只有一条不做无差别的比价只按成本定价。成本包括三块时间成本预计投入的开发和调试时间折算成时薪。程序员时薪别按上班工资算要按你想达到的副业目标算。维护成本上线之后未来三个月预计要花的维护时间。沟通成本这个客户的需求是否清晰、是否好沟通。不好沟通的客户报价直接上浮30%-50%他是来买你的心力损耗。算完成本按“总成本乘以1.5到2”作为报价。一方面留出议价空间一方面也避免接下亏本单。还有一个经验贵一点的单客户往往更珍惜你的时间。报价太低客户会下意识觉得你时间不值钱于是什么小需求都找你。报价只要在合理范围内偏高一点反而能让双方保持边界感。要让客户知道你的时间是能被明确计价的他自然会收敛需求。5.4 心态层面的偷懒允许自己拒绝也允许自己休息最后这一点我想认真聊聊。副业本身是为了让生活更好但好多程序员做着做着就把副业做成了另一个“996”。晚上下班吃完饭坐到电脑前就开始写周末也不休息连陪家人都在想着那个Bug怎么解决。这不是努力这是透支。我自己也经历过这个阶段那时候白天上班晚上做外包周末继续扛。那段时间是我技术水平增长最快的时期但也是身体和精神状态最差的时期。后来我做了个决定每周至少留一天完全不碰副业手机开启免打扰让自己像一个正常人一样生活。神奇的是当我允许自己休息之后工作效率并没有下降反而提高了。因为脑子放松了再回来写代码的思路会更清晰过去卡壳的问题有时反而能迎刃而解。偷懒不是逃避责任而是优化系统。程序员写代码的时候知道要找性能瓶颈、要防过载你自己的时间安排为什么就不肯做同样的优化呢把自己当成一台长期运行的服务器副业是上面跑的一个服务如果你不给这台服务器留余量它早晚要宕机。学会偷懒是程序员做副业最重要的一门功课。把重复的交给代码把琐碎的交给工具把复杂的拆成模块把不该接的需求挡在门外——当你真正做到这些你才有精力去思考那些真正值得思考的事下一个副业方向是什么你的个人品牌怎么积累你未来三年想走到哪一步。这才是副业真正的意义它不该是一份压垮你的第二职业而应该是一个帮你探索自由、放大能力的练习场。省下来的时间才是你最终赚到的东西。