Topline / Anis Bennaceur：AI 让「自己做软件」成为销售现场的默认答案 (2026)

原文定位

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

软件销售中「我们自己做」异议率与年度合同额影响 — 原文根据 Attention 的 100 家匿名供应商样本绘制：异议率从 2025 年末的 2.0% 升至 2026 年上半年的 5.5% 和当前季度的 7.2%；右侧比较不同 ACV 档位中的出现频率与胜率影响。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

软件产品从可复制功能到组织护城河的四象限 — 原文矩阵以「单人或多人」和「是否产生新的专有数据」为两个轴，把产品分为 commodity、Claude Skill、echo chamber 与 moat；作者据此解释为什么多人工作流积累的组织上下文更难由内部团队在短时间重做。1

作者因此把软件价值的分界线从「能不能做出一个功能」移到「能不能持续积累一套多人共享的上下文」。每次协作都留下专有数据，更多用户带来更多上下文，供应商再把新的智能叠加到这套组织记忆上，产品便可能形成内部短期开发无法复制的复利。1

结论与边界

Anis Bennaceur 预计，软件市场仍会在「买」与「建」之间摆动。下一轮留下来的供应商，靠的不会只是更有说服力的销售话术，而是把多人工作流变成会持续积累专有上下文的产品。文章的证据来自 Attention 自己的销售样本，因果解释和下一轮竞争判断也属于作者的商业分析；材料支持的范围，是 AI 正在改变软件采购中的成本比较和销售异议，而不是所有软件都会被内部团队取代。1

References

1
The Year Every Buyer Tries To Build Their Own Software
toplinemedia.substack.com