res在游戏里是什么？

一、res在游戏里是什么？

RES：复活Resurrect / Rescure的缩写，指复活暂时死亡的角色。

其他意思:

1、ATK：攻击

在游戏中ATK代表攻击力，是attack的缩写。

2、DEF：防守、物理防御力

DEF - Defence防御，游戏里的简称。

3、INT：智力 （魔法攻击力，魔法值）

INT为“智力”属性，全称为“intelligence”。多指代游戏中角色的属性。

4、HIT：命中率

在游戏里有打击，击中，造成伤害的意思。一般多出现于竞技类游戏之中。

5、SPD：速度

在游戏里，SPD是speed的缩写，表示速度

二、设计游戏技能时，怎么想技能名称？

找个狂拽酷炫吊炸天的词或句子照着改。

例如

绚烂缤纷花绽放，

超级水流大漩涡，

驾雷驭电戏冲浪，

认真起来大暴击，

之类的。

三、游戏ui技能设计

游戏UI技能设计

在游戏开发中，UI技能设计 扮演着至关重要的角色。好的界面设计能够提升玩家体验，增加游戏的吸引力。而在游戏中，技能系统是玩家与游戏世界互动的重要方式之一。因此，将技能系统与UI界面融合设计，不仅可以方便玩家操作，还能更好地展现游戏的乐趣和挑战性。

游戏UI技能设计的目标之一是提供清晰简洁的界面，使玩家能够快速理解和使用游戏中的技能。在设计过程中，需要考虑玩家的视觉习惯和操作习惯，确保界面布局合理，按钮大小适中，颜色搭配和谐。通过良好的视觉设计，可以引导玩家注意力，减少操作失误，提高游戏体验的流畅度。

另外，游戏UI技能设计还要注重信息的呈现和反馈。在技能界面上，需要清晰地显示技能的名称、描述、冷却时间等关键信息，让玩家一目了然。同时，及时准确的反馈玩家操作，比如按键音效、动画效果等，能够增强玩家的成就感，提升游戏的互动性。

游戏UI技能设计的关键要素

在实际设计过程中，需要重点关注几个关键要素，以确保技能界面的设计符合玩家需求并达到预期效果。

1. 游戏风格：UI设计需要与游戏整体风格相匹配，保持统一的视觉风格和风格一致性，能够增强玩家的代入感和沉浸感。

2. 交互设计：设计师需要考虑玩家的操作习惯和心理预期，合理安排界面布局和交互逻辑，提高游戏界面的易用性和友好性。

3. 反馈机制：及时准确的反馈是良好游戏体验的关键因素之一，玩家能够通过界面反馈得知自己的操作是否达到预期效果。

4. 视觉设计：包括按钮样式、颜色搭配、图标设计等，需要符合玩家审美，吸引玩家眼球，提升界面的美观度和可识别度。

5. 信息呈现：清晰明了的信息展示能够帮助玩家快速了解技能属性和效果，减少玩家的认知负荷，提高游戏的流畅度。

结语

综上所述，游戏UI技能设计是游戏开发中一个极为重要且值得重视的环节。通过合理的界面设计、交互设计和视觉设计，能够有效提升游戏品质和玩家体验，为游戏的成功打下坚实基础。在未来的游戏开发中，我们应不断探索创新，不断优化游戏UI技能设计，以满足玩家不断增长的需求和期待。

四、游戏有有哪些设计的特别好的游戏技能？

先说一下我对优秀游戏技能的评判标准。

1.玩家看到之后会兴奋，想要自己也试一试这个技能。

2.和游戏的题材、剧情充分结合。

3.最优秀的技能应在游戏中起到画龙点睛的作用。

1.《星之卡比》 吸收

卡比的吸收复制技能就完美符合上述三个条件。

玩家可以操作卡比，吸收怪物并复制怪物的能力。

犹记得长辈把弟弟妹妹甩给我的时候，只要把GBA拿出来，插上《星之卡比 镜之大迷宫》就可以一直不用问了。

对于孩子来说，光是把所有遇到的怪物都咽下去试试会获得什么能力，就足够玩上无数个下午。

同时这个技能设定与卡比什么都能吸进去的基础设定完美贴合。

吸收复制在《梦之泉物语》中第一次登场。

凭借这一创新，《梦之泉物语》在已经处于末期的FC平台上取得了过百万的销量。同时这个技能设定也成为星之卡比系列的招牌。

