Checkout got 3.4× slower
OrdersController#create now runs the same inventory query 14 times per request.
- p95
- 184 → 631 ms
- since
- Aug 19, 14:32
- likely cause
- missing preload
I found the call site. I’ll add the preload, run the request spec, and keep this open until the fix reports.
orders_controller.rb01 / THE LOOP
这个循环，五拍
你只在第一拍里。后面的每一拍都不需要你。
你发布
这是唯一有人参与的一步。比较是以版本为锚而不是以时钟为锚，所以在有了「之前」和「之后」以前，什么都不会被判断。
形状动了，一条发现自己写出来
每次渲染一条查询变成了十四条。统计找出候选，模型判断哪些值得打扰人，而十四条实际上只是缺一个索引的漂移，会作为一条发现而不是十四条送到。
你的助手来问发生了什么
通过 MCP，从那个已经打开着仓库的编辑器里问。没有仪表盘要去看，不用从截图里复制粘贴，也不需要有人记着这个动态列表的存在。
它拿到的比屏幕上显示的多
这是故意的。动态列表是为一个能用隔壁窗口的代码补上其余部分的人压缩过的；助手做不到这一点，所以它拿到的是采集到的每一个调用帧而不是最可能的那个、规范化后的 SQL，以及每次父调用下哪些子调用解释了这次变化。
它写出修复，并说明自己改了什么
没有说明的关闭会被拒绝。改了什么、改在哪些文件里、以及为什么这处理的是这次测量本身而不只是碰巧同时发生 —— 这是只有关闭的那一方知道的东西，一个月后就再也找不回来了。
然后你把修复发出去，第五拍就又变成第一拍。整个形状就是这样。
02 / MCP
它实际能做什么
五个工具。两种方案里都全都有 —— 限制助手就是限制产品本身。
$ claude mcp add sixty \
-e SIXTY_API_KEY=sixty_sk_… \
-e SIXTY_ENDPOINT=https://ingest.sixty.sh \
-- npx -y @sixty-sh/mcpCursor、VS Code、Codex，以及任何会说 MCP 的东西，都用同样这两个值，写成一段配置。
list_findings- 当前未处理的有哪些，按排序，带 id。
get_finding- 一条完整的发现：调用帧、SQL、子调用拆解，以及与它同一根因的其它发现。
get_change- 那次部署里改动了这段代码的 pull request 的差分 —— 发现所运行的文件排在最前。
close_finding- 解决、忽略或重新打开 —— 必须给理由。
check_service- 有没有东西在到达，如果没有，是为什么。
install_sixty- 针对这类项目的安装说明。
03 / TRUST BOUNDARY
我们假定它一定会说自己做完了
一个自己关掉自己工单的助手，正是谨慎的读者会停下来的地方。这样停一下是对的。下面是代码为此做了什么。
- 关闭是一种声称，不是一次验证。 任何助手最强的动机都是「做完」，而一条针对从未部署的修复被关掉的发现，就等于从人会看的那张列表里消失了。所以
resolved的含义是：带着这个修复的版本已经上报，而且数字确实动了 —— 在那之前，它一直是打开的。 - 仍然能复现的模式会被重新打开。 不管谁声称了什么，检测器都会在下一轮再跑一次，把它放回来。
- 每一次关闭都会记录是谁做的 —
user:[email protected]或者agent:sixty_sk_abcd。你永远分得清是你们中的哪一个判定它做完了。 - 它读取用的密钥写不了遥测，而你生产环境里的那把密钥什么都读不了。上报密钥泄露，意味着有人能发假的延迟数字；读取密钥泄露，意味着有人拿到了你的发现。这既不是同一种风险，也不是同一份凭据。
- 发现里包含不是这里的人写的文本。 操作名来自你的应用，而带着 shell 的助手，和浏览器是不同种类的读者。所以采集端会把结构上属于一行的东西 —— 名字、文件、版本、SQL —— 全部压平，MCP 服务器则给借来的文本打上标记，好让一条发现没法冒充它周围的结构。这不会让文字变得无害；它拿掉的是属于伪造而不是属于说服的那一半。