假设你把一批照片复制到移动硬盘。一部分已经复制成功，另一部分因为文件占用或存储空间不足而失败。进度窗口消失后，软件只留下“操作失败”四个字。你不知道哪些照片已经复制，也不知道重新执行会覆盖文件、生成副本，还是只处理剩余项目。
底层程序可能准确地报告了每一次读写的结果，但界面没有把这些结果组织成你能理解的信息。于是，确认文件、比较目录和判断是否重试的工作，需要由你继续完成。这个例子是一个假设场景，却能把“功能已经实现”和“用户能够完成任务”之间的差别说明白。
讨论软件质量时，UI/UX 容易被缩减为圆角、配色、图标和动画。谈到自由软件，又会出现另一层顾虑：维护者已经投入了无偿劳动，继续要求视觉打磨和交互改进，是否忽视了项目的资源限制？我认为这两件事需要同时考虑。设计有成本，项目可以限定自己承担的工作；用户能否理解和使用软件，也确实是质量问题。
假设一个游戏的某一帧突然变慢，Agent 要调查原因。它需要找到耗时的 GPU 工作负载，查看相关资源和源码，修改后重新构建，再用新的运行结果判断问题是否得到改善。Apple 的 Metal 开发工具已经提供了图形界面和命令行入口，可以读取捕获并调查这类问题。[1]
这项任务会经过几种不同的环境：源码在仓库里，GPU 状态在捕获中，修改效果要在目标设备上观察。Shell 能启动这些工具、组织文件和处理输出；专业工具决定哪些状态可以被读取；操作系统和应用的权限设置决定调用能否执行。要评价 Agent 在某个平台上工作的体验，就得把这些环节连起来看。
这篇文章来自一次失败的写作。
最早那版 snap.md 的第一句是“一个被情绪放大的标签”。它从一开始就在同时做两件事：核查 Ubuntu 与 Snap 的事实，同时纠正社区对这件事的舆论。写到后来，文章里长出了“社区偏见从何而来”这样一整章，桌面中心主义、自利归因、回声室被放进一项打包格式的技术论证里。结语同时承担“总结 Snap”和“劝社区理性”两个任务。