另外提一句，卡比之父就是如今大名鼎鼎的《任天堂明星大乱斗》的制作人樱井政博。

2.《刺客信条》 鹰眼

在刺客信条的世界观中，拥有先行者血统的人可以激发这种能力。

游戏中，开启鹰眼可以快速发现并标记敌人或目标NPC，追踪敌人痕迹，发现隐藏信息等。

如果刺客信条中没有鹰眼这个技能，整个潜入与刺杀目标将变得非常繁琐，恼人。

有了鹰眼之后，不但加强了主角异于常人的优越感。

同时也方便玩家进行潜入，确定关卡目标。

《巫师》中猎魔人的追踪能力也有相似之处，不过不会像鹰眼这样贯穿整个系列，成为游戏核心中不可缺少的一环。

在刺客信条起源之后，育碧已经把鹰眼升级为鹰的眼睛。

当然育碧也为了这个升级，也做了额外的设定。

纵观历史，有两个人展示了一种先进的鹰眼视觉，他们可以通过心灵感应看到和听到动物，尤其是通过鹰的感官。有两个已知的有这种能力的人分别是巴耶克，一位古埃及刺客和守护者，还有尤妮伊欧蒂，殖民地刺客拉通哈给顿的女儿。类似的版本也出现在古希腊，在伯罗奔尼撒战争期间被一位斯巴达的佣兵所使用。——刺客信条维基

3.《星际争霸2》折跃

直到今天我还记得当初在看《星际争霸2》宣传片时的兴奋与激动。

折跃科技是《星际争霸2》星灵的核心科技与种族特色。

折越科技在控制核心中研究。

完成后，玩家可以将传送门变形成折跃门。

直接在水晶能量覆盖的地方折越部队。

这简直太酷了。

在星际争霸1中，星灵特点之一是建筑只能在水晶塔周围建造。

折跃的加入使星灵的设定更加丰满。

星灵在星际争霸中给人的印象一直是，优雅，高科技，注重战斗精神的种族。

同时星灵的人口数量也较少。

折跃这一设定非常符合星灵的特征，战斗单位数量少，战斗时需要从各地折跃传送以集结部队。

同时围绕这一设定，也衍生出了花样繁多的战术。

在最早的自由之翼中的4BG战术（4兵营快攻）

到虚空之遗资料片中PVZ的神族空投白球开局。

数不胜数。

最后给不熟悉星际争霸的同学附上一段，我手打的4BG演示视频。

满足三个条件的优秀技能还有很多，比如《downwell》中的“枪靴”，《Braid》中的回溯等等。感兴趣的话，可以买来玩一玩。

五、元气骑士技能设计？

小皮游戏里有更详细的职业介绍。 解析，所以在使用一些高费的武器时也能保证蓝量，适合稳扎稳打的玩家朋友使用：一段时间内吸收所有伤害，不止一个圣骑士圣骑士 解锁条件，不容易缺蓝：1美刀 技能-能量护盾。 大概就是这样一个基本状况。升满星之后吸收的伤害将转化成能量，技能也是偏防御。

升满星之后技能可以回蓝：防御非常强大

六、RPG 游戏中的即死技能从设计上来讲是否就是花瓶技能？

让我来终结此题吧

先给个结论：rpg游戏的即死技能们从设计来讲需要巧妙构思才能物尽其用。

还是拿最终幻想5举个例子，让我们先看看隐藏boss神龙的图鉴：

看到长长的immunity(免疫)列表了没？

里面的异常有10种之多：毒 柯南 变蛙 石化 死亡 糊涂 麻痹 小五郎 老化 停止

这些异常属性都有各自的用处。

比如有个蓝魔法叫Lv5死亡，此魔法的效果是：秒杀等级能被5整除的敌人

那么现在遇到这样的boss，你会想到什么？

41级，如果能把它的等级除以2，那不就20了吗？(这游戏小数点后一律舍去)

正好蓝魔法师有一个技能叫黑之冲击，用了等级减半，再加上Lv5死亡魔法是不是瞬间秒杀？

萌新打这个boss只会看着自己的人物被boss的彗星魔法轰杀以后被吸入...

还有，最近啊，我在玩任天堂手游 失落的龙约。最近开的新boss叫彩羽和乙羽

看看这两只萝莉的笑容，是不是想守护一番？

