Berdasarkan Kes Sebenar Pengaturcaraan Automatik Claude Code, Kongsikan Beberapa Teknik Kata Isyarat

Artikel ini, melalui satu kes sebenar, akan berkongsi dengan anda kes penggunaan sebenar Claude Code. Sebelum berkongsi, mari kita buat satu tinjauan kecil

Keperluan asal: Terdapat seorang pengguna berbayar yang dihormati, yang ingin saya tambahkan masa perubahan artikel dalam artikel

Pada pandangan pertama, keperluan ini agak sukar untuk dilaksanakan. Kerana artikel di laman web saya tidak disimpan dalam pangkalan data, semuanya dibina menggunakan SSG next.js. Ia langsung tidak mempunyai masa kemas kini.

Satu teknik di sini ialah: Apabila menyelesaikan masalah, kita tidak sepatutnya terus memberikan keperluan asal kepada Claude Code, atas beberapa sebab berikut

1. Keperluan asal agak kabur, ia mungkin tersalah faham, dan jika ia tersalah faham, walaupun akhirnya menambah masa, masa itu mungkin tidak boleh dipercayai

2. Penggunaan Token Claude Code memang sangat mahal, oleh itu, keperluan kabur boleh menyebabkan banyak Token dibazirkan tanpa makna

Oleh itu, kita perlu menguraikan keperluan asal sekali. Saya terlebih dahulu berunding dalam deepseek, dan deepseek memberi saya dua penyelesaian

1. Masa pembinaan fail, setiap kali build, kita perlu mendapatkan masa pembinaan fail, tetapi strategi pembungkusan turbopack agak berbeza, setiap kali dibina, nilai hash fail akan berubah, jadi masa pembinaan ini mungkin tidak boleh dipercayai

2. Masa penyerahan git, saya fikir, ini sepatutnya lebih boleh dipercayai

Setelah mempunyai arah penyelesaian kasar, saya mempunyai kata isyarat mudah ini: Kompilasi masa penyerahan git di bahagian atas setiap artikel .mdx

Claude Code masih agak boleh dipercayai, jika kata isyarat agak tepat, secara keseluruhannya tiada masalah, terus melaksanakan

Setelah menghabiskan 7 dolar daripada kuota saya, mengambil masa kira-kira 20 minit, akhirnya berjaya dilaksanakan.

Jika tiada masalah, maka masalah timbul, ia sebenarnya melangkau perubahan 171 fail.

Satu tempat yang sangat mengelirukan di sini ialah, sebenarnya fail yang dilangkau di sini hanya menghantar satu parameter tambahan pass, selain itu semuanya sama

<PostLayout pass>...

Tetapi ia tidak fleksibel, mentakrifkan parameter tambahan yang dihantar ini sebagai komponen tersuai yang sama sekali berbeza. Kemudian melangkau dan tidak memprosesnya ～ ～

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 (
    <Layout gitInfo={gitInfo || undefined}>
      {children}
    </Layout>
  );
}

Tetapi keadaan sebenar ialah, hasil yang saya perlukan adalah seperti ini, hasil pelaksanaan adalah sama sepenuhnya.

import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
  return (
    <MdxLayout pass filePath="src/app/r19base/(4.compiler)/23.compilerlower/page.mdx">
      {children}
    </MdxLayout>
  );
}

Kemudian pada masa ini, saya terjebak dalam kata isyarat

Saya memasukkan kata isyarat sekali lagi: Gunakan cara yang sama seperti di atas untuk menyusun semula 171 fail yang dilangkau

Ungkapan saya ini, jika difikirkan dengan teliti, ia mempunyai sedikit kekaburan. Kerana Claude Code telah memberi saya satu cadangan penyelesaian, tetapi saya tidak menerima penyelesaian ini, niat saya adalah, menggunakan penyelesaian seperti ratusan fail yang telah diubah suai untuk mengubah fail yang dilangkau, tetapi dalam proses pelaksanaan, ia difahami sebagai: penyelesaian yang dicadangkannya di atas

Kekaburan ini menyebabkan ia melaksanakan mengikut penyelesaian yang saya tidak mahukan selama 20 minit, di tengah-tengah juga terdapat 2 kesilapan pembaikan diri, terus menelan token saya, dua kekaburan mula bertarung menyebabkan kesilapan.

Akhirnya saya terpaksa meninggalkan pelaksanaan ini sekali lagi, menjelaskan semula maksud saya.

Ringkasan

1. Dalam kata isyarat, sebaiknya mengandungi penyelesaian yang agak stabil dan tepat, biarkan AI berfikir semakin sedikit semakin baik, ini boleh mengurangkan kadar halusinasi.

2. Kata isyarat keperluan pasti tidak boleh mempunyai kekaburan, kekaburan mudah menyebabkan kesilapan, walaupun Claude Code akhirnya boleh dibaiki, tetapi ini akan menyebabkan penggunaan token yang besar. Dan kerana LLM berdasarkan mekanisme ramalan untuk menghasilkan hasil, salah baca awal, kekaburan, dan lain-lain, akan menyebabkan setiap langkah seterusnya semakin jauh ke arah yang salah, dan ia juga akan cuba logik konsisten diri, menjana beberapa perkara yang tidak wujud, semakin menulis semakin banyak masalah, juga meningkatkan kesukaran penyemakan pembangun, jika anda tertipu oleh halusinasinya, maka akan menyebabkan akibat yang serius

3. Kekangan bahasa semula jadi tidak setepat kod, dalam kata isyarat, mengandungi nama fail, pembolehubah kod, perkataan khusus kod, istilah profesional, dan lain-lain, akan mengurangkan halusinasi Cluade Code dengan ketara