Frontend Development on KnightLi Blog

Prompt-Vault: a prompt specification library for testing AI coding ability

Fri, 15 May 2026 09:00:52 +0800

w512/Prompt-Vault is a small but useful prompt repository. It does not collect magic prompts; it organizes executable coding prompts into difficulty levels so they can be used to test LLMs and coding agents.

Project: https://github.com/w512/Prompt-Vault

The repository is small, but the structure is clear: Easy, Medium, and Hard. Each Markdown file is a standalone task. The README also says these prompts are suitable for testing language models or practicing small projects.

Not a prompt scrapbook

Many prompt repositories look large but are hard to evaluate. The titles are attractive, but the prompts lack acceptance criteria.

Prompt-Vault is closer to a specification library. Each task tries to describe:

What app to build
Required features
UI style
Technical constraints
Whether it must run as a single file
Whether dependencies are allowed
Whether data should persist

This is much better for testing models than “make a nice Kanban board”, because it reveals whether the model truly understands requirements.

Easy: basic interaction

Easy/Bubble_Sort_Visualizer.md asks for a single-file index.html that visualizes bubble sort with bars, start/reset buttons, a speed slider, comparison count, and a dark theme.

It tests whether a model can connect algorithm state to UI, control animation timing, handle reset and running states, and keep the code readable.

Easy/ToDo_List.md starts from static HTML and gradually adds task creation, completed state, deletion, counters, Active / Completed stats, and localStorage.

It is a simple task, but it tests whether a model can evolve code step by step instead of dumping a messy implementation.

Medium: state and animation complexity

Medium/Sorting_Visualization.md upgrades the challenge. The same page must support Bubble Sort, Insertion Sort, Selection Sort, Merge Sort, Quick Sort, and Heap Sort.

It also needs algorithm selection, speed and size sliders, reset, start / pause, and a live stats panel.

This catches many failures: an agent may implement one bubble sort animation, but multiple algorithms plus pause/resume and stats often break state management.

Useful checks include:

Does every algorithm really sort?
Does the animation match the algorithm steps?
Can it pause and resume?
Does reset stop old animation loops?
Does changing array size break state?
Are the statistics credible?

Hard: product completeness

Hard/Kanban_Board.md asks for a complete board: default columns, custom columns, double-click rename, delete empty columns, cards with title and description, priority, deadline, drag-and-drop, search, priority filter, localStorage, footer stats, glassmorphism dark theme, and responsive horizontal scrolling.

This tests product completeness, not just one feature.

Hard/Markdown_Editor_Desktop.md asks for a Tauri 2 cross-platform Markdown editor. It includes split editing and preview, sync scrolling, live rendering, preview mode, focus mode, open/save/save-as, unsaved title markers, formatting toolbar, shortcuts, themes, font settings, Vue 3, Pinia, marked.js, prism.js, and Tauri plugins.

This is no longer a simple web prompt. It tests frontend state, Tauri plugins, filesystem permissions, IPC boundaries, and desktop packaging.

Why it is valuable

Prompt-Vault is valuable because it provides reusable evaluation samples.

If you compare models or coding agents, you can run the same prompt repeatedly and observe:

Which model follows constraints
Which model misses fewer features
Which model handles edge cases
Which output is easier to maintain
Which model is better at UI details
Which model is stable under single-file constraints

This is more reliable than “it feels smarter”.

Frontend tasks are especially useful because many failures are not syntax errors. They are missing button states, broken animation, lost persistence, wrong drag targets, or stale statistics.

How to extend it

The repository could become a stronger benchmark by adding acceptance checklists, failure cases, scoring dimensions, reference implementations, and cross-model result records.

For example, a sorting task should include checks such as “rapid Start / Reset clicks must not create multiple animation loops.” A Kanban task should specify what happens when deleting a non-empty column.

These details make the prompt useful for human review and automated agent evaluation.

Suggested use

To test an AI coding tool:

Give one prompt unchanged.
Do not add extra hints.
Run the generated result.
Check features one by one.
Record missing features and bugs.
Give one repair round.
Compare time, token cost, and final code quality.

This is closer to real development than simply checking whether a page appears.

Summary

Prompt-Vault is a lightweight prompt specification library. It is useful for AI coding tests and for frontend practice projects.

It reminds us that a good coding prompt is not just a wish. It should define requirements, constraints, interactions, state, acceptance, and run mode.

If you compare Codex, Claude Code, Cursor, Gemini CLI, or other coding agents, this kind of leveled prompt is worth keeping.

DeepSeek V4 Pro vs GPT-5.5: After Testing Frontend, Writing, and Coding, the Gap Feels Bigger Than Expected

Sat, 25 Apr 2026 11:12:00 +0800

Comparisons between DeepSeek V4 Pro and GPT-5.5 are getting more attention lately. The reason is no longer whether either model is usable. The real question is: when the work lands in frontend development, writing, and coding, which one is better suited to be your main tool?

When people compare models like this, they often start by asking which one is stronger.
But the more useful question is usually different: in a real task, which one is steadier, cheaper to communicate with, and more likely to produce something you can keep building on immediately?

If we simplify the conclusion first, it roughly looks like this:

When you want more balanced output and a more complete productized experience, many people still look at GPT-5.5 first
When you need high-frequency iteration in Chinese, care more about cost, and want fast response cycles, DeepSeek V4 Pro becomes a serious candidate
What really determines the experience is often not the model name itself, but the task type, the prompting approach, and whether you need to keep revising afterward

Let’s break this down through the three most common comparison scenarios.

