跪拜 Guibai
← Back to the summary

DeepSeek Harness After a Week: 8 Pitfalls and a Quick-Reference Checklist

I got my hands on DeepSeek Harness on the first day it was open-sourced and wrote an initial impressions piece back then. My conclusion was: the gap between it and Claude Code is bigger than expected. A week later, I haven't changed that conclusion — but I've compiled the pitfalls I ran into, plus the ones the community keeps asking about every day, into a quick-reference checklist. Read this before installing; it'll save you half a day.

For those who haven't kept up, a one-line background: DSH is an Agent coding framework open-sourced by DeepSeek, built around the idea that "everything is a plugin." It racked up 95,000 stars in two days. The hype is real, and so is the barrier to entry.

Pitfall 1: Environment not set up correctly, stuck at the first step

The most common turn-off scenario: after installation, it won't run, throwing all kinds of errors. Many people close the page right here.

I also stumbled on this the first day. Later I found that 90% of cases fall into two categories:

  1. Wrong Node version. DSH has runtime version requirements. If the version is too low, dependencies simply won't install. Run this first:
// Check the environment before installing; don't wait for errors to look it up
console.log(process.version); // Upgrade first if it's below the official requirement
  1. The first startup is absurdly slow. It needs to initialize a bunch of things. Waiting a few minutes for the first run is normal — it's not frozen. I thought it was dead at the time and force-killed it twice before I realized.

One-line solution: Check the version requirements before installing, give the first startup plenty of patience, and if all else fails, use a community-made one-click launcher.

Pitfall 2: Connecting models carelessly burns through tokens painfully

DSH itself is a framework; you need to connect the model yourself. Many people's second pitfall is: immediately plugging in the most expensive model, running a few tasks, glancing at the bill, and instantly cooling off.

My current approach is tiered usage:

Another easily overlooked point: The access configuration methods for different models aren't exactly the same. Filling the key in the wrong place, or having an extra slash in the base_url, will throw errors where you can't see the cause. After configuration, run a minimal task as a trial first; don't jump straight into real requirements.

// My habit: After configuration, run a smoke test first to confirm the pipeline works before doing real work
// A minimal verification task: ask it to read a file and summarize it
// If it returns normally, it means the key, base_url, and model name are all correct

One-line solution: Run a smoke test with a lightweight model first. Once the pipeline works, tier your tasks. Your wallet will thank you.

Pitfall 3: Dumping the entire project in guarantees a botched output

This is where I see the community mess up the most, and I've messed up here myself.

Throwing a legacy project with tens of thousands of lines entirely at DSH and saying "help me optimize this" — it will either give you a pile of correct-sounding nonsense, or fix A and break B. The problem isn't with it; it's that you didn't break down the task.

The output quality of Agent-type tools is basically equal to the quality of your task decomposition. For the same task of modifying a list page, the difference between two feeding methods:

Botched feeding method:

This project is a bit messy; help me refactor it.

Usable feeding method:

Only modify the src/pages/list directory: extract the filtering logic from the component, make it an independent hook, keep the existing API unchanged, and don't touch the style files.

The smaller the scope and the clearer the constraints, the more accurate it is. It's not that it can't do big jobs; it's that big jobs need to be cut into small pieces to feed it.

Pitfall 4: The plugin ecosystem is lively, but don't install everything

"Everything is a plugin" is DSH's most imaginative aspect, and community plugins have been proliferating wildly these past two days. But honestly, the quality is uneven — some plugins solve real problems, while others are still at the conceptual stage, with more documentation than functionality.

I now have just three criteria for choosing plugins:

  1. Check maintenance frequency: Only consider those updated within the last week.
  2. Check the issues section: If people are raising questions and the author responds, it means the project is alive.
  3. Fit your own scenario: I'm a front-end developer, so I prioritize installing things related to component generation and page restoration. I hold off on all the trendy "all-in-one plugins" for now.

There's also a hidden cost to installing too many plugins: they might participate in every task, making the output unpredictable. Better too few than too many; finish using one before considering the next.

Pitfall 5: Misaligned expectations — it's not a drop-in replacement for Claude Code

This last pitfall isn't written on the surface, but it's the most fatal.

Many people install DSH with the mindset of "finding a free/open-source Claude Code replacement." Using it with that expectation will likely lead to disappointment — this is why my initial impressions said "the gap is bigger than expected."

But with a different expectation, it has its own ecological niche:

Requirement More Suitable Choice
Pursuing the strongest single-point effect, don't want to tinker Mature closed-source tools like Claude Code
Want open-source control, want to install your own plugin extensions DSH
Data-sensitive, want to run locally/privatized DSH
Team wants to build its own workflow on top of it DSH

One sentence: It's a "controllable open-source foundation," not a "money-saving replacement." Once expectations are right, the experience improves.

Pitfall Avoidance Quick-Reference Checklist (Suggest Bookmarking)

# Symptom Most Likely Cause One-Line Solution
1 Can't install / dependency errors Node version mismatch Check official version requirements first, then install
2 First startup seems "frozen" Normal initialization takes time Wait a few minutes, don't force-kill
3 Nameless errors after configuration key/base_url filled incorrectly Smoke test with a minimal task
4 Token consumption is frightening Heavy model doing light work Tier tasks; use lightweight models for light work
5 Output is "correct nonsense" Task too large, not broken down Cut into small pieces by directory/module to feed
6 Fixing A breaks B No constraints given Explicitly state "what not to touch"
7 Slower/messier after installing plugins Too many plugins interfering with each other Better too few than too many; add one by one
8 Feeling it's "not as good as Claude Code" Misaligned expectations Use it as an open-source foundation, not a replacement

Final Words

The reason DSH is this hot is essentially that developers want an Agent foundation they can control themselves — choose their own plugins, connect their own models, manage their own data. It's not perfect yet, and there are plenty of pitfalls, but the direction hits the mark.

My advice is simple: If you're already using Claude Code/Codex for daily work, don't rush to migrate; but if you want a controllable, extensible, privatizable option, DSH is worth spending an evening getting familiar with the pitfalls.

What pitfalls did you encounter when installing DSH? Or is there a specific community plugin you'd like me to test individually? Let's chat in the comments, and the next article will test the one with the most requests.