Наскрізний проект, відповідальне використання штучного інтелекту та дорожня карта в професії

Прибуток:

• Здатність розробляти наскрізну мобільну функцію, яку можна перевірити в дизайні, коді, інтеграції ШІ, конфіденційності, тестуванні, налагодженні, продуктивності та етапах випуску
• Здатність створити основу для відповідального та етичного використання штучного інтелекту з принципами прозорості, перевірки-підзвітності та справедливості-незлочинності.
• Здатність створити стійку професійну практику, розрізняючи сфери, де штучний інтелект сильний і слабкий, і залишаючи остаточне рішення в руках людей.

У цьому модулі ми використовували штучний інтелект на кожному етапі мобільної розробки: генерація коду, інтерфейс, інтеграція ШІ на пристрої та в хмарі, тестування, налагодження, продуктивність, конфіденційність і доставка до магазину. У цьому останньому розділі ми об’єднаємо всі ці частини в єдиний наскрізний потік, роз’яснимо основу для відповідального та етичного використання штучного інтелекту та поговоримо про те, як перетворити ці навички на сталу професійну практику. Основне повідомлення не змінилося, але тепер воно твердо встановлено: штучний інтелект – це сила, яка примножує компетентного мобільного розробника; це не заміна. Це особа, яка відповідає за якість, безпеку та перспективність продукту для користувача.

Наскрізна функція: об’єднання частин

Розробка реальної функції від початку до кінця з підтримкою штучного інтелекту об’єднує в ланцюжок усі вивчені нами підрозділи. Приклад: функція «додати витрати з квитанції». Потік працює так:

1. Дизайн (розділ 3). Створіть проект екрана та чотири стани (завантаження/порожній/помилка/повний) за допомогою штучного інтелекту, запитайте доступність із самого початку.
2. Код (блок 2). Створення камери, моделі даних і ViewModel шар за шаром за допомогою MVVM; перевірити кожен шар.
3. ШІ на пристрої (блок 4). Зчитування суми/дати з квитанції за допомогою розпізнавання тексту ML Kit; Розглянемо попередню обробку та оцінку достовірності.
4. Конфіденційність (розділ 9). Запит на дозвіл камери з найменшими привілеями, напишіть сценарій відхилення, зберігайте дані на пристрої.
5. Тестування (блок 6). Створення модульних тестів логіки вилучення, тестування інтерфейсу користувача дисплея; Включати прикордонні держави.
6. Налагодження (розділ 7). Попросіть ШІ проаналізувати збої в контексті та вирішити першопричину.
7. Виступ (блок 8). Виміряйте витрати батареї на обробку камери та налаштуйте її на зручне використання батареї.
8. Трансляція (блок 10). Прозоро повідомляйте про використання ШІ, правдиво заповнюйте форму конфіденційності та проводите самоперевірку.

На кожному кроці ШІ прискорюється, людина перевіряє та приймає рішення. Цей цикл є ядром модуля.

Порада: не намагайтеся змусити штучний інтелект виконати складну функцію за допомогою одного величезного запиту. Розбийте його на кроки, які можна перевірити, як описано вище. Тестування результатів кожного кроку та перехід до наступного безпечніше та, зрештою, швидше; Тому що велику помилку ловиш не в кінці, а на першому кроці.

Відповідальне та етичне використання ШІ

Тільки технічної компетентності недостатньо; відповідальний каркас завершує його. Три принципи:

Прозорість. Користувач повинен знати, що він або вона взаємодіє з ШІ. Таємний штучний інтелект є зловживанням довіри. Вміст, створений ШІ, позначається тегами; Поради штучного інтелекту представлені як «корисна порада», а не як «сувора правда».

Перевірка та звітність. Результат ШІ є відправною точкою, а не готовим продуктом. Ви несете відповідальність за кожен опублікований рядок коду, кожну відповідь ШІ, кожну транзакцію даних. «ШІ написав це так» не є захистом.

Справедливість і незлочинність. Моделі штучного інтелекту можуть мати упередження від даних, на яких вони навчаються. Розпізнавання обличчя може гірше працювати на деяких кольорах шкіри, система рекомендацій може виключити групу. Ви несете відповідальність за те, щоб ваш продукт належним чином працював у різних групах користувачів.

