固定案例可以说明一种筛选方法怎样工作，但换成自己的表格以后，研究者首先面对的是列名、单位、缺失值、候选身份和结果回填。这些步骤没有接起来，模型输出就只能停留在一张排行榜里。

面对一批候选配体，模型给出一个分数以后，下一步仍有很实际的问题：这一轮只能测几个，先选谁，不同方法是否用了相同的信息和预算。单独列一条误差指标，往往还解释不了推荐名单为什么变化。

长项目里经常会同时冒出两个相关问题。一个标签在继续原任务，另一个标签想沿着同一段历史做点别的。复制整段会话会让两边逐渐分开；直接共用可变历史，又会让同时完成的两轮互相覆盖。

把会议转写放到RK3588上，除了模型能不能运行，还要决定有限的计算花在哪。输入来自哪一路麦克风，什么时候值得调用另一套识别器，增加一次计算能换来多少质量，这几件事需要分别比较。

录音软件能把一次对话保存下来，真正难用的往往是之后的部分：这次聊过什么，下次还要确认什么，自己的哪段回答值得再练。如果每次都从一份长转写重新开始，历史很快就会变成另一种资料堆积。

面试准备容易留下很多互不相连的材料：岗位介绍、自己的经历、一次练习录音，还有练完以后写下的几条建议。下一次再准备时，材料仍在，却不容易找出“这次先练什么”。

修界面时经常会遇到一个很直接的需求：把当前效果截下来，连同问题发给 agent。对于已有长会话的桌面工具，增加一个上传按钮只是开始。图片还要跟着排队消息、编辑重发和历史恢复一起走，压缩上下文以后也不能莫名消失。

收到一封活动邀请以后，真正耗时间的事情通常在邮件之外：判断值不值得参加，找自己的资料，打开报名页，把差不多填过很多次的内容再填一遍，最后检查提交。

Agent 跑得久以后，问题会从“能不能调用工具”变成“现在究竟做到哪一步”。一个命令已经发出，界面却没收到结果；用户切到了另一段会话，旧任务的异步回包还在路上；上下文压缩到一半，又有新消息进入历史。单看一轮正常对

做一个项目时，聊天窗口很快就会装不下全部工作：代码在编辑器里，命令留在终端，查过的资料散落在浏览器，另一个问题又得开一段新对话。第二天回来，还要重新解释昨天做到哪里。