Pek gesaan pengekodan Claude untuk penyahpepijatan, refactor, dan semakan seni bina

Empat kekangan yang menjadikan setiap gesaan di bawah berkesan

Sebelum gesaan-gesaan itu, inilah peraturan yang dikongsi semuanya. Menambah ini pada mana-mana gesaan pengekodan menambah baik output lebih daripada menukar model.

Nyatakan versi anda. Data latihan cenderung ke arah versi utama yang paling banyak ditulis mengenainya, yang selalunya bukan versi yang anda gunakan. We are on [framework] [version], [language] [version] menghalang kebanyakan jawapan lapuk.

Hadkan diff. Minta pembetulan dan anda selalunya mendapat refactor. Change as little as possible, preserve existing structure and naming, and list every line you changed with a one line reason ialah ayat paling berguna dalam dokumen ini.

Minta hipotesis sebelum penyelesaian. Model yang ditanya apa yang salah memberi anda tekaan yang disampaikan sebagai kesimpulan. Model yang diminta punca mengikut kedudukan dan semakan murah memberi anda rancangan penyahpepijatan.

Wajibkan mod kegagalan. What could this break, and is this fixing the cause or the symptom? mengesan kelas bantuan AI paling mahal, iaitu perubahan yang menghilangkan simptom sedangkan kecacatan kekal.

Penyahpepijatan

1. Hipotesis mengikut kedudukan

Here is the error, the relevant code, and what I have already ruled out. Do not give me a fix yet. List the four most likely causes ranked by probability, and for each the single cheapest check that would confirm or eliminate it. Error: [paste]. Code: [paste]. Already ruled out: [list]. Stack: [language, framework, versions].

2. Pepijat berselang

This fails intermittently, roughly [frequency], under [conditions]. Enumerate the categories of intermittent failure that could produce this specific symptom: timing, ordering, resource exhaustion, an external dependency, state leaking between runs, clock or timezone, caching. For each, say what in the code supports or contradicts it, and exactly what I should log to distinguish them. Code: [paste].

3. Berfungsi secara tempatan

This works locally and fails in [environment]. List every category of environment difference that could cause this specific symptom: configuration, environment variables, versions, filesystem and case sensitivity, timezone and locale, network and DNS, permissions, resource limits, and build or bundling differences. Rank by likelihood given the symptom, and give me the diagnostic command for each.

4. Terangkan pembetulan sebelum saya menerimanya

Explain why this fix works, what it does not fix, and what it could break. If the real cause is elsewhere and this is a symptom patch, say so directly.

Semakan kod

5. Semak diff

Review this diff as a demanding reviewer. Categories in priority order: correctness bugs, security issues, unhandled failure modes, race conditions, then style. For each finding give severity, the specific line, and why it matters in this codebase rather than in general. Do not comment on formatting. If the diff is sound, say so rather than manufacturing findings. Conventions: [describe]. Diff: [paste].

6. Semakan keselamatan

Review this code for security issues specifically: injection, authentication and authorisation gaps, unsafe deserialisation, secrets in code or logs, unvalidated input reaching a sensitive operation, and dependency risk. For each, give the attack path concretely rather than naming the category. State clearly what you cannot assess without seeing [deployment, auth layer, data sensitivity].

7. Audit mod kegagalan

For each external call in this code, state what happens when it is slow, when it fails, when it returns unexpected data, and when it succeeds but partially. Which of those are currently unhandled, and which would be silent?

Yang terakhir itu mengesan lebih banyak isu produksi sebenar berbanding semakan umum, kerana ia bertanya tentang laluan yang tiada sesiapa menulis ujian untuknya.

Refactoring dan seni bina

8. Rancangan refactor

Propose a sequenced plan to refactor [description]. Constraints: the public API of [x] cannot change, we deploy continuously so every step must be independently shippable, and tests must pass after each step. For each step give the change, the risk, how to verify it, and how to roll it back. Order by risk, lowest first. Do not write the code yet.

