На основе реального случая автоматического программирования с Claude Code, поделюсь некоторыми техниками написания промптов
В этой статье, на основе реального случая, я поделюсь с вами практическим примером использования Claude Code. Перед тем как поделиться, давайте проведем небольшой опрос
Исходное требование: один уважаемый платный пользователь пожелал, чтобы я добавил в статьях время их изменения
На первый взгляд, реализовать это требование было несколько сложно. Потому что статьи на моем сайте не хранятся в базе данных, все они построены с использованием SSG в next.js. У них просто нет времени обновления.
Один из приемов здесь заключается в следующем: при решении проблемы не стоит напрямую передавать исходное требование в Claude Code, по нескольким причинам
1. Исходное требование относительно расплывчато, он может понять его неправильно, и если он поймет его неверно, то в итоге, хотя и добавит время, это время может оказаться ненадежным
2. Расход токенов в Claude Code действительно очень дорогой, поэтому нечеткое требование может привести к бессмысленному расходованию большого количества токенов
Поэтому мы должны разбить исходное требование на части. Сначала я проконсультировался в deepseek, и deepseek дал мне два варианта
1. Время сборки файла, при каждой сборке нам нужно получать время сборки файла, но стратегия сборки turbopack несколько иная, при каждой сборке хэш-значение файла меняется, это время сборки может быть ненадежным
2. Время коммита в git, я подумал, что это должно быть более надежным
Имея общее направление решения, у меня появился этот простой промпт: скомпилировать время коммита git в заголовке каждой статьи .mdx
Claude Code все же довольно надежен, если промпт достаточно точный, в целом проблем нет, он просто начинает выполнять
После того как я потратил 7 долларов из своего лимита, примерно за 20 минут, наконец-то выполнение завершилось успешно.
Как и следовало ожидать, произошло неожиданное: он пропустил изменения в 171 файлах.
Здесь есть очень неприятный момент: на самом деле пропущенные файлы лишь передавали дополнительный параметр pass, все остальное было полностью одинаковым
<PostLayout pass>...Но он не проявил гибкости, определив этот дополнительный параметр как совершенно другой пользовательский компонент. И затем просто пропустил его, не обрабатывая ～ ～
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>
);
}Но реальная ситуация такова, что мне нужен был такой результат, и результат выполнения был бы полностью идентичным.
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>
);
}И вот здесь я попал в ловушку с промптом
Я снова ввел промпт: используя тот же способ, что и выше, рефакторите пропущенные 171 файл
Моя формулировка, если подумать, содержит некоторую двусмысленность. Потому что Claude Code уже предложил мне вариант решения, но я его не принял. Моим намерением было изменить пропущенные файлы по той же схеме, что и уже измененные сотни файлов, но в процессе выполнения он понял это как: тот вариант, который он предложил выше
Эта двусмысленность привела к тому, что он 20 минут выполнял по нежелательной для меня схеме, в середине даже дважды произошли ошибки с самовосстановлением, он яростно поглощал мои токены, две интерпретации начали конфликтовать, что привело к ошибкам.
В итоге мне пришлось отказаться от этого выполнения и заново четко сформулировать свою мысль.
Итог
1. В промптах лучше всего содержать относительно стабильные и точные решения, чем меньше AI думает, тем лучше, это снижает частоту галлюцинаций.
2. В промптах с требованиями не должно быть двусмысленности, двусмысленность легко приводит к ошибкам, хотя Claude Code в итоге может исправить их, но это вызовет большой расход токенов. И поскольку LLM генерирует результаты на основе механизма предсказания, раннее неверное прочтение, двусмысленность и т.д. приведут к тому, что каждый последующий шаг будет уходить все дальше в неправильном направлении, и он будет пытаться логически самоутвердиться, генерируя несуществующие вещи, чем больше пишет, тем больше проблем, что также увеличивает сложность проверки для разработчика, если вы поддадитесь его галлюцинациям, это может привести к серьезным последствиям
3. Ограничения естественного языка не так точны, как код; включение в промпты имен файлов, переменных кода, специальных терминов кода, профессиональной терминологии и т.д. значительно снижает галлюцинации Claude Code
