Spesifikasi aplikasi mudah alih: templat satu halaman

Spesifikasi aplikasi mudah alih: jawapan ringkas

Spesifikasi aplikasi mudah alih yang baik, apabila anda membina aplikasi anda sendiri, muat dalam satu halaman. Ia menjawab sepuluh soalan: untuk siapa, apa masalahnya, apa fungsi utamanya, bagaimana aplikasi menjana wang, apa yang berlaku tanpa akaun, data apa yang mesti kekal, untuk platform mana, apa yang di luar versi pertama, bagaimana anda tahu ia berjaya, dan apa kekangannya. Templat untuk disalin ada di bawah. Anda juga boleh memuat turun rangka dan grid pengesahannya (.md), tanpa perlu mendaftar.

Templat 40 halaman yang anda jumpa dalam talian ditulis untuk kegunaan lain: pelanggan yang menempah aplikasi daripada penyedia perkhidmatan dan memerlukan dokumen kontrak. Anda pula ialah orang yang membuat keputusan dan juga yang membina, selalunya dengan bantuan AI. Spesifikasi anda ada dua tujuan: memutuskan perkara penting sebelum mula mengekod, dan memberi Claude, ChatGPT atau Cursor konteks yang jelas supaya mereka membina aplikasi yang betul.

Saya menerbitkan aplikasi iOS saya sendiri. Solys, jam penggera dengan permainan mini, dan TradaZen, simulator dagangan, ada di App Store. Nolera dan Clic pernah ditolak oleh Apple, kemudian diperbaiki. Inilah kaedah yang saya gunakan untuk setiap satu, dan inilah yang saya cadangkan kepada anda di sini.

Kenapa satu halaman sudah cukup untuk merangka aplikasi anda sendiri

Dokumen panjang memberi rasa seolah-olah anda sudah maju. Hakikatnya, ia ditulis sekali, jarang dibaca semula, dan projek mula menyimpang daripadanya sejak minggu-minggu pertama. Satu halaman pula boleh dibaca semula dalam dua minit sebelum setiap sesi kerja.

Had ruang ini juga ada kesan yang berguna: ia memaksa anda membuat keputusan. Jika satu jawapan melebihi dua ayat, selalunya keputusan itu belum dibuat. Lebih baik anda sedar di atas kertas daripada dalam kod anda, tiga minggu kemudian.

Akhir sekali, satu halaman ialah saiz yang sesuai untuk AI. Anda boleh menampalnya sepenuhnya dalam perbualan, atau menyimpannya dalam fail konteks projek anda. Dokumen pendek lebih mudah disemak dan mengurangkan arahan yang bercanggah. Ia tidak menjamin AI akan mematuhinya: semak cadangannya berdasarkan rangka ini.

Apa yang perlu ada dalam spesifikasi aplikasi mudah alih?

Jawab setiap soalan ini dalam satu atau dua ayat.

1. Siapa yang menggunakan aplikasi, dan dalam situasi apa? Bukan "golongan 18-35 tahun". Sebaliknya, seorang individu tertentu, pada satu masa tertentu dalam harinya.
2. Masalah apa yang diselesaikan aplikasi, dalam satu ayat? Jika anda perlukan "dan juga", anda sedang menerangkan dua aplikasi.
3. Apakah SATU fungsi utama versi pertama? Satu sahaja. Yang lain boleh tunggu angka. Halaman MVP aplikasi iOS menerangkan cara memilihnya.
4. Bagaimana aplikasi menjana wang? Langganan, pembelian sekali atau percuma. Jawapan ini mengubah aplikasi sejak skrin pertama. Jika anda ragu-ragu, baca langganan atau pembelian sekali untuk aplikasi iOS.
5. Apa yang boleh dilakukan tanpa membuat akaun? Memutuskan awal apa yang boleh diakses tanpa pendaftaran mengelakkan anda membina semula seluruh aliran permulaan.
6. Data apa yang mesti kekal apabila bertukar telefon? Soalan inilah yang menentukan sama ada anda perlukan backend seperti Supabase, atau semuanya boleh kekal dalam peranti.
7. iOS sahaja, atau iOS dan Android? Nasihat saya untuk pemula: iOS dahulu. Saya terangkan sebabnya dalam aplikasi iOS dan Android serentak.
8. Apa yang secara jelas DI LUAR versi pertama? Bahagian paling berguna dalam dokumen ini. Ia menghentikan perdebatan sebelum ia bermula, dengan diri anda sendiri mahupun dengan AI.
9. Bagaimana anda tahu ia berjaya? Satu isyarat sahaja, boleh diukur dalam beberapa minggu selepas pelancaran: percubaan percuma yang dimulakan, pelanggan berbayar, pengguna yang kembali.
10. Apa kekangan sebenar anda? Masa yang boleh anda peruntukkan setiap minggu, peralatan anda, dan akaun Apple Developer anda, yang berharga 99 $ setahun. Tiada Mac? Itu bukan penghalang, seperti yang saya terangkan dalam menerbitkan aplikasi iOS tanpa Mac.

