AI 时代的软件自研与采购之争

当 AI 已经能够帮助企业快速开发软件，制造企业为什么还要支付商业 MES 的许可费，或持续订阅 SaaS 服务？这个问题有一个合理的出发点：如果企业能够以更低的成本实现所需功能，采购商业软件的经济性就需要重新评估。但判断自研是否划算，还必须区分两件事：开发出一套软件，与长期拥有和运营这套软件，承担的工作和责任不同。

这里也需要区分 MES 与 SaaS。MES 描述软件承担的制造执行功能，SaaS 描述软件的交付和服务方式，商业 MES 并不都采用 SaaS 模式。因此，企业比较的实际对象可能是自研 MES 与商业 MES，也可能是自建某项应用与订阅相应服务。无论采用哪种方式，都需要明确谁负责部署、维护、升级和故障处理。

判断自研与采购，需要区分三个评价层面

企业可以从功能实现、工程可靠性和业务价值三个层面评价软件方案。它们相互关联，分别回答“能否做出来”“能否持续可靠运行”和“是否改善了业务”。这是本文的分析视角，不是对专业能力的严格分类；软件工程本身也包含需求分析与设计等工作。

第一个层面是功能实现。对于边界清楚、接口明确的需求，AI 可以辅助生成界面、查询逻辑、接口适配代码和测试代码，帮助团队验证想法。不过，可运行的程序只能说明某种实现能够执行，不能单独证明需求覆盖充分，也不能证明业务规则正确。

第二个层面是工程可靠性。版本管理、测试验证、安全治理、架构演进和持续维护，都服务于系统长期可靠运行。企业需要知道当前运行的是什么版本、变更影响哪些业务，以及异常发生后如何恢复正确状态。AI 可以辅助这些工作，但验收依据和上线责任仍需由企业及相关服务方明确承担。

第三个层面是业务价值。即使程序准确实现了需求，如果需求保留了重复审批、不一致的数据口径或相互冲突的部门规则，系统仍可能无法创造预期收益。企业需要确认哪些信息用于什么判断、谁有权作出决定，以及如何评价执行结果。对于制造业务，还需要协调交付优先级、设备利用率与在制品流动等不同目标。

AI 对这些工作的净成本影响，需要结合具体任务、工具和团队评估。代码生成更快，并不直接等于整个项目成本更低，还应计入审阅、返工、集成和验证投入。例如：即使 AI 让某个报表工具的编码时间减少了 30%，也不能直接认定整套 MES 的开发、集成、验证和长期维护成本都减少了 30%。

软件承担的生产责任，如何影响自研与采购？

评价自研与采购时，工程可靠性的要求需要落实到软件实际承担的业务职责。对于半导体工厂，只读分析工具与参与生产执行的应用，所需的验证范围、异常处理和维护能力不同。因此，判断 AI 辅助自研是否划算，需要先明确软件承担哪些生产责任，再比较实现和维持这些责任所需的投入。

可以用一个假设场景说明这种差异。某工厂开发批次查询工具，读取 MES 中的在制品信息，帮助工程师定位滞留批次。工具需要保证数据准确，并说明更新时间。如果进一步增加通过 MES 接口提交批次出站请求的功能，就需要确认执行条件、请求结果和异常处理方式。例如，服务端已经完成出站，但网络中断使工具没有收到响应，重试时就需要避免重复执行。两种功能可能使用相似的界面，却需要不同的工程保障。

这些要求会直接影响自研的实际成本。AI 可以加快查询页面和接口代码的开发，但生产业务规则的确认、异常场景测试、运行监控和故障处理仍需持续投入。即使复用已有 MES 的事务能力，新增应用与接口之间的交互也需要验证。企业因此需要评估内部团队能否长期维护这条业务链路，而不只是计算第一版程序的开发时间。

生产责任增加，也不能直接推出必须采购商业软件。自研团队如果具备相应的开发、验证和运维能力，自研仍然可以成立；供应商则需要证明其产品、接口和服务能够满足同样的要求。比较应当建立在相近的职责范围与服务水平上，并明确哪些工作由平台承担，哪些仍由企业负责，避免低估任何一方的长期成本。