这两只萝莉设定上血量通用，一起被消灭。如果一只一个血量，只要有一只不为0另一个就会无限复活呢？

是不是感觉彩羽和乙羽的笑容更灿烂了？

然而在ff5里就有这么种情况，堂堂boss战，三只不死族，只要有一只还活着另外两只就会复活并放出合体三角攻击！

怎么办？一只一只投凤凰之尾(阴间整不了阳间的东西)？那得全灭多少次？

正确方法是先把他们的血量削成个位数，然后召唤奥丁，一刀两断

这就是即死类攻击的用途，明白了吗？

奥丁怎么来的？它吃石化....用个基本上很难中的石化魔法对它是一击必杀，就像这样：

天神奥丁，真惨啊....

所以说嘛，这即死魔法好不好用，纯看游戏设计好不好。

还漏了一个魔法，叫时空传送，这个魔法在巫术类游戏里面非常有意思

在地图探索时使用，会传送到指定位置；

在遇敌时使用，会传送到随机位置。

如果这个位置在地图外，判定全灭...

而在最终幻想里面，这个魔法就只能试图秒杀敌人然后超低成功率，也算是游戏进化的一个牺牲品吧...

七、ui设计包括游戏设计吗？

ui设计主要是手机的界面设计，不包括游戏设计的

八、选择动漫设计还是游戏设计？

动漫设计主要是针对动漫的人物、场景设计。游戏设计的分类更加多，包括游戏程序设计、2d美工（如原画）、3d美工（如3d造型）等等。两者的区别在于：

一、动漫对计算机基础要求没那么高。游戏设计无论程序还是美工，都更需要熟练使用一些软件。

二、动漫设计对美术功底的硬性要求没游戏美工高。

三、在大环境下，游戏设计更加功利化一点，现在动漫产业比较惨淡。

九、卡牌类游戏中如何设计角色的技能体系?

跟策划朋友们聊到策略框架，说喜欢引用阴阳师的技能和套装设计，并在此基础上进行策略的二次改造。然后发现实现出来的技能功能重合度很高，多数体现在只能附加数值BUFF和控制BUFF上。

有时候为了提升策略丰富度只能强行往上再加新的策略层，但尴尬的是，新的策略层的组成还是那些模块。如果设计独立闭环的战斗机制，则会带来数值平衡上的长期维护量剧增。

问了一下操作，发现他们在分解战斗元素时是按效果去分类的，在写开发需求时也是以效果为基础单位去设计。于是涉世不深的程序在实现时直接敲出完整效果作为基础单位。请注意，一些效果其实是多个策略元素组成的。当你想单独调用这个效果中的一部分元素设计新的策略体系时，发现几个元素之间已经绑定封装了。如果在设计底层时就发现还好，但通常发现的时候已经是技能体系开发完成进行测试，甚至是上线后进行版本迭代时。这时候去调整是令人崩溃的。

那如何避免底层桎梏影响自由设计呢？

很简单啊，设计时策略元素足够细就行了。

我们来解析一下这类游戏的设计底层，从更底层的设计看策略元素可以怎么划分。

我们先选择一个解析目标。策略卡牌领军者为魔灵召唤和阴阳师。

其中魔灵召唤中的速度条延续了传统回合制的设计，对速度属性的体验感非常清晰，这是策略设计里的传统核心亮点之一。而阴阳师的设计转向了通过鬼火前置控制技能释放。

我们选择更传统的魔灵召唤，去解析这个半回合制卡牌的策略设计思路：

元素分层、状态设计、状态联动、流派设定。

一、元素分层

首先我们分拆一个攻击过程：从指令调起动作（攻击），调用属性计算动作结果（命中及伤害），到展示动作结果。

这个过程的所有元素可以分为动作层、结果层、属性层。

拆分的意义在于，策略的实现依赖于这些元素，而分层能够很好地对策略进行分类指导。

• 动作层，由卡牌直接发起的动作：攻击、治疗、复活等，一般统一为技能，范围自身。
• 结果层，实际上是被动动作层，如受击、死亡、被暴击，被控限制动作，行动条增减等，范围全局（自身队伍+敌方队伍）。
• 属性层，参与伤害计算的所有值。

一些组合属性也经常被归类为属性。如绑定动作的属性，反伤吸血等。这些组合属性也被玩家称为策略属性，即已经初步具备了改变战斗方式的策略。由于一些奇怪的属性被做成了可养成经常被调用，所以确实有程序是直接按属性做了。

