Прибуток:
- Можливість розрізнити, де штучний інтелект забезпечує реальну швидкість мобільної розробки (код шаблону, чернетка, навчання), а де (архітектура, дозвіл, безпека, публікація) рішення залишається за людиною, залежно від рівня ризику завдання.
- Можливість застосовувати дисципліну, яка перевіряє кожен результат штучного інтелекту за допомогою етапів компіляції, тестування та перегляду
- Здатність виробити звичку писати сильні, заповнені контекстом підказки та захищати особисті дані та секретні ключі, не передаючи їх ШІ
Розробка мобільних додатків є однією з найбільш конкурентоспроможних сфер програмного забезпечення у світі. Ми говоримо про продукт, який працює на мільярдах пристроїв, цикл оновлення якого залежить від схвалення магазину та постійно вимірюється в кишені користувача. Штучний інтелект (ШІ — програмні системи, які можуть виробляти текст, код і рішення, як люди) увійшов у цю сферу двома способами: по-перше, як допомога, що прискорює процес розробки (генерація коду, налагодження, написання тестів), і по-друге, як можливість, вбудована в додаток (розпізнавання зображень на пристрої, помічник у чаті, система рекомендацій). Цей модуль навчає обох наскрізно. Але давайте з самого початку сформулюємо одне речення: ШІ не замінює мобільного розробника; розширює свою продуктивність і сферу застосування. Ви несете відповідальність за кожен виданий рядок коду, кожен запитуваний дозвіл і кожну транзакцію, здійснену з даними користувача.
У цьому розділі ми побачимо, де штучний інтелект створює справжню цінність у розробці мобільних пристроїв, де він повинен поступатися людям, як перевіряти кожен результат і чому дисципліна конфіденційності та безпеки не підлягає обговоренню.
Де ШІ стане в нагоді в мобільній розробці?
Мобільна розробка складається з багатьох повторюваних і шаблонних завдань: написання коду перегляду, налаштування рівня мережевого запиту, визначення моделі даних, створення тестового випадку, вирішення повідомлення про помилку. ШІ створює ці шаблони дуже швидко. Навпаки, архітектурні рішення, переваги взаємодії з користувачем, межі безпеки та точність бізнес-логіки є сферою діяльності людей.
Корисно розділити завдання на три групи залежно від рівня ризику:
Тип завдання
Роль ШІ
чоловіча роль
Код шаблону (шаблонний), зразок екрана, перетворення
Генерує протяг, прискорює його
Переглядає, інтегрує
Бізнес-логіка, потік даних, інтеграція API
Надає пропозиції та проекти
Перевіряє, тестує, підтверджує
Архітектура, запит на дозвіл, безпека, рішення про трансляцію
Перелічує варіанти та обґрунтування
Приймає рішення і несе відповідальність
Ця таблиця буде нашим компасом протягом усього модуля. Правий стовпець ніколи не передається ШІ.
Порада: сприймайте AI як «дуже швидкого, але недосвідченого стажера». Ви ставите йому чітке завдання, читаєте його роздруківку, тестуєте його і берете на себе відповідальність. Ви не надсилаєте створений стажером код у виробництво (живе середовище), не прочитавши його; Це ж правило стосується ШІ.
Перевірочна дисципліна: три кроки
ШІ-текст плавний і виглядає впевнено; Але вільність - це не точність. ШІ іноді підходить для функції бібліотеки, якої не існує (це називається галюцинацією — модель впевнено виробляє щось, чого насправді не існує). Ось триетапний фільтр, який розробник мобільних пристроїв застосовує до кожного результату ШІ:
- Скомпілюйте та запустіть. Чи дійсно код компілюється, чи відкривається програма? Чи API, запропонований штучним інтелектом, справді міститься в SDK (набір для розробки програмного забезпечення — готовий набір інструментів, які пропонує платформа)?
- Перевірте це. Перевірте очікувану поведінку автоматично або вручну. «Здається, це працює» недостатньо; Спробуйте крайні випадки (неактивні дані, відсутність мережі, відмову в дозволі).
- Перегляньте та обґрунтуйте. Ви розумієте, чому код написаний саме так? Не публікуйте код, який ви не розумієте. Запитайте ШІ «що робить ця лінія, навіщо вона потрібна?» запитати.
Увага: номери версій, назви бібліотек і підписи API, надані YZ, можуть бути застарілими або сфабрикованими. Він не може знати про оновлення, випущені після кінцевої дати (останньої дати навчання моделі). Завжди перевіряйте критичну залежність з офіційної документації (Apple Developer, Android Developers).
три міні-чохла
Випадок 1 — Прискорення розробки екрана. Команда електронної комерції розробила екран детальної інформації про продукт за допомогою штучного інтелекту від Jetpack Compose (набір інструментів для сучасного інтерфейсу Android). Перший проект, який зазвичай займає 2 дні, вийшов за 3 години. Але під час тестування команда виявила, що форматування ціни, створене штучним інтелектом, неправильно округлювало пенні: 19,99 TL відображалося як 20 TL на деяких пристроях. Якби не було перевірки, ця помилка була б активна. Прибуток реальний, але контроль обов'язковий.
Випадок 2 — спіймана галюцинація. Розробник отримав код від штучного інтелекту для запиту дозволу на місцезнаходження в iOS. AI запропонував функцію під назвою requestPreciseLocationOnce(). Такого API не було; Правильним був запитWhenInUseAuthorization(). Помилка компіляції виявила це негайно. Урок: компілятор є найчеснішим аудитором ШІ.
Випадок 3 — Пастка конфіденційності. Одна команда вставила звіти про помилки користувача в AI і попросила рішення. Звіти містили адресу електронної пошти та ідентифікатори пристроїв користувачів. Це означало витік персональних даних на сторонній сервіс і було порушенням КВКК (Закон про захист персональних даних). Рішення: очищення (маскування) особистих полів перед передачею даних ШІ.
Слабка підказка / Сильна підказка
Різниця між двома підказками для однієї роботи визначає якість результату.
Слабка підказка: «Напишіть мені екран входу».
Потужна підказка: «Створіть екран входу за допомогою Jetpack Compose для Android. Вимоги:- Поле електронної пошти та пароля; перевірка формату електронної пошти, пароль принаймні з 8 символів- Кнопка «Увійти» вимкнена під час завантаження та показує лічильник- Повідомлення про помилки з’являються червоним текстом під полем- Архітектура MVVM: стан у ViewModel, лише Composable UI- Kotlin, Material 3, minSdk 24Just give код, потім кожен розділ Поясніть 1 реченням».
У другому запиті вказано платформу, інструмент, архітектуру, межі та вихідний формат. Це не залишає нічого для здогадок ШІ; Таким чином, це дає набагато корисніший і легший для перевірки результат.
Початкові шаблони, які можна копіювати
Використовуйте наведені нижче шаблони, заповнюючи їх власним контекстом.
Роль і шаблон контексту: «Ви старший [iOS/Android/Flutter] розробник. Мій проект: [тип програми], цільова платформа [версія], архітектура [MVVM/Clean]. Завдання: [що ви хочете]. Обмеження: [мова, бібліотека, версія]. Спочатку узагальніть план у 3 пункти, потім створіть код, а потім перелічіть ризики.»
Шаблон перевірки коду: «Перегляньте наступний [мовний] код. Визначте: 1) Помилки та ризики збою 2) Проблеми з пам’яттю/продуктивністю 3) Уразливості безпеки та конфіденційності 4) Де це можна написати простіше. Номери рядків для кожного елемента та запропонуйте виправлення.[код]»
Навчальний шаблон: «Поясніть [концепцію, наприклад, async/await у Swift] з точки зору розробника мобільних пристроїв. Наведіть простий приклад, згадайте 3 поширені помилки та вкажіть, коли мені не слід його використовувати».
Шаблон перевірки: «Ви запропонували цей API/функцію: [назва]. Перевірте: яку версію SDK він отримав, який дозвіл для нього потрібен, чи він застарілий? Якщо не впевнені, скажіть «не впевнений, перевірте офіційну документацію».»
Поширені помилки
- Вставлення результату, не читаючи його. Найпоширеніша і найнебезпечніша помилка. Навіть якщо скомпільовано, логіка може бути неправильною.
- Передача конфіденційних даних ШІ. Ключ API, дані користувача, сертифікат підпису ніколи не вставляються в запит.
- Версія та API не перевіряються. AI може запропонувати застарілі або вигадані API; Останнє слово за офіційним документом.
- Залишаючи архітектурне рішення ШІ. «Яка архітектура найкраща?» Відповідь на запитання залежить від вашого проекту; ШІ дає загальну відповідь, ви знаєте контекст.
- Написання однієї гігантської підказки. Спроба вирішити складну задачу одним запитом; Безпечніше розбити це на невеликі кроки, які можна перевірити.
- Запит дозволу «про всяк випадок». ШІ іноді додає більше дозволів, ніж потрібно; Кожен дозвіл створює ризик для схвалення зберігання та довіри користувача.
Підсумовуючи
Штучний інтелект відіграє дві ролі в мобільній розробці: помічник, який прискорює процес розробки, і можливість вбудованої програми. Шаблонний код забезпечує величезне прискорення для складання та навчання; Але рішення щодо архітектури, безпеки, дозволів і публікації є людськими. Кожен результат перевіряється за допомогою трьох етапів: компілювання, тестування, перегляд. Конфіденційні дані та особиста інформація ніколи не передаються ШІ. Платформа сильного попиту чітко визначає інструмент, обмеження та формат виведення. Ця дисципліна є основою для решти модуля.
Аплікаційне завдання
Виберіть екран із власного мобільного проекту (або уявної «програми для створення нотаток»). Напишіть підказку для цього екрана, використовуючи «Шаблон ролі та контексту» вище. Спробуйте скомпілювати згенерований штучним інтелектом код у проект і пропустити його через триетапний фільтр перевірки: чи він скомпільований, чи працював, як очікувалося, чи ви зрозуміли кожен рядок? Занотуйте принаймні одну знайдену помилку або підроблений API.
контрольний список
- [ ] Я визначив, до якого з трьох сегментів належить завдання, виходячи з його рівня ризику
- [ ] У запиті я вказав платформу, версію, архітектуру та обмеження
- [ ] Я скомпільував результат і запустив його
- [ ] Я протестував граничні випадки (неактивні дані, відсутність мережі, дозвіл відмовлено)
- [ ] Я переконався, що розумію кожен рядок
- [ ] Я не надавав жодних особистих даних чи закритих ключів ШІ
- [ ] Я перевірив критичні API з офіційної документації