做3D游戏开发这几年我越来越觉得跟AI协作写图形代码这件事难点从来不在AI本身而在怎么把话说明白。尤其是着色器Shader这种又吃数学、又吃管线知识、还特别依赖目标平台的东西一句帮我写个溶解效果基本得不到能用的结果。所以我一直保持一个习惯把高频遇到的图形开发场景沉淀成一套可复用的AI提示词模板。这次整理的100条就是围绕高级图形与着色器这个主题展开的系列第二弹覆盖代码生成、效果调试、性能优化、风格探索等完整场景专门给Unity、UE、Godot的开发者以及TA、独立游戏开发者用。文章会把这套提示词的分类逻辑、代表性写法、实战用法和踩坑经验一次性讲透方便你直接拿过去改造进自己的工作流。1. 为什么图形开发比任何环节都更需要提示词工程1.1 通用提示词在着色器面前的集体失灵很多人问过我一个问题我让AI写业务逻辑代码效果还行怎么一到渲染相关就变成人工智障了答案其实不复杂。普通的业务代码比如背包系统、敌人AI、对话逻辑它们的上下文往往是封闭的——入参出参明确逻辑靠几个if和for就能讲清楚AI只需要理解输入A、输出B就够了。但着色器不是这样。一个着色器程序哪怕只有几十行它背后藏着的东西是渲染管线用的是前向还是延迟、光照模型是PBR还是卡通、坐标空间怎么变换、纹理采样用了哪些UV语义、目标设备支持到OpenGL ES 3.0还是Vulkan、SRP Batcher有没有冲突、变体膨胀会不会杀死编译时间。这些上下文如果你不在提示词里交代清楚AI就只能根据训练数据里的平均水平瞎猜。猜对了是运气猜错了才是常态。你可以把写提示词想象成给一位顶级程序员下需求但这位程序员最大的特点是看不见你的项目也没有提问的习惯。你给的信息越模糊它交出来的东西就越泛化。所以图形开发领域提示词不是可有可无的润色而是整个协作流程里的需求规格说明书。没有这一层AI生成的Shader代码大概率只能在编辑器里好看进不了真机。1.2 图形开发者的真实痛点查错和调参才是时间黑洞做渲染的人应该都有共鸣写Shader本身不难难的是写完之后的调试。编辑器里一片洋红色你不知道是语法错、语义错还是平台特性不支持。跑起来效果不对你一条条注释掉代码去定位问题一次就是半小时。调到差不多能看了打包上手机帧率又掉得没法玩。这种时候打开ChatGPT敲一句为什么我的Shader在手机上很卡它根本没法回答因为问题本身就不够具体。但AI在这件事上其实潜力巨大它熟记大量文档、GitHub仓库、论坛问答比任何一个单独开发者见过的报错都多。问题在于我们得用提示词把模糊症状转换成可诊断的信息——这就是为什么我坚持要建一套专门的提示词库而不是零散地每次问一嘴。同样一个描边断裂问题你用帮我看看为什么描边断了和用我有一个基于视角方向计算的轮廓线效果在Android端某些机型上描边出现断裂疑似半透明物体排序导致请检查我的深度写入方式并给出两种修复方案得到的结果完全是两个等级。所以这套提示词本质上就是在帮所有被调试和调参折磨的图形开发者把向AI表达问题这件事标准化。它解决的不是AI能不能写Shader而是AI能不能稳定地写出你看得上、还能用的Shader。2. 100条提示词的分类框架与设计思路2.1 按任务场景划分而不是按图形知识点划分最开始规划这套提示词时我考虑过两种组织方式。第一种是按技术点来分比如顶点着色器一类、片元着色器一类、后处理一类听起来好像很系统但实际用起来特别别扭——因为现实中没人会单纯想写一个片元着色器大家的诉求永远是我要做一个XXX效果可能同时涉及顶点、片元、深度、模板缓冲、后处理。所以我最终采用了按任务场景划分的方式。100条提示词分成了六类效果实现类、代码生成类、调试排查类、性能优化类、美术风格探索类、工具与工作流类。这个划分的核心逻辑很简单你在实际开发里遇到什么任务场景就去对应的分类里找提示词而不是跟着图形学教科书走。分类数量典型场景效果实现类24溶解、描边、体积雾、冰块折射、全息投影等具体效果代码生成类22把需求描述变成可编译的ShaderLab/HLSL/GLSL代码调试排查类18渲染错误、现象异常、平台兼容问题定位与修复性能优化类16带宽、指令数、变体、移动端发热卡顿调优美术风格探索类12卡通渲染、写实风格、风格化水、赛博朋克光效等工具与工作流类8与引擎、插件、构建管线、AI工具的配合2.2 为什么需求描述上下文是提示词的第一要素在这100条提示词里几乎每一条都包含一个共同的结构上下文、目标、约束、验收标准。这是我在反复使用中总结出来的四要素。上下文是让AI知道你在什么环境里工作比如采用URP管线的Unity 2022.3项目移动端目标为主。目标是你要达成的最终效果比如一个角色死亡时的溶解效果边缘带自发光过渡受击时加速溶解。约束是明确告诉AI不能做什么比如不要使用动态分支不要新增额外Pass不要在片元着色器里做循环采样。验收标准则是你判断结果好坏的依据比如在iPhone 11级别设备上帧率不低于60fps变体数量控制在一个。这四个要素缺一个提示词的质量就会肉眼可见地下降。缺上下文AI会默认选中它的偏见设置比如生成一套需要额外Shader.PropertyBlock才能配合的代码缺目标AI就无从判断重点效果做得花里胡哨但核心表现缺失缺约束AI肆无忌惮地用各种高级特性最后在移动端直接编译失败缺验收标准AI不知道自己写得合不合格产出的代码风格和技术取向会很随机。2.3 难度梯度的刻意安排从给灵感到给可上线代码这100条提示词并不是一个平的清单我刻意设计了三条难度线。第一条是灵感线适合在效果拿不准时用。比如我想做一个带有科技感的全息投影效果不要能量护盾那种烂大街风格给我五个偏写实的方案每个方案说明技术路径和性能代价。这条线的提示词输出的是思路和方案而不是代码用来打开脑洞、提前避坑。第二条是进阶线适合做技术验证。比如请用HLSL写一个基于高度的雪地覆盖效果顶点偏移和片元着色都要包含积雪厚度由一张R通道贴图控制并且可以交互式刷积雪覆盖区域。它要求AI给出能跑的代码但一般不涉及严格的性能优化适合在验证阶段快速试错。第三条是上线线也是我强调最多的。比如请给我一个可直接用于URP管线的描边效果要支持描边粗细随距离变化不能额外产生Draw Call在移动端Vulkan下无闪烁请给出ShaderLab完整代码以及参数面板注释。它要求的是工程级代码所有细节都要为交付负责。实战中我建议从灵感线进在进阶线做技术选型最后用上线线收口这样100条提示词能覆盖个人开发者和团队TA的不同需求。3. 核心提示词示例与用法拆解可直接抄3.1 效果实现类把我想要翻译成AI能执行效果实现类的提示词是所有分类里使用频率最高的因为它解决的是从美术需求到技术方案的翻译问题。下面这条是我常用的模板以科幻角色边缘发光为例我需要实现一个角色边缘发光效果用于科幻风格的角色选择界面。 - 平台Unity 2022.3 URP管线目标平台PC和安卓需要同时兼容。 - 效果要求边缘发光的宽度约2-5像素光圈随距离轻微呼吸颜色为青蓝色。 - 技术限制不要使用后处理方案因为角色要嵌在UI界面中禁止新增渲染Pass必须在URP的Lit基础上扩展。 - 输出要求给出ShaderLab完整代码关键参数要暴露在Inspector面板中注释用中文注明每个参数的物理意义。这条提示词的关键在于必须在URP的Lit基础上扩展这个约束。很多AI生成的边缘光效果方案是做一次单独的边缘检测后处理或者给物体加一个额外的Pass来输出轮廓。但实际你的需求是嵌在UI里的角色展示用后处理方案会打出整个屏幕用额外Pass又可能和Lit的深度写入冲突。你在提示词里提前把这些坑堵死AI就必须在Lit的片元着色器里想办法这才可能产出真正能用的方案。用了这类提示词之后我要提醒一个常见认知误区AI第一次给的效果参数往往非常激进边缘光宽度、强度、噪点密度全都拉得很满。这是因为它学到的演示工程都是这种风格。你需要用后续对话把它压回来而不是指望一次生成就完美。我会在后面讲这种多轮迭代的操作方法。3.2 代码生成类五个必填字段让生成结果稳定可用代码生成类是100条提示词里最硬核的它要求AI直接交付可编译的Shader代码。根据我的使用经验想让结果稳定提示词里必须包含五个字段目标API与版本。Shader代码对平台的敏感度极高比如Unity里同样是移动端OpenGL ES 3.0和Vulkan的浮点精度行为就不一样半向量计算、导数指令的支持程度也不同。你告诉AI目标是URP 14使用Vulkan后端的安卓设备和只说安卓手机得到的代码质量会有代差。依赖的输入资源。比如使用一张MainTex的Albedo贴图、一张灰度噪声图、一个自定义的_Cutoff标量。AI看到输入明确就会顺着这个数据结构去组织代码而不是自作主张使用一堆你没准备的纹理。关键算法约束。比如顶点色用来控制遮罩区域法线方向不需要重新计算直接用v.normal。这些约束表面上是技术细节实际是在防止AI引入它偏爱的复杂流程。不能使用的特性。这是一个反直觉但极其有效的字段。比如不要使用Compute Shader不要使用顶点纹理采样不要在片元着色器中使用lerp做超过三次的混合。AI大模型的训练数据里充满了各种高端酷炫的特性你不禁止它就不由自主地用。把这些不能用写清楚输出的代码反而会回归朴实的可运行路线。可验收的结果形态。比如输出完整ShaderLab代码包含Properties、SubShader、Fallback并给出Inspector面板上每个参数的取值范围建议。这让AI明确知道它的输出是要给人用的工程文件而不是一段教学示例。下面这条代码生成类提示词是我实际项目的翻版效果是在原作基础上加了本地空间的扰动请为URP管线生成一个局部顶点扰动着色器供角色披风布料使用。 - 输入纹理一张布料纹理 _MainTex一张遮盖扰动范围的 _MaskTexR通道有效。 - 扰动方式用 _SinTime.y 作为时间驱动顶点沿本地法线方向偏移偏移量 扰动幅度(_Magnitude) * 遮罩值 * 正弦波。 - 禁止禁止在片元阶段采样 _MaskTex禁止写自定义光照模型直接使用URP的Lit函数。 - 输出完整ShaderLab代码标注属性范围主纹理使用Unity默认的_MainTex白纹理兜底。你看这样一个提示词输出的代码基本不需要改动就能挂到材质球上用了。3.3 调试排查类让AI当你的代码审查员调试排查类的提示词核心不是让AI直接给答案而是让AI理解你的观察和推断和你一起定位问题。我自己调试Shader时最常用的一种提示词结构是复述现象 → 说明已验证的信息 → 列出怀疑方向 → 请AI排优先级。举个例子我有一个描边效果基于视角方向计算轮廓。在PC上表现正常但在骁龙8Gen1安卓机上角色转身时描边会出现断续的闪烁同时角色背后偶尔有半透明物体穿帮。 已验证信息 1. 半透明物体使用AlphaBlend没有写入深度。 2. 描边在单独的Pass中渲染采用Cull Off。 3. 关闭后处理中景深效果后闪烁明显减少。 请帮我分析可能的原因并按可能性从高到低排序给出每种原因的验证方法和修复方案同时说明修复方案的性能代价。为什么这种写法比帮我修下描边闪烁好用得多因为你已经替AI缩小了几十倍的问题空间。它不需要从描边闪烁这个全世界成千上万种原因里去找只需要在半透明混合、Pass顺序、后处理深度冲突这三个小范围里推理。AI在这种引导下给出的答案准确率会高非常多。这种排查式提示词还能帮你做预检。我有好几次在真机上调试前先把代码和现象丢给AI做一轮预分析它往往能提前告诉你这个现象大概率是敌对的深度冲突建议你先检查××参数省掉了在真机上反复烧版本的痛苦。3.4 性能优化类让AIReview而不是重写性能优化的提示词我最忌讳的是让AI优化一下。这种指令太开放AI通常会做两件事把代码重构成它认为的更高效形态或者在注释里写一堆假大空的优化建议。这两种都不是你想要的。正确的做法是让AI审查并量化。下面这条模板我在移动端项目里反复用请Review以下Fragment Shader代码重点排查带宽消耗和ALU指令数。 审查要求 1. 识别所有纹理采样次数指出哪些采样可以合批或减少。 2. 检查是否存在循环内的常量计算若能提出来请标注。 3. 检查是否使用了动态分支若有请给出无分支替代方案。 4. 给出优化前后的大致指令数估算说明优化对移动端GPU以Adreno 730为例的影响。 5. 最终输出一份优化后的完整代码但必须保持视觉效果不变。这里面有个很微妙的点你让AI估算指令数再给完整代码它就有了论证压力不会随手乱改。我实测下来AI在这种模式下给出的优化方案更克制通常它会选择消除重复采样、提取常量、用lerp替代分支这类相对安全的手段而不是推倒重来。相反如果你只是说帮我优化下性能它有概率把整个Shader重写成完全不同的算法视觉效果直接就崩了。配合性能优化提示词的另一个做法是让AI反向教你。比如你看不懂它优化的某个步骤可以继续追问为什么把两个纹理采样合并成一个就能省带宽你从内存访问的角度给我讲讲。这种追问式提示词虽然不在100条清单里但它是从清单派生出来的好玩法能帮你真正提升对渲染管线的理解。4. 实战从提示词到可用材质的完整工作流4.1 完整需求的第一次描述光讲模板不讲实战没有说服力下面我用一个角色死亡溶解效果完整走一遍从提示词到材质球落地的流程。第一步我会用效果实现类提示词先把需求宽泛地描述一遍我要为动作游戏实现角色死亡溶解效果。 效果预期角色从脚部向上溶解消失溶解边缘有亮橙色的灼烧过渡带过渡带宽度约10%的角色身高。 平台Unity 2022.3 URP目标是PC为主、兼容中端移动设备。 素材现状所有角色使用同一套PBR材质没有单独溶解贴图希望你用程序化噪声实现。 特别说明角色在溶解过程中仍然需要参与光照不允许变透明后直接关闭渲染。注意我特意加了没有单独溶解贴图用程序化噪声这个约束。这是为了逼AI用它训练数据里最常见的Perlin噪声或Voronoi噪声方案而不是套路化地生成一张要美术额外准备的溶解图。然后AI会给出一个方案建议一般会选择在片元着色器里结合Clip函数实现你可能还会收到一段关于为什么用clip而不是alphaBlend的解释。到这里第一步就算完成了。4.2 分步生成代码别指望一次到位AI给出方案后不要直接说好把代码给我而是要分步要。我会这样连续对话第一步让它先搭骨架请基于上面的方案先输出ShaderLab的代码框架包括属性定义、Pass结构、顶点着色器、片元着色器的空实现先不要写具体算法。这步的价值是让AI先明确代码的组织方式确保后续算法是填进一个正确的骨架里。等骨架没问题了再要求它填充核心算法在片元着色器中加入程序化噪声溶解逻辑溶解阈值由_Cutoff控制在阈值附近渲染灼烧边缘色。最后让它补齐细节给灼烧边缘增加基于噪声梯度的发光并把相关参数全部暴露到Inspector面板。这种分步生成看起来多花了几轮对话实际上每一轮输出的代码都更干净、更好检查。一次性让AI输出全部完整代码一旦出现编译错误或效果不符合预期你很难分辨是骨架的问题还是算法的哪部分出了问题。分步生成则让你每一步都有明确的检查点每一步错了都能及时纠正。4.3 人工检查清单AI代码到手后的必经工序AI把代码生成完不等于工作做完了。我在拿到AI生成的Shader后不管它说得多自信都会过一遍自己的检查清单。这份清单是长期踩坑踩出来的第一检查所有UV和贴图采样确认语义是不是对的。AI特别喜欢生成一个叫uv_MainTex的变量但URP的Lit结构里UV的传递方式要和对应Tiling/Offset配套否则贴图平铺一改就全乱。第二检查透明与深度。如果你的效果用了透明度变化那就要想清楚深度写入和渲染队列的问题。很多AI生成的溶解效果用了clip丢弃像素这部分没问题但它如果用了alpha blend方式就容易出现半透明物体排序错乱角色身体前后面穿插。遇到这种情况要么强行要求AI只能用clip要么提醒它考虑两个Pass分开渲染。第三检查SRP Batcher兼容性。URP里所有Material属性必须通过CBUFFER声明才能被SRP Batcher正常合批。AI生成的代码有时漏掉CBUFFER或者把属性放到了函数内部肉眼很难注意到。我用一个简单的排查方法让AI自己声明这段代码是否满足SRP Batcher兼容要求若不满足请修正效果不错。第四检查变体数量。AI生成代码时往往不会在意Shader变体但它可能会引入多个多编译指令导致构建时变体爆炸。我在项目实际遇到过AI生成的一个效果让打包时间从3分钟涨到17分钟原因就是它在代码里加了三个multi_compile每个都交叉组合了一堆关键字。后来我在提示词里固定加一句尽量减少multi_compile指令优先使用动态分支或宏替换问题基本就消失了。4.4 多轮迭代中的真实对话记录下面截取一段我的真实迭代对话你可以直观看到提示词怎么跟着实测结果走。第一轮AI给出了可直接溶解的代码我上机测试后发现溶解边缘的灼烧带太宽而且在角色转身时边缘出现锯齿闪烁。第二轮我会说边缘太宽是因为_EdgeWidth设为0.15过大请给我一个合理的取值范围参考同时把边缘过渡改为基于噪声值梯度而不是恒定宽度。AI会调整算法让它只有在噪声变化剧烈的区域才产生灼烧效果。第三轮可能还有问题角色透明部分遮挡了后面的敌人这是因为溶解后像素被clip丢弃了理论上不该遮挡。但检查后发现AI在顶点着色器里动了透明度相关的输出我立刻补充约束保持clip丢弃逻辑不要在顶点阶段修改透明度所有溶解判定放到片元着色器统一处理。AI改完之后遮挡问题就消失了。通常一个看着简单的溶解效果我至少会迭代三到五轮。AI生成20%的代码剩下80%的时间都在我真机测试→发现细微问题→追加提示词约束→重新生成这个循环里。提这个词看着琐碎但每一次追加的约束都在帮AI更精确地理解你的项目后面再让它生成类似效果时质量会有肉眼可见的提升。5. 提示词工程踩坑与避坑实录5.1 AI生成Shader的五个典型翻车点我在多个项目里让AI写过各种Shader翻过很多车这里把最高频的五个问题记下来推荐你直接收藏。第一目标平台差异导致的编译崩溃。AI在训练时见过大量桌面端Shader代码随手就会用上一些在移动端不受支持的特性。最典型的是在片元着色器里使用偏导数指令或者依赖早期深度测试的写入时机。桌面GPU的驱动宽容度高移动端GPU对这种问题零容忍常常直接编译失败。避坑方法就是前面反复强调的把目标平台写死在提示词里并在代码审查时重点看有没有用到衍指令、顶点纹理采样这类危险操作。第二数学运算精度错误。AI生成的法线变换代码偶尔会直接拿模型矩阵乘以法线方向这在非统一缩放时就错了。真正安全的做法是用逆转置矩阵或者直接用Unity内置的物体空间法线。这类错误在编辑器里很难发现因为很多测试物体的缩放是(1,1,1)只有你把物体拉伸之后光照才突然变得奇怪。避坑方法是让AI在输出代码时主动标注法线变换是否考虑了非统一缩放碰到没标注的直接追问一句就行。第三不认识引擎版本之间的API差异。Unity不同版本之间URP的API变化非常大。比如2022.3的URP里很多内置函数和Shader库的引用路径变了AI如果用到旧版本API代码编译就报红。我让AI生成的代码经常需要手工改一行把#include Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl改成实际项目的路径。这种问题AI自己很难发现因为它看不到你的工程文件路径。实际操作中我养成了让AI先自报此代码适用的Unity版本和URP版本范围的习惯。第四过渡设计导致性能踩雷。AI有很强的堆料倾向一个简单的玻璃效果它可能给你叠了三层折射、两层反射探针采样、一次屏幕空间散射。效果是很炫但中端手机直接卡成PPT。我看过AI生成的一段水Shader片元着色器里嵌套循环做了6次纹理采样这种代码在PC上没问题在Adreno上就是个灾难。所以我在性能优化提示词里会专门加一句请评估每个操作在移动端GPU上的相对成本优先保证帧率。第五逻辑正确但美术表达错位。AI不知道你的游戏调性它生成的科幻风能量盾永远是蓝紫色调高饱和边缘光。你说我要偏写实的魔法护盾它还是给你一堆霓虹色。这不是技术问题但同样致命。我的习惯是在美术风格探索类的提示词里同时给出不要什么比如不要赛博朋克的粉蓝配色不要高饱和自发光不要锐利的闪烁要有柔和的过渡。这些不要往往比要什么更能约束AI的美术输出。5.2 常见问题速查表下面这个表格是我在实际上班过程中积累的你可以直接打印出来贴工位上。问题现象可能原因排查思路修复方式材质球显示洋红色编译失败通常是API错或路径错看Console报错定位HLSL引用路径修改include路径为项目对应URP版本手机上效果与PC明显不同精度或半精度裁剪/平台特性差异检查是否使用了half/half2、灵活坐标在提示词里要求保证移动端浮点精度稳定粒子系统使用了该Shader后特别卡粒子使用了同一个材质变体分支查看变体数量看是否多个multi_compile改用静态分支或减少multi_compile物体拉伸后光照错误法线未使用逆转置矩阵检查法线变换代码改为TransformObjectToWorldNormal溶解边缘锯齿闪烁噪声梯度变化太快增大噪声频率的平滑度引入更多噪声层做平滑混合半透明对象排序混乱深度写入未正确配置检查透明队列和ZWrite改为两个Pass后Pass半透明写入深度5.3 让AI更听劝的措辞技巧最后分享一个关于怎么说的实操经验。同样一个需求用不同的语句表达AI生成的质量差异很大。我总结了一条规律否定式约束要放在肯定式目标前面。如果你的提示词写成我要一个有金属质感的溶解效果能接受的话尽量不用动态分支也行AI大概率会优先满足金属质感溶解效果把动态分支的事忘在脑后。反过来写不要使用动态分支任何三角函数的调用必须放在顶点着色器在这个前提下实现有金属质感的溶解效果AI就会把你划的红线当作硬性条件在这个框里做文章。另外AI对话是有记忆衰减的上下文越长它对你最早说的约束就越淡。处理办法是把关键约束在每次提问里重述一遍。哪怕你觉得啰嗦也要坚持在每一轮迭代中重复URP管线移动端兼容不要动态分支这几条。这就像给一个记忆力不太好的同事写备忘虽然烦但确实有效。6. 从这100条到你的专属提示词库6.1 把提示词当代码资产来管理我刚把提示词整理成系统时犯过一个典型错误每次需要时临时写一条用完就丢下次再重新编内容每次都不一样质量忽高忽低。后来我想明白了提示词跟代码一样也需要资产管理于是我开始用一个文本仓库专门维护。现在我所有提示词都存在一个Markdown文件里每条带版本的增删记录。遇到效果很好的提示词就标上效果极佳某项目复用过三次遇到无效或翻车的就标注此写法导致生成代码不可用原因见备注。这个习惯半年下来我的提示词库已经从零散灵光变成了可靠工具箱。你要复制这套思路很简单建一个仓库每条提示词后面附加两个字段——适用场景和实测效果描述不需要多复杂但一定要坚持维护。6.2 提示词形态的跨领域复用这套提示词虽然标题里写着高级图形与着色器但你深入看就会发现它的底层思考方式是可以平移的。比如3D建模环节你让AI生成一个带褶皱的多边形网格布线方案或者three.js网页端做3D渲染时你让AI生成基于WebGL2的后处理溶解Shader核心思路都完全一致交代平台、交代目标、交代限制、再要可验收的结果。甚至更进一步的做免费商用引擎选型时你完全可以把Fine的选择问题也提示词化。比如对比Godot 4和Unity 2022.3在移动端2D游戏开发上的优劣势重点是包体大小、渲染性能、学习曲线我需要免费商用跟让AI生成Shader的底层逻辑一模一样。这些提示词写多了你会慢慢形成一种AI协作直觉知道什么信息该给、什么约束必须先说这套能力比100条现成清单值钱得多。6.3 我的日常使用习惯先讲思路再落代码最后讲一个我坚持很久的习惯也是我认为这套提示词真正发挥价值的地方不管让AI做什么效果我都会先要求它用三句话概括自己的实现思路我确认思路可行后才允许它写代码。比如我想让AI做一个冰块折射效果我会先问请先描述实现思路包括折射方案选择、是否需要屏幕抓取、性能开销大概是什么量级。如果它提到要用GrabPass我就直接否决因为移动端GrabPass的带宽开销太大如果它提到用视差映射模拟折射我就可以进一步讨论。这一步思路确认看起来浪费了一轮对话但实际上帮我避免了无数次生成代码后才发现方向就错了的大规模返工。你可以把这种做法理解成先和AI对齐需求再让它施工。它跟我们带实习生是一个道理——上来就写代码的实习生大概率要返工先讲方案、你点头了再动手效率反而更高。我建议你把这100条提示词当成一个起点而不是终点。每条提示词都只是种子真正长成适合你项目的工具靠的是你在每一次实战里和AI来回碰撞出的那些修正和补充那才是真正属于你的东西。