Update nexus wiki content
This commit is contained in:
@@ -2,52 +2,54 @@
|
||||
title: "Blender Add-on Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/game-development/blender/blender-addon-engineer.md]]
|
||||
- [[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 确保引擎端交接的可重复性。
|
||||
- 核心主题：Blender 插件开发专家 Agent 个性化文档，专注于通过 Python 和 bpy API 构建 Blender 原生工具
|
||||
- 问题域：游戏开发、3D 美术管线中的重复性 Blender 工作流痛点
|
||||
- 方法/机制：利用 bpy API 构建自定义 Operators、Panels、Property Groups，实现资产验证、导出自动化、命名规范检查
|
||||
- 结论/价值：为技术美术和游戏开发团队提供生产级 Blender 自动化工具，将重复性资产准备工作转化为可靠的一键式工作流
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 主体 + 机制 + 结果：Blender Add-on Engineer 偏好数据 API 访问（bpy.data/bpy.types）而非脆弱的上下文相关操作符（bpy.ops），使得 Operator 行为可预测且稳定。
|
||||
- 主体 + 机制 + 结果：验证工具必须在自动修复前报告问题，确保用户知情同意，避免破坏性意外修改。
|
||||
- 主体 + 机制 + 结果：批量工具必须精确记录其修改内容，使得 Pipeline 可审计且可回滚。
|
||||
- 主体 + 机制 + 结果：导出器必须保留源场景状态，除非用户明确选择破坏性清理，确保交接过程可重复验证。
|
||||
- Blender Add-on Engineer 优先使用 bpy.data 等数据 API 访问，而非依赖易碎的 bpy.ops 上下文操作
|
||||
- 验证工具必须在自动修复前报告问题，不允许静默"成功"
|
||||
- 批量工具必须精确记录所有变更，导出器除非用户明确选择否则不得破坏源场景状态
|
||||
- 工具每次迭代后资产准备工作时间应减少 50% 以上
|
||||
|
||||
## 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." — 非破坏性工作流核心原则
|
||||
> "Every tool must save time or prevent a real class of handoff error." — 工具交付的强制性价值标准
|
||||
|
||||
> "Prefer data API access (`bpy.data`, `bpy.types`, direct property edits) over fragile context-dependent `bpy.ops` calls." — Blender API 最佳实践
|
||||
|
||||
> "If the tool interrupts flow, the tool is wrong until proven otherwise." — 工具设计原则
|
||||
|
||||
## 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 绑定和序列化存储。
|
||||
- [[AssetValidation]]：资产验证 — 在资产导出前检查命名、变换、材质槽、集合放置等规范，防止交接错误
|
||||
- [[PipelineAutomation]]：管线自动化 — 通过自定义 Operators、Panels、Property Groups 将重复性 Blender 任务自动化
|
||||
- [[NamingConventions]]：命名规范 — 确定性且文档化的命名规则，用于检测 Blender 重复后缀、空格等命名漂移问题
|
||||
- [[NonDestructiveWorkflow]]：非破坏性工作流 — 不经用户确认不执行重命名、删除、应用变换或合并数据，支持 dry-run 模式
|
||||
- [[BpyAPI]]：Blender Python API — 通过 `bpy.data`、`bpy.types`、直接属性编辑与 Operator 调用构建 Blender 工具
|
||||
- [[CollectionBasedExport]]：基于集合的导出 — 通过显式的包含/排除规则进行集合级导出，避免隐藏场景启发式逻辑
|
||||
|
||||
## 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"。
|
||||
- Blender：开源 3D 创作套件，Agent 的目标平台和 API 基础
|
||||
- glTF/FBX/USD：主流 3D 引擎交接格式，导出器支持的目标格式
|
||||
- Unity/Unreal：游戏引擎目标平台，Asset Validator 的下游消费者
|
||||
|
||||
## 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]]：验证工具产出报告，供设计师决策修复方案。
|
||||
- [[GameDesigner]] ← belongs_to ← [[GameDevelopmentAgentTeam]]
|
||||
- [[TechnicalArtist]] ← related_to ← [[BlenderAddonEngineer]]
|
||||
- [[UnityArchitect]] ← adjacent_to ← [[BlenderAddonEngineer]]（3D 资产交接）
|
||||
- [[UnrealWorldBuilder]] ← adjacent_to ← [[BlenderAddonEngineer]]（3D 资产交接）
|
||||
- [[UnityShaderGraphArtist]] ← uses ← [[BlenderAddonEngineer]]（材质/着色器资产准备）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[UnityArchitect]] 在"编辑器工具的数据修改时机"上存在设计哲学差异：
|
||||
- 冲突点：Unity Architect 建议通过 ScriptableObject 实现编辑时-运行时状态分离，倾向于在编辑器扩展中直接修改资产；Blender Add-on Engineer 坚持非破坏性原则，验证后必须用户主动确认才执行修改。
|
||||
- 当前观点：Blender 艺术家工作流强调"保留原始数据"——任何破坏性修改必须在 Dry-run 模式下预演，用户确认后才执行。
|
||||
- 对方观点：Unity Editor 工具倾向于"所见即所得"——编辑器内修改即为正式修改，ScriptableObject 负责持久化状态。
|
||||
- 协调建议：两者均强调"验证先行"——Blender Add-on Engineer 的非破坏性验证 + Unity Architect 的 SO 状态分离，本质上是从不同平台约束出发的等效安全实践。
|
||||
- 与 [[UnityEditorToolDeveloper]] 冲突：
|
||||
- 冲突点：工具开发平台的定位差异
|
||||
- 当前观点：Blender Add-on Engineer 专注于 Blender 原生工具（bpy API），不跨 DCC
|
||||
- 对方观点：Unity Editor Tool Developer 在 Unity Editor 内部用 C# 构建工具
|
||||
- 注：两者服务不同场景，无直接功能冲突，仅在"管线工具"概念上有领域重叠
|
||||
|
||||
Reference in New Issue
Block a user