Увага: будь-яка техніка, яку ви вивчаєте у сфері ІТ та безпеки, використовується лише для дозволених і конструктивних цілей. Використання штучного інтелекту для створення зловмисного програмного забезпечення, злому чиєїсь програми без дозволу, збору даних користувачів без згоди або створення оманливого вмісту є незаконним і суперечить етиці професії. Міра сили виявляється там, де її не використовуєш.

Визнання обмежень ШІ

Зрілий розробник знає, де штучний інтелект блищить, а де йому не вистачає.

ШІ потужний

ШІ слабкий

Код форми, виготовлення котла

Товарні та архітектурні рішення

Проект тестування та документації

Розуміння бізнес-контексту та користувача

Читання журналу збоїв, сканування помилок

Остаточний діагноз першопричини (потрібна перевірка)

Навчання, пояснення концепції

Поточна/невироблена інформація API

Текст, опис, переклад

Етика, безпека та юридичне остаточне рішення

Інтерналізація цієї відмінності є ключовою для ефективного використання ШІ та уникнення його пасток.

три міні-чохла

Випадок 1 — Наскрізна швидкість. One solo developer finished the "unplugged" feature in 4 days with the 8-step flow above; Без штучного інтелекту оцінка становила 12 днів. Але оскільки він перевіряв кожен крок, публікацію було схвалено з першого разу. Швидкість була реальною, тому що дисципліна була реальною. Урок: AI + перевірка швидше, ніж AI - перевірка.

Випадок 2 — виявлено упередження. Під час тестування функції передбачення роду іменників на основі штучного інтелекту команда помітила систематичні помилки в деяких турецьких іменниках; модель була навчена переважно на англійських даних. Цю функцію змінено на запит користувача замість того, щоб робити неправильні припущення. Урок: робота розробника — перевірити упередженість навчання моделі.

Випадок 3. Захист «ШІ так сказав» розвалився. Розробник опублікував платіжний код, згенерований ШІ, не перевіривши його; В одному крайньому випадку код робив подвійні колекції. Відповідальність не знімається словами «це написав AI»; Як власник облікового запису, він був розробником. Урок: відповідальність не можна делегувати.

Слабка підказка / Сильна підказка

Слабка підказка: «Напишіть мені повну заявку на сканування квитанції».

Потужна підказка: «Допоможіть мені розробити функцію «додати витрати з квитанції» крок за кроком. Давайте продовжимо по порядку, коли я перевірю та схвалю кожен крок, переходьте до наступного: 1) Екран + чотири стани + доступність2) Шари MVVM (камера, модель, ViewModel)3) Зчитування суми/дати з квитанції за допомогою ML Kit + оцінка довіри4) Дозвіл камери (найменший привілей) + відмова flow5) Тести модулів і інтерфейсу користувача Розкажіть мені про ризики та моменти, які мені потрібно перевіряти на кожному кроці."

Шаблони, які можна копіювати

Шаблон наскрізного планування: «Я розроблю таку функцію: [функція]. Розбийте її на етапи, які можна перевірити: дизайн, код, інтеграція штучного інтелекту, конфіденційність/дозвіл, тестування, продуктивність, випуск. Напишіть результати, ризики та критерії перевірки для кожного кроку. Не створюйте жодного гігантського виробництва».

Шаблон аудиту етики/упередженості: «Перевірте таку функцію ШІ на справедливість і упередженість: [функція]. Які групи користувачів можуть працювати погано? Як тренувальні дані впливають на упередженість? Як це перевірити, як зробити більш інклюзивним?»

Шаблон перевірки підзвітності: «Перелічіть запитання про підзвітність, які я маю поставити перед випуском цього створеного штучним інтелектом коду/функції: чи зрозумів я це, чи перевірив я це, чи безпечно, чи прозоро для користувача, чи законно/етично?»

Шаблон безперервного навчання: «Запропонуйте 4-тижневий практичний план для вдосконалення моїх навичок штучного інтелекту в мобільному розробнику: одна тема щотижня (код, інтеграція, тестування, випуск), з метою невеликого проекту та звички перевірки».

Поширені помилки

