Dowody z procesu pracy przy ocenie programowania wspomaganego przez AI
Jak dobierać informacje o przebiegu pracy wspomaganej przez AI do pytania o efekt uczenia się i jasno określać granice wnioskowania.
TraceYield — wiedza
8 min czytania · Zaktualizowano 7 października 2026
Interpretacja TraceYield
- Przebieg pracy nad oprogramowaniemSzerszy zapis pracy zależny od kontekstu; może zawierać rozgałęzienia, powtórzenia i luki.
- Wybrane dowody dotyczące przebiegu pracyKonkretne zapisy dobrane tak, aby wesprzeć ograniczone twierdzenie o tym, co się wydarzyło.
- Dowody istotne dla określonego efektu uczenia sięProwadzący wybiera dowody odnoszące się do efektu, obok artefaktu i innych materiałów oceny.
- Granica ludzkiego osąduDowody w TraceYield nie rozstrzygają, czy efekt uczenia się został osiągnięty.
- Ocena prowadzącegoProwadzący stosuje efekty kursu, kryteria, kontekst i właściwą procedurę.
Krótka odpowiedź: wybierz dowody dotyczące pracy, a uczenie się oceń osobno
Dowody z procesu pracy pokazują wybrane, obserwowalne fragmenty tego, jak rozwijało się zadanie programistyczne: jak określono zadanie i jego kontekst, co się zmieniło, jakie decyzje techniczne podjęto, co sprawdzono i jaki był wynik kontroli. Przy programowaniu wspomaganym przez AI mogą obejmować istotną interakcję z narzędziem lub reakcję studenta na jego propozycję.
W tym artykule „przebieg pracy nad oprogramowaniem” to robocza definicja redakcyjna: osadzony w kontekście, uporządkowany, lecz mogący się rozgałęziać zapis istotnych zdarzeń i zmian artefaktów w epizodzie pracy, powiązany tam, gdzie to możliwe, z weryfikacją i dostępnymi dowodami wyniku. Nie jest to standard ani zwalidowany model TraceYield. Dowody dotyczące przebiegu pracy to te zapisy, które mogą wesprzeć określone twierdzenie o epizodzie. Dowody istotne dla efektu uczenia się stanowią kolejną selekcję, dokonaną na potrzeby oceny. Prowadzący interpretuje je następnie w odniesieniu do efektu i warunków oceny. Te warstwy są powiązane, ale nie są tym samym.
Dlaczego końcowy artefakt nie odpowiada na każde pytanie oceniającego
Końcowy kod, testy i dokumentacja są ważnymi dowodami dotyczącymi oddanego artefaktu. Nie zawsze pokazują jednak, jak student doprecyzował niejednoznaczne wymaganie, zareagował na nieudaną próbę albo potrafi zastosować pojęcie w zmienionym problemie. Narzędzie AI może w znacznym stopniu uczestniczyć w tworzeniu artefaktu, więc sam wynik może nie wystarczyć, gdy efekt dotyczy rozumowania lub adaptacji.
To kwestia projektu oceny, a nie twierdzenie, że praca końcowa straciła wartość. Raport ACM Task Force o generatywnej AI i ocenie programowania opisuje praktyki zgłaszane przez edukatorów oraz przykłady zmian; nie potwierdza skuteczności tej interpretacji TraceYield. Wizja Npuls dotycząca oceniania, egzaminowania i AI to szeroki kontekst sektorowy, nie gotowa rubryka do oceny programowania.
Interpretacja TraceYield: dowody z przebiegu pracy same w sobie nie są dowodami uczenia się
Proponowana interpretacja TraceYield rozdziela cztery kwestie: przebieg pracy nad oprogramowaniem → wybrane dowody dotyczące przebiegu → dowody istotne dla określonego efektu uczenia się → ocena prowadzącego. Przebieg dostarcza kontekstu. Wybrany zapis może uzasadniać ograniczone twierdzenie o tym, co się wydarzyło. Prowadzący rozstrzyga, czy dowody są istotne i wystarczające, uwzględniając artefakt oraz pozostałe dowody.
To propozycja porządkowania informacji, a nie zwalidowana metoda dydaktyczna. TraceYield jest przed etapem pilotażu; publiczne opisy produktu przedstawiają planowane widoki dowodów i ich powiązań. Artykuł nie twierdzi, że rozwiązanie zostało zwalidowane w klasie ani że produkt ocenia uczenie się.
Dobieraj dowody, wychodząc od efektu uczenia się
Zacznij od jednego efektu i ustal, co student ma zademonstrować. Wybierz najmniejszy zestaw dowodów, który może pomóc odpowiedzieć na to pytanie, i określ, co każdy element wspiera, a czego nie. Przy projektowaniu usługi mogą być istotne krótka notatka o kontekście i uzasadnienie decyzji. Przy debugowaniu współbieżności znaczenie mogą mieć awaria, zmiana hipotezy i ukierunkowany test. Przy testowaniu ważne mogą być sam test, jego zakres i wyjaśnienie, czego nie sprawdza.
Artefakt końcowy nadal jest częścią oceny. Zapis procesu powinien wnosić informacje o efekcie, których nie da się uzyskać z samego artefaktu; nie należy go zbierać tylko dlatego, że narzędzie na to pozwala. Npuls i raport ACM zapewniają zewnętrzny kontekst dla oceniania uwzględniającego AI i uczenie się. Sposób mapowania dowodów i planer na tej stronie są propozycją TraceYield, a nie wnioskiem potwierdzonym przez te źródła.
Przykład ilustracyjny: zapobieganie podwójnym rezerwacjom w aplikacji HBO-ICT
Przykład ilustracyjny — nie są to dane studentów, wyniki badań ani dane TraceYield. Zadanie polega na zmianie istniejącej usługi rezerwacji sprzętu tak, aby dwie osoby nie mogły zarezerwować tego samego urządzenia na nakładające się terminy. Efekt uczenia się brzmi: „Zaprojektować i wdrożyć regułę spójności danych w aplikacji internetowej obsługującej współbieżność oraz uzasadnić sposób jej weryfikacji”. Warunki zadania dopuszczają użycie AI.
Zadanie i kontekst. Student otrzymuje istniejącą usługę, schemat bazy danych, wymagania rezerwacji i środowisko testowe. Repozytorium sprawdza dostępność w kodzie aplikacji przed zapisem rezerwacji.
Propozycja AI. Student pyta agenta, jak zapobiec nakładającym się rezerwacjom. Agent proponuje sprawdzenie istniejącej rezerwacji, a następnie zapis, jeśli jej nie ma.
Działanie i niepowodzenie weryfikacji. Student dostosowuje propozycję i dodaje test uruchamiający niemal równocześnie dwie nakładające się rezerwacje. Obie zostają zaakceptowane w środowisku testowym, co ujawnia wyścig między sprawdzeniem a zapisem.
Nowa hipoteza. Po przekazaniu wyniku testu i schematu agentowi student zapisuje zmienioną hipotezę: niezmiennik trzeba egzekwować na poziomie bazy, a nie tylko przez wcześniejsze sprawdzenie w aplikacji.
Poprawka i weryfikacja. Student wybiera odpowiednie ograniczenie bazy danych, obsługuje konflikt w usłudze i aktualizuje test integracyjny. Uruchamia test współbieżności oraz dotychczasowe testy rezerwacji, a następnie wyjaśnia, co sprawdzają i czego nie obejmują.
Co dowody z przykładu mogą, a czego nie mogą uzasadnić
A. Co bezpośrednio pokazują zapisy: jeśli istnieją i są wiarygodne, można ustalić, że wysłano początkowe zapytanie, agent zaproponował sekwencję sprawdzenie–zapis, student dodał test współbieżności, test wykazał błąd, student przekazał wynik jako nowy kontekst, zmienił implementację, a określone testy dały określone wyniki. Każde twierdzenie powinno wskazywać odpowiedni zapis lub artefakt.
B. Co może mieć znaczenie dla efektu: test i wynikająca z niego zmiana mogą być istotne dla pytania, czy student potrafi rozpoznać wyścig i zastosować regułę spójności danych. Zmiana w bazie, ukierunkowany test oraz wyjaśnienie lub demonstracja studenta dostarczają różnych informacji. Prowadzący ocenia, czy łącznie są istotne i wystarczające dla efektu.
C. Czego nie można wywnioskować z samego przebiegu: że student rozumiał współbieżność, był autorem implementacji, pracował samodzielnie, ma ogólną kompetencję, postępował uczciwie albo powinien dostać konkretną ocenę. Takie wnioski wymagają innych dowodów i oceny prowadzącego. Przykład pokazuje możliwy sposób projektowania dowodów, nie wynik badań.
Wybierz mały, celowy zestaw dowodów zamiast pełnego archiwum rozmów
W wielu zadaniach prowadzący może przejrzeć krótkie określenie kontekstu, jedną wybraną decyzję lub poprawkę, powiązany artefakt albo test oraz ukierunkowane wyjaśnienie. Część prac może wymagać dalszej demonstracji lub pytania o zastosowanie wiedzy w innym kontekście — zależnie od efektu i lokalnego projektu oceny. Nie trzeba czytać każdego promptu, aby zapytać o konkretną decyzję.
Wybrany punkt kontrolny może też umożliwić informację zwrotną, gdy student może jeszcze zmienić kierunek. Prowadzący może dopytać o nowe dane z debugowania lub poprosić o sprawdzenie innej hipotezy. Taki zapis nie musi być osobno oceniany.
Zwykle niepotrzebne lub nieproporcjonalne są pełne transkrypcje promptów, każde naciśnięcie klawisza, stałe monitorowanie, prywatne rozmowy bez związku z efektem, surowa liczba tokenów jako miara uczenia się albo powtarzane dokumentowanie rutynowych czynności. Gdy zapis może zawierać dane wrażliwe, użyj bezpieczniejszego streszczenia lub pomiń go, jeśli pytanie można rozstrzygnąć bez niego. Uprzedź studentów, co jest zbierane, dlaczego, kto ma dostęp i jak długo dane są przechowywane.
Praktyczna próba projektowa: Który efekt wyjaśnia ten dowód? Czy student może go dostarczyć w proporcjonalny sposób? Czy oceniający potrafi go spójnie zinterpretować? Jakie ryzyko prywatności lub dostępności powstaje? Usuń element, którego cel jest niejasny. To propozycja planowania oparta na źródłach artykułu, nie zwalidowana skala ani rubryka.
Granice wnioskowania: formułuj najwęższy uzasadniony wniosek
Zapis poprawki może wykazać, że do niej doszło, jeśli źródło wiarygodnie to potwierdza. Nie wyjaśnia, dlaczego student ją wprowadził ani czy ma ogólną kompetencję. Wynik testu wspiera twierdzenie o tym teście, danych i środowisku, nie o bezbłędności całej implementacji. Końcowy artefakt pokazuje, co oddano, ale sam nie ujawnia, co student rozumie.
Brakujące zapisy przebiegu pracy to brakujące dowody, a nie dowód niewłaściwego postępowania. Zarejestrowane użycie AI nie dowodzi, że student się nie uczył; brak zapisu interakcji nie dowodzi pracy bez pomocy. Jeśli dowody są niejednoznaczne, zastosuj uczciwe, powiązane z efektem uzupełnienie zamiast zamieniać niepewność w zarzut lub wynik punktowy.
Ocena prowadzącego pozostaje odrębna
Opisywana rola TraceYield polega na ułatwianiu łączenia i przeglądania wybranych dowodów z przebiegu pracy. Produkt nie jest detektorem AI, automatycznym oceniającym ani systemem ustalającym autorstwo. Nie rozstrzyga, czy dowody potwierdzają efekt uczenia się. Ocenę podejmuje prowadzący, stosując kryteria kursu, procedury instytucji i właściwy kontekst.
Skorzystaj z drukowanego Planera dowodów z procesu pracy, aby powiązać efekt z zadaniem, artefaktem, wybranymi zapisami procesu, wyjaśnieniem lub demonstracją, weryfikacją i późniejszą oceną prowadzącego. Szerszy projekt zadania omawia ocena zadań programistycznych wspomaganych przez AI, a odpowiedzialność i rozumienie — odpowiedzialność studenta za pracę.
Niezależne narzędzie dla prowadzących
Planer dowodów z procesu pracy
Powiąż jeden efekt uczenia się z zadaniem i potrzebnymi dowodami: końcowym artefaktem, wybranymi dowodami z procesu pracy, wyjaśnieniem lub demonstracją, weryfikacją oraz oceną prowadzącego. Drukowany planer zawiera przykład z tworzenia oprogramowania.
Otwórz planerPlaner działa niezależnie od TraceYield. Wpisy pozostają na otwartej stronie, dopóki nie wydrukujesz jej lub nie zapiszesz; planer nie przesyła danych do TraceYield.