Why Independent Developers Fail at Floor Plan Recognition with AI (and How to Get It Right)

Independent developers building real estate agent mini-programs have almost all had the same idea: a user uploads a floor plan, and AI automatically interprets it—how many bedrooms and living rooms, which direction it faces, whether the circulation is reasonable, and roughly what the efficiency ratio is. It sounds easy, but anyone who has actually tried knows this road is littered with pitfalls. This article first covers the failure cases, then how to avoid them.

1. Three Typical Failure Patterns

Death #1: Throwing the image directly at a general-purpose vision model. The developer connects a multimodal model's API, sends the original floor plan image over, and asks it to output structured JSON. The result: hand-drawn sketches, rendered images, and promotional images with furniture and decor get wildly different interpretation quality. For the same image, if the phrasing of the question changes slightly, the output fields don't match, and the frontend parsing crashes outright. A week after launch, there were more customer service tickets than users.

Death #2: Solving every problem with one giant prompt. To make the output stable, some people cram every requirement—identifying rooms, calculating areas, evaluating circulation, finding flaws, giving suggestions—into one massive prompt. The result: every feature works 60% correctly, and none works 90% correctly. Worse, changing any single line of the prompt causes other features' outputs to drift, making regression testing essentially a matter of luck.

Death #3: Writing a set of adapter code for each new model. The team finds that a single model handles certain floor plan styles poorly, so they connect a second model, then a third. Each model has different SDKs, authentication methods, parameter names, and error codes, and soon the codebase contains three nearly copy-pasted adapter layers. One model quietly adjusts its rate limiting policy, random timeouts start occurring in production, and it takes a whole night of debugging to discover that a vendor had reduced the concurrency quota.

The common thread in these three pitfalls: treating AI as "one smart function" rather than a production pipeline that needs to be broken into steps, monitored, and made replaceable.

2. The Right Architecture: Task Decomposition + Unified Gateway

The correct approach is to break "floor plan interpretation" into a pipeline where each step does only one thing:

1. Preprocessing and classification: Determine the image type (hand-drawn / rendered / CAD export / with decor). Politely reject unqualified images instead of wasting tokens;
2. Structured recognition: Let the model only identify room composition, labeled text, and dimension information, outputting strict JSON Schema;
3. Metric calculation: Calculations like efficiency ratio and width-to-depth ratio should be done in code, not by the model—LLM arithmetic is one of the least reliable links in the chain;
4. Commentary generation: Feed the structured data from the previous step back in, and let the model handle only "speaking human language," producing buyer-oriented interpretation copy.

The key engineering decision: route all model calls through a single AI API gateway instead of connecting directly to each provider. Why does this reduce maintenance costs?

• Authentication and key management done once. You don't need keys from multiple vendors scattered throughout your code, dramatically reducing both leakage risk and rotation costs;
• One unified request/response format. Switching underlying models or running A/B comparisons only requires changing gateway configuration with zero changes to business code—this directly eliminates the copy-pasted adapter layers of "Death #3";
• Unified logging, billing, and error codes. Which step is burning money, which model has a high error rate, what the timeout rate is—you can see it all on one dashboard instead of digging through three vendors' wildly different backends;
• Centralized rate limiting and fallback. If one vendor gets flaky, the gateway automatically switches to a backup model, completely invisible to users.

3. Key Implementation Steps

1. Build a test set with 10–20 floor plans in different styles (draw them yourself or use copyright-free materials—do not scrape real listing data, which carries privacy and copyright risks). Get the structured recognition step working first, and only proceed once accuracy meets the bar;
2. Use JSON Schema to constrain model output; automatically retry once on parse failure, and if it still fails, fall back to a "manual annotation" entry point;
3. Connect to a unified AI gateway and configure different model routes for the recognition and commentary steps—use a strong vision model for recognition and a cost-effective model for commentary;
4. Add output guardrails before launch: filter numbers that models tend to "make up," such as areas and prices—any calculated number must always come from code-computed results.

A minimal viable flow checklist:

用户上传图片
  → [网关路由] 图片分类模型：判断是否为有效户型图
      ├─ 无效 → 返回引导话术，流程结束
      └─ 有效 ↓
  → [网关路由] 视觉模型：结构化识别（JSON Schema 校验）
      ├─ 校验失败 → 重试1次 → 仍失败 → 转人工标注
      └─ 成功 ↓
  → 业务代码：计算得房率、开间进深比等指标
  → [网关路由] 文本模型：生成买家视角解读文案
  → 护栏过滤（数字替换为计算值、敏感词检查）
  → 返回前端渲染

4. Practical Advice for Small Teams

Start your MVP with the most core step of the pipeline (structured recognition), and only add the commentary feature once it's working. Throughout this process, the biggest dividend of a unified gateway isn't saving a few lines of code—it's giving you the confidence to switch models. With models iterating this fast, reducing the cost of "switching models" to changing one line of configuration is what keeps your product on the best cost-performance tier.

If you're ready to get started, you can register an account first at https://api.thistoken.ai/register, bring multiple models into one unified entry point, and get the foundation right from step one.

---

Tired of juggling provider integrations? Register at https://api.thistoken.ai/register and call every model through one base_url.