与其等待 AI 的未来，我更想先改变下周一的销售工作

看完孙正义的演讲，重新思考 HDG 的经营与组织

每当新的 AI 模型发布，我都会关心它又能做什么。理解问题是否更准确，处理资料是否更快，能否承担更多工作。这些进步值得期待，但最近，我更常问自己另一个问题：AI 的能力不断提高，我们公司的工作方式究竟改变了多少？

我已经把与 AI 对话融入日常经营。它能帮助我整理信息、推敲想法，也能把一些模糊的问题变成可以讨论的方案。然而，屏幕上出现一个好答案，并不等于公司已经解决了问题。分析写得完整，不代表负责人知道下一步做什么；提案准备得漂亮，也不代表客户已经理解、接受并愿意下单。

真正需要跨过去的，是从“理解了”到“做起来”的距离。

看过孙正义在 SoftBank World 2026 的演讲后，我想把其中的启发放回北海道开发集团（HDG）的日常经营。不只是讨论未来会有多少 AI，而是具体思考：下周一，销售人员打开工作消息时，能否更清楚地知道应该联系谁、确认什么，以及为什么值得现在行动？

一、从宏大的未来预测中，我想学的是什么

在 2026 年 7 月 14 日的演讲中，孙正义描绘了面向 2040 年的未来：AI 可能承担全球 GDP 的约 20%，并出现 100 万亿个 AI 智能体和 10 亿台人形机器人。这些是他提出的预测，并不是已经实现或必然实现的事实。软银官方演讲报道

对我而言，比这些数字更有启发的，是思考的方向：先明确希望抵达的未来，再反过来判断今天应该做什么。经营者不能只问眼前的工具有什么功能，也要问自己究竟想让公司具备怎样的能力。

演讲也把 AI 基础设施的投入与回报联系起来，并提出关注“Return on AI”，也就是 AI 投入究竟带来了怎样的价值。这让我觉得，期待技术进步与检验经营效果，应当同时进行。软银新闻的演讲报道

长期投入当然不能只看眼前，但长期思考也不能成为推迟检查结果的理由。我希望一边保留未来的方向，一边及时了解实际发生了什么。如果现阶段的工作没有变清楚，就应该先调整做法，而不是用更大的未来数字解释今天的问题。

HDG 不需要复制大型科技公司的投资路径。我们的业务、资源和责任不同。我们要回答的，是能否把已有经验用得更好，让客户沟通更及时，让判断更可靠，让有限的人力用在更值得做的事情上。

从这里开始，文章不再是对演讲内容的转述，而是我结合 HDG 所做的思考。接下来谈到的销售流程、系统连接和试行方式，是我们的设计方向，并不是孙正义对 HDG 提出的建议。

二、HDG 的优势，需要从“有人知道”走向“公司能够使用”

我们的工作围绕商品、客户、供应方和市场展开。一件商品适合什么渠道，客户在意哪些条件，供货周期是否稳定，海外市场对包装和说明有什么要求，这些都不是只看一张产品表就能理解的。

经验和关系，是商业判断的重要基础。但经验如果只存在于某个人的脑海里，其他人就很难在需要的时候使用。关系如果只由一个人维护，组织也很难持续积累对客户的理解。

这并不是说，每个人都必须把所有事情写成报告。真正需要留下来的，是会影响下一次判断的信息：这个客户为什么选择我们，上一笔订单有什么特殊背景，哪些条件已经确认，哪些仍然不确定。

我想让 AI 发挥作用的地方，是帮助我们整理这些信息，找出需要确认的空白，让合适的人更容易看到与自己工作有关的事实。它不能代替长期合作中的信任，也不能凭空理解客户没有表达的意图。

过去的资料保存下来，还不等于知识能够被使用。只有当下一位负责人能据此提出更好的问题、避免重复调查、理解上一位同事的判断，经验才真正变成公司的能力。

对 HDG 来说，AI 的价值不只在于增加新的知识来源，也在于让我们已经拥有的知识，不再每次都从头整理。

三、复购预测到预订订单之间，有些步骤不能省略

这次我想具体推进的，是从再次采购的可能性出发，帮助销售人员开展提案，再与客户确认预订订单。

基本思路并不复杂：观察历史订单，找出可能值得再次沟通的客户和商品，再由负责人核实情况。我们希望在客户发来订单之后及时响应，也希望在条件允许时，更早与客户一起讨论下一阶段的需要。

我设想的流程是：

历史订单确认 → 复购候选识别 → 销售负责人核实 → 向客户提出建议 → 双方确认条件 → 形成预订订单。