• Створення складної функції з одним гігантським запитом. Неможливо перевірити; розбийте його на кроки.
• Уникнення відповідальності, кажучи «ШІ так написав». Ви несете відповідальність за опублікований код.
• Не тестування на упередженість AI. Модель може погано працювати в деяких групах; Випробуйте справедливість.
• Приховування взаємодії ШІ від користувача. Прозорість є основою довіри.
• Забувши про обмеження ШІ. Люди мають останнє слово щодо архітектури, етики та поточного API.
• Перестати вчитися. Інструменти та правила магазину швидко змінюються; Постійно оновлюйтеся.

Підсумовуючи

Наскрізна функція об’єднує всі частини модуля в ланцюжку: дизайн, код, інтеграцію ШІ, конфіденційність, тестування, налагодження, продуктивність і випуск. На кожному кроці ШІ прискорюється, людина перевіряє та приймає рішення; Комплексна робота розбивається на невеликі етапи, які можна перевірити. Відповідальне використання базується на трьох принципах: прозорість, перевірка-підзвітність і справедливість-не зашкодь. ШІ є потужним мультиплікатором, але люди мають останнє слово щодо архітектури, етики, безпеки та сучасних знань. «ШІ зробив це саме так» не є захистом; Ви несете відповідальність за свій продукт і обіцянки, які ви даєте своєму користувачеві. Завдяки цій дисципліні штучний інтелект робить вас швидшими, комплекснішими та сильнішими протягом вашої кар’єри.

Аплікаційне завдання

Розбийте мобільну функцію за вашим вибором (наприклад, «підведення підсумків за допомогою голосових нотаток» або «розпізнавання продукту з фотографії») на етапи, які можна перевірити, за допомогою «шаблону наскрізного планування». Насправді розробіть і перевірте принаймні один крок за допомогою ШІ. Потім проаналізуйте, які групи користувачів ця функція може спричинити проблеми за допомогою «шаблону контролю етики/упередженості», і дайте відповіді на запитання, які потрібно поставити перед випуском за допомогою «шаблону контролю відповідальності».

контрольний список

• [ ] Я розділив функцію на невеликі кроки, які можна перевірити, а не на окреме гігантське виробництво
• [ ] Я перевіряв результати ШІ на кожному кроці та прийняв рішення
• [ ] Я прозоро представив взаємодію ШІ для користувача
• [ ] Я оцінив, чи функція працює справедливо/упереджено в різних групах
• [ ] Я відповів на запитання про відповідальність перед випуском (зрозуміло/тестування/безпечно/етично)
• [ ] Я використовував ШІ лише для компетентних і конструктивних цілей і планую продовжувати навчання

Модульний екзамен

1. Що з наведеного нижче є найточнішим позиціонуванням штучного інтелекту в мобільній розробці?

• А) ШІ замінює розробника; можна публікувати безпосередньо без читання коду, який він генерує
• Б) Штучний інтелект працює лише над написанням тексту, він не має нічого спільного з генерацією коду
• В) Штучний інтелект – помічник і прискорювач; Відповідальність за рішення щодо архітектури, безпеки та трансляції лежить на людях ✔
• D) Оскільки штучний інтелект завжди створює правильний код, додаткове тестування та перевірка не потрібні

Опис: Штучний інтелект – це помічник і прискорювач, який генерує код, креслення та рішення. Відповідальність та остаточне затвердження таких рішень, як архітектура, дозвіл, безпека та публікація, покладається на компетентного розробника; Люди відповідають за кожен опублікований рядок.

2. Під час запиту мобільного коду від штучного інтелекту, що найбільше підвищує архітектурну якість створюваного коду?

• A) Зробіть підказку якомога коротшою та скажіть «напишіть мені програму»
• B) Спочатку нав’яжіть архітектуру на кшталт MVVM і запитуйте код невеликими частинами, шар за шаром ✔
• C) Створення всієї функції як одного гігантського файлу в одному запиті
• D) Не вказуйте архітектуру взагалі та залиште найкраще рішення штучному інтелекту

Пояснення: нав’язування такої архітектури, як MVVM, і вимога шару за рівнем перед написанням коду безпосередньо в ШІ створює структуру, яку можна перевірити та підтримувати, яка відокремлює логіку від екрана. Запит без архітектури повертає код, який запихає все на екран.