软件承担的责任还可能随使用范围扩大而变化：原本供个人分析的工具，可能逐渐被多个部门依赖，甚至进入生产执行流程。产品、工艺和设备变化，也会增加新的适配与验证工作。最初可行的自研或采购方案，因此需要在业务职责和维护条件发生变化时重新评估。这也是软件选择需要关注完整生命周期的原因。

什么情况下企业需要重新评估自研与采购？

自研与采购的选择，在 AI 出现之前就已经存在。拥有 IT 团队和软件工程师的制造企业，早已具备开发内部系统的能力。IBM SiView Standard 起源于 20 世纪 80 年代日本野洲工厂使用的内部解决方案，后来发展为商业产品。这个案例说明内部系统可以被持续发展并产品化；它本身不构成制造企业放弃自研、改用外部商业软件的迁移案例。

企业是否需要重新选择，取决于系统能否持续适配业务、流程是否合理、经验是否充分，以及维护责任是否明确。这些要求同时适用于自研和商业软件；它们不会仅因采购方式不同而自动得到满足。

首先，系统需要跟随业务演进。自研系统可以围绕上线时的产品、工艺、设备和管理流程满足需求，但这些条件会变化。如果最初把某些业务条件固定在程序中，后续就可能不断增加判断分支和专用逻辑，使局部修改触及更多模块。可配置、可扩展的设计有助于控制这种影响，但自研团队同样需要为此投入。成熟商业产品有机会将多个客户的共性需求转化为可配置的数据模型、业务规则和扩展机制，并分摊通用缺陷修复与兼容性维护的投入。这些能力仍需在具体产品和实施方案中核实，扩展限制或过度定制也可能使商业系统难以演进。

可以用一个假设场景说明这种变化。某工厂最初开发的 MES 以整批流转为主要管理方式，同一批次中的晶圆按相同路线加工。后来，工艺开发需要将部分晶圆拆出，安排不同的实验步骤，其中一部分还需要返工。此时，增加一个“拆批”按钮只是界面变化，系统还要记录晶圆与原批次、新批次之间的关系，区分加工步骤，并保证生产历史连续可追溯。相关查询、权限、设备接口和报表也可能需要调整，原有数据结构能否表达这些关系，会直接影响修改范围。

修改代码只是变更工作的一部分，相关团队还需要进行影响评估、回归验证、数据迁移和发布准备。尤其当变更影响生产记录时，恢复旧版本程序与恢复正确的业务状态，需要分别考虑。长期扩展的难点，是在支持新场景的同时维持已有行为的正确性。

其次，功能实现需要服务于合理的业务流程。企业熟悉自己的问题，并不意味着已经选定合适的解决方案。现场人员能够描述重复录入、审批等待或信息查询困难，却可能把方案限定为“将这张表搬到系统中”或“给这个环节增加一个按钮”。如果开发需求直接沿用这些描述，软件就可能继续保留原有流程中的重复工作。

例如，假设某工厂的异常处置流程需要多个部门依次填写内容相近的表单。开发团队用 AI 生成电子表单后，纸张传递减少了，但相同批次、设备和异常信息仍需反复录入。业务团队还需要分析哪些信息可以复用、哪些确认与授权必须保留，以及哪些事项可以并行处理，再用重复录入次数、等待时间和记录完整性评价改进效果。只检查页面能否运行，无法回答这些业务问题。

第三，团队需要持续拓宽经验。内部团队可以围绕已经发生的问题开发功能，却未必见过其他工厂处理类似问题的方式。尚未识别的约束，也很难进入需求清单。成熟供应商有机会从多个客户项目中积累经验，并将可复用部分纳入产品，但迁移能否成立，仍取决于业务关系和约束是否相似。内部团队同样可以通过跨工厂协作、行业交流和外部评审积累经验。

