接单选工时制还是项目制，算完才明白

2026-07-26 工时制,项目制,计价方式,接单定价

同一单烧烤店小程序，如果按工时结，我可能报不出 ¥3000——因为手写代码不到 20 行。客户按结果付钱，我按结果定价，这就是项目制。接单选工时制还是项目制，不是哪个更专业的问题，是谁承担范围不确定的风险。

结论：需求清楚走项目制，需求含糊走工时制。 选反了，两边都会难受。

两种计价方式摆在一起

| 维度 | 工时制 | 项目制 |

|------|--------|--------|

| 报价依据 | 单位时间价格 × 预估时间 | 交付结果的整体价格 |

| 范围变化的风险 | 客户承担，改多少算多少 | 你承担，改多了自己亏 |

| 客户的心理感受 | 「不知道最后要花多少」 | 「价格清楚，心里有底」 |

| 你的收入上限 | 被你的时间锁死 | 可能远超工时价值 |

| 需求含糊时的表现 | 相对安全，边做边算 | 危险，容易无限投入 |

| 对信任的要求 | 低，过程透明即可 | 高，客户要先信你能交付 |

最后一行是很多人忽略的：项目制卖的是承诺，工时制卖的是时间。 卖承诺的前提是对方信你。

需求说不清、客户自己也在探索的单子，必须走工时制。 这类项目你没法估总量，硬报一个总价等于赌。

工时制还有个好处：它让「改需求」这件事变得自然。客户每多要一次，账上多一笔，不用每次都谈加钱，冲突少很多。

代价是客户容易焦虑。所以走工时制，你要主动给进度和已用工时，让他看见钱花在哪。

范围能被写成文字、你能估出总量的单子，走项目制。 这类项目里，你的经验和工具能直接变成利润。

那单 ¥3000 的小程序就是典型：需求清楚、有可复用的模板、交付边界明确。客户买的是问题被解决，不是我的代码行数。

项目制还有一个隐形好处：它逼你在报价前把需求问清楚。因为你一旦报错，亏的是自己。

我目前的默认是项目制，原因有三个。

第一，我的交付里有大量可复用资产。 做过的模板、现成的组件、AI 员工能代劳的部分，这些让我的实际耗时远低于客户想象。工时制会把这份优势抹平。

第二，客户更喜欢确定的价格。 大多数中小客户预算有限，他们需要一开始就知道要花多少。

第三，项目制让我敢用工具。 工时制下我用 AI 提效等于自己减收入，项目制下用工具省下来的时间就是我的。

但我会在报价单里写清楚范围边界。范围之外的一律走变更流程，这部分在客户中途加需求怎么加钱里写过。

真正落地的做法常常是混合的：主体按项目报价，不确定的部分按工时结算。

比如一个项目里，核心功能我能估准，就报固定价；后期运营维护、数据接入这些说不清的，就按人天计。

这样客户拿到一个明确的起始价，你也给自己留了不确定部分的出口。合同里把两部分分开写，以双方签字确认的版本为准。

Q：接单选工时制还是项目制，哪个风险更小？

A：对乙方来说，需求含糊时工时制风险更小，需求清楚时项目制收益更高。核心判断是「我能不能把范围写成文字」，能就项目制。

Q：客户坚持要固定总价，但需求很模糊怎么办？

A：把固定价限定在一个明确的范围内，范围外单独计价。或者先做一个小的付费调研阶段，把需求理清再报总价。

Q：项目制做超时了，能追加费用吗？

A：超时如果是范围扩大导致的，可以谈追加；如果是你自己估错，通常只能自己承担。这也是项目制的风险所在，报价时要留余量。