这篇文章还没写下第一段正文之前，已经先变成了一张画布。
画布上有 19 个节点、18 条关系。文章要写给谁、核心观点是什么、开头从哪里切入、中间用什么案例、读者可能会质疑什么、最后怎样让人照着做，全都先摊开了。等这些事情明确以后，我才对 AI 说：开写。
这正是我最近在用的一套新方案：先用 dbskill 和 AI 把事情聊明白，再把确认后的任务放进 Canvasight，整理成一张可视化画布，最后让 AI 按照画布执行。
整个过程里，AI 参与得很深，但我不再要求它一上来就给答案。
AI 很忙，事情却不一定做得对
以前我使用 AI，通常是从一句需求直接开始的。
比如我会说：“帮我写一篇文章，介绍我最近的 AI 工作流。”AI 很快就会给出一个大纲，接着生成正文。单看每一步都挺顺利，但写到后面经常会出现几个问题：前面提过的重点被漏掉了，文章的目标读者悄悄变了，案例和观点对不上，或者写出了一篇结构完整、读完却没有留下什么印象的文章。
这时候我一般会继续补 Prompt。这里改一下，那里加一点，再提醒它不要忘记前面说过的要求。聊天记录越来越长，真正重要的决定却散落在几十轮对话里。人记不住，AI 也只能根据当前上下文猜测哪些信息更重要。
我后来意识到，问题不一定出在模型能力上。很多时候，AI 只是太早开始执行了。
我们还没把目标、边界、材料、依赖和完成标准说清楚，就已经要求它交付结果。对话看起来很顺畅，任务其实还没有被真正定义。
聊天记录不是任务结构。Prompt 再长，也不会自动长出清晰的关系。
我现在把 AI 协作拆成三层
我现在的流程很简单：db skill 负责把话聊明白，Canvasight 负责把关系摆明白，AI 负责把事情做出来。
这三层看起来都在和 AI 打交道，但承担的职责完全不同。
澄清和明确
第一层是澄清。我会先使用合适的 db skill，和 AI 讨论我到底想解决什么问题。这个阶段不急着生产最终结果，而是持续追问：真正的目标是什么？最后要交付什么？哪些内容必须保留？哪些边界不能越过？需要哪些材料？做到什么程度才算完成？
不同任务可以选择不同的 db skill。目标模糊时可以先做目标清晰化，商业问题可以先诊断，内容项目则可以先判断选题、结构和受众。重点不在于选中一个“万能 skill”，而在于让 AI 暂时停留在思考和澄清阶段。
我通常会这样开始：
我想做一件事：________。
先不要执行。请用合适的 db skill 和我一起把目标、交付物、边界、材料、风险和验收标准聊清楚。遇到会改变方案方向的问题，先问我，不要替我决定。经过几轮对话，原本的一句话想法会逐渐变成一份任务定义。这个阶段的产物不是一段“听起来很有道理”的回复，而是已经足够明确、可以进入下一步的输入。
可视化任务
第二层是结构化。我会把双方已经确认的内容输出到 Canvasight。
在画布里，目标、子任务、依赖关系、参考材料、风险、决策和验收标准不再混在一段文字里。它们会成为不同节点，通过位置和连线形成一张任务地图。我可以一眼看出某个任务依赖什么、某段内容缺少什么证据、哪个问题还没有得到解决。
这里真正有用的并不是“看起来更可视化”。画布把原本藏在聊天上下文里的关系，变成了人和 AI 都能检查的共享对象。
我会用类似这样的指令完成交接：
把我们已经确认的任务整理到 Canvasight。
请分别建立目标、受众、边界、材料、执行步骤、依赖、风险和验收节点。不要把尚未解决的关键分歧伪装成普通任务。整理完成后，先让我检查结构，不要立即执行。AI 执行
第三层才是执行。等我检查完画布，确认没有明显遗漏或错误关系，再让 AI 从具体节点开始工作。
这时每个执行节点最好都能回答五个问题：输入是什么，要做什么，受什么约束，应该交付什么，如何判断完成。AI 不需要再从一大段聊天里猜我的真实意图，只需要在清楚的上下文中完成当前节点，并把结果放回对应位置。
人的工作也随之改变。以前我不断补 Prompt、追遗漏、纠正跑偏；现在我更多是在检查结构、处理例外和做最终判断。
这篇文章本身，就是这套流程的一次运行
我最初对 AI 说的内容其实很短：我想写一篇文章，介绍一套使用 db skill、Canvasight 和 AI 的工作方案。任务清晰、高度可视化，而且 AI 深度参与。
如果沿用以前的方式，AI 完全可以马上生成一篇文章。但这一次，我们先打开 Canvasight，把文章拆成了 19 个节点。
除了常规的开头、正文和结尾，画布还单独整理了几个很容易被忽略的部分：目标读者是谁，文章真正要证明什么，需要什么真实案例，读者会提出哪些反对意见，这套方法在什么情况下不值得使用，以及文章写完以后如何判断它是否合格。
画布里还有一条失败恢复路径。信息不足时，任务应该退回 db skill 继续澄清；依赖关系有问题时，回到 Canvasight 调整结构；执行结果不达标时，只重做对应节点，不需要推翻整段对话重新开始。
等这张图通过检查以后，我才说了两个字：开写。
此刻你读到的这篇文章，就是 AI 根据那张画布执行后的结果。它不只是介绍这套方案，也把自己的生成过程变成了一个可以检查的案例。
为什么中间一定要有一张画布
一开始我也会觉得，对话已经说得很清楚了，为什么还要多一道画布？真正用起来以后，我发现这一步解决的是语言天然不擅长处理的问题。
聊天是线性的。我们一句接一句往下说，但复杂任务往往同时存在多个分支：目标影响范围，材料支撑判断，某个步骤依赖另一个步骤，风险又可能改变执行顺序。这些关系塞在聊天里时，需要人一直记着；放到画布上，它们会直接出现在空间中。
这种外化对人和 AI 都有帮助。
对人来说，画布降低了记忆压力。我不需要反复翻聊天记录，就能发现缺口、重复和冲突。对 AI 来说，结构化上下文减少了猜测空间。对整个协作过程来说，每次修改都落在具体节点上，讨论、执行和复盘终于指向同一份任务模型。
我觉得这才是“人机协作”里经常缺失的一层。我们有越来越强的模型，也有越来越多可以调用的 skill，但如果没有一个共享、可检查、能持续更新的任务结构，AI 参与得越深，失控时的返工成本也会越高。
这套方法并不适合所有任务
画布会带来额外的整理成本，这一点没必要回避。
如果只是翻译一句话、改一个标题、查一个明确事实，直接让 AI 执行就好。为了几分钟能完成的事情画十几个节点，只会让流程变得笨重。
我更愿意在几类任务中使用它：步骤多、信息来源多、存在明显依赖、需要多个 AI 或多人协作、一次跑偏会造成大量返工，或者任务会持续很多天。复杂写作、产品设计、研究整理、开发改造和长期项目都比较合适。
画布也不是越详细越好。我不会把所有聊天内容都搬进去，只保留会影响执行的结构。一个节点最好只承担一个主要职责；没有输入和验收条件的节点，不应该急着运行；没有解决的关键分歧，也不能包装成一项普通待办交给 AI。
另外，这套方案不会消除模型幻觉，也不能代替事实核查、权限控制和高风险判断。AI 可以协助生成结构，甚至完成大部分执行工作，但目标、优先级、风险承受和最终验收仍然要由人负责。
如果你想试，可以从一个反复返工的任务开始
不用先搭一套很宏大的系统。找一个最近让你反复补 Prompt 的任务，走完下面这个最小流程就够了：
用一句话描述你想做的事。
让合适的 db skill 追问目标、交付物、边界、材料和验收标准。
由你确认关键决策，再把任务输出到 Canvasight。
检查每个执行节点是否具备输入、动作、依赖、输出和验收条件。
让 AI 逐节点执行；发现问题时，回到出问题的那一层修正。
一张合格的执行画布，不需要看起来多复杂。只要目标能被一句话复述，每个节点职责清楚，关键依赖有连线，材料来源明确，风险有处理路径，结果可以被验收，它就已经比一段不断增长的聊天记录更可靠。
我越来越确定，AI 参与得越深，人就越不能只负责“提需求”。真正重要的工作，是在 AI 动手之前，把任务定义清楚；在 AI 执行过程中，让结构保持可见；在 AI 交付以后，用提前约定的标准判断结果。
db skill 把话聊明白，Canvasight 把关系摆明白，AI 把事情做出来。
这就是我最近在用的工作方式。