Bir insan “düzeltme başarılı” cümlesini anlayabilir. Sonraki otomasyon adımı ise hangi dosyanın değiştiğini, hangi kontrolün çalıştığını ve açık iş kalıp kalmadığını ayrı alanlarda bekleyebilir. Codex çıktısı başka bir program tarafından tüketilecekse teslim sözleşmesini görevden önce tanımlamak faydalıdır. Resmî non-interactive belgeleri, son yanıtı bir JSON Schema ile yapılandırma seçeneğini açıklar; asıl tasarım kararı hangi bilgiyi isteyeceğinizdir.

Önce çıktıyı kullanan kişiyi düşünün

Bir hata inceleme sisteminin sonuçları panoda göstereceğini varsayın. Sistem yalnızca başlık, önem derecesi, dosya yolu ve kanıt istiyorsa, uzun serbest metni sonradan parçalamak gereksiz iş yaratır. Alanları bu ihtiyaca göre seçin. Kullanılmayacak onlarca alan eklemek, hem üretimi hem de doğrulamayı karmaşıklaştırır. En küçük yararlı sözleşme daha kolay bakım görür.

Örnek görev: “Değişiklikleri incele ve bulguları JSON olarak teslim et. Her bulguda title, severity, file ve evidence alanları olsun. Kanıtlanmış sorun yoksa boş liste döndür. Tahminleri bulgu gibi yazma; ayrı bir uncertainties listesinde belirt.” Bu tasarım, kesin sonuçla araştırılması gereken noktayı birbirinden ayırır.

Türleri ve boş değerleri açıklayın

severity alanının sayı mı metin mi olduğu önceden belirlenmelidir. Aynı akışın bir çalışmada “yüksek”, diğerinde 3 döndürmesi sonraki sistemi zorlar. İzin verilen değerleri seçin ve boş sonucun ne ifade ettiğini yazın. Dosya bilinmiyorsa boş metin, null veya alanın yokluğu seçeneklerinden biri tercih edilebilir; önemli olan tutarlılıktır.

Tarih ve saat alanlarında da açık olun. Bir günlük kaydının yerel saatiyle sunucu zamanını karıştırmak olay sıralamasını bozabilir. Kaynakta saat dilimi yoksa bunu uydurarak tamamlamak yerine belirsizlik bilgisini koruyun. Sayısal alanlarda ölçü birimini tanımlamak da aynı sözleşmenin parçasıdır. “Süre: 12” tek başına yeterince açıklayıcı değildir.

Biçim doğruluğunu içerik doğruluğundan ayırın

Geçerli JSON, doğru analiz demek değildir. tests_passed alanı true döndüğü halde hiçbir test çalıştırılmamış olabilir. Bu nedenle yalnızca sonuca değil, kanıt alanına da yer verin. Çalıştırılan kontrolün adı, sonucu ve varsa çıktı dosyası, iddianın değerlendirilmesini sağlar. Çalıştırılmayan kontrolü başarılı gibi kodlamayın.

Örneğin tek bir genel “durum” alanı yerine completed, blocked ve not_run gibi açık durumlar kullanılabilir. Bunlar bu örneğin uygulama tercihidir; Codex'e ait zorunlu durum adları değildir. Kendi tüketici programınızın ihtiyaçlarına göre bir liste seçip bütün üreticilerin aynı anlamları kullandığını doğrulayın.

Küçük örneklerle sözleşmeyi sınayın

Üç girdi hazırlayın: bulgu içeren değişiklik, sorun bulunmayan değişiklik ve eksik dosyalı değişiklik. Üçünde de yanıtın ayrıştırıldığını görmek yalnızca ilk kontroldür. İkinci kontrolde önem derecesinin gerekçeyle uyumunu, boş listenin doğru kullanımını ve belirsizliğin kaybolmadığını inceleyin. Gerçek kişisel veri gerektirmeyen sentetik örneklerle başlayabilirsiniz.

Sözleşme değiştiğinde sürümünü kaydedin. Yeni bir alan eklenmesi tüketicinin davranışını etkiliyorsa geçiş süreci gerekir. Önceki örnek çıktıları küçük bir test arşivinde tutmak, istem değişikliğinin eski tüketicileri bozup bozmadığını görmenizi sağlar. Yapılandırılmış teslimin değeri, yalnızca düzenli görünmesinde değil; farklı adımlar arasında anlamı korumasındadır.

Bir dosya yolu alanı için depo köküne göre göreli biçim seçebilirsiniz. Böylece aynı çıktı farklı CI makinelerinde karşılaştırılabilir kalır. Ancak insanın dosyayı hemen açması gereken bir teslimde erişilebilir bağlantı gerekebilir. Sözleşmenin biçimini, çıktının gerçekten nasıl kullanılacağı belirlemelidir.

Resmî kaynak: OpenAI Docs — Non-interactive mode.