很多程序员会用项目总价判断私活是否划算，但这很容易高估收入。评估 GitHub 项目接私活的真实时薪，不能只看客户支付了多少钱，而要把获客、沟通、需求澄清、开发、测试、部署、修改和售后支持全部计入时间成本。
先算“全链路工时”
可以使用一个简单公式：
真实时薪 = 实际到手收入 ÷ 项目全链路投入小时数
全链路投入不只是写代码的时间，还包括展示项目、回复客户、开会确认需求、等待反馈、处理返工和上线部署。如果项目总价为 6000 元，开发用了 40 小时，另外还有多轮沟通、修改和部署，那么实际时薪必然低于 150 元。若客户持续追加细节，却没有同步增加预算，时薪还会进一步下降。
因此，GitHub 作品集的价值不只是展示技术能力，更在于减少解释成本。一个能运行的 Demo、清晰的 README、真实截图和明确的功能边界，可以让客户更快理解交付结果，也更容易接受按模块报价。
把报价拆成可核算的范围
评估项目时，至少要把以下内容单独列出：
- 功能模块与对应工时；
- 源码、部署文档和演示环境是否包含在交付中；
- 首次交付后允许修改的次数；
- 服务器采购、长期维护和新增需求是否另行计费；
- 平台服务费或其他获客成本是否影响最终到手金额。
例如，一个后台管理界面可能报价 3000 到 6000 元，但如果包含大量定制页面、反复修改和上线支持，就不能直接拿总价除以编码时间。报价前写清“交付什么、不交付什么”，比单纯提高单价更能保护真实时薪。
用项目筛选客户，而不是只吸引客户
GitHub 项目接私活的核心收益是筛选权。项目越贴近某类具体问题，客户越容易判断是否匹配，沟通中的无效往返也越少。反过来，技术栈写得很满，却没有运行效果和边界说明的仓库，往往只能带来泛泛询价。
最终应记录每个项目的预计工时与实际工时，尤其关注返工和沟通占比。连续复盘后，才能知道哪些类型的需求值得继续接，哪些项目虽然总价不低，实际却是在用业余时间低价出售确定性。
