图工程：把AI工作流变成可管理的步骤图

I came on here to talk about a term I keep seeing going viral on Twitter. It's graph engineering. You've seen it. I've seen it, too. And I'll be honest, the first time I saw it, my reaction was, "Okay, is this a real thing, or did we just invent another phrase to make everyone feel behind?" Because AI has this funny habit where every few weeks, there's this new term that goes viral. Prompt engineering, context engineering, agent engineering, vibe coding, uh loop engineering, and now graph engineering.

Some of these phrases are hype. Some of them are actually useful. And graph engineering is one of the useful ones, because it gives you a much better way to think about how AI actually gets done. So, in this episode, I'm going to explain graph engineering in plain English. By the end of this episode, I want you to be able to take one AI workflow you already run, like customer research, port triage, content production, or startup idea validation, and turn it into a simple map of steps, checks, handoffs, loops, and human approvals.

So, we're going to talk about all that and how you can do it. It's going to be clearly explained. So, let's get into it.

[music]

The simplest way to think about graph engineering is like this. Prompt engineering is how you ask the AI for a better question, and context engineering is how you give AI better information. But graph engineering is how you design the work around the AI, so the whole thing stops living inside inside one messy, giant AI chat. I'll give you an example. Imagine you're researching a new new idea. The normal way most people use AI is they open up a chat and they say, "Should I build this idea?"

The model will give you a confident answer. It probably sounds pretty smart. It might give you the market size, a few competitors, maybe a go-to-market plan, and you feel like you did the research. But if you actually slow down, you realize something a little uncomfortable happened. One model in one pass decided what mattered, researched the market, interpreted the evidence, wrote the recommendation, and graded it in its own confidence.

That's a lot of trust to put into one blob of text. In some cases, you might spend years of your life based on this one question that you asked, and you might be working on the wrong thing. The graph version looks a lot different. So, a planner first breaks the question into angles. One research One researcher looks at the customer, another looks at competitors, another looks at distribution, another looks at pricing, another looks at risks.

Then a skeptic will try to kill the weak findings. Then a merger turns the surviving evidence into a one-page recommendation. And then you approve the decision before you act on it. The output might still be this written report, but the work behind it is just designed so much better. And that at its core is graph engineering. You're taking a messy AI task and turning it into a workflow that you can actually manage. Now, let's define the basic vocabulary without making this feel like a computer science lecture.

By the way, I remember learning about One of my first classes in university was graph theory and and and so it's a real throwback for me. I will explain it to you in the clearest way possible. When people say graph, they basically mean jobs connected by arrows. Each job is a step in the workflow. The arrows show what happens next. And the shared notes moving through the workflow are the state, which is just a fancy way of saying what does the system know so far?

So, that sounds technical for about 5 seconds and then you realize that's actually how work gets done in the real world in in in reality. You know, think about customer support. When a customer writes in, the work is rarely just answer the ticket. First, you need to understand what kind of issue it is. Then you need to check the customer's account history. Maybe you need to search for the docs for the right policy. Then you draft a response.

Then you decide whether this is risky enough that a human should review it before going out. When you draw those steps out and connect them in an order, they actually depend on each other and that is a graph. Take content for example. If I'm making a YouTube episode, the work isn't just write a script. A good episode might start with research, a thesis, examples, a hook, maybe a script, then title ideas, then thumbnail uh directions, then I you know, an Excalidraw, and then a final pass where I ask, "Does this sound like a human being or does this sound like someone trapped inside a SaaS onboarding flow?"

Some of those steps have to happen in order. Some of those steps have have to happen in order. You probably want the thesis before the script. You probably want the script before the Excalidraw. But other pieces can happen at the same time. One re- One researcher can look for examples while another looks for counterarguments. One could study the audience angle, while another looks for practical workflows. Then, those outputs merge back into the script.

And that's where the graph starts paying because most people use AI in a straight line because chat makes everything kind of feel sequential. You ask for research, then you ask for summary, then you ask for a draft, and then you ask for edits, then you ask for titles. That works for really simple things, but when the work has multiple pieces, the straight-line chat starts to get slow and fuzzy and actually hard to trust.

What's cool about a graph is it lets you design the work more like a small team. One part plans, a few work in parallel, another checks the work, another merges it, and then the human approves the final step. And once that clicks in your head, uh it just gets a lot less mysterious because there's two different things people mean when they say graph in AI. And this is actually where a lot of the confusion comes from. The first is what's called a knowledge graph.

A knowledge graph helps AI reason over relationships over things. For example, this customer works at this company, this company uses this product, this product connects to this tool, this support issue relates to this feature, and this feature is owned by this team. Knowledge graphs help because AI reason across relationships in messy data. This matters because normal rag often retrieve chunks of text that looks similar to the question, but it can struggle when the answer actually requires connecting different people across companies and topics and claims and events.

You know, there's tools like you might have heard of Microsoft graph rag, because sometimes you just need AI to understand relationships inside a body of knowledge, not just to retrieve the nearest paragraph. That is one version of graph engineering. The second version is what's called an agent graph. An agent graph is about how work moves. So, a planner hands work to researchers, the researchers work in parallel, a skeptic checks the findings, a synthesizer might merge the parts, and a human will, you know, approve the final answer.

This episode is mostly about agent graphs, actually, because that is the version you can start using today as a founder, as a creator, as an operator, as a small team. So, I figured I'd do an episode focusing on that. Um the easiest way to remember the difference, though, is is kind of like this. Knowledge graphs help AI understand how information connects, whereas agent graphs help AI understand how work should move.

And eventually, the truth is the best systems use both. The AI will understand relationships inside your business, and it will also know how to move through the right steps. Um but how can we make this tactical? When should you use graph engineering? Well, use it when the work has multiple steps, multiple sources, maybe multiple paths, checks, risk, or approvals. Honestly, if you're asking AI to brainstorm 10 names for a new project, you probably don't need a graph.

If you're asking AI to sum

原文超出正文长度上限，此处截断——上游还有内容，完整版见上方「原文 ↗」。