从参考到可编辑 Blender 模型

让用户拿到能选中零件、继续修改、另存和导出的三维工程。由 AI 理解参考并编写 Blender Python，由 Blender 建立几何、材质和场景。不将渲染图片当作三维文件，也不把本次案例的车型、对象数量和尺寸设成通用模板。

1. 明确输入与目标

• 查看用户提供的图片、设计图或已有模型。给出文字概念时，可以直接设计一个合理的风格化模型，说明采用的设计假设。
• 用户要复现某个案例并更换主体时，保留“参考理解、独立零件、可编辑工程、实际修改、导出验证”的工作方式，重新设计主体。不要照搬原案例的部件清单。
• 明确外观风格、主要尺寸、必须独立的部件及预期用途。一般的比例、配色、展示角度可自行选择；会改变对象身份或要求精确复刻的缺失信息先澄清。
• 区分输入里能确认的形状、标注尺寸、未知的背面和设计补全。多视图冲突时优先采用用户指定的尺寸来源，记录实际取舍。
• 没有原始图纸时可补一张概念说明图，但准确标注它是设计辅助或后补说明。不能声称先按图建模，实际却从完成的模型反推图纸。

2. 检查环境和已有资产

• 检查实际 Blender 路径、版本和已有工程。临时运行的 Blender 不等于已安装；只在用户授权时安装软件。
• 优先使用 Blender Python/CLI 或已有 Blender API。MCP 可以承载脚本，但不是这个流程的必要依赖；避免仅为建模反复初始化桌面控制。
• 用 --python-exit-code 1 运行脚本，遇到异常检查日志与退出码。沙箱导致启动失败时走宿主的权限机制，不能将失败忽略后报告成功。
• 保留用户原模型及未保存修改。新建案例使用独立目录；后续修改另存版本，前台与后台不要同时写同一工程。
• 先检查可复用资产及其许可。若使用下载模型或外部生成服务，说明来源与其实际贡献，不将它们冒充脚本原创建模。

3. 把外观分解成可编辑零件

• 在项目中写出简短的部件清单，将关键参考特征对应到具体几何和对象名。例如家具的柜体与抽屉，机器人躯干与传感器，坦克外观的车体、履带、轮组和炮塔。
• 用 Collection 和必要的 Empty 表达装配关系。只把需要独立选择、修改或导出的部分拆成对象；重复零件可共享 mesh 数据，但保留单独对象控制。
• 先建立主要轮廓和比例，再添加细节、倒角和材质。选用适合形状的基础体、曲线或直接网格，不强迫所有物体使用同一种几何表示。
• 设定明确的单位和轴向。区分物体原点、局部坐标、父级变换与最终可见尺寸；修改器可能让实测尺寸与设计尺寸不同。
• 检查面朝向、关键接缝和附件关系。先看主视角和正交视角，修正明显比例或法线问题，再输出全部展示图。

4. 保存基础工程并实际修改

• 用户明确要求修改或演示时，先保存基础 .blend，再重新打开这个文件进行修改；没有修改要求时只交付当前范围内的基础工程。
• 读取 尺寸修改与验证，把自然语言要求落实到指定对象、尺寸变化、固定锚点及跟随的附件。
• 只修改被要求的对象或共享材质。单独修改某个重复件的几何前，检查 mesh 是否被多个对象共享；需要独立修改时先复制目标的数据，避免其他对象一起变化。加长轴向部件时检查直径与固定端；移动支架时检查上面的传感器；扩大盒体时检查盖子的位置。
• 保存修改版 .blend。需要证明版本来源时，在修改版记录基础文件摘要；不要把两次独立生成的相似模型称为基于原工程的修改。
• 为基础版和修改版保留相同展示相机，避免通过改变视角、裁切或灯光夸大修改效果。

5. 导出、验证与交付

• 按当前要求交付原生 .blend、GLB 和少量多角度渲染。只有用户明确要求保留修改前后版本时才同时交付基础版与修改版；用户只要求单个模型或已有工程的局部编辑时按其范围执行。
• GLB 只导出目标模型，不混入摄影棚地面、灯光或辅助物。在空场景中导回，检查独立部件、名称及关键几何；不要把 Blender 回读通过表述成所有引擎材质一致。
• 重新打开最终原生工程，检查对象可选、关键尺寸与配色符合要求、附件位置正确。不要仅以文件存在或对象数量作为成功证据。
• 检查最终渲染。几何有效、外形相似、生产可用是不同判断；没有做过的 UV、绑定、碰撞、制造公差和打印验证如实说明，不自动扩展工作。
• 保存可读的初始视角和显示方式。颜色演示可以用 SOLID 的材质颜色，但它不等于节点材质的真实渲染；需要判断材质时检查材质预览或渲染。
• 提供实际可打开的文件链接，简要说明哪些零件能改、如何找到它们、两版改了什么，以及实际通过的检查。

范围边界

拆解动画、装配演示、Blender 界面录屏、角色绑定和打印检查都是后续独立请求。不要因为模型具备独立零件，就默认生成这些内容。用户只要求教程、分析或封装 skill 时，保持已有模型只读。