語義快照模板用 6 個欄位把「我覺得不對」變成機器可查的證據

简介： 6个字段把"我觉得不对"变成机器能查的证据：所属产品、组件类型、界面证据、用户误判成了什么、出现场景、唯一编号。模板的作用不是多填表，而是强迫翻译发生：字段齐全只是结构入场券，困惑可被第三方复现、证据来自真实场景，才算把直觉变成了证据，个人困惑由此沉淀为规则体系的原材料。

开篇 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