9d3f01eN+1
orders.enrichOrders
之前1每次请求的查询数→此次部署后14每次请求的查询数
- 始于
v2.4.0- 可能的变更
- #815 扩大订单查询范围
- 运行位置
orders/getUserOrders.ts:47
从变更出发的性能监控
找出哪个部署弄坏了你的应用。
Sixty 会发现新版本如何改变应用的行为——一次查询变成十四次，三十行变成三万行——并把证据交给你已经在使用的编程智能体。
orders.enrichOrdersNew finding
Detected 3 min after deployN+1 query
orders.enrichOrders
This release changed what this operation normally does.
Previous release1 query
→Current release14 queries
- Started at
- v2.4.0
- Code location
- orders/getUserOrders.ts:47
Ask Sixty about this finding…⌘ K
1 条命令完成安装0 个仪表盘要搭0 个阈值要调0 条用户数据被收集
已经在为别的产品付费了？与 Datadog、New Relic 和 Sentry 的对比 →给出答案，而不是又一个仪表盘
AI 运行时回归检测
发现智能体何时变慢、变贵或陷入工具循环。
Sixty 跨版本比较同一项智能体任务：令牌、模型成本、首个令牌时间、工具调用和失败。动态页报告变化，脱敏运行轨迹展示原因。
release e18c6ba支持智能体每次成功运行的成本提高了 3.5 倍
之前 $0.0164→本次部署后 $0.0426
一条贯穿整个应用的轨迹
浏览器、后端、模型、工具和数据库始终相连。
轨迹上下文跨服务跟随请求。模型生成包含工具调用，工具包含内部 HTTP 和数据库工作，因此 Sixty 能一路定位到负责的拉取请求。
browserSupport form submitted0ms
requestPOST /api/support4.82s
generationsupport-agent · gpt-5-mini4.20s
toolMCP · knowledge-base.search ×4310ms
databaseSELECT help_articles · 8 rows96ms
toolMCP · orders.lookup ×2424ms
与证据关联的会话回放
指标变化时，看看用户实际看到了什么。
浏览器错误、无响应交互或卡住的加载生成问题时，Sixty 会保留故障前后的一小段遮罩录像。回放是问题的证据，不是所有访客的档案。
/checkout
Something went wrong
↖
一个安静运行的闭环
你发布，我们发现。你的助手负责 修好它。
没有仪表盘要看，也没有告警要配。下面这三件事就是整个产品，而其中只有第一件是你做的。
你发布一个变更
版本标记来自你已经使用的部署平台。
Sixty 发现形态变化
一次查询变成十四次，无需预先猜测阈值。
智能体收到完整证据
测量结果、查询、调用栈和相关差异会一起送达。
从版本定位到具体代码行
不只是哪次部署。是哪个 pull request。
一次部署包含许多变更。Sixty 使用两个版本之间准确的提交记录，再指出哪个拉取请求改动了发现所在的文件。
v2.4.0这次部署里带了 4 个改动
- #812升级依赖
- #814加上发票导出
- #815把订单查询的条件放宽orders/getUserOrders.ts
- #818设置页的文案修正
- 连着五个版本，
orders.getUserOrders每次都返回三十行。那就是基线。没有人设定过它。 - 然后它返回了三万行。没有抛异常，没有超时，在缓存热着的数据库上，页面感觉还是好好的。
- 是从 v2.4.0 开始的。市面上任何一个监控工具都能告诉你到这一步 —— 而那次部署里带了四个改动。
- 是 #815，它碰了这条查询所运行的文件。这才是你的编码助手能动手的那句话，也是别的东西都不会给你的那句话。
pnpm e2e 在仓库克隆上打印出来的；版本标签和 pull request 编号是示意的。持续监控，真正从不间断
关键在于它 从不停下。
每一个版本都会在上线几分钟后与前一个版本作比较，只要应用还在跑就一直如此。你不用启动它，不会被问任何问题，也没有哪次运行需要你记着去做。
正在盯着checkout-api · production
4c02f1a没有漂移 · 比较了 47 个操作2 minbb7e340没有漂移 · 比较了 47 个操作3 min2e9b503什么都不返回profile.load12 行 → 0 行4 min5a1d0c8没有漂移 · 比较了 48 个操作2 minc40aa19没有漂移 · 比较了 48 个操作2 min9d3f01e行数orders.getUserOrders30 行 → 30,000 行4 min9d3f01eN+1orders.enrichOrders1 次查询 → 14 次查询4 min7b21ee4没有漂移 · 比较了 46 个操作3 mina3f9c21没有漂移 · 比较了 46 个操作2 mind81b904没有漂移 · 比较了 46 个操作2 min
pnpm e2e 运行重建 —— 数字来自那次运行 —— 版本号是示意的。无需改变工作方式
你 已经开着的东西，它就能配合。
Sixty 负责看着；你本来就在用的编码助手负责修。两者之间的交接是一个 MCP 服务器，这也是为什么在哪里安装都是同样那两个值 —— 以及为什么在没有自己编辑器的地方，安装就变成往聊天框里粘一段提示词。
Claude Code
一条命令。发现会以它能直接动手的载荷送到。
Cursor
同样的两个值，写成一段配置。
Lovable
不用自己的编辑器 —— 往它的聊天框里粘一段提示词就行。
Replit
助手和部署在同一个地方；版本标记是白送的。
VS Code
Copilot、Continue，或者你接进去的任何东西。
Codex
还有 Windsurf、Zed、Cline —— 只要会说 MCP 就行。
OpenTelemetry / OTLP · Node · Python · Go · Ruby · PHP · Browser · React Native · Supabase
Keep Grafana, Prometheus, Elastic, Vercel, AWS, or the backend you already use. Send the same OTEL traces and metrics to Sixty for release-aware problem detection.
OpenTelemetry setup → 它支持的所有语言和框架 →投入很小，功能完整
让智能体完成安装，然后发布两次。
两个套餐都包含全部发现、智能体 API 和 MCP。7 天试用从完整产品开始；下一次发布后，你会收到第一次对比。
下一次部署才是关键
看看你的 上一次改动做了什么。
让 Sixty 观察发生了什么变化，再让熟悉代码的智能体完成修复。
不收集用户 ID、提示词正文、模型回复或查询值。路由、工具输入和结果只保留结构；回放文字默认遮罩。
看它抓一个给你
关闭由 pnpm e2e 的输出重建，它会种下正是这一个回归并把它检测出来。数字就是那次运行的。
部署 9d3f01部署 4c02f1a
一切平静。 自你上次部署以来没有漂移。
高行数orders.getUserOrders未处理已认领已解决
30 行 → 30,000 行1000×
这条查询丢了它的 where 子句，于是把整张表读出来，再由代码去筛。在你笔记本上什么都没变慢 —— 那里的表只有四十行。
在等人来看。已经开了四秒。已被你的助手认领 —— 证据已通过 MCP 取到：查询、调用帧、数字。已解决 · 「补上了 user_id 上缺失的 where 子句」
- 你部署
- 我们把它和上一次作比较
- 你的助手接手
- 它自己关掉