指南 · 收尾
怎样用配饰为成衣收尾
配饰最后再加,而且只在成衣已经达标之后再加。
一句话回答
配饰是收尾工序。它加在一件已经满足需求所写上下限的成衣上,而不是用来抢救一件不达标的成衣。顺序之所以重要,是因为同一次尝试里既改成衣又改配饰,得到的结果谁都无法归因。
流程是:先纸样与面料,其次核验上下限,配饰放在最后,而且一次只加一件。
配饰在一次组装里承担什么角色
玩家把配饰描述为附加在完成后的服装上的独立物件,而不是纸样的一部分。官方上线说明把新配饰与新面料并列提到,这确认了配饰作为一个类别存在,也确认了 2026 年 9 月 21 日发售之后又新增了更多。2026 年 10 月 14 日的 Build 443 公告是最清楚的例子:它加入了 Silver Clasp、Silver Narcissus Chain、Silver Twin Souls Chain、Black Dagger Beaded Trim 与 Widow's Lace Trim。这些说明没有描述任何一款具体配饰的作用。物品名在这里保留英文原文:官方中文译名尚未核实,等拿到之后再替换,而不是自己造一个译名。
除此之外,已核查的来源对算式保持沉默。不靠编造也能说清的是收尾工序在普通服装缝制里的用途:和真实缝制一样,一件收尾之物用来完成整体观感,它是在主衣身合身之后才被挑选的,而不是之前。把配饰当作组装里的最后一个决定,能让这个对照保持完整,也让结果保持可读。
Build 443 之后,放置操作被重做了
如果你此前被饰边的放置折磨过,那么 10 月 14 日的这次补丁正好针对这一点:饰边与配饰的放置方式被整体重做,包括快速放置、复制饰边的按钮、拖拽旋转人台、允许饰边高度为负,以及袖口等复杂几何体上饰边断裂的修复。更完整的一份记录见更新日志与配饰参考。官方同时说明相机控制仍不满意,未来可能做更彻底的改动,也就是说这一版的手感是当前最好的一版,但不一定是最终一版。
这些是操作层面的改动,不改变本页的顺序规则:成衣先达标,配饰最后加,一次只加一件。
顺序规则:先通过上下限,再做装饰
下面的顺序适用于每一次组装,无论需求里有没有提到配饰。它被写成这样,是为了让每一步都只留下一个可归因的改动。
- 读需求,抄下它写明的每一条限制,包括预算以及任何上限。
- 只用纸样与面料把成衣做出来并核验。收尾部分暂时一分钱都别花。
- 记录成品的数值。这次读数是之后每一次配饰测试的参照点。
- 挑一件配饰来测,而且只挑一件。一次尝试里加两件,之后无法把它们分开。
- 把它附加上,再在同一个位置、按同一个顺序读一遍同样的数值。
- 比较两次读数,写下什么移动了、朝哪个方向移动、在自己的屏幕上移动了多少。
- 在花下去之前先查剩余预算。如果这件配饰并不改变需求点名的任何数值,那么这笔花费是装饰,而不是进展。
配饰如何把数值推过上限
需求可以同时带有上限与下限,而一个要求克制的委托会拒绝一件超出的成衣。因此,一件在低数值成衣上无害的配饰,完全可能成为让一件已经贴近上限的成衣交付失败的东西。在附加任何东西之前,重读上下限,并问一句:这件配饰最可能把每一个被点名的数值推向哪个方向——向上、向下,还是完全不动。如果你的屏幕上看不出答案,这件配饰就还没有到可以安全加入的时候。
这正是收尾工序与主体组装不同的地方。装饰是可选的,所以一件没有经过测量的配饰,在换来物件的同时也换来了风险。分数如何回应一次组装,见质量指南;组装那一侧则写在缝纫流程里。
成本效益问题清单
四个问题决定一件配饰是否值它的成本。这些问题问的是你自己的屏幕与你自己的笔记,因为本站不发布任何配饰成本,也不会编造一个。
| 要问的问题 | 答案从哪里来 | 为什么重要 |
|---|---|---|
| 它会改变需求点名的某个数值吗? | 从自己的屏幕上读出的、配饰前后的成衣数值 | 一件移动了未被点名数值的配饰,对通过需求没有帮助 |
| 它把这个数值推向上下限之内,而不是越过去吗? | 第一次读需求时抄下的需求自身上下限 | 在某个数值上有利的方向,可能毁掉另一个本已贴近上限的数值 |
| 它比替代方案更贵吗? | 该物件显示的价格,与它所替代的面料成本并列比较 | 花在做微小移动上的收尾开销,可能买不到需求需要的任何东西 |
| 这个移动可以复现吗? | 第二次只做同一处改动、其它一切相同的尝试 | 一次移动可能是噪声,两次相同的移动才是证据 |
收尾检查清单
在成品离开你手上之前,把这份清单过一遍。每一行都是一次检查而不是一个数字,而回答不了的检查项就留着空着。
- 需求点名的每一条限制,都是从成品上读出来的,而不是回忆出来的。
- 每一条限制都与需求按要紧的方向比对过:下限达标,上限未被越过。
- 配饰的数量与你自己的记录相符,没有哪一件是误加的。
- 剩余预算已经与实际发生的面料和收尾花费核对过。
- 数值连同日期与那次组装一起写下来了,日后的改动才不会被误认成错误。
- 游戏没有显示的数值一律留空,而不是用猜测填上。
交付前如何检查成品
交付是一次比对,而不是一次记忆测验。把需求点名的每一个数值从成品上读出来,再把两套数字都填进委托检查器,它会报告成衣在哪里不足、又在哪里超出。同一套流程在需求那一侧的说明见委托方法那一篇,而整个循环的参考页是委托索引。
把配饰作为这一轮检查的一部分,而不是单独检查,因为一个朝有利方向移动的数值,可能已经把另一个推过了上限。如果需求点名的某个数值在你的屏幕上不可见,就不要在它的位置上写任何东西。把未知数值记录成一个数字,比坦承这里有个空缺更糟。
哪些内容仍然是未知的
本站不发布任何关于配饰属性的内容。配饰参考被刻意留空:没有已核查的来源把某个配饰名称与它的成本或属性数值写在一起,所以这张表保留了名称、成本与属性三列,却没有数据行。 Steam 商店页与官方新闻页只在功能层面描述游戏,并没有提供这些组合。
这里仍然未知:配饰会改变哪些属性、它是加到成衣上、替换其中一部分,还是以别的方式被计分、每件配饰要花多少、配饰花费是否计入委托预算、配饰之间能否叠加,以及这些在 2026 年 9 月 21 日发售之后有没有变化。
本页不会为其中任何一项做估算,也不会从一个相似物件那里抄一个数字来填格子。等某个来源写明了某个配饰数值,这一行就会带着来源与核查日期发布在配饰参考上。
常见问题
什么时候该给成衣加配饰?
在成衣已经满足需求点名的上下限之后,并且在那些数值被写下来之后。更早加一件,等于把两个变量混在一起,于是某个移动了的数值无法归因于其中任何一个。规则是:先成衣,再核验上下限,最后才是配饰。
一件配饰会让成衣通不过委托吗?
它可以让某个数值朝任一方向移动,而需求除了下限之外也可能设有上限。一件原本贴着上限通过的成衣,可能被事后加上的配饰推过上限。这就是为什么在附加任何东西之后都要重读上下限。
配饰是给成衣数值做加法,还是替换掉它们?
没有已核查的来源写明是哪一种,所以本页不声称任何一种行为。玩家把配饰描述为施加在完成后的服装上的独立物件,但结果背后的算式并未公开。检验方法是:用同一件成衣做两遍,两遍之间只差一件配饰,然后自己比较两次读数。
为什么这个站上的配饰参考是空的?
一行记录需要一个配饰名称,加上一个可被重新打开的来源所给出的成本或属性数值。2026 年 10 月 18 日的核查没有找到这样的组合:2026 年 10 月 14 日的 Build 443 公告点名了五款新配饰与饰边,却没有给出其中任何一款的成本或属性数值,所以这张表以空态发布,而不是用读者根本无法核实的合理数字填满。