1. Frontend tasks: the real question is not whether it can build a page, but whether it can keep improving it

Frontend work looks ideal for model comparisons because the result is easy to see.
Can the page run? Does it look good? Is the structure clean? You can judge all of that quickly.

But the real difference usually does not appear in whether the first draft works. It shows up in questions like these:

Is the structure clear enough?
Is the component split natural?
Does changing one part accidentally break another?
Can it keep following the same implementation logic across multiple rounds of instructions?

That is also why many frontend demos that look impressive in the first round do not necessarily stay ahead in real workflows.

If your task is something like:

Quickly generate a runnable page prototype
Draft a landing page idea
Fill in required styles, buttons, cards, forms, and other basic elements

then both models will often get you fairly close, and the difference is more about output style.

But if the task becomes:

Repeatedly revising the UI over multiple rounds
Reading existing code and continuing from there
Balancing component structure, style consistency, and maintainability
Gradually turning a static page into real project code

then what you should watch is no longer “who looks better in round one,” but “who is less likely to drift off by round five.”

So in frontend work, the key comparison is not whether the model can generate a page. It is whether, after you keep adding constraints, it can still maintain stable structure, consistent naming, and manageable modification costs.

2. Writing tasks: the real difference is not how much it writes, but how stable the style stays and how well rewrites go

Writing is another area where people can misjudge models very easily.

A big reason is that first drafts often look fine from both sides.
The structure is complete, the paragraphs are there, and the tone is smooth enough that it is easy to think they are basically similar.

But as soon as you push the task one step further, the differences show up:

Can it accurately understand your intended audience?
Can it switch tone while staying on the same topic?
Does it lose key points when rewriting?
Does it stay stable when compressing, expanding, retitling, or restructuring?

The biggest problem in writing is usually not “it cannot write,” but “it wrote something that still needs a lot of fixing.”

So when comparing DeepSeek V4 Pro and GPT-5.5, the more useful method is not to ask each to write one article. It is to run several rounds like this:

Write the first draft
Rewrite it in a different tone
Compress it into a shorter version
Rework it into something better suited for click-driven headlines or search distribution

If a model can keep the key points intact, the wording stable, and the structure clean through those rounds, then it has much more value in a real writing workflow.

In other words, what writing tasks really measure is not “literary flair,” but revision ability, instruction following, and the feeling of continuous collaboration.

3. Coding tasks: the real gap shows up in long-chain stability

Coding tasks expose a model’s real level more easily than frontend work, because they are not just about generating output. They have to connect with reality.

Very quickly, you run into questions like:

Can it understand an existing project structure?
Can it modify multiple files at once?
Does it introduce new problems after making changes?
Can it keep debugging by following logs and errors?
After several rounds, does it still remember what it already changed?

In this kind of work, what users care about most is usually not whether a single code snippet looks elegant. It is: can this model keep moving the task forward, instead of leaving me to clean up the mess?

So when comparing DeepSeek V4 Pro and GPT-5.5, the most meaningful thing to look at is usually not isolated coding prompts, but a process closer to real work:

Read an existing repository
Find a bug
Modify several related files
Continue fixing based on error messages
Summarize the result clearly at the end

Once the task enters that kind of continuous workflow, context retention, execution habits, explanation quality, and rework rate all matter more than single-turn answer quality.

That is also why many users eventually do not settle on “using only one model forever” for coding. Instead, they switch their main tool depending on the stage of the task.

4. What is really worth comparing is not who wins, but which tasks are more cost-effective to assign to whom

If you put DeepSeek V4 Pro and GPT-5.5 side by side and only try to pick one overall champion, the result is usually an empty conclusion.

That is because real tasks are not one standard exam:

Some are one-off generation
Some are multi-round collaboration
Some are Chinese writing
Some are engineering changes
Some prioritize speed
Some prioritize stability
Some prioritize cost

So the approach that is closer to real usage is usually to divide by task goal:

If you want a more complete overall experience, more mature interaction, and steadier general output, try GPT-5.5 first
If you want high-frequency experimentation in Chinese, fast iteration, and better efficiency for the money, DeepSeek V4 Pro deserves a serious place in your workflow
If the task itself is long-chain, multi-round, and collaborative, do not stop at the first result—look at who stays steadier after five rounds

In other words, the real question is not “who is absolutely stronger,” but this:
for frontend work, writing, and coding, which model feels more like the most practical tool for your current stage?

5. How to run a comparison that actually means something

If you want to test DeepSeek V4 Pro and GPT-5.5 yourself, a more reliable method is usually not to run a single round, but to do something like this:

Give both models the same initial requirement
Keep the same constraints on both sides
Continue asking follow-up questions for three to five rounds
Record output quality, drift frequency, and rework amount
Only then compare speed, cost, and final usability

That kind of test will get you much closer to real work than simply asking who looks more impressive in the first round.

Especially in frontend, writing, and coding, what often determines the actual experience is not the starting line, but who can stay with you and help finish the work.

6. A simple way to remember it

If you just want a practical summary, you can remember it like this:

GPT-5.5: more like a broad, productized, mainstream default workspace
DeepSeek V4 Pro: more like a strong competitor worth bringing into daily workflows in Chinese and in high-frequency trial-and-error work
The real comparison point: not flashy first-round output, but who stays steadier and saves more effort after multiple rounds of revision

So in this kind of comparison, what really matters is never just “who won.” It is this:
for your frontend, writing, and coding tasks, which model makes continuous progress easier, reduces rework, and gives you more stable output?