这条流程里，最重要的恰恰是中间几步。不能因为过去的订货间隔比较稳定，就直接把下一次采购当成已经确定的需求。

例如，下面只是一个虚构的设计例子，并非 HDG 的真实交易：某客户过去几次大约每月订购同一种商品。系统可以提示负责人值得联系，但不能据此断言客户库存已经不足。前几次可能与活动有关，也可能是集中备货；本次销售节奏、库存和采购计划都需要重新确认。

好的提示，应该帮助销售人员问出更合适的问题，而不是机械地重复“该补货了”。只有了解客户下一阶段的安排，才能讨论商品、数量、交期和条件。

我不希望把预测包装成确定性。预测的用途，是帮助人更早发现值得确认的事情；订单的形成，仍然需要真实的客户意愿和双方的明确约定。

四、数据能够计算，不代表它已经可以支持承诺

实际查看 SCM（供应链管理）系统的数据并进行试算时，我更清楚地意识到：数据的含义与数据的数量，同样重要。

一个数量，究竟指单件、整箱还是其他包装单位？同一个客户名下的不同收货地点，是否应该放在一起分析？过去一次较大的订单，是日常补货还是临时活动？如果已有尚未完成的订单，再次提醒会不会让负责人误以为还没有安排？

这些问题不处理清楚，即使计算过程没有错误，结果也可能不适合直接用于销售。

历史订单反映的是过去发生过的采购行为，不会自动告诉我们客户今天的库存，更不会自动说明客户未来一定需要多少。内部系统里的库存信息，也不能脱离可销售条件、既有安排和供货确认，直接变成对客户的承诺。

日期也需要辨别。下单日期、出货日期和销售入账日期，回答的是不同的问题；取消或退货的记录，不能不加区分地当成正常需求。如果历史次数太少，或采购间隔本来就没有规律，我宁愿先不做时间预测，只把它作为需要人工了解的业务，而不是强行套入同一套算法。

我认为，系统不仅要展示建议，还应该让负责人知道建议来自什么记录、哪些条件尚未核实。资料不足时，明确显示“需要确认”，比给出一个看起来精确的答案更有帮助。

这一点也改变了我对自动化准备工作的理解。准备不是把资料尽量多地交给 AI，而是把关键数据解释清楚，把不能混用的情况分开，把必须由人判断的地方标出来。

计算能够成立，与客户可以据此安排销售，是两种不同的要求。我们要先把这个区别守住，才有资格讨论流程提速。

五、MCP 可以帮助连接系统，但责任边界仍要自己设计

讨论具体实施时，一个自然的问题是：能不能通过 MCP，让 AI 读取现有 SCM 系统，再提出建议？

MCP 是连接 AI 应用与外部工具、数据的一种协议。官方文档将其范围限定在上下文交换，并不规定应用如何使用大模型、如何管理这些信息。MCP 官方架构说明

对我而言，这意味着连接能力很重要，但连接本身不是完整的业务设计。即使 AI 能调用系统工具，也不代表数据一定准确、账户有权执行所有操作，或者每一条商业建议都可以直接采取行动。交易判断是否合理，仍然需要业务上的核实。

在 HDG 的方案里，我希望把“读取信息”“形成判断”和“执行操作”分开。第一步，在允许的范围内查看相关记录；第二步，根据记录整理候选、说明依据和待确认事项；第三步，只有满足业务条件并取得必要批准后，才进入相应操作。

这意味着，能够读订单，不等于可以修改订单；能够起草客户提案，不等于可以自行发送；能够提示供货风险，也不等于可以替公司作出采购承诺。

发生异常时同样要有规则。数据获取失败、负责人不明确、记录存在冲突，都不应该靠猜测继续。先保留状态，再请适当的人确认，往往比勉强完成一次自动处理更可靠。

读取文档时，也要区分信息与操作许可。我希望外部资料或内部记录里出现的一段文字，不会因为被 AI 读到，就直接变成执行系统操作的命令。允许参考资料，不等于允许资料改写业务权限。这个边界，同样是我们需要设计和检查的内容。

我不想把这种区分写成复杂的技术口号。对实际使用者来说，它应该很清楚：AI 看到了什么、建议什么、还没有做什么，下一步由谁负责。系统是否方便，最终要在这几个问题上接受检验。

六、每天检查业务，不等于每天给所有人发送通知

当候选和确认事项能够整理出来，下一步就是如何交到负责人手里。我们选择讨论 Slack 等内部消息工具，是因为提醒必须进入大家实际工作的地方，而不是只停留在另一张没人打开的报表里。

但这不意味着信息越多越好。每天把完整列表发给所有人，让大家自己查找相关部分，可能只是把筛选工作从系统转移给员工。