第四，软件需要明确的长期维护责任。项目上线后，需要有人持续负责需求取舍、架构调整、版本管理、验证和故障处理。熟悉原始设计的工程师可能转岗或离职，如果设计依据、异常处理逻辑和测试场景没有被保留，新团队就需要重新理解系统为什么这样运行。AI 可以辅助阅读代码、补充测试和整理文档，但源代码未必完整记录当年的业务约束与取舍理由，维护团队仍需核实解释并对变更负责。

这些工作需要持续投入基础设施、监控、备份、安全更新、故障响应、文档和人员交接。即使没有形成对外支付的账单，也会占用内部团队的时间，并影响团队能够用于专有业务改进的资源。采购可以将部分共性维护工作交给供应商，但本地配置、系统集成、定制功能与升级验证由谁承担，仍取决于部署方式、合同范围和实施安排。

当内部团队反复维护通用功能，现有系统又难以跟上生产要求时，采购一个适配的基础平台值得评估。如果企业具备持续开发、验证与运维能力，自研也可以是可行路径。无论选择哪种方式，都应在相近的功能范围、服务水平和使用周期下，比较开发费用、许可或订阅费，以及集成、验证、运维、持续适配、故障影响和未来迁移成本。维护困难可以触发重新评估，但不能单独证明迁移更划算。

企业数字化存在两种不同的推动力量

制造企业内部的软件开发需求，通常受到两种不同力量的推动。一种来自现场工程师，希望尽快解决具体问题；另一种来自企业管理层，希望建立跨部门、跨工厂的一致管理方式。两者关注的范围不同，但都具有合理的业务诉求。理解这种差异，才能判断 AI 加快应用开发后，哪些工作适合由工程师自主完成，哪些工作仍然需要企业级系统与统一治理。

自下而上的工程师创新，通常从一个明确的现场问题开始。工艺工程师为了减少从 HMI 向 Excel 重复复制数据，编写数据采集脚本；质量工程师为了追踪某类缺陷，开发小型分析工具；生产主管为了及时了解批次进度，建立生产看板。这些工具能够直接回应使用者的需求，因为开发者熟悉数据来自哪里、哪些异常值得关注，以及结果将用于什么判断。需求提出者、开发者和使用者之间的距离较短，也便于根据实际使用情况快速调整功能。

不过，解决局部问题所需的条件，与支持企业级协同所需的条件并不完全相同。一个工具在某个部门内使用时，开发者和使用者可能共享许多未写明的约定，例如设备状态如何解释、异常数据如何剔除、某项指标从哪个时点开始计算。这些约定可以通过日常沟通维持，却未必已经形成统一的数据定义和文档。当工具被其他部门采用，或用于比较不同工厂的生产表现时，原先依赖共同经验的部分就需要明确下来。否则，同名指标可能采用不同算法，相似状态也可能代表不同业务含义。

可以用一个假设场景说明这一点。两支工程团队分别开发批次等待时间看板，其中一支将批次暂停期间计入等待时间，另一支为了分析可执行批次的排队情况，排除了暂停期间。两种处理方式都可能适合各自的分析目的，但如果管理层直接将结果汇总，比较不同工厂的等待时间，就可能把计算口径的差异误认为生产表现的差异。此时，问题并不在于某个看板能否运行，而在于数据是否支持同一种解释。即使 AI 能够快速生成两个看板，也不会自动确定企业究竟要比较什么，以及应当使用哪一种统计口径。

自上而下的企业级标准化建设，正是为了处理这类跨部门、跨工厂的关系。管理层需要把生产信息用于资源协调、异常分析和运营决策，因此需要明确共享数据的含义、来源和更新方式，并使相关业务状态能够被连续追踪。MES 等企业级系统可以承担其中的制造执行与生产记录职责，但统一信息并不只靠部署一套软件实现。企业还需要确定哪些规则适用于共同业务，哪些差异来自产品、工艺或设备条件，并在系统中保留这些必要差异。标准化的目的，是让各方能够一致地理解和执行相同规则，而不是把所有工厂的流程强行做成一样。

