创始人需要保留的五类工作

一人公司里的「一人」，主要指经营控制权集中在一个创始人手里。产品做什么，服务谁，钱怎么花，哪些结果可以交付，最后由谁负责，这些关键判断有清楚的归属。至于具体执行，可以使用软件、AI、外包、顾问和各类专业服务。^[1]

这一区分很重要。很多人刚开始做一人业务时，会把写代码、做设计、回复客户、记账、投放和内容生产全部揽到自己身上。时间很快被日常任务填满，真正需要创始人判断的事情反而没人处理。另一种情况是过早把整块工作交出去，自己只看最后结果。需求没有讲清楚，质量标准也没有建立，交付出现问题时很难判断该改哪里。

更可行的做法，是先画一张责任图。图上不只写「谁来做」，还要写「谁来判断」「谁能访问什么」「怎样验收」和「失败后谁来接管」。

第一类是方向和优先级。

一人公司资源有限，同一时间能够认真解决的问题不多。目标用户是谁，当前最值得验证的假设是什么，哪些需求暂时不做，这些选择需要由经营者自己完成。外部合作者可以补充信息，AI 也可以整理候选方案，但它们无法替业务承担取舍的结果。

第二类是对客户的承诺。

页面上写了什么，销售过程中答应了什么，交付时间和服务范围怎样定义，最后都由业务主体承担。文案、客服回复和合同初稿可以请人协助，正式承诺仍要由了解产品能力和履约成本的人确认。

第三类是权限和资产。

域名、代码仓库、云服务、支付账户、广告账户、客户数据和源文件，不应随着一次外包完整移交给某个人。每个合作者只获得完成当前任务所需的权限。管理员、付款方式、备份和恢复渠道由内部保留，并在合作结束后及时回收。

第四类是质量判断。

AI 可以在很短时间内生成很多候选结果，外包团队也可以按要求提交成品。真正困难的部分，是判断哪个结果符合用户、品牌、技术和商业目标。在 AI 设计工作流中，人的工作可以概括为观察、选择、修正和验收。生成速度提高后，这部分工作没有消失，反而更密集。^[2]

第五类是最终责任。

合同、知识产权、客户数据、税务、安全和产品事故，都有明确的责任主体。执行工作可以交给会计师、律师、服务商或承包方，业务方仍要提供真实资料、作出必要决策并保存记录。公司和个人也需要保持真实的账户与行为隔离。专业服务能降低错误概率，不能让责任自动消失。^[3]

外包前，先把工作亲自走一遍

一家提供 PDF 和图片生成 API 的小型软件业务，在早期由创始人自己完成关键词研究、文章结构、截图、技术步骤和发布。业务扩大后，初稿写作才逐渐交给外部作者。选题、结构、事实检查和最终发布仍保留在内部。^[4]

这个案例说明，外包开始前需要有一份真实做过的样本。样本不一定完美，但要能回答几个基本问题：

• 完成这项工作需要哪些输入；
• 中间有哪些必须作出的判断；
• 什么结果可以直接使用；
• 哪些错误会造成返工或风险；
• 整个流程在哪些位置需要账号和数据权限。

如果内部从未完成过这项工作，需求往往只能写成「做一篇专业文章」「设计一个好看的页面」或「把这个功能开发出来」。这样的描述没有统一的完成标准。候选人只能按自己的理解交付，委托方也只能在看到结果后凭感觉反复修改。

内部走过一轮之后，才适合把其中稳定、重复、容易检查的环节交出去。仍然模糊、经常变化或直接影响客户承诺的部分，可以暂时留在内部。

一份可以验收的任务说明

任务说明需要同时定义工作和验收。至少应包括下面这些内容：

1. 任务目的：这项工作解决什么问题，交付物会放在哪里使用。
2. 范围：需要完成哪些内容，哪些内容明确不在本次工作内。
3. 输入：资料、账号、接口、示例、品牌规范和已有成果。
4. 必要步骤：必须实际操作、测试、截图或核对的部分。
5. 交付格式：文件类型、结构、命名、源文件和说明文档。
6. 质量标准：什么可以接受，常见错误是什么，参考样本有哪些。
7. 协作方式：截止时间、中间检查、反馈渠道、修改次数和超出范围后的处理。
8. 验收与交接：由谁验收，怎样确认完成，账号、代码和文件怎样交回。

对于技术内容，任务说明还要写清代码能否运行、界面步骤是否真实、截图是否来自当前产品、引用能否追溯。对于设计工作，需要说明使用场景、尺寸、信息层级、品牌限制和可编辑文件。对于开发工作，则需要明确环境、测试、日志、部署和回滚方式。

这份说明应当持续更新。一次合作中出现了新的误解，下一次就把对应规则和示例补进去。时间久了，零散反馈会逐渐变成可复用的工作指南。