Inclua regras de entrada, saída e erros em uma solicitação de script para o trabalho

01Complete a descrição da tarefa antes de obter código

Uma boa request contém work rules concretas em vez de uma role instruction longa. “Organize os arquivos de forma adequada” não decide qual folder ler, como nomear o result, como lidar com duplicates ou se deve sobrescrever. Este artigo limita o scope a uma pequena tarefa: combinar uma semana de synthetic work logs por team. O result é uma request reutilizável, além dos arquivos de input e expected result.

02Divida o trabalho em seis itens

Você também precisa escrever o que “time per item” realmente significa. Neste synthetic example, todos os input minutes são definidos como o work time correspondente ao completed count da row. Se isso incluir waiting time ou tempo em unfinished work, o significado desse average muda, então defina primeiro a work definition.

03Ordem para escrever a solicitação

1. Reduza o scope da automation a um único result. Não misture collecting files, tallying e sending email de uma vez; defina este result como um per-team summary file.
2. Escreva os key names, data types e units do input. Declare claramente, por exemplo, que completed é um integer e time é um integer em minutes.
3. Em vez de usar um original com real names e internal paths removidos, crie uma synthetic sample. Os dados podem ser identificados por transactions ou unusual values mesmo se os nomes forem alterados, portanto escreva todo o example do zero.
4. Calcule por conta própria o expected result da sample. Decida nesta etapa se deve dividir depois de somar ou calcular average por row.
5. Escreva as handling rules para errors, empty input, division by zero e existing output files.
6. Antes de enviar a request, procure conflicting instructions. Não diga que todos os values são integers e depois diga para transformar blanks automaticamente em 0.

04Combine o input com o resultado esperado

O Design team tem 5 items e 140 minutes, portanto time per item é 28 minutes. Se você usar 27.5 minutes, o simple average dos per-row values de 30 e 25 minutes, a diferença nos item counts não é refletida. O Operations team tem 4 items, 80 minutes e 20 minutes per item. Os 0 items do Support team significam que não há average a calcular, então ele é mostrado como null.

input-sample.json e expected-output.json formam um pair que mostra essas diferenças. JSON é um formato de structured data, e null é diferente do number 0. Essa distinção também pode ser confirmada no value mapping descrito na documentação oficial de json do Python.

05Uma solicitação que você pode editar e usar imediatamente

다음 조건을 만족하는 로컬 Python 스크립트를 작성해 주세요.

[업무 목적]
한 주의 작업 기록을 팀별로 합쳐 완료 건수, 작업 시간 합계(분), 건당 작업 시간(분/건)을 확인합니다.
이 요청의 모든 기록은 합성 샘플입니다. 실명, 고객 정보, 계약 내용, 사내 경로, 계정 키는 포함하지 않습니다.

[실행 환경과 범위]
Python 3 표준 라이브러리만 사용합니다. 외부 패키지 설치, 인터넷 접속, 유료 API 호출, 이메일 전송은 하지 않습니다.
현재 작업 폴더의 input.json만 읽습니다. 하위 폴더 탐색, 원본 수정, 파일 삭제는 하지 않습니다.
새 output.json을 만듭니다. output.json이 이미 있으면 덮어쓰지 말고 이유를 알려주며 종료합니다.

[입력 형식]
UTF-8 JSON 배열입니다. 각 행에는 record_id, team, completed, minutes 네 키만 있습니다.
record_id는 중복되지 않는 비어 있지 않은 문자열입니다.
team은 설계, 운영, 지원 가운데 하나입니다. 알 수 없는 팀은 임의로 바꾸지 않습니다.
completed와 minutes는 0 이상의 정수입니다. 문자열 숫자, true/false, null, 누락 값은 허용하지 않습니다.
입력 배열은 비어 있어도 됩니다. 한 행의 오류라도 있으면 전체 집계를 중단합니다.

[입력 샘플]
[
  {"record_id":"S001","team":"설계","completed":3,"minutes":90},
  {"record_id":"S002","team":"설계","completed":2,"minutes":50},
  {"record_id":"O001","team":"운영","completed":4,"minutes":80},
  {"record_id":"H001","team":"지원","completed":0,"minutes":0}
]

