검토할 수 있는 diff로 끝나는 파스칼 프로그래밍

에이전트가 프로젝트에서 수행할 수 있는 작업

• 파일read_file, write_file, edit_file, grep, glob 및 list_dir는 채팅의 작업 폴더 내에서 작동합니다. 따라서 .pas 단위, .dpr 파일 또는 텍스트 .dfm 폼은 한 번의 요청으로 처리할 수 있습니다. 생성, 편집 및 읽은 파일 수는 카운터로 표시됩니다.
• ShellWindows, WSL 또는 소유한 서버의 SSH에서 빌드 명령, 테스트 명령 또는 포맷터를 실행합니다. 성공 여부는 실제 종료 코드로 판단되며, 위험한 명령은 실행 전에 차단됩니다.
• 웹web_search는 페이지를 찾고 http_get은 하나의 문서 페이지를 읽습니다. 이는 특정 루틴의 정확한 시그니처나 오류 메시지의 정확한 문구가 필요할 때 도움이 됩니다. 에이전트가 페이지를 읽고, 사용자는 무엇을 사용할지 결정합니다.
• 스크린샷 및 이미지ocr는 저장된 스크린샷의 텍스트를 읽습니다. 예를 들어 창에서 복사할 수 없는 컴파일러 메시지의 경우입니다. gen_image는 실제 이미지 파일을 작업 폴더에 저장합니다.
• 오케스트레이션task는 독립적인 작업 부분에 대해 병렬 하위 에이전트를 시작합니다. run_on_model은 하나의 어려운 단계를 더 큰 모델로 보냅니다. skill은 저장된 플레이북(예: 브랜치 및 커밋을 위한 버전 관리 절차)을 재사용합니다.
• 승인 모드Auto-run은 즉시 실행하며, Ask first는 변경 사항을 생성하는 작업 전에 일시 중단하고 diff를 표시해 수락할 수 있게 합니다. Plan only는 계획만 작성하고 아무것도 실행하지 않습니다. 계획은 앱 재시작 후에도 유지됩니다.
• Cron예약된 시간에 프롬프트를 실행합니다. 예를 들어 매일 밤 빌드 명령을 실행하고 종료 코드를 보고하는 요청을 설정할 수 있습니다. 일정을 한 번 설정하면 다음 아침 채팅에서 결과를 확인할 수 있습니다.
• 모델API 엔드포인트를 통해 클라우드 AI 공급자, PC에서 로컬로 실행되는 모델 또는 내장 모델에 연결합니다. 테스트 버튼은 연결의 응답 시간과 컨텍스트 창을 보여줍니다.

실제 프로젝트의 네 가지 작업

상속된 단위 읽기

프로젝트를 상속받은 Delphi 개발자는 종종 몇 년간 손보지 않은 단위를 열 때가 많습니다. Arraydeck에게 단위를 설명해 달라고 요청하세요. 에이전트는 read_file을 호출한 후 인터페이스 섹션, 구현 섹션 및 uses 절을 평이한 언어로 설명합니다. grep은 해당 절차가 다른 단위에서 어떻게 호출되는지 보여줍니다. 아무것도 작성되지 않습니다. 이 답변을 증거가 아닌 지도로 사용하세요. 프로젝트의 줄을 변경하기 전에 각 주장이 소스와 일치하는지 비교하고, 자신의 편집기에서 단위를 열며 빌드 명령을 실행해 실제 종료 코드를 확인하세요. 첫 번째 단위가 명확해지면 다음 단위에 대해 요청을 반복하세요.

문자열 루틴이 Unicode를 처리하도록 만들기

문자열의 Unicode 코드를 변환하려면 먼저 텍스트를 생성하거나 분할하는 루틴을 찾아야 합니다. 에이전트는 함수 이름에 대해 grep을 실행하고 read_file로 단위를 읽은 후 edit_file로 변경을 제안합니다. Ask first 모드에서는 diff가 수락을 기다립니다. 그런 다음 Shell은 빌드 명령과 테스트 명령을 실행하며, 각 카드는 실제 종료 코드를 보여줍니다. 문자열은 작은따옴표를 사용하고 :=은 값을 할당하므로, 이전 루틴이 어떻게 작동했는지와 비교해 diff를 읽고 자체 데이터의 텍스트로 테스트하세요. 한 가지 사례라도 다르게 동작하면 변경 사항을 거부하세요. 테스트가 일치할 때까지 이전 루틴의 사본을 보관하세요.

함수의 반환 횟수 줄이기

함수에 반환문이 몇 개 있어야 하는지에 대해서는 의견이 분분하지만, Arraydeck은 이 선택을 사용자에게 맡깁니다. 여러 종료 지점이 있는 함수를 선택하고 Result에 한 번만 값을 설정하는 버전을 요청하세요. 에이전트는 단위를 읽고 함수를 편집한 후 변경 사항을 diff로 보여줍니다. 파스칼 프로그래밍에서는 반환 값을 Result에 유지하므로 편집이 작고 줄별로 쉽게 확인할 수 있습니다. 이후 테스트를 실행하세요. 에이전트가 새 버전이 이전 버전과 같은 동작을 보장하지 않기 때문입니다. 테스트가 실패하면 diff를 거부하세요. 검토된 작은 편집이 큰 리팩토링보다 낫습니다.

폼이 대화 상자를 어떻게 사용하는지 확인하기

프로젝트에서 FMX 대화 상자를 올바르게 사용하는 방법을 확인하려면 에이전트에게 대화 상자가 표시되는 모든 위치를 찾아달라고 요청하세요. 에이전트는 .pas 파일에 대해 grep을 실행하고 read_file로 일치 항목을 엽니다. 그런 다음 각 단위와 이벤트 핸들러를 명시하는 짧은 목록을 채팅에 작성합니다. 버튼 클릭과 같은 이벤트는 폼의 절차이므로 목록은 목차처럼 읽힙니다. 변경 사항을 요청하기 전에 Ask first로 전환하세요. 각 diff를 검토하고 폼을 직접 테스트하세요. 에이전트는 폼을 시각적으로 디자인하지 않기 때문입니다. 각 폼에 대해 반복하세요.