二、状态：元素改变

而让我们认为一款游戏划策略强的依据，多数是游戏中状态种类的丰富程度。

那么状态是什么。状态实际上是对战斗内元素的额外改变。

魔灵的常规状态有三类：

• 数值BUFF，获得正负数值的附加，加入属性层进行伤害计算
• 行动BUFF，获得和限制行动的附加，展示在结果层
• 结果BUFF，以魔灵召唤为例，进入或免除结果（如免死免伤）、增减改变结果（增减行动条、行动回合）

//这部分就是在找出所有的元素之后，预设出这些元素可以如何发生变化

这里的设计工作就是设计元素可以如何变化的参数组合，以最通用易拓展的的方式。如：

• 中毒（每回合开始时进行无动作的攻击，扣除a类伤害X，持续Y回合，不可叠加，同名最多n个同时生效）
• 沉默（本回合仅进行普通攻击和反击，不参与合击，持续Y回合，不可叠加，同名可刷新，结束追加n%免疫抗）

这看起来，状态更像是一个结果，事实上当卡牌被赋予状态这个结果，确实是被归类在结果层。

既然是结果，那么它需要触发。后面触发机制就是基于状态的骚操作了。

三、技能：状态联动

我们重温一下攻击流程。

发起动作，调用属性，展示双方结果。

以上三段中，动作和展示结果（被动动作）广义上都属于动作层。而动作是默认的触发条件，于是动作跟状态的联动开始了。

1. 发起动作，触发状态
2. 展示自身结果，触发状态
3. 展示目标结果，触发状态

这时候我们想起来，状态中有2类状态分别对动作和结果进行了改变，且状态完成赋予后本身也属于一个结果。于是我们有了这个联动模型：

发起动作【触发状态（动作类）】……【触发状态（非动作类）】——调用属性——展示自身结果【触发状态（动作类）】……【触发状态（非动作类）】，展示目标结果【触发状态（动作类）】……【触发状态（非动作类）】

//这里可以看出触发结果为动作的状态收益极高

技能就是对联动模型的封装。

这里有人就问了，既然状态可以触发动作，那不是可以动作触发动作无限循环。理论上是可以的，魔灵中有一些特殊的技能就是A技能概率触发A技能。也有A触发B，B触发C的技能环。只是为了避免无限连环，它用概率去限制。

分层的作用在这里体现了一个指导意义：触发条件和触发结果一般不用同一层，如果一定要设计在同一层，那么最好在收益和触发概率上进行限制。

那结果触发结果呢？不存在的，任何结果都需要一个动作作为前置。哥们又问了，那我打出暴击，然后特性是暴击时目标瞬间秒杀。这不就是结果触发结果吗。其实这里属于我们语言描述的简化，正确的描述是：

如A攻击时对B打出暴击，则使B瞬间被击杀。

这里B的死亡结果，是A追加了一个无需展示的攻击动作，这个动作导致B被秒杀。因为秒杀特性是在A的身上，所以A需要追加动作使B死亡。而不是B带个特性叫“被暴击就去死”，那这B也太玻璃心了，不可取哈。这叫弱点，不叫策略。

从上面的联动模型看，联动可以做得非常花哨，五花八门的，一不小心就成开放式无限递归了，那怎样利用这个模型进行合理的框架搭建呢。流派预设就应运而生了。

四、流派设定

策略卡牌的核心在于队伍构建，构建目的自然是特性最大化，即最强流派。而流派的实现依赖于各层之间要素的联动即技能组合。

联动的结构一般是（特定数值最大化+此数值带来的联动终结效果）。如队伍为5张卡，则某一张卡为将数值转化为最终特性收益，其余卡为该卡叠加数值。

所以我们设定流派时，首先需要定下的是这个流派进行最终特性收益的技能方式，可以理解为魔兽世界里盗贼的终结技。所以设定流派的第一步：

1、设定终结技

以暴击为例子看下关联。

终结技一般是对暴击效果的放大，如被动自带巨额爆伤提升，或是关联了极大收益的特性效果。如：

• 暴击概率再次攻击，这是与动作层联动。可以作为终结技但需要终结者本身具备不错的输出能力
• 暴击概率提升攻击力，与属性联动。提升能力一般作为蓄力而不是终结
• 暴击概率附加行动状态，与debuff联动。debuff为最后结果时，一般还不如直接上debuff的技能实用

