Проект от край до край, отговорно използване на изкуствен интелект и пътна карта в професията

Печалби:

• Възможност за разработване на мобилна функция от край до край и проверима в дизайн, код, AI интеграция, поверителност, тестване, отстраняване на грешки, производителност и стъпки за пускане
• Способност за създаване на рамка за отговорно и етично използване на изкуствения интелект с принципите на прозрачност, проверка-отчетност и справедливост-безвредност.
• Възможност за създаване на устойчива професионална практика чрез разграничаване на областите, в които изкуственият интелект е силен и слаб и запазване на крайното решение в ръцете на хората.

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

Функция от край до край: комбиниране на части

Разработването на истинска функция от началото до края с поддръжка на AI съчетава всяка единица, която сме научили във верига. Пример: функция „добавяне на разход от разписка“. Потокът работи по следния начин:

1. Дизайн (Единица 3). Начертайте екрана и четири състояния (зареждане/празно/грешка/пълно) с AI, поискайте достъпност от самото начало.
2. Код (Единица 2). Генерирайте камера, модел на данни и ViewModel слой по слой с MVVM; проверете всеки слой.
3. AI на устройството (Единица 4). Прочетете сумата/датата от разписката с ML Kit разпознаване на текст; Помислете за предварителна обработка и оценяване на увереността.
4. Поверителност (Единица 9). Поискайте разрешение за камера с най-малко привилегии, напишете сценария за отхвърляне, запазете данните на устройството.
5. Тестване (Единица 6). Генериране на модулни тестове на логиката за извличане, UI тестване на дисплея; Включете гранични държави.
6. Отстраняване на грешки (Единица 7). Накарайте AI да анализира сривовете с контекст и да разреши първопричината.
7. Изпълнение (Единица 8). Измерете разхода на батерията за обработка на камерата и я настройте щадяща батерията.
8. Излъчване (Единица 10). Докладвайте прозрачно за използването на AI, попълнете вярно формуляра за поверителност и направете самотест.

На всяка стъпка AI ускорява, човекът проверява и решава. Този цикъл е ядрото на модула.

Съвет: Не се опитвайте да накарате AI да направи сложна функция с една огромна заявка. Разбийте го на проверими стъпки като по-горе. Тестването на резултата от всяка стъпка и преминаването към следващата е едновременно по-безопасно и в крайна сметка по-бързо; Защото хващаш голяма грешка не накрая, а на първата стъпка.

Отговорно и етично използване на AI

Само техническа компетентност не е достатъчна; отговорна рамка го допълва. Три принципа:

Прозрачност. Потребителят трябва да знае, че той или тя взаимодейства с AI. Тайният AI е злоупотреба с доверие. Генерираното от AI съдържание е маркирано; AI съветите се представят като „полезни съвети“, а не като „твърда истина“.

Проверка и отчетност. Изходът от AI е отправна точка, а не завършен продукт. Вие носите отговорност за всеки публикуван ред код, всеки отговор на AI, всяка транзакция с данни. „ИИ го е написал така“ не е защита.

Справедливост и невредимост. AI моделите могат да носят отклонения от данните, върху които са обучени. Разпознаването на лица може да работи по-зле при някои цветове на кожата, системата за препоръки може да изключи група. Ваша отговорност е да тествате дали вашият продукт работи сравнително сред различни потребителски групи.

Внимание: Всяка техника, която научите в областта на ИТ и сигурността, се използва само за разрешени и конструктивни цели. Използването на AI за създаване на злонамерен софтуер, кракване на нечие друго приложение без разрешение, събиране на потребителски данни без съгласие или създаване на подвеждащо съдържание е незаконно и противоречи на етиката на професията. Мярката за сила се разкрива там, където не я използвате.

Признаване на ограниченията на AI

Зрелият разработчик знае къде AI блести и къде не достига.

AI е мощен

AI е слаб

Код на матрицата, производство на бойлер