我希望设计的是按本人负责的业务提供提示。首次出现的必要确认事项可以通知；之后只有重要条件变化、出现新的待办或确实需要采取行动时，再补充提醒。同一项没有变化的内容，不需要每天重新制造紧迫感。

面向承担销售指标的成员，不等于让所有人收到同样的全部信息。即使对象范围扩大，信息也应继续按本人的职责和负责业务分发。

客户复购、新客户开拓和门店补货，也不能仅仅因为都与销售有关，就使用完全相同的判断规则。通知形式可以统一，业务逻辑不能因此被简化掉。

通知还需要与状态相连。已经确认、等待客户回复、暂缓、无需跟进，都应该有所区别。没有回复，并不自动表示负责人没有工作；消息送达，也不等于对方已经理解，更不等于事项已经解决。

如果找不到明确的接收人，就暂停该条通知，而不是随便转发给另一个人或扩大到公共群组。我想减少的是“接下来该确认什么”的迷茫，而不是减少员工认真思考客户问题的时间。

七、预订订单的意义，是把真实需求变得更清楚

为什么我要把流程继续延伸到预订订单，而不只停在提醒和提案？因为如果双方能够更早确认需求，后续的商品安排和沟通就可能更有准备。

但这里的“可能”不能被省略。预订订单不是提前把销售数字做出来，也不是把预测数量改一个名称，就当成客户的采购承诺。

需要确认的，不只是客户表达了兴趣，还包括商品和数量、交付时间、适用条件，以及我们能否履行。若仍有未决条件，就应该明确记录，不能让内部记录呈现出超过实际确定程度的状态。

具体推进时，数量单位、价格条件、收货地点，以及条件发生变化时如何处理，也需要双方明确。客户仍在考虑的部分应当保留为待确认；供应方尚未确认的时间，也不能因为内部希望成交，就写成已经承诺的交期。

对客户而言，提前沟通应该有助于安排业务，而不是增加被催促采购的压力。对我们而言，提前了解意向，也不应成为未经确认就扩大备货的理由。

我希望将来验证的是，这种做法是否减少了临时沟通，是否让后续安排更加清楚，是否让双方更容易达成合适的订单。这些效果目前都不能保证，更不能因为流程设计看起来合理，就写成已经发生的经营成果。

在客户明确同意之前，候选仍然只是候选，建议仍然只是建议。守住这种状态区分，销售人员才不会被系统里的数字推着走，客户也不会承担我们内部预测带来的误解。

八、对我本人来说，最重要的是把经验变成共同的判断条件

演讲接近尾声时，孙正义谈到企业应发挥自身行业知识、经验和数据的价值，在熟悉的领域推进 AI。这一点与我正在思考的问题非常接近。原视频约 57 分钟处

如果 AI 只是让我一个人更快地看完更多资料、处理更多业务，公司也可能因此更加依赖我。短期看，我的效率提高了；长期看，组织的判断仍然集中在同一个地方。

我真正想改变的，是这种依赖的结构。

哪些客户值得优先联系？什么条件不清楚时必须停下？什么事项由负责人自行判断，什么需要上级确认？遇到特殊情况，应该向谁提出什么问题？这些判断条件，需要从我脑海里的经验，变成员工能够理解、讨论和使用的规则。

这并不意味着把经验写成一份文件就结束了。规则需要在实际业务中接受检验。出现例外时，要分清是资料不足、适用条件不同，还是原来的判断方式本身需要修改。

AI 可以帮助整理这些差异，但修订规则的责任仍然在我们。规则应该给员工行动的依据，而不是让他们面对不合理的建议时只能照做。

我希望自己的时间逐渐更多地用于这些工作：明确方向，解释判断，处理真正重要的例外，并培养能够承担结果的人。这比单纯增加我个人每天处理的消息数量，更接近我想要的经营变化。

九、让员工把注意力留给客户，而不是让员工围着 AI 转

谈到 AI 与组织，很容易把重点放在一个人可以完成多少工作。我更关心的是，当资料整理和初步检查得到帮助后，人能否把注意力留给更重要的事情。

销售工作的价值，不只是发送消息。它包括理解客户计划、发现对方尚未说清的顾虑、解释商品的适用条件，以及在双方条件不一致时继续寻找合理的方案。这些都需要耐心、经验和信任。

如果引入 AI 后，员工反而要每天检查大量低价值提示、重复填写处理结果，或者花更多时间解释系统为什么误判，我们就应该重新审视设计。

我也不希望把 AI 的输出直接变成员工能力或态度的评价。没有采用某条建议，可能是负责人掌握了系统没有的信息；暂时没有成交，也不能脱离客户采购周期和具体交易条件简单归因。

