三条路的差异不在报价上
同一个数据需求，你可以自己写脚本、可以买现成的采集工具、也可以找服务商。
这三条路的价格是能直接比的，但价格不是主要差异。真正拉开距离的是三件事：谁来定字段口径、目标站改版时谁负责修、以及数据出问题时找谁。
这篇不推销任何一条路。下面把三条路各自适合什么情况写清楚，包括什么时候你根本不该找我们。
什么情况下自己写最划算
以下条件同时满足，自己动手是最优解：
- 一次性需求，不需要周期重复
- 量在几百到几千条
- 目标站结构简单：列表页上就有你要的全部字段，分页规整，不需要逐条点进详情页
- 团队里有人写过脚本，Python 加两个库的程度就够
- 结果不进关键业务流程，错几条不影响决策
这种情况下，会写的人花两三个小时就跑完了，而走一遍需求沟通、测试、报价、确认的流程，时间成本反而更高。
这类需求我们在评估阶段会直接建议你自己做。 接下来对双方都没意思——你多花钱，我们也赚不到什么。
自己写的隐藏成本不在写，在维护。目标站改版一次脚本就废，你得自己发现、自己定位、自己改。一次性需求没有这个问题，所以它才适合自己做；一旦变成周期性的，这笔账就要重算。
什么情况下现成工具够用
采集工具适合这种情况：
- 目标是主流平台，工具有现成的模板
- 量在套餐范围内
- 能接受工具定义的字段结构，不需要按自己的口径调整
- 只做单个站点，不需要和别的来源合并
工具的价值是把「写脚本」这一步省掉了，对于模板覆盖到的场景确实高效。
隐藏成本有三处，都不在订阅费里：
第一，字段口径是工具定的。 变体商品算一条还是多条、价格取原价还是现价、评论数是总数还是某时段内——这些工具按自己的逻辑处理，你要的口径它不一定支持。等数据拿回来才发现口径不对，返工的是你。
第二，跨站点的结果结构不一致。 三个站点跑出来三种字段结构，合并的工作量经常超过采集本身。这一步工具不管。
第三，模板失效时你只能等。 目标站改版后，模板什么时候修好取决于工具方的排期，不取决于你的项目进度。
什么情况下找服务商
反过来，下面几条命中任意两条，找人做通常更划算：
- 跨多个站点或多个国家，需要统一口径后合并
- 字段口径要按你的用途定，不是接受现成结构
- 周期性重复，需要长期稳定跑
- 结果要进业务流程，错误会传导到决策
- 出问题需要有人负责，而不是自己排查
服务商这条路的隐藏成本也要说清楚：沟通成本是真实存在的。需求写不清楚会来回确认几轮，这也是站上反复强调需求模板的原因——一份可执行的数据需求应该包含什么那篇就是为了压缩这一段。
更大的风险是找到不靠谱的。判断服务商的几个具体问题，写在关于我们里，那些标准你可以拿去问任何一家，包括我们。
一个四问判断顺序
按这个顺序问，通常两三步就能定：
第一问：一次性还是周期性？ 周期性的直接排除自己写——除非你愿意长期承担维护。维护成本不会消失，只会在你和服务商之间转移。
第二问：一个站还是多个站？ 多个站基本排除工具。不是工具跑不了，是跑完之后的结构不一致，合并成本会吃掉省下来的钱。
第三问：字段口径谁定？ 要按你的用途定口径，就排除工具。工具给的是它的结构，不是你的。
第四问：出问题谁负责？ 如果这份数据错了会影响决策，那么「有人对结果负责」本身就是要买的东西之一。
三条路都走不通的情况
这种情况比想象中多：
- 核心字段只有登录后可见
- 单次查询上限低到拆分成本超过数据本身的价值
- 目标站结构频繁变动，维护成本高于数据带来的收益
- 数据用途本身落在不该做的范围内
前三种换哪条路结果都一样，因为限制来自目标平台不是执行方式。第四种任何一条路都不该走。
碰到这几种，要改的是需求本身，不是执行方式。受限平台还有哪几条路可走，写在受限平台的数据怎么办。
一句话总结
一次性、小量、单站、简单结构——自己做。 单站、主流平台、接受现成口径——用工具。 跨站、要定口径、要周期跑、要有人负责——找人。
如果你不确定自己落在哪一档，把需求发过来，评估阶段就能给出判断——包括「这个你自己做就行」这个结论。测试不单独收费，具体验证哪几件事写在小规模测试到底测什么。