Hacker改完一行，怎样看见它真正改变了什么？
绿色测试灯、即时画面和一段可以回放的历史都叫反馈，但回答的是不同问题。沿着一次修改，观察哪些结果能直接看见，哪些还要停下来思考。
本文的问题 · 17
- 文件一变就重跑测试：缩短反馈的一种实现
- 从缩短反馈循环到立即连接创作结果
- 创作工具必须让操作结果可见
- 让修改的结果直接可见，可以减轻使用者在脑中推演的负担
- 把时间过程变得可见：从屏幕演示扩展到实体工作空间
- 慢思考与即时反馈，必须二选一吗？
- 从一行改动，到一个真能用的原型
- 局部重跑时，画面真的是从同一帧开始吗？
- 一个头像传对了，又传得够快吗？
- 元件能当天买到，为什么还需要亲手摸一摸？
- 看见错误之后，还要多久才能再试一次？
- 已经用了异步回调，页面为什么还是卡住？
- 电脑跑出结果之前，能停在哪一步检查？
- 改了状态变换，旧操作还能重新算一遍吗？
- 怎样让总线读数对上时钟脉冲？
- 重新运行一遍，还能得到眼前的状态吗？
- 服务端状态变了，为什么屏幕还没变？
文件一变就重跑测试：缩短反馈的一种实现
Victor要求创作者及时看到决定的后果；Acme演示的Watch在文件变化后自动重跑测试，并更新独立窗口，使修改结果无需手动发起运行即可出现。
对照原文与时间戳 · 2
each time something changes in the directory it reruns the commandif you make a change or you make a decision you need to see the effect of that immediatelyWatch是离散测试反馈，不等同于Victor展示的逐值即时可视化；连接只涵盖缩短修改与结果之间的等待。
从缩短反馈循环到立即连接创作结果
In Search of Tomorrow 追问能否把反馈循环缩短到几乎为零；Victor 明确提出创作者应立即连接到所创作之物；前者说明设计历程，后者给出相近的设计原则。
对照原文与时间戳 · 2
What if we shortened the feedback loop to effectively nothingcreators need an immediate connection to what they create二者是不同演讲中的相近主张，不构成影响关系，也不证明零延迟在所有工具中可行。
创作工具必须让操作结果可见
Victor 要求创作者立即看到决定的结果；Sibelius 把关键操作状态藏在光标细微色差与层层菜单中，展示这一原则被破坏时的具体创作障碍。
对照原文与时间戳 · 2
...by making the arrow a subtle shade of blue? Do you know how hard that is to see?you need to see the effect of that immediately两者并非互相评论；Sibelius 评析针对片中的历史版本。
让修改的结果直接可见，可以减轻使用者在脑中推演的负担
前两例谈编程，第三例谈制谱界面；反馈能帮助观察，但不能保证用户理解背后的概念。
对照原文与时间戳 · 3
if you make a change or you make a decision you need to see the effect of that immediatelySo I could literally watch the
data flow through my program....by making the arrow a subtle shade of blue? Do you know how hard that is to see?把时间过程变得可见：从屏幕演示扩展到实体工作空间
两者都把孤立瞬间扩展为可比较的时间过程。Inventing 用模拟游戏的未来轨迹支持即时调整；Seeing 将这一设计方向扩展为真实项目的运行记录、历史比较和环境级观察设施。
对照原文与时间戳 · 2
immediately you have to map time to spacelook across a range of time at once模拟系统可重新计算未来，实体项目则需要传感和记录；两种技术条件不同。不能据此声称作者改口，或把回放视为反事实预测。
慢思考与即时反馈，必须二选一吗？
Hammock 强调思考但也明确允许试验后返回修改；Inventing 主张创作者与产物保持即时联系。它们可以分别服务问题构思与实现探索，而不是简单的快慢对立。
对照原文与时间戳 · 2
you're going to try stuff and go backcreators need an immediate connection to what they create互补是本站提出的阅读视角。短引文不证明两种方法必然兼容所有任务，也不构成两位作者之间的辩论。
从一行改动，到一个真能用的原型
Cursor 团队希望建议赶在下一次编辑之前到达。Levels 的反馈单位大了一圈：在一人维护的产品里，从改代码到发布的等待也由自己控制。Kay 回忆的 Alto 则用一台昂贵原型提前体验未来机器的交互。三种反馈各自能推翻不同猜想：编辑器猜没猜对下一步，用户会不会用这个功能，或者整套交互是否值得继续造。把最后一个问题的答案换成「补全很快」，仍然少了一次实验。
原文与时间戳 · 3
predicting what the user’s going to do next in their editing of existing codebeing alone by myself on my laptop, in my underwear in a hotel room or something, I can ship very fastit was there to simulate this laptop of the future局部重跑时，画面真的是从同一帧开始吗？
Sanderson 调整 Manim 动画中的一小段时，希望反复运行它来比较效果。直接把同一段代码再贴一次，会在已经改变的场景上继续运行。他的做法是先回到片段起点的状态。使用即时预览时可以做一个便宜的自检：不改任何代码，连续重跑两次。如果第二次画面已经不同，这个预览还隔离不了刚刚那次修改的作用。
原文与时间戳 · 1
It has to revert to the state that the scene had at the start.一个头像传对了，又传得够快吗？
Zuckerberg 解释实验头像怎样先扫描一个人的各种表情，再在视频通话中传输驱动模型的编码。Carmack 给了另一条验收条件：同处一室的感觉取决于细微反应能否足够及时。把眉毛抬起、对方看到、对方回应画在一条线上。单帧截图用来检查还原的表情，来回对话用来检查时延。截图做得更像，并不能回答第二个问题。
原文与时间戳 · 4
scanned ourselves in a lot of different expressionssend an encoded version of what you're supposed to look like over the wirethe super low latency responsivenessjust occupying the same field of view元件能当天买到，为什么还需要亲手摸一摸？
Kay 的飞行案例问的是失败后多久能再试一次，深圳的元件市场补上了实验开始前的等待。片中创业者讲到，某些零件本地订货可以当天或次日到货；另一位受访者说明，挑开关只看照片和规格还不够，手感、尺寸和安装细节需要直接检查。就近接触零件，既减少等待，也让团队更早发现「选错了」；找到合适型号之后，还能在同一市场继续采购。把这两个环节分开，才能分辨流程是在更快地采购，还是更早地检验产品假设。影片后半段的租金与城中村讨论又提醒我们：这种试错条件依赖供应商、工作空间和当地经验共同存在，并不是给单个团队换一个更快的工具就能复制。
原文与时间戳 · 2
we can order in the morning and then we get it in the afternoonyou want to know how it feels看见错误之后，还要多久才能再试一次？
把画面即时显示出来，只缩短了反馈循环的一部分。Kay 讲述的人力飞行尝试还要面对一个更慢的环节：原型摔坏以后，修复会不会耗掉几个月？在他的叙述里，MacCready 先把目标改为一天能承受多次失败、几分钟就能修好，于是有机会通过反复飞行了解问题。把这个角度带回编程工具：除了「多久看到结果」，再量一下「多久恢复到可以做下一次实验」。可撤销的改动、可恢复的测试环境，可能比更快的画面刷新更先解除瓶颈。这是从演讲案例得到的设计问题，并非他对所有研发流程验证过的定律。
原文与时间戳 · 2
we need to be able to do 12 crashes a dayyou could fix it in a few minutes已经用了异步回调，页面为什么还是卡住？
先把「工作已经排队」和「用户已经看到结果」画成两个不同事件。Roberts 连续排入几个定时回调时，较后的回调仍会等待前面的工作，所以一秒是最早可执行的等待条件，并不承诺一秒时执行。滚动演示再补上一种故障：每次事件都很快入队，队列里的慢工作却越积越多。把这个模型用于检查反馈工具，可以沿着输入、入队、实际执行、渲染逐段追踪；把同步循环换成回调并没有自动缩短整条路径。他的动画用简化的渲染队列揭示等待位置，不能直接当作所有浏览器调度规则的完整规格。
原文与时间戳 · 2
it's a minimum time to executionyou're flooding the queue with queued events.电脑跑出结果之前，能停在哪一步检查？
Eater 把反馈问题放到一台小电脑的搭建过程里。他先分别搭建、测试模块，再在整机配合时处理新的问题；讲到时钟时，又提出放慢、停止和单步执行，让排障不只依赖最后的输出。这补充了「即时看见」的含义：有时需要把过程变慢，才能定位一次改变从哪里开始偏离预期。可以据此问自己的调试工具：能否停在两个动作之间，观察当时的状态？这里采用的是讲者说明的方法；未查看画面中的接线和状态变化，不能据此确认整机实现或保证每次单步都能找出故障。
原文与时间戳 · 2
one module at a timeYou can also stop the clock, and then step one step at a time, which is very useful for troubleshooting改了状态变换，旧操作还能重新算一遍吗？
即时刷新画面之前，还要问这次修改需要哪个状态。Abramov 的口述方案把状态变换写成接收旧状态与动作、返回新状态的函数，并保留动作作为重算的输入；他同时要求不要随处修改状态，把副作用推向边缘。这里的反馈因此有条件：如果只留下当前画面，先前怎样走到这里的操作就不能直接拿来重算。这个解释补充了实时预览与可回放历史的区别；现场代码和重放效果尚未核看，不据字幕承诺任意应用都能这样运行。
原文与时间戳 · 2
if you push side effects to the edgeIt takes state an action and returns the new state.怎样让总线读数对上时钟脉冲？
Eater 最初让 Arduino 持续读取地址线。按他的描述，串口虽然不断输出数字，却很难看出某次变化对应哪个时钟脉冲。于是他改成在时钟上升沿触发读取，让每条地址记录对应一个脉冲，再加入数据和读写方向。配合可暂停、可单步的时钟，他可以用逐拍记录来解释复位后从哪里开始取指。这个例子给「看见改动」补了一个具体问题：记录的触发点能否和你要解释的事件对应？这里的采样方案用于他刻意放慢的实验，代码和实际读数仍待视核。
原文与时间戳 · 2
We can stop the clock and we can single-step itread and print out the values of the address pins once per clock pulse重新运行一遍，还能得到眼前的状态吗？
Jack Rusher 主张保留运行中的状态，让开发者在难以重现的场景里立即看见修改效果。他也指出，源码里删掉的定义可能仍留在运行环境里。Joel Grus 从笔记本的执行顺序提出对应的问题：页面上显示的单元格顺序，可能与产生当前结果的顺序不同。
即时反馈保留了排查问题所需的现场，重新执行检验的是另一件事：交给同事的源码和数据能不能从头产生同样的结果。记录当前会话里的前置步骤，可以让这两种检查各自回答自己的问题。
原文与时间戳 · 2
the same thing that you just evaluated earlier is still in the runtimenotebooks have tons and tons of hidden State服务端状态变了，为什么屏幕还没变？
Chris McCord 用 LiveView 的早期示例说明，状态变化触发服务端重新渲染，再把所需的界面改动发给浏览器。Jake Archibald 的事件循环讲解关注浏览器这一端。他指出，运行中的任务需要完成，页面才有机会进入下一次渲染。
追查一次延迟更新时，把两段时间分开记。先找服务端什么时候生成并发送更新，再找浏览器什么时候能显示它。屏幕上的一次停顿，可能需要沿两段不同的工作往回查。
原文与时间戳 · 3
this paradigm on the server and sending those minimal Dom patches over the wireif our state changes our template gets renderedThe event loop guarantees your task will complete before rendering next happens.读完再想一步
选一次最近的改动：如果只能看到最终画面，会漏掉哪个中间状态？