跪拜 Guibai
← All articles
Frontend · Artificial Intelligence · Agent

Yanhuo Shijian Turns Meal Planning Into a Structured, Adjustable Workflow

By 雨夜寻晴天 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Most AI cooking tools dump a block of text and call it a meal plan. Yanhuo Shijian treats the output as mutable, structured data — a menu, a shopping list, a recipe library — that can be partially edited, exported, and reused, which is closer to how people actually cook across a week.

Summary

Yanhuo Shijian (Hearth & Mealtime) tackles the full meal-decision chain: deciding what to eat, generating a menu, adjusting dishes, viewing recipes, and organizing a shopping list. Users set parameters like headcount, days, meals per day, dietary restrictions, budget, and available cooking time. The system returns a structured menu where any single dish can be swapped with a reason — no need to scrap the whole plan. A separate “What to Eat Today” mode solves a single meal from ingredients already on hand, and a “What’s Nearby” page searches real restaurant locations when cooking isn’t an option.

Menus feed into an auto-generated, categorized grocery list that can be marked off, exported as CSV or image, and printed. Dishes can be saved to a personal recipe library, and feedback like “liked” or “don’t want again” informs future generations. The homepage functions as a workbench rather than a landing page, surfacing the current menu and quick actions.

Privacy is handled by keeping user-supplied API keys in the browser’s local storage; they are never written to the Supabase database. The project is a free public-welfare demo, with source code available on GitHub.

Takeaways
A structured menu is generated from headcount, days, meals per day, taste preferences, dietary restrictions, budget, and cooking time.
Individual dishes can be swapped with a reason (dislike, too complex, too expensive, recently eaten) without regenerating the full plan.
A “What to Eat Today” mode suggests meals from ingredients already at home, available time, and energy level.
A “What’s Nearby” page searches real restaurant locations by address or GPS, filtered by distance, budget, and rating.
Menus auto-generate a categorized grocery list that can be checked off, exported as CSV or image, and printed.
Dishes can be saved to a personal recipe library; feedback like “liked” or “don’t want again” feeds into future menu generation.
User-supplied model and map API keys are stored only in the browser’s localStorage and never sent to the backend database.
The project is open-source (GitHub) and currently runs as a free public-welfare demo.
Conclusions

Treating a meal plan as mutable structured data — not a static text block — is the core design decision that separates this from most AI recipe generators. Partial edits, categorized exports, and feedback loops make the output actionable across multiple days.

The inclusion of a restaurant-search fallback acknowledges that home cooking isn’t always the right answer; a meal-planning tool that ignores takeout and dining out is planning for an idealized week that rarely happens.

Storing API keys exclusively in the browser and never on the server is a practical privacy stance for a demo, but it also means the tool’s AI features break silently if the user clears local storage or switches devices — a trade-off worth documenting upfront.

Concepts & terms
Structured menu generation
Instead of returning freeform text, the AI outputs a data structure with distinct fields for dishes, ingredients, steps, and metadata, allowing partial edits, exports, and downstream processing like shopping-list creation.
Local-only API key storage
User-provided keys for LLM and map services are persisted in the browser’s localStorage and sent only with each request; the server never stores them, reducing the risk of credential leaks from a backend breach.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