Продуктови и архитектурни решения

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

Разбиране на бизнес контекста и потребителя

Четене на регистър на сривовете, сканиране на грешки

Окончателна диагноза на първопричината (изисква се проверка)

Учене, обяснение на концепцията

Текуща/неизмислена информация за API

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

Етика, сигурност и правно окончателно решение

Интернализиране на това разграничение е от ключово значение за ефективното използване на AI и избягване на неговите капани.

три мини калъфа

Случай 1 — Скорост от край до край. Един соло разработчик завърши функцията „изключен“ за 4 дни с потока от 8 стъпки по-горе; Без AI прогнозата беше 12 дни. Но тъй като той проверяваше всяка стъпка, публикацията беше одобрена от първия път. Скоростта беше истинска, защото дисциплината беше истинска. Урок: AI + проверката е по-бърза от AI - проверката.

Случай 2 — Уловено пристрастие. Докато тества базирана на изкуствен интелект функция за предсказване на пола на съществителните, екип забеляза систематични грешки в някои турски съществителни; моделът беше обучен на предимно английски данни. Функцията е променена да пита потребителя, вместо да прави грешни предположения. Урок: работа на разработчика е да тества пристрастията към обучението на модела.

Случай 3 — Защитата „AI каза така“ се срина. Разработчик публикува код за плащане, генериран от AI, без да го провери; В един краен случай кодът правеше двойни колекции. Отговорността не се премахва, като се каже „AI го е написал“; Като титуляр на акаунта той беше разработчик. Поука: отговорността не може да бъде делегирана.

Слаба подкана / Силна подкана

Слаба подкана: „Напишете ми пълно заявление за сканиране на разписка.“

Мощна подкана: „Помогнете ми да разработя функцията „добавяне на разход от разписка“ стъпка по стъпка. Нека продължим по ред, когато проверя и одобря всяка стъпка, преминете към следващата: 1) Екран + четири състояния + достъпност2) MVVM слоеве (камера, модел, ViewModel)3) Сума/дата на четене от разписка с ML Kit + рейтинг на доверие4) Разрешение за камера (най-малка привилегия) + отхвърляне flow5) Тестове на единици и UI Кажете ми рисковете и точките, които трябва да проверявам на всяка стъпка."

Копируеми шаблони

Шаблон за планиране от край до край: „Ще разработя следната функция: [характеристика]. Разбийте я на проверими стъпки: дизайн, код, AI интеграция, поверителност/разрешение, тестване, производителност, издание. Напишете изхода, риска и критериите за проверка за всяка стъпка. Не правете нито едно гигантско производство.“

Шаблон за одит на етика/пристрастие: „Проверете следната функция на ИИ за справедливост и пристрастност: [функция]. Кои потребителски групи може да се представи лошо? Как данните от обучението влияят на пристрастията? Как да го тествам, как да го направя по-приобщаващ?“

Шаблон за проверка на отчетността: „Избройте въпросите за отчетност, които трябва да задам, преди да пусна този генериран от AI код/функция: разбрах ли го, тествал ли съм го, безопасно ли е, прозрачно ли е за потребителя, законно/етично ли е?“

Шаблон за непрекъснато обучение: „Предложете 4-седмичен практически план за подобряване на уменията ми за AI в мобилен разработчик: една тема всяка седмица (код, интеграция, тестване, пускане), с цел малък проект и навик за проверка.“

Често срещани грешки

• Създаване на сложна функция с една огромна заявка. Не може да се провери; разбийте го на стъпки.
• Избягване на отговорност, като се каже "ИИ е написал така". Вие носите отговорност за публикувания код.
• Не се тества за отклонение от AI. Моделът може да работи зле в някои групи; Тествайте справедливостта.
• Скриване на взаимодействие с AI от потребителя. Прозрачността е в основата на доверието.
• Забравяйки ограниченията на AI. Хората имат последната дума по отношение на архитектурата, етиката и текущия API.
• Да спра да уча. Инструментите и правилата на магазина се променят бързо; Бъдете постоянно актуализирани.