当局部工具与核心系统之间的边界清楚时，这两种力量可以形成互补。在以 MES 管理批次状态和生产历史的架构中，工程师可以读取相关数据，开发面向特定问题的查询、分析或展示工具。局部工具负责帮助使用者理解信息，核心系统继续按既定规则维护生产记录。如果局部工具进一步需要提交状态变更，则需要通过明确的接口和业务校验完成。这样的分工既保留现场创新的速度，也使共享数据和生产执行规则有清楚的维护责任。

当 AI 辅助工具使局部应用更容易开发时，工具的数量和功能范围也可能扩大。工程师原本只想生成一份分析报表，后来可能增加数据修正、任务分配或审批功能；某个部门使用的小工具，也可能逐渐被其他部门依赖。如果这些扩展缺乏统一治理，原先的辅助工具就可能开始承担正式业务职责，而它的数据来源、权限范围和维护责任却没有同步明确。多个团队还可能分别实现相似功能，形成不同的指标口径、规则版本和更新节奏。每个正式使用的应用，都需要明确的数据来源、权限范围、维护负责人和维护资源，应用之间的依赖也需要纳入变更评估。

因此，现场工程师可以继续提出问题、验证需求，并开发职责清楚的工具；企业则需要为共享数据、生产状态变更和跨部门业务规则建立共同约定。无论核心平台采用自研系统还是商业软件，应用扩展与治理能力都需要同步发展。

商业软件供应商也必须改变

商业软件供应商也需要重新证明自身的价值。自研软件存在长期维护与演进成本，并不能据此认定商业软件天然更优。许可费用、按用户数量收费、供应商锁定，以及购买后长期闲置的功能，都可能削弱采购的经济性。因此，企业需要比较的是具体方案的成本、适配程度和长期交付能力，不能仅凭“成熟商业产品”这一身份判断其价值。

收费方式是否合理，取决于费用增长与实际使用价值之间的关系。例如，在一个假设场景中，工厂希望让更多工程师和生产管理人员查看生产信息。如果系统按用户数量收费，扩大信息访问范围就可能增加许可成本，而新增用户可能只使用少量查询功能。企业因此需要评估，为这些使用场景支付的费用是否与获得的价值相称。类似地，如果采购方案绑定了大量暂时不需要的模块，企业就可能为尚未使用的功能付费。功能清单很长，并不等于这些功能已经进入日常业务，更不等于它们产生了可衡量的收益。

供应商锁定也会影响长期成本。企业对一个系统的依赖，可能逐渐延伸到数据模型、业务配置、接口和定制代码。即使生产数据能够导出，迁移时仍可能需要重新解释历史记录之间的关系、转换业务规则，并验证新系统能否正确支持现有流程。随着这些依赖积累，更换供应商的成本可能上升。因而，接口开放程度、数据可迁移性和扩展机制，都会影响采购决策。客户需要的不只是今天能够接入系统，也包括未来调整架构或更换产品时，仍有可行的选择。

商业系统自身的复杂性同样需要控制。供应商持续增加功能，可以覆盖更多业务场景，但如果模块边界不清楚、配置相互依赖，或者定制功能与基础产品紧密耦合，客户也可能面临培训困难、变更影响难以判断和升级验证范围扩大的问题。此时，功能增长会伴随新的维护负担。供应商需要让新增能力具有清楚的适用范围，并使客户能够按需求采用，而不是每增加一项功能，都让整个系统更难理解和管理。

AI 辅助开发为企业提供了更多可比较的实现路径，也可能帮助供应商提高交付效率。双方的成本都会受到影响，竞争压力需要结合实际方案判断。对于职责清楚的报表、查询工具或接口适配应用，企业可能通过 AI 辅助开发获得替代方案，也可能在现有平台上自行扩展。这并不意味着企业能够轻易替换核心 MES，但它会改变部分功能的采购依据：当相近的业务效果可以通过较低成本的方式实现时，供应商就需要解释，其收费还包含哪些持续服务，以及这些服务如何减少客户的工作和风险。竞争压力由此从功能是否存在，延伸到功能交付、维护和演进是否值得付费。

