卖源码的售后答疑，我划了三条线

2026-10-01 源码销售,售后答疑,服务边界,独立开发

源码这东西跟别的不一样：你交出去的不是一个能用的黑盒，是一堆等着被人改的代码。买的人一定会改，改完一定会问。卖源码要不要管售后答疑，我的答案是要管，但得先划清楚线——不管的范围，比管的范围更重要。

卖源码要不要管售后答疑：三条线分别划在哪

第一条线：装不上的问题，我管。 代码在他机器上跑不起来，这是我的问题，不是他的问题。

第二条线：按文档改的问题，我管到文档为止。 文档里写过的，我指个位置；文档里没写的，我补进文档。

第三条线：改成他自己的业务逻辑，不管。 这是他的产品，不是我的产品。

划完这三条线，我发现售后从「无限责任」变成了「有限动作」。核心不是少干活，是知道什么时候可以停。

前提：不是所有源码都值得这样划

这套规则有个前提——你的源码得有一份能看的文档。 没有文档就划三条线，等于每条线都靠临场判断，那比不划还累。

另一个前提是：你不靠答疑本身赚钱。如果你的商业模式是「低价卖源码 + 高价答疑」，那这三条线不适用，那种模式本质是卖服务不是卖产品。

适用范围说清楚：这套规则适合标准化交付的模板类源码，不适合定制开发交付的项目。定制项目的责任边界得写进合同里。

第一步：把常见问题先写下来

开工第一件事不是定规则，是翻聊天记录。把你被问过三次以上的问题列出来，这就是你的文档目录。

我自己的经验是，重复问题集中在几个地方：环境怎么装、依赖版本对不对、某个配置该改哪里。这几类写清楚，能挡掉大半提问。

具体动作：今天就翻一遍你的历史消息，把重复问题列成一个清单。不用写答案，先列问题。

第二步：定回复模板，别每次现写

同一类问题用同一段回答。 这不是敷衍，是省时间，也是让口径一致。

比如「装不上」这一类，我固定回三句话：先贴报错、再说你的环境版本、然后我给你指位置。这三句话我不用每次重新想。

具体动作：给每一类常见问题写一段固定回复，存在你能随时贴的地方。

第三步：把「不管」写进商品页

这一步最容易被跳过。你必须在他付钱之前就让他看到边界。

我的落地页上除了交付物说明，还会写清楚答疑的范围和方式。付费前看到边界，付费后就不会觉得被坑。

具体动作：在你的商品页加一小段「答疑范围」，写清楚管什么、不管什么、通过什么渠道。

第四步：留一条升级通道

边界不是墙，得留个门。 有些人确实需要你帮他改业务逻辑，这种事按次算，明说就行。

我现在的做法是把这类需求单独列出来，说明按什么方式计。这样既不影响标准交付的边界，也不至于把愿意付钱的人推走。

具体动作：想清楚你的「额外服务」怎么计价，写一行字放在答疑范围下面。把这一步做完，卖源码要不要管售后答疑就不再是个每次都要重新纠结的问题。

最容易卡住的地方

第一，心软。 有人态度好、说得很急，你就破例了。破例一次没关系，破例十次你的规则就没了。

第二，回答完就忘了。 回答过的问题不补进文档，下次还得再答一遍。每一次重复回答，都是一次没写文档的代价。

第三，把边界说得太硬。 边界要清楚，但语气不用冷。同样是拒绝，说「这块属于你的业务逻辑，我这边不覆盖」比不回复好得多。

常见问题

Q：卖源码要不要管售后答疑？

A：要管，但要划边界。装不上的问题负责到底，文档覆盖的问题指到文档，改成自己业务逻辑的部分不覆盖，按次另算。

Q：源码售后一般管多久？

A：没有统一标准，建议在商品页写清楚，比如按版本或按时间段界定。核心是让买家在付钱前就看到这个期限，而不是事后争论。

Q：买家一直问超出范围的问题怎么办？

A：先确认这个问题文档里有没有，没有就补进文档再指给他。确实属于他业务逻辑的，明确说明不在范围内，需要的话按额外服务计。