Disse prompts er rekonstruerede undervisningseksempler, ikke originale udviklingssamtaler. De indeholder hverken appkode, nøgler, konfiguration eller driftsdetaljer. Brug et tilladt, tilgængeligt værktøj eller papir. Uden AI: tegn forløbet og skriv kontrolkriterier, uden at vente på underviseren. Opdigtede eksempler kan også drøftes i mødet.
Et udviklingsforløb, der kan genbruges
Beskriv person og situation → afgræns forløbet → lav første version med opdigtet materiale → prøv én opgave på enheden → notér stop → ret én ting og test igen → invitér frivillige → vælg næste skridt ud fra fund.
Du kan begynde en prototype med AI og eksisterende muligheder, før du har lært Android/iOS-programmering systematisk. Lær stadig det, opgaven kræver: tilladelser og tilstande, API og udgifter, lagring og gendannelse samt adgang og kontrol. Pakning, signering, installation og tjenestens tilgængelighed skal faktisk afprøves. Casen bruger tidligere erfaring, ikke øjeblikkelig skabelse uden viden.
Opgave 1 | Hjælp personen med at begynde at fortælle
»Design en lille prototype til lydnotater. Brugeren vil fortælle i ro uden først at skrive en artikel. Demonstrér med opdigtede hverdagsspørgsmål og kun fire trin: spørgsmål, svar, pause, gem. Angiv tilstande og kontrol før et implementeringsforslag. Ingen rigtige konti, private optagelser eller automatisk kamera. Markér tilladelser, udgifter og fejltilstande, jeg skal bekræfte.«
Kontrollér: Høres spørgsmålet først? Stopper pause faktisk? Kan det gemte findes? Forklares fejl uden at slette bekræftet indhold?
Opgave 2 | Efter AI siger, at fejlen er rettet
»Forventet: Gentag læser kun det aktuelle spørgsmål. Faktisk: Telefonen er tavs. Skeln mellem kendt, ukendt og tre testbare hypoteser. Foreslå mindste reproduktion og én første kontrol. Vent på resultatet før ændringer; ret ikke flere moduler samtidig. Forklar gentest og resterende risici bagefter.«
Kopiér ikke rigtige logfiler; de kan indeholde identifikatorer eller legitimationsoplysninger. Øvelsen handler om reproduktion, hypoteser, én ændring og gentest, ikke syntaks eller frameworknavne.
Opgave 3 | Sortér feedback uden at beslutte for mig
»Opdigtet prøveoversigt: A vil prøve, men har ikke installeret; B stopper ved installation; C vil redigere tekst, men finder ikke stedet; D ønsker daglige emner og finder senere eksisterende valg. Sortér indstilling, adfærd, forhindring og muligt behov. Markér utilstrækkelig dokumentation. Foreslå én observerbar næste opgave pr. person uden at udlede salg, behandlingseffekt eller alles behov.«
Deltagerne skal opdage, at »tilføj en funktion« kan handle om en eksisterende funktion, der er svær at finde. Ros er ikke en handel, og et forslag beviser ikke et behov.
Produktansvar for data og API
| Problem | Det skal deltageren kunne forklare | Case og næste skridt |
|---|---|---|
| Det, der forlader telefonen | Hvor går optagelser, tekst og konfiguration hen? Hvem har adgang? | Tegn kun et forenklet dataflow, ingen rigtige tjenesteindstillinger |
| Formålet med én Key pr. person | Hjælper adgang, kvoter og placering af udgifter. Særskilt fakturering afhænger af udbyder og kontoindstillinger | Adskiller ikke automatisk personlige optegnelser. Tildeling ved registrering kræver håndtering af samtidige forespørgsler, tom pulje og tilbagekaldelse |
| Hvorfor administratoradgang ikke er en almindelig indstilling | Klienten kan analyseres. Sløring er ikke fortrolighed | Bekvemmelighed under intern test har resterende risici og er ikke en moden sikkerhedsmodel |
| Mindre risiko ved små forsøg | Færrest mulige data, begrænset adgang, tilbagekaldelse, gendannelsestest og fejlhåndtering | Reel adskillelse kræver kontrollerede tjenester, adgangskontrol, revision og andre tekniske tiltag. Kurset hævder ikke, at alt er løst |
| Styring af udgifter | Hvem har ansvar for antal kald, varighed, tjenestefejl og budget? | Studerende bruger en hypotetisk kvote, ikke opdigtede udbyderpriser. Sæt grænse før test |
Kurset forklarer ansvar og metoder uden rigtige baggrundstabeller, konfigurationer, Bot-oplysninger eller udtræksmetoder. Lukket kode er et produktvalg; sikkerhed må ikke bygge på det alene.
Stærkere analyse- og genskabelsesværktøjer
Pr. 2026-10-23 er kun repositorybeskrivelse og licensangivelse læst. Ingen installation, kørsel eller praktisk afprøvning.
REA's officielle repository ↗: beskriver hjælp til analyse af appadfærd, binære filer og kørsel. Beskrivelsen garanterer ikke vellykket analyse af enhver app.
replica-skills officielle repository ↗: samler observation, genskabelse og test som en skill. README anbefaler genskabelse af funktioner og forløb med egne materialer, uden kopiering af målappens kode, mærke, tekster eller indhold.
Begge angiver aktuelt MIT-licens. Kontrollér version, afhængigheder og licens før brug.Værktøjets licens er noget andet end rettigheder og adgang til målappen. Repositoryslogans er ikke juridisk tilladelse eller sikkerhedsgaranti. Kurset drøfter kun egne eller klart tilladte demonstrationer, uden juridiske konklusioner eller træning i reverse engineering.
Fire spørgsmål før beslutningen
Må jeg tilgå og analysere dette? Er det metoden, licenserede komponenter eller andres indhold, jeg vil bruge? Hvordan angiver jeg kilde og kontrollerer resultatet? Selv med samme udseende: Hvem er mine brugere, hvad vælger jeg til og fra, og hvad er mit ansvar?
»Min egen kerne« er ikke en ansvarsfraskrivelse og kræver ikke, at alle kodelinjer skrives fra bunden. Skaberen har ansvar for retning, kilder, kontrol, fravalg og endelig levering.