一个技能中可以包含多重联动，所以只要设计者愿意，可以有无限种关联形式。但作为终结技时，默认伤害最大化作为终极流派标准。//正常情况下，暴击伤害被动提升的技能会作为最稳定的终结技。

当然只要设计者愿意，也可以把控制流作为终结去设计，用来防守非常恶心对手。

也就是说，终结技决定了流派核心。于是衍生出了各种诸如一波暴击流华山派，寒冰控制流嵩山派，自虐反击流青城派等剑派。

而围绕着终结技，为终结者提供属性支援的部分则是蓄力技了。

2、设定蓄力支援

在魔灵召唤中，为了避免4个队员集中给1个终结者过度叠加状态，一般属性类buff被设定为不可叠加以免失控。所以魔灵的流派设计基础思路是：

【终结者+队伍光环者+上状态者+上目标负面状态者+其他治疗攻速保护等】

又有人说魔灵召唤可以给一个目标上多个中毒状态啊。其实我们看中毒的状态设计：

中毒（每回合开始时进行无动作的攻击，扣除a类伤害X，持续Y回合，不可叠加，同名最多n个同时生效）

可以看出中毒实际上是一个在回合开始时自动攻击的行动状态，而不是赋予属性的状态，因此叠加并不会崩坏伤害公式。

3、流派赋值范围

安排好基础流派的最佳承担者之后，这个流派的最高赋值参考就出来了。完美流派的天花板数值，用于卡牌的赋值分配。

然后根据这个基础流派做2~3个变种流派用于混淆视听。如：

【终结者+队伍光环者+上状态者+上目标负面状态者+其他】中，每个位置都提供可替换的卡牌，赋值低于模板卡牌但可以附加更多特性。

或者调整基础位置：

【终结者+次终结者+队伍光环者+上状态者+上次要状态者+其他】

【终结者+队伍光环者+非流派增益状态+其他】

……

从基础流派中蓄力角色的穿插变换，到终结者的变化调整，始终坚持最少3个套路变化，才能使流派的策略构建具备灵活性。

这个部分有很多设计上的奇淫巧技，后面有时间再总结一下。

然后有人说了，你这连克制都没设计，怎么体现策略性啊。

于是又多了一段充数的废话出来了。

五、克制设计

先问一个问题，策略框架里克制是否必需机制？

很多人觉得需要，这样才更能体现智力游戏的乐趣。你看魔灵召唤也是有属性克制的嘛。

我们还是从底层伤害计算来看看魔灵召唤的属性克制设计：

魔灵召唤中，属性克制影响命中、效果命中、暴击概率、最终伤害（10%）。

你会发现这些属性都是可以作为独立模块去计算的，也就是说，其实属性克制可以看作上层策略层，可以独立添加或去除。

当然魔灵召唤是一开始就以属性克制为基础设定去开发内容的，所以五系魔灵在设计之初就定好了不同的属性偏向，以及后续开发自动战斗时，也将属性克制纳入了AI机制。

实际上如果要设计属性克制，可以这样进行。

1. 先设计好多个基础流派的卡牌，即所有卡牌
2. 把所有卡牌复制5份
3. 分别赋予5系属性
4. 设计整体作为属性克制的独立算式
5. 根据属性偏向对流派进行调整，如魔灵会调整卡牌技能甚至（胎生）品阶

这不纯粹在扩卡池么？对啊。（就这么无耻地承认了）

只是很尴尬的点在于，如果属性克制的受益过高，那么流派构建的收益就相对降低。反之会被忽视（比如风丑的辉煌）。

总之目前魔灵属性克制对伤害的影响是10%，更多的影响体现在概率性的数值和自动战斗时的目标选取上。

仅仅是这样的低收益，魔灵召唤也付出了极高的数值平衡维护成本。

所以阴阳师选择了去除属性克制，走了鬼火路线去调教技能了，当然也跟它的世界观有关。

就到这，都不知所云了。

十、类DOTA游戏如何设计多样化的技能系统？

这个嘛，我觉得我还是能答的，因为我曾经设计了DOTA2的一款RPG，虽然未完（逃

当然没翻译完，因为弃坑了233

以上是数据驱动类型的技能，还有脚本驱动类型的技能。

===========================================================

