Pianificatore ciclo calorico zigzag
Trasformi un budget calorico settimanale in giorni alti e bassi alternati: 14000 kcal con uno zigzag del 20% danno giorni alti da 2400 kcal e bassi da 1466,7 kcal, e la settimana somma ancora 14000. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Calorie settimanali
- 14.000
- Zigzag (%)
- 20
- Precisione
- 1
- Media giornaliera (kcal)
- 2000
- Giorno alto (kcal)
- 2400
- Giorno basso (kcal)
- 1466,7
- Numero di giorni alti
- 4
Il ciclo calorico, spesso chiamato dieta a zigzag, mantiene lo stesso budget energetico settimanale alternando giorni a introito più alto e più basso affinché la media resti sull’obiettivo. Coach, sviluppatori di app e persone che monitorano i macro lo usano per facilitare l’aderenza nei giorni sociali, sostenere allenamenti più duri con più carburante ed evitare il deficit giornaliero piatto che risulta restrittivo a ogni pasto. Questo pianificatore di ciclo calorico a zigzag accetta un totale calorico settimanale e una percentuale di zigzag opzionale, quindi costruisce un piano deterministico di sette giorni: i giorni alti restano di una percentuale fissa sopra la media settimanale, i giorni bassi sono risolti in modo che la settimana sommi esattamente il Suo budget, e il motivo alterna dal lunedì alla domenica.
Come si calcola la settimana a zigzag
Parta dal totale calorico settimanale di cui già si fida—mantenimento per sette, un piano di deficit o qualsiasi budget fisso—e divida per sette per ottenere la media giornaliera piatta. La percentuale di zigzag solleva i giorni alti sopra quella media: le calorie alte equivalgono alla media moltiplicata per uno più la percentuale su cento.
Poiché un motivo alternato di sette giorni non può collocare lo stesso numero di giorni alti e bassi, il pianificatore conta quante fessure alte crea il motivo (quattro se la settimana inizia alta, tre se inizia bassa) e risolve le calorie dei giorni bassi in modo che il conteggio alto per le calorie alte più il conteggio basso per le calorie basse eguagli il totale settimanale originale.
Quell’identità mantiene la settimana onesta: non si inventa energia extra nei giorni di festa e non si sottoconsegna il budget nei giorni più calmi. I giorni sono etichettati da lunedì a domenica con kind high o low e una cifra calorica arrotondata alla precisione richiesta; l’ultimo giorno assorbe il residuo di arrotondamento così la somma riportata continua a coincidere con il totale settimanale.
Se la percentuale è così grande che i giorni bassi cadrebbero a zero o sotto, la richiesta è rifiutata invece di restituire un piano con un giorno di digiuno forzato.
Dove un pianificatore di ciclo calorico a zigzag porta valore
I personal trainer e i coach online esportano una settimana a zigzag in modelli di pasti del cliente così la cena del venerdì può essere più alta senza far saltare il deficit settimanale già negoziato. Le app di fitness che già calcolano il TDEE o un deficit lineare possono chiamare questo pianificatore come puro passo successivo: stesse calorie settimanali, target giorno per giorno più ricchi per liste della spesa e notifiche push.
Chi usava fogli di calcolo e ritoccava a mano colonne alte e basse smette di scostarsi dal totale settimanale quando entra l’arrotondamento; l’aggiustamento del giorno residuo tiene bloccata la somma.
Casi d'uso
Piani settimanali per i clienti del coach
Trasformi un budget calorico settimanale fisso in sette target alti e bassi alternati che il cliente può seguire senza superare il totale energetico concordato.
Post-elaborazione nelle app di fitness
Dopo aver calcolato TDEE o un deficit, chiami il pianificatore zigzag per emettere introiti deterministici giorno per giorno per liste della spesa e promemoria.
Domande frequenti
Perché i giorni bassi scendono più di quanto salgono quelli alti?
Perché una settimana che inizia alta ha quattro giorni alti e tre bassi. Con 14000 kcal e uno zigzag del 20%, i giorni alti ricevono 2400 kcal, quindi i tre bassi devono scendere a 1466,7 kcal per rispettare il totale.
Posso iniziare la settimana con un giorno basso?
Sì. Iniziando in basso la settimana ha tre giorni alti e quattro bassi, e il valore dei giorni bassi viene ricalcolato perché i sette giorni sommino esattamente il suo budget.
Perché l'ultimo giorno è leggermente diverso dagli altri giorni alti?
L'ultimo giorno assorbe il resto dell'arrotondamento, così la settimana coincide esattamente con il totale. Nell'esempio da 14000 kcal la domenica mostra 2399,9 kcal invece di 2400.
C'è un limite alla percentuale di zigzag?
Sì. Se la percentuale è così alta che i giorni bassi scenderebbero a zero o sotto, il piano viene respinto invece di imporre un giorno di digiuno forzato. Se la lascia vuota, si usa il 20%.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo stack
curl -X POST https://api.kit.forhosting.com/health/calorie-zigzag \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"weekly_calories":14000}'const res = await fetch("https://api.kit.forhosting.com/health/calorie-zigzag", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"weekly_calories": 14000
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/health/calorie-zigzag",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"weekly_calories": 14000
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/health/calorie-zigzag", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"weekly_calories":14000}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"weekly_calories":14000}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/health/calorie-zigzag", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Esempio di richiesta
{
"weekly_calories": 14000
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "health.calorie_zigzag",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Input non validi o non positivi falliscono con un errore invalid_input chiaro invece di inventare calorie.
Contratto di input, forma della risposta e regole di validazione
La precision opzionale è un intero da zero a sei decimali e ha default uno. Invii un corpo JSON con POST con weekly_calories come numero finito positivo—il budget di sette giorni in chilocalorie. Lo zigzag_percent opzionale ha default venti e deve essere finito e positivo; è la percentuale di elevazione dei giorni alti sopra la media settimanale. L’high_first opzionale ha default true così il giorno uno è alto e la settimana alterna high, low, high, e così via; lo imposti a false per iniziare con un giorno basso. Sono accettati alias di campo per ergonomia: weekly_kcal, week_calories, weekly_total e total_calories mappano al budget settimanale; percent, variation_percent, swing_percent e zigzag_pct all’ampiezza; start_high e begin_high a high_first; decimals e dp a precision. Campi mancanti, valori non finiti, totali settimanali non positivi, percentuali non positive e oscillazioni abbastanza grandi da rendere i giorni bassi non positivi falliscono con invalid_input e non sono fatturati. In caso di successo il corpo riecheggia weekly_calories, zigzag_percent e high_first; riporta average_daily_kcal, high_day_kcal, low_day_kcal, high_day_count e low_day_count; restituisce days come array di sette oggetti con day, label, kind e calories; e include sum_kcal, formula e precision. Esempio: quattordicimila calorie settimanali al venti per cento con high_first true produce una media di duemila, giorni alti a duemilaquattrocento e giorni bassi risolti in modo che quattro alti e tre bassi sommino ancora quattordicimila.
Dove un pianificatore di ciclo calorico a zigzag porta valore
Poiché l’implementazione è pure parse di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello né rete in uscita, e la validazione fallita non consuma saldo. Abbini l’output al Suo split di macro o generatore di pasti se le servono proteine e carboidrati al giorno; questo endpoint pianifica solo l’energia, non macro, ricette né consigli medici, e non inventerà una settimana quando gli input sono non positivi o altrimenti non validi.
Casi di integrazione
Widget di contenuto e dimostrazioni
Alimenti uno strumento gratuito di ciclo calorico nel browser che coincide byte per byte con l’API a pagamento per landing SEO e screenshot di prodotto.
Domande tecniche
Come funziona il pianificatore di ciclo calorico a zigzag?
Divide il Suo totale calorico settimanale per sette per la media, alza i giorni alti di zigzag_percent sopra quella media, risolve i giorni bassi affinché la settimana sommi lo stesso totale e alterna high e low dal lunedì alla domenica.
Quali input sono obbligatori?
weekly_calories (finito positivo). Opzionale: zigzag_percent (default 20), high_first (default true), precision (default 1). Valori non positivi o non validi restituiscono invalid_input.
I giorni alti e bassi coincidono ancora con il mio totale settimanale?
Sì. Le calorie dei giorni bassi sono risolte dal budget settimanale e dal livello dei giorni alti così che n_high×high + n_low×low eguagli il totale settimanale prima dell’arrotondamento; l’ultimo giorno assorbe il residuo.
Cosa succede se zigzag_percent è troppo grande?
Se i giorni bassi sarebbero zero o negativi, l’attività fallisce con invalid_input. Riduca la percentuale affinché ogni giorno resti strettamente positivo.
Quanto costa il pianificatore di ciclo calorico a zigzag?
Lo strumento nel browser è gratuito. Le richieste API usano il saldo prepagato KIT a $0.002 per chiamata riuscita; l’input non valido non viene fatturato.