Topline / Anis Bennaceur：AI 让「自己做软件」成为销售现场的默认答案
Topline 与 Anis Bennaceur 解释 AI 如何把「自己做软件」变成常见销售异议，以及买方应如何把原型成本算到长期维护和组织上下文。
原文定位
Topline 与 Anis Bennaceur 于页面标注的 2026 年 8 月 18 日发表 《The Year Every Buyer Tries To Build Their Own Software》。文章追问一个软件销售现场正在变得常见的问题：买方为什么越来越愿意自己做软件，供应商该怎样证明外购产品的长期价值。作者的回答分成两半：AI 降低了做出原型的门槛，却没有自动降低长期维护一套软件的成本；供应商若想留下来，必须让产品积累内部团队难以快速复制的专有上下文。1
三件事把「自己做」变成默认选项
作者把变化归结为能力、经济性和组织许可同时到位。
能力。 AI 让开发软件变成更轻的工作。文章引述 Retool 对 817 名开发者的调查：35% 的受访者已经用定制开发替代过至少一个 SaaS 工具，78% 预计在 2026 年继续增加自建；超过一半的非工程人员已经可以做出解决方案，其中包括面向客户的产品。1
经济性。 当一个点状软件产品的价格达到五位数或七位数，而内部团队几小时就能做出一个能用的版本，买方自然会先拿两者比较。这个比较的诱惑来自原型成本，而不是完整的长期拥有成本。1
组织许可。 企业高层正在把 AI 变成各职能部门的任务。文章引述 IBM 的 2026 年 CEO 调查：大型组织中设立或聘用首席 AI 官的比例从 2025 年的 26% 升至 2026 年的 76%，85% 的 CEO 认为每个职能负责人都需要成为本领域的 AI 专家。组织一旦公开要求各部门使用 AI，内部做工具便获得了预算之外的行动理由。1
销售数据里，异议率已经变成了什么样
作者用 Attention 的销售数据观察这股变化。样本包含 100 家匿名软件供应商，覆盖 15 个行业和不同年度合同额（ACV）档位。文章给出的「我们自己做」异议率，从 2025 年末的 2.0% 升至 2026 年上半年的 5.5%，再升至原文所称当前季度的 7.2%；100 家供应商中有 82 家的异议率仍在上升。1
作者认为，异议率上升与 Claude 和 MCP 让技术运营团队更容易搭建内部工具的时间点高度重合。作者同时承认，这组数据无法证明因果关系；在文章提供的材料里，AI 工具变得易用只是作者认为最清楚的解释，而不是样本检验出的结论。1
交易金额越大，异议带来的损失越明显。ACV 低于 2.5 万美元的交易约有 4% 遇到这类异议，胜率基本不受影响；2.5 万至 10 万美元的交易约有 6% 遇到异议，出现异议时，中位胜率下降约三分之二；10 万美元以上的交易接近 9% 遇到异议，中位供应商的赢单概率相对基线下降约 80%，其中约 60% 最终被记录为
No Decision。作者的解释是，买方说「我们可以自己做」时，交易有时并没有转向内部开发，而是停在评估阶段。1行业之间也有差别。数据与分析类软件的异议出现率为 8%，网络安全、销售科技和开发工具约为 6%—7%，房地产科技和物流约为 3%。作者把这组差别概括为：买方越懂技术，越容易把自己看成供应商的潜在竞争者。由于 CRM 很少设置「内部自建」这个选项，许多交易会被记成
No Decision 或 Other；作者估计，中位供应商近 10% 的流失合同额可能与这类异议有关。1买方要把 v1 的便宜算到 v10
文章写到一位曾考虑用便宜的记事工具和内部 agent 平台替代 7 万美元供应商合同的买方。只看第一版开发成本，买方似乎能省下 5 万美元；把后续迭代放进账本后，比较就变了。自建系统需要持续承担 token 费用、数据管道维护、故障修复、模型和 API、基础设施、安全、集成与调试成本，还会占用本来负责主营业务的员工时间。1
作者没有把自建一律判定为错误。工作流如果高度贴合本公司、能形成战略差异、维护成本低，而且组织里有人真正具备维护能力，自建可能比每年支付 10 万美元 SaaS 费用更合理。作者给买方设了三个条件：
- 失败代价低。 系统一天不能用，或给出错误答案时，损失必须小于自建带来的收益。
- 维护责任明确。 某个人或团队的正式职责必须包括上线后的维护，而不能只靠发起项目的员工继续热心支持；人员流动后，系统仍要有人接手。
- v10 的经济性仍成立。 成本核算要覆盖初始开发、维护、基础设施、模型与 API、安全、集成、调试，以及维护者无法投入主营工作的机会成本。
三个条件全部成立时，自建才有清晰的理由。任何一个条件缺失，第一版很便宜的内部工具都可能变成组织里最贵的软件。1
供应商要在三层上回应 DIY
作者把卖方应对方式称为「杠杆金字塔」：销售与 Enablement 动得最快，Demand Gen 居中，产品最慢，却能改变竞争本身。
销售与 Enablement 先处理眼前的异议。 作者建议供应商从销售录音里找出已经赢下的相关交易，观察销售人员怎样回答。销售人员不必争辩买方做不到，因为买方现在确实可能做出一个可用版本。销售人员应当把比较拉回维护责任、故障代价和长期成本，并把前置部署工程师纳入合同，替买方完成最后一公里的实施工作。1
Demand Gen 重新定义目标客户。 作者建议把客户分成三组：从未提出 build vs. buy 异议却会购买的客户；提出异议后仍会购买的客户；因为异议而流失的客户。供应商可以用公司规模、技术栈、角色和意向信号，找出前两组与第三组的差异，把预算集中到更像成功客户的买方，而不是继续追逐注定停滞的交易。1
产品层解决根本问题。 作者用两个问题筛选产品功能：功能是否产生新的专有数据？它是单人使用，还是多人协作并随用户增加而变得更有价值？第二个问题同时决定了内部自建的复杂度和失败成本。1
功能容易复制，组织上下文更难复制
作者的矩阵把产品分成四类。单人使用、又不产生新专有数据的功能属于 commodity，现成大模型已经能直接提供。单人使用但会产生新数据的功能类似 Claude 或 Codex Skill，技术型买方可能在几天甚至几小时内复制。多人使用却不产生新数据的产品像一个可替换的 echo chamber：它没有记忆，也没有随使用增加的复利，技术团队容易把它克隆或拆掉。多人协作并持续产生新的组织上下文，才可能形成 moat。1
作者因此把软件价值的分界线从「能不能做出一个功能」移到「能不能持续积累一套多人共享的上下文」。每次协作都留下专有数据，更多用户带来更多上下文，供应商再把新的智能叠加到这套组织记忆上，产品便可能形成内部短期开发无法复制的复利。1
结论与边界
Anis Bennaceur 预计，软件市场仍会在「买」与「建」之间摆动。下一轮留下来的供应商，靠的不会只是更有说服力的销售话术，而是把多人工作流变成会持续积累专有上下文的产品。文章的证据来自 Attention 自己的销售样本，因果解释和下一轮竞争判断也属于作者的商业分析；材料支持的范围，是 AI 正在改变软件采购中的成本比较和销售异议，而不是所有软件都会被内部团队取代。1
References
- 1The Year Every Buyer Tries To Build Their Own Software
toplinemedia.substack.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.