9. Hujahkan sebelah lain

I am choosing [approach A] over [approach B] for [context and constraints]. Make the strongest case for B. What would have to be true about our constraints for B to be correct, and is any of it true here? Do not conclude that both are valid.

10. Fahami apa yang anda warisi

Here are the main source files. Produce: the entry points, the data flow from request to response, the state that is shared and where it is mutated, external dependencies and what happens when each is unavailable, and the three areas most likely to contain bugs based on complexity and coupling. State explicitly what you cannot determine from what I provided.

Arahan terakhir itu penting. Model akan menerangkan tingkah laku fail yang anda tidak tampal, yang disimpulkan daripada namanya. Memaksa senarai jelas perkara yang tidak diketahui memberitahu anda apa yang perlu dibaca.

Ujian

11. Ujian yang tidak akan anda tulis

Write test cases for this function, focusing on inputs I probably have not considered: boundaries, empty and null, unicode, very large values, concurrent calls, and any implicit assumption in the implementation. For each test, state the assumption it is checking. Function: [paste].

12. Uji suite ujian

Here is a function and its existing tests. What behaviour is not covered? Specifically: error paths, boundary values, interactions between parameters, and anything the implementation does that no test asserts. Do not rewrite the existing tests.

Yang kedua ialah gesaan bernilai lebih tinggi dan jarang dijalankan. Peratusan liputan memberitahu anda baris mana yang dilaksanakan, bukan tingkah laku mana yang sebenarnya dipastikan, dan jurang antara kedua-duanya itulah tempat regresi tinggal.

Corak pendapat kedua

Tabiat paling bernilai dalam keseluruhan pek ini, dan satu-satunya yang memerlukan lebih daripada satu model.

Dapatkan jawapan daripada satu model. Kemudian tukar dan serahkannya:

Another engineer proposed this solution to this problem. Find what is wrong with it: correctness under edge cases, concurrency, error handling, performance at [scale], or a simpler approach that was missed. If it is genuinely sound, say so plainly rather than inventing objections. Problem: [paste]. Proposed solution: [paste].

Dua hasil dan kedua-duanya berguna. Sama ada model kedua menjumpai lubang sebenar, yang kini anda ketahui sebelum menggabungkan (merge), atau ia bersetuju walaupun didesak untuk tidak bersetuju, iaitu pengesahan yang bermakna. Mengulangi dengan model yang sama tidak memberikan anda kedua-duanya, kerana model yang menyemak outputnya sendiri kebanyakannya bersetuju dengan dirinya sendiri.

Gunakannya pada keputusan yang mahal jika tersilap: perubahan skema, pembetulan concurrency, apa sahaja yang menyentuh auth atau wang. Bukan untuk kerja rutin. Lihat bandingkan model bersebelahan, menukar model di tengah perbualan, dan tulis dan nyahpepijat kod dengan pelbagai model untuk keseluruhan aliran kerja di satu tempat.

Apa yang perlu diperhatikan

API rekaan. Nama kaedah, parameter, dan kunci konfigurasi yang yakin tetapi tidak wujud, terutamanya untuk pustaka yang baru-baru ini berubah. Tandatangan itu akan kelihatan betul. Semak dokumentasi sebenar sebelum membina di atas apa-apa yang tidak biasa.

Tiada isyarat keyakinan. Pembetulan yang betul dan yang salah secara halus datang dengan kepastian yang sama. Nada tidak memberitahu anda apa-apa.

Skop yang merayap secara senyap. Inilah sebab kekangan kedua wujud.

Teater keselamatan. Menamakan kelas kelemahan dalam kod anda adalah langkah pertama yang berguna. Ia bukan audit, dan model tidak mengetahui model ancaman, deployment, atau sensitiviti data anda.

Simpan gesaan yang anda guna setiap minggu di suatu tempat yang boleh anda tampal, dan letakkan kekangan tetap dalam arahan projek supaya ia terpakai secara automatik pada setiap sembang dalam projek itu.