你的软件工厂有多开放？|上下文|代码|工作流|工厂

你的工厂越来越聪明。你能把这份智能带走吗？

在把公司的工作交给软件工厂之前，先问两个问题：你能不能把上下文带进去，以及，你能不能把它学到的东西带出来？第一个问题从来不缺关注。接仓库、灌文档、配工具、告诉代理团队是怎么干活的，这些事大家都在做。

第二个问题的分量，随着每一次运行都在变重。工程师解释架构决策，评审者纠正反复出现的错误，事故暴露出那些从来没被写下来的约束，评估确立了什么样的产出算合格。时间一长，工厂积累起一套对这家公司业务越来越值钱的理解。

如果你换了模型、编码代理、运行框架或者整个工厂，这份理解有多少能跟你走？一个接受你的知识、却把学到的东西锁死的工厂，是一扇单向门。

有价值的产出不只是代码

传统制造业的比方有助于说明其中的利害。买一件制成品，并不会自动获得生产它所需的知识。你拿到的是产出，制造商留下的是过程知识：怎么处理异常、怎么检测缺陷、怎么让下一轮生产更好。这通常是一笔划算的买卖，大多数公司本来就该买通用组件。但当生产过程中包含的正是让业务与众不同的那部分知识时，这份知识在哪里积累，就变成了一个战略选择。

在 AI 驱动的软件工厂里，知识是人帮着造出来的。人提供上下文、展示判断力、解释一个看起来合理的答案为什么是错的。运营过程则揭示产出的软件到底能不能用。工厂产出代码，同时也产出对这家公司如何造软件更深的理解。

你可以拥有生成的每一行代码，却依然依赖某一个平台来承载产生这些代码的理解。丢掉这份理解，意味着要花钱重建决策、重新发现例外、把同样的教训再讲一遍。代码能离开，诀窍留在了原地。

开放组件只是起点

让工厂变开放，有几条现成的路：支持多种模型、接入外部编码代理、跑在客户自己控制的环境里、为现有工具暴露接口。每一条都创造了有价值的自由度。但没有哪一条能单独告诉你，生产过程中积累的知识，能不能搬到别处去。

下一个问题关乎在这套基础设施内部积累的知识：你能检查、提取出什么，并把它独立地重新投入使用？信息留在你的环境里，解决的是一层顾虑；能在模型之间做选择，解决的是另一层；把维护中的技能、架构决策、评估用例、学到的约束带进另一套生产系统，解决的是又一层依赖。

一个开放的软件工厂应该让这件事成为可能。它的上下文和学习成果，应该在你的控制下保持可理解、可治理、可复用，拥有超越任何单一组件或供应商的生命周期。

带进你的上下文

组织里本来就有值得用的知识，它们散落在仓库、内部文档、工单、架构决策、业务系统和人的经验里。把上下文带进来，意味着把这些理解接到工作上，而不是要求公司在一个新产品里把自己重新造一遍。

连接器能取回一份文档，但有用的上下文还得告诉代理：这份文档是不是最新的、哪份协议优先、例外在哪里适用。来源、权限和关系，和文本本身一样重要。

工厂应该容纳你已有的技能和指令、你的模型网关、你的评估、你的可观测性、你的审批流程。这些系统已经跑通的地方，就是你带进来的生产能力的一部分。你还应该能带进自己的循环——从现成的工作流开始，改进它，或者用一套反映自身要求的加固流程替换它。公司需要掌控上下文如何收集、动作如何检查、反馈如何并入。

把学到的东西带走

设想一个编码代理绕过了内部服务，直接写数据库。实现看起来合理，但漏掉了服务提供的授权和审计行为。评审者抓住了它，并解释了这个服务为什么存在。