开篇 30 秒
你在界面上看到一个不对劲的地方，错误提示轻飘飘的、删除按钮没有二次确认、AI说了句"我无法回答"，你却分不清它是拒绝了你，还是会话已经结束。
过去，这种直觉的去处是固定的：截图发群里，口头告诉前端改，改完就忘了。
这个模板只做一件事：把"我觉得不对"变成一条6个字段的结构化记录。它会被机器接收、判定、归档，最终长成一条能自动拦截同类问题的规则。
不需要会写代码。会截图，会描述困惑，就够了。
一、模板本体
{
"snapshot_id": "SNAP-2026-0001",
"scene": "",
"symptom": "",
"impact": "",
"expectation": "",
"evidence": ""
}
6个字段全部是冻结字段（v1.0.0），含义和顺序不要改，机器靠它们做格式校验和归档。
二、逐字段怎么填
| 字段 | 回答什么 | 合格线 | 典型不合格 |
|---|---|---|---|
snapshot_id |
它是谁 | 组织内唯一，建议 SNAP-年份-序号 |
留空、重复 |
scene |
在哪个场景 | 精确到"哪个场景"，不是"哪个页面" | "设置页的报错" |
symptom |
用户看到什么 | 引用界面真实原文，不转述 | "报错文案不对" |
impact |
用户承受了什么 | 写清"用户因此做了什么错误决策" | "体验不好" |
expectation |
本该表达什么 | 一句话，机器能据此判定 | "文案应该更严肃一点" |
evidence |
证据在哪 | 至少1个真实产品实例（截图 + 复现路径） | "截图见附件" |
四个字段各带一个自问题：
scene——问自己：换一个同事，只看这个字段，能十分钟内自己找到这个界面吗？
合格：「Web 端 · 账号设置 · 邮箱已绑定区域 · 解绑失败时的错误提示」symptom——问自己：如果这条快照半年后被人翻出来，原话还在吗？
合格：「提示文案为『出了点小问题，请稍后再试』，无错误码、无重试入口」impact——问自己：用户看到它之后，是"必须立即处理"，还是"等一等就好"？这两个世界不能平均。
合格：「用户以为只是暂时故障，没有保存已编辑的内容就关闭了页面，丢失40分钟工作」expectation——问自己：只用一句话，机器能不能据此判断"实际表达"和"预期表达"是不是一回事？
合格：「该状态为不可恢复错误（fatal），必须表达『已丢失，需要用户立即处理』，并提供已编辑内容的导出入口」
evidence 是三条准入硬要求之一：格式硬要求、语义硬要求、证据硬要求。退回不是拒绝，是翻译能力的第一道把关，退回时会说明缺什么，补齐再进来。
三、完整示例：BND-001边界动作诊断「拒绝 ≠ 终止」
《边界动作诊断》文中分析过的真实漂移模式，拿来做示范：
{
"snapshot_id": "SNAP-2026-0042",
"scene": "AI 对话助手 · 会话窗口 · 用户追问超出能力范围的问题时",
"symptom": "助手回复『我无法回答这个问题』，随后会话区域清空，输入框置灰",
"impact": "用户以为是账号或网络故障，反复刷新重登；实际只是本轮问答被拒，会话本身仍可继续",
"expectation": "该状态为软拒绝（soft boundary）：表达『此问题超出当前能力』，同时明确告知用户会话未结束、可继续提问或换个问法",
"evidence": "截图 2 张（回复瞬间 / 清空后）+ 复现路径：询问任意超出知识截止日期的实时数据问题"
}
这条快照后来长成了什么：拒绝、终止、升级被 blocked=true 一个布尔值压塌成了同一个槽位，修复路径是把 boundary.soft / hard / review 变成离散令牌写进契约，让机器在生成前拦截错误表达。
界面语义的边界，其实就是产品对用户权利的边界。
四、框架设计背景：
语义快照不是一张孤立的表单，而是 把设计规范写成代码格式（Schema-As-Code） 框架证据链的入口设计。要理解为什么6个字段一个不能少、为什么不能"写详细点就行"，需要先看到它在整条流水线中的位置。
4.1 三阶段全景
把设计规范写成代码格式（Schema-As-Code） 不是一套理论，是一条可执行的三阶段流水线（Semantic Pipeline）：
| 阶段 | 统一命名 | 回答的问题 | 核心资产 |
|---|---|---|---|
| 阶段一 | Guard 结构化诊断 | 我的产品有没有语义断层？ | 6字段快照 + 三层判定模型 + 模式库 |
| 阶段二 | Contract 语义契约化 | 我怎么用规则锁住设计意图？ | YAML契约 + 契约库 + 4种编译格式 |
| 阶段三 | Verify 验证闭环 | 我怎么证明规则真的有效？ | 四层推演拦截 + 消费追踪 |
4.2 快照横跨三个阶段
- Guard 阶段：快照是整条流水线唯一的人工入口。Contract与Verify全部由规则引擎驱动、确定性可审计；只有快照依赖人观察、人填写。这意味着整条链路的事实污染风险集中在入口，所以入口的格式纪律必须最严。
- Contract 阶段：快照是契约的"出生证明"。语义字典与契约只为有证据的语义服务，不为想象需求定义语义。没有快照背书的规则是拍脑袋，有快照背书的规则是证据长出来的。
- Verify 阶段：快照是验证的基线。拦截归因、消费追踪、A/B对比的所有读数，都要能回溯到具体快照编号，"这条规则为什么存在"的答案永远是"因为这类漂移真实发生过"。
4.3 回到开篇的问题
为什么"截图发群里"三个月后变成废纸？
因为语义漂移是路径依赖的，同一张红色截图，在系统崩溃场景里是致命错误，在限流提示里只是情绪过载，像素完全相同、语义完全相反。判断差异所需的全部信息都在像素之外（这个失效机制的系统论证见《语义断层地图的三栏断裂》）。
为什么必须结构化、不能"写详细点就行"？
因为自然语言只记结论不记前提，写得越详细越私人；证据的价值不在单条的丰富度，而在条与条之间能否放在同一维度上比较，可跨时间、跨产品、跨人比对的记录才是组织资产。
为什么是 6 个字段？
字段集合是从"三层判定各自需要消费什么"反推出来的最小完备集，少于6个，判定断粮；多于6个，采集执行率崩塌。6是下限也是上限。
一个判断请记住：语义字典管"规模化复用"，不管"创意萌芽"。
你探索新交互的时候不需要填任何东西，字典不介入。它只在一个时刻介入，当一个"不对劲"值得被组织记住的时候。
五、操作流程：一条快照从发现到长成规则
先看人机分工的总图。这条流程不是"你多做一件事"，而是"机器自动跑大部分，你只在判断点上出手"：
┌───────────────────────────────────────────────────────┐
│ 机器自动跑 │
│ ├─ 格式校验：缺字段、类型不符，提交即被拦 │
│ ├─ 提交安检：语义矛盾、描述过短，当场打回并说明原因 │
│ ├─ 三层判定：这是什么 → 缺了什么 → 哪里对不上 │
│ ├─ 置信度分级归档：≥0.85 自动归档 │
│ └─ 编译分发：长成契约后自动编译为四种产物 │
├───────────────────────────────────────────────────────┤
│ 人做决策（你在这里） │
│ ├─ 识别：这是语义问题还是视觉问题 │
│ ├─ 采集：把直觉填成 6 个字段 │
│ ├─ 复核：0.60–0.85 区间的快照由人复核 │
│ └─ 补录：走查发现规则盲区，回头补一条快照 │
└───────────────────────────────────────────────────────┘
Step 1：发现与区分，这是语义问题还是视觉问题
| 判断标准 | 去向 |
|---|---|
| 颜色不对、间距不对、字体不对 | 视觉问题 → 走视觉走查流程 |
| 用户看到界面后做出了错误的行动决策 | 语义问题 → 进入本流程 |
质量门槛：必须能说出"用户因此做错了什么"，说不出就还没到现场。
Step 2：采集，按6字段填快照
逐字段的填写标准与合格线，见本文第二章。卡壳的字段，就是你还停在"感觉"而不是"判断"的地方，把它写清楚再往下。
无工具时：用文档模板手动记录，发给具备翻译能力的协作者（组织初期通常就是设计系统负责人）归档。
Step 3：提交，机器先替你过安检
字段不全、语义矛盾、描述太短的快照当场打回并说明原因，不会混进规则库。被退回不等于被拒绝：退回时说明缺什么，补齐再进来。
Step 4：判定分流，置信度三档
| 置信度 | 机器动作 | 你需要做什么 |
|---|---|---|
| ≥ 0.85 | 自动归档到对应模式节点 | 收到"证据已采纳"反馈，不用做任何事 |
| 0.60–0.85 | 标记"待人工复核" | 复核结论对你可见 |
| < 0.60 | 不硬猜，触发新模式创建流程 | 可能收到补充证据的请求 |
Step 5：归档，快照成为模式卡片
你的快照成为模式卡片的一部分，引用记录对你可见。从这一刻起，你的判断不再是你个人的判断，是组织的证据。
Step 6：回流，Checklist回到你的走查现场
快照长成的契约经编译管线产出四种产物，其中 Checklist 会回到你手里：走查时按清单逐项核对，发现清单没覆盖的，回头补一条快照，盲区补快照，规则体系才转得起来。
关键认知：这不是新岗位、新职责，是你已经在做的走查和反馈的动作升级，以前是截图发群，现在是截图入库。翻译能力不需要专人专岗，它内化在每个角色的生长里；你的角色长出的新能力，是"把直觉写成证据"。能力拆解的完整地图详见《语义翻译的操作日常》。
六、你在设计意图的工程化交付里的位置：语义漂移的第一发现者
没有人比你更接近问题发生的那一刻。机器判定再准，也要有人先把"不对劲"指出来。
这个位置不属于某个编制，只属于一个动作。你的核心动作只有三个：采集 → 提交 → 等待反馈。
谁填：任何发现问题的人。设计师、产品经理、前端、设计系统负责人自己，都可以。
谁收：具备翻译能力的协作者（组织初期通常就是设计系统负责人）。
填了会发生什么（每一步你都有回音）：
| 时点 | 你会收到什么 |
|---|---|
| 提交后 | 确认通知：你的快照已被接收 |
| 判定后 | 自动归档的，你收到"证据已采纳"反馈；进入复核的，复核结论对你可见 |
| 归档后 | 你的快照成为模式卡片的一部分，你可以在模式库中看到引用记录 |
七、交付标准与自检
提交前自检清单（全勾再走）：
- [ ] 6 个字段全部填写，无空项，字段名未改
- [ ] symptom 引用的是界面真实原文
- [ ] impact 写清了"用户因此承受了什么"，而不是"体验不好"
- [ ] expectation 是一句话能说清的语义判断，机器可据此判定
- [ ] evidence 至少 1 个真实产品实例（截图 + 复现路径/链接）
一个便宜的自测：把快照给一个不看视觉稿的同事，只看字段，让他复述"用户必须做什么"。 复述不出"立即处理"和"等一等就好"的差别，说明 expectation 还没写到位。
标注的及格线不是人看懂了，是机器不会误解。
八、最小可行：今天的第一条快照
不用等体系搭好。15分钟跑通第一条：
- 找一个你最近吐槽过的界面（不用等严重，轻飘飘的报错提示就很好用）
- 按六个字段逐个填
- 过一遍自检清单，交出去
第一条不需要完美。0.60–0.85 的复核区间，就是留给"不完美但真实"的判断的。
九、常见误区
"这是又要加流程吗？"
不是审批，是登记。没有门槛、没有评审会，格式对 + 有证据就入库。字典管规模化复用，不管创意萌芽，你探索阶段的一切自由原样保留。
"我语义判断错了怎么办？"
没关系。快照是你的观察记录，不是终审判决。三层判定会复核，0.60–0.85 区间会有人来复核，错了会被修正，对了就成为模式库的第一块砖。判断依据写不下来，通常说明判断还停在直觉层，这本身就是一次有效的自检。
"和平时提bug有什么区别？"
Bug记录的是"功能错了"，快照记录的是"语义错了"，它意味着什么、用户该做什么。前者修完即弃，后者会沉淀成模式卡片，长成一条拦截规则，让同类问题不再发生。
"6个字段会不会太少，说不清楚？"
恰恰相反。少一个词，AI就把两个世界平均成一个，字段少，是逼你把直觉换成判断。模糊的描述机器无法判定，离散的判断才能被判定。
结语
从"截图发群"到"证据入库"，变的是直觉的归宿，不是你多干了什么。
把设计规范写成代码格式（Schema-As-Code）这套框架的源头活水，就是你在界面上多看的那一眼。机器负责跑完剩下的路，判定、归档、翻译、编译、拦截，但路的第一块砖，永远是你按模板写下的那一条快照。
它会流向下一个YAML契约的模板的世界：在那里，有人把它翻译成一份7字段的YAML契约，编译成四种产物，其中一种Checklist会回到你的走查现场。如果你想看看自己的直觉最终被写成什么样，值得去翻一翻。
__
第一条快照提交成功后，欢迎回来分享那一刻，它值得被记录。
1920.png.png
