这是蓝图的完整字段参考。有关蓝图的介绍以及它们如何适配 Devin 的环境，请参阅声明式环境
配置。
概览
post-build 部分；对于仓库级蓝图，还可以包含一个可选的 clone 部分：
所有部分都是可选的。你可以任意组合使用。
initialize 会在完整构建期间以及对从头重新构建的工作区执行。结果会保存到快照中。在差异构建中，继承的工作区会跳过 initialize，拉取最新代码，并且只运行 maintenance。请将 maintenance 编写为自包含的，使其能够在现有快照之上独立运行，而不要求必须先立即运行 initialize，也不要依赖 initialize 之前写入 $ENVRC 的环境变量。在每次会话开始时，maintenance 命令不会自动执行——而是作为上下文提供给 Agent，以便它在需要时知道应运行哪些依赖命令 (例如，在拉取最新代码后) 。这些命令仍应尽量快速，并支持增量执行。当你的蓝图发生更改时，系统会自动运行构建，也会定期运行 (约每 24 小时一次) 。
initialize
initialize 安装不依赖代码具体状态的工具和运行时，例如语言运行时、系统软件包和全局 CLI。
简单写法
结构化格式
run 的单独步骤。
何时使用 initialize 与 maintenance
这两个部分都会在完整构建期间运行。在差异构建中，继承的工作区会跳过
initialize，并在拉取最新代码后只运行 maintenance。工具和运行时放在 initialize；与代码锁文件保持同步的依赖命令放在 maintenance 中。
maintenance
maintenance 执行依赖安装以及其他应在代码克隆后运行的命令。这些命令会在构建期间运行，并在 会话 开始时提供给 Agent，以便它在依赖发生变化时重新运行。这里适合放置 npm install、pip install、uv sync 等类似命令。
对于仓库级蓝图，
maintenance 命令需在仓库根目录中运行。对于组织级蓝图，这些命令需在主目录 (~) 中运行。knowledge
knowledge 部分不会执行。它提供 Devin 在你的项目中工作时会用到的参考信息。你可以通过这一部分告诉 Devin 用于 lint、测试、构建以及其他项目特定工作流程的正确命令。
name 字段是一个标签。按照惯例，lint、test 和 build 是标准名称。Devin 在验证工作结果时会参考这些名称。你也可以添加任意其他使用自定义名称的知识条目：
post-build
post-build 部分仅在组织级和企业级蓝图中可用 (仓库级蓝图不支持) 。其中的步骤会在构建过程中运行，即在所有代码仓库都已克隆，且其 initialize 和 maintenance 步骤均已完成之后，但会在健康检查和创建快照镜像之前执行。因此，这里非常适合执行需要完整环境就绪后才能进行的跨代码仓库验证和健康检查。
由于它会在构建后期、整个环境已完整就绪时运行，post-build 步骤可以访问每个已克隆的代码仓库，以及企业、组织和代码仓库蓝图安装的所有工具。
post-build 步骤与 initialize 和 maintenance 使用相同的步骤类型 (shell run 命令和 GitHub Actions uses) ，并且从主目录 (~) 运行。clone
clone 部分会覆盖 Devin 将代码仓库克隆到快照中时使用的默认设置。每个字段都是可选的；未设置时，会回退到合理的默认值，以保持当前行为不变。
clone 仅适用于仓库级蓝图——它控制该代码仓库如何克隆到快照中。在组织级或企业级蓝图中，它不起作用。步骤类型
initialize、maintenance 或 post-build 中的每个步骤都属于以下两种类型之一：shell 命令 (run) 或 GitHub Actions (uses) 。
Shell 命令 (run)
执行详情：
- 命令在 bash 中运行。如果多行脚本中的任一命令失败，整个步骤会立即停止。
- 组织级蓝图在主目录 (
~) 中执行。 - 仓库级蓝图在克隆后的仓库根目录中执行。
- 每个步骤的超时时间为 1 小时。
- secrets 会自动作为环境变量提供。
GitHub Actions (uses)
Action 引用格式：
github.com/ 前缀和 @<ref> 后缀都必填。ref 通常是类似 v5 这样的版本标签。
常用 action：
with 值的作用方式：
通过 with 传入的值会作为该 action 的输入，遵循与 GitHub Actions 工作流程相同的规范。所有值都会被转换为字符串。
setup-python 会将 Python 可执行文件添加到 PATH 中，因此之后的所有步骤以及 maintenance 中都可以继续使用它。
run 与 uses：该用哪个
实际上，大多数配置都会对语言运行时使用
uses，其余情况则使用 run。
环境变量和 secrets
步骤级环境变量
env 字段定义额外的环境变量：
跨步骤环境变量 ($ENVRC)
$ENVRC 文件：
$ENVRC 的变量会自动导出，并可在所有后续步骤和由当前构建生成的 Devin 会话 中使用。这与 GitHub Actions 中的 $GITHUB_ENV 类似。
这也适用于 PATH。如果你将工具安装到非标准目录
(即 /usr/bin 或 /usr/local/bin 之外的任何位置) ，请将其追加到 $ENVRC，这样
后续步骤和仓库级蓝图就能找到该二进制文件：
run: 块中直接使用 export PATH=... 只会影响该步骤的 shell。
每个步骤都会启动一个新的 shell 进程，因此，未写入
$ENVRC 的 PATH 更改都会丢失。
uses: action (例如 actions/setup-node) 会自动将其对 PATH
的添加传播到 $ENVRC —— 你只需要为 run: 步骤手动执行此操作。$ENVRC 会在每次构建开始时重置，包括差异构建。
某次构建期间写入的值在下一次构建中不可用。尤其是，
继承的 工作区 只运行 maintenance，因此不能依赖
父构建中 initialize 写入 $ENVRC 的 PATH 或其他变量。
请在 maintenance
内部配置 maintenance 所需的任何环境。
Secrets
$MY_SECRET) 。
在构建期间，每个步骤运行前都会注入 Secrets，并且 会在每次会话开始时再次注入。Secrets 不会保留在快照镜像本身中，因此凭据绝不会被写入已保存的机器镜像。
- 组织级 Secrets：在 组织 中所有 蓝图 的每个步骤里，都可作为环境变量使用。在组织级蓝图编辑器的 Secrets 选项卡中设置。
- Enterprise Secrets：会与 组织 Secrets 合并 (如果名称冲突，则以 组织 Secrets 为准) 。在所有 组织 中都可用。
- 仓库 Secrets：会写入每个 repo 对应的文件
/run/repo_secrets/{owner/repo}/.env.secrets。在构建期间，该 repo 的 蓝图 步骤运行前，会自动 source 该 repo 的 Secrets。在会话期间，Devin 在该 repo 中工作时也会 source 它们。在该代码仓库的蓝图编辑器的 Secrets 选项卡中配置这些 Secrets。
仅构建 Secrets：标记为 “build only” 的 Secrets 在快照构建期间可用，但会在快照保存前移除。对于仅在构建时需要的凭据，请使用这类 Secrets (例如，
在
initialize 期间下载私有构件) 。文件附件
.npmrc、settings.xml、配置文件) 。上传的文件会写入 ~/.files/，并会为每个文件设置一个指向其路径的环境变量：
FILE_ 前缀。
在 蓝图 的步骤中使用文件附件：
由 Git 管理的蓝图
.devin/blueprint.yaml 文件的形式存储在你的代码仓库中，然后通过 API 或 UI 进行同步。有关设置指示和详细信息，请参阅 由 Git 管理的蓝图。
完整示例
有关蓝图如何跨层级 (企业 → 组织 → 仓库) 组合、构建状态、仓库状态，以及哪些因素会触发重建，请参阅“声明式配置”页面中的构建和
会话。