В обобщение

Функция от край до край комбинира всички части на модула във верига: дизайн, код, AI интеграция, поверителност, тестване, отстраняване на грешки, производителност и освобождаване. На всяка стъпка AI ускорява, хората проверяват и решават; Сложната работа е разделена на малки проверими стъпки. Отговорното използване се основава на три принципа: прозрачност, проверка - отчетност и справедливост - не вреди. AI е мощен мултипликатор, но хората имат последната дума по отношение на архитектурата, етиката, сигурността и текущите знания. „ИИ го направи по този начин“ не е защита; Вие носите отговорност за вашия продукт и обещанието, което давате на вашия потребител. С тази дисциплина AI ви прави по-бързи, по-всеобхватни и по-силни през цялата ви кариера.

Задача за приложение

Разбийте мобилна функция по ваш избор (напр. „обобщаване чрез водене на гласови бележки“ или „разпознаване на продукт от снимка“) на проверими стъпки с „шаблон за планиране от край до край“. Всъщност разработете и валидирайте поне една стъпка с AI. След това анализирайте кои групи потребители функцията може да причини проблеми с „шаблон за контрол на етика/пристрастия“ и отговорете на въпросите, които трябва да зададете преди пускането с „шаблон за контрол на отговорността“.

контролен списък

• [ ] Разделих функцията на проверими малки стъпки, а не на едно гигантско производство
• [ ] Проверих резултата от AI на всяка стъпка и взех решението
• [ ] Представих взаимодействието с AI прозрачно на потребителя
• [ ] Оцених дали функцията работи справедливо/предубедено в различни групи
• [ ] Отговорих на въпроси относно отговорността преди пускането на пазара (разбрано/тестващо/безопасно/етично)
• [ ] Използвал съм AI само за компетентни и конструктивни цели и планирам да продължа да уча

Изпит по модул

1. Кое от следните е най-точното позициониране на изкуствения интелект в мобилното развитие?

• A) AI замества разработчика; може да се публикува директно, без да се чете кодът, който генерира
• Б) Изкуственият интелект работи само при писане на текст, няма нищо общо с генерирането на код
• В) Изкуственият интелект е помощник и ускорител; Отговорността за решенията за архитектура, сигурност и излъчване се носи от хората ✔
• Г) Тъй като изкуственият интелект винаги създава правилен код, не са необходими допълнителни тестове и верификации

Описание: Изкуственият интелект е асистент и ускорител, който генерира код, чертежи и решения. Отговорността и окончателното одобрение на решения като архитектура, разрешителни, сигурност и публикуване са на компетентния разработчик; Хората са отговорни за всеки публикуван ред.

2. Когато се иска мобилен код от изкуствен интелект, какво повишава най-много архитектурното качество на произведения код?

• A) Направете подканата възможно най-кратка и кажете „напишете ми приложение“
• B) Първо, наложете архитектура като MVVM и поискайте кода на малки части, слой по слой ✔
• C) Създаване на цялата функция като единичен огромен файл в един подкана
• D) Изобщо не уточнявайте архитектурата и оставете най-доброто решение на изкуствения интелект

Обяснение: Налагането на архитектура като MVVM и изискването слой по слой преди писане на код директно към AI създава тествана и поддържаема структура, която отделя логиката от екрана. Заявката без архитектура връща код, който натъпква всичко на екрана.

3. Какво най-често се пренебрегва при създаването на интерфейс с изкуствен интелект и кое е най-критично при реална употреба?

• A) Проектиране на състояния на зареждане, празно и грешки, не само на цял екран ✔
• B) Създаване само на най-добре изглеждащия цял екран, пропускане на други случаи
• C) Добавяне на възможно най-много цветове и анимации към всеки екран
• Г) Оставянето на маркерите за достъпност последни и само справяне с външния вид

