Печалби:
- Да можеш да разграничиш къде изкуственият интелект осигурява реална скорост в мобилното развитие (код на шаблон, чернова, обучение) и къде (архитектура, разрешение, сигурност, публикуване) решението е оставено на човека, в зависимост от нивото на риск на задачата.
- Възможност за прилагане на дисциплина, която проверява всеки изход от изкуствен интелект чрез стъпки за компилиране, тестване и преглед
- Способност да развиете навик за писане на силни, изпълнени с контекст подкани и защита на личните данни и секретни ключове, без да ги давате на AI
Разработката на мобилни приложения е едно от най-конкурентните софтуерни полета в света. Говорим за продукт, който работи на милиарди устройства, чийто цикъл на актуализиране зависи от одобрението на магазина и се измерва в джоба на потребителя по всяко време. Изкуственият интелект (AI — софтуерни системи, които могат да произвеждат текст, код и решения като хората) навлезе в тази област по два начина: първо, като помощ, която ускорява процеса на разработка (генериране на код, отстраняване на грешки, писане на тестове) и второ, като възможност, вградена в приложението (разпознаване на изображения в устройството, асистент за чат, двигател за препоръки). Този модул преподава и двете от край до край. Но нека напишем едно изречение от самото начало: AI не замества мобилния разработчик; разширява своята производителност и обхват. Вие носите отговорност за всеки издаден ред код, всяко поискано разрешение и всяка транзакция, извършена с потребителски данни.
В този раздел ще видим къде изкуственият интелект произвежда истинска стойност в мобилното развитие, къде трябва да се предаде на хората, как да проверим всеки резултат и защо дисциплината за поверителност и сигурност не подлежи на обсъждане.
Къде AI е полезен в мобилното развитие?
Мобилната разработка се състои от много повтарящи се и шаблонни задачи: писане на код за изглед, настройка на слой на мрежова заявка, дефиниране на модел на данни, създаване на тестов случай, разрешаване на съобщението за грешка. AI произвежда тези модели много бързо. За разлика от тях, архитектурните решения, предпочитанията за потребителско изживяване, границите на сигурността и точността на бизнес логиката са домейн на хората.
Полезно е задачите да се разделят на три кофи въз основа на нивото на риск:
Тип задача
Роля на AI
мъжка роля
Код на шаблон (шаблон), примерен екран, преобразуване
Генерира чернова, ускорява го
Преглежда, интегрира
Бизнес логика, поток от данни, API интеграция
Предоставя предложения и чернови
Проверява, тества, валидира
Архитектура, искане за разрешение, сигурност, решение за излъчване
Изброява опции и обосновки
Взема решението и носи отговорността
Тази таблица ще бъде нашият компас през целия модул. Дясната колона никога не се предава на AI.
Съвет: Мислете за AI като за „много бърз, но неопитен стажант“. Давате му ясна задача, четете разпечатката му, подлагате го на тест и поемате отговорност. Не изпращате кода, създаден от стажанта, в продукция (жива среда), без да го прочетете; Същото правило важи и за AI.
Дисциплина за проверка: три стъпки
AI текстът е плавен и изглежда уверен; Но плавността не е точност. AI понякога пасва на библиотечна функция, която не съществува (това се нарича халюцинация — моделът уверено произвежда нещо, което всъщност не съществува). Ето филтъра в три стъпки, който мобилният разработчик прилага към всеки изход на AI:
- Компилирайте и стартирайте. Кодът всъщност компилира ли се, отваря ли се приложението? API, предложен от AI, наистина ли е в SDK (комплект за разработка на софтуер — готовият набор от инструменти, предлагани от платформата)?
- Тествайте го. Тествайте очакваното поведение автоматично или ръчно. „Изглежда, че работи“ не е достатъчно; Опитайте крайни случаи (неактивни данни, без мрежа, отказано разрешение).
- Прегледайте и обосновете. Разбирате ли защо кодът е написан по този начин? Не публикувайте код, който не разбирате. Попитайте AI "какво прави този ред, защо е необходим?" попитайте.
Внимание: Номерата на версиите, имената на библиотеките и подписите на API, предоставени от YZ, може да са остарели или изфабрикувани. Той не може да знае за актуализации, пуснати след крайната дата (последната дата, на която моделът е бил обучен). Винаги проверявайте критична зависимост от официалната документация (Apple Developer, Android Developers).
три мини калъфа
Случай 1 — Ускоряване на разработката на екрана. Екип за електронна търговия изготви екрана с подробности за продукта с помощта на AI от Jetpack Compose (модерен набор от инструменти за интерфейс на Android). Първата чернова, която обикновено отнема 2 дни, излезе след 3 часа. Но екипът установи в теста, че форматирането на цената, произведено от AI, прави закръгляването на стотинка неправилно: 19,99 TL се появява като 20 TL на някои устройства. Ако нямаше проверка, тази грешка щеше да се активира. Печалбата е реална, но контролът е задължителен.
Случай 2 — Уловена халюцинация. Разработчик получи код от AI, за да поиска разрешение за местоположение в iOS. AI предложи функция, наречена requestPreciseLocationOnce(). Нямаше такъв API; Правилният беше requestWhenInUseAuthorization(). Грешката при компилирането разкри това веднага. Урок: компилаторът е най-честният одитор на AI.
Случай 3 — Капан за поверителност. Един екип постави потребителски доклади за грешки в AI и поиска решение. Докладите включват имейли и идентификатори на устройства на потребителите. Това означаваше изтичане на лични данни към услуга на трета страна и беше нарушение по отношение на KVKK (Закон за защита на личните данни). Решение: изчистване (маскиране) на лични полета, преди да се дадат данните на AI.
Слаба подкана / Силна подкана
Разликата между две подкани за една и съща работа определя качеството на изхода.
Слаба подкана: „Напишете ми екран за вход.“
Мощна подкана: „Създайте екран за вход с помощта на Jetpack Compose за Android. Изисквания: - Поле за имейл и парола; проверка на формата на имейла, парола от поне 8 знака - Бутонът „Вход“ е деактивиран по време на зареждане и показване на въртящия се бутон - Съобщенията за грешка се появяват в червен текст под полето - MVVM архитектура: състояние във ViewModel, само Composable UI - Kotlin, Material 3, minSdk 24Просто дайте кода, след това всеки раздел Обяснете в 1 изречение."
Втората подкана казва платформата, инструмента, архитектурата, границите и изходния формат. Не оставя нищо за AI да отгатне; Следователно дава много по-полезен и по-лесен за проверка резултат.
Копируеми стартови шаблони
Използвайте шаблоните по-долу, като ги попълните с вашия собствен контекст.
Шаблон за роля и контекст: „Вие сте старши [iOS/Android/Flutter] разработчик. Моят проект: [тип приложение], целева платформа [версия], архитектура [MVVM/Clean]. Задача: [какво искате]. Ограничения: [език, библиотека, версия]. Първо обобщете плана в 3 елемента, след това създайте кода, след това избройте рисковете.“
Шаблон за преглед на кода: „Разгледайте следния код на [език]. Идентифицирайте: 1) Грешки и рискове от сривове 2) Проблеми с паметта/производителността 3) Уязвимости в сигурността и поверителността 4) Къде може да се напише по-просто. Номера на редове за всеки елемент и предложете корекции.[код]“
Шаблон за обучение: „Обяснете [концепция, напр. async/await в Swift] от гледна точка на мобилен разработчик. Дайте прост пример, споменете 3 често срещани грешки и посочете кога не трябва да го използвам.“
Шаблон за проверка: „Вие предложихте този API/функция: [име]. Проверете: В коя версия на SDK влезе, какво разрешение изисква, отхвърлен ли е? Ако не сте сигурни, кажете „не съм сигурен, проверете в официалната документация“.“
Често срещани грешки
- Поставяне на изхода, без да го четете. Най-честата и най-опасната грешка. Дори и компилирана, логиката може да е грешна.
- Предоставяне на поверителни данни на AI. API ключ, потребителски данни, сертификат за подписване никога не се поставят в заявката.
- Версията и API не се проверяват. AI може да предложи остарели или измислени API; Официалният документ има последната дума.
- Оставяне на архитектурното решение на AI. „Коя е най-добрата архитектура?“ Отговорът на въпроса зависи от вашия проект; AI дава общ отговор, знаете контекста.
- Писане на един гигантски ред. Опит за решаване на сложна задача с една заявка; По-безопасно е да го разделите на малки, проверими стъпки.
- Искане на разрешения „за всеки случай“. AI понякога добавя повече разрешения от необходимото; Всяко разрешение представлява риск за одобрението на хранилището и доверието на потребителите.
В обобщение
AI играе две роли в мобилната разработка: асистент, който ускорява процеса на разработка, и възможност за вградено приложение. Шаблонният код осигурява огромно ускорение за чертане и обучение; Но решенията за архитектура, сигурност, разрешения и публикуване са човешки. Всеки изход се проверява чрез три стъпки: компилиране, тестване, преглед. Поверителни данни и лична информация никога не се предоставят на AI. Платформата със силно търсене ясно посочва инструмента, ограниченията и изходния формат. Тази дисциплина е основа за останалата част от модула.
Задача за приложение
Изберете екран от вашия собствен мобилен проект (или въображаемо „приложение за водене на бележки“). Напишете подкана за този екран, като използвате „Шаблон за роля и контекст“ по-горе. Опитайте да компилирате кода, генериран от AI, в проект и да го прекарате през филтър за проверка в три стъпки: компилира ли се, работи ли според очакванията, разбирате ли всеки ред? Отбележете поне един бъг или фалшив API, който намерите.
контролен списък
- [ ] Определих в коя от трите кофи попада задачата въз основа на нейното ниво на риск
- [ ] Посочих платформата, версията, архитектурата и ограниченията в заявката
- [ ] Компилирах резултата и го стартирах
- [ ] Тествах ограничени случаи (неактивни данни, без мрежа, отказано разрешение)
- [ ] Уверих се, че разбирам всеки ред
- [ ] Не предоставих никакви лични данни или лични ключове на AI
- [ ] Проверих критичните API от официалната документация