上周帮一位朋友看他刚打出来的测试包，桌面上的应用图标糊成一团马赛克，进游戏后UI里那些小图标边缘全是锯齿。他第一反应是美术给的图不行，重新导出了三遍PNG，问题纹丝不动。我打开工程瞄了一眼：Texture Type 还是默认的 Default，Max Size 卡在 1024，压缩格式挂着 Automatic，图集压根没建。图标这条链路的问题，十次里有八次不在美术那边，在导入设置和平台配置这边。
另一个问题是预制件。他有一批UI面板是复制粘贴出来的，改一处忘一处，最后同一个"领取"按钮在三个界面里长得都不一样；还有一个弹窗预制件里引用的特效节点，被同事在场景里手动删掉了，预制件本身没更新，进游戏就报空引用。
图标和预制件，看起来是两个不相干的话题，其实在工程里是同一件事的两面：资源配置。图标管的是"资源怎么进包、进来之后长什么样"，预制件管的是"资源怎么组装、组装完怎么复用"。这两块配置一旦松散，后面所有性能优化和版本迭代都会被拖累。下面这些内容是我这几年在几个中小型项目里反复踩、反复改攒下来的，主要写给刚接手完整项目配置工作的同学，也写给那些"能跑就行、上线再说"的老手做个对照。
1. 先把事故还原：图标与预制件为什么总在打包前夜爆雷
1.1 两类问题的共同根源是"默认值太宽容"
Unity3D 的默认导入设置是为"能跑"设计的，不是为"能上线"设计的。一张PNG拖进工程，引擎会自动判断类型、自动选压缩、自动给一个1024的尺寸上限。这套默认逻辑在编辑器里预览毫无问题，因为编辑器用的是原始资源，很多设置根本不会生效——压缩不会真的压，图集不会真的打，Mipmap 的采样偏差也看不出来。等你 Build 出来装到手机上，所有被"宽容"掩盖的问题一次性暴露。
预制件同理。你在编辑器里拖一个节点进预制件、挂一个脚本、连一个引用，编辑器会帮你维持这些关系，哪怕这个引用指向的是场景里的临时对象。但打包之后场景重新加载，那些运行时才存在的对象根本不存在，引用自然断掉。默认行为不报错，只在运行时给你一个NullReferenceException。
我见过最典型的一次，是一个图标资源同时被三个图集引用，打包时资源被打了两遍，包体莫名其妙多了6MB；同时那个预制件里挂的脚本因为类名改过一次，序列化字段全丢，UI上一排按钮全是空白。两件事凑在同一个版本里，排查花了整整一天。
1.2 图标链路的完整路径，比大多数人以为的长
很多人脑子里的图标链路是"美术出图 → 拖进工程 → 设置里选一下 → 打包"。实际链路是这样的：
| 环节 | 关键动作 | 常见失效点 |
|---|---|---|
| 美术输出 | 定尺寸、透明通道、留白 | 出了带透明边的方形图 |
| 导入设置 | Texture Type、Max Size、压缩 | 用了 Default 类型 |
| 图集归属 | Sprite Atlas 分组、Packing Tag | 没进图集，Draw Call 爆炸 |
| UI引用 | Image / RawImage 选哪个 | RawImage 用了图集资源 |
| 应用图标 | Player Settings 各平台分槽位 | 只配了 Default 槽 |
| 打包 | 平台相关压缩、图集烘焙 | 图集没勾 Include in Build |
六个环节，任何一个掉链子，最终表现都是"图标不好看"或者"包体不对"，但根因可能在天差地别的两个地方。所以我后来养成一个习惯：排查图标问题永远从后往前查，先看打包日志里图集有没有被烘进去，再倒推导入设置，最后才怀疑美术图。
1.3 预制件的问题更隐蔽，因为它"能跑"
图标出问题，肉眼可见。预制件出问题，往往要等到某个特定操作路径才触发。比如一个道具预制件，正常流程走没问题，只有玩家在背包满的时候点"使用"才会走到一条清理逻辑，那条逻辑里引用的一个子节点在你重构预制件结构时被改名了，于是崩。
这类问题的排查成本极高，因为复现路径长。我处理过的做法是：把预制件的结构变更当成接口变更来对待。改层级名、改组件顺序、删子节点，都要假设有外部代码通过transform.Find("xxx")在找它。真要清理，先在工程里全局搜一遍字符串，确认没人引用再动手。
2. 图标这条线：从一张PNG到玩家桌面上的那个方块
2.1 导入设置里那几个真正会咬人的开关
先讲单张图标的导入设置。选中一张图，Inspector 里那堆选项，我按"必须改"和"看情况"分一下。
必须改的：
- Texture Type：UI图标一律选
Sprite (2D and UI)。选 Default 的话，Unity 会当成普通贴图处理，Image 组件虽然也能吃，但 Sprite 相关的一些优化（比如 Tight 打包、图集合并）就用不上。3D物体表面贴的图标（比如技能球）也是 Sprite 或者走材质，不要留在 Default。 - Read/Write Enabled：关掉。这个选项打开后，CPU 侧会保留一份内存副本，方便你用脚本读取像素。图标几乎不需要运行时读像素，开着纯属浪费，一张1024的图在这个选项上能多吃4MB内存。
- Generate Mip Maps：纯UI图标关掉。Mipmap 是为"远距离观察"准备的，UI 图标永远是 1:1 显示，开了只会让边缘在非整数缩放下更糊。但如果是贴在3D模型上的图标（比如地面上的指示标记），要开，否则远处会闪烁。
- Wrap Mode：改成
Clamp。UI 图标的 UV 一般都在 0-1 之间，但九宫格拉伸、Image 的 Fill 模式在某些边界情况下会采样到范围外，Repeat 会让边缘出现一条来自对边的像素。
看情况的：
- Filter Mode：默认 Bilinear。像素风格的图标必须改成 Point，否则放大会糊成一片。反过来，写实风格图标用 Point 会有硬边。
- Compression：这个后面单独说。
- Max Size：这个是最容易踩坑的一个，后面也单独说。
还有两个容易被忽略的：Alpha Is Transparency建议勾上，尤其是图标边缘有半透明的，不勾的话边缘会出现黑边或者白边（取决于背景色）；Sprite Mode单张图标就用Single，如果一张图里切了多个图标就用Multiple，改完记得点 Apply 再进 Sprite Editor 切。
2.2 Max Size 和压缩格式：两个决定"糊不糊"的关键参数
Max Size 的逻辑很简单：如果原图超过这个尺寸，Unity 会等比缩到不超过这个值。问题在于很多人不知道自己的图到底显示多大。
举个实际例子。一个 1080p 的手机屏幕，宽度 1080 像素。你在 UI 里放一个占屏宽 10% 的图标，那它在屏幕上的实际像素就是 108 像素。考虑到高DPI设备（比如 2K、3K 屏），实际需要的分辨率大概在 200-300 像素之间。这种情况下，Max Size 设 1024 完全是浪费——图在包里占的体积是 256 的四倍，显存也是四倍，视觉效果一点提升都没有。
我的经验值是按图标的最大显示尺寸 × 2来定：
| 图标用途 | 屏幕占比 | 建议源尺寸 | Max Size |
|---|---|---|---|
| 应用启动图标 | 系统决定 | 1024×1024 | 1024 |
| 主界面大按钮 | 15%-20% 屏宽 | 256×256 | 256 |
| 列表项小图标 | 5%-8% 屏宽 | 128×128 | 128 |
| 状态角标 | 2%-3% 屏宽 | 64×64 | 64 |
压缩格式这块，现在的项目基本可以统一到ASTC。安卓端从 4.3 之后支持，iOS 从 A8 芯片开始支持，覆盖率已经足够。ASTC 的好处是按块压缩，4×4 到 12×12 可选，块越小质量越高体积越大。图标这种有明显边缘和文字的资源，我一般用ASTC 6×6，纯色块多的可以用ASTC 8×8。
如果项目还要兼顾非常老的低端机，可以保留 ETC2 作为 fallback。具体配置在 Player Settings 的 Texture Compression 里，可以给不同平台指定不同格式。
注意：压缩格式是"平台覆盖"设置，你在单张图的 Inspector 里看到的是默认值，实际打包时会走 Player Settings 里的覆盖。排查包体异常时一定要去那边看一眼，我遇到过团队里有人手动给某张图指定了 RGBA32 未压缩，结果一张 2048 的图占了 16MB。
2.3 Sprite Atlas：不做这一步，Draw Call 会教你做人
UI 图标最大的性能坑不是单张图多大，而是批次被打断。Unity 的 UGUI 只有在相邻的 UI 元素使用同一张纹理时才能合批。如果你的界面上有 20 个图标，来自 20 张独立的 PNG，那就是 20 个 Draw Call，加上中间的文本和背景，一个小界面轻松跑到 40+。
解决办法就是 Sprite Atlas。做法是：创建一个 Sprite Atlas 资产，把相关图标拖进 Objects for Packing，勾上Include in Build，然后在打包时引擎会把它们合成一张大图。
图集怎么分？我的做法是按使用场景分，不按美术风格分：
atlas_common：所有界面都可能用到的基础图标（关闭、返回、箭头、加号）atlas_main：主界面和主菜单atlas_battle：战斗内HUDatlas_shop：商城相关（这类图通常更新频繁，单独分出来方便热更）
这样分的好处是：一个界面加载时只需要加载对应的那一两张图集，不会因为一张图把整个巨型图集全拉进内存。
图集尺寸也有讲究。默认最大 2048×2048，如果没有特别大的图，建议压到 1024，因为图集是按整张分配的，2048 的图集即使只用了三分之一，显存也按整张算。可以在 Atlas 的 Inspector 里看到 Packed Sprites 和占用率的预览。
还有一个非常容易踩的坑：已经在图集里的 Sprite，如果在 Image 组件里被换成了别的图集里的 Sprite，运行时会触发图集重新绑定，表现为切换界面时有一次明显的卡顿。解决方案是用SpriteAtlasManager.atlasRequested回调预加载，或者在界面打开前就把需要的图集LoadAssetAsync一遍。
2.4 应用图标：Player Settings 里那几个必须逐平台填的槽位
应用图标和 UI 图标是两条完全独立的链路。Player Settings 里的 Icon 区域，Unity 已经按平台做好了分组，但很多人只填了 Default 就打包了。
安卓端现在主流是自适应图标（Adaptive Icon），分前景层和背景层两个槽。前景层的实际内容只占整个图标区域约 66%，外圈是留给系统做各种形状裁剪（圆形、方形、水滴形）的。这意味着你的图标主体必须缩进到中间那块安全区里，不然在某些启动器上会被裁掉边缘。
iOS 端相对简单，一张 1024 的方图，系统会自动生成各种尺寸。但有两个硬性要求：不能有透明通道，不能有圆角（系统自动加）。这两条如果有违反，上传时会被直接打回。我吃过一次亏，美术给的图是带透明背景的 PNG，转成 iOS 图标后透明区域变成了纯黑，审核直接拒。
提示：不管哪个平台，图标源文件都建议保留一份 1024×1024 的无损原图放在工程外，不要在工程里反复压缩。因为每次替换图标都要重新走一遍导入流程，反复压缩会有累积损失。
2.5 图标相关的三个真实踩坑记录
第一个坑：图集里的图被单独引用。有个同事直接把图集打包后生成的 Sprite 拖到了别的地方用，那个 Sprite 在打包后是一个"图集内的子图"，一旦图集被卸载，引用就变空。表现是切场景之后部分图标变白。解决办法是始终引用原始 Sprite 资产，不要引用图集内部的。
第二个坑：九宫格图标的 Border 设置丢失。图标用Sprite Mode: Single并且设置了 Border 做成九宫格按钮，结果某次重新导入（批量替换了源图），Border 被重置成 0,0,0,0，所有按钮变形。这个只能靠流程约束：替换图源时保留 .meta 文件，不要连 meta 一起删了重新导入。
第三个坑：多语言版本的图标带了文字。有个项目图标上直接写了中文，结果要出海外版本时全部重做。UI 图的规范应该定死：图标只放图形，文字用独立的 Text 组件叠加。这条后来写进了我们的美术交付规范里。
3. 预制件不是"保存一下就完事"：结构、引用与变体
3.1 Prefab 的本质是一个序列化模板，理解这点才能理解所有坑
Prefab 在磁盘上就是一个 YAML 文件，记录了"这个 GameObject 有哪些组件、每个组件的字段值是什么、有哪些子节点"。实例化的时候，引擎读这个文件，在内存里重建出一棵树。
理解了这个本质，很多现象就说得通了：
- 为什么改预制件会影响所有实例：因为所有实例都是从同一份模板克隆的，修改模板等于改了"基因"。
- 为什么实例上的修改可以覆盖：每个实例会额外存一份"差异表"（Overrides），记录它和模板不同的地方。Inspector 里那些加粗的字段就是差异项。
- 为什么删除脚本后引用会变成 Missing：序列化记录的是脚本的 GUID，脚本删了，GUID 找不到了，字段自然为空。
我见过太多人把 Prefab 当成"存起来的一份场景对象"来用，随手 Apply、随手 Revert，最后版本里全是互相打架的覆盖。我的建议是：在团队里立一条规矩——预制件模板只在 Prefab Mode 里改，实例上只做必要的差异化覆盖，覆盖项要能一句话说清为什么。
3.2 嵌套预制件与预制件变体：拆分的边界在哪
嵌套预制件（Nested Prefab）是 Unity 2018.3 之后引入的，允许一个预制件里包含另一个预制件实例。这个功能解决了一个长期痛点：以前做一个"带血条的角色头像"，血条部分没法复用，每个角色都要重新搭一遍。
拆不拆的标准，我用三条来判：
- 会不会在多个地方出现：会，就拆。
- 会不会独立变化：会，就拆。比如血条的样式经常改，但角色头像框基本不变，那就把血条拆成独立预制件。
- 拆分后层级深度会不会超过4层：会，就别拆太细。层级过深的预制件在实例化时开销更大，而且 Inspector 里找东西很痛苦。
预制件变体（Prefab Variant）解决的是另一类问题：大部分相同、小部分不同。比如你有 10 种敌人，模型不同但都有相同的血条、碰撞体、AI 脚本。可以做一个"敌人基类预制件"，然后每种敌人做 Variant，只覆盖模型字段。这样基类上的血条逻辑一改，10 个变体全跟着改。
这里有个坑值得单独说：变体上的覆盖是"记录式"的，不是"快照式"的。也就是说，如果你在基类上删掉了一个组件，变体上如果之前覆盖过这个组件的某个字段，删掉基类组件后，变体上那个覆盖会变成一条悬空的记录，表现出来就是 Missing Script。所以基类预制件的结构变更要格外谨慎，改完记得把所有变体过一遍。
3.3 引用边界的三种断法，以及怎么提前发现
预制件最容易在引用上出事，我把见过的断引用分成三类：
第一类：引用了场景对象。预制件里某个字段指向了场景里的一个 GameObject。这种引用在编辑时是有效的，因为对象都在同一个场景里；但预制件本身并不知道这个场景，打包后实例化时，那个场景对象可能根本不存在。Unity 对这种引用会给一个警告（"Prefab has a reference to a scene object"），但警告容易被忽略。
第二类：引用了 Resources 之外的非托管资源。直接用AssetDatabase路径或者某个目录下的资源，运行时如果不是通过Resources.Load或 Addressables 加载，引用会在打包后失效。这是老生常谈，但每年都有新项目踩。
第三类：序列化字段改名或类型变更。这是最隐蔽的一类。C# 脚本里一个public GameObject effectNode;改成了public GameObject fxNode;，序列化文件里的字段名对不上，引擎会静默丢弃这条数据，字段变成 null。不报错，不警告，只在运行时崩。
针对第三类，我的做法是公共字段一律用[SerializeField] private，然后加一次性的重命名迁移方法，或者干脆在字段上加[FormerlySerializedAs("effectNode")]。这个特性在重构时能救命，Unity 会在反序列化时按旧名字找一遍数据。
排查断引用最直接的工具是编辑器脚本，扫一遍所有预制件的所有组件，检查有没有 null 的序列化引用：
using UnityEngine; using UnityEditor; using System.IO; using System.Reflection; public class PrefabReferenceChecker : EditorWindow { [MenuItem("Tools/预制件引用检查")] public static void Check() { string[] guids = AssetDatabase.FindAssets("t:Prefab", new[] { "Assets" }); int broken = 0; foreach (var guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); GameObject go = AssetDatabase.LoadAssetAtPath<GameObject>(path); if (go == null) continue; var components = go.GetComponentsInChildren<Component>(true); foreach (var comp in components) { if (comp == null) { Debug.LogWarning($"[缺失脚本] {path}"); broken++; continue; } var fields = comp.GetType().GetFields( BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance); foreach (var f in fields) { bool serialized = f.IsPublic || f.GetCustomAttribute<SerializeField>() != null; if (!serialized) continue; if (typeof(Object).IsAssignableFrom(f.FieldType)) { var val = f.GetValue(comp) as Object; if (val == null && f.FieldType != typeof(Object)) { Debug.LogWarning( $"[空引用] {path} :: {comp.GetType().Name}.{f.Name}"); broken++; } } } } } Debug.Log($"检查完成，共发现 {broken} 处可疑引用"); } }这个脚本不能覆盖所有情况（比如故意留空的字段会被误报），但作为打包前的自查工具足够了。我一般在版本提测前跑一遍，把警告清干净。
3.4 实例化性能：预制件配置里那些不影响功能但影响帧率的东西
预制件配置还有一个常被忽视的维度：实例化开销。一个预制件的层级越深、组件越多、挂的脚本越多，Instantiate的时候就越慢。在对象池里批量生成时，这个开销会集中爆发。
几个实测有效的优化点：
- 控制层级深度。每多一层 Transform，实例化时就多一次构造。我见过一个特效预制件嵌套了 12 层，单个实例化要 0.8ms，一次弹 30 个就是 24ms，直接掉一帧。后来压到 4 层，降到 0.2ms。
- 减少不必要的空 GameObject。有人喜欢用空节点做"分组"，视觉上整洁，但每个空节点都是实例化成本。能用组件本身做锚点的，就别加空节点。
- 脚本数量精简。一个预制件挂 10 个脚本，每个脚本都有自己的
Awake、OnEnable，实例化时会依次调用。能合并的合并，能延迟初始化的延迟。 - 静态标记谨慎使用。
Static勾选后会走静态批处理，但这些对象就不能移动了。预制件上的静态标记在实例化后是带过来的，如果一个本该移动的道具预制件在身上勾了 Static，运行时你会看到它在原地闪烁。
提示：如果预制件是用对象池管理的，把
Instantiate的第一次预热放在加载界面做掉，不要等到战斗里第一次用到才生成。这个改动几乎零成本，但能明显减少卡顿。
4. 两条链路怎么打通：把配置规范落到工程里
4.1 命名和目录：不是强迫症，是为了能写自动化脚本
资源和预制件的命名规范，很多团队觉得是形式主义。但只要你想写任何自动化校验脚本，第一步就卡在"怎么识别这个资源是什么类型"。我的做法是给每类资源一个固定前缀：
| 资源类型 | 前缀 | 示例 |
|---|---|---|
| UI 图标 | icon_ | icon_common_close.png |
| 图集 | atlas_ | atlas_battle.spriteatlas |
| UI 预制件 | ui_ | ui_shop_panel.prefab |
| 场景物件预制件 | obj_ | obj_barrel_01.prefab |
| 角色预制件 | char_ | char_enemy_slime.prefab |
目录结构也跟着分层：Assets/Art/UI/Icons、Assets/Art/UI/Atlases、Assets/Prefabs/UI、Assets/Prefabs/Characters。这样写脚本时，一条FindAssets("t:Prefab", new[]{"Assets/Prefabs/UI"})就能精准扫到目标范围。
命名还有个细节：不要用中文、不要用空格、不要用大小写混排。有些平台的打包工具对路径大小写敏感，Windows 上开发、Linux 上构建的时候，Icon_Close.png和icon_close.png会被当成两个文件。
4.2 一份可以照着执行的核对清单
下面这张表是我现在每个版本提测前必过的一遍，贴在团队协作区，新人也能照着做：
| 检查项 | 怎么查 | 合格标准 |
|---|---|---|
| UI图标的 Texture Type | 批量选中看 Inspector | 全部为 Sprite |
| Read/Write 是否关闭 | 同上 | 全部未勾选 |
| UI图标的 Mipmap | 同上 | 全部未勾选 |
| 图标是否都在图集里 | Sprite Atlas 的 Packed Sprites 列表 | 无遗漏，占用率 <80% |
| 图集是否 Include in Build | Atlas 的 Inspector | 勾选 |
| 应用图标各平台槽位 | Player Settings → Icon | 安卓前景/背景、iOS 逐尺寸都有 |
| iOS 图标无透明通道 | 源文件属性 | Alpha 通道已移除 |
| 预制件空引用 | 跑一遍上面的检查脚本 | 0 条警告 |
| 预制件层级深度 | 目测或脚本统计 | ≤5 层 |
| 预制件是否引用场景对象 | 检查脚本扩展或手动 | 无 |
| Prefab Variant 基类是否变更 | 对比上一版本 | 无未同步的结构改动 |
这张表看起来长，跑一遍熟练之后大概十几分钟。但不跑的话，问题会在测试阶段以"UI显示异常""闪退"的形式回来找你，成本是十倍以上。
4.3 让规范变成脚本，而不是口头约定
清单再详细，靠人自觉执行迟早会漏。真正靠谱的做法是把能自动化的部分写成编辑器脚本，挂在打包流程前。
比如图标导入设置的批量校验与修正，可以在AssetPostprocessor里做：
using UnityEditor; using UnityEngine; public class IconImportRule : AssetPostprocessor { // 图标放在 Assets/Art/UI/Icons 下时自动套用规范 void OnPreprocessTexture() { if (!assetPath.StartsWith("Assets/Art/UI/Icons/")) return; TextureImporter importer = (TextureImporter)assetImporter; importer.textureType = TextureImporterType.Sprite; importer.spriteImportMode = SpriteImportMode.Single; importer.isReadable = false; importer.mipmapEnabled = false; importer.wrapMode = TextureWrapMode.Clamp; importer.alphaIsTransparency = true; importer.maxTextureSize = 256; importer.textureCompression = TextureImporterCompression.CompressedHQ; } }这段代码会在任何资源被导入前检查路径，命中规则就强制套用设置。好处是新来的美术同学不管怎么拖图，配置都是对的，不需要额外沟通。
同理，预制件这边可以做一个打包前的批量检查，把前面那段PrefabReferenceChecker扩展成自动执行：在IPreprocessBuildWithReport接口里调用检查方法，如果发现严重问题就直接BuildFailedException中断打包。这样"带着断引用打出来的包"这种事从流程上就被堵死了。
using UnityEditor.Build; using UnityEditor.Build.Reporting; public class PreBuildValidator : IPreprocessBuildWithReport { public int callbackOrder => 0; public void OnPreprocessBuild(BuildReport report) { int broken = PrefabReferenceCounter.Count(); if (broken > 0) { throw new BuildFailedException( $"预制件检测到 {broken} 处空引用，已终止打包"); } } }这两个脚本加起来不到100行，但省下来的排查时间是以小时计的。我个人认为，小团队最值得投入的技术建设不是框架，是这类"防止低级错误发生"的自动化。框架可以后面再换，低级错误每出一个都要人命。
5. 一些散落在实际项目里的经验碎片
图标和图集这块，还有一个经常被忽视的成本项：图集重新打包的时间。项目后期图标数量上去之后，每次改动一张图，整个图集都要重烘一次，如果图集分得不合理（比如把不相关的图标全塞一张），改一个小图标要等半分钟。我的处理办法是把更新频率差异大的图标分开建图集，稳定不变的放一张大的，经常变的单独放小的。
预制件这边，我最想分享的一条是：不要在预制件实例上做"临时试验"。很多人调试时会随手给实例换个材质、改个位置、删个子节点，觉得等会儿 Revert 掉就行。问题是这些东西会变成覆盖项存在场景文件里，如果场景被提交了，别人打开就是另一副样子。后来我们在团队里约定，凡是试验性修改，一律复制一份预制件到临时目录里改，改完删掉，原型链路干净得多。
还有一件事值得提一下：预制件的序列化字段命名尽量别动。项目做久了，脚本重构是必然的，Rename一下变量名看着很清爽，但序列化数据是按名字存的。真要改就加上[FormerlySerializedAs]，或者干脆不动，在注释里说明用途。我现在的习惯是，给这类字段的名字都起得稍微长一点、语义重一点，避免以后手痒想改。
最后说个和工具链相关的观察。图标和预制件的配置工作，本质上是"资源治理"的一部分，做得好没有存在感，做得差处处是坑。我见过不少团队把这件事完全交给某一个人，交接的时候靠口头传授，人一走全部从头再来。真正稳的做法是在工程中留下痕迹：导入规则写成 Postprocessor，检查项写成脚本，规范和目录结构写进 README，让下一个接手的人打开工程就能看懂规矩是什么。这件事花的功夫是一次性的，收益却覆盖整个项目周期。