Templat spesifikasi untuk disalin

Salin templat ini ke dalam nota atau fail teks di akar projek anda, kemudian gantikan setiap baris.

• Nama sementara aplikasi: …
• Untuk siapa: seseorang yang … pada ketika …
• Masalah yang diselesaikan, dalam satu ayat: …
• Fungsi utama versi 1: …
• Apa yang pengguna lihat ketika membuka aplikasi buat kali pertama: …
• Model perniagaan: langganan / pembelian sekali / percuma, dan apa yang berbayar: …
• Tanpa akaun, pengguna boleh: …
• Data yang perlu disimpan antara dua telefon: tiada / …
• Platform: iOS dahulu (Android kemudian jika angka menyokong)
• Di luar versi 1: …, …, …
• Isyarat kejayaan: …
• Stack: React Native, Expo, Supabase jika perlukan akaun, RevenueCat untuk langganan
• Kekangan: … jam seminggu, akaun Apple Developer sudah dibuka atau belum, ada Mac atau tidak
• Aplikasi yang saya suka pengalamannya, dan kenapa: …

Tambah tiga hingga lima tangkapan skrin aplikasi yang anda suka, dengan sepatah kata tentang apa yang anda suka. Ia lebih jelas daripada panduan reka bentuk, untuk anda dan juga untuk AI.

Spesifikasi bukan senarai hajat. Ia senarai keputusan yang sudah dibuat.

Contoh: halaman yang sudah diisi untuk aplikasi rekaan

Untuk melihat tahap perincian yang diharapkan, inilah templat yang diisi untuk aplikasi rekaan sebagai contoh, iaitu pemasa ulang kaji.

• Untuk siapa: pelajar yang mengulang kaji seorang diri pada waktu malam dan hilang tumpuan selepas sepuluh minit.
• Masalah: dia tidak dapat bertahan satu sesi kerja tanpa menyentuh telefonnya.
• Fungsi utama: memulakan sesi bermasa dan melihat rentetan hari yang berjaya dikekalkan.
• Skrin pertama: satu butang sahaja untuk memulakan sesi.
• Model perniagaan: langganan untuk statistik terperinci, sesi asas percuma.
• Tanpa akaun: semuanya, kecuali sandaran antara dua telefon.
• Di luar versi 1: mod kumpulan, kedudukan antara rakan, widget, versi Android.
• Isyarat kejayaan: pengguna yang kembali beberapa hari berturut-turut.

Perhatikan apa yang sengaja tiada: tiada senarai dua puluh skrin, tiada warna yang ditetapkan, tiada seni bina. Pilihan ini akan datang semasa membina, dan halaman ini membantu anda memastikan ia terus menyokong fungsi utama.

Cara menggunakan spesifikasi anda untuk membimbing AI

Di sinilah halaman anda paling bermanfaat. AI yang mengekod tanpa konteks akan meneka, dan selalunya ia meneka aplikasi lain, bukan aplikasi anda.

Letakkan halaman ini dalam konteks tetap projek. Claude Code membaca fail CLAUDE.md di akar projek, Cursor ada fail peraturannya sendiri. Tampal spesifikasi anda di situ, bersama stack anda. Setiap permintaan kemudian bermula daripada asas yang sama.

Petik bahagian "di luar versi 1" apabila AI berlebihan. Pembantu AI suka mencadangkan fungsi tambahan: mod gelap, fungsi kongsi, pemberitahuan. Senarai pengecualian anda memberi jawapan siap: bukan sekarang.

Minta pelan yang mematuhi halaman ini. Sebelum kerja besar, tulis: "ini spesifikasi saya, cadangkan pelan untuk fungsi utama, jangan kod lagi". Anda terus nampak jika pelan itu menyimpang daripada apa yang anda putuskan.

Minta ia menyemak halaman itu, bukan hanya kod. Tanya: "soalan mana dalam spesifikasi ini yang kabur atau bercanggah?". Ini kegunaan AI yang dipandang rendah, dan ia menyelamatkan anda daripada berminggu-minggu bekerja ke arah yang salah.

Untuk pergi lebih jauh, saya huraikan perangkap dan semakan dalam membina aplikasi iOS dengan AI.

Menukar keputusan menjadi kriteria pengesahan