[처리 규칙]
팀별 completed와 minutes를 각각 합합니다.
minutes_per_completed = 팀 작업 시간 합계 / 팀 완료 건수 합계입니다.
행별 평균을 다시 평균하지 않습니다. 건수가 0이면 minutes_per_completed는 JSON null입니다.
평균은 계산 후 Decimal의 ROUND_HALF_UP 방식으로 소수 둘째 자리까지 반올림해 JSON 숫자로 저장합니다.
출력에는 입력에 나타난 팀만 넣고, 팀 순서는 설계 → 운영 → 지원으로 고정합니다.
빈 입력의 출력은 빈 배열 []입니다.

[기대 결과]
[
  {"team":"설계","total_completed":5,"total_minutes":140,"minutes_per_completed":28.0},
  {"team":"운영","total_completed":4,"total_minutes":80,"minutes_per_completed":20.0},
  {"team":"지원","total_completed":0,"total_minutes":0,"minutes_per_completed":null}
]
JSON 숫자는 28과 28.0의 표기가 달라도 같은 값으로 비교합니다.

[오류 원칙]
파일 없음, 잘못된 JSON, 배열이 아닌 최상위 구조, 중복 record_id, 필수 키 누락,
추가 키, 허용되지 않은 팀, 음수/문자열/불리언 숫자를 발견하면 성공 결과를 만들지 않습니다.
오류 메시지는 행 번호(1부터 시작)와 필드 이름, 오류 이유만 출력하고 입력 내용 전체를 출력하지 않습니다.
입력 오류를 0으로 바꾸거나 잘못된 행을 조용히 건너뛰지 않습니다. 종료 코드는 실패를 나타내야 합니다.

[답변 형식]
먼저 목적, 입력, 출력, 오류 처리, 남은 가정을 짧게 요약합니다.
그 다음 완성 스크립트와 실행 방법, 이 샘플의 기대 결과를 제시합니다.
요구사항끼리 충돌하거나 업무 의미를 확정할 수 없으면 코드를 쓰기 전에 해당 쟁점만 질문합니다.
실제로 실행하지 않았다면 실행 완료라고 쓰지 않습니다.

Ao reutilizar isso para outro trabalho, não altere apenas os team names; altere também purpose, input definition, formula, significado dos valores 0 e blank e expected result. Se o input sample e o expected result não concordarem, fica incerto qual deles a IA tratará como reference.

06Verifique antes de enviar

• O file name, read scope e output location estão informados?
• Data type, unit e allowed values estão definidos para cada field?
• É possível ver o denominator do average e quando ocorre rounding?
• Os casos missing, duplicate, zero-count e empty-array estão definidos de forma diferente?
• A sample mostra a work structure sem nenhuma real sensitive information?
• Uma pessoa consegue explicar o sample result?
• Você pediu para não afirmar que executou algo que não executou?

A OWASP explica a verificação tanto do input format quanto do business meaning dos values. Este artigo leva essa distinção para a request definindo separadamente “é um integer?”, “é 0 ou maior?” e “é um allowed team?”. Escrever isso na request não significa que o returned code realmente implemente essas rules.

07Causas comuns de respostas inconsistentes

08O que este material verificou e próximos passos

Uma request é um agreement document para implementation. Se o code executa corretamente, lida com files com segurança e se adapta a real work data precisa ser verificado separadamente no code recebido. Este material verificou os expected values da synthetic sample com Python e confirmou que a request contém os required items. Ele não inclui resultados de uma solicitação a um AI service nem da execução de generated code.

• request.txt: a request completa acima
• input-sample.json: quatro rows de synthetic input sem sensitive information
• expected-output.json: expected result correspondente ao hand calculation e Python check
• prompt-checklist.txt: checklist para escrever requests
• README.txt: ordem para ler os files

As References foram verificadas nas páginas oficiais em 2026-09-19. Os documentos do Python e da OWASP dão suporte aos princípios de input format e validation; eles não garantem a answer quality de nenhum AI service.

Registro de execução e verificação

Biblioteca padrão local do Python no Windows; fontes oficiais verificadas em 2026-09-19

• Foram calculados independentemente os count e time totals e averages por team para as 4 synthetic input rows e comparados com expected-output.json
• Foi verificado que o average do Support team com 0 items é null
• Foram verificados os itens input, output, sample, error e sensitive-information exclusion da request e a sintaxe JSON

Princípios de redação e verificação de todo o site

Fontes de referência

As explicações e os exemplos são de elaboração própria. Os comportamentos e conceitos relacionados podem ser consultados nas fontes oficiais abaixo.

• Documentação oficial do Python · módulo json ↗ (New tab)
• OWASP · Guia de validação de entradas ↗ (New tab)