VSCode Plugin TikZ Preview for Local Rendering and Preview

Editor’s Note · AI Serial Entrepreneur Perspective (Summary generated by AI; views belong to the original author; no need to read the full article)

Built a VSCode plugin for TikZ Preview that compiles locally instead of using the web version, solving geometry/function graph rendering issues. Total time: 5 hours. Cost: 3.05 CNY (B-tier third-party billing): Pro model used 130k tokens for planning, Flash model used 48k tokens for coding, cache hit rate 99.7%. Key takeaway: Using Pro for planning and Flash for coding is the core money-saving strategy, but continuing sessions multiplies costs, so manually verify auto-published code.

• Use Pro for planning, switch to Flash for coding
• Continuing conversations is expensive; open new windows for new tasks
• Auto-publish skills require human code review
• Codex next-day review fills self-test blind spots

1. What Opportunity Is This

This is an opportunity to optimize developer tools in a vertical niche. Target users are bloggers, researchers, and programmers who use VSCode for LaTeX/TikZ drawing. The pain point is that TikZ code can’t be previewed in real time within VSCode, requiring frequent switching to external tools. The solution is to develop a VSCode plugin that calls the local TeX engine and integrates PDF.js preview, building reputation through free open-source release, with potential monetization through advanced features like cloud rendering or collaboration later.

2. Independent Assessment

Worth building as a “portfolio piece” or “traffic entry point,” but direct monetization is difficult. Key reasons: although the TikZ user base is precise, it’s limited in scale, and existing open-source solutions (like KtikZ) already meet basic needs. The differentiation lies in the lightweight experience from “no WASM engine installation required” and “support for LuaLaTeX/Shell Escape.” Editor’s perspective: the value of this case isn’t selling the plugin, but validating the extremely low cost and short cycle of “AI-assisted development of vertical micro-tools,” making it a typical low-cost trial-and-error model.

3. Cold Start Path

First validation step: don’t write code from scratch; instead, find negative reviews of existing plugins (like KtikZ) and confirm whether users truly care about “local rendering” vs. “online rendering.” Cost scale: extremely low, mainly API call fees (actual full process cost only 3.05 CNY), primary cost is time (about 5 hours). Cycle: from requirement refinement to code release, MVP validation can be completed in 1-2 days. If user feedback is strong, proceed with open-source release and community building.

4. Biggest Risks and Pitfalls to Avoid

The biggest risk is “hidden bugs caused by AI hallucinations.” In the original case, AI-generated initial code couldn’t render PDFs correctly and didn’t cover the extreme scenario of “quick file switching,” leaving old render results behind. Mitigation: must introduce an independent Code Review step; don’t rely on the same AI session’s self-check. Another pitfall is uncontrolled token costs—frequent use of “resume” causes non-cached input spikes, so strictly control session context and avoid irrelevant multi-turn conversations polluting context.

5. Case Review (How Others Did It)

• Technology Selection Decision: Abandoned mainstream WebAssembly solutions (texjsx/BusyTeX) due to large bundle sizes (200-340MB) and lack of Shell Escape support; ultimately chose to mimic KtikZ by calling the local TeX environment, ensuring full compatibility with LuaLaTeX and complex packages (tkz-elements, tkz-fct).
• Workflow Design: Used a “superpower skill” to refine requirements first. Before coding, AI improved structure through Q&A, resolving many potential logic gaps and reducing subsequent Debug rounds.
• Model Layering Strategy: High-tier models (deepseek-v4-pro) used for planning and spec writing; low-cost models (deepseek-v4-flash) for actual code writing. Pro model cache hit rate measured at 99.7%, Flash handled extensive execution details, keeping total cost under 3 CNY.
• Next-Day Code Review: Used another model (Codex/gpt-5.5) to review the previous day’s code, successfully catching the critical bug “rendering errors caused by quick file switching.” Easily overlooked in daily debugging, cross-model review filled single-model blind spots.
• Automated Release: Created a dedicated Skill to handle version releases; inputting commands auto-updates Changelog, README, and version numbers. But must manually verify auto-generated Skill files to prevent AI from incorrectly modifying core logic.
• Avoiding Cost Traps: Avoid frequent use of the `resume` function. Testing showed three consecutive resumes caused unmatched input tokens to surge 4x; a day of only updating docs cost nearly as much as the first day of development combined. Recommend new tasks get new sessions, or periodically compress context.

6. Dual-Track Executability

Cross-border: viable. Such developer tool plugins have huge overseas market demand; can publish to Marketplace for exposure and explore SaaS-based hosted rendering monetization. Domestic: viable. Although the LaTeX user base is small, spreading as an “AI programming case” through tech media can attract developer attention and convert into course or consulting business.

Original article · Like Fish Drinking Water: Read original →

Related tool recommendation (promoted): GLM Coding Plan — AI Coding Powered by G…