Impeccable 的 bolder 指令：在既有设计系统内做「区块级调强」的克制放大方法论

在设计语言 Impeccable 的指令体系中，bolder 是一条常常被误读的「Refine（精修）」命令：用户说「这块太平了、再大胆一点」时，本能反应往往是叠加更多特效，而这条命令的核心恰恰是拒绝这种本能。本文以 bolder 参考文档 为主体，结合 SKILL.md 的命令路由、new-work.md 的职责边界与 polish.md 的收尾交接，讲解 bolder 的适用边界、诊断方法、放大四原则与骨架测试，帮助你在不改动系统其他任何部分的前提下，把一个平淡区块提升到与既有设计世界同等的表现力。

一、bolder 在 Impeccable 命令体系中的定位

Impeccable 把工作流拆成 Build、Evaluate、Refine、Enhance、Fix、Iterate 等类别。在 SKILL.md 的 Commands 表 中，bolder 与 polish、quieter、distill、harden、onboard 并列，归类为 Refine（精修），一行描述即可点明它的身份：

bolder [target] — Amplify safe or bland designs（放大安全或平庸的设计），参考文档 reference/bolder.md。

命令的触发与路由遵循 skill 的统一规则：用户显式或明显隐含了该子命令时，加载对应参考文档并执行；无参数调用 /impeccable 时由 routing.md 给出上下文感知建议。机器可读的命令元数据位于 command-metadata.json，其中对 bolder 的触发语义描述得更细，便于 Agent 与意图识别层判断何时该选用它：

"Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability. Use when the user says the design looks bland, generic, too safe, lacks personality, or wants more visual impact and character."

也就是说，「看起来平淡/千篇一律/太安全/缺个性/想要更有视觉冲击」这类需求，才是 bolder 的正确入口。注意它与 quieter（把过于刺激的设计降噪，见 reference/quieter.md）构成互补的两个方向，同属 Refine 类精修而非重建。

二、先划清边界：bolder 指令 ≠ 方向决策中的「bolder 转向」

参考文档开篇用一整段强调了一条最容易踩的歧义，务必先分清语境：

一个方向决策回合（direction round）正在桌上、尚未敲定时，用户说出 "bolder"，指的是 Bolder hand register steer —— 即方向骰局中的「更敢」重掷寄存器，去接触一套全新的异域形态（foreign forms），属于 new-work.md 的新世界决策流程，而不是本文这条命令。

在 new-work.md 中可以读到这条「bolder register」的完整定义：方向未定时允许 --register bolder 重掷，含义是 "foreign forms only, at full commitment"（只掷异域形态、全情投入）。而本指令则完全不同：

本指令精修的是一个世界已经上线的表面（a surface whose world already shipped）。"Bolder" 是一个放大请求，而且几乎总是作用在已经存在的某个对象上。周围页面、它的系统、它的约定，都是既定的前提。

一句话总结：方向未定 → 说 bolder 意味着换世界；方向已定、表面已上线 → 说 bolder 意味着把系统自己的语言拧到满格。 前者是 new-work 的职权，后者才落到本文档描述的执行方法上。任何在新建/换肤流程中把两者混用的做法都会破坏决策纪律。

三、范围至高无上：只许动被点名的目标

文档把放大请求的首要纪律命名为 "Scope is sovereign"（范围至上），并给了字面级的要求：

"Everything else stays"（其它一切保持不变）是一条字面指令。只触碰被点名的目标；不要去重排它的邻居；不要把页面迁移到一个新理念；不要加入当前表面尚未拥有的颜色、字体、圆角、阴影或系统原语（primitives）。

执行者需要同时守住两件事：

• 不动体系外的东西：如果现有系统真的无法表达这个方向，禁止自作主张去扩展系统，而是要向用户提问。文档在这里留了一个按宿主环境替换的占位符 {{ask_instruction}}（详见文末「仓库中的多重形态」一节），不同分发副本会将其替换成「通过结构化提问工具询问」或「直接向用户澄清你无法推断的内容」，但意图一致：说出你需要的精确新增项、以及它要承担的职责，由用户裁决，而非自己加戏。
• 不做范围外的创意竞赛：new-work.md 对「既有表面内的区块扩展」同样有定论——"A section, component, feature, or state inside an established surface inherits that surface. Never turn a local addition into a new identity exercise."（既有表面内的区块继承该表面；绝不把一次局部新增变成一场新身份练习）。这与 bolder 的范围纪律互为印证：局部区块的放大，永远在它所属的世界里完成。

四、先诊断：一个区块为什么会显得「平」

在动手放大之前，参考文档要求先回答「为什么它读起来是平的」。它的诊断起点不是找缺点，而是看邻居：

一个区块通常显得平淡，恰恰是因为其平淡原因已被周围的其他部分解决了。去观察页面其余部分做了而该区块没做的：满强度的展示字体、承载意义的排版结构装置（structural devices）、标志性母题（signature motif）、密度与节奏。

由此得出关键判断：平，通常意味着这个区块悄悄退出了系统自身最强的那几手动作。而最可靠的放大路径，是把目标拉升到其邻居已经达到的表现层级，并且用的是系统自己的词汇表，而非发明一套新词汇。

这套诊断把「求索更多效果」定义为与大写意义上的「敢」相反的反应，参考文档明确要求第一步就拒绝它：

