54 lines
5.4 KiB
Markdown
54 lines
5.4 KiB
Markdown
---
|
||
title: "Blender Add-on Engineer Agent Personality"
|
||
type: source
|
||
tags: []
|
||
date: 2026-04-26
|
||
---
|
||
|
||
## Source File
|
||
- [[raw/Agent/agency-agents/game-development/blender/blender-addon-engineer.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：Blender 工具开发专家 AI Agent 人格规范——通过 Python + bpy API 构建 Blender 原生工具（自定义 Operator、Panel、资产验证器、导出器），将重复性 DCC 工作流自动化为可靠的一键工作流。
|
||
- 问题域：3D 资产生成中的命名漂移、未应用变换、错误材质槽映射、导出配置不一致等交接错误问题。
|
||
- 方法/机制：数据 API（bpy.data）优先于操作符（bpy.ops）以确保可靠性；非破坏性验证优先于自动修复；确定性命名规范；Pipeline 可靠性三角（验证→报告→确认→导出）。
|
||
- 结论/价值：每个工具必须节省时间或防止一类真实的交接错误；Asset Validation 可在资产离开 Blender 前拦截问题；Export Preset 确保引擎端交接的可重复性。
|
||
|
||
## Key Claims（用中文描述）
|
||
- 主体 + 机制 + 结果：Blender Add-on Engineer 偏好数据 API 访问（bpy.data/bpy.types）而非脆弱的上下文相关操作符（bpy.ops），使得 Operator 行为可预测且稳定。
|
||
- 主体 + 机制 + 结果：验证工具必须在自动修复前报告问题，确保用户知情同意，避免破坏性意外修改。
|
||
- 主体 + 机制 + 结果：批量工具必须精确记录其修改内容，使得 Pipeline 可审计且可回滚。
|
||
- 主体 + 机制 + 结果：导出器必须保留源场景状态，除非用户明确选择破坏性清理，确保交接过程可重复验证。
|
||
|
||
## Key Quotes
|
||
> "Every tool must save time or prevent a real class of handoff error." — 默认要求：每个工具必须有可量化的价值
|
||
> "Operators must fail with actionable error messages — never silently 'succeed' while leaving the scene in an ambiguous state." — 操作符失败规范
|
||
> "Never destructively rename, delete, apply transforms, or merge data without explicit user confirmation or a dry-run mode." — 非破坏性工作流核心原则
|
||
|
||
## Key Concepts
|
||
- [[bpy]]：Blender Python API，提供数据访问（bpy.data）和操作符执行（bpy.ops）两套接口；Add-on Engineer 偏好数据 API 以确保可靠性。
|
||
- [[Asset-Validation]]：资产验证——在资产离开 Blender 前检查命名、变换、材质槽、集合放置等标准的自动化流程，是 Pipeline 可靠性的第一道防线。
|
||
- [[Non-Destructive-Workflow]]：非破坏性工作流——不主动修改源数据，通过验证→报告→确认→执行四步确保用户知情同意，是 Blender Add-on Engineer 的核心设计原则。
|
||
- [[Export-Presets]]：导出预设——可配置的引擎交接规则集（FBX/glTF/USD），确保导出设置在多次运行间保持可重复性。
|
||
- [[Pipeline-Reliability]]：Pipeline 可靠性三角——命名确定性 + 变换分离检查 + 材质槽顺序验证 + 集合包含/排除显式规则，是 Add-on Engineer 交付的核心质量标准。
|
||
- [[AddonPreferences]]：Blender Add-on 持久化设置机制，用于存储跨会话保留的工具配置（如默认导出路径、验证规则开关）。
|
||
- [[PropertyGroups]]：Blender Python 属性组——结构化自定义属性的声明方式，支持 UI 绑定和序列化存储。
|
||
|
||
## Key Entities
|
||
- [[Blender]]：Blender Foundation 开发的开源 3D DCC 软件，通过 Python bpy API 支持插件扩展；本文档的核心目标平台。
|
||
- [[BlenderAddonEngineer]]：The Agency Game Development 部门 Blender 专项专家 Agent，核心理念"Pipeline-first, artist-empathetic, automation-obsessed, reliability-minded"。
|
||
|
||
## Connections
|
||
- [[TechnicalArtist]] ← extends ← [[BlenderAddonEngineer]]：技术美术是 Blender Add-on Engineer 的上级角色，后者是 Blender 专项实现。
|
||
- [[GameDesigner]] ← depends_on ← [[BlenderAddonEngineer]]：游戏设计师依赖资产验证和导出管线确保设计资产正确交接。
|
||
- [[UnityArchitect]] ← parallel ← [[BlenderAddonEngineer]]：同为 DCC 工具开发专家，但 Unity Architect 专注 Unity Editor 扩展；两者共享 Editor 工具开发的通用原则（验证优先、持久化配置、非破坏性）。
|
||
- [[UnrealSystemsEngineer]] ← parallel ← [[BlenderAddonEngineer]]：同为工具开发专家，Unreal Systems Engineer 专注 UE5 C++/Blueprint 扩展；两者共享"管道优先、验证先行"理念。
|
||
- [[BlenderAddonEngineer]] ← provides ← [[Asset-Validation]] → feeds → [[GameDesigner]]：验证工具产出报告，供设计师决策修复方案。
|
||
|
||
## Contradictions
|
||
- 与 [[UnityArchitect]] 在"编辑器工具的数据修改时机"上存在设计哲学差异：
|
||
- 冲突点：Unity Architect 建议通过 ScriptableObject 实现编辑时-运行时状态分离，倾向于在编辑器扩展中直接修改资产；Blender Add-on Engineer 坚持非破坏性原则，验证后必须用户主动确认才执行修改。
|
||
- 当前观点：Blender 艺术家工作流强调"保留原始数据"——任何破坏性修改必须在 Dry-run 模式下预演，用户确认后才执行。
|
||
- 对方观点：Unity Editor 工具倾向于"所见即所得"——编辑器内修改即为正式修改，ScriptableObject 负责持久化状态。
|
||
- 协调建议：两者均强调"验证先行"——Blender Add-on Engineer 的非破坏性验证 + Unity Architect 的 SO 状态分离，本质上是从不同平台约束出发的等效安全实践。
|