Kullanıcılar, yapılacak işler, varlıklar ve uç durumları kapsayan tek sayfalık bir uygulama şablonunu Planning Mode için net istemlere dönüştürmek üzere kullanın.
Bulanık bir fikir hayal kurmak için iyidir. İnşa etmek için kötüdür.
Bir AI oluşturucusuna “alışkanlık takip uygulaması” gibi detay vermeden sorduğunuzda, ne demek istediğinizi tahmin etmek zorunda kalır. Bu tahminler istemden isteme değişir, dolayısıyla uygulama da değişir. Ekranlar tutarsız olur, veriler inşa sırasında yeniden adlandırılır ve özellikler ortaya çıkar, kaybolur, sonra farklı bir biçimde geri gelir.
Bu tutarsızlık genellikle birkaç yerde görünür:
“Planning Mode” inşa öncesinde yapılan basit bir duraktır. AI'nin yoktan uyduracağı kararları siz yazarsınız. Amaç tutarlılık: UI, backend ve veritabanının takip edeceği tek bir karar seti.
Amaç mükemmellik değil. Amaç, sürekli tahmin yamaları yapmak zorunda kalmadan üzerinde yineleme yapabileceğiniz bir inşa süreci. Sonra fikrinizi değiştirirseniz, küçük bir spesifikasyonu güncellersiniz ve aynı mantıkla yeniden inşa edersiniz.
İşte bu yüzden tek sayfalık bir uygulama şablonu önemlidir. Uzun bir PRD değildir ve haftalarca diyagram çizmek değildir. Kim kullanıcıdır, ne yapmak istiyorlar, hangi veriler vardır (sade dilde) ve hangi uç durumlar veya dışlanacaklar ilk sürümün kontrolden çıkmasını engeller—bunlara cevap veren bir sayfadır.
Örnek: “Bir rezervasyon uygulaması” tek bir salon sahibi için mi yoksa bir pazar yeri için mi olduğunu, müşterilerin yeniden planlayıp iptal edip etmeyeceğini bilmeden çok belirsizdir.
Tek sayfalık bir uygulama şablonu, bulanık bir fikri net talimatlara dönüştüren kısa bir nottur. Tüm ürünü “tasarlamıyorsunuz.” AI oluşturucunuza aynı seçimleri her seferinde yaptıracak kadar yapı veriyorsunuz.
Sayfa dört bloktan oluşur. Bir sayfaya sığmıyorsa, muhtemelen ilk sürüm için fazla özelliğiniz vardır.
Tek sayfa faydalı kısıtlar dayatır. Birincil kullanıcıyı seçmeniz, en küçük başarılı akışı tanımlamanız ve “her şeyi destekle” gibi belirsiz vaatlerden kaçınmanız gerekir. Bu kısıtlar AI ile oluşturulan uygulamanın ekranlar boyunca fikrini değiştirmemesini sağlar.
“Yeterince iyi” detay basit, test edilebilir ifadeler gibidir. Birisi okuyup “Bunu nasıl biliriz, işe yarıyor mu?” diye sorabiliyorsa doğru seviyedesiniz demektir.
Hedef için hızlı bir kıstas:
Dili sade tutun. Satırları doğrudan istemlere yapıştırabileceğiniz şekilde yazın: “Bir yönetici bir isteği onaylayabilir veya reddedebilir ve talep eden kişi durum güncellemesi alır.”
20 dakikalık bir zamanlayıcı kurun ve “inşa etmeye yetecek kadar net” olun, “mükemmel” olmaya çalışma. Amaç, AI oluşturucunuzun her seferinde aynı seçimleri yapmasını sağlamak için tahminleri ortadan kaldırmaktır.
Tek cümleyle cevaplayan bir başlangıç yapın: kimin için ve hangi sonuç elde ediliyor?
Örnek: “Köpek sahiplerinin yürüyüşleri ve veteriner ziyaretlerini tek bir yerde takip edebileceği mobil uygulama.”
Bir cümlede söyleyemiyorsanız fikir muhtemelen iki uygulamadır.
Sonra 1–3 gerçek insan gibi kullanıcı tipi adlandırın, soyut rollere göre değil. “Owner,” “Vet” ve “Family member” “Kullanıcı A”dan daha iyidir. Her biri için en çok neyi önemsediğine dair kısa bir satır ekleyin.
Ardından 3–7 yapılacak iş yazın, şu formatta: “When [durum], I want to [aksiyon], so I can [sonuç].” Test edilebilir olsun. “Yürüyüşü bitirdiğimde mesafe ve not kaydetmek istiyorum, böylece desenleri görebileyim” “sağlığı takip et”den daha açıktır.
Şimdi varlıklarınızı ve temel alanları veritabanı terimleri kullanmadan tanımlayın. Uygulamanın neyi hatırladığını düşünün. Köpek uygulaması için: Dog (isim, yaş), Walk (tarih, süre, notlar), Visit (tarih, klinik, ücret). Bir alan bir ekranda veya işte kullanılmıyorsa, bırakın.
Son olarak iki kısa blokla bitirin: uç durumlar ve kapsam dışı olanlar. Uç durumlar sinir bozucu ama yaygındır (“internet yok”, “aynı isimli iki köpek”). Kapsam dışı olanlar ilk sürümde yapmayacağınız şeylerdir (“ödeme yok”, “sosyal besleme yok”).
Her bloğu, oluşturucunuzun takip edebileceği istemlere dönüştürün. Yapıyı (amaç, kullanıcılar, işler, varlıklar, uç durumlar) tutarlı tutmak sistemin ekranları, veriyi ve akışları eşleştirmesini kolaylaştırır.
Spesifikasyonunuz “herkes için” diyorsa, AI önce ne inşa edeceğini tahmin etmek zorunda kalır. Tek sayfalık uygulama şablonunda kullanıcıları demografik değil, niyetle tanımlayın (ne yapmak için geldiler). Niyet ekranlar, veri ve izinler hakkında net seçimler yapar.
2–4 kullanıcı tipi adlandırın, her biri için tek bir ana hedef. İyi örnekler: “Sipariş veren müşteri,” “Siparişleri yerine getiren ekip üyesi,” “Performansı inceleyen yönetici.” Belirsiz örnekler: “18–35,” “meşgul profesyoneller,” veya “admin” (neyi yönettiklerini söylemezseniz).
Her seferinde aynı cümle yapısını kullanın: “When..., I want to..., so I can...”. Bu uygulamayı sonucu odaklı tutar ve AI oluşturucuya sabit, test edilebilir gereksinimler verir.
İşte “tamam”ı net tanımlayan gerçekçi JTBD örnekleri:
Başarı kriterleri “iyi görünüyor” belirsizliğini ortadan kaldırır. Builder’a UI’nin neye izin vermesi gerektiğini ve backend’in ne saklaması gerektiğini söyler.
Tam bir güvenlik planı yazmayın. Sadece kimin ne yapabileceğini sade dille belirtin.
Örnek: “Üyeler kendi öğelerini oluşturup düzenleyebilir. Yöneticiler herhangi bir öğeyi düzenleyebilir ve durumu değiştirebilir. Sahipler kullanıcıları ve faturayı yönetebilir.”
Planning Mode gibi bir araç kullanıyorsanız, bu kullanıcı tipleri, JTBD satırları ve izinler güvenilir girdiler olur. AI’nin ekstra roller uydurmasını veya sorumlulukları karıştırmasını da engeller.
Varlıklar, uygulamanın takip ettiği “şeyler”dir. Onları net isimlendirirseniz, AI oluşturucu ekranlar, formlar ve veritabanı eşleşmesini sağlayabilir. Bu, hatalı alan ve gereksiz özelliklerden kaçınır.
Önce çekirdek isimleri listeleyin. Uygulama “projeleri yönetmek” içinse isimleriniz Project, Task, Comment olur. “Saç kesimi rezervasyonu” için Booking, Service, Customer, Staff olabilir.
Her varlık için alanları günlük dilde yazın, veritabanı terimleri değil. Bir kişinin bir forma ne yazacağını hayal edin.
Bir alanı bir cümlede açıklayamıyorsanız, muhtemelen ilk sürüm için çok ayrıntılıdır.
Varlıkların nasıl bağlandığını basit cümlelerle anlatın:
“Bir kullanıcının birçok projesi olabilir.” “Her görev bir projeye ait olur.” “Bir yorum bir göreve aittir ve bir yazara sahiptir.”
Bu, builder’a tutarlı listeler, detay sayfaları ve filtreler üretmesi için yeterli yapıyı verir.
Dağınık davranışı önleyecek birkaç veri kuralı ekleyin:
Son olarak, şu anda ne saklamayacağınızı açıkça yazın. Örnek: “v1'de dosya ekleri yok,” veya “Çalışan programlarını henüz takip etme, sadece rezervasyonları tut.” Bu dışlamalar uygulamanın yanlış yönde büyümesini engeller.
Tek sayfalık bir uygulama şablonu, ilk sürüm küçük ve sabit ekran setine sahip olduğunda en iyi çalışır. Uygulamanızın gelecekteki tüm ekranlarını tasarlamaya çalışırsanız, AI oluşturucu durmadan tahmin yapar ve UI yeniden inşa edildikçe sürüklenir.
Ana işi tamamlamaya izin veren minimum ekranları adlandırarak başlayın. Çoğu MVP için 3–6 ekran yeterlidir:
Sonra mutlu yolu kısa bir hikâye olarak yazın baştan sona.
Örnek: “Kullanıcı giriş yapar, listeye düşer, arama yapar, bir öğeyi açar, bir alanı düzenler, kaydeder ve listeye döner.”
Her ekran için ana eylemleri sade kelimelerle not edin. “Her şeyi yap” ekranlarından kaçının. En çok önemli 2–4 eylemi seçin: oluştur, düzenle, ara, dışa aktar, arşivle gibi.
Ayrıca neyin hızlı olması gerektiğine ve neyin “yeterince iyi” olabileceğine karar verin. “Hızlı” genelde listenin çabuk açılması, aramanın hızlı cevap vermesi ve kaydetmenin anlık hissettirmesidir. “Yeterince iyi” dışa aktarmanın birkaç saniye sürmesi, temel analizler veya sınırlı ayarlar olabilir.
Son olarak, rolleri ve erişimi her rol için bir satırda yakalayın:
Bu, ekranları öngörülebilir tutar, izin sürprizlerini önler ve sonraki yeniden yazımları azaltır.
Çoğu yeniden yazımın sebebi tek: uygulama mutlu yolu iyi işlerken gerçek dünya geldiğinde bozulur.
İyi bir tek sayfa uygulama şablonu uç durumlar ve kapsam dışı olanlar için yer bırakır ve bu küçük alan saatler kazandırır.
Her JTBD için şu soruyu sorun: neler ters gidebilir? Basit, teknik olmayan şekilde yazın. Amacınız, builder’ın her seferinde aynı kararı vermesini sağlamak için belirsizliği kaldırmaktır.
Yazılmaya değer yaygın uç durumlar:
Sonra tepkiyi belirleyin. Spesifik olun: “İşlemi engelle ve açık bir mesaj göster,” “Taslak olarak kaydetmeye izin ver,” veya “Bir kez yeniden dene, sonra tekrar dene düğmesi göster.” Bu kurallar doğrudan tutarlı istemlere dönüşür.
Gizlilik ve güvenlik beklentilerini 1–2 satırda ekleyin. Örnek: “Gerekli minimum veriyi topla,” “Kullanıcı hesaplarını ve kişisel verilerini silme hakkı olsun,” “Özel öğeler varsayılan olarak gizli.” Eğer uygulamanız kullanıcı tarafından oluşturulan içerik içeriyorsa, bildirme ve spam ile nasıl başa çıkılacağına dair basit bir kural ekleyin, v1 basit olsa bile.
Son olarak, kapsam dışı olanları yazın ki kapsam büyümesinin önüne geçin.
Açık kapsam dışı örnekleri:
Kısa bir örnek: iş “Etkinlik oluştur” ise, tarihin geçmiş olması, başlığın boş olması veya aynı etkinliğin iki kez oluşturulması durumunda ne yapılacağını tanımlayın. Bu netlik sonraki yeniden yazımı engeller.
Tutarlı sonuç almanın en hızlı yolu, tek sayfa şablonunuzun her bloğunu küçük, doğrudan bir isteme çevirmektir. Oluşturucuya bir büyük, bulanık istek vermek yerine, sıralanmış kartlar seti veriyormuş gibi düşünün.
Her bloğu (Kullanıcılar, İşler, Varlıklar, Ekranlar, Uç durumlar, Kapsam dışı) tek bir talimata dönüştürün, net isimler ve fiiller kullanın. “Temiz yap” gibi görüşleri yalnızca “temiz”in ne demek olduğunu da söylerseniz ekleyin.
İki adımlı bir döngü kullanın: önce oluştur, sonra spesifikasyona göre doğrula.
Bir de bitiş tanımı (definition of done) ekleyin ki oluşturucu ne zaman duracağını bilsin. Ölçülebilir olsun:
Sadece gerçekten önemliysa kısıtlar ekleyin: gerekli cihazlar (mobil-öncelikli), gerekli kimlik doğrulama (sadece admin), veya platformun beklediği belirli bir yığın (React frontend, Go backend, PostgreSQL) gibi.
Düzeltme istediğinizde, kodu değil spesifikasyon bloğunu referans verin.
Örnek: “Varlıklar bloğunu güncelle: ‘Subscription’ ekle X ve Y alanlarıyla. Ardından yalnızca etkilenen API ve ekranları yeniden üret, doğrulama adımını çalıştır.”
Bu yaklaşım planı stabil tutar ve güvenle yineleme yapmanızı sağlar.
Basit bir randevu hatırlatma takipçisi yapmak istediğinizi varsayın; küçük bir salon için. Amaç tam bir rezervasyon sistemi değil. Amaç randevuları saklamak ve hatırlatmalar göndermek.
Doldurulmuş tek sayfa uygulama şablonu şöyle görünür.
APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.
USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.
JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.
ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.
EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments
Şimdi bunu Planning Mode uygulama oluşturma için yapıştırılabilecek istem paketine çevirin. Builder’ın her seferinde aynı seçimleri yapmasını sağlayacak kadar katı tutun.
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.
Dağınık çıktı genellikle bulanık bir spes ve özellik istek listesiyle başlar. Bir AI oluşturucu istediğinizi yapar ama aklınızı okuyamaz. Küçük boşluklar ekranlar ve akışlar arasında büyük farklılıklara dönüşür.
Bu tuzaklar tutarlılığı en çok bozar ve tek sayfa şablonu bunları düzeltir:
Eğer Planning Mode’u Koder.ai ile kullanıyorsanız, bu temel kurallar daha da önem kazanır çünkü plan tekrar eden istemlerin kaynağı olur. Net işler, küçük veri modeli, açık izinler ve test edilebilir başarı kuralları her yeni ekranı diğerleriyle hizalı tutar.
İnşa etmeden önce tek sayfa uygulama şablonunuzda hızlı bir gözden geçirme yapın. Amaç, AI inşasını tahmin etmeye zorlayan boşlukları kapatmaktır. Bu tahminler yeniden yazımlara dönüşür.
Hızlı tamlık kontrolü:
Basit bir puanlama fikri isterseniz, her alanı 0–2 arasında puanlayın:
Üretmeden önce en az 7/10 hedefleyin. Varlıklar veya uç durumlar 2'nin altındaysa önce onları düzeltin. Çünkü en çok sürtüşmeyi onlar çıkarır.
İlk oluşturma sonrası, uygulamayı her JTBD'ye göre gözden geçirin ve uyumsuzlukları işaretleyin. Her değişiklikten önce bir anlık görüntü alın. Yeni yineleme işleri daha kötü yaparsa, geri alın ve daha küçük bir düzenleme deneyin.
Eğer Koder.ai (koder.ai) kullanıyorsanız, Planning Mode bu tek sayfa spesifikasyonu “gerçek kaynak” olarak tutmak ve sadece değişeni yeniden üretmek için pratik bir yerdir.
Kabul ettiğiniz bir değişiklik olduğunda, aynı gün spesifikasyonu güncelleyin. Bir değişikliği reddederseniz nedenini yazın ki bir sonraki istem tutarlı kalsın.
Planning Mode, ekranlar ve kod üretmeden önce kilit kararları yazdığınız kısa bir ara adımdır. Amaç tutarlılık: aynı kullanıcılar, akışlar ve veri adları UI, backend ve veritabanı arasında sabit kalsın, böylece her seferinde yeni varsayımlarla yeniden inşa etmezsiniz.
Tek cümlelik bir hedefle başlayın, sonra dört blok doldurun:
Bir sayfaya sığmıyorsa, v1 için özellikleri kesin.
Pratik ve niyet odaklı tutun. Birkaç kullanıcı tipi ve onların ne yapmaya çalıştığını yazın.
Örnek: “Randevu oluşturan Owner/Staff” “Admin” demekten daha açıklayıcıdır. Bir rolün ne yaptığını bir cümleyle açıklayamıyorsanız muhtemelen çok belirsizdir.
Her işi test edilebilir kılmak için katı bir desen kullanın:
Ardından neyin “tamam” sayılacağını kısaça yazın (ne kaydedilmeli/güncellenmeli/görünmeli). Bu, builder’ın rastgele adımlar veya gereksiz ekranlar eklemesini engeller.
MVP için uygulamanın hatırladığı "şeyleri" sade dilde listeleyin ve her birine ekranda gerçekten kullanacağınız 3–7 alan verin.
Örnek: Appointment: başlangıç zamanı, süre, durum, servis, müşteri. Bir alan iş veya ekranda kullanılmıyorsa v1'de bırakın.
İlişkileri basit cümlelerle yazın:
Ayrıca birkaç temel kural ekleyin (gerekli alanlar, benzersizlik, varsayılanlar). Bu, listeler, formlar ve filtrelerin tutarlı olmasını sağlar.
İlk versiyon için ana işi tamamlatan 3–6 ekran yeterlidir:
Ayrıca bir "mutlu yol" hikâyesi yazın (başla → aksiyon → kaydet → onay) ki akış sapmasın.
Gerçek kullanımın mutlu yolu bozduğu yerlerdir. En olası 5–10 uç durumu yazın:
Her biri için beklenen davranışı açıkça belirtin (işlemi engelle, mesaj göster, taslak olarak kaydet, yeniden dene vb.).
Her blok için kısa, uygulanabilir bir talimat setine dönüştürün ve doğrulama ekleyin.
Basit sıra:
Bu, tek ve büyük bir muğlak isteme güvenmekten daha tutarlı sonuç verir.
Önce spesifikasyonu güncelleyin, sonra sadece değişen kısımları yeniden üretin.
Örnek: “Subscription adlı bir varlık ekle X/Y alanlarıyla; etkilenen ekranları ve API'leri güncelle; tekrar kontrol et.” Spesifikasyon kaynağını tek gerçek olarak tutmak dağınık, tutarsız düzenlemeleri önler.