那个反射式的答案——伸手去抓更多特效——恰好是 bold 的反面；先把它拒掉。

五、放大的四条原则

文档给出了四条互为约束的执行原则，它们共同构成「调强」而非「加料」的操作定义：

1. 放大系统已拥有的东西（Amplify what the system already owns） 复用它的母题与字阶（type scale），并以满强度呈现——是为这个区块把旋钮拧大，而不是为它发明新东西。检验标准很尖锐：更 bold 的版本应当看起来更像同一个品牌，而不是更不像。

2. 内容必须保持真实（Keep content true） 既有文案声明属于范围之内：除非用户提供了替换内容，否则必须原样保留。如果这个方向的成立依赖真实证据而证据缺席，就去向用户要，而不是编造。

3. 先下注，再让周围安静（Commit, then clarify） 半吊子动作读起来只是噪音。把那一个决定性动作做完整，然后压静周围的一切，让这个动作清晰可读。文档给出一条反直觉的检验：如果每个元素都变响了，这个区块只会变得更平。 这解释了为什么「到处加一点」恰恰是平淡的制造机。

4. 给它自己的节奏（Give it its own rhythm） 目标区块应该在滚动中读作一个峰值——与周围相比在密度或节奏上产生一次换挡，而不是「同质内容的更多份」。平铺直叙的同构放大无法制造高潮感。

六、骨架测试：剥离文案后它还立得住吗

为了对抗「靠加大字号假装大胆」，参考文档要求在执行前做一个可操作的检查：

把你规划的区块中的文案剥离掉，只研究裸露的结构。仅凭层级与系统自身的装置，这个骨架是否依然能说出这个区块是什么、为什么它重要？如果只有把文字放回去它才成立，那么 boldness 存在于文本字号里，而不在设计里。

骨架测试同时定义了占位符的正确语义：一个给图片或产物的占位符，命名的是一个 job（职责）、一个锚点（anchor）和一件证据（evidence）——也就是说，它要说清楚「这里需要一个能证明该主张的东西」，而不是「在这里放一张装饰性照片」。占位符所指代的内容，要用该主题实际拥有的素材去填满。

从结构上可以这样理解骨架测试：它把「设计的信心」从「文案的说服力」中独立出来度量。一个区块若抽掉文字就说不清自己，那它的 bold 只是文字大小的幻觉。

七、收尾检查与交接：完成即交棒给 polish

参考文档以一个「Before you finish（完成之前）」清单收束本轮工作，四项逐条核对：

• 被点名目标之外的一切都未被改动；
• 没有在未被要求的情况下出现新的颜色、字体或系统原语；
• 该区块原有的约定——包括任何驱动动作（action）的约定——仍然以同样的方式工作；
• 这个区块毋庸置疑地还是同一个品牌，只是对自己更有把握。

当目标能独立立住、且没有把页面拽散时，文档要求把工作交给下一棒：

当目标能自持而不拆散页面时，交给 impeccable polish 做最后一轮（hand off to {{command_prefix}}impeccable polish for the final pass）。

这里的 {{command_prefix}} 同样是宿主相关的模板占位符，在具体安装中会被替换为实际的命令前缀（如 /impeccable 或按 harness 约定的斜杠命令）。交接语义与 polish.md 的定义严格对齐：polish 是精修而非伪装的重设计，它保留既有视觉世界、内容与行为。反过来，如果 polish 过程中发现概念本身错了，polish 文档要求明说并建议 redesign 或 bolder，而不是把替换方案偷偷塞进精修里——这两条命令因此构成一个闭合的循环：bolder 放大、polish 收口、概念错则回到 bolder 或 redesign。

八、bolder 参考文档在仓库中的多重形态

bolder 的方法论以近内容、多副本的形式沉淀在仓库里，随不同 AI harness 的分发路径展开：

• 本任务关联的主副本：.trae/skills/impeccable/reference/bolder.md（Trae 安装），其第 9 行提问占位符已被替换为直白文字「Ask the user directly to clarify what you cannot infer.」；
• 镜像副本一：skill/reference/bolder.md（skill 目录，仍保留 {{ask_instruction}}、{{command_prefix}} 未替换字面量）；
• 镜像副本二：plugin/skills/impeccable/reference/bolder.md（plugin 分发）。

这类未展开的 {{ask_instruction}}、{{command_prefix}} 占位符是文档对外部环境的显式契约点：正式运行前由各 harness 的执行框架注入「结构化提问指令」与「斜杠命令前缀」。读懂这套模板机制有助于分辨哪些文字是方法论本体、哪些是待注入的宿主接口，避免在移植到新环境时把占位符误当成最终措辞。

与此对应，命令的「一句话身份」同样分散存储并保持同源：命令行为定义在 SKILL.md，意图匹配语义在 scripts/command-metadata.json，执行方法论在 reference/bolder.md，三者各司其职——路由层负责「什么时候用」，参考层负责「具体怎么做」。

小结

bolder 是关于克制的放大术：它要求你只动一个目标、只放大系统已有的词汇、只下完整的一注、并让骨架而非文案承担说服力。它既不是到处加特效的冲动反应，也不是方向未定时的换世界动作，而是把一个已经上线世界里的某个平淡区块，拉升到它邻居已经达到的表现层级。执行结束时，区块读起来应当是同一个品牌、只是更有底气——随后把收尾交给 polish，让精修在既有系统里完成最后一公里。