这是
content/posts/indie/indie-leverage-and-delegation的目录页，收录 10 篇文章。前面十六组分别讲「要不要做」「在哪上架」「丢了怎么找回」「怎么合法立住」「多条线怎么加减」「怎么用接单换现金」「前 100 天怎么走」「怎么让人知道你」「人来了怎么留住」「收多少钱」「用户不在你的语言里怎么办」「怎么判断做的东西是对的」「怎么让产品看起来像样」「怎么把软件送到用户手里」「怎么把能力做成 API」「怎么给产品加 AI」。这一组回到最现实的约束：一个人做不完时，哪些事该交出去、交给谁、怎么验收、怎么收回。
这个系列解决什么问题
一个人的产能有天花板。加功能、回工单、剪视频、对账、写文档，每一件都不难，合起来就把主线挤没了。于是开始找人：外包设计、外包开发、请虚拟助理、做联盟计划。钱花出去了，时间却没有回来。
常见的四种情形：
- 设计外包改了三轮，最后自己重做，钱和时间都花了。
- 开发外包交付后能跑，但没人看得懂，改一行要问三天。
- 请了虚拟助理，权限给得太宽，客户数据与后台密钥都暴露在外面。
- 做了联盟计划，佣金结出去不少，真正留下来的客户没几个，还和渠道争客户归属。
这一组不讨论法律意见与公司组织，只做一件事：把「借力」拆成一个人能判断、能算账、能验收、能收回的动作。
核心主张：五条口径
第一，借力不是省钱，是买时间。 先算交接、验收、协调三项隐性成本，再看省下的工时是否真的回到主线。
第二，顺序不能反。 先自动化、再模板化、最后才外包；能写成规则的，不要先找人。
第三，判断不能交出去。 定价、定位、用户关系、核心架构、账号与密钥主权、事故沟通必须留在自己手里。
第四，交付物要可验收、可接管、可退出。 写不出验收标准的任务，不该外包；接不回来的模块，不该分包。
第五，所有数字都是教学假设。 每篇正文都标注了这一点，换成自己的时薪与任务量重算才有意义。
10 篇速览
| 文章 | 核心内容 | 阶段 |
|---|---|---|
| 借力的顺序：先自动化、再模板化、最后外包 | 任务四象限、三种借力方式的成本结构、四项隐性成本、六个月回本门槛 | 决策 |
| 边界清单：哪些能交出去，哪些必须自己握着 | 保留清单与可交清单、红黄绿三级、账号与数据权限、收回演练 | 边界 |
| 找人与试单：作品、报价、背调与红旗信号 | 四类渠道、2–4 小时付费试单、四项评分、六条红旗、两个背调问题 | 选人 |
| 需求交底：把「感觉」写成可验收的 brief | brief 七块、参考样本与反例、可判断的验收标准、变更单、返工记录 | 交底 |
| 发包方的成本结构：报价、付款节点与合同最小集 | 三种计价、30/40/30 付款、合同最小集、每净回收小时现金支出与全包成本 | 算账 |
| 设计与内容外包：brief、五个回合与素材归属 | 五个回合、修改上限两轮、源文件与字体图库授权、复用率 | 执行 |
| 开发外包与代码交接：接得住、改得动、走得掉 | 分包边界、最小权限、交接包六件、三项接管验收 | 交接 |
| 自动化、虚拟助理与一线客服：把按规则执行的事交出去 | toil 识别、自动化三档、虚拟助理任务、客服权限与抽检 | 放大 |
| 联盟、代理与分成：不是雇佣的借力 | 四类合作、分成基数、客户所有权、月度对账、终止与尾随佣金 | 合作 |
| 借力验收：回收工时、返工率、单位成本与退出 | 四张表、季度复盘、scale/fix/stop、知识回流与权限回收 | 验收 |
三条阅读路径
路径 A：还没借力，正在判断该不该找人
先读 01 算回本周期，再用 02 划边界；如果结论是「先自动化」，直接跳到 08。决定外包后，用 03 做试单、04 写 brief，再按 05 算全包成本。
路径 B：已经在用外包，但返工多、交接乱
先从 04 查 brief 是否可验收，再用 05 算每净回收小时现金支出与全包成本；设计内容问题读 06，代码接管问题读 07，最后用 10 的四张表决定加码、修补还是停。
路径 C：想用虚拟助理、客服外包或联盟放大
读 08 区分「按规则执行」与「需要判断」的任务，按权限、话术与抽检设计一线外包；再做 09 的联盟或代理计划，把客户所有权、分成基数与对账写进协议。
与其它专题的边界
| 专题 | 它讲什么 | 本组的边界 |
|---|---|---|
| 外包与协作的合规：合同、付款、保密、竞业与雇佣边界 | 四种协作形态、合同条款、付款节点、保密竞业、跨境外包 | 最接近的一篇；它讲法律形态与风险，本组讲发包方的成本、验收与退出流程 |
| 合同与条款：服务条款、隐私政策、DPA、退款政策与试点协议 | 对客户的法律文本 | 它讲对客户条款；本组只列发包合同的最小集与商务执行 |
| 报价：从卖时间到卖结果 | 接单方的报价方法 | 那组是卖方视角；本组是发包方视角的每净回收小时现金支出与全包成本 |
| 需求边界：把「再改一下」变成变更单 | 接单方如何管范围 | 那篇讲接单方防守；本组讲发包方怎么把 brief 写清、把变更算进成本 |
| 收束：把服务关掉、降级或转交 | 服务生意的退出与移交 | 它讲客户项目收尾；本组讲外包关系的终止、权限回收与知识回流 |
| 交付节奏：里程碑、周报与验收 | 你向客户交付时的里程碑与验收 | 方向相反：那篇讲乙方怎么交付，本组讲甲方怎么验收外包 |
| 一个人的时间分配：怎么同时维护 N 个产品 | 多产品之间的时间预算 | 它讲时间怎么分；本组讲分出去之后怎么验收与收回 |
| 维护负债账本：依赖、证书与平台政策的季度巡检 | 维护项与到期提醒 | 它管维护清单；本组管维护工作里哪些可以交出去 |
| 独立开发者生存指南（四）：工程与技术策略 | 技术债与产品债的取舍 | 它讲要不要重构；本组讲重构与维护外包的边界与接管成本 |
| 第 21–30 天：手工跑通一次交付 | 用人工交付验证需求 | 它讲用人工验证需求；本组讲把已成立的人工流程交给别人 |
| 客服不是成本：工单是免费的需求样本 | 客服工单作为需求信号 | 它讲从工单里读需求；本组讲一线客服外包的权限、话术与抽检 |
| 开发者支持：工单分级、状态页与事故沟通 | 开发者工单与事故沟通 | 它讲开发者支持；本组讲消费者一线客服、虚拟助理与自动回复的边界 |
| SDK 与示例：薄封装边界、版本策略与多语言维护成本 | 每语言 SDK 的年维护成本 | 它算语言维护成本；本组算外包模块的接管与维护成本 |
| 视觉物料：图标、截图、演示图与素材清单 | 品牌物料自己做 | 那组讲自己怎么做；本组讲设计执行外包的 brief、修改上限与素材归属 |
| 设计验收：一致性、可访问性与跨平台的一张表 | 设计验收清单 | 它给验收维度；本组给外包交付物的格式、授权与源文件验收 |
| 交接与数字遗产：应急联系人、资产文档、出售与关停移交 | 整个产品的交接 | 它讲产品级交接；本组讲单个外包模块的可接管性 |
| 运维自动化与 Runbook as Code 实践 | toil 识别与自动化技术实现 | 它讲技术实现；本组讲一人产品的自动化优先级、回本与维护成本 |
| 个人游戏开发者失败案例：外包美术没有管线，风格越做越乱 | 外包美术翻车的单点案例 | 它给案例；本组把它抽象成 brief、验收与素材管线 |
| 个人游戏开发者成功案例：程序和美术两人合作做完第一款游戏 | 两人合作的范围、分成、决策权与退出 | 它讲长期合作；本组讲可终止的外包与按任务结算 |
| SaaS 第一位协作者：什么时候该找人，哪些事不能外包 | SaaS 公司的第一位协作者 | 它讲招人与组织；本组讲一人产品按任务拆分的权限边界、验收与收回 |
| SaaS 渠道伙伴：早期合作不要只谈分成，要先谈交付能力 | 渠道伙伴的销售包与分成 | 它讲渠道销售包；本组讲一人产品联盟计划的归因、客户所有权与分账 |
| SaaS 行业观察：渠道体系与合作伙伴生态 | 代理商、咨询伙伴、技术伙伴与平台市场 | 它讲 B2B 渠道体系；本组讲自助产品的联盟与推荐分成 |
| 15.1 外包切分与计价模型 | 游戏美术按资产切分与计价 | 它讲美术资产的切分与单价；本组讲软件任务的分包、付款节点与全包成本 |
| 14.2 外包与素材成本 | 游戏项目的外包预算与素材成本 | 它算游戏美术预算；本组算一人软件产品的任务级借力成本 |
| 13.1 美术需求书（Brief）的结构化写法 | 美术 brief 的结构化模板 | 它给美术 brief 模板；本组给跨设计、内容、开发与客服的通用 brief 七块 |
| 游戏外包供应商管理：从试单、验收到长期协作的实战方法 | 游戏美术、音频、动画、测试与本地化的供应商管理 | 最接近的案例型文章；它面向游戏资产产线，本组面向软件产品的任务级借力 |
| 游戏外包验收标准：怎么避免交付时才发现不能用 | 游戏外包的需求文档、里程碑与最低验收清单 | 它给游戏资产的验收项；本组给软件交付物的可判断标准与返工账 |
| 13.3 团队、外包与远程协作 | 外包有效产能、利用率与时区重叠 | 它算投放素材的产能缺口；本组算一人产品的时间回收与单位成本 |
| 游戏发行合同怎么谈：分成、买断、里程碑和控制权的关键条款 | 游戏发行合同的分成与控制权 | 它讲发行商合同；本组讲一人软件产品的联盟、代理与分成对账 |
| 一个人的消息系统：事务邮件、通知分层与送达率 | 消息清点、事务邮件基线、SPF/DKIM/DMARC、送达率账本、通知分层、偏好中心、渠道分工、生命周期序列、同意与退订、四张验收表 | 那组讲不靠人值守的自动消息；本组讲自动化、外包与协作边界 |
| 一个人的社区：冷启动、版规、版主与社群健康 | 社群该不该建、载体选型、前 100 人、版规与三档处置、版主与志愿者、内容节奏、答疑沉淀、活动与线下、商业化边界、四张验收表 | 那组讲志愿者版主的权限、轮值与退出；本组讲外包、自动化与协作边界，含付费外包的验收 |
| 一个人的财务：现金流、runway 与月度结账 | 四张表与四个收入、分账、收入确认、成本清点、13 周滚动、runway 与薪酬、15 分钟月结、税预提、现金预警与收缩、四维验收 | 那组讲外包与工具的成本项；本组讲外包、自动化与协作边界 |
| 一个人的运维：可用性、告警、事故与值班 | 可用性预算、五条探针、告警降噪、日志串联、状态页、容量水位、依赖降级、发布观察、事故复盘、四维验收 | 那组讲可用性与事故响应；本组讲外包、自动化与协作边界 |
| 一个人的多租户：组织、邀请、角色与数据隔离 | 组织引入判据、三层模型与迁移、邀请与成员生命周期、角色矩阵、三层校验、数据隔离、审计日志、席位一致、交接与四维验收 | 那组讲客户组织内的数据权限；本组讲外包、自动化与协作边界 |
| 一个人的产品度量：事件字典、指标口径与决策看板 | 六个决策与十二个指标、二十四事件字典、埋点三处校验、口径五要素、五步漏斗、一屏四区看板、四条校验与三方对账、采样与保留、样本量与灰度、九项验收 | 那组讲度量体系怎么建；本组讲外包、自动化与协作边界 |
| 一个人的架构：技术选型、模块边界与演进（10 篇） | 技术选型排除法、九个模块与依赖方向、数据迁移三步、四个升级窗口、技术债预算、三次规则、重构判据、可替换性、幂等与补偿、四维验收 | 那组讲代码结构与交接前提；本组讲外包、自动化与协作边界 |
| 一个人的计费系统：订阅状态机、按比例计费与失败重试（10 篇） | 订阅状态机、五个时点、按比例计费、按量计量、催收、退款拒付、发票税务、对账漏损、自建决策、十二项验收 | 那组讲计费可外包的边界；本组讲外包、自动化与协作边界 |
| 一个人的隐私工程：数据地图、最小化与删除权（10 篇） | 数据地图、最小化、合法性依据与同意、政策一致性、数据主体请求、删除、保留期、跨境与供应商、泄露响应、十二项验收 | 那组讲外包与供应商的数据边界；本组讲外包、自动化与协作边界 |
| 一个人的数据搬家：导入、去重、迁移与退出（10 篇） | 迁移漏斗、导入契约、字段映射、去重合并、幂等重跑、人工代导入、窗口与回滚、附件限额、导出退出、十项验收 | 那组讲外包代导入与 SOP；本组讲外包、自动化与协作边界 |
| 一个人的质量守门：验证预算、回归清单与发布门禁（10 篇） | 47 缺陷与三条红线、12 条关键路径、三层配比、38→26 回归、六项门禁、四级缺陷、测试数据、不可逆保护、测试债、十项验收 | 那组讲外包交付的验收与门禁；本组讲外包、自动化与协作边界 |
| 一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应 | 14 个攻击面、认证与枚举、会话撤销、17 个密钥三档、四条边界、41 个依赖与 186 条告警、四类限流、9 类审计日志、72 小时三段响应、20 项验收 | 那组讲密钥与访问边界；本组讲外包、自动化与协作边界 |
| 一个人的性能与账单：4.2 秒的首屏、一千二百次查询与每月 210 美元 | 4 项预算与 20 格、RUM 与慢查询、412→168 KB、1,200→3 次查询、0→86% 缓存、34 秒导出、7→4 个第三方、210→118 美元、3 次回归告警、10 项验收 | 那组讲自动化之外的技术效率；本组讲外包、自动化与协作边界 |
| 一个人的企业客户：九家询价、一百四十八道问卷与 134 天的第一单 | 9 家询价与 130 h、96 天采购、148 题问卷、7 个子处理者、SLA 43.2/216 分钟、26 h SSO、4 周试点、38 天到账、8 h 实施、10 项验收 | 那组讲哪些企业动作要自己握着；本组讲外包、自动化与协作边界 |
| 一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护 | 4,200 star 与 1,949 美元、612 h 维护、214 依赖、48,600 行 78/22、1,180 个 issue、214 条告警、23 个赞助者、9 家双许可、17 位贡献者、10 项验收 | 那组讲仓库权限怎么交出去；本组讲外包、自动化与协作边界 |
本组统一口径
- 借力不是省钱，是买时间：先算交接、验收、协调三项隐性成本，再谈省下的工时。
- 顺序不能反：先自动化、再模板化、最后才外包；能写成规则的，不要先找人。
- 判断不能交出去：定价、定位、用户关系、核心架构、账号与密钥主权、事故沟通必须留在自己手里。
- 交付物要可验收、可接管、可退出：写不出验收标准的任务，不该外包。
- 所有数字都是教学假设：每篇正文都标注了这一点，换成自己的时薪与任务量重算才有意义。
使用说明
每篇都可以单独读，但建议按「先判断、再选人、最后验收」的顺序。每篇末尾有行动清单与验收标准，验收标准写成了一句可判断真假的话——做不到就是没做完，不需要再解释。
文中出现的人物、产品与数字均为教学假设，用于演示算法，不代表经核实的真实案例。涉及合同、雇佣、税务、竞业与消费者保护的部分只说明取向，不构成法律意见，具体口径请以所在地法规与专业人士意见为准。
本组的证据与使用方法
这十篇不引用任何外包平台的实时费率与佣金比例，也不承诺外包一定更便宜。可复算的部分全部用四则运算给出算式（回本周期、核心时间占比、试单加权得分、brief 完整度、返工率、每净回收小时现金支出、全包成本、素材复用率、接管时间、自动化回本、误判率、合作净收入、综合验收分），读者可以替换成自己的时薪与任务量重跑；不可复算的部分（例如具体平台的报价、合同条款、税务与雇佣认定）明确标注为需要自行核验，并给出核验方向。
建议的使用方式：先用 01 判断该不该借力、用 02 划清边界；决定借力后按 03–05 完成选人、交底与算账；执行阶段按 06–08 管设计内容、代码交接与一线外包；需要用外部销售时读 09；最后用 10 的四张表做季度复盘。借力不是一次性动作，是一条需要持续验收与回收的线。