ColdMailr AI：我打造了一個無需提示詞的求職主動聯絡電郵生成器

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built ?

ColdMailr AI is a zero-prompt cold email generator for job seekers. You fill in three fields (target company, role, and your one core achievement), click a button, and get a ready-to-send cold email for a hiring manager.

Who would pay for it ?
Students, freshers, and career switchers who know cold outreach works but freeze at the blank page. Career coaches, bootcamps, and college placement cells could also use it with their cohorts.

The problem: getting a good email out of a general chatbot means writing a prompt first (“Act as a career coach, keep it under 100 words, don’t invent facts...”), and the result changes every time. Many people either don’t know how to prompt well or give up after one mediocre draft.

How it’s different from ChatGPT , Claude or other LLM chat tools:

In Chat LLM

• You write “act as a recruiter / career coach...” every time.
• Output format changes on every run.
• May invent numbers, company news or achievements
• One answer, take it or leave it
• You judge whether it’s good

BUT

In ColdMailr AI

• The role, rules and tone are built in. You only enter your facts
• Same structure every time: subject line, greeting, 3 short paragraphs, one low-pressure ask
• A validator checks every draft and rejects invented numbers and fake company claims
• The model writes 3 candidates, and the app picks the cleanest one
• Banned clichés (“passionate”, “I hope this finds you well”) and length limits are enforced in code

To be fair, a skilled prompter can get a similar email from any chat model. ColdMailr’s value is packaging that expertise so nobody has to prompt at all, and checking the output before the user sees it.

Demo

🔗 Live: https://coldmailr.onrender.com/

(It runs on a free Render instance, so the first load after idle time can take up to a minute while the server wakes up.)

Code

{https://github.com/Abbas7120/ColdMailR}

How I Built It ?
Model: Qwen3-8B, an open-weight model, served through Tinker (Thinking Machines) for sampling.
Backend: Node.js + Express serves the UI and API. It passes each request to a Python script that talks to Tinker.
Prompt design: a strict system prompt (the sender is always the candidate, use only the given facts, copy numbers exactly) plus four few-shot examples from different fields (engineering, marketing, a fresher with no numbers, sales), so it works for any role.
Quality layer: the model generates 3 candidate emails per request. A Python validator checks each for format, length, company mention, banned phrases and any number that wasn’t in the user’s input. The best passing candidate is returned.
Honest failures: if generation fails, the user sees a clear error. The app never shows a fake template as if it were AI output.
UX: a staged progress bar (“Matching tone to the role...”, “Checking quality and facts...”) so the wait feels purposeful.
Deployment: Render (Node web service with a Python virtual environment).

Why Does Open Innovation Matter?

Cost and control: with an open-weight model, I can choose the model, swap it, or later fine-tune it on good cold emails. I’m not locked to one vendor’s pricing, rate limits or policy changes.

Fine-tuning: a closed chat API gives me a prompt box. An open model on Tinker gives me a path to train a model that writes cold emails specifically, which is the real moat for a product like this.

Trust: the whole pipeline, including the prompt and the validator, is open on GitHub, so users and contributors can inspect exactly how emails are produced and add rules.

Accessibility: students can fork it, run it, and improve it without needing a paid closed API.

Prize Categories

Best Use of Render:
Render is the production runtime for the whole app. One Render web service runs the Node/Express server, the UI, and the Python AI pipeline: prompt building, tokenization, Tinker sampling and output validation. The live demo at https://coldmailr.onrender.com/ is that service.
No Docker, a plain Render build. The Node runtime’s build command creates a Python virtual environment, installs the Python dependencies, and pre-downloads the Qwen tokenizer, so users don’t wait on a download. The start command is just node server.js.
Secrets stay out of the repo. The Tinker API key lives in Render’s environment variables, and .env and .venv are git-ignored.
Deploy on push. Every push to main redeploys, so contributors’ pull requests ship quickly.
Mixed-language stack on one service , Render runs Node and Python side by side without separate infrastructure, which keeps hosting simple for a solo builder.

Best Use of Tinker:
Tinker is the only model backend. Every email comes from Qwen3-8B (open-weight), sampled through Tinker’s ServiceClient and SamplingClient. There is no closed API anywhere in the pipeline.
Best-of-N sampling in one call. Each request asks Tinker for 3 candidate emails with num_samples=3. A validator then scores them for format, length, company mention, cliché phrases and invented numbers, and returns the cleanest one. Tinker’s batched sampling makes this cheap enough to run on every click.
Prompt control at the token level. I build the Qwen chat template myself (system rules plus four few-shot examples), tokenize it locally, and pass token IDs to Tinker. This gives exact control over stop tokens and the empty-think block, which a hosted chat endpoint wouldn’t expose.
Reliability, not just generation. Tinker supplies the candidates and my validation layer decides what the user sees. The result is that the app never shows invented numbers or fake company claims.
Built to grow into fine-tuning. The validator’s accepted outputs are exactly the training data needed to fine-tune the model on Tinker for cold emails specifically. That is the next step on the roadmap.