我开发了一个一键式内联 AI 重写工具（以及它遇到的问题）

I’ve been dogfooding a small writing helper I built called Rephrazo, and I thought it might be useful to share some implementation details and mistakes so far.<p>The idea is simple:<p>* highlight text where you’re writing * press a hotkey * get an AI paraphrase in a small popup * insert it back with one click<p>The goal is to remove the “copy - open AI tool - paste - rewrite - paste back” loop for small edits.<p>This post is about how I wired it up, what worked technically, and what didn’t.<p>### Constraints I designed for<p>From the beginning I tried to design under a few constraints:<p>* One hotkey → one main action * Stay inside the current app (no browser, no big side panel) * Minimal UI: single suggestion, one click to insert * Latency “feels instant” or it doesn’t get used<p>Whenever I broke these constraints (added extra choices, prompts, etc.), usage dropped in dogfooding.<p>### High-level architecture<p>Rough breakdown:<p>* Desktop client that:<p><pre><code> * listens for a global hotkey * grabs the current text selection * sends it to an API * displays the returned paraphrase in a small overlay near the selection</code></pre> * Backend API that:<p><pre><code> * accepts the selected text + some minimal context * calls an LLM * applies a fixed prompt (“make this clearer, keep tone&#x2F;voice as much as possible”) * returns a single suggestion (no multi-choice for now) </code></pre> No fancy infra yet, just trying to keep the path from “key press” to “returned text” as short as possible.<p>### Text capture and insertion<p>The surprisingly tricky part wasn’t the LLM, it was:<p>* reliably capturing the selected text * not messing up the user’s clipboard * inserting the rewritten text back without breaking formatting<p>The first version literally abused the clipboard:<p>* save clipboard * copy selection * send to backend * replace selection by pasting the result * restore clipboard<p>This worked… until it didn’t:<p>* some apps ignore simulated keypresses * sometimes the clipboard got overwritten by other things in between * it felt fragile and “hacky”<p>I’m slowly moving toward more app-aware integrations (where possible) while still keeping a generic fallback.<p>### Latency and UX<p>Latency matters more than I expected. Rough buckets:<p>* &lt; 500 ms → feels instant, people are happy * 1–2 seconds → acceptable if the suggestion is clearly better * &gt; 3 seconds → people regret pressing the hotkey and use it less<p>A few tiny UX things helped:<p>* show a small “loading” state immediately near the selection * render the popup instantly (skeleton state), then fill it when the response arrives * on failure, show a short, honest message instead of silently doing nothing<p>If you’re building AI tools, this won’t surprise you, but it’s different when you watch your own users hesitate after a few slow responses.<p>### Things that went wrong<p>* I overbuilt customization early:<p><pre><code> * tone dropdowns * multiple modes (“shorter”, “longer”, “more formal”) * extra toggles People ignored them, or got decision fatigue. </code></pre> * I underestimated how many edge cases there are with selection&#x2F;insertion across different apps.<p>* I didn’t log enough in the first builds, so I had to retrofit telemetry to understand actual usage.<p>If you’re curious, the current early version is here: [https:&#x2F;&#x2F;rephrazo-ai.app&#x2F;](https:&#x2F;&#x2F;rephrazo-ai.app&#x2F;)