GSD 面向用户的 UI 品牌规范完全指南阶段横幅、检查点框与终端输出的视觉一致性【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-doneGSDGet Shit Done是一个面向 Claude Code 等 AI 编程工具的元提示、上下文工程与规格驱动开发系统其工作流会输出大量面向用户的阶段性信息。本文系统拆解仓库中用于统一这些输出的视觉模式规范 docs/zh-CN/references/ui-brand.md覆盖阶段横幅、检查点框、状态符号、进度显示、生成指示器、下一步区块、错误框与表格的标准写法并给出禁止出现的反模式帮助你理解并复用这套“AI 输出即用户界面”的品牌约定。读完本文你将能精确复刻 GSD 各类工作流的标准输出形态并能据此编写或审查新的编排工作流。规范是什么为什么 AI 输出也需要“品牌”GSD 的核心思路是复杂性在系统内部不在你的工作流里。用户看到的是整齐划一、便于跟踪的命令输出而背后是由编排器生成研究员、规划者、执行者等多个子代理来完成复杂工作多代理编排的机制可参考 docs/ARCHITECTURE.md。正因为存在大量由 AI 自主生成的阶段性输出、等待用户确认的检查点、需要用户复制的下一步命令输出形态的稳定与否直接决定用户能否顺畅理解“系统当前在哪里、需要我做什么”。因此本仓库维护了一份统一的 UI 品牌规范中文版即 docs/zh-CN/references/ui-brand.md其英文原版位于 get-shit-done/references/ui-brand.md。规范在仓库中的角色正如文件开头所写“编排器通过 引用此文件”。在真实工作流中确实如此——get-shit-done/workflows/plan-phase.md、get-shit-done/workflows/ui-phase.md、get-shit-done/workflows/secure-phase.md、get-shit-done/workflows/validate-phase.md、get-shit-done/workflows/ui-review.md 等都通过引用方式加载该参考文件get-shit-done/references/gate-prompts.md 也在文档中明确指向它规定检查点框必须使用 62 字符内宽的双线边框。阶段横幅用于主要工作流过渡当工作流从一个阶段过渡到另一个阶段如从“研究”进入“定义需求”或完成一个里程碑时使用横幅在终端中醒目地宣告阶段切换━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GSD ► {阶段名称} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━阶段名称必须大写可选枚举值如下QUESTIONING提问RESEARCHING研究DEFINING REQUIREMENTS定义需求CREATING ROADMAP创建路线图PLANNING PHASE {N}规划阶段 {N}EXECUTING WAVE {N}执行波次 {N}VERIFYING验证PHASE {N} COMPLETE ✓阶段 {N} 完成MILESTONE COMPLETE 里程碑完成从源码工作流可以观察到这个模式的真实落地形态例如 get-shit-done/workflows/autonomous.md 中使用GSD ► AUTONOMOUS ▸ COMPLETE 、GSD ► AUTONOMOUS ▸ Phase {N}/{T}: {Name} [████░░░░] {P}%、GSD ► AUTONOMOUS ▸ PHASE ${ONLY_PHASE} COMPLETE ✓等横幅表达自主执行中的各类状态get-shit-done/workflows/add-tests.md 则以GSD ► ADD TESTS — Phase ${phase_number}: ${phase_name}的形式在工作流内组合横幅。值得注意的是实际工作流在GSD ►之后会按需追加更具体的子阶段名如AUTONOMOUS ▸ ...这属于对“阶段名称大写 GSD ►前缀”规则的合理扩展。横幅的分隔线统一使用全角制表符━连成一整条行首GSD ►前缀是强制性标识缺失即为反模式见后文。检查点框需要用户操作时的标准呈现计划的执行高度自主但“验证”“决策”“操作”这三类场景必须停下来等用户。规范规定检查点框宽度固定为 62 字符这也是 get-shit-done/references/gate-prompts.md 中“checkpoint boxes use double-line border drawing with 62-character inner width”所强调的实现细节╔══════════════════════════════════════════════════════════════╗ ║ CHECKPOINT: {类型} ║ ╚══════════════════════════════════════════════════════════════╝ {内容} ────────────────────────────────────────────────────────────── → {操作提示} ──────────────────────────────────────────────────────────────三种检查点类型与对应的用户操作提示CHECKPOINT: 需要验证→→ 输入 approved 或描述问题CHECKPOINT: 需要决策→→ 选择: option-a / option-bCHECKPOINT: 需要操作→→ 完成后输入 done检查点的语义背景可参阅姊妹篇规范 docs/zh-CN/references/checkpoints.md它按“human-verify约 90%/ decision约 9%/ human-action约 1%多用于认证门控”划分场景并强调黄金法则——凡是 Claude 能自动化的就绝不让用户手动执行检查点只留给真正需要人工判断的时刻。工作流中的真实样例见 get-shit-done/workflows/sketch.md 的║ CHECKPOINT: Verification Required、get-shit-done/workflows/spike.md 中的CHECKPOINT: Decision Required与CHECKPOINT: Verification Required以及 get-shit-done/workflows/sketch-wrap-up.md 中的CHECKPOINT: Decision Required。检查点框的“操作提示行”还会与 docs/zh-CN/references/checkpoints.md 中给出的完整示例含进度、任务名、如何验证步骤组合使用确保用户拿到的是可执行、可判断的信息而不是一个空泛的确认请求。此外仓库还沉淀了可供编排工作流复用的“门禁提示词模式”gate prompt patterns见 get-shit-done/references/gate-prompts.md。它规定了检查点选择器的通用约束header至多 12 字符、单选multiSelect恒为false、每屏至多 4 个选项超出则拆两步、始终兜底处理用户自由输入。常用模式包括 approve-revise-abort批准 / 请求变更 / 中止、yes-no、stale-continue、multi-option-escalation升级处理等。状态符号一套无歧义的“交通灯”在表格、列表、进度报告等任何出现状态的地方统一使用以下符号避免混用语义✓ 完成 / 通过 / 已验证 ✗ 失败 / 缺失 / 阻塞 ◆ 进行中 ○ 待处理 ⚡ 自动批准 ⚠ 警告 里程碑完成仅在横幅中两个容易被忽略的约束✓可同时表达“通过/已验证”只能在里程碑横幅中使用不能散落到正文各处当装饰。这与下文的“随机 emoji 反模式”呼应——状态符号本身即语义无需额外表情烘托。进度显示三个粒度级别的“标尺”规范按信息粒度划分了三种进度表达方式实际使用时按当前汇报对象选择其一阶段/里程碑级别——用填充方块表达百分比进度: ████████░░ 80%任务级别——用完成计数表达任务: 2/4 完成计划级别计划: 3/5 完成这种“条形图 百分比”以及“分子/分母计数”的组合在自主执行工作流中同样被广泛采用例如 get-shit-done/workflows/autonomous.md 的[████░░░░] {P}%即横幅内嵌进度条的实例。需要说明的是上述中文文案“进度/任务/计划”是对应中文版文档中的措辞在英文版 get-shit-done/references/ui-brand.md 中则为Progress: ...、Tasks: ...、Plans: ...。若你基于英文工作流二次开发请保持整份工作流语言一致。生成指示器让“并行子代理”过程可见GSD 的编排器在幕后生成研究员等子代理。为了让用户感知到这一过程而非面对一片沉默规范定义了生成指示器的动画式输出◆ 正在生成研究员... ◆ 并行生成 4 个研究员... → 技术栈研究 → 功能研究 → 架构研究 → 陷阱研究 ✓ 研究员完成: STACK.md 已写入细看这套写法会发现它内嵌了三个语义◆表示“正在发生”、→罗列并行分支、✓表示“某个子代理已经收尾并落地产物如 STACK.md”。它与你看到的状态符号表一一对应读起来就像系统在“现场直播”编排过程。这正好对应 README 所描述的“编排器从不做重活——它生成代理、等待、整合结果”的架构而规范的职责是把这层内部机制转译为用户可读的进度叙事。下一步区块每个主要完成点之后的“出口”规范强调始终在主要完成后给出“下一步”区块让用户明确知道刚刚结束的阶段通向哪里。标准形态如下─────────────────────────────────────────────────────────────── ## ▶ 下一步 **{标识符}: {名称}** — {单行描述} {可复制粘贴的命令} sub/clear 优先 → 全新上下文窗口/sub ─────────────────────────────────────────────────────────────── **也可选** - (根据工作流选填可选命令例如 /gsd-progress --next) ───────────────────────────────────────────────────────────────区块内的格式要点这些要点在配套文档 docs/zh-CN/references/continuation-format.md 中展开为完整“续接格式”规范始终展示“它是什么”——名称 单行描述绝不仅仅甩一个命令路径标识符通常带阶段/计划编号如02-03。从源文件拉取上下文——阶段信息来自ROADMAP.md计划信息来自对应PLAN.md的objective。命令用内联代码包裹反引号保证可复制粘贴、在支持的终端中渲染为可点击命令不要用围栏代码块嵌套展示命令以免产生嵌套歧义。sub内必须解释/clear的意义——GSD 每个计划/阶段都应在全新上下文窗口中执行以对抗上下文衰减因此要写“/clear优先 → 全新上下文窗口”而不是干巴巴一句“先运行 /clear”。备选命令区用“也可选”措辞而非“其他选项”。区块上下以---分隔线框出视觉上独立成块。Docs/zh-CN/references/continuation-format.md 还给出了“执行下一个计划”“阶段最后一个计划”“规划阶段”“阶段完成准备下一步”“多个同等选项”“里程碑完成”等场景的变体写法并反向列举了反模式仅命令无上下文、缺少/clear说明、用围栏代码块等可作为编写下一步区块时的权威参考。错误框失败时的“边界清晰 可修复”当流程出错时用错误框把错误描述与解决方案隔离呈现╔══════════════════════════════════════════════════════════════╗ ║ ERROR ║ ╚══════════════════════════════════════════════════════════════╝ {错误描述} **修复方法:** {解决步骤}错误框与检查点框共用 62 字符宽的双线边框保持家族一致性。其设计意图是先让用户知道“发生了什么”再明确告诉用户“怎么修”——描述与修复步骤分列两个字段避免把失败原因埋在长篇文字中。表格统一的状态汇总形态多阶段/多计划的状态汇总一律使用 Markdown 表格表格内的状态直接复用状态符号与进度表达| 阶段 | 状态 | 计划 | 进度 | |------|------|------|------| | 1 | ✓ | 3/3 | 100% | | 2 | ◆ | 1/4 | 25% | | 3 | ○ | 0/2 | 0% |从表格可以直观看出三种符号并列时的信息密度✓是已完成、◆是进行中、○是待处理配合“计划 3/3”“进度 100%”等计数读者扫一眼即可判断整个路线图的健康状况。反模式清单校验任何 AI 输出的一页清单规范在末尾给出了明确的负面清单。这些是编排器在审查输出时应当拦截、或你在自定义工作流时应主动避免的写法变化的框/横幅宽度破坏视觉节奏与可读性混合横幅样式、---、***混用导致风格不统一横幅中缺少GSD ►前缀丢掉品牌标识随机 emoji如、✨、——状态符号已承担语义额外表情属于噪音完成后缺少下一步区块用户会迷失方向不知道接下来做什么结合前面各节这套反模式清单本质上是在维护三个稳定性目标结构稳定固定字符与边框样式、语义稳定符号含义唯一、横幅前缀统一、流程稳定完成之后必有出口。这与仓库中大量以“确保输出一致、可解析、可路由”为目的的工程约束参见 docs/CONTEXT.md是同构的。如何在自己的工作流中应用这套规范规范文件本身是一份“提示词参考文档”其主要用法有二引用加载在自定义工作流或代理提示词的开头以引用规范文件。仓库内做法可参考 get-shit-done/workflows/plan-phase.md 的~/.claude/get-shit-done/references/ui-brand.md安装后为本地绝对路径或 get-shit-done/workflows/profile-user.md 中把 ui-brand 与 display patterns 一并加载的写法。按规范手写输出即使不引用文件也应严格复刻本规范给出的字符模板——横幅用━分隔线与GSD ► {大写阶段名}前缀检查点框保持 62 字符双线边框下一步区块遵循“标识符 描述 内联命令 /clear说明 也可选”的结构。判断输出是否合规的快速自检顺序横幅有没有GSD ►且大写边框/横幅宽度是否恒定检查点是否给出明确的用户操作提示完成处是否缺少下一步区块是否混入了未定义的 emoji这套自检不依赖视觉审美任何 AI 编排器都可以机械地执行——这正是一份“面向 AI 消费”的品牌规范与人类设计稿的本质差异所在。结语UI 品牌规范是 GSD “把复杂性藏进系统内部”理念的直接产物用户可以不懂编排器、研究员、波次执行的内部实现但只要输出遵循阶段横幅、检查点框、状态符号、进度显示、下一步区块、错误框与表格这套统一语言用户就永远能回答三个问题——系统做到哪一步了、它在等我做什么、接下来我该复制哪条命令。围绕 docs/zh-CN/references/ui-brand.md 这份核心文档配合 docs/zh-CN/references/continuation-format.md、docs/zh-CN/references/checkpoints.md 与 get-shit-done/references/gate-prompts.md 等周边规范再加上仓库内各工作流autonomous、sketch、spike 等的落地样例你可以完整复刻并校验这套面向用户的 AI 输出体验。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考