3. Що найчастіше не враховують при створенні інтерфейсу зі штучним інтелектом і що найбільш критично в реальному використанні?

• A) Розробка станів завантаження, порожнього та помилок, а не лише на весь екран ✔
• B) Створення лише найкращого вигляду на весь екран, пропускаючи інші випадки
• C) Додавання якомога більшої кількості кольорів та анімації до кожного екрана
• D) Залиште теги доступності останніми та торкайтеся лише зовнішнього вигляду

Пояснення: розробники часто розглядають лише «повний» стан; тоді як насправді користувач здебільшого стикається зі станами завантаження, порожнього та помилок. Створення всіх чотирьох станів (завантаження/порожній/помилка/повний) — секрет надійного інтерфейсу.

4. Чому ШІ на пристрої часто є вибором за умовчанням для функції, яка обробляє конфіденційні особисті дані (наприклад, вимірювання стану здоров’я)?

• A) Моделі на пристрої завжди точніші, ніж хмарні
• B) Обробка на пристрої ніколи не вимагає витрат на батарею чи процесор
• C) Обробка на пристрої необмежена щодо розміру моделі
• D) Оскільки дані не залишають телефон, це забезпечує велику перевагу з точки зору конфіденційності та довіри користувачів ✔

Пояснення: обробка на пристрої не видаляє дані з телефону; Це велика перевага з точки зору дотримання конфіденційності та довіри користувачів, а також працює в автономному режимі та миттєво. Його межею є потужність пристрою і розмір моделі.

5. Яка найпоширеніша «тиха» помилка, яка призводить до безглуздих результатів і не створює повідомлення про помилку під час інтеграції моделі на пристрої?

• A) Неправильне написання назви файлу моделі
• B) Низька роздільна здатність значка програми
• C) Неправильна попередня обробка вхідних даних (розмір/нормалізація) ✔
• D) Темна тема екрана

Пояснення: неправильна попередня обробка вхідних даних призведе до абсолютно неправильних результатів без помилок. Значення попередньої обробки слід перевіряти з документації моделі.

6. Яке правило є найбільш критичним для безпеки під час інтеграції хмарного LLM у мобільну програму?

• A) Ключ API слід зберігати лише у серверній частині, а не на клієнті; запити мають проходити через проксі ✔
• Б) Для зручності ключ API має бути вбудований безпосередньо в код програми
• C) Ключ API має бути спільно використаний в описі програми
• D) Ключ API слід зберігати в клієнті та приховувати, лише змінивши назву.

Розкриття інформації: ключ API ніколи не вбудовується в код мобільної програми; тому що програму можна реконструювати та витягти ключ. Правильна архітектура полягає у збереженні ключа лише у серверній частині та передачі запитів через ваш власний проксі-сервер.

7. Що найбільше підвищує швидкість, яку сприймає користувач, і швидкість завершення функцій у довгих відповідях LLM?

• A) Очікування, поки буде отримана вся відповідь, і показ її одразу
• B) Показ відповіді слово за словом, у міру її створення, з потоковою передачею ✔
• C) Надсилання всієї історії чату моделі з кожним запитом
• D) Збільште типову інструкцію, щоб якомога більше розширити відповідь

Опис: Потокове передавання значно збільшує сприйняту швидкість і плавність, відображаючи відповідь, коли вона створюється слово за словом. Замість того, щоб чекати на порожньому екрані, користувач спостерігає за текстовою формою; Це значно знижує відсоток залишення.

8. Яка найпоширеніша проблема в тестах, створених штучним інтелектом, робить тест марним?

• A) Тести охоплюють занадто багато граничних станів
• Б) У тестах використовуються макетні об’єкти, а не реальні служби
• C) Тести виконуються дуже швидко
• D) Роздуття області порожніми/некорисними тестами, які фактично не перевіряють поведінку ✔

Пояснення: Штучний інтелект іноді створює тести, які фактично не перевіряють вихідні дані (наприклад, просто викличте функцію та напишіть порожнє твердження). Вони завищують кількість покриття, але не забезпечують реального захисту; Кожен тест необхідно перевірити, щоб перевірити значущу поведінку.

9. Чому заглушити аварійне завершення роботи за допомогою підказки штучного інтелекту не є достатнім рішенням?