Fungsi utama mesti ada hasil yang boleh diperhatikan. Untuk pemasa rekaan dalam contoh ini, "pemasa berfungsi" terlalu kabur. Tulis sebaliknya: "Saya mulakan sesi, baki masa dipaparkan, saya boleh menghentikannya dan melihat semula sesi terakhir yang selesai selepas membuka semula aplikasi." Putuskan secara berasingan sama ada pemasa perlu terus berjalan semasa skrin dikunci: pilihan ini boleh mengubah kerja teknikal.

Tambah tiga baris untuk setiap fungsi: tindakan, hasil yang dijangka, bukti. Bukti boleh jadi ujian automatik untuk pengiraan atau semakan pada peranti untuk aliran pengguna. Catat juga apa yang belum diuji. Grid kecil ini mengelakkan anda menyangka skrin yang siap sebagai fungsi yang sedia digunakan.

Inilah grid yang sudah diisi untuk pemasa rekaan kita. Ini kriteria untuk disemak, bukan ujian yang sudah lulus:

Keputusan rangka	Untuk diuji	Hasil yang dijangka
Sesi asas boleh diakses tanpa akaun	Pasang aplikasi dan mulakan sesi tanpa mendaftar	Tiada borang pendaftaran yang menghalang permulaan
Sesi yang dibatalkan tidak dikira dalam rentetan	Hentikan sesi sebelum tamat, kemudian buka sejarah	Tiada sesi selesai yang ditambah
Sejarah kekal dalam peranti	Selesaikan sesi, tutup kemudian buka semula aplikasi	Sesi muncul sekali sahaja dengan tempoh yang betul
Pemasa asas berfungsi tanpa rangkaian	Aktifkan mod pesawat dan selesaikan sesi	Pemasa dan simpanan setempat masih boleh digunakan
Statistik terperinci berbayar	Buka statistik tanpa langganan	Tawaran dipaparkan; sesi asas masih boleh diakses

Perkara yang masih kabur menjadi keputusan yang perlu dibuat. Contohnya: apa yang berlaku jika pengguna mengunci skrin atau menukar waktu telefon semasa sesi? Jangan biarkan ejen AI memilih secara senyap. Tulis tingkah laku yang anda mahu, kemudian tambah kes itu ke dalam grid. Untuk mengatur ujian ini pada pemasangan sebenar, gunakan panduan menguji aplikasi iPhone dengan TestFlight.

Memutuskan apa yang perlu dibuang apabila versi pertama melimpah

Ambil setiap fungsi dan tanya satu soalan: "Tanpanya, bolehkah pengguna masih mendapat hasil yang dijanjikan?" Untuk pemasa kita, kedudukan antara rakan boleh tunggu. Melihat semula sesi yang selesai adalah perlu jika anda menjanjikan rentetan hari. Skrin langganan hanya menjadi perlu jika anda benar-benar menjual statistik sejak versi ini.

Catat keputusan dan sebabnya dalam jurnal templat yang boleh dimuat turun. Anda boleh menilai semula pilihan ini selepas ujian, tanpa kehilangan sebab di sebalik skop asal. Tutorial membina aplikasi dengan Claude Code kemudian menunjukkan cara menukar rangka ini kepada permintaan yang terhad dan boleh disemak.

Untuk pengalaman sebenar, TradaZen mengubah skopnya selepas diterbitkan. Rangka ini berguna untuk melancarkan versi pertama yang boleh diukur, kemudian memutuskan versi seterusnya berdasarkan maklum balas sebenar.

Perangkap katalog fungsi

Naluri semula jadi ialah menyenaraikan semua yang aplikasi "perlu buat": peta, sembang, pemberitahuan, rujukan rakan, mod luar talian. Katalog ini ialah tanda paling pasti projek yang tidak akan siap, atas sebab mudah: setiap fungsi yang ditambah sebelum pelancaran melambatkan saat pengguna sebenar memberitahu anda apa yang penting.

Versi pertama yang baik melakukan satu perkara, dan melakukannya dengan baik. Namun berhati-hati dengan keterlaluan sebaliknya: Apple mahukan aplikasi yang melebihi sekadar laman web yang dibungkus, menurut peraturan 4.2 App Review Guidelines. Satu fungsi utama, ya; cangkerang kosong, tidak: itulah sebab penolakan guideline 4.2.

Apa yang tidak patut ada dalam spesifikasi aplikasi mudah alih

• Panduan reka bentuk lengkap. Beberapa tangkapan skrin rujukan sudah memadai pada permulaan.
• Jadual harian. Anda belum ada maklumat untuk mematuhinya. Sasaran mingguan sudah cukup.
• Seni bina teknikal terperinci. Pilih stack yang terbukti, kemudian biarkan butirannya diputuskan semasa membina.
• Fungsi "untuk kemudian" yang bercampur dengan yang lain. Semuanya masuk ke bahagian di luar versi 1.

