Over the past year I've been leaning on AI more and more for log digging at work. At first I kept it simple: AI can read code and summarize long text, so surely I can paste an error log and it'll tell me what's wrong.

It kind of works, but only up to a point.

Paste a big chunk of logs and it will summarize them and pick out the obvious ERROR lines. But real production debugging is rarely about spotting an ERROR. It's about whether that ERROR is the root cause, which service it came from, whether a downstream service wrapped it and threw it back up, how the user's taskId maps to the requestId in the logs, and how many systems a single failed task actually crossed. That part doesn't get solved by pasting logs.

So I eventually wrote down what I learned into a Skill: Mercer-Lee/loghound.

What debugging used to feel like

Before AI, my production debugging was basically the same ritual every time:

1. Support or a teammate sends over a taskId, uid, requestId, or in the worst case just a screenshot.
2. I open the log platform and guess which service to check first.
3. I search for keywords and look for ERROR or WARN.
4. If the entry service only says "downstream call failed," I go find the downstream service.
5. If that service calls another one, I keep following.
6. Finally I turn whatever I can understand into a short answer: what happened, can it be retried, is it the user's material, or do we need engineering.

That whole flow runs on experience. "Task failed" can mean parameter validation failed at the entry, a queue job died, rendering failed, a download failed, or a third-party callback broke. They all look similar from the outside. The first ERROR in the log platform is often just the surface.

The logs are scattered too. Some are in Alibaba Cloud SLS, some in Tencent Cloud CLS, some in Volcano Engine TLS, and some workflow systems only expose status through webhooks or APIs. Occasionally I also have to reverse-lookup users, tasks, or assets in MongoDB or SQL. Doing that by hand every time gets old fast.

AI can help here, but it needs a fixed workbench, not a pile of logs pasted in at the last minute.

What goes wrong when AI reads logs directly

I hit three recurring problems early on.

First, AI loves to treat a symptom as the cause. The entry service says "task execution failed," and AI reports back that the cause is "task execution failed." That's useless. The real clues live downstream: a 403 on an asset download, an unsupported file format, a callback timeout, a parsing failure, or a third-party API returning a concrete error. You have to trace down to that layer before the conclusion means anything.

Second, too many logs wash out the context. One investigation can surface dozens or hundreds of entries. Feed them all to AI and it burns tokens while duplicate logs, INFO noise, and irrelevant WARNs drag it around. The output looks thorough but misses the one line that mattered.

Third, AI doesn't know our topology. When I search logs, I carry a mental map: which service is the entry, which service owns the queue, what a taskId prefix means, and which error usually means I should go check another service. If you don't give AI that map, it's just guessing. The video-generation project I debug most often has the entry, async queues, callbacks, scheduled jobs, and atomic data services split apart, which adds up to more than a dozen log sources on its own.

Once I accepted that, I stopped trying to feed it more logs and started structuring my debugging experience into a fixed process it can follow.

What I wanted to preserve

loghound looks like a log query tool, but what I actually wanted to preserve is the debugging method. I split it into two layers:

• Script layer: query logs, query databases, normalize results, pull out error signals, cluster and deduplicate.
• Analysis layer: classify the problem, trace along the service chain, separate symptoms from root causes, and produce a conclusion for internal use or support.

The script layer handles evidence collection. It talks to Alibaba Cloud SLS, Tencent Cloud CLS, Volcano Engine TLS, webhook workflow engines, and can reverse-lookup records in MongoDB or SQL by user or task ID. Every platform has different query methods and response shapes, so the results get normalized into something AI can read.

The analysis layer handles judgment. The Skill starts by asking what kind of report this is: incident, quality issue, status check, vague feedback, batch problem, or audit. Different types need different paths; you can't treat everything as "go find the ERROR."

After that it follows an identifier priority:

traceId / requestId > taskId > uid / userId > user-side ID

If the entry service has nothing, or the logs don't match what the user described, it falls back to recent anomalies by uid. If a downstream failure shows up, it extracts the downstream taskId, traceId, or requestId and follows the topology to the next hop. The rules are simple, but they stop AI from glancing at logs and guessing.

A real example

One case stuck with me. Someone reported in the test environment that a short-video editing endpoint was supposed to reject a request, but it didn't seem to.

My first instinct was to search for ERROR. The entry service had nothing: just normal logs about the task entering editing and being re-triggered. The rights-check logs I expected weren't attached to the request at all.

If I'd stopped there, I would have written "the endpoint is missing validation." Instead, following the loghound flow, I found the request actually was rejected — just not as an error. It was caught earlier by a content-duration limit, and the endpoint returned a success response carrying a tip. The problem wasn't that the check was missing; it was that the rejection never surfaced as an error.

What made that case close was: classify the problem type first (not "task failed," but "should have been blocked and wasn't"), find the request in the entry logs, then line up the code path — duration check first, then rights check, then deduction. The rights check never appeared in the logs because the code returned at the duration check, so it never ran.

The whole thing took about five minutes. Before, just aligning those logs with the code path could easily eat half my morning.

Things I care about in the Skill

First, separate "status check" from "incident." A lot of the time someone just wants to know whether a task finished. If AI starts writing root causes, ownership, and support scripts for that, it looks ridiculous. So loghound forces the problem type classification first.

Second, logs are evidence, not the answer. A script result only says what was found at a point in time. AI still has to combine upstream and downstream chains, error location, log level, and failure stage before calling something a root cause.

Third, don't stop at wrapped business errors. Systems love to package downstream errors as "task failed," "generation failed," or "processing exception." Those are ERROR-level, but not necessarily the cause. If there's a downstream clue, keep going.

Fourth, the output has to be usable. The end of a debugging session isn't a pile of logs; it's telling someone the cause, whether the user did something wrong, whether retry is safe, and whether engineering needs to step in. Especially for support, it shouldn't read like a stack-trace report.

What it can do now

Right now loghound covers:

• Querying the same taskId or requestId across multiple cloud log platforms
• Recognizing log sources and environments per project config
• Normalizing logs, clustering, and extracting error signals
• Tracing downstream services from topology
• Converting user-side IDs to internal IDs via MongoDB or SQL
• Checking webhook-style workflow status and errors
• Generating root cause analysis and response wording through a fixed Skill process

It's not a universal incident bot. Every company has different topology, log formats, and task ID rules, so it always needs project config, log sources, and call relationships set up.

That's also why it's useful. A tool that doesn't understand your system can only summarize logs. Feed it the topology, log rules, and debugging experience, and it starts to actually help.

Closing thoughts

I used to think log debugging was pure experience work. An experienced person sees an error and knows whether to trust it, whether to keep tracing downstream, which database to reverse-lookup an ID in, what can be answered to a user, and what must go to engineering.

After a year with AI, I've shifted a bit: experience work can be handed to AI, as long as you extract the experience. Don't just say "look at these logs." Tell it to classify the problem first, pick the strongest identifier, fall back when nothing shows up, follow downstream failures, never treat a wrapped error as the root cause, and always attach evidence to conclusions. Once those rules are written down, AI gets a lot steadier.

So loghound is less a tool and more a writeup: the judgment paths that used to live in my head, turned into a Skill. It's my attempt to make AI not just "read logs," but debug the way an engineer actually would. If I keep iterating, I want to add more log platforms, more topologies, and more real incidents until the rough edges are covered.