Two months with WorkBuddy: turning a chat box into a daily task machine

What annoys me most is doing repetitive work on overtime. At 3 a.m. I was revising a design doc, and by the seventh version I realized I was doing something really dumb: copying a dozen or so verbal comments from the review meeting one by one into a table, tagging owners, tagging priorities. I did this once a week for two months.

A couple days ago I came across that Tencent Cloud case collection "What Everyone Is Using WorkBuddy For" — supposedly six pieces picked from sixty submissions, covering financial annual report parsing, resume screening, 3D scene modeling, civil service exam data mining, all of it. After reading it, my first reaction was: these people use it in wildly different ways. Same tool — some use it like a search box, some use it like a colleague.

It sits on your desktop, can read files, run scripts, connect to systems — it's an AI digital colleague.

I've been using it for two months, stepped in plenty of pits, and the conclusion I finally landed on is one sentence: treat it like a chat box and it's just a chat box; treat it like a workspace and it actually starts working. My setup is Windows plus local folders — other environments may not apply.

First, draw the map

The first thing is to create a workspace. Open WorkBuddy, there's a plus sign in the top left, click in and choose "New Workspace," then pick a local folder as its working directory. This is the step beginners skip most easily — skip it and you'll find it can't read your files, because it has no idea where they are.

The workspace is basically drawing a map boundary for it. I made a folder called Design Daily, with two subdirectories under it, input and output. Input gets review notes, md exported from Feishu docs, requirement screenshots; output is where it writes on its own. Draw the boundary clearly, and only then will it stop rummaging all over your hard drive.

Then comes stating the requirements. This is where I took the biggest detour. At first I always wanted to spell out all the requirements in one go, and the result came out wrong, fields all scrambled. Later I learned better — only let it do one thing at a time. Specifically for that weekly table, my instruction is one sentence: read this week's newly added meeting notes in the input folder, extract each to-do, output three columns — item, owner, priority — save as xlsx into output.

The key is the next step. After it breaks down the task it doesn't just start running — an execution plan floats up on the left side, with a little dot in front of each step. Those are checkpoints, which I understand as save points. Click in and you can see which files this step plans to read and how it plans to handle them. My habit is to glance at every step, because once this kind of work goes sideways, tracking down the error afterward is slower than just rerunning it. One time it interpreted priority as the order things were mentioned in the meeting — the first few all high priority, the rest all low. I saw in the checkpoint that the step description was off, changed the prompt directly, and saved a round of rework.

Once it runs smoothly, save it as a task template — next time no need to re-describe, just click the template and swap the input folder. One level up from that is scheduled tasks; mine runs automatically every Friday afternoon, and when it's done I get a summary in Feishu. I've used scheduled tasks for about two months — stable is stable, but the premise is that the input file format doesn't change. One time I switched to a new meeting notes template, and it treated the header row as a to-do.

Who can view, who can edit

This table isn't just for me. After the workspace is set up there's "Share" in the top right, where you can pull people in. On my side I gave the lead designer and producer read-only, and gave another designer on the same team edit access. The difference is that read-only people can see execution records and output files but can't change prompts and templates; editors can.

I stepped in a pit once with permissions. Early on, for convenience, I gave the whole team edit access, and someone changed the field names in the template — my scheduled task output empty tables for two weeks straight, and it took me ages to find out. Now the division is: I maintain templates and input specs, the designer on my team is responsible for dropping files into input, the lead designer only looks at output. Sounds like making a mountain out of a molehill, but for a task that runs every week, when something goes wrong the scariest thing is not knowing who changed it.

Oh right, I wrote a post in September about wanting to copy the design-to-code approach to organize UI assets, and the fields all scrambled. That lesson is the same as this one: don't expect it to guess your data structure — you have to nail down the field names first, then let it fill them in.

Back to that 3 a.m. Now I still go through those dozen or so comments, but it only takes five minutes — mainly checking whether it missed time descriptions like "before next Wednesday." It occasionally misses those, so a human has to backstop it.

The rest of the time I spend revising the design doc.