Before this article had even written its first paragraph of body text, it had already become a canvas.
There are 19 nodes and 18 relationships on the canvas. Who the article is written for, what the core viewpoint is, where the opening should start, which cases to use in the middle, what readers might question, and how to get people to follow along at the end—all of it is laid out first. Only after these things are clear do I say to the AI: start writing.
This is exactly a new approach I have been using recently: first use dbskill and AI to talk things through clearly, then put the confirmed task into Canvasight, organize it into a visual canvas, and finally have the AI execute according to the canvas.
Throughout the whole process, the AI is deeply involved, but I no longer ask it to give an answer right away.
The AI is very busy, but things are not necessarily done right.
In the past, when I used AI, I usually started directly from a single request.
For example, I would say: "Help me write an article introducing my recent AI workflow." AI would quickly give an outline, then generate the main text. Looking at each step individually, it seemed to go smoothly, but by the later stages of writing, several problems often appeared: key points mentioned earlier were missed, the target audience of the article quietly changed, cases and viewpoints did not match up, or it produced an article with a complete structure that left no impression after reading.
At that point I would usually keep adding to the Prompt. Change this here, add a little there, and remind it not to forget the requirements mentioned earlier. The chat log grew longer and longer, while the truly important decisions were scattered across dozens of rounds of conversation. People cannot remember them all, and AI can only guess from the current context which information is more important.
I later realized that the problem may not necessarily lie in the model's capabilities. In many cases, AI simply started executing too early.
Before we had clearly explained the goals, boundaries, materials, dependencies, and completion criteria, we were already asking it to deliver results. The conversation looked smooth, but the task had not actually been truly defined.
A chat log is not a task structure. No matter how long the Prompt is, clear relationships will not automatically grow out of it.
I now break AI collaboration into three layers
My current workflow is simple:the db skill is responsible for talking things through clearly, Canvasight is responsible for laying out relationships clearly, and AI is responsible for getting things done.
db skill GitHub address:https://github.com/dontbesilent2025/dbskill; Canvasight official website:https://canvasight.top/zh
These three layers all appear to be interacting with AI, but they carry completely different responsibilities.
Clarify and define
The first layer is clarification. I first use an appropriate db skill and discuss with AI what problem I am actually trying to solve. At this stage, there is no rush to produce the final result; instead, I keep asking: What is the real goal? What must ultimately be delivered? What content must be preserved? Which boundaries must not be crossed? What materials are needed? What level of completion counts as done?
Different tasks can use different db skills. When the goal is vague, start by clarifying the goal; for business problems, start with diagnosis; for content projects, start by judging the topic, structure, and audience. The point is not to pick a "universal skill," but to make AI pause at the thinking and clarification stage.
I usually start like this:
我想做一件事：________。
先不要执行。请用合适的 db skill 和我一起把目标、交付物、边界、材料、风险和验收标准聊清楚。遇到会改变方案方向的问题，先问我，不要替我决定。After several rounds of dialogue, the original one-sentence idea gradually becomes a task definition. The output of this stage is not a response that "sounds very reasonable," but input that is clear enough to move to the next step.
Visualize the task
The second layer is structuring. I output the content already confirmed by both sides to Canvasight.
On the canvas, goals, subtasks, dependencies, reference materials, risks, decisions, and acceptance criteria are no longer mixed into a single block of text. They become different nodes, forming a task map through positions and connections. At a glance, I can see what a task depends on, what evidence a piece of content lacks, and which issue has not yet been resolved.
What is truly useful here is not that it "looks more visual." The canvas turns relationships originally hidden in the chat context into shared objects that both humans and AI can inspect.
I complete the handoff with instructions like this:
把我们已经确认的任务整理到 Canvasight。
请分别建立目标、受众、边界、材料、执行步骤、依赖、风险和验收节点。不要把尚未解决的关键分歧伪装成普通任务。整理完成后，先让我检查结构，不要立即执行。AI execution
The third layer is execution. After I check the canvas and confirm there are no obvious omissions or incorrect relationships, I then let AI start working from specific nodes.
At this point, each execution node should ideally be able to answer five questions: what is the input, what needs to be done, what constraints apply, what should be delivered, and how to determine completion. AI no longer needs to guess my true intent from a long chat; it only needs to complete the current node within a clear context and place the result in the corresponding position.
Human work changes accordingly. Previously, I constantly supplemented prompts, chased omissions, and corrected deviations; now I spend more time checking structure, handling exceptions, and making final judgments.
This article itself is a run of this process.
What I initially said to the AI was actually very short: I want to write an article introducing a work solution using db skill, Canvasight, and AI. The task is clear, highly visual, and AI is deeply involved.
If following the previous approach, AI could have generated an article immediately. But this time, we first opened Canvasight and broke the article into 19 nodes.
Besides the conventional beginning, body, and ending, the canvas also separately organized several easily overlooked parts: who the target readers are, what the article really aims to prove, what real cases are needed, what objections readers will raise, under what circumstances this method is not worth using, and how to judge whether the article is qualified after it is written.
The canvas also includes a failure recovery path. When information is insufficient, the task should return to db skill for further clarification; when there are issues with dependencies, return to Canvasight to adjust the structure; when execution results do not meet standards, only redo the corresponding node without overturning the entire conversation and starting over.
After this diagram passed inspection, I finally said two words: start writing.
The article you are reading right now is the result of AI executing based on that canvas. It not only introduces this solution but also turns its own generation process into a checkable case.
Why must there be a canvas in between?
At first, I also felt that the conversation was already clear, so why add a canvas? After actually using it, I found that this step solves problems that language is naturally not good at handling.
Chat is linear. We speak one sentence after another, but complex tasks often have multiple branches simultaneously: goals affect scope, materials support judgments, a certain step depends on another step, and risks may change the execution order. When these relationships are crammed into chat, a person must constantly remember them; when placed on a canvas, they directly appear in space.
This kind of externalization helps both people and AI.
For people, the canvas reduces memory pressure. I don't need to repeatedly scroll through chat logs to spot gaps, duplicates, and conflicts. For AI, structured context reduces room for guessing. For the whole collaboration process, every change lands on a specific node, so discussion, execution, and review finally point to the same task model.
I think this is the layer that is often missing in "human-AI collaboration." We have increasingly powerful models and more and more skills we can call on, but without a shared, inspectable, continuously updatable task structure, the deeper AI is involved, the higher the rework cost when things go off track.
This method is not suitable for all tasks
The canvas brings extra organizing overhead, and there is no point avoiding that fact.
If it's just translating a sentence, changing a title, or looking up a clear fact, just have AI do it directly. Drawing a dozen nodes for something that takes a few minutes to finish will only make the process clunky.
I prefer to use it for several types of tasks: many steps, many information sources, obvious dependencies, needing multiple AIs or multiple people to collaborate, where one wrong turn causes a lot of rework, or where the task will continue for many days. Complex writing, product design, research organization, development and refactoring, and long-term projects are all fairly suitable.
The canvas is not better the more detailed it is. I won't move all chat content into it, only the structure that will affect execution. A node should ideally carry only one main responsibility; a node without inputs and acceptance conditions should not be run in a hurry; an unresolved key disagreement also cannot be packaged as an ordinary to-do and handed to AI.
In addition, this approach will not eliminate model hallucinations, nor can it replace fact-checking, permission control, and high-risk judgment. AI can help generate structure and even complete most of the execution work, but goals, priorities, risk tolerance, and final acceptance still have to be the responsibility of humans.
If you want to try it, start with a task that keeps causing rework
You don't need to build a grand system first. Find a task that recently made you repeatedly patch prompts, and just go through this minimal process:
Describe what you want to do in one sentence.
Let the appropriate db skill ask follow-up questions about goals, deliverables, boundaries, materials, and acceptance criteria.
You confirm the key decisions, then output the tasks to Canvasight.
Check whether each execution node has inputs, actions, dependencies, outputs, and acceptance conditions.
Have the AI execute node by node; when a problem is found, return to the layer where the problem occurred and fix it.
A qualified execution canvas does not need to look complicated. As long as the goal can be restated in one sentence, each node has clear responsibilities, key dependencies are connected, material sources are clear, risks have handling paths, and results can be accepted, it is already more reliable than an ever-growing chat log.
I am increasingly certain that the deeper AI participates, the less people can be responsible only for "making requests." The truly important work is to define the task clearly before AI starts; to keep the structure visible while AI executes; and after AI delivers, to judge the results using standards agreed upon in advance.
The db skill talks things through clearly, Canvasight lays out the relationships clearly, and AI gets things done.
This is the way I have been working recently.
78 likes
You can like once today