• A) try-catch взагалі не можна використовувати в мобільних додатках
• B) Збій припиняється, але оскільки основна причина не усунена, проблема повертається в іншій формі ✔
• C) Використання try-catch сповільнює роботу програми, тому це заборонено
• D) Заглушена помилка автоматично відхиляється магазином

Пояснення: замовчування симптому не усуває першопричину; Збій припиняється, але початкова проблема (наприклад, розрив з’єднання даних) повертається в іншій формі (наприклад, втрата даних). Метою професійного налагодження є усунення першопричини, а не симптому.

10. Якого основного золотого правила слід дотримуватися при оптимізації продуктивності?

• A) Спочатку візьміть профіль і виміряйте реальне вузьке місце, а потім оптимізуйте ✔
• B) Вгадування, де відбувається повільно, і концентрація там
• C) Гонитва за невеликими перевагами в кожній функції
• D) Вимірювання продуктивності на емуляторі та ніколи не пробування реального пристрою

Опис: спочатку виміряйте, потім оптимізуйте. Справжнє вузьке місце майже завжди знаходиться в іншому місці, ніж передбачувано; Оптимізація без профілювання є сліпим припущенням і часто марною тратою зусиль.

11. Яка найважливіша інженерна проблема для постійно запущеної функції ШІ (наприклад, трансляція з камери в реальному часі)?

• A) Функція запитує якомога більше дозволів
• B) Управління вартістю батареї та процесора безперервної обробки з частотою вибірки та пакетною обробкою ✔
• C) Запускайте функцію лише на найдорожчих телефонах
• D) Постійне рендеринг камери з максимально можливою частотою кадрів

Опис: Постійно робоча модель, камера та мережа; Він може швидко витрачати заряд батареї, нагрівати пристрій і бути обмеженим системою. Зменшення частоти вибірки, пакетування та запуск лише за потреби – це способи керування витратами акумулятора.

12. Що означає принцип «найменших привілеїв» в управлінні дозволами в мобільній розробці?

• A) Запит усіх можливих дозволів під час запуску, про всяк випадок.
• Б) Виведення програми з ладу, якщо в дозволі відмовлено
• C) Запит на найширший дозвіл і планування звузити його пізніше.
• D) Запит лише фактично необхідного дозволу, коли це необхідно та в найвужчому обсязі, зі сценарієм відмови ✔

Пояснення: Найменший привілей запитує лише той дозвіл, який дійсно потрібен, коли він потрібен і в якомога меншому обсязі. Забагато дозволів підриває довіру користувачів, призводить до відхилення сховища та збільшує ризик витоку даних.

13. Які конкретні вимоги повинні бути виконані при представленні до магазину програми зі штучним інтелектом?

• A) Прозорість контенту, контроль вмісту та розкриття даних, які надходять до штучного інтелекту, у формі конфіденційності ✔
• B) Приховування використання штучного інтелекту від користувача
• C) Позначення даних, які насправді не збираються у формі конфіденційності
• Г) Перспективні функції, яких немає в описі

Розкриття інформації: магазини очікують прозорості вмісту (заяви про те, що він створює штучний інтелект), модерування вмісту (фільтрування шкідливого виводу та сповіщення користувачів) і розкриття інформації про використання даних із програм, що містять штучний інтелект; Потрібне попередження про точність у чутливій зоні. Заявки, у яких вони відсутні, будуть відхилені.

14. Чому захист «ШІ так написав» є недійсним, коли в опублікованому коді, згенерованому штучним інтелектом, виникає гранична помилка?

• A) Оскільки штучний інтелект завжди створює код без помилок, помилка походить від користувача
• B) Оскільки автоматично зберігає правильний код, згенерований ШІ
• В) Тому що відповідальність не можна перекласти на штучний інтелект; Розробник відповідає за опублікований код і дані ✔
• D) Тому що створений штучним інтелектом код ніколи не публікується

Опис: результати ШІ є відправною точкою, а не готовим продуктом. Саме розробник відповідає за кожен опублікований рядок, кожну оброблену інформацію та кожну обіцянку; відповідальність не може бути делегована штучному інтелекту, тому результати повинні бути зрозумілі та перевірені перед публікацією.