Bila perlu mengemas kini spesifikasi anda?

Baca semula pada awal setiap minggu kerja. Kemas kini hanya apabila sesuatu keputusan berubah atas sebab yang kukuh: ujian pada iPhone anda yang menunjukkan sesuatu skrin tidak berfungsi, maklum balas penguji, kekangan Apple yang ditemui di pertengahan jalan. Jika anda mengubahnya setiap hari, ia sudah tidak merangka apa-apa.

Selepas versi pertama diterbitkan, halaman ini menjadi asas versi seterusnya: apa yang di luar versi 1 naik ke atas, disusun mengikut apa yang angka beritahu anda. Gambaran keseluruhan perjalanan, daripada idea hingga penerbitan, ada di halaman membina aplikasi iPhone.

Daripada halaman kepada aplikasi yang diterbitkan

Jika anda sudah menjawab sepuluh soalan ini, anda sudah melakukan kerja yang dilangkau oleh banyak projek. Seterusnya: membina fungsi utama, mengujinya pada iPhone anda, menyambungkan langganan dan menyediakan dokumen untuk Apple.

Perjalanan inilah yang ada dalam iOS Kit, dalam empat langkah yang boleh diikuti mengikut rentak anda: langkah pertama ialah memilih aplikasi yang boleh menjana pendapatan, khalayaknya dan harganya, dan spesifikasi anda ialah titik permulaannya.

Tidak pasti sama ada idea anda sudah sedia untuk dimuatkan dalam satu halaman? Diagnostik percuma memberitahu apa yang menghalang projek anda hari ini dan langkah mana yang perlu didahulukan. Halaman utama kemudian menunjukkan cara membina aplikasi mudah alih berdasarkan rangka ini, dengan Claude Code.

Saya tidak menjanjikan pendapatan mahupun penerbitan: Apple yang meluluskan, dan pasaran yang menentukan selebihnya. Tanpa kit pun, templat ini sudah cukup untuk anda bermula.

Soalan lazim

Bagaimana menulis spesifikasi untuk aplikasi mudah alih?

Pastikan spesifikasi anda muat dalam satu halaman: sepuluh soalan, satu atau dua ayat setiap jawapan. Ia merangkumi khalayak, masalah, fungsi utama, model perniagaan, apa yang berlaku tanpa akaun, data yang mesti kekal, platform, apa yang di luar versi pertama, isyarat kejayaan dan kekangan. Jika satu jawapan melebihi dua ayat, selalunya keputusan itu belum dibuat.

Perisian apa untuk menulis spesifikasi aplikasi?

Nota biasa atau fail teks di akar projek anda: salin templat ke situ, kemudian gantikan setiap baris. Anda juga boleh memuat turun rangka dan grid pengesahannya (.md), tanpa perlu mendaftar. Untuk membimbing AI, simpan kemudian dalam fail konteks projek anda.

Perlukah spesifikasi 40 halaman untuk sebuah aplikasi?

Tidak, apabila anda membina aplikasi anda sendiri: satu halaman sudah cukup. Templat 40 halaman dalam talian ditulis untuk pelanggan yang menempah aplikasi daripada penyedia perkhidmatan dan memerlukan dokumen kontrak. Anda pula yang membuat keputusan dan membina: halaman anda berguna untuk memutuskan perkara sebelum mengekod dan memberi konteks kepada AI.

Bagaimana memberikan spesifikasi kepada AI yang mengekod?

Letakkan halaman itu dalam konteks tetap projek: Claude Code membaca fail CLAUDE.md di akar projek, Cursor ada fail peraturannya sendiri. Petik bahagian "di luar versi 1" apabila AI berlebihan. Sebelum kerja besar, minta pelan yang mematuhi halaman itu, tanpa terus mengekod.

Bagaimana menyemak sama ada sesuatu fungsi mematuhi spesifikasi?

Tambah tiga baris untuk setiap fungsi: tindakan, hasil yang dijangka dan bukti. Bukti boleh jadi ujian automatik untuk pengiraan, atau semakan pada peranti untuk aliran pengguna. Catat juga apa yang belum diuji, supaya anda tidak menyangka skrin yang siap sebagai fungsi yang sedia digunakan.

Apa yang tidak patut dimasukkan dalam spesifikasi aplikasi?

Empat perkara yang perlu dielakkan: panduan reka bentuk lengkap, jadual harian, seni bina teknikal terperinci, dan fungsi "untuk kemudian" yang bercampur dengan yang lain. Beberapa tangkapan skrin rujukan sudah memadai pada permulaan, dan sasaran mingguan sudah cukup untuk jadual. Fungsi untuk kemudian semuanya masuk ke bahagian di luar versi 1.