对于半导体制造企业，这种价值需要落实到具体的工程工作中。假设工厂需要增加一项批次追溯分析功能，供应商的价值可以体现在提供含义清楚的数据、支持稳定的访问接口，并在产品升级后维持约定的兼容性。客户因此可以将精力集中在分析逻辑上，减少对底层关系和接口变化的重复处理。相反，如果每次增加查询都需要重新定制，每次升级又需要大量修复，那么商业平台原本承诺节省的工作，仍可能由客户承担。这个例子说明，平台价值需要通过实际交付来验证，不能只看它是否提供了一个追溯页面或一组接口。

采购长期服务时，企业还需要明确产品更新、安全补丁、适用的法规变化支持和架构升级是否包含在合同内、支持多久，以及客户需要承担哪些升级工作。供应商持续创新能力也应当按照实际交付来评价。制造业务变化后，供应商能否及时支持新的物料关系、工艺流程和设备交互方式，以及能否让客户以可接受的工作量采用这些能力，比单纯增加功能数量更有意义。可靠性则需要体现在日常运行、故障处理和版本变更中，包括问题能否被定位、修复是否及时，以及升级后既有业务是否仍然正确。已经交付并经过验证的功能，可以作为当前能力的依据；未来支持承诺则需要结合合同、供应商记录和兑现风险评估。产品路线图可以帮助客户判断方向，但不能直接视为已经获得的能力。

因此，AI 带来的竞争压力，不只是要求商业软件供应商更快地编写代码，也要求它们更清楚地证明收费、持续服务与客户收益之间的关系。合理的采购仍然可以为制造企业分担长期的软件工程责任，但这项价值需要通过产品能力、实施效果和持续支持来体现。随着企业获得更多自主开发选择，商业软件供应商需要以更适配的收费方式、更清楚的扩展边界和可信的交付记录，持续获得客户的选择。

企业究竟应该开发什么，又应该采购什么？

企业决定开发什么、采购什么，可以从不同业务能力的价值出发，再确定系统的实现方式。对于能够体现企业专有知识、需要持续自主调整，并且有助于形成竞争优势的能力，自研值得重点考虑。对于工单管理、生产追溯、电子批次记录等需求，企业可以优先评估成熟产品是否提供适配的基础机制。功能名称通用，并不意味着具体实现可以直接标准化，还需要区分可复用的基础能力、工厂特有配置与差异化策略。

判断一项能力是否具有差异化价值，需要看它如何影响实际业务。专有工艺知识、特殊生产逻辑、独有的数据处理方法，以及围绕特定制造条件形成的系统集成，可能帮助企业更快地识别问题、作出更合适的决策，或支持商业产品尚未覆盖的生产方式。不过，“只有本厂这样做”并不足以证明某项功能构成竞争优势。企业还需要确认，这种差异是否带来了可验证的效果，以及是否值得长期维护。仅仅源于历史习惯的特殊流程，如果没有明确价值，就不宜因为 AI 能够快速实现而被永久固化。

对于真正有价值的专有能力，企业需要掌握其业务定义、关键数据、判断逻辑和验证依据。自主掌握这些内容，并不要求每一行代码都从零编写。企业可以使用现有框架、商业平台的配置能力或扩展接口，实现自己的规则与算法。AI 可以辅助生成代码、构建测试和整理文档，加快工程实现；业务团队和开发团队则需要共同确认，这些实现是否准确表达了企业的知识，以及在什么条件下适用。这样，关键能力才能被明确记录、持续改进，并在人员或技术平台变化后继续使用。

通用能力的采购价值，则体现在减少重复建设及其后续维护。工单管理需要维护任务及其执行状态，生产追溯需要保留物料与加工历史之间的关系，电子批次记录需要组织和保存相关执行信息。这些功能看似能够较快开发，但投入使用后仍需处理异常情况、权限、版本变化和接口兼容。如果成熟平台能够满足本厂的业务要求，企业就可以复用这些基础能力，将开发重点放在尚未被充分解决的问题上。具体产品是否适用，仍需要通过场景验证，不能仅凭“行业通用功能”的名称判断。