Обяснение: Разработчиците често вземат предвид само 'пълното' състояние; докато в действителност потребителят най-често среща състояния на зареждане, празни и грешки. Генерирането на всичките четири състояния (зареждане/празно/грешка/пълно) е тайната на стабилния интерфейс.

4. Защо AI на устройството често е изборът по подразбиране за функция, която обработва чувствителни лични данни (напр. измерване на здравето)?

• A) Моделите на устройството винаги са по-точни от облака
• B) Обработката на устройството никога не води до разходи за батерия или процесор
• C) Обработката на устройството е неограничена по отношение на размера на модела
• D) Тъй като данните не напускат телефона, това осигурява силно предимство по отношение на поверителността и доверието на потребителите ✔

Обяснение: Обработката на устройството не премахва данни от телефона; Това е силно предимство по отношение на спазването на поверителността и доверието на потребителите, плюс това работи офлайн и мигновено. Ограничението му е мощността на устройството и размерът на модела.

5. Коя е най-честата „тиха“ грешка, която причинява безсмислени резултати и не извежда съобщение за грешка при интегриране на модел на устройство?

• A) Грешно изписване на името на файла на модела
• B) Ниска резолюция на иконата на приложението
• C) Неправилна предварителна обработка на входа (размер/нормализиране) ✔
• D) Тъмна тема на екрана

Обяснение: Неправилното извършване на предварителна обработка на входа ще доведе до напълно грешни резултати, без да генерира грешки. Стойностите за предварителна обработка трябва да бъдат проверени от документацията на модела.

6. Кое е най-критичното за сигурността правило при интегриране на облачен LLM в мобилно приложение?

• A) API ключът трябва да се съхранява само в бекенда, а не на клиента; заявките трябва да минават през прокси ✔
• B) API ключът трябва да бъде вграден директно в кода на приложението за удобство
• C) API ключът трябва да бъде споделен в описанието на приложението
• D) API ключът трябва да се съхранява в клиента и да се скрие само чрез промяна на името.

Разкриване: API ключът никога не се вгражда в кода на мобилното приложение; тъй като приложението може да бъде проектирано обратно и ключът да бъде извлечен. Правилната архитектура е да запазите ключа само в бекенда и да предавате заявки през вашия собствен прокси сървър.

7. Какво най-много увеличава възприетата от потребителя скорост и степента на завършване на функцията при дългите отговори на LLM?

• A) Изчакване, докато се получи целият отговор и показване наведнъж
• B) Показване на отговора дума по дума, както е произведен, с поточно предаване ✔
• C) Изпращане на цялата история на чата до модела с всяка заявка
• D) Увеличете модела на инструкцията, за да разширите отговора възможно най-много

Описание: Поточното предаване драстично увеличава възприеманата скорост и плавност чрез показване на отговора, докато се произвежда дума по дума. Вместо да чака на празен екран, потребителят гледа текстовата форма; Това значително намалява процента на изоставяне.

8. Кой е най-честият проблем в тестове, създадени от изкуствен интелект, който прави теста безполезен?

• A) Тестовете обхващат твърде много гранични състояния
• B) Тестовете използват фалшиви обекти, а не реални услуги
• В) Тестовете се изпълняват много бързо
• D) Раздуване на обхвата чрез празни/безполезни тестове, които всъщност не валидират поведение ✔

Обяснение: Изкуственият интелект понякога произвежда тестове, които всъщност не проверяват никакъв изход (напр. просто извикайте функцията и напишете празно твърдение). Те увеличават броя на покритието, но не осигуряват реална защита; Всеки тест трябва да бъде проверен, за да се провери смисленото поведение.

9. Защо не е достатъчно решение да заглушите срив, като го поставите в try-catch с предложение за изкуствен интелект?

