北京
你的工厂越来越聪明。你能把这份智能带走吗？
在把公司的工作交给软件工厂之前，先问两个问题：你能不能把上下文带进去，以及，你能不能把它学到的东西带出来？第一个问题从来不缺关注。接仓库、灌文档、配工具、告诉代理团队是怎么干活的，这些事大家都在做。
第二个问题的分量，随着每一次运行都在变重。工程师解释架构决策，评审者纠正反复出现的错误，事故暴露出那些从来没被写下来的约束，评估确立了什么样的产出算合格。时间一长，工厂积累起一套对这家公司业务越来越值钱的理解。
如果你换了模型、编码代理、运行框架或者整个工厂，这份理解有多少能跟你走？一个接受你的知识、却把学到的东西锁死的工厂，是一扇单向门。
有价值的产出不只是代码
传统制造业的比方有助于说明其中的利害。买一件制成品，并不会自动获得生产它所需的知识。你拿到的是产出，制造商留下的是过程知识：怎么处理异常、怎么检测缺陷、怎么让下一轮生产更好。这通常是一笔划算的买卖，大多数公司本来就该买通用组件。但当生产过程中包含的正是让业务与众不同的那部分知识时，这份知识在哪里积累，就变成了一个战略选择。
在 AI 驱动的软件工厂里，知识是人帮着造出来的。人提供上下文、展示判断力、解释一个看起来合理的答案为什么是错的。运营过程则揭示产出的软件到底能不能用。工厂产出代码，同时也产出对这家公司如何造软件更深的理解。
你可以拥有生成的每一行代码，却依然依赖某一个平台来承载产生这些代码的理解。丢掉这份理解，意味着要花钱重建决策、重新发现例外、把同样的教训再讲一遍。代码能离开，诀窍留在了原地。
开放组件只是起点
让工厂变开放，有几条现成的路：支持多种模型、接入外部编码代理、跑在客户自己控制的环境里、为现有工具暴露接口。每一条都创造了有价值的自由度。但没有哪一条能单独告诉你，生产过程中积累的知识，能不能搬到别处去。
下一个问题关乎在这套基础设施内部积累的知识：你能检查、提取出什么，并把它独立地重新投入使用？信息留在你的环境里，解决的是一层顾虑；能在模型之间做选择，解决的是另一层；把维护中的技能、架构决策、评估用例、学到的约束带进另一套生产系统，解决的是又一层依赖。
一个开放的软件工厂应该让这件事成为可能。它的上下文和学习成果，应该在你的控制下保持可理解、可治理、可复用，拥有超越任何单一组件或供应商的生命周期。
带进你的上下文
组织里本来就有值得用的知识，它们散落在仓库、内部文档、工单、架构决策、业务系统和人的经验里。把上下文带进来，意味着把这些理解接到工作上，而不是要求公司在一个新产品里把自己重新造一遍。
连接器能取回一份文档，但有用的上下文还得告诉代理：这份文档是不是最新的、哪份协议优先、例外在哪里适用。来源、权限和关系，和文本本身一样重要。
工厂应该容纳你已有的技能和指令、你的模型网关、你的评估、你的可观测性、你的审批流程。这些系统已经跑通的地方，就是你带进来的生产能力的一部分。你还应该能带进自己的循环——从现成的工作流开始，改进它，或者用一套反映自身要求的加固流程替换它。公司需要掌控上下文如何收集、动作如何检查、反馈如何并入。
把学到的东西带走
设想一个编码代理绕过了内部服务，直接写数据库。实现看起来合理，但漏掉了服务提供的授权和审计行为。评审者抓住了它，并解释了这个服务为什么存在。
眼前的修复是一个更好的拉取请求。更持久的改进可能是几样产物：
- 一份架构决策，说明这条边界和它的理由
- 一项技能，描述这类改动该怎么做
- 一个评估用例，检查代理是否尊重这条边界
- 一项自动化检查，在评审之前就抓住违规
这些产物把一次纠正变成能指导未来工作的知识。当另一位开发者、代理或工作流接手时，它们应该仍然可用。导出的对话记录是对话的证据，但它不一定告诉你哪条教训被采纳了、适用于哪里、或者如何验证另一个系统是否正确使用了它。
有用的提取要保留含义。一条教训需要它的来源、适用范围、评审状态和支持证据。一项技能需要它的依赖。一个评估需要足够的环境信息才能重新运行。这也是为什么学习需要判断力。一个变通做法不应该悄悄变成政策。一个临时例外不应该变成通用规则。必须有人决定什么值得保留，并检验所提议的改进是否真的有用。
一个务实的起点，是把开发工作中反复出现的问题，转化为对技能和工作流的改进。这些改进
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
