Како да се прегледува работа со помош на AI според спецификацијата

Зошто е ова важно

AI може многу брзо да произведе код, текст, тестови и промени во интерфејсот што изгледаат завршено.

Таа брзина создава ризик при преглед: рецензентите може несвесно да преминат од прашањето „Дали ова е правилното однесување на производот?“ кон прашањето „Дали ова изгледа разумно?“

Тоа не се исти прашања.

Во работа водена од спецификација, прегледот треба да почне со усогласеност, а дури потоа да премине на квалитет на код, стил и детали на имплементацијата.

Почнете од изворот на вистината

Пред да го прегледувате резултатот, идентификувајте ги документите што го дефинираат наменетото однесување.

Во репозиториумот Let Books тоа обично значи:

• AGENTS.md за правила на производот, текови на работа и опсег
• AGENTS-Implementation.md за тактички ограничувања на испораката
• README.md за прикажување на тековната состојба
• релевантна документација под docs/ за насоки за објавување, проверка или тек на работа

Без овој чекор, прегледот лесно станува субјективен и локален.

Прегледувајте по правилен редослед

Користете го овој редослед кога прегледувате работа со помош на AI.

1. Усогласеност со производот

Прашајте дали резултатот одговара на наменетиот кориснички тек на работа и границата на производот.

Примери:

• дали рачниот внес и понатаму функционира таму каде што спецификацијата го бара тоа
• дали промената ја зачувува поделбата меѓу физичките примероци и библиографските записи
• дали додава однесување што никогаш не било одобрено
• дали погрешно ги прикажува опционалните AI можности како задолжителни

Ако усогласеноста со производот е погрешна, нема голема вредност прво да се троши време на дотерување.

2. Усогласеност на документацијата

Прашајте дали околните документи сè уште чесно ја опишуваат реалноста.

Примери:

• дали кориснички видлив тек на работа е сменет без ажурирање на документацијата
• дали README сè уште точно ја опишува тековната состојба
• дали новите јавни тврдења одговараат на реалната документирана позиција на производот

Промените генерирани од AI често го менуваат однесувањето без да се ажурира наративот околу тоа однесување.

3. Валидација и резервно однесување

Прашајте дали промената ги зачувува очекувањата од спецификацијата за неуспех и резервни текови.

Примери:

• дали текот на работа и понатаму може да успее кога опционален провајдер ќе откаже
• дали невалидните влезови се обработуваат експлицитно
• дали излезите со ниска сигурност или несигурните резултати се третираат како предлози наместо како факти

Тука многу уверливи имплементации паѓаат на вистинскиот тест на производот.

4. Технички квалитет

Дури по горните проверки треба најголемиот дел од времето да се троши на:

• јасност
• одржливост
• именување
• дуплирање
• тестови
• структура

Техничкиот квалитет и понатаму е важен. Само не треба да има предност пред исправноста на производот.

Вообичаени замки при преглед

Работата со помош на AI има тенденција да создаде неколку повторливи замки при преглед.

Замка на полиран излез

Резултатот изгледа чисто, па рецензентите претпоставуваат дека е точен.

Замка на блискиот контекст

Промената одговара на најблиската постојна имплементација, но најблиската имплементација можеби веќе отстапила.

Замка на имплицитниот опсег

Асистентот додава функционалности, апстракции или претпоставки што никогаш не биле побарани, а рецензентот ги прифаќа бидејќи не се очигледно расипани.

Замка на поминати тестови

Тестовите можат да поминат затоа што го валидираат генерираното однесување, а не затоа што го валидираат наменетото однесување на производот.

Практична контролна листа за преглед

За секоја позначајна промена со помош на AI, прашајте:

1. Кое правило на производот или тек на работа треба да го имплементира оваа промена?
2. Која спецификација или документација го дефинира тоа правило?
3. Дали резултатот ги зачувува потребните ограничувања?
4. Дали го задржува резервното однесување недопрено?
5. Дали документацијата и понатаму се совпаѓа со добиеното однесување?
6. Која валидација или тестови ја поддржуваат промената?
7. Дали асистентот додаде нешто што треба да се отстрани како надвор од опсегот?

Како да се прегледуваат генерирани тестови

Генерираните тестови се корисни, но и тие треба да се прегледуваат според спецификацијата.

Прашајте:

• дали тестовите го проверуваат наменетиот тек на работа
• дали покриваат резервно однесување
• дали ги одразуваат документираните гранични услови
• дали тврдат некое удобно однесување што никогаш не било специфицирано

Ова е особено важно во работа водена од спецификација бидејќи слаб тестен пакет може да го заклучи отстапувањето.

Примери од Let Books

Примери за прашања на ниво на спецификација во овој репозиториум вклучуваат:

• дали текот на работа и понатаму останува корисен без платени AI услуги
• дали документацијата за тековната состојба јасно го раздвојува статусот на демото од идните планови за backend
• дали јавната документација избегнува да го третира изворниот код како канонски уреднички доказ
• дали чекорите за валидација и понатаму остануваат дел од текот на испорака наместо опционално сеќавање

Овие прашања се доволно конкретни за да го водат прегледот, а токму тоа треба да го овозможи една спецификација.

Трајната поука

Прегледот на работа со помош на AI не е проверка дали асистентот произвел нешто импресивно. Тој е проверка дали резултатот сè уште припаѓа на наменетиот производ.

Најдоброто прашање при преглед обично не е „Дали ова работи?“, туку „Дали ова одговара на спецификацијата, вклучувајќи ги деловите што лесно се забораваат?“

Дополнително читање

• ../spec-driven-content-program.md
• how-to-write-a-spec-that-ai-can-follow.md
• how-to-turn-a-product-spec-into-an-implementation-plan.md
• how-to-keep-spec-docs-demo-and-code-aligned.md
• ../wiki/mk/spec-driven-development.md
• ../blog/mk/spec-driven-development-for-ai-projects.md