show-me

给我看看

没展示出来的作品，就等于不存在。

这项技能弥合了完成某件事与真正交付给对方之间的差距。用文字描述一张图片，不等于展示它。打印出一个文件路径，也不等于展示它。两者看起来都像是交付了，但实际上都不是。

无需安装任何东西。你编写 HTML，打开它，让对方查看。

何时触发

只要答案是视觉内容，而你正准备改用文字描述时：

• 计划、结构、路线图、步骤
• 两件或多件事物之间的比较
• 布局、页面、设计、线框图
• 报告、评审、仪表板、进度摘要
• 任何需要用户在选项之间做选择的时刻

如果他们得读两遍，那就把它画出来。

模式 1 - 展示

一个方案，或一组版本。

1. 将一个完整、独立的 HTML 文件写入临时路径。CSS 内联，不发起外部请求，不使用 CDN 链接，不使用网页字体。即使断网也必须能渲染。
2. 加入 <meta charset="utf-8">。否则每个撇号都会变成三个乱码字符。
3. 打开它，并将浏览器窗口置于前台（见下文）。
4. 之后再说任何相关内容。

模式 2 - 选择

用户需要在两个或更多方向中做选择。

至少三个。 两个选项其实是伪装成选择题的是非题。三个选项才能让人开始看清自己真正想要什么，而答案往往是在第三种形态中加入第一种方案的一部分。

将它们并排放在同一页面上，每个选项都配一个简短标签和一句话描述其主张——不是装饰，而是主张。然后提问。

绝不要让人从文字描述的视觉选项中做选择。 布局的文字描述只是你脑中的模型，不是布局本身，所以你得到的要么是针对错误对象的裁定，要么根本得不到裁定。先渲染，再提问。

渲染前：一句话测试

用一句话描述每个方向。如果同一句话适用于其中两个，那你只是给同一个想法换了样式，而不是设计了两个方案。 回去重做。三个只是在同一种模式上略作变化的方案板，会让这次选择毫无意义，因为无论他们选哪个，你都什么也没学到。

方案板

按此构建。它刻意保持朴素，让选项成为唯一有视觉分量的内容；每张卡片都带有一个复制所选内容的按钮，这样他们只需点击作答，不必打字说明自己选了哪个。

