Meldr 为何删掉“Generate draft”按钮：一个写作工具的默认设计反思

Here is the line that changed my project:

Next · Generate draft

That's a label on a button in a terminal UI. It appeared right after you approved an editorial brief in Meldr, the writing workflow tool I'm building. I deleted it, and I want to explain why, because it ended up changing more than the interface.

Where Meldr came from

Meldr was born out of selfishness: I wanted to streamline article writing for my own workflow. Writing a technical article involves a lot of work around the writing. Before I start, I'm checking whether someone has covered the idea and what evidence I actually have. Afterward, I'm verifying claims. In practice that meant 15 browser tabs, a few AI conversations, my editor, and scattered notes. The fragmentation was the slow part, not the writing.

So I'm building it to meld those steps into one terminal workflow:

research → angle → editorial brief → approved outline → write → review → publish

Everything between steps lives in plain Markdown files, and two points are human decisions: approving the brief, and accepting or rejecting review proposals.

What the button was saying

Approving a brief means "I agree with this direction." The button turned that into "now generate all the prose." One keystroke took you from an outline to something that looked like a finished article.

Something about that didn't sit right with me. If other writers were going to use Meldr, I had to ask myself: would this encourage fully AI-written articles, even slop?

Technical posts are useful when they carry something only the author has: the real bug, the tradeoff that was harder than expected, the thing that surprised them. A model working from an outline has none of that. It fills the gaps with plausible, confident, interchangeable text, which is the thing people mean by AI slop.

To be clear, I'm not saying nobody should draft with AI. That's each writer's call. My decision was narrower: I didn't want to build the tool whose recommended path leads there. Defaults tell people what a tool expects from them, so I removed draft generation entirely instead of tucking it behind a setting.

After you approve a brief now, the next action is to open working.md and write.

What Meldr does instead

Meldr helps with the work around the writing, and each piece is built so the model proposes and the author decides.

Your article is yours. Without a generated draft, ownership is simple:

article/
├── brief.md             direction, audience, thesis, scope, outline
├── working.md           your article
├── editorial-notes.md   author placeholders, open verification work
└── revisions/           review proposals, section suggestions, claim reports

Review needs real prose. If working.md is just a title, "review my draft" could quietly become "write one for me." Meldr refuses to review a title-only file. Once there's text, it looks at structure, voice, and claims that sound more certain than the evidence supports, and everything comes back as a proposal you can accept, edit, or ignore.

Section help is on request. For a section I'm stuck on, Meldr asks what I want:

What would you like to do?

› I'll write this section
  Suggest talking points
  Help me start it
  Skip for now

The model is called only when I ask, and the result is a proposal that never touches working.md unless I accept it.

Proposals can go stale. If Meldr reviews your article and you then rewrite three paragraphs, accepting the old proposal would apply it to a version that no longer exists. Meldr records the source article's SHA-256 digest when it creates a revision and checks it again on accept:

proposal source ≠ current article  →  stale, refuse to apply

Gaps stay visibly yours. When a model has no real example, it will invent one. So Meldr leaves author-owned gaps unresolved instead of papering over them:

[AUTHOR: Add the real debugging problem that caused you to build this.]

Claims get the same treatment. Meldr flags statements that deserve verification and says what evidence would help, but it doesn't declare them true. Claim reports stay separate from revisions, so uncertainty can't be accepted into verified prose. It becomes a research list.

The tradeoff

Meldr is slower than a tool that hands you a draft in a minute, and that's deliberate. It's also still in progress, so I may find that some of these choices need adjusting. But the parts of writing I wanted help with were the research, the structure, and the checking, and none of those needed the tool to write the article for me.

One note on privacy: Meldr is local-first, so projects live on your machine and stay inspectable, but when you ask for model help, the relevant context goes to whichever provider you configure. There's no autonomous publishing step either.

What I took from it

I expected the lesson to be about AI. It turned out to be about defaults. One recommended button shaped the file layout, the review logic, and how I thought about who owns what in the tool.

If you build tools with AI in the loop, has a default ever surprised you like this? And if you use AI while writing technical posts, where do you want the help: research, structure, proofreading, claim checking, or getting through one hard section?