我知道这里的所有人可能不感兴趣于使用 AI 助手进行编码，但我理解这一点。然而，Unity 开发者在他们的工作流程中使用 AI 代理，我认为其中一些人可能会遇到与我相同的问题的上下文和令牌问题。 我想与那些人一起改进这个工具。大家好，我是 unity-cli 的开发者，这是一个用于控制 Unity 工作流程的终端工具。最近，我在尝试 RTK 时开始思考，Unity 可能需要类似的工具：一个小工具，可以在将输出发送到 LLM 或 AI 编码代理之前减少噪音。 当使用 Unity 项目通过 AI 代理进行工作时，很多上下文并不是实际有用的信息。它包括重复的路径、.meta 文件、GUID、YAML 存储详细信息、重复的组件和长的预设或场景备份。 例如，即使是一个简单的文件列表也可能看起来像这样： C:/Project/MyGame/Assets/Examples/Characters/Enemy_01.prefab C:/Project/MyGame/Assets/Examples/Characters/Enemy_01.prefab.meta C:/Project/MyGame/Assets/Examples/Characters/Enemy_02.prefab C:/Project/MyGame/Assets/Examples/Characters/Enemy_02.prefab.meta C:/Project/MyGame/Assets/Examples/Characters/Enemy_03.prefab C:/Project/MyGame/Assets/Examples/Characters/Enemy_03.prefab.meta 作为人类，你可能会将其读作： Characters [预设] Enemy_01..03 这就是 unity-scanner 试图产生的输出。它会去掉重复的绝对路径、默认隐藏 .meta 文件、将资产按文件夹和类型分组，并压缩数字名称，如 Enemy_01、Enemy_02、Enemy_03 为 Enemy_01..03。重点不是Dump一切。重点是保持有用的结构，将重复的噪音折叠起来以节省令牌。 Unity YAML 有同样的问题，但更糟糕。一个预设或场景文件全是这样的块： --- !u!1 &100001 GameObject: m_Name: SampleRoot m_Component: - component: {fileID: 400001} - component: {fileID: 230001} --- !u!4 &400001 Transform: m_GameObject: {fileID: 100001} m_Father: {fileID: 0} --- !u!23 &230001 MeshRenderer: m_GameObject: {fileID: 100001} m_CastShadows: 1 m_ReceiveShadows: 1 这种格式对于 Unity 序列化来说是可以接受的，但对于 AI 代理来说却不是很友好。 GameObject 名称在一个块中，父关系在另一个块中，组件通过文件 ID 相连，MonoBehaviour 通常需要 GUID 解析才能找到脚本。 unity-scanner read 将其转换为更可读的映射： CMP c1 Transform c2 Transform, MeshFilter, MeshRenderer TREE [0] SampleRoot c1 [1] SampleMeshRoot c1 [2..9] SampleMesh_01..08 c2 (8) 更多： 41 根据深度/限制折叠： 18 TREE 是实际的 GameObject 层次结构。 CMP 是重复的组件组合表。如果许多对象具有相同的 Transform, MeshFilter, MeshRenderer 组合，它将被一次声明为 c2 而不是在每行上重复。 可以折叠的渲染只子对象也会折叠。当可能时，可以显示类似于： [2..9] SampleMesh_01..08 c2 (8) 当有内容被隐藏时，输出仍然会说出被隐藏了多少条线，如 more 或 collapsed render-only，所以代理可以决定是否需要深入。 对于 ScriptableObject 和 MonoBehaviour 字段，它试图只显示需要检查的字段。 当可以解析 GUID 时，它会显示资产路径，以免您需要运行另一个 grep 才能了解引用指向什么。 reference {fileID: 11400000, guid: ...} -> Assets/Examples/Data/SampleReference.asset 搜索也是围绕 Unity 概念而不是原始文本行进行的。 [预设] UI SamplePanel file-name object: SamplePanel components: RectTransform, CanvasRenderer 因此，不仅仅是看到匹配的 m_Name: 行，您还可以知道匹配来自文件名、GameObject 名称、组件还是 GUID 引用。 这使得代理更容易选择下一步要检查什么。 当前命令是： unity-scanner list 压缩 ls 对 Unity 资产 unity-scanner read 可读的总结 对预设/场景/资产 YAML unity-scanner search 结构化搜索按文件名、GameObject、组件或 GUID unity-scanner refs 找出资产或 GUID 的引用 GitHub 仓库：https://github.com/youngwoocho02/unity-scanner 安装： macOS / Linux：curl -fsSL https://raw.githubusercontent.com/youngwoocho02/unity-scanner/master/install.sh | sh Windows PowerShell：irm https://raw.githubusercontent.com/youngwoocho02/unity-scanner/master/install.ps1 | iex 最新版本：https://github.com/youngwoocho02/unity-scanner/releases/tag/v0.1.0 主要思想是将 Unity 项目视为 AI 助手开发的紧凑地图。 我做了这个，因为在我的 Unity 和 AI 代理工作流程中，我一直会遇到同样的问题：代理需要项目结构、预设结构、引用和组件信息，但默认终端输出往往比它实际携带的信息大得多。 这仍然是一个早期版本。 我先从我自己遇到的令牌浪费最多的问题开始：预设和场景检查、ScriptableObject 摘要、GUID 引用和压缩资产列表。 我非常感谢其他使用 AI 代理的 Unity 开发者提供反馈。如果您有例子，Unity 输出特别噪声，或者有关于预设、场景、ScriptableObject、Addressables 或 GUID 引用输出应该如何压缩的想法，我都很想听。 问题、PR 和真实使用例都受欢迎。 我想将这个工具发展成为 Unity 开发者与 AI 代理合作的实用 CLI 工具，而不是仅仅是一个小工具。