QoderWake User Guide - Alibaba AI Digital Employee Auto-Duty Development Process

NowAI There are many tools available, but most require constant monitoring. You have to open the tool, input the question, add background information, monitor the results, and follow up with further questions. When the task or project changes, a lot of context needs to be explained again.

In a real team, it's even more of a headache. GitHub Issues need to be triaged, CI failures need to be investigated, dependency upgrades need to be followed up, user feedback needs to be organized, and alerts need to be determined as false positives. These tasks aren't actually difficult, just tedious and time-consuming.

I've been looking for a product that can solve this problem.

Alibaba recently launched QoderWake, a digital employee product based on the concept of a 24/7 digital employee. Each employee has a role, identity, memories, skills, and access boundaries. They will wake up automatically when it's time to do something, report back after completion, and seek approval before undertaking high-risk operations.

Wow, K immediately arranged to try out a workflow commonly found in real teams.

First, go to the official website to download it. Currently, it only supports Apple systems, but a Windows version will be available soon, so stay tuned.

The installation process is the same as for other applications.

After installation, the homepage looks like this. It comes pre-loaded with six digital employees: front-end, back-end, testing, product, data analyst, and content operations. If that's not enough, you can customize your own digital employees.

Case 1: Triage of GitHub Issues

I first created a backend engineer employee, linked it to a GitHub repository, and set up an event-driven task. Whenever a new issue appears in the repository, it will enter the triage process.

My expectation is that Yongqi can read new issues, determine the problem type, tag them, and leave the first valid comment. If it's a bug, it should be able to point out the modules that might be affected, suggest logs or files to check first, and if the information is insufficient, it should ask follow-up questions first, and never guess.

A new bug issue was created, and a few minutes later, the backend engineer woke up and started working. He first read the issue, then determined it might involve interface boundary conditions. He then added tags like "bug," "backend," and "needs-triage," conducted initial investigations and followed up with questions, and finally summarized the key points of the investigation.

This case actually demonstrates QoderWake's "production availability". Issue triage isn't particularly difficult, but it's easy for it to back up. Digital staff first categorize, mark, and indicate directions for issues, so subsequent responsible parties don't have to start reading the queue from scratch.

During the issue triage process, I basically didn't need to worry about Yongqi's work. I set up the results to be synchronized in the DingTalk group, and Yongqi would send them directly to me after finishing, which was really convenient.

Personally, I feel that QoderWake is very suitable to take over the first-level triage. It has already moved the issue from "no one is looking at it" to "someone can handle it".

Case 2: CI Failure Diagnosis

In the second scenario, I set up a task for test engineers to follow up on a pipeline failure. They didn't need to merge the code directly; they needed to clearly explain the reason for the failure first.

My goal is that when CI fails, the team sees more than just a series of red flags; they need a readable diagnostic report. The report should include the location of the failure, the key error message, possible causes, and next steps recommendations.

It's really impressive; all of these features have been implemented. Furthermore, the test engineer, Xiaoyanzi, will first locate the failing job and then extract the key logs, instead of simply pasting the entire log verbatim. Xiaoyanzi will connect the error with recent changes to determine whether it's due to unstable test cases, environment changes, dependency issues, or a problem introduced by a specific commit.

The report structure is also very clear: first, it states which stage the failure occurred at; then, it lists the key errors; and finally, it provides the most likely causes and suggested ways to reproduce the failure.

Finally, this categorization summary and root cause analysis is so thoughtful; it's perfect for covering the time when the team isn't at their computers.

Many CI failures actually have very simple problems.SimpleNobody wants to check the logs right away.

Digital employees can save a lot of fragmented time before morning meetings by turning logs into structured reports.

Case 3: Dependency Upgrade and Security Inspection

In the third scenario, I set up a dependency inspection task that runs every Monday morning, which was assigned to backend engineers.

Prompt words:

Check the current project dependencies every Monday morning. Please scan the dependency list to identify upgradable versions and potential security risks.

Prioritize minor version and patch upgrades, and run tests to verify compatibility.

For major version upgrades, upgrades involving changes to security policies, or upgrades that may affect production operations, please provide a risk description and wait for my confirmation.

Finally, please output the upgrade list, test results, risk assessment, and suggestions for the next steps.

Yonghe Robotics first conducted a project overview, clearly listing the documents, functions, and external dependencies.

They then conducted a risk assessment for me and very directly pointed out the "only concern".

Finally, very clear suggestions and summaries were given.

In this case, my main concern was whether it would move around randomly, and the result was exactly as expected.

QoderWake's permission limits and approval mechanism provide a boundary of trust; it will do things, but it won't do them recklessly..

Case 4: Product Processing and User Feedback

In the fourth scenario, I didn't continue with the R&D task. Instead, I assigned a product manager, Ms. K, to give her a batch of user feedback and asked her to compile it into requirements materials.

K organized the messy feedback into structured materials, and also provided frequently asked questions, priority of requirements, and a draft PRD, which greatly reduced the cost of sorting and summarizing.

As expected, the output of this case was very similar to the pre-conference preparation materials for a product meeting. K-sister would first divide the feedback into several categories, then merge the repetitive expressions, and finally extract a few frequently asked questions.

QoderWake is a great tool for product managers to prepare and organize information beforehand.

Transforming dozens of disorganized feedback items into discussable material is a time-consuming but necessary task. If digital employees handle this step first, people can dedicate their time to judgment and decision-making.

Case 5: Front-end page optimization

In the final scenario, I used a dialogue task to find a front-end engineer to handle page adaptation issues.

Let's first look at what the original front-end page looks like.

Er Kang first listed the problems, then provided a complete solution, and finally outlined the scope of the impact.

This case had the strongest sense of collaboration. Er Kang didn't start making changes immediately; he first looked for documents, read the component structure, and explained the plan. Only after I confirmed it did Er Kang help me create the patch.

After making the changes, directly report which states were adjusted, such as narrow screen layout, button arrangement, error messages, loading status, and empty status display, etc.

If you're not satisfied with the changes, you can make further modifications. Take a look at the results; they're definitely much better.

This scenario most closely resembles the feeling of working with a "long-term colleague." You summarize and identify problems step by step, "discuss and plan" to confirm the solution, then they implement it, and finally you review and approve it.

Currently, this role is well-suited for the execution-oriented approach of front-end engineers, especially for handling specific, small-scale optimizations.

After testing these 5 cases, I think QoderWake is like a colleague you can gradually get to know.

Collaboration is also much more reliable. These digital employees all work on the devices I designate, and I can see their permissions, actions requiring approval, and task logs. I know what they did and why they did it.

QoderWake isn't just for chatting; it can also connect to GitHub, Jira, and GitLab, sorted by time or event.automaticStarting work is suitable for handling recurring issues with clear boundaries and acceptable results.

What's even more interesting is that each employee has their own role and memories, and projects also have their own unique memories. The longer you use it, the better it understands your project habits.

A truly worry-free digital employee is one who can keep things moving forward even when you're not at your computer.

Of course, we should also look at its current stage objectively.

QoderWake has launched its global public beta test. Apply to become your first digital employee!

Application portal: qoder.com/qoderwake

Original link:I'll have Alibaba's digital employees live in computers and see if they can actually get the job done.