可以用一个假设场景说明这种分工。某晶圆厂已经使用 MES 管理批次状态和生产历史，但希望根据自身瓶颈设备的特点，开发一套批次优先级计算方法。在这个场景中，企业可以保留已有的生产记录与状态管理能力，自主开发计算逻辑，通过约定接口读取所需数据，并将排序建议交给既有派工流程使用。内部团队的投入集中在如何表达本厂的生产约束、如何平衡不同目标，以及如何验证排序结果。它不必为了实现这套方法，同时重新开发整套工单、追溯和批次记录功能。能否采用这一方案，取决于现有平台是否提供合适的数据与接口，以及新增逻辑能否与既有业务规则协调。

在成熟平台上构建专有功能，也需要清楚的扩展边界。如果客户功能依赖平台内部未公开的数据结构，或必须反复修改基础代码，平台升级就可能带来较大的适配工作。稳定的接口、明确的数据含义和可验证的扩展机制，因而也是采购价值的一部分。企业需要同时考虑功能能否接入、升级后能否继续运行，以及未来更换平台时关键逻辑是否能够迁移。平台负责哪些基础能力、内部团队维护哪些扩展，应当在方案中明确下来。

这一原则提供的是资源配置方向，而不是对所有系统作出统一结论。如果商业产品无法覆盖关键制造要求，扩展受到明显限制，或采购与集成的长期成本不合适，企业仍可以评估更大范围的自研。相应地，企业也需要具备持续开发、验证和运维这些能力的条件。优先掌握具有差异化价值的能力，在适配和经济性成立时复用成熟的基础能力。如果复用成熟平台能够减少重复工作，企业就可以将节省的资源投入专有知识、业务改进和关键能力的持续发展，让 AI 加快更值得完成的工作。

自研、采购与 AI Agent 如何协作？

沿着上述判断，制造企业可以进一步考虑，自研能力、采购平台与 AI Agent 如何在同一套受控制造架构中协作。自研与采购主要决定能力由谁开发和维护，AI Agent 则是一种可以嵌入这些能力的实现方式。三者可以组合使用，具体划分应取决于工厂需求、平台能力和验证结果。

例如，经验证、可持续维护的平台承担核心生产记录和事务，企业掌握关键工艺知识、生产决策逻辑及其验证依据，AI Agent 在明确的数据访问范围和任务权限内，辅助分析或调用既有流程。这里的平台既可以是商业产品，也可以是企业自研系统。这一方向是本文对前述讨论的工程延伸，具体划分仍需由工厂验证。

AI 辅助开发与 AI Agent 在运行时执行任务，还需要分别管理。前者生成的代码可以经过审阅、测试和发布后进入系统；后者则会根据运行时输入选择动作，其执行范围需要由接口权限、业务规则和验证机制共同限定。如果模型只参与开发，程序发布后可以独立运行，模型服务中断主要影响后续开发效率；如果应用在运行时持续调用模型，服务可用性、调用成本和模型行为变化就可能直接影响业务功能，更换模型也可能需要重新验证。

Agent 可以整理异常信息、解释派工结果或提交授权范围内的请求，但请求是否允许执行，应由负责业务校验的系统环节依据当前状态和规则判断。对于不满足条件或无法完成验证的请求，需要有明确的拒绝、降级或转交处理方式。这样，动态分析可以参与业务流程，生产约束也有清楚的执行位置和责任归属。

AI 时代的软件选择，最终需要同时回答三个问题：所需功能能否实现，系统能否持续可靠运行，以及执行结果是否改善了业务。企业可以根据场景验证与生命周期成本比较，采购适配的基础能力，自主发展具有差异化价值的工艺与决策逻辑，并逐步验证 AI Agent 适合承担的任务。开发速度影响想法能够多快被实现；工程可靠性决定系统能够承担什么责任；业务评价检验这些投入是否转化为实际价值。