<!doctype html><meta charset="utf-8"><title>Pick a direction</title>
<style>
 :root{--bg:#fff;--fg:#14171a;--mut:#5d6b7a;--line:#e3e8ef;--card:#f7f9fb;--accent:#c2410c}
 @media (prefers-color-scheme:dark){
   :root{--bg:#0f1418;--fg:#eef2f6;--mut:#9aa8b6;--line:#243039;--card:#161d23;--accent:#fb923c}}
 *{box-sizing:border-box}
 body{margin:0;background:var(--bg);color:var(--fg);padding:40px 32px 80px;
      font:16px/1.55 ui-sans-serif,-apple-system,"Segoe UI",Roboto,sans-serif}
 h1{font-size:26px;margin:0 0 6px}
 p.lede{margin:0 0 30px;color:var(--mut);max-width:70ch}
 .grid{display:grid;gap:22px;grid-template-columns:repeat(auto-fit,minmax(300px,1fr))}
 .card{border:1px solid var(--line);border-radius:12px;background:var(--card);
       padding:18px;display:flex;flex-direction:column;gap:10px}
 .card img,.card svg{width:100%;display:block;border-radius:7px;border:1px solid var(--line)}
 h2{font-size:17px;margin:0}
 .angle{color:var(--mut);font-size:14px;margin:0;flex:1}
 button{font:inherit;font-size:14px;padding:9px 14px;border-radius:7px;cursor:pointer;
        border:1px solid var(--accent);background:transparent;color:var(--accent)}
 button:hover{background:var(--accent);color:var(--bg)}
</style>
<h1>Pick a direction</h1>
<p class="lede">One line on what to judge, and what to ignore.</p>
<div class="grid">
  <div class="card">
    
    <h2>A &mdash; name of the device</h2>
    <p class="angle">The argument this one makes, in one line.</p>
    <button onclick="navigator.clipboard.writeText('A');this.textContent='Copied — paste it back'">Pick A</button>
  </div>
  
</div>

让方案板保持诚实的三条规则：

• 说清布局手法，而非装饰。“左侧显示时间线”是一种布局手法。“蓝色版本”是装饰，意味着你把同一个东西做了两遍。
• 嵌入所有图片。<img src="/some/local/path.png"> 在文件移动后就会显示为破损图标。将图片转换为 Base64 并嵌入页面，或用内联 SVG 或 HTML 绘制。
• 要判断形状？就用灰度渲染，并在导语中说明。 在他们查看结构之前，颜色就已经左右了判断。

正确打开

open -a "Google Chrome" file.html 并没有给他们展示任何东西。 它会创建标签页，却不会将浏览器置于前台，所以新标签页会被堆在他们实际查看的内容后面。在 macOS 上改用：

osascript <<'EOF'
tell application "Google Chrome"
  activate
  set w to front window
  make new tab at end of tabs of w with properties {URL:"file:///ABSOLUTE/PATH"}
  set active tab index of w to (count of tabs of w)
end tell
EOF

activate 会将窗口置于前台，而设置 active tab index 会选中新标签页。两者缺一不可。在 Linux 上，对应的命令是 xdg-open；在 Windows 上则是 start。

然后确认它确实生效了。 读取活动标签页的 URL 并确认是你打开的文件——期间可能有另一个窗口或进程抢走焦点：

osascript -e 'tell application "Google Chrome" to return URL of active tab of front window'

命令以 0 退出只能证明它运行了，绝不能证明他们看到了内容。

哪些内容应渲染为 HTML，哪些不应

HTML：用于他们要查看或分享的内容，包括计划、评审、比较、报告、仪表板、选项网格和会话交接。

纯文本：用于他们要粘贴到其他工具中的内容，包括社交媒体帖子、新闻简报正文、文档、配置文件和指令文件。HTML 会破坏粘贴目标；而在配置文件中，它会在之后的每次会话中消耗令牌，却毫无益处。

开始制作前，先说明你要输出哪一种。

两件会毁掉成果的事

文字密集的内容上不要加背景网格或纹理。 在仪表板上看起来不错，却会让密集文档真的难以阅读。

先亲自查看。 没有打开过的渲染结果，就无法诚实地描述；而这正是把损坏的页面当作候选方案展示出来的原因。

如何介绍成果

渲染结果会自己说明一切。围绕它写的话应当少之又少。

先说结论，不说过程。 第一行就说明他们看到的是什么，以及你的看法。绝不要先说你将要做什么，或你是如何做出来的。

最后给出一件接下来要做的事，单独占一行，现在就能做：

Next: pick a direction and I will build it out.

只给一个下一步，不要列菜单。不要说“如果你想修改，请告诉我”，也不要列出五件他们可以要求你做的事。如果确实没有下一步，就说工作已完成，然后结束。

明确说出结论，包括失败之处。 “这个坏了，另外两个值得看看”胜过沉默，也胜过把损坏的页面当作候选方案展示。

不要猜测

最浪费时间的失败，不是渲染效果差，而是基于无人核实的内容，自信地做出成果。

如果你不知道文件名、数字、状态、路径，或链接指向何处，就去核实——读取文件、运行查询、打开页面。没有核实过的看似合理的答案，就是失败，不是捷径。

如果确实无法核实，就明确说**“未经核实”**，并指出缺少什么。绝不要用听起来似乎正确的内容填补空缺，不要根据文件名推断数值，也不要报告自己没有执行过的检查结果。

这与 Anthropic 自己在幻觉指导中提到的理念一致：明确允许模型承认不确定并说自己不知道，而不是让它自行选择听起来最可能的答案。

开口前的检查

只问一个问题：他们在本次会话中亲眼看过这个成果吗？

如果没有，无论成果本身完成得多好，你都还没有完成。