• A) try-catch изобщо не може да се използва в мобилни приложения
• B) Сривът спира, но тъй като основната причина не е разрешена, проблемът се връща в различна форма ✔
• C) Използването на try-catch забавя приложението, така че е забранено
• D) Заглушената грешка се отхвърля автоматично от магазина

Обяснение: Заглушаването на симптома не решава първопричината; Сривът спира, но първоначалният проблем (напр. прекъсната връзка за данни) се връща под друга форма (напр. загуба на данни). Целта на професионалното отстраняване на грешки е да се реши първопричината, а не симптомът.

10. Кое е основното златно правило, което трябва да следвате при оптимизиране на производителността?

• A) Първо вземете профил и измерете реалното затруднение, след което оптимизирайте ✔
• Б) Отгатването къде е бавно и концентрирането там
• В) Преследване на малки печалби във всяка функция
• D) Измерване на производителността на емулатора и никога не опитване на истинското устройство

Описание: Първо измервайте, оптимизирайте по-късно. Истинското тясно място почти винаги е на различно място от предвиденото; Оптимизацията без профилиране е сляпо предположение и често е загуба на усилия.

11. Коя е най-важната инженерна грижа за постоянно работеща AI функция (напр. превод от камера на живо)?

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

Описание: Постоянно работещ модел, камера и мрежа; Може бързо да изразходва батерията, да загрява устройството и да бъде ограничен от системата. Намаляването на честотата на вземане на проби, групирането и работата само когато е необходимо са начини за управление на разходите за батерия.

12. Какво означава принципът на „най-малкото привилегия“ в управлението на разрешенията в мобилното развитие?

• A) Искане на всички възможни разрешения при стартиране, за всеки случай.
• B) Правене на приложението неработещо, ако разрешението е отказано
• В) Искане на най-широко разрешение и планиране на ограничаването му по-късно.
• D) Искане само на разрешението, което действително се изисква, когато е необходимо и в рамките на най-тесния обхват, със сценарий за отхвърляне ✔

Обяснение: Най-малката привилегия е да се иска само разрешението, което действително е необходимо, когато е необходимо и във възможно най-малката степен. Твърде многото разрешения подкопават доверието на потребителите, водят до отхвърляне на магазина и увеличават риска от изтичане на данни.

13. Какви специфични изисквания трябва да бъдат изпълнени при представяне на приложение с изкуствен интелект в магазина?

• A) Прозрачност на съдържанието, контрол на съдържанието и разкриване на данните, отиващи към изкуствения интелект под формата на поверителност ✔
• Б) Скриване на използването на изкуствен интелект от потребителя
• C) Маркиране на данни, които всъщност не се събират във формуляра за поверителност
• Г) Обещаващи характеристики, които не съществуват в описанието

Разкриване: Магазините очакват прозрачност на съдържанието (изявление, че произвежда AI), модериране на съдържанието (филтриране на вреден изход и известяване на потребителите) и разкриване на използването на данни от приложения, съдържащи изкуствен интелект; Изисква се предупреждение за точност в чувствителна зона. Заявленията, които не ги съдържат, ще бъдат отхвърлени.

14. Защо защитата „AI го е написал така“ е невалидна, когато възникне грешка в крайния случай в публикуван код, генериран от AI?

• A) Тъй като изкуственият интелект винаги създава код без грешки, грешката идва от потребителя
• B) Тъй като автоматично съхранява правилен код, генериран от AI
• В) Защото отговорността не може да бъде прехвърлена на изкуствения интелект; Разработчикът е отговорен за публикувания код и данни ✔
• Г) Защото генерираният от изкуствен интелект код никога не се пуска на живо

Описание: AI резултатът е начална точка, а не завършен продукт. Разработчикът е отговорен за всеки публикуван ред, всяка обработена информация и всяко дадено обещание; отговорността не може да бъде делегирана на AI, така че изходът трябва да бъде разбран и тестван преди публикуване.