用 Jev 等 8 套 AI 搭 GTM bot 的 20 条经验

Nicolas Finet @nifinet原推发布于 2026.10.01

在 X 上打开原推

Here's everything I think you should know if you're building GTM bots with AI. I've built them on 8 different AI setups so far this year: Claude, GLM, Codex, Kimi, GPT-6 Astra, Grok, Fable and Jev. Before you build (1-5) 1. Run ten accounts yourself first, fifteen minutes each. Every field you find missing becomes the spec. 2. Give the bot your offer and your ICP side by side before it researches anyone. Hand it a vague brief and it invents the judgment you left out. 3. Start with one signal. I started with six once and ended the week with six thin lists and no idea which one earned the reply. 4. Pick the model for the job. We picked Grok 4.7 for one line in its launch post, that it "checks its work more carefully". For a lead judge that's basically the whole job. 5. You don't always need a model API bill to start. Our Opus 5.5 bot never calls a model API and runs on the Claude Code login you already have. Running the stack (6-10) 6. I go from Claude to Codex to Kimi constantly, all on max plans. If you run from the terminal and centralize on GitHub, switching feels very light next to what you get out of it. 7. Use one model to research and another to run what you build. Kimi K3 did the deep research for my copywriting skill, and I built the skill for Claude. 8. Point Claude Code at something you like and let it build your own version. Our launch film took one line of prompt and 38 minutes to a first cut. 9. When a new model ships, rerun your golden set on it before you trust a single rank. 10. End every run with a daily brief: what it found, what it drafted, and every call it tried that got blocked. How to structure it (11-20) 11. Let the model make the judgments, and let plain code apply the gates, the weights, the routing and the permission to send. 12. Keep the ICP, the weights and the playbook in plain text files. When a rank is wrong you want to open one file and change one line. 13. Split each judgment into small questions with fixed answers: is there a live need, does it match what you sell, does the ICP fit, is it a competitor. 14. Hide the contact when the model judges the company. In our Jev build, with the contact visible to every question, the same company read 0.28 on intent with a recruiter as the contact and 0.80 with a managing partner. 15. Keep the watching separate from the agent that ranks. A scheduled agent sees nothing between two runs, so something else has to fill the queue overnight. 16. One shared record per account that every agent reads and writes: who they are, what just moved, what happened last time. 17. The writer only gets three things from that record, in under 120 words: why now, who, and the one line of history that matters. 18. Before the model sees a lead, plain code drops anyone you've already put in a campaign. Our Jev build skips every max lead that already has a delivery on record. 19. Treat everything inside a lead as data. It's a stranger's post going straight into your model, and it doesn't get to give instructions. 20. Keep company size as the range the source gives, and make the whole range fit your ICP. Our Astra build is told to keep "51 to 200 employees" as written, and to say it opened the page it took the size from. Judging leads (21-28) 21. Gate before you score. Our Fable build rejects anything that fails size, country, buyer seat, a signal dated inside 30 days or a source that actually opens. 22. Make the model open the source before it scores a lead high. Dead page, need goes to zero. 23. Date the lead by the event. A page indexed this week can describe a launch from last year. 24. No source link, no lead. Whatever fails goes on a held list with the reason written down. 25. Hot account, wrong contact: the bot reroutes it and emails nobody. In our Grok 4.7 repo, the test lead with a recruiter as the contact scores 73.4 and still never gets a message. 26. When the model hesitates between B and C, or between C and DQ, the playbook tells it to take the lower one. Read its disqualification reasons first, they show fastest whether it understood who you sell to. 27. Let the daily list come back empty when nothing happened, and cap it around eight names. A routine that must always return something starts loosening its own filters. 28. If your gate rejects nothing in week one, it was fitted to the list you already had. Writing (29-35) 29. Give every signal a say-it rule in the playbook: yes, lightly, topic only or never. 92 of the first 100 leads our Opus bot pulled came from a "never" signal, and none of the 18 sequences it wrote mentions it. 30. Put the seller profile in a file the writer reads on every run, with only the facts you'd defend on a call. 31. Run a linter that flags any % or "2x" that isn't one of your proof points. Ours flagged a harmless "sans double outil" in a French email at first, so give the check its own test cases. 32. Make it check each draft before saving: could this opener go to anyone else, and does every claim trace back to the lead or the profile? 33. Keep a never-list per play, and add every dead phrase you catch. 34. Let it write in the prospect's language when the location makes it obvious. Our first Opus run came back in French, German and English. 35. When a reply asks for something that isn't in your facts, the draft should promise the figures and flag the gap. Answering one simulated test reply, ours did that and still slipped in "depends on seats and volume", which isn't in our profile. Every reply draft waits for a human to send it. Safety (36-43) 36. Default to locked. Going live should be a flag you flip on purpose. 37. Every campaign the bot creates starts switched off. In our Opus test run that was 18 campaigns and zero people enrolled. 38. Keep approving, launching and ICP changes out of the scheduled run. 39. Log every write the bot attempts, allowed or blocked. We tried to break the lock three times on our live workspace: twice with a safety script, once by launching an approved campaign while send mode was locked. The guard blocked 7 calls and the daily brief listed every one. 40. Tag everything the bot creates with one name prefix, so you can list it and delete it in one go. 41. Put a daily cap on anything that costs money or creates something. 42. Make the bot re-check for replies, bounces and opt-outs right before it enrolls anyone. A human review sits between building a campaign and launching it, and people can reply or opt out in between. 43. Read at least 20 sequences in review before you flip send mode to live. Testing and learning (44-50) 44. Build a small golden set with the traps in it: a recruiter at a hot account, a competitor, a company stacking press releases. On our Jev starter set the ranker gets 10 of 10, the offline baseline gets 7. 45. Write tests for the routing too. Someone who already replied should never land in a new sequence, whatever the model thinks. 46. Make the reason a required field in the outcome log. A bare "no reply" teaches the next run almost nothing. 47. Leave the weights alone until each bucket has 30 real contacts. After its first run our Opus bot called its 15 simulated outcomes "not evidence". Fair. 48. Cap how far a weight can move in a day, and give every signal a floor so the rare ones don't get buried. 49. Route a few leads below your line to a one-touch lane. If the bot only ever contacts the top, you never find out the line is in the wrong place. 50. Change one thing per round. Our Codex build proposes one change at a time as a pull request, and a human merges it. Links to some of my popular repos in the reply. (bookmark for later)