Thema wählen, fertigstellen, klar aufschreiben

In Teil 1 dieses Kurses haben wir gemeinsam RepoBot gebaut: einen Frage-Antwort-Assistenten für httpx, vom Kommandozeilen-Chatprogramm v1 bis zum Webdienst v4, mit Suche, Agent, Evaluation und Leitplanken.

Das Abschlussprojekt lässt dich diesen Weg noch einmal selbstständig gehen, nur bestimmst du diesmal das Thema selbst. Diese Lektion lehrt keine neue Technik, sondern wie man ein Projekt wirklich fertigstellt.

Das Thema wählen

Ein gutes Thema für das Abschlussprojekt erfüllt diese Bedingungen:

• Du selbst oder Menschen um dich herum würden es wirklich nutzen. Nur mit echten Nutzern weißt du, ob es brauchbar ist, und hast den Antrieb, es fertigzustellen.
• Es gibt ein klares Richtig und Falsch. Ob eine Antwort stimmt, eine Einordnung genau ist, extrahierte Felder vollständig sind, lässt sich prüfen. Themen wie „ein schönes Gedicht schreiben“ lassen sich schwer evaluieren und eignen sich nicht als Abschlussprojekt.
• Die erste brauchbare Version ist in zwei bis vier Wochen fertig. Lieber klein und fertig.
• Die Daten sind dir zugänglich, und du darfst sie nutzen. Öffentliche Dokumentation, eigene Notizen, Open-Source-Datensätze sind alle in Ordnung. Bei internen Firmendaten zuerst klären, ob man sie nutzen und an eine API schicken darf.

Einige Richtungen zur Orientierung, jede entspricht bestimmten Modulen des Kurses:

题目                                    主要用到
给你常用的一个开源库做答疑助手          RAG（04）、评估（06）
读懂一个代码仓库、回答"这个函数在哪里   智能体和工具（05）、MCP（05 第 7 课）
被调用"的助手
从简历、合同、发票里抽取固定字段        提示词和 JSON 输出（02）、评估（06）
把客服工单自动分类，并给出建议回复      提示词（02）、模型评委（06），可能用到微调（10）
在某个领域的文字上训练一个小模型        第 09 模块，外加第 08 模块第 6 课的过拟合检查
（比如宋词、对联、自己的聊天记录）

Wähl kein Thema wie „einen universellen KI-Assistenten bauen“. Es hat keine Grenzen, wird nie fertig und lässt sich nicht evaluieren.

Schritt 1: die Kriterien für „fertig“ aufschreiben

Bevor du loslegst, schreib eine GOAL.md, die nur drei Fragen beantwortet:

1. Für wen, und welches Problem löst es? Ein Satz.
2. Wie sieht „fertig“ aus? Als einige überprüfbare Punkte formuliert, wie das „Du bist fertig, wenn“ am Anfang jedes Moduls dieses Kurses. Etwa: „Beantwortet Nutzungsfragen zur httpx-Dokumentation, mindestens 16 von 20 Evaluationsfragen richtig, jede Antwort mit Quelle“, „durchschnittliche Kosten pro Frage höchstens 0,01 Yuan“.
3. Was ausdrücklich nicht dazugehört. Etwa „kein Bild-Upload“, „nur Chinesisch“.

Diese Datei entscheidet, wann dein Projekt fertig ist. Ohne sie wächst ein Projekt leicht immer weiter, und am Ende ist nichts fertig. Modul 07, Lektion 3 sagte dasselbe: erst Abnahmekriterien festlegen, dann loslegen.

Schritt 2: zuerst der Evaluationsdatensatz

Bevor du irgendwelchen Funktionscode schreibst, bereite 20 bis 50 Evaluationsfragen vor.

Das klingt nach verkehrter Reihenfolge, ist aber der wichtigste Schritt des ganzen Projekts (Modul 06, Lektion 1):

