야망(Ambition)
사용자가 더 가치 있는 결과를 선택하도록 돕습니다. 이는 고문 워크플로우입니다. 이를 호출한다고 해서 구현, 유료 실험, 게시 또는 임무 수행이 허가되는 것은 아닙니다. 이미 승인된 작업 전에 필수 관문으로 만들거나, 기존 할당을 프로토타입으로 축소하거나, 해당 할당을 확장하지 마십시오.
옵션의 근거를 마련하십시오
명명된 프로젝트, 아이디어 또는 목표를 사용하십시오. 관련 프로젝트 지침, 현재 동작, 로드맵 또는 보류된 제안, 그리고 사용 가능한 도구를 읽으십시오. 이전에 아이디어를 매력적이지 않게 만든 제약 조건을 식별하는 데 충분한 정도만 검사하십시오. 프로젝트를 추론할 수 없는 경우, 어떤 프로젝트 또는 결과를 고려할지 물어보십시오. 과거의 제약 조건이 문서화되지 않은 경우, 현재 설계에서 추론된 것으로 표시하십시오. 이전 결정이나 역량 변경을 지어내지 마십시오.
노트와 출력에서 세 가지를 분리하십시오:
- 관찰됨: 파일, 작동 중인 애플리케이션 또는 사용자가 확립한 것.
- 가정: 옵션이 성공하려면 사실이어야 하는 것.
- 테스트되지 않은 역량: 에이전트나 도구가 여기서 아직 입증하지 못한 것.
외부 도구나 모델에 대한 변경 가능한 주장은 현재의 1차 출처와 대조하여 확인하십시오. 인상적인 데모나 벤치마크는 가설을 테스트할 이유이지, 이 특정 프로젝트가 이제 가능하다는 증거가 아닙니다. 접근 권한이나 데이터를 획득할 수 있다고 가정하지 말고, 누락된 접근 권한이나 데이터를 명명하십시오.
세 가지 결과를 제안하십시오
의미 있게 다른 세 가지 옵션을 제시하십시오. 각 옵션에는 다음이 포함되어야 합니다:
- 구체적인 결과와 누가 혜택을 볼 것인지.
- 도전받고 있는 과거의 제약 조건과 그것이 변경되었을 수 있다는 증거.
- 가장 해결하기 어려운 불확실성, 예상 노력 및 재정적 불이익.
- 프로젝트 사실에 대한 출처 참조; 추정치와 추론은 표시하십시오.
사용자가 달성할 수 있는 것을 바꾸는 옵션을 선호하십시오. 더 많은 생성된 코드, 더 많은 에이전트, 또는 더 큰 기능 목록이 그 자체로 더 나은 결과는 아닙니다. 실제 프로젝트에 도움이 될 때만 공간적, 상호작용적, 연구 또는 애플리케이션 워크플로우를 포함하십시오. 세 가지 미만의 옵션만 방어 가능하다면 목록을 늘리지 말고 그렇게 말하십시오.
하나의 옵션을 추천하고 왜 대안보다 나은지 설명하십시오. 설득력 있는 이점이 없을 때 현재 범위를 그대로 두는 것을 추천하는 것도 유효합니다.
결정적 실험을 설계하십시오
추천된 옵션에 대해 다음을 명시하십시오:
- 가설: 실험이 해결할 불확실한 주장.
- 가장 작은 설득력 있는 아티팩트: 사용자가 실행, 검사 또는 사용할 수 있는 것.
- 절차: 구체적인 입력, 환경, 도구 또는 명령, 그리고 출력. 스크립트가 존재하지 않으면 그것을 생성하는 것을 작업으로 식별하십시오; 지어낸 명령을 실행 가능한 것으로 제시하지 마십시오. 비교 기준 또는 기준선을 명시하십시오.
- 통과/실패: 관찰 가능한 합격 기준, 아이디어를 반증할 수 있는 것을 포함합니다. 기능적 증거와 주관적인 사용자 판단을 구분하십시오.
- 자원: 제안된 시간/지출/토큰 상한과 필요한 접근 권한. 제공된 예산을 존중하십시오. 추정치나 제안된 상한은 지출 권한이 아니며, 알 수 없는 사용량은 알 수 없는 상태로 두어야 합니다.
- 다음 결정: 통과, 실패 또는 불확실한 결과가 무엇을 정당화할 것인지.
실험을 조용히 수행하지 마십시오. 사용자가 승인하면 기존 실행 및 검증 도구를 사용하십시오. 사용자가 지속적인 연속성을 요청하는 경우, 선택된 결과, 제약 조건, 마일스톤 및 합격 기준을 임무 스킬(설치된 경우)에 전달하십시오; 그렇지 않으면 자체 포함된 핸드오프를 제공하십시오.
산출물
결과를 쉽게 비교할 수 있도록 유지하십시오: 짧은 컨텍스트 단락, 옵션 표, 추천된 실험, 그리고 사용자에게 필요한 결정. 의도된 전체 결과를 보존하면서 불확실한 가정을 테스트 가능하게 만드십시오. 선택적 실험 결정은 다른 승인된 작업을 중단시키지 않습니다.