上面很多答主讲的其实都是数据驱动类型的技能，也就是data-driven，简单的来说，就是把通用的技能肢解成若干方面。

一个数据驱动的技能是一串键值的集合。键值是单一的、基于树的结构，用于储存包含了键/值对的嵌套部分。

一个典型的数据驱动类型技能框架是这样定义的，当然指的是dota2：

"datadriven_skeleton"{ // General // ---------------------------------------------------------------------------------------- "BaseClass" "ability_datadriven" "AbilityBehavior" "DOTA_ABILITY_BEHAVIOR_UNIT_TARGET" "AbilityTextureName" "spellicon" "AbilityUnitTargetTeam" "DOTA_UNIT_TARGET_TEAM_ENEMY" "AbilityUnitTargetType" "DOTA_UNIT_TARGET_HERO | DOTA_UNIT_TARGET_BASIC" "AbilityUnitTargetFlags" "DOTA_UNIT_TARGET_FLAG_MAGIC_IMMUNE_ENEMIES" "AbilityUnitDamageType" "DAMAGE_TYPE_MAGICAL" "AbilityType" "DOTA_ABILITY_TYPE_BASIC" "MaxLevel" "7" "RequiredLevel" "-4" "LevelsBetweenUpgrades" "7" "AbilityCastPoint" "0.0" "AbilityCastAnimation" "ACT_DOTA_ATTACK" "AnimationPlaybackRate" "1" "AnimationIgnoresModelScale" "1" // Stats //---------------------------------------------------------------------------------------- "AbilityDamage" "0 0 0 0" "AbilityManaCost" "0 0 0 0" "AbilityCooldown" "0.0 0.0 0.0 0.0" "AbilityCastRange" "0" "AbilityCastRangeBuffer" "250" "AbilityChannelTime" "0.0 0.0 0.0 0.0" "AbilityChannelledManaCostPerSecond" "30 35 40 45" "AbilityDuration" "0.0 0.0 0.0 0.0" "AoERadius" "250" // ...}

可以看到，一个技能被拆分成了很多很多各自独立，相辅相成的部分，目标选取限定、图标资源、技能类型、最高等级、升级等级要求、升级等级间隔要求、施法点、施法动画、目标阵营限定、目标类型限定、粒子效果、伤害、CD、耗蓝、施法时间、施法前摇、施法后摇、持续时间、AOE范围……

这些部分又各自有各自的关键字，将他们依据自己的创意组合在一起，可以快速地组合出非常非常多的技能，就是数据驱动类型技能存在的最大意义。

第二个意义在于，数据驱动类型技能是一个框架，它的存在是最通用的一个模板。就拿非常有特点的，冰魂的大招来说。冰魂大招的具体实现压根不是在数据驱动类型所能实现的，但是如果你解包了文件之后你会看到，冰魂大招确确实实存在于数据驱动类型技能表里头。为什么？就是因为数据驱动类型给了你一个框架，你先把数据给我填上去，再去谈脚本实现。

脚本驱动的技能确实给力，它相对于前者更底层，控制更多的东西，甚至可以一定意义上改变游戏的规则（在冰魂大招里体现为禁止生命回复），但是如果所有的东西都拿脚本来写，整个代码会变得混乱不堪，充斥着这样那样的变量和语句，无法提炼出技能的核心数据。

因此，数据驱动往往和脚本驱动统一在一起，有纯数据驱动的技能，也有数据驱动里包含脚本驱动的技能，还有少数纯脚本驱动的技能，不过前两者占大多数。数据驱动提供技能最基本的类型和框架设定，同时为脚本提供了接口，怎么实现，由脚本提供者去考虑。

==============================================

因此，你说一个普适的技能系统是不存在的，即时战斗的和回合制的能一样吗？宝石迷宫和暗黑破坏神能一样吗？这跟2D\2.5D\3D没关系，画面跟系统不是一回事（大多数情况下，你说fez我也没辙）

你先要选定一个游戏类型，仔细思考其职业、系统上会涉及到的东西，然后用一个尽可能大而全的框架把你的构思框住，细细肢解，最后非常特殊的再单独使用脚本实现。因此不要急着去做这个通用的框架，把能想到的都想了，把框不住的东西问了程序看能不能单独实现，再去肢解。肢解也不要一次就弄完，反复想想，能不能分得更细，更科学，更有结构性，你在架构上多花一个小时，或许后期实现能省十个小时。