• Das Schreiben der Fragen zwingt dich zu klären, was Nutzer wirklich fragen werden und welche Antwort als gut gilt.
• Mit dem Evaluationsdatensatz weißt du nach jeder Änderung mit einem Befehl, ob es besser oder schlechter geworden ist.
• Beim Schreiben der README hast du am Ende echte Zahlen statt „funktioniert sehr gut“.

Die Fragen sollen normale Fragen abdecken, aber auch Grenzfälle, Fragen, die abgelehnt werden sollen, und Eingaben, die missbraucht werden könnten (Modul 06, Lektion 5).

Schritt 3: die einfachste brauchbare Version bauen

Bau zuerst mit dem einfachsten Ansatz eine Version und lass den Evaluationsdatensatz einmal laufen.

RepoBot v1 schlug absichtlich keine Unterlagen nach, um klar zu sehen, wie weit „der einfachste Ansatz“ kommt und wo er scheitert. Diese Fehlschläge sagen dir, was als Nächstes am dringendsten ist: Antwortet es falsch, weil es die Unterlagen nicht kennt, RAG ergänzen; weil es mehrstufig suchen müsste, an einen Agenten denken; ist nur das Format instabil, zuerst den Prompt ändern.

Setz nicht gleich zu Beginn alle gelernten Techniken ein. Modul 05, Lektion 1 hat gesagt: Was ein einfacher Workflow löst, braucht keinen Agenten. Für jede Ergänzung muss ein Evaluationsergebnis zeigen, dass sie wirklich etwas verbessert.

Schritt 4: in kleinen Schritten verbessern

Danach bei jedem Schritt:

1. Die gescheiterten Fragen im Evaluationsergebnis ansehen und die wichtigste Fehlerart finden.
2. Gegen diese Fehlerart eine Änderung vornehmen.
3. Den Evaluationsdatensatz erneut laufen lassen und das Ergebnis notieren.
4. Mit git committen und in der Commit-Nachricht die Veränderung des Evaluationsergebnisses festhalten.

Die Evaluationsergebnisse jedes Schritts in einer Tabelle festhalten. Beim Schreiben der README ist diese Tabelle der überzeugendste Inhalt: Sie zeigt, dass jede Entwurfsentscheidung einen Grund hat.

版本    改动                          答对      平均花费/题   平均耗时
v1      直接问模型                    7/20      0.002 元      2.1 秒
v2      加上 RAG（向量检索）          13/20     0.004 元      3.0 秒
v3      改成混合检索 + 重排           16/20     0.004 元      3.4 秒

(Die Tabelle oben ist ein Formatbeispiel, keine echten Daten. In deine Tabelle gehören die Zahlen, die du selbst gemessen hast.)

Schritt 5: Prüfung vor dem Livegang

Soll dein Projekt von anderen genutzt werden, prüfe es anhand von Modul 06:

• Schlüssel stehen nicht im Code und sind nicht in git eingecheckt.
• Es gibt Grenzen für Eingabelänge und Aufrufhäufigkeit, damit niemand dein Geld verbrennt.
• Im Log sind Schritte, Dauer und Kosten jeder Anfrage zu sehen, aber keine sensiblen Nutzerdaten.
• Es gibt Leitplanken für Ein- und Ausgabe, und der Evaluationsdatensatz bestätigt, dass sie keine normalen Fragen treffen.
• Nutzt es einen Agenten, haben die aufrufbaren Tools minimale Rechte (Modul 05, Lektion 8).

Schritt 6: die README schreiben

Ist ein Projekt noch so gut, versteht es niemand und kann es niemand ausführen, ist es so gut wie nicht gemacht. Eine README braucht mindestens:

• Eine Beschreibung in einem Satz: was es ist, für wen.
• Wirkung: ein, zwei echte Anwendungsbeispiele (Ausgaben echter Läufe, nichts erfunden) und die Tabelle der Evaluationsergebnisse.
• Ausführung: die vollständigen Schritte vom Klonen des Codes bis zum Ergebnis, sodass andere es nachmachen und zum Laufen bringen können. Klar angeben, welche Umgebungsvariablen nötig sind und was es ungefähr kostet.
• Entwurf: der Gesamtaufbau, die wichtigsten Entscheidungen und ihre Gründe (warum RAG statt Feintuning, warum dieses Modell).
• Was es nicht gut kann: welche Art Fragen im Evaluationsdatensatz noch falsch beantwortet wird, bekannte Grenzen.

Der letzte Punkt wird am leichtesten weggelassen, zeigt aber am besten dein Können. Kannst du klar sagen, wo dein System Fehler macht, zeigt das, dass du es wirklich verstanden hast. RepoBot v4 aus Modul 06 hat in der README aufgelistet, „was vor dem Betrieb noch fehlt“.

Such danach einen Freund, der das Projekt nicht kennt, und bitte ihn, es nur mit der README zum Laufen zu bringen. Jede Stelle, an der er hängen bleibt, ist eine Stelle, die die README ändern muss.

Es anderen erklären

Zum Schluss versuch, dein Projekt anderen in fünf Minuten zu erklären. Zur Gliederung kannst du die Fragen nutzen, die der Kurs Start AI Engineering zusammengestellt hat (sie standen auch am Ende der Projektlektionen von Modulen 03 bis 06):

1. Welches Problem löst es? Wer nutzt es?
2. Was ist die Eingabe, was die Ausgabe?
3. Warum dieser Ansatz und nicht ein einfacherer oder komplexerer?
4. Woher weißt du, wie gut es ist? Wie lauten die Zahlen?
5. Was kostet ein Aufruf, wie lange dauert er?
6. Wo macht es Fehler? Was passiert dann?

Kannst du diese sechs Fragen klar beantworten, dann kannst du nicht nur „ein großes Modell aufrufen“, sondern selbstständig eine verlässliche KI-Anwendung bauen. Genau dorthin wollte dich dieser Kurs von der ersten Lektion an bringen.

Übungen

1. Schreib drei mögliche Themen auf, bewerte jedes nach den vier Bedingungen aus „Das Thema wählen“ und entscheide dich für eines.
2. Schreib für dein Thema eine GOAL.md und mindestens 20 Evaluationsfragen, bevor du mit dem Code beginnst.
3. Gib die README nach der Fertigstellung einer Person, die das Projekt nicht kennt, notiere, wo sie hängen bleibt, und überarbeite die README.

Selbsttest

1. Warum bereitet man den Evaluationsdatensatz vor, bevor man Funktionscode schreibt?

Das Schreiben der Evaluationsfragen zwingt dich zu klären, was Nutzer fragen werden und welche Antwort als gut gilt; damit lässt sich jede Änderung mit einem Befehl beurteilen; und beim Schreiben der README hat man echte Zahlen. Ohne Evaluationsdatensatz urteilt man nur nach dem Gefühl bei ein paar Beispielen und irrt sich leicht.

2. Warum empfiehlt es sich, zuerst eine einfachste Version zu bauen, statt gleich RAG, Agenten und andere Techniken einzusetzen?

Die einfachste Version zeigt, wo das Problem wirklich liegt: fehlende Unterlagen, nötige mehrstufige Abläufe oder nur ein instabiles Format. Wählt man die Technik nach der Ursache des Scheiterns und belegt jede Ergänzung mit Evaluationsergebnissen, wird das System nicht unnötig komplex.

3. Warum gehört „was es nicht gut kann“ in die README?

Es sagt Nutzern, in welchen Fällen sie sich nicht auf das System verlassen können, und verhindert Fehlgebrauch; und es zeigt, dass der Autor sein System wirklich versteht und weiß, wo es Fehler macht. Eine README, die nur Stärken nennt, ist schwerer zu vertrauen.