过去半年我发现很多团队对 AI 编程的抱怨正在悄悄变化模型生成得“准不准”已经不是首要矛盾“产出物管不管得住”变成了新的瓶颈。代码从一个对话框里来技术方案从另一个对话框里来中间还有 AI 画的原型图、整理的测试数据、写的发布说明。这些东西都有一个共同的称呼——AI ArtifactsAI 产物而它们目前的存放方式基本等于散落在聊天记录里的“第 3 版”“最终版 2”。很多人以为这只是个人使用习惯问题但在团队协作里它已经上升到工程失控的程度同一个 AI 生成的代码补丁有人提交了有人覆盖了有人根本不知道存在过。而工作流Workflow就更麻烦一个多步骤的 AI 任务——比如“先读代码库、再生成变更建议、然后按规范跑测试”——每次都要重新组织一遍提示词没有人能把它当作一个可复用的资产。这正是 Derive 这类项目出现的背景它试图给 AI artifacts 和 workflows 一个“开放的家”。这看起来像是一个分门别类的网盘但实际上它踩中的是 LLM 应用工程化的下一层基础设施从“生成”走向“治理”。这篇文章会先讲清楚 AI artifacts 和 workflows 为什么值得被当作独立技术资产再拆解一个“开放家园”应该具备哪些核心能力最后给出一个最小可跑的 Artifact Hub 原型设计。看完之后你不仅能理解 Derive 背后的设计思路也能在自己的项目里快速搭出一套 AI 产物管理框架。1. 这篇文章真正要解决的问题先做一个判断AI 开发的下一个阶段不是模型更强而是产物可管。现在团队里最常见的协作模式是什么一个人打开 Claude 或 Cursor生成了代码然后复制粘贴到 IDE提交进 Git 仓库。AI 生成的文档呢转成 PDF 丢进群里。AI 生成的架构图呢截个图放进飞书或者 Notion。看起来每个环节都有工具但问题是这些工具之间没有任何关联。Git 记录了代码变更但没记录这段代码是哪次对话、哪条 prompt、哪个模型版本生成的。Notion 记录了文档但没记录文档背后的原始材料和工作流。于是出现了三个很现实的痛点第一不可追溯。出问题时想知道“这个代码是谁让 AI 改的、基于什么上下文改的”几乎不可能。第二不可复用。一次精心设计的 AI 工作流跑完就丢了下次要重复时只能重新组织 prompt。第三不可组合。AI 产出的数据、代码、文档、配置是割裂的无法像软件包一样被依赖、叠加、升级。如果这些问题只出现在个人开发者的业余项目里尚可忍受。但当团队规模超过 5 人或者项目进入维护期这种“对话式开发”的产物管理成本会指数级上升。Derive 这类项目的重要意义就在这里它尝试把这些散落的 AI 产物统一收纳并提供版本、元数据、工作流编排能力。换句话说它想让 AI 开发从“写出来的产物”变成“管起来的资产”。这篇文章适合三类读者已经在团队中使用 AI 辅助开发的工程师正在设计企业内部 AI 平台的技术负责人以及对 LLM 应用工程化感兴趣的研究者。如果你还停留在“AI 只是帮我写代码”的阶段这篇文章可能会提前帮你看到下一步的基础设施形态。2. AI Artifacts 与 Workflows概念边界与适用场景2.1 什么是 AI ArtifactsAI Artifact 是指由 AI 模型生成或深度参与的产出物包括但不限于代码片段、完整文件、Pull Request 描述、测试用例、架构图、数据分析报告、SQL 语句、配置文件、Prompt 模板等。这里需要和两个相近概念做区分。首先是普通“文件”。一个由 AI 生成、但之后被人工大量修改的代码文件在物理上就是一个普通文件但它在元数据上不是它保留着 AI 生成时的上下文、模型信息、父级 prompt这些信息在普通文件系统里完全没有位置。其次是“AI 回复”。对话平台中的每一次回复都是 AI 产物但多数时候它们被当作一次性消息处理没有人给它们编号、建索引、记录版本。Derive 对 AI Artifacts 的理解更接近“一级公民”一个 artifact 应该有独立 ID、版本、类型、来源模型、上游依赖和下游引用。它不是聊天记录里的附件而是像 Git 对象一样可寻址、可引用的实体。2.2 什么是 AI WorkflowsAI Workflow 则是一组有顺序的 AI 操作步骤。举个例子一个典型的“代码变更建议”工作流包含读取仓库结构、分析指定文件、生成变更建议、运行静态检查、总结变更影响。这个过程如果每一步都是人工在对话框里操作既无法保证一致性也无法复用。Workflow 的抽象价值在于它把一次性的对话过程变成了结构化的计算图。每个步骤有输入、输出、工具调用和验证方式。这样一个工作流就可以像函数一样被调用输入不同项目参数复用同一套 AI 推理流程。2.3 为什么现成的 Git、网盘、知识库不够用有人会问Git 加对象存储加 Wiki 不就能管理这些吗理论上能实际很勉强。Git 擅长管理文本文件的版本但 AI 产物并不都是文本也可能是二进制的图片、音频、模型权重。更关键的是Git 的 commit 结构不包含“这个文件是从哪个模型、哪条 prompt、哪个工具调用链产生的”这类信息。网盘只能解决文件的存储共享不解决元数据、版本之间的关系和依赖。知识库如 Notion、Confluence解决了文档的组织但不适合存储高频产生、结构化的数据对象。所以 Derive 的定位是很聪明的它既不是代码仓库也不是网盘更不是文档知识库而是介于三者之间的一种新类型——专门为 AI 产物设计的资产管理平台。它允许每个 artifact 有自己的生命周期也允许 workflow 作为一等公民存在而不是散落在文档里的“标准操作流程”说明。3. 从对话生成到资产治理Derive 类项目需要解决的三个核心问题如果把“AI 产物管理”看作一个完整的系统工程Derive 类项目需要回应三个问题可追溯性、可复用性、可组合性。下面逐一展开。3.1 可追溯性知道每份产物从哪来、如何验证AI 开发与传统软件开发最大的区别在于产物的来源不可确定性。传统代码由人类编写提交信息基本能说明“为什么这么写”。AI 产物则由模型生成同一段代码不同模型、不同温度、不同 prompt 会产生完全不同的结果。可追溯性要求在 artifact 上记录足够多的 provenance来源信息。谁创建的、用的哪个模型、温度参数是什么、输入了哪些上下文、在什么时间生成这些信息看似琐碎但在生产事故排查时非常关键。具体来说追踪链应该包含三个层次请求级用户输入的 prompt、模型参数、使用的工具。产物级生成结果、后处理步骤、人工修改记录。依赖级该 artifact 依赖了哪些上游 artifact 或外部资源。没有这些信息AI 生成的代码一旦上了生产环境出问题后将无法定位是模型能力问题、Prompt 设计问题还是人工改造问题。Derive 的思路是让这些信息成为每一份产物的标配元数据。3.2 可复用性不让工作流变成一次性消耗品我在很多团队看到这样的场景A 同学花了一个小时精心设计了一套 prompt 链条用于从需求文档中提取测试用例效果很好。B 同学下个月也遇到了类似任务却不知道这套流程的存在又花了一个小时重新设计。这就是典型的 AI 工作流不可复用问题。Workflow 的可复用化远远不只是保存一段 Prompt 那么简单。它需要将每个步骤的工具调用、校验规则、输出格式全部结构化。比如一个“提取需求并生成测试用例”的工作流每个步骤都应该有明确的输入 schema 和输出 schema定义好错误处理逻辑和重试方式。Derive 将 workflow 作为一等公民带来的直接收益是团队可以把运行良好的 AI 流程沉淀成标准化模板新项目直接引用而不是重新发明轮子。3.3 可组合性让产物像积木一样被搭建第三层是可组合性这可能是最有工程想象力的一部分。当 artifacts 和 workflows 都是可寻址的实体时它们之间就可以互相引用、组合形成新的产物。举个例子一个数据分析报告 artifact可以由一个“数据清洗 workflow”和一个“图表生成 workflow”组合而成。用户修改了上游数据下游报告可以重新生成用户调整了图表风格报告自动更新。这已经类似传统软件工程中的包管理、依赖注入、管道编排。在 Derive 的框架下一个 workflow 的输出可以作为另一个 workflow 的输入一个 artifact 的版本可以被另一个 artifact 稳定引用。这种设计把 AI 开发从“一次性对话”变成了“可组装流水线”。4. 架构拆解一个“AI 产物开放家园”应该具备哪些能力前面讲的是理念这一节落到架构。一个面向 AI artifacts 和 workflows 的开放平台至少应该包含以下五个能力模块。4.1 对象存储层为任何类型的产物提供物理位置Artifact 的类型千差万别文本、JSON、PNG、PDF、Python wheel、嵌入向量都可能成为产物。因此底层需要一个与类型无关的存储层。设计上推荐使用对象存储如 MinIO、S3、本地磁盘目录作为叶子存储每个 artifact 映射为一个对象键形如artifacts/{id}/{version}/{filename}。这个设计保证了扩展性也让中继代理代理对象存储和多种后端可以并存。4.2 元数据与索引层让产物可搜索、可引用只有存储没有元数据仍然相当于一个只支持绝对路径的网盘。元数据层至少需要维护以下字段基础字段name、type、version、creator、created_at。provenance 字段model_id、prompt_hash、temperature、tool_chain。关系字段upstream_artifact_ids、downstream_artifact_ids、workflow_id。自定义标签便于按项目、模块、团队维度筛选。元数据最好存储在事务性数据库如 PostgreSQL中并建立组合索引便于按(project, type, version)等模式查询。4.3 工作流引擎层调度 AI 步骤的执行工作流引擎负责将 workflow definition 解析为可执行步骤并调度模型调用、工具调用、人工审批。它并一定需要像 Airflow 那样复杂但至少需要具备步骤编排支持线性顺序、条件分支、并行执行。输入输出映射每一步读取上方产物输出落到 artifact 存储。可重试机制模型调用失败时有限次重试。人工审查点高风险操作如代码合并、数据删除前暂停。4.4 API 层开放的读写接口一个“开放的家园”必然要求 API 优先。核心接口包括创建/读取/更新/删除 artifact。发布/执行/检索 workflow。查询 artifact 的依赖关系与版本历史。注册新模型源或工具源。API 设计需要遵循 REST 或较新实践中常用的 JSON-RPC并支持 API Key 认证。这样不仅网页端可以使用IDE 插件、CLI 工具、CI/CD 流水线也都能接入。4.5 权限与审计层多租户与合规基础最后是权限。AI 产物涉及代码、数据、内部文档权限控制不是可选项。需要支持项目级隔离、角色级权限管理员、开发者、只读者、以及完整的审计日志。尤其是 workflow 中的自动操作每步执行都应该留下可审计的记录。5. 用最少代码实现一个 Artifact Hub 原型理解了架构之后下面用 FastAPI 加 PostgreSQL 实现一个最小版本覆盖 artifact 的注册、查询、版本管理以及简单的 workflow 定义。这个示例不绑定 Derive 的具体实现但展示了一致的核心思路。5.1 环境准备建议环境如下Python 3.10 以上。FastAPI 与 Uvicorn。SQLAlchemy 2.x。PostgreSQL 15也可以用 SQLite 代替演示。Docker Compose可选用于一键启动数据库。安装依赖pip install fastapi uvicorn sqlalchemy psycopg2-binary pydantic requests如果不想安装 PostgreSQL本地演示可以直接将后文中的连接串改为sqlite:///./artifact_hub.db但不推荐生产环境使用。5.2 数据模型设计首先定义 artifacts 与 workflows 两张表。# 文件路径models.py from datetime import datetime from sqlalchemy import ( Column, String, Integer, Text, DateTime, JSON, BigInteger, ForeignKey ) from sqlalchemy.ext.declarative import declarative_base Base declarative_base() class Artifact(Base): __tablename__ artifacts id Column(BigInteger, primary_keyTrue, autoincrementTrue) name Column(String(256), nullableFalse, uniqueTrue) artifact_type Column(String(64), nullableFalse) # code / doc / image / data / workflow version Column(String(64), nullableFalse, defaultv0.1) source Column(String(128)) # 来源如 claude-3.5-sonnet prompt_hash Column(String(64)) # 生成时的 prompt 哈希用于追溯 summary Column(Text, default) storage_url Column(String(512), nullableFalse) created_at Column(DateTime, defaultdatetime.utcnow) updated_at Column(DateTime, defaultdatetime.utcnow, onupdatedatetime.utcnow) class Workflow(Base): __tablename__ workflows id Column(BigInteger, primary_keyTrue, autoincrementTrue) name Column(String(256), nullableFalse, uniqueTrue) definition Column(JSON, nullableFalse) # 结构化 workflow 定义 input_artifact_ids Column(JSON, defaultlist) output_artifact_id Column(BigInteger, ForeignKey(artifacts.id), nullableTrue) status Column(String(32), defaultpending) created_at Column(DateTime, defaultdatetime.utcnow)这里的prompt_hash字段很关键它记录了生成产物的提示词摘要方便后续审计又避免了直接存储完整 prompt 带来的空间浪费与敏感信息泄露。5.3 API 代码注册与查询 Artifact接下来是 API 层提供两个核心端点。# 文件路径main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from typing import Optional, List from sqlalchemy import create_engine from sqlalchemy.orm import sessionmaker from models import Base, Artifact, Workflow DATABASE_URL postgresql://artifact:artifactlocalhost:5432/artifact_hub engine create_engine(DATABASE_URL) SessionLocal sessionmaker(bindengine) Base.metadata.create_all(bindengine) app FastAPI(titleArtifact Hub) class ArtifactCreate(BaseModel): name: str artifact_type: str version: str Field(defaultv0.1) source: Optional[str] None prompt_hash: Optional[str] None summary: Optional[str] None storage_url: str class ArtifactOut(ArtifactCreate): id: int created_at: str app.post(/api/artifacts, response_modelArtifactOut) def create_artifact(payload: ArtifactCreate): db SessionLocal() exists db.query(Artifact).filter(Artifact.name payload.name).first() if exists: db.close() raise HTTPException(status_code409, detailartifact name already exists) artifact Artifact(**payload.dict()) db.add(artifact) db.commit() db.refresh(artifact) result { id: artifact.id, name: artifact.name, artifact_type: artifact.artifact_type, version: artifact.version, source: artifact.source, prompt_hash: artifact.prompt_hash, summary: artifact.summary, storage_url: artifact.storage_url, created_at: artifact.created_at.isoformat(), } db.close() return result app.get(/api/artifacts/{name}, response_modelArtifactOut) def get_artifact(name: str): db SessionLocal() artifact db.query(Artifact).filter(Artifact.name name).first() db.close() if not artifact: raise HTTPException(status_code404, detailartifact not found) return { id: artifact.id, name: artifact.name, artifact_type: artifact.artifact_type, version: artifact.version, source: artifact.source, prompt_hash: artifact.prompt_hash, summary: artifact.summary, storage_url: artifact.storage_url, created_at: artifact.created_at.isoformat(), }这段代码虽然简单但已经展示了三个关键机制模型字段与表结构对应、创建时对重名 artifact 进行冲突保护、返回时序列化为结构化 JSON。核心逻辑不复杂实际工程中需要补充的是鉴权和对象存储的预签名 URL 生成。5.4 工作流注册与执行示例再提供一个 workflow 端的示例用于演示 AI 工作流如何被结构化。# 文件路径workflow_demo.py import json import requests def define_naming_workflow(): workflow_definition { name: code_review_suggestion, steps: [ { step_id: read_repository, tool: repository_reader, input: {path: {project_path}}, }, { step_id: analyze_diff, tool: llm_analyzer, input: { model: claude-3.5-sonnet, prompt_template: 请分析以下变更并给出风险建议, depends_on: [read_repository], }, }, { step_id: check_result, tool: static_checker, input: {depends_on: [analyze_diff]}, }, ], output: analyze_diff.result, } resp requests.post( http://localhost:8000/api/workflows, json{name: code_review_suggestion, definition: workflow_definition}, ) resp.raise_for_status() return resp.json()这里定义了一个三步工作流读仓库、大模型分析、静态检查。每步声明了依赖执行引擎可以据此构建有向无环图支持并行调度和条件执行。这个结构化定义就是 workflow 可复用的基础——它不是一串自然语言 Prompt而是一份可执行、可校验、可版本化的 JSON 配置。5.5 启动与试运行启动 API 服务uvicorn main:app --reload --port 8000如果是本地 Docker 方式启动 PostgreSQLdocker run -d \ --name artifact-postgres \ -e POSTGRES_DBartifact_hub \ -e POSTGRES_USERartifact \ -e POSTGRES_PASSWORDartifact \ -p 5432:5432 \ postgres:15注册一个 artifactcurl -X POST http://localhost:8000/api/artifacts \ -H Content-Type: application/json \ -d { name: payment-module-refactor, artifact_type: code_diff, version: v0.1, source: claude-3.5-sonnet, prompt_hash: a3f5c2e8b9d14e7a, summary: 支付模块重构建议包含异常处理优化, storage_url: s3://artifacts/payment-module-refactor/v0.1/diff.patch }查询 artifactcurl http://localhost:8000/api/artifacts/payment-module-refactor预期返回 JSON包含上面注册的所有字段以及数据库自动生成的 id 和 created_at。6. 运行结果与效果验证启动并注册成功后如何判断这套 Artifact Hub 真正可用我建议用三个标准验证。第一接口层验证。创建、查询、版本更新三个基本操作全部返回正确状态码。这是最表面的验证但能快速发现数据库连接、字段序列化问题。第二数据层验证。进入 PostgreSQL 查看 artifacts 表的记录确认prompt_hash、storage_url等元数据字段都正确入库而不是被丢弃或截断。SELECT id, name, artifact_type, version, source, prompt_hash, created_at FROM artifacts;如果prompt_hash出现在查询结果里说明元数据链路是通的。如果为空大概率是请求体中没有传入对应字段可以检查 API 请求 JSON 是否完整。第三业务层验证。将一个真实场景接入该 Hub比如把一次 AI 代码审查的产出物注册成 artifact然后二次消费。这里推荐做一个“上传后读取”闭环注册一个 code_diff artifact再用脚本读取它并交给下游检查工具处理。artifact requests.get(http://localhost:8000/api/artifacts/payment-module-refactor).json() print(Artifact 类型:, artifact[artifact_type]) print(来源模型:, artifact[source]) print(存储路径:, artifact[storage_url])输出三行信息并且存储路径可以被后续步骤直接引用就算跑通了最小闭环。如果最终目标是复现 Derive 的完整能力还需要补充 workflow 的异步执行和回调通知但这套原型已经能够验证最关键的一条主线AI 产物是可注册、可查询、可追踪元数据的结构化资产。7. 常见问题与排查思路在实际搭建和运行这类系统时有下面几个高频问题整理成表格供参考。问题现象可能原因排查方式解决方案创建 artifact 返回 409 冲突同名 artifact 已存在但用户误认为更新操作查询当前记录与创建请求的 name 字段明确语义创建接口默认拒绝重名需要更新时调用版本化接口prompt_hash字段一直为空客户端未传该字段或模型层尚未接入打印服务端收到的请求体检查字段名称在 SDK 中统一计算 prompt_hash 并注入请求数据库连接失败PostgreSQL 未启动或端口被占用执行docker ps检查容器状态尝试 psql 连接确认连接串与端口映射一致必要时重启容器workflow 执行步骤互相依赖但顺序错乱定义中缺少depends_on或者依赖字段拼写错误打印 workflow definition检查每个 step 的依赖字段为每个步骤显式声明依赖采用 DAG 校验器提前检查发布 artifact 后下游无法引用下游引用了旧版本对象键或storage_url是临时地址对比下游代码中的存储路径与库中存储值使用 artifact ID 加版本号作为引用标识不要直接硬编码对象键存储大量图片或模型后元数据查询变慢元数据表记录了无关的二进制信息索引缺失查看慢查询日志分析查询条件将大文件元数据拆分对常用查询字段建立组合索引删除 artifact 后 workflow 历史执行记录失效外键关系设计不够清晰查找 workflow 中引用已删除 artifact 的步骤采用软删除或归档策略保留历史引用快照需要特别提醒的是在真实项目中artifact 一旦被 workflow 引用最好不要做物理删除。更安全的做法是软删除在表中增加deleted_at字段查询时过滤而不是直接删行。这能避免“下游正引用着某个 artifact上游却被删了”的连锁故障。8. 最佳实践与工程建议把原型系统放到真实团队环境还有几个工程化建议值得提前考虑。8.1 版本策略不要用“最终版”这种命名AI 产物的版本号应该遵循明确的规范。对于代码类产物可以直接对齐 Git commit。对于非代码类产物推荐使用语义化版本SemVer或者增加时间戳。比较推荐的一种模式是v{major}.{minor}.{patch}-{timestamp}例如v1.2.0-202502011330。保证“版本不可变”也很重要一旦某个 artifact 版本对外发布就不能修改内容只能新增版本。这与镜像仓库、NPM 包的管理哲学一致——不可变版本是构建可组合性的基础。# 推荐命名规范 {artifact-name}:{semver}-{yyyyMMddHHmm} # 示例 payment-module-refactor:v1.2.0-2025020113308.2 溯源信息该记录的必须记录很多人提交 artifact 时只填名字和类型这远远不够。至少应该记录模型名称、模型版本、API 调用参数、完整 Prompt 的哈希、人工修改记录。人工修改记录尤其重要因为经过大量人工修改的产物其“AI 属性”已经减弱审计时要把人工改动和 AI 生成部分区分开。8.3 权限控制隔离比共享更重要一个团队刚开始搭建 Artifact Hub 时往往倾向于全部共享这会在后期带来巨大麻烦。AI 产物可能内含敏感客户数据、未公开的业务逻辑、内部架构信息建议从一开始就建立项目级隔离。最小可用权限模型建议Admin管理所有项目、用户、系统配置。Developer可读写本项目内的 artifact可创建 workflow。Reader只读访问指定项目的 artifact。8.4 与 CI/CD 集成让产物流转起来Artifact Hub 最有价值的接入点是作为 CI/CD 流水线的中间存储。一个典型场景是代码提交触发构建构建过程中调用 AI 生成变更分析将分析结果作为 artifact 注册进 Hub流水线的下游环节如自动生成 changelog、通知审阅人、更新知识库再读取这个 artifact。这种模式的好处是 AI 产物不再靠人工从一个页面复制到另一个页面而是通过 API 自动流转。8.5 安全边界自动执行前加人工闸门AI workflow 最大的隐患是整个流程自动执行。比如某一步是“生成代码”和“提交变更”如果完全自动化错误的代码可能直接进入代码库。安全红线是涉及数据删除、依赖升级、生产环境变更、对外发布的步骤必须插入人工审批节点。在 workflow 定义中可以明确标记requires_approval: true执行引擎遇到该字段时暂停等待人工确认后再继续。9. 总结与后续学习方向回到开头那个判断AI 开发的下一个阶段不是模型更强而是产物可管。Derive 的 Show HN 之所以值得关注不在于它实现了多少花哨的功能而在于它点出了一个被很多人忽略的事实——AI 生成能力已经溢出AI 产物的管理能力才刚刚开始。这篇文章完成了三件事首先用可追溯性、可复用性、可组合性三个维度解释了 AI artifacts 和 workflows 为什么值得独立管理其次拆解了开放平台应有的存储、元数据、工作流引擎、API 和权限模块最后用 FastAPI 和 PostgreSQL 实现了一个最小 Artifact Hub覆盖了产物注册、查询、workflow 定义等核心链路。如果你准备在自己的团队落地类似方案建议按下面的顺序推进先解决可追溯性让每一份 AI 产物都有源可查再固化常用工作流让高频操作变成可复用模板最后考虑可组合性把产物和工作流编排成标准化流水线。至于选型可以考虑使用 Derive 之类的开源项目作为起点也可以基于自研的轻量架构从零搭建。真正的关键是开始把 AI 产物当作资产来治理而不是继续让它们在聊天记录里漂着。下一步值得深入的方向包括Prompt 哈希的稳定性设计、多模型来源的元数据标准、artifact 的引用计数与垃圾回收、以及 workflow 执行中的幂等性保障。每一点都能独立写成一篇技术文章也恰好都是 AI 工程化最前沿的基础设施问题。