这次试行只用于内部业务确认，不包括对员工的雇用或待遇作出判断。我希望把业务协助与人事决定的边界说清楚，不让销售提醒和回复记录被误解为自动评价员工的依据。

好的系统应该允许员工提出不同意见，记录“为什么不适用”，并让这些反馈帮助下一轮改进。这样，经验丰富的人不是被要求服从机器，而是在帮助公司形成更可靠的判断方式。

AI 应当支持人把工作做深，而不是只让工作看起来更忙。

十、我想衡量的，不是用了多少 AI，而是工作发生了什么变化

回到 Return on AI，HDG 需要把这个问题翻译成自己的经营语言。我们用了多少次工具、生成了多少文字，并不足以说明投入是否值得。

我希望先看一条比较完整的过程：提示是否准确地找到了值得确认的事情，负责人是否更容易采取行动，确认后有没有形成有意义的客户提案，提案是否进一步转化为双方认可的订单。

之后，才适合继续看实际订单、毛利、所需时间和运行费用。维护规则、核对错误和更新资料，也要计算在投入里，而不是只计算被节省的几分钟。

即使未来出现了订单增长，也不能把所有增长都归功于 AI。季节变化、客户活动、销售人员原有的努力、商品条件调整，都可能影响结果。

在条件允许时，我想比较同类业务原来的处理方式与试行后的差异，也可以考虑分阶段开展，观察哪些变化更可能来自流程改善。这些比较方法是后续的验证方案，目前并没有相应的验证结果。

最初的判断标准也不必过于宏大。少了一次无效核实，更早发现一项条件冲突，或者让负责人更快理解需要补充什么，都值得记录。不过，这些过程上的改善，仍然要继续观察能否形成稳定的业务价值。

重要的是允许结果告诉我们：哪些值得继续，哪些需要调整，哪些没有必要保留。

十一、先从小范围的内部确认开始，再讨论扩大

截至 2026 年 9 月 5 日，这项工作已经进行到设计、数据试算和准备于下一周开展内部确认试行的阶段。

目前还没有实际消息发送成功的验证结果，也没有客户提案效果或预订订单增长的验证结果。本文记录的是准备推进的方向，不是一项已经完成的销售自动化成果。

起步阶段只做内部确认，不由 AI 自动向客户发送提案，也不由 AI 自行登记订单。把一个流程写出来，与它已经可以安全运行，是两回事。

第一阶段，我想先确认消息是否送到了正确的人、内容是否容易理解，以及它有没有帮助负责人补齐必要信息。对于不适合预测的业务，或暂时缺少依据的项目，要允许停留在人工确认，不急着推进到下一步。

等到资料含义和实际流程比较清楚，再判断哪些情况适合形成提案草稿。进一步涉及向客户发送、登记订单或安排商品时，需要重新确认权限、批准和履行条件，不能把第一阶段的试行许可理解为所有后续操作都已获准。

扩大范围也应有明确理由。不是因为系统已经连接更多数据，就必须把更多业务纳入自动处理；而是因为小范围的结果说明，这套方法确实适用，并且有人能够维护和负责。

我愿意从一个不那么耀眼的起点开始：把该确认的事情讲清楚，把不确定的地方留下来，让负责人真正参与修正。只要这个起点可靠，后续才有可能逐步前进。

十二、把未来的方向，变成下周一可以迈出的一步

宏大的未来预测能够打开视野，但不会自动改变客户今天的采购计划。另一方面，如果每天只想着怎样把眼前的操作做快一点，也可能忘记公司究竟要往哪里走。

我希望把这两种视角放在一起。

对 HDG 而言，我想让北海道商品走向世界的工作，更贴近客户真实的需求；让员工减少寻找信息和重复确认的时间，多一些与客户共同思考的时间；让公司的经验不只属于少数人，而是能够被更多负责人理解和使用。

这不是等待某一个新模型出现以后，才可以开始的事情。许多基础工作，现在就需要由我们完成：把事实弄清楚，把责任说明白，把流程中容易混淆的状态区分开，再用实际结果不断修正。

对我本人来说，改变也不只是学会更多 AI 操作。我需要重新安排自己的注意力：不再把所有事情都揽到自己这里，而是多花时间为同事创造独立判断所需的条件；少一些对工具能力的期待，多一些对实际工作结果的追问。

下一次复盘时，我想问的不是“这周又用了什么新功能”，而是“哪一个原本不清楚的问题变清楚了，哪一次客户沟通因此变得更有价值”。

未来值得认真思考。下周一的工作，也值得认真设计。

我想从两者相遇的地方，迈出 HDG 的下一步。