Claude Code ile Otomatik Programlama Üzerine Gerçek Bir Vaka: İpuçları ve Teknikler
Bu makalede, gerçek bir vaka üzerinden Claude Code'un pratik kullanımını paylaşacağım. Paylaşıma başlamadan önce küçük bir anket yapalım.
Orijinal ihtiyaç: Değerli bir ücretli kullanıcı, makalelerime değiştirilme tarihi eklememi istedi.
İlk bakışta bu ihtiyacı karşılamak biraz zor görünüyordu. Çünkü sitemdeki makaleler veritabanında saklanmıyor, hepsi next.js'in SSG özelliğiyle oluşturuluyor. Hiçbir güncelleme tarihi yoktu.
Buradaki püf nokta şu: Sorunları çözerken orijinal ihtiyacı doğrudan Claude Code'a vermemeliyiz, bunun birkaç nedeni var:
1. Orijinal ihtiyaç nispeten belirsizdir, yanlış anlaşılabilir. Yanlış anlaşılırsa, sonuçta bir tarih ekleyebilir ama bu tarih güvenilir olmayabilir.
2. Claude Code'un Token tüketimi gerçekten çok pahalı, bu nedenle belirsiz ihtiyaçlar anlamsız Token tüketimine yol açabilir.
Bu yüzden orijinal ihtiyacı parçalara ayırmalıyız. Önce deepseek'te danıştım, deepseek bana iki çözüm önerdi:
1. Dosya oluşturma tarihi - her build sırasında dosyanın oluşturulma tarihini almalıyız, ancak turbopack'in paketleme stratejisi biraz farklı, her build'de dosyanın hash değeri değişiyor, bu nedenle oluşturma tarihi güvenilir olmayabilir.
2. git commit tarihi - bunun daha güvenilir olacağını düşündüm.
Genel bir çözüm yönü belirledikten sonra, basit bir ipucu oluşturdum: git commit tarihini her .mdx makalesinin başına derle
Claude Code oldukça güvenilir, ipuçları doğruysa genelde sorun çıkarmıyor, hemen işe koyuluyor.
7 dolar harcadıktan ve yaklaşık 20 dakika sonra, nihayet başarıyla tamamlandı.
Tahmin edileceği gibi, beklenmedik bir durum oldu: 171 dosyayı değiştirmeyi atladı.
Buradaki sorun şu: Atlanan dosyalar sadece ek bir pass parametresi alıyordu, diğer her şey tamamen aynıydı.
<PostLayout pass>...Ancak esnek davranmayıp, bu ek parametreyi tamamen farklı bir özel bileşen olarak tanımladı. Sonra da işlemeyi atladı ～ ～
import Layout from 'components/post-layout';
import { getGitFileInfo } from '@/utils/git-info';
export default function Article({ children }: any) {
const gitInfo = getGitFileInfo('src/app/你的路径/page.mdx');
return (
{children}
);
}Ancak gerçekte ihtiyacım olan şey buydu, çalışma sonuçları tamamen aynı olmalıydı.
import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
return (
{children}
);
}Sonra burada ipuçlarında bir sorun yaşadım.
Tekrar şu ipucunu girdim: Atlanan 171 dosyayı yukarıdakiyle aynı yöntemle yeniden yapılandır
Bu ifadem biraz düşününce biraz belirsiz. Çünkü Claude Code bana zaten bir öneri sunmuştu, ancak ben bu öneriyi onaylamıyordum. Amacım, değiştirilmiş yüzlerce dosyada kullanılan yöntemi atlanan dosyalara uygulamaktı, ancak yürütme sırasında onun anladığı şey şuydu: Yukarıda önerdiği yöntem
Bu belirsizlik, istemediğim bir plana göre 20 dakika boyunca çalışmasına neden oldu, arada 2 kez hata yapıp kendini düzeltti ve token'larımı acımasızca tüketti. İki farklı anlam çatışması hatalara yol açtı.
Sonunda bu yürütmeyi bırakıp, anlamımı yeniden netleştirmek zorunda kaldım.
Özet
1. İpuçları mümkünse nispeten kararlı ve doğru çözümler içermeli, AI'nın düşünmesi ne kadar az olursa o kadar iyi, böylece halüsinasyon oranı azalır.
2. İhtiyaç ipuçlarında kesinlikle belirsizlik olmamalı, belirsizlik hatalara yol açabilir. Claude Code sonunda düzeltebilse de bu çok fazla token tüketimine neden olur. Ayrıca LLM'ler tahmin mekanizmasına dayalı sonuç ürettiği için, erken dönemdeki yanlış okumalar ve belirsizlikler, sonraki her adımın yanlış yönde ilerlemesine neden olur. Ayrıca mantıksal tutarlılık sağlamaya çalışır, var olmayan şeyler üretebilir, yazdıkça sorunlar büyür ve geliştiricinin inceleme zorluğunu artırır. Eğer onun halüsinasyonlarına kanarsanız, ciddi sonuçlar doğurabilir.
3. Doğal dilin kısıtlayıcı gücü kod kadar kesin değildir. İpuçlarında dosya adları, kod değişkenleri, kod özel kelimeleri, teknik terimler vb. bulunması, Claude Code'un halüsinasyonlarını büyük ölçüde azaltır.
