SOOKMYUNG · PBL Ⅰ · AI PROBLEM SOLVING

PBLⅠ 학습 포털 · 15주차

정의된 문제를 작동하는 해결책으로 바꿉니다. 매주 하나의 산출물을 만들고, 실습 프롬프트를 그대로 복사해 쓰며, 제너레이터로 나만의 지시문을 만듭니다.

2026학년도 2학기  |  월 15:00-17:50 (명신관517)  |  담당 정진혁
학습 흐름  문제 분해해법 발산수렴·선정로직 설계자동화프로토타입검증발표
학습 진도0 / 15 주차 완료
PART 1 · 문제의 해부
PART 2 · 발산과 수렴
PART 3 · 로직과 자동화
PART 4 · 프로토타입과 검증
PART 1 · 1주차 · 오리엔테이션

문제 해결이란 무엇인가

AI는 마법 지팡이가 아니다 — 해결 가능한 문제를 고르는 눈
학습 목표이번 학기에 내가 실제로 해결할 문제 1건을 고르고, 그 문제가 “해결 가능한 형태”인지 판정할 수 있다.
이론 슬라이드 (10장)
핵심 개념
해결 가능한 문제의 조건

범위가 닫혀 있고, 성공을 판정할 기준이 있으며, 한 학기 안에 결과를 확인할 수 있어야 합니다.

AI가 못 하는 일

무엇을 해결할지 결정하기, 가치를 판단하기, 책임지기. 이 셋은 끝까지 사람의 몫입니다.

컴퓨팅 사고 3단계

분해(쪼개기) · 패턴인식(반복 찾기) · 추상화(핵심만 남기기). 이 과목 전체의 뼈대입니다.

문제 발견 → 문제 해결

PBLⅡ가 “무엇이 문제인가”였다면, PBLⅠ은 “그래서 어떻게 할 것인가”입니다.

실습 절차 (170분)
STEP 1 · 후보 3건 적기 (25분)최근 3개월 안에 직접 겪은 불편 3가지를 씁니다. 남의 문제가 아니라 내 문제여야 합니다.
STEP 2 · 해결가능성 판정 (40분)아래 프롬프트로 3건을 범위·판정기준·기간 관점에서 채점하고, 해결 불가능한 형태를 걸러냅니다.
STEP 3 · 1건 확정 (45분)한 문장으로 문제를 정의합니다. “누가 / 언제 / 무엇 때문에 / 어떤 손해를 본다”의 형식.
STEP 4 · 성공 기준 선언 (60분)학기말에 무엇이 달라져 있어야 “해결했다”고 말할 수 있는지 수치 또는 관찰 가능한 상태로 적습니다.
실습 프롬프트
이번 주 산출물문제 선정서 A4 1매(문제 한 문장 + 성공 기준 3층위) + 주간 성찰 보고서
체크포인트
  • 후보 3건을 적고 점수로 걸러냈다
  • 문제를 “누가/언제/무엇 때문에/어떤 손해” 한 문장으로 썼다
  • 성공 기준을 관찰 가능한 형태로 3층위 적었다
  • AI가 대신 결정해 준 부분이 없는지 확인했다
PART 1 · 2주차

현상과 원인 분리하기

5 Whys와 로직트리로 증상이 아닌 뿌리를 치기
학습 목표눈에 보이는 증상과 그것을 만드는 원인을 분리하고, 원인 구조를 3단 이상 전개한 로직트리로 그릴 수 있다.
이론 슬라이드 (10장)
핵심 개념
증상 치료의 함정

“알림을 늘리자”는 대개 증상 처방입니다. 왜 놓치는지를 묻지 않으면 같은 문제가 되돌아옵니다.

5 Whys

왜를 다섯 번 묻습니다. 세 번째부터 답이 막히는 지점이 대개 진짜 원인입니다.

로직트리

원인을 가지로 펼칩니다. 같은 층위의 가지들은 서로 겹치지 않아야 합니다(MECE).

공격 지점 선택

모든 원인을 다 칠 수 없습니다. 영향이 크고 내가 손댈 수 있는 하나를 고릅니다.

실습 절차 (170분)
STEP 1 · 증상 나열 (25분)1주차 문제에서 관찰되는 증상만 사실 그대로 6개 이상 적습니다. 해석과 추측은 뺍니다.
STEP 2 · 5 Whys (35분)증상 중 가장 자주 일어나는 것 하나를 골라 다섯 번 파고듭니다. 사람의 게으름으로 끝나면 실패한 것입니다.
STEP 3 · 로직트리 전개 (60분)아래 프롬프트로 원인 구조를 3단 이상 펼치고, 겹치는 가지를 손으로 정리합니다.
STEP 4 · 공격 지점 표시 (50분)영향도 × 통제가능성 2축에 원인들을 배치하고, 이번 학기에 칠 지점 1~2개에 표시합니다.
실습 프롬프트
이번 주 산출물문제 원인 로직트리(3단 이상) + 공격 지점 1~2개 표시본
체크포인트
  • 증상과 원인을 분리해 적었다
  • 로직트리를 3단 이상 전개했다
  • 같은 층위의 겹치는 가지를 정리했다
  • 이번 학기에 칠 공격 지점을 골랐다
PART 1 · 3주차

문제 분해 (Decomposition)

해결 불가능해 보이는 덩어리를 1~2시간짜리 작업으로 자르기
학습 목표큰 문제를 10개 이하의 실행 가능한 작업으로 쪼개고, 각 작업의 선행조건과 산출을 명시할 수 있다.
이론 슬라이드 (10장)
핵심 개념
작업의 적정 크기

한 번 앉아서 끝낼 수 있는 크기(1~2시간). 더 크면 미루게 되고, 더 작으면 관리 비용이 큽니다.

추상화 수준 맞추기

“조사한다”와 “설문 링크를 만든다”가 한 목록에 섞이면 진행이 멈춥니다.

선행조건

무엇이 끝나야 이것을 시작할 수 있는가. 이것이 곧 일정입니다.

제약의 명시화

예산·시간·인력·권한을 숫자로 적습니다. 제약이 명확할수록 해법이 구체화됩니다.

실습 절차 (170분)
STEP 1 · 제약 확정 (25분)가용 시간, 쓸 수 있는 돈, 도와줄 사람 수, 접근 가능한 데이터를 숫자로 적습니다.
STEP 2 · 1차 분해 (45분)아래 프롬프트로 문제를 작업 목록으로 분해합니다. 결과에서 지우는 것이 핵심입니다.
STEP 3 · 크기 맞추기 (50분)2시간을 넘는 작업은 다시 자르고, 15분짜리는 합칩니다. 최종 10개 이하로 만듭니다.
STEP 4 · 순서 확정 (50분)선행조건을 연결해 순서를 정하고, 가장 먼저 할 3개를 표시합니다. 이 표가 남은 12주의 기준입니다.
실습 프롬프트
이번 주 산출물실행 작업표(10개 이하, 작업/산출/시간/선행조건) + 우선 3개 표시
체크포인트
  • 제약을 숫자로 적었다
  • 모든 작업이 1~2시간 크기로 맞춰졌다
  • 작업 수가 10개 이하다
  • 가장 먼저 할 3가지를 골랐다
PART 1 · 4주차

효과적인 AI 소통 · RTCF

역할·작업·맥락·형식 4요소로 지시문 구조화하기
학습 목표같은 질문이라도 4요소를 갖추면 결과가 어떻게 달라지는지 확인하고, 내 문제에 맞는 재사용 템플릿 3종을 만든다.
이론 슬라이드 (10장)
핵심 개념 — RTCF 4요소
R · 역할

누구로서 답할지 지정합니다. 전문성의 층위가 여기서 결정됩니다.

T · 작업

동사로 정확히. 하나의 프롬프트에는 하나의 작업만 넣습니다.

C · 맥락

배경·제약·이미 아는 것. 답의 품질을 가장 크게 좌우합니다.

F · 형식

표·불릿·줄 수·톤. 재작업 시간을 없애는 항목입니다.

실습 절차 (170분)
STEP 1 · 막 던지기 (20분)내 문제와 관련된 질문 하나를 평소처럼 던지고 결과를 저장합니다.
STEP 2 · 4요소 채우기 (40분)같은 질문을 템플릿에 맞춰 다시 씁니다. 맥락에 3줄 이상 넣는 것이 관건입니다.
STEP 3 · 비교와 진단 (40분)두 결과를 나란히 놓고 무엇이 달라졌는지 3가지를 적고, [4-2]로 프롬프트를 진단합니다.
STEP 4 · 템플릿 3종 제작 (70분)조사용·분석용·작성용 템플릿을 각각 만듭니다. 변수는 5개 이내로 유지합니다.
실습 프롬프트
환각(Hallucination) 방지 3규칙① 모르면 모른다고 하라고 명시할 것 ② 수치·인용에는 출처를 요구할 것 ③ 사실과 추론을 분리해 쓰게 할 것. 이 세 줄을 모든 템플릿 하단에 고정으로 넣으십시오.
이번 주 산출물재사용 RTCF 템플릿 3종(조사용·분석용·작성용) + 개선 전후 비교표
체크포인트
  • 같은 질문의 두 결과를 비교해 차이 3가지를 적었다
  • 맥락(C)에 3줄 이상을 채웠다
  • 변수 5개 이내의 템플릿 3종을 완성했다
  • 각 템플릿을 다른 입력으로 한 번 더 돌려 봤다
PART 2 · 5주차

발산적 사고 · SCAMPER × AI

먼저 양으로 이긴다 — 해법 아이디어 30안 만들기
학습 목표SCAMPER 7축으로 해법을 양적으로 확장하고, 판단을 유보한 채 아이디어를 모으는 훈련을 한다.
이론 슬라이드 (10장)
핵심 개념
발산과 수렴의 분리

모으면서 동시에 평가하면 둘 다 망합니다. 이번 주는 평가 금지입니다.

SCAMPER 7축

대체·결합·응용·변형·용도전환·제거·역발상. 막힌 생각을 강제로 옆으로 밀어 줍니다.

AI는 증폭기

내가 3개를 내면 AI는 30개로 늘립니다. 다만 평범한 30개가 되기 쉬우므로 축을 지정해야 합니다.

이상한 아이디어의 값

바로 쓸 수 없는 아이디어가 다음 아이디어의 재료가 됩니다. 지우지 말고 보관하십시오.

실습 절차 (170분)
STEP 1 · 맨손 발상 (25분)AI 없이 혼자 10분, 팀과 10분. 최소 8안을 손으로 씁니다. 이것이 기준선입니다.
STEP 2 · SCAMPER 확장 (50분)아래 프롬프트로 7축 × 3안 = 21안을 뽑습니다.
STEP 3 · 극단 조건 발상 (45분)“예산 0원이라면”, “하루 만에 해야 한다면”, “반대로 한다면” 조건을 걸어 추가 확장합니다.
STEP 4 · 30안 정리 (50분)중복을 합치되 지우지는 않고, 한 줄 설명을 붙여 목록화합니다.
실습 프롬프트
이번 주 산출물해법 아이디어 30안 리스트(축·조건 표기 포함)
체크포인트
  • AI 없이 먼저 8안을 손으로 썼다
  • SCAMPER 7축을 모두 채웠다
  • 총 30안 이상을 확보했다
  • 이번 주에는 아이디어를 평가하지 않았다
PART 2 · 6주차

모순 해결 · TRIZ

“A를 얻으면 B를 잃는” 구조를 깨는 법
학습 목표해결을 막고 있는 트레이드오프를 모순 문장으로 정의하고, 분리 원리로 둘 다 얻는 대안을 만든다.
이론 슬라이드 (10장)
핵심 개념
모순이 곧 문제

“빠르게 하면 부정확해진다”처럼, 문제가 안 풀리는 이유는 대개 하나의 모순 때문입니다.

타협하지 않기

절충안은 둘 다 잃습니다. TRIZ는 절충 대신 모순을 소거하려 합니다.

분리 4원리

시간·공간·조건·전체와 부분으로 분리합니다. “언제는 A, 언제는 B”가 가장 흔한 해법입니다.

이상적 최종 결과

비용도 부작용도 없이 기능만 남는 상태를 먼저 상상하고 거기서 역산합니다.

실습 절차 (170분)
STEP 1 · 모순 찾기 (35분)5주차 30안 중 “좋은데 이것 때문에 안 된다”는 이유를 모아 모순 문장으로 씁니다.
STEP 2 · 이상적 결과 선언 (30분)비용·부작용이 0인 이상 상태를 한 문장으로 적습니다.
STEP 3 · 분리 원리 적용 (60분)아래 프롬프트로 시간·공간·조건·부분 분리 해법을 만듭니다.
STEP 4 · 5안 선별 (45분)모순을 실제로 소거한 안 5개를 골라 근거와 함께 정리합니다.
실습 프롬프트
이번 주 산출물모순 정의서(모순 2문장 + 이상적 결과) + 모순 해소 아이디어 5안
체크포인트
  • 모순을 “A를 높이면 B가 나빠진다” 형식으로 썼다
  • 이상적 최종 결과를 한 문장으로 선언했다
  • 분리 원리 4가지를 모두 시도했다
  • 절충안이 아닌 소거안 5개를 골랐다
PART 2 · 7주차

수렴적 사고와 제약 충족

평가 매트릭스로 30안을 1안으로 줄이기
학습 목표가중치가 설정된 평가 매트릭스로 해법을 비교하고, 극한 제약 하에서 실행 가능한 최종 1안을 근거와 함께 선정한다.
이론 슬라이드 (10장)
핵심 개념
기준을 먼저, 점수는 나중

후보를 보고 기준을 만들면 이미 답을 정해 놓은 것입니다. 기준부터 확정합니다.

가중치

모든 기준이 같은 무게일 수 없습니다. 성공 기준(1주차)에 가까운 항목에 무게를 줍니다.

제약 충족(CSP)

“예산 0원, 인력 1명, 2주” 같은 하드 제약을 못 넘는 안은 점수와 무관하게 탈락입니다.

휴리스틱 탐색

완벽한 최적해 대신 충분히 좋은 해를 빠르게 찾습니다. 학기 프로젝트에는 이쪽이 맞습니다.

실습 절차 (170분)
STEP 1 · 기준·가중치 확정 (30분)효과·실현가능성·비용·시급성 등 4~5개 기준과 가중치를 먼저 정합니다.
STEP 2 · 하드 제약 필터 (25분)제약을 못 넘는 안을 먼저 잘라 냅니다. 30안이 대개 10안 이하로 줄어듭니다.
STEP 3 · 매트릭스 채점 (55분)아래 프롬프트로 채점표를 만들고, 내 판단으로 점수를 수정합니다.
STEP 4 · 1안 확정 + 반론 (60분)1위 안에 대해 “왜 2위가 아닌가”를 3줄로 방어합니다. 방어가 안 되면 다시 고릅니다.
실습 프롬프트
이번 주 산출물아이디어 평가 매트릭스 + 최종 해법 1안 선정 근거서
체크포인트
  • 기준과 가중치를 후보보다 먼저 정했다
  • 하드 제약으로 후보를 먼저 걸렀다
  • AI 점수를 내 판단으로 수정했다
  • “왜 2위가 아닌가”를 방어했다
PART 2 · 8주차 · 중간고사

솔루션 컨셉 발표

문제 분해 → 대안 비교 → 선정 근거 → 해결 로직의 종합 점검
학습 목표1~7주차 산출물을 하나의 솔루션 컨셉 명세서로 통합하고, 동료의 질문에 근거로 답한다.
이론 슬라이드 (10장)
제출물 구성 (A4 5매 내외)
구성내용근거 주차
1. 문제 정의문제 한 문장 + 성공 기준 3층위1주차
2. 원인 구조로직트리 + 공격 지점 선택 근거2주차
3. 작업 분해실행 작업표(10개 이하) + 제약3주차
4. 대안 탐색30안 요약 + 모순 정의서5·6주차
5. 선정평가 매트릭스 + 1안 선정 근거 + 최대 약점7주차
6. 해결 로직 초안해결 절차를 글 또는 도해로 (9주차에 정식 순서도로 발전)
부록사용한 프롬프트 원문 전체4주차 템플릿
발표 (팀·개인 각 7분 + 질의 3분)
1분 · 문제누가 언제 무엇 때문에 어떤 손해를 보는가. 사례 하나로 시작합니다.
2분 · 원인과 공격 지점로직트리에서 왜 이 지점을 골랐는지.
3분 · 대안과 선정버린 안과 버린 이유를 반드시 포함합니다.
1분 · 다음 8주 계획무엇을 만들어 어떻게 검증할 것인가.
중간 점검 프롬프트
제출물솔루션 컨셉 명세서(A4 5매) + 발표자료 + 프롬프트 부록 · 평가 비중 30%
체크포인트
  • 6개 구성 요소가 모두 들어갔다
  • 버린 안과 버린 이유를 명시했다
  • 프롬프트 원문을 부록으로 첨부했다
  • 예상 질문 5개에 답을 준비했다
PART 3 · 9주차

알고리즘 설계 · 순서도로 사고하기

해결 절차를 조건·반복·분기로 기술하기
학습 목표선정한 해법의 실행 절차를 순서도로 그리고, 사람이 할 일과 AI가 할 일의 경계를 명시할 수 있다.
이론 슬라이드 (10장)
핵심 개념
절차로 쓸 수 없으면 못 만든다

말로는 되는데 순서도가 안 그려진다면, 아직 해법이 아니라 소망입니다.

세 가지 기호면 충분

처리(사각) · 판단(마름모) · 시작/끝(둥근). 이 셋으로 거의 모든 절차를 그립니다.

분기가 곧 예외

“아니오” 쪽 화살표가 비어 있는 순서도는 12주차에 반드시 깨집니다.

사람·AI 경계선

각 단계마다 실행 주체를 표시합니다. 판단과 책임이 필요한 단계는 사람으로 둡니다.

실습 절차 (170분)
STEP 1 · 절차 글로 쓰기 (30분)해법이 작동하는 과정을 번호 매긴 문장 10~15개로 씁니다.
STEP 2 · 판단 지점 표시 (30분)“만약 ~라면”이 들어가는 지점을 모두 찾아 표시합니다.
STEP 3 · 순서도 생성 (60분)아래 프롬프트로 Mermaid 코드를 받아 mermaid.live 등에 붙여 도식을 확인·수정합니다.
STEP 4 · 주체 표기 (50분)각 단계에 [사람] / [AI] / [자동] 표기를 넣고, AI가 판단하는 지점의 위험을 적습니다.
실습 프롬프트
이번 주 산출물해결 절차 순서도(Mermaid 도식) + 단계별 주체·실패 대안표
체크포인트
  • 절차를 번호 문장 10개 이상으로 썼다
  • 모든 판단 노드에 “아니오” 경로가 있다
  • 단계마다 실행 주체를 표기했다
  • 자동화하면 안 되는 단계를 지정했다
PART 3 · 10주차

프롬프트 체이닝과 AI 에이전트

한 번에 시키지 말고, 연결해서 시키기
학습 목표큰 작업을 4단계 이상의 프롬프트 체인으로 분할하고, 단계 간 입출력 규격을 정의할 수 있다.
이론 슬라이드 (10장)
핵심 개념
한 프롬프트 한 작업

수집·요약·작성·검토를 한 번에 시키면 전부 평균 이하가 됩니다.

체인의 접합부

앞 단계의 출력 형식이 뒤 단계의 입력 형식입니다. 여기를 규격화해야 체인이 끊기지 않습니다.

검토자 역할 분리

쓴 AI가 스스로 검토하면 관대해집니다. 검토는 다른 역할·다른 세션으로 분리합니다.

에이전트란

목표를 주면 스스로 단계를 나눠 실행하는 구성. 이번 주는 그 구조를 손으로 설계해 봅니다.

실습 절차 (170분)
STEP 1 · 반복 업무 1건 선정 (25분)내 프로젝트에서 매번 반복될 작업 하나를 고릅니다.
STEP 2 · 체인 설계 (50분)아래 프롬프트로 4~6단계 체인을 만들고 각 단계의 입출력 규격을 확정합니다.
STEP 3 · 실행 (60분)실제로 순서대로 돌립니다. 끊기는 지점을 기록합니다.
STEP 4 · 검토 단계 추가 (35분)마지막에 다른 역할의 검토 프롬프트를 붙이고 결과 차이를 비교합니다.
실습 프롬프트
이번 주 산출물4단계 이상 프롬프트 체인 설계서(지시문 전문 포함) + 실행 결과
체크포인트
  • 단계마다 입출력 규격을 정했다
  • 검토 단계를 다른 역할로 분리했다
  • 실제로 끝까지 한 번 돌려 봤다
  • 끊긴 지점과 원인을 기록했다
PART 3 · 11주차

노코드 자동화와 지식 연결 (RAG 기초)

내 자료를 AI에 붙이고, 반복을 기계에 넘기기
학습 목표내 자료를 근거로 답하는 구성(RAG)의 원리와 한계를 이해하고, 반복 작업 1건을 자동 파이프라인으로 설계한다.
이론 슬라이드 (10장)
핵심 개념
RAG의 원리

모델이 외우는 대신, 내가 준 문서에서 찾아 인용합니다. 출처가 붙는 것이 최대 장점입니다.

RAG의 한계

넣은 자료가 틀리면 답도 틀립니다. 문서가 많다고 좋아지지 않고, 정리된 문서라야 합니다.

자동화의 단위

트리거(언제) → 처리(무엇을) → 출력(어디로). 이 셋으로 표현되면 자동화할 수 있습니다.

먼저 손으로 3번

손으로 세 번 해 본 절차만 자동화합니다. 그래야 예외를 압니다.

실습 절차 (170분)
STEP 1 · 지식 자료 정리 (40분)내 프로젝트 관련 자료 5개 이상을 모아 제목·출처·날짜를 정리합니다.
STEP 2 · 나만의 도우미 구성 (50분)자료를 올려 “이 자료만 근거로 답하라”는 조건의 도우미를 만들고 질문 10개로 시험합니다.
STEP 3 · 파이프라인 설계 (50분)아래 프롬프트로 트리거·처리·출력을 정의한 자동화 설계도를 만듭니다.
STEP 4 · 시범 실행 (30분)한 번 실행해 결과와 소요 시간을 기록하고, 손으로 할 때와 비교합니다.
실습 프롬프트
개인정보 주의학습 자료·자동화 대상에 타인의 이름, 연락처, 학번, 건강·성적 정보가 포함되지 않도록 하십시오. 필요하면 가명 처리 후 사용하고, 원자료는 개인 저장소에만 둡니다.
이번 주 산출물자동화 파이프라인 설계도 + 시범 실행 결과(전후 소요 시간 비교)
체크포인트
  • 자료 5개 이상으로 도우미를 구성했다
  • 질문 10개로 근거 인용 품질을 시험했다
  • 트리거·처리·출력이 정의된 설계도를 만들었다
  • 개인정보 포함 여부를 점검했다
PART 3 · 12주차

예외 처리와 레드티밍

내 해법을 가장 세게 공격해 보는 시간
학습 목표해법이 깨지는 지점을 스스로 찾아 예외 시나리오로 정리하고, 반박에 대한 대응 논리를 세운다.
이론 슬라이드 (10장)
핵심 개념
정상 경로의 착시

순서도의 “예” 경로만 보면 모든 해법은 완벽합니다. 문제는 언제나 “아니오”에서 터집니다.

세 종류의 예외

실수(오입력) · 악용(일부러) · 엣지케이스(드문 조건). 각각 대비가 다릅니다.

레드팀

내 해법을 무너뜨리는 것이 목적인 역할. AI에게 이 역할을 주면 가장 값이 큽니다.

윤리·책임

누가 피해를 볼 수 있는가, 그 피해를 누가 책임지는가. 답이 없으면 설계를 고칩니다.

실습 절차 (170분)
STEP 1 · 아니오 경로 채우기 (35분)9주차 순서도의 모든 “아니오”에 무슨 일이 일어나는지 적습니다.
STEP 2 · 레드팀 공격 (55분)아래 프롬프트로 내 해법을 공격받고, 아픈 지적 5개를 그대로 기록합니다.
STEP 3 · 대응 논리 수립 (45분)지적마다 ① 인정하고 고칠 것 ② 근거로 반박할 것 ③ 범위 밖으로 선언할 것을 구분합니다.
STEP 4 · 윤리 점검 (35분)피해 가능 집단, 개인정보, 오작동 시 책임 소재를 표로 정리합니다.
실습 프롬프트
이번 주 산출물예외 시나리오 표 + 레드팀 반박 대응서 + 윤리 점검표
체크포인트
  • 순서도의 모든 “아니오” 경로를 채웠다
  • 아픈 지적 5개를 그대로 기록했다
  • 고칠 것과 범위 밖을 구분했다
  • 피해 가능 집단과 책임 주체를 적었다
PART 4 · 13주차

프로토타입 제작

설명하지 말고 보여 주기 — 작동하는 최소 시제품
학습 목표최소 기능 범위를 정하고, 노코드·AI 도구로 실제로 만져 볼 수 있는 프로토타입 v1을 만든다.
이론 슬라이드 (10장)
핵심 개념
MVP의 M은 최소

성공 기준 하나를 확인할 수 있는 만큼만 만듭니다. 나머지는 다 나중입니다.

가짜여도 된다

뒤에서 사람이 처리하더라도 사용자가 겪는 경험이 진짜라면 검증에는 충분합니다.

화면 흐름 먼저

첫 화면 → 핵심 행동 → 결과 확인. 세 장면이면 대부분의 흐름이 표현됩니다.

완성도의 함정

예쁘게 만들수록 사람들은 본질 대신 색깔을 지적합니다. 거칠게 유지하십시오.

실습 절차 (170분)
STEP 1 · 범위 자르기 (30분)기능 목록을 쓰고, 성공 기준 확인에 필요 없는 것을 전부 지웁니다.
STEP 2 · 화면·흐름 설계 (40분)세 장면으로 사용 흐름을 그립니다. 종이도 좋습니다.
STEP 3 · 제작 (70분)아래 프롬프트로 제작 명세를 만들고 노코드·AI 도구로 v1을 만듭니다.
STEP 4 · 자가 시연 (30분)처음 보는 사람인 척 끝까지 써 봅니다. 막히는 지점을 전부 적습니다.
실습 프롬프트
이번 주 산출물작동하는 프로토타입 v1(링크 또는 캡처) + 사용 시나리오 대본
체크포인트
  • 기능을 3개 이하로 잘랐다
  • 사용 흐름을 세 장면으로 그렸다
  • 끝까지 작동하는 v1을 만들었다
  • 막히는 지점을 목록으로 적었다
PART 4 · 14주차

해결책 검증 · CER과 사용자 테스트

“좋아 보인다”가 아니라 근거로 말하기
학습 목표5인 이상 실사용 테스트로 데이터를 모으고, 주장–근거–추론(CER) 구조의 검증 리포트를 작성해 v2로 수정한다.
이론 슬라이드 (10장)
핵심 개념
CER 구조

주장(Claim) · 근거(Evidence) · 추론(Reasoning). 근거 없는 주장은 감상문입니다.

말 대신 행동을 보라

“좋아요”는 데이터가 아닙니다. 끝까지 했는가, 몇 초 걸렸는가가 데이터입니다.

5명의 법칙

5명만 시켜 봐도 치명적 문제의 대부분이 드러납니다. 숫자보다 관찰이 중요합니다.

실패는 결과다

가설이 틀렸다는 결론도 완전한 결과입니다. 억지로 성공으로 포장하지 마십시오.

실습 절차 (170분)
STEP 1 · 가설과 지표 확정 (30분)“이 해법을 쓰면 [무엇]이 [얼마나] 달라진다”를 반증 가능한 문장으로 씁니다.
STEP 2 · 사용자 테스트 (60분)5명에게 시연 없이 써 보게 하고, 말이 아니라 행동을 기록합니다.
STEP 3 · 데이터 정리·분석 (45분)아래 프롬프트로 정량·정성 데이터를 CER 구조로 정리합니다.
STEP 4 · v2 수정 (35분)가장 많이 걸린 지점 1~2개만 고칩니다. 전부 고치려 하지 않습니다.
실습 프롬프트
이번 주 산출물검증 리포트(CER 구조, 데이터 시각화 포함) + 프로토타입 v2
체크포인트
  • 가설을 반증 가능한 문장으로 썼다
  • 5명 이상에게 힌트 없이 시켜 봤다
  • 주장마다 데이터 근거를 붙였다
  • 고칠 것을 1~2개로 제한했다
PART 4 · 15주차 · 기말

최종 캡스톤 · Solution Pitch

문제 – 해법 – 로직 – 검증을 8분에 증명하기
학습 목표한 학기의 문제해결 과정을 하나의 논리로 묶어 발표하고, 동료 검토를 통해 자기 해법의 한계를 명확히 진술한다.
이론 슬라이드 (10장)
최종 제출물
제출물구성분량
해결 로직 명세서문제 정의 · 원인 구조 · 대안과 선정 · 순서도 · 예외 처리 · 자동화 설계A4 8~10매
프로토타입작동하는 v2 (링크·캡처·시연 영상 중 택1) + 사용 시나리오
검증 리포트가설 · 지표 · 결과 · CER 3세트 · 한계A4 3매
동료 검토서동료 2인 검토 의견 + 내가 반영한 것 / 반영하지 않은 것과 이유A4 2매
부록사용한 프롬프트 전문, 실패한 시도 기록제한 없음
발표 구성 (8분 + 질의 4분)
1분 · 문제구체적 장면 하나로 시작합니다. 통계는 그다음입니다.
2분 · 해법과 선정 근거버린 안을 먼저 보여 주면 고른 안이 설득됩니다.
2분 · 작동 시연말로 설명하지 말고 실제로 돌립니다. 실패해도 그대로 보여 줍니다.
2분 · 검증 결과가설 지지 여부를 먼저 말하고, 근거 데이터를 붙입니다.
1분 · 한계와 다음이 해법이 통하지 않는 조건을 스스로 밝힙니다. 이 항목이 평가에서 가장 큽니다.
마무리 프롬프트
제출물해결 로직 명세서 + 프로토타입 + 검증 리포트 + 동료 검토서 · 평가 비중 40%
체크포인트
  • 네 가지 제출물을 모두 완성했다
  • 발표에서 실제로 시연했다
  • 가설 지지 여부를 명확히 말했다
  • 해법이 통하지 않는 조건을 스스로 밝혔다
  • 실패한 시도를 부록에 남겼다

프로젝트 제너레이터

내 프로젝트 정보를 넣으면 그대로 복사해 쓸 수 있는 지시문이 만들어집니다. 빈칸을 채우고 「프롬프트 생성」을 누른 뒤, 생성된 상자의 「복사」로 AI에 붙여넣으십시오. 생성되는 지시문은 영어입니다 — AI 응답 품질을 일정하게 유지하기 위해 프롬프트는 전 언어 공통으로 영어를 사용합니다.

문제 분해 제너레이터

1~3주차용. 문제를 원인 구조와 실행 작업으로 쪼개는 지시문을 만듭니다.
생성된 지시문 (English)

해법 발산·선정 제너레이터

5~7주차용. 아이디어를 양적으로 확장하고 가중 매트릭스로 1안을 고르는 지시문을 만듭니다.
생성된 지시문 (English)

검증 설계 제너레이터

13~14주차용. 프로토타입을 사람에게 시험해 근거를 만드는 지시문을 만듭니다.
생성된 지시문 (English)
SOOKMYUNG · PBL Ⅰ · AI PROBLEM SOLVING

PBLⅠ Learning Portal · 15 Weeks

Turn a defined problem into a working solution. Every week you build one deliverable, copy the practice prompts as they are, and use the generators to write instructions of your own.

Fall Semester 2026  |  Mon 16:00–18:50 (Myeongsin Hall 517)  |  Instructor: Jinhyuk Jung
Course arc  Break down the problemDivergeConverge and selectDesign the logicAutomatePrototypeValidatePresent
Progress0 / 15 weeks completed
PART 1 · Anatomy of a problem
PART 2 · Diverge and converge
PART 3 · Logic and automation
PART 4 · Prototype and validation
PART 1 · Week 1 · Orientation

What Problem Solving Is

AI is not a magic wand — learning to spot a problem you can actually solve
Learning objectivePick the one problem you will actually solve this semester, and judge whether it is in a “solvable” shape.
Theory slides (10)
Key concepts
What makes a problem solvable

Its scope is closed, there is a standard for judging success, and you can see a result within one semester.

What AI cannot do

Decide what to solve, judge what matters, take responsibility. Those three stay with you to the end.

Three steps of computational thinking

Decomposition (split it) · pattern recognition (find what repeats) · abstraction (keep only the core). This is the skeleton of the whole course.

Finding a problem → solving one

PBLⅡ asked “what is the problem?” PBLⅠ asks “so what are you going to do about it?”

Studio procedure (170 min)
STEP 1 · Write three candidates (25 min)Write three frustrations you personally ran into in the last three months. Your problems, not someone else's.
STEP 2 · Judge solvability (40 min)Score all three on scope, success criteria and timeframe with the prompt below, and drop the ones in an unsolvable shape.
STEP 3 · Commit to one (45 min)Define the problem in one sentence: “who / when / because of what / loses what.”
STEP 4 · Declare success criteria (60 min)Write what must be different at the end of the semester for you to say you solved it — as a number or an observable state.
Practice prompts
Deliverable this weekOne A4 page defining the problem (one-sentence problem + three levels of success criteria) + weekly reflection report
Checkpoints
  • Wrote three candidates and filtered them by score
  • Wrote the problem as one sentence: who / when / because of what / loses what
  • Wrote three levels of success criteria in observable form
  • Checked that AI did not make any decision in my place
PART 1 · Week 2

Separating Symptom from Cause

Hitting the root instead of the symptom, with 5 Whys and a logic tree
Learning objectiveSeparate the visible symptom from what produces it, and draw the cause structure as a logic tree at least three levels deep.
Theory slides (10)
Key concepts
The symptom-treatment trap

“Let's send more notifications” is usually a prescription for a symptom. If you never ask why people miss them, the problem comes back.

5 Whys

Ask why five times. The point where answers start to stall, usually the third, is where the real cause sits.

Logic tree

Spread the causes out as branches. Branches at the same level must not overlap (MECE).

Choosing where to strike

You cannot hit every cause. Pick the one with large impact that you can actually touch.

Studio procedure (170 min)
STEP 1 · List symptoms (25 min)Write six or more symptoms you observe in your Week 1 problem, as plain facts. Leave out interpretation and guesswork.
STEP 2 · 5 Whys (35 min)Pick the symptom that occurs most often and dig five levels down. If you end at "people are lazy," you failed.
STEP 3 · Build the logic tree (60 min)Use the prompt below to spread the cause structure at least three levels, then clean up overlapping branches by hand.
STEP 4 · Mark the strike point (50 min)Place the causes on two axes, impact × controllability, and mark the 1–2 you will hit this semester.
Practice prompts
Deliverable this weekCause logic tree (3+ levels) + a copy with the 1–2 strike points marked
Checkpoints
  • Wrote symptoms and causes separately
  • Expanded the logic tree at least three levels
  • Cleaned up overlapping branches at the same level
  • Chose the strike point for this semester
PART 1 · Week 3

Decomposition

Cutting an unsolvable-looking lump into one- to two-hour tasks
Learning objectiveBreak a large problem into ten or fewer executable tasks, and state the prerequisite and output of each.
Theory slides (10)
Key concepts
The right size for a task

Something you can finish in one sitting (1–2 hours). Bigger and you postpone it; smaller and the overhead of tracking it costs more than the work.

Match the level of abstraction

When “do research” and “make the survey link” sit in the same list, progress stops.

Prerequisites

What has to finish before this can start. That is your schedule.

State the constraints

Write budget, time, people and permissions as numbers. The clearer the constraint, the more concrete the solution.

Studio procedure (170 min)
STEP 1 · Fix the constraints (25 min)Write your available hours, spendable money, number of people who will help and reachable data as numbers.
STEP 2 · First decomposition (45 min)Break the problem into a task list with the prompt below. What matters is what you delete from the result.
STEP 3 · Fix the sizes (50 min)Cut anything over two hours again, merge anything under fifteen minutes. Land on ten or fewer.
STEP 4 · Fix the order (50 min)Chain the prerequisites into an order and mark the first three. This table is your reference for the remaining 12 weeks.
Practice prompts
Deliverable this weekTask table (10 or fewer: task / output / time / prerequisite) + the top 3 marked
Checkpoints
  • Wrote the constraints as numbers
  • Every task is sized at 1–2 hours
  • There are ten tasks or fewer
  • Chose the three things to do first
PART 1 · Week 4

Talking to AI Effectively · RTCF

Structuring instructions with four elements: role, task, context, format
Learning objectiveSee how the same question changes once all four elements are present, and build three reusable templates for your own problem.
Theory slides (10)
Key concepts — the four RTCF elements
R · Role

Specify who is answering. This is what sets the level of expertise.

T · Task

A precise verb. One prompt carries one task.

C · Context

Background, constraints, what you already know. This drives the quality of the answer more than anything else.

F · Format

Table, bullets, line count, tone. This is what removes the rework.

Studio procedure (170 min)
STEP 1 · Just ask (20 min)Throw one question about your problem the way you normally would, and save the result.
STEP 2 · Fill the four elements (40 min)Rewrite the same question into the template. Getting three or more lines into context is the whole trick.
STEP 3 · Compare and diagnose (40 min)Put the two results side by side, write three things that changed, and run [4-2] on your prompt.
STEP 4 · Build three templates (70 min)Make one each for research, analysis and writing. Keep variables to five or fewer.
Practice prompts
Three rules against hallucination① Tell it to say so when it does not know ② demand sources for figures and quotations ③ make it separate fact from inference. Keep these three lines pinned at the bottom of every template.
Deliverable this weekThree reusable RTCF templates (research · analysis · writing) + a before/after comparison table
Checkpoints
  • Compared two answers to the same question and wrote three differences
  • Filled context (C) with three or more lines
  • Finished three templates with five variables or fewer
  • Ran each template once more with different inputs
PART 2 · Week 5

Divergent Thinking · SCAMPER × AI

Win on quantity first — generate 30 solution ideas
Learning objectiveExpand solutions across the seven SCAMPER axes, and train yourself to gather ideas with judgment suspended.
Theory slides (10)
Key concepts
Keep divergence and convergence apart

Evaluating while you gather ruins both. No evaluation this week.

The seven SCAMPER axes

Substitute · combine · adapt · modify · put to other use · eliminate · reverse. They push a stuck mind sideways by force.

AI is an amplifier

You bring 3, AI turns it into 30. But 30 ordinary ideas come easily, so you have to name the axis.

What a strange idea is worth

An idea you cannot use becomes the raw material for the next one. Do not delete it — keep it.

Studio procedure (170 min)
STEP 1 · Bare-handed ideation (25 min)Ten minutes alone without AI, ten with your team. Write at least 8 ideas by hand. This is your baseline.
STEP 2 · SCAMPER expansion (50 min)Use the prompt below to pull 7 axes × 3 ideas = 21 ideas.
STEP 3 · Extreme-condition ideation (45 min)Add conditions — “with zero budget,” “if it had to be done in a day,” “if you did the opposite” — and expand further.
STEP 4 · Assemble the 30 (50 min)Merge duplicates without deleting anything, and list each with a one-line description.
Practice prompts
Deliverable this weekA list of 30 solution ideas (labelled by axis and condition)
Checkpoints
  • Wrote 8 ideas by hand before touching AI
  • Filled all seven SCAMPER axes
  • Collected 30 or more ideas in total
  • Did not evaluate any idea this week
PART 2 · Week 6

Resolving Contradictions · TRIZ

How to break the “gain A, lose B” structure
Learning objectiveState the trade-off blocking your solution as a contradiction, and use the separation principles to get both sides.
Theory slides (10)
Key concepts
The contradiction is the problem

“Do it fast and it gets inaccurate” — the reason a problem will not budge is usually a single contradiction.

Do not compromise

A middle-ground answer loses both sides. TRIZ tries to eliminate the contradiction instead of splitting it.

Four separation principles

Separate by time, space, condition, or whole and part. “A at these times, B at those” is the most common answer.

Ideal final result

Imagine the state where the function remains with no cost and no side effect, then work backwards from there.

Studio procedure (170 min)
STEP 1 · Find the contradiction (35 min)Collect the “it's good, but this is what stops it” reasons from your 30 Week 5 ideas and write them as contradictions.
STEP 2 · Declare the ideal result (30 min)Write the ideal state, with zero cost and zero side effects, in one sentence.
STEP 3 · Apply the separation principles (60 min)Use the prompt below to build solutions separated by time, space, condition and part.
STEP 4 · Select 5 (45 min)Pick the 5 ideas that actually eliminate the contradiction and write down why.
Practice prompts
Deliverable this weekContradiction statement (2 sentences + ideal result) + 5 ideas that resolve it
Checkpoints
  • Wrote the contradiction as “raise A and B gets worse”
  • Declared the ideal final result in one sentence
  • Tried all four separation principles
  • Picked 5 ideas that eliminate rather than compromise
PART 2 · Week 7

Convergent Thinking and Constraint Satisfaction

Cutting 30 ideas down to 1 with an evaluation matrix
Learning objectiveCompare solutions with a weighted evaluation matrix, and select one final idea, with reasons, that is executable under hard constraints.
Theory slides (10)
Key concepts
Criteria first, scores later

If you build the criteria after looking at the candidates, you have already picked the winner. Fix the criteria first.

Weights

Not every criterion can carry the same weight. Put weight on whatever sits closest to your Week 1 success criteria.

Constraint satisfaction (CSP)

An idea that fails a hard constraint like “zero budget, one person, two weeks” is out regardless of its score.

Heuristic search

Find a good-enough answer quickly instead of a perfect optimum. For a semester project, that is the right trade.

Studio procedure (170 min)
STEP 1 · Fix criteria and weights (30 min)Settle on 4–5 criteria — impact, feasibility, cost, urgency and the like — and their weights first.
STEP 2 · Hard-constraint filter (25 min)Cut the ideas that fail a constraint before anything else. Thirty usually drops to ten or fewer.
STEP 3 · Score the matrix (55 min)Build the scoring table with the prompt below, then correct the scores with your own judgment.
STEP 4 · Commit to one + rebuttal (60 min)Defend “why not the runner-up” in three lines. If you cannot defend it, pick again.
Practice prompts
Deliverable this weekIdea evaluation matrix + a written rationale for the final solution
Checkpoints
  • Set criteria and weights before looking at candidates
  • Filtered candidates by hard constraints first
  • Corrected the AI's scores with my own judgment
  • Defended “why not the runner-up”
PART 2 · Week 8 · Midterm

Solution Concept Presentation

A full check of decomposition → comparison → rationale → solution logic
Learning objectiveConsolidate the Week 1–7 deliverables into a single solution concept specification, and answer your peers' questions with evidence.
Theory slides (10)
What to submit (about 5 A4 pages)
SectionContentsFrom week
1. Problem definitionOne-sentence problem + three levels of success criteriaWeek 1
2. Cause structureLogic tree + rationale for the chosen strike pointWeek 2
3. Task decompositionTask table (10 or fewer) + constraintsWeek 3
4. AlternativesSummary of the 30 ideas + contradiction statementWeeks 5·6
5. SelectionEvaluation matrix + rationale for the chosen idea + its biggest weaknessWeek 7
6. Draft solution logicThe procedure in prose or a diagram (becomes a proper flowchart in Week 9)
AppendixFull text of every prompt usedWeek 4 templates
Presentation (7 min each, team and individual, + 3 min Q&A)
1 min · ProblemWho, when, because of what, loses what. Open with a single case.
2 min · Causes and strike pointWhy you picked this point on the logic tree.
3 min · Alternatives and selectionAlways include what you dropped and why.
1 min · Plan for the next 8 weeksWhat you will build and how you will validate it.
Midterm check prompt
SubmissionSolution concept specification (5 A4 pages) + slides + prompt appendix · weight 30%
Checkpoints
  • All six sections are present
  • Stated what I dropped and why
  • Attached the full prompts as an appendix
  • Prepared answers to the 5 likely questions
PART 3 · Week 9

Algorithm Design · Thinking in Flowcharts

Describing the procedure in conditions, loops and branches
Learning objectiveDraw the execution procedure of your chosen solution as a flowchart, and mark the line between what people do and what AI does.
Theory slides (10)
Key concepts
If you cannot write the procedure, you cannot build it

If you can say it but can't draw it, it's still a wish, not a solution.

Three symbols are enough

Process (rectangle) · decision (diamond) · start/end (rounded). These three draw almost any procedure.

Every branch is an exception

A flowchart with an empty “no” arrow will break in Week 12, without fail.

The human–AI line

Mark who executes each step. Leave the steps that need judgment and accountability with a person.

Studio procedure (170 min)
STEP 1 · Write the procedure in prose (30 min)Write how the solution works as 10–15 numbered sentences.
STEP 2 · Mark the decision points (30 min)Find and mark every place where an “if” appears.
STEP 3 · Generate the flowchart (60 min)Get Mermaid code with the prompt below, paste it into mermaid.live or similar, then check and fix the diagram.
STEP 4 · Label the actors (50 min)Tag each step [human] / [AI] / [automatic] and write the risk wherever AI does the judging.
Practice prompts
Deliverable this weekSolution flowchart (Mermaid diagram) + a table of actors and failure fallbacks per step
Checkpoints
  • Wrote the procedure as 10 or more numbered sentences
  • Every decision node has a “no” path
  • Labelled the actor for each step
  • Named the steps that must not be automated
PART 3 · Week 10

Prompt Chaining and AI Agents

Don't ask for it all at once — chain it
Learning objectiveSplit a large task into a chain of four or more prompts, and define the input and output spec between stages.
Theory slides (10)
Key concepts
One prompt, one task

Ask for gathering, summarizing, writing and reviewing at once and all four come back below average.

The joints of the chain

The output format of one stage is the input format of the next. Standardize the joint or the chain snaps.

Separate the reviewer

An AI reviewing its own writing goes easy on itself. Put review in a different role and a different session.

What an agent is

A setup that takes a goal and splits it into steps on its own. This week you design that structure by hand.

Studio procedure (170 min)
STEP 1 · Pick one repetitive task (25 min)Choose a task in your project that will come up again and again.
STEP 2 · Design the chain (50 min)Build a 4–6 stage chain with the prompt below and fix the input/output spec of each stage.
STEP 3 · Run it (60 min)Actually run it in order. Record where it breaks.
STEP 4 · Add a review stage (35 min)Attach a review prompt in a different role at the end and compare the difference in output.
Practice prompts
Deliverable this weekA prompt chain design of 4+ stages (with full instruction texts) + the results of running it
Checkpoints
  • Set an input/output spec for each stage
  • Put the review stage in a different role
  • Actually ran it end to end once
  • Recorded where it broke and why
PART 3 · Week 11

No-Code Automation and Connecting Knowledge (RAG Basics)

Attaching your own material to AI, and handing repetition to a machine
Learning objectiveUnderstand how a setup that answers from your own material (RAG) works and where it fails, and design one repetitive task as an automated pipeline.
Theory slides (10)
Key concepts
How RAG works

Instead of recalling from memory, the model looks things up in the documents you gave it and cites them. The citation is the biggest gain.

Where RAG fails

Feed it wrong material and the answer is wrong. More documents does not mean better; they have to be organized.

The unit of automation

Trigger (when) → process (what) → output (where to). If you can express it in those three, you can automate it.

Do it by hand three times first

Only automate a procedure you have run by hand three times. That is how you learn its exceptions.

Studio procedure (170 min)
STEP 1 · Organize your source material (40 min)Collect five or more documents related to your project and record title, source and date.
STEP 2 · Build your own assistant (50 min)Upload the material, set the condition “answer only from this material,” and test it with 10 questions.
STEP 3 · Design the pipeline (50 min)Use the prompt below to draw an automation design with trigger, process and output defined.
STEP 4 · Trial run (30 min)Run it once, record the result and the time it took, and compare against doing it by hand.
Practice prompts
Personal data warningKeep other people's names, contact details, student IDs, and health or grade information out of your training material and anything you automate. Pseudonymize where you must, and keep the raw material in your own storage only.
Deliverable this weekAutomation pipeline design + trial run results (time before vs. after)
Checkpoints
  • Built the assistant on five or more documents
  • Tested citation quality with 10 questions
  • Produced a design with trigger, process and output defined
  • Checked whether any personal data was included
PART 3 · Week 12

Exception Handling and Red Teaming

The week you attack your own solution as hard as you can
Learning objectiveFind where your solution breaks, write those points up as exception scenarios, and build a response to each objection.
Theory slides (10)
Key concepts
The illusion of the happy path

Look only at the “yes” path of a flowchart and every solution is perfect. Things always blow up on the “no.”

Three kinds of exception

Mistakes (bad input) · abuse (on purpose) · edge cases (rare conditions). Each needs a different defense.

Red team

A role whose purpose is to bring your solution down. Giving AI this role pays off more than anything else.

Ethics and accountability

Who could be harmed, and who answers for that harm. No answer means you fix the design.

Studio procedure (170 min)
STEP 1 · Fill in the “no” paths (35 min)Write what happens at every “no” in your Week 9 flowchart.
STEP 2 · Red team attack (55 min)Let the prompt below attack your solution, and record the 5 criticisms that sting, word for word.
STEP 3 · Build your response (45 min)For each criticism, decide whether to ① accept and fix ② rebut with evidence ③ declare it out of scope.
STEP 4 · Ethics check (35 min)Tabulate who could be harmed, what personal data is involved, and who is accountable when it misfires.
Practice prompts
Deliverable this weekException scenario table + red team response document + ethics check table
Checkpoints
  • Filled every “no” path in the flowchart
  • Recorded the 5 criticisms that stung, verbatim
  • Separated what to fix from what is out of scope
  • Wrote down who could be harmed and who is accountable
PART 4 · Week 13

Building the Prototype

Show it, don't explain it — the smallest thing that works
Learning objectiveSet the minimum feature scope and build a prototype v1 that people can actually touch, using no-code and AI tools.
Theory slides (10)
Key concepts
The M in MVP is minimum

Build only as much as it takes to test one success criterion. Everything else comes later.

Fake is fine

Even if a person handles it behind the scenes, if the user's experience is real it is enough for validation.

Screen flow first

First screen → core action → seeing the result. Three scenes express most flows.

The polish trap

The prettier it looks, the more people comment on the colors instead of the substance. Keep it rough.

Studio procedure (170 min)
STEP 1 · Cut the scope (30 min)Write the feature list and delete everything not needed to test the success criterion.
STEP 2 · Design screens and flow (40 min)Draw the usage flow in three scenes. Paper is fine.
STEP 3 · Build (70 min)Write the build spec with the prompt below and make v1 with no-code and AI tools.
STEP 4 · Self demo (30 min)Use it end to end as if you had never seen it. Write down every place you get stuck.
Practice prompts
Deliverable this weekA working prototype v1 (link or screenshots) + a usage scenario script
Checkpoints
  • Cut the features to three or fewer
  • Drew the usage flow in three scenes
  • Built a v1 that works end to end
  • Listed every place I got stuck
PART 4 · Week 14

Validating the Solution · CER and User Testing

Speaking from evidence, not from “it looks good”
Learning objectiveGather data from real use with five or more people, write a validation report in claim–evidence–reasoning (CER) form, and revise into v2.
Theory slides (10)
Key concepts
The CER structure

Claim · Evidence · Reasoning. A claim with no evidence is a personal impression.

Watch behavior, not words

“I like it” is not data. Did they finish, and how many seconds did it take — that is data.

The rule of five

Five users surface most of the fatal problems. Observation matters more than sample size.

Failure is a result

Concluding the hypothesis was wrong is a complete result. Do not dress it up as a success.

Studio procedure (170 min)
STEP 1 · Fix the hypothesis and metrics (30 min)Write “using this solution changes [what] by [how much]” as a falsifiable sentence.
STEP 2 · User testing (60 min)Have 5 people use it with no demo, and record behavior rather than words.
STEP 3 · Organize and analyze the data (45 min)Use the prompt below to put the quantitative and qualitative data into CER form.
STEP 4 · Revise into v2 (35 min)Fix only the 1–2 places where people got stuck most. Do not try to fix everything.
Practice prompts
Deliverable this weekValidation report (CER structure, with data visualized) + prototype v2
Checkpoints
  • Wrote the hypothesis as a falsifiable sentence
  • Had five or more people try it with no hints
  • Attached data as evidence to every claim
  • Limited the fixes to one or two
PART 4 · Week 15 · Final

Final Capstone · Solution Pitch

Proving problem – solution – logic – validation in 8 minutes
Learning objectivePresent a semester of problem solving as one line of reasoning, and state the limits of your own solution clearly through peer review.
Theory slides (10)
Final submissions
SubmissionContentsLength
Solution logic specificationProblem definition · cause structure · alternatives and selection · flowchart · exception handling · automation design8–10 A4 pages
PrototypeA working v2 (link, screenshots or demo video — pick one) + usage scenario
Validation reportHypothesis · metrics · results · 3 CER sets · limits3 A4 pages
Peer review documentComments from 2 peers + what I acted on / what I did not and why2 A4 pages
AppendixFull text of every prompt used, and a record of the attempts that failedNo limit
Presentation format (8 min + 4 min Q&A)
1 min · ProblemOpen with one concrete scene. Statistics come after.
2 min · Solution and rationaleShow what you dropped first and the choice you made becomes convincing.
2 min · Live demoDon't describe it, run it. If it fails, show that too.
2 min · Validation resultsSay whether the hypothesis held first, then attach the data.
1 min · Limits and next stepsState the conditions under which your solution does not work. This carries the most weight in the grade.
Closing prompts
SubmissionSolution logic specification + prototype + validation report + peer review document · weight 40%
Checkpoints
  • Completed all four submissions
  • Actually demoed it live in the talk
  • Stated clearly whether the hypothesis held
  • Stated on my own the conditions under which the solution fails
  • Left the failed attempts in the appendix

Project generators

Enter your project details and the generator writes an instruction you can copy straight into an AI tool. Fill in the fields, press “Generate prompt”, then use “Copy” on the box that appears. The generated instruction is in English — prompts are kept in English across all languages so answer quality stays consistent.

Problem decomposition generator

For weeks 1–3. Writes an instruction that breaks your problem into a cause structure and executable tasks.
Generated instruction (English)

Idea generation & selection generator

For weeks 5–7. Expands ideas in volume, then picks one with a weighted matrix.
Generated instruction (English)

Validation design generator

For weeks 13–14. Writes an instruction for testing your prototype on real people and building evidence.
Generated instruction (English)
SOOKMYUNG · PBL Ⅰ · AI PROBLEM SOLVING

PBLⅠ 学习门户 · 15周

把已经定义好的问题变成能运转的解决方案。每周做出一件产出, 直接复制实操提示词来用,再用生成器写出属于自己的指令。

2026学年 第二学期  |  周一 16:00–18:50 (明新馆517)  |  授课教师:郑镇赫
学习路径  问题拆解方案发散收敛·选定逻辑设计自动化原型验证汇报
学习进度已完成 0 / 15 周
PART 1 · 问题的解剖
PART 2 · 发散与收敛
PART 3 · 逻辑与自动化
PART 4 · 原型与验证
PART 1 · 第1周 · 导论

什么是问题解决

AI 不是魔法棒 —— 练出挑选可解问题的眼力
学习目标选定本学期自己真正要解决的1个问题,并能判断这个问题是不是“可解的形态”。
理论幻灯片(10页)
核心概念
可解问题的条件

范围是封闭的,有判定成功的标准,而且一个学期之内能看到结果。

AI 做不到的事

决定解决什么、判断价值、承担责任。这三件事自始至终都是人的份内事。

计算思维三步

拆解(切开)· 模式识别(找重复)· 抽象(只留核心)。这是整门课的骨架。

发现问题 → 解决问题

如果说 PBLⅡ 问的是“什么是问题”,PBLⅠ 问的就是“那么该怎么做”。

实操流程 (170分钟)
STEP 1 · 写下3个候选 (25分钟)写出最近三个月里自己亲身遇到的3件麻烦事。必须是自己的问题,不是别人的。
STEP 2 · 判定可解性 (40分钟)用下面的提示词从范围、判定标准、周期三个角度给3件事打分,筛掉不可解的形态。
STEP 3 · 确定1件 (45分钟)用一句话定义问题。格式是“谁 / 在什么时候 / 因为什么 / 蒙受什么损失”。
STEP 4 · 声明成功标准 (60分钟)写清学期末要出现什么变化才算“解决了”,用数值或可观察的状态来表述。
实操提示词
本周产出问题选定书A4 1页(问题一句话 + 成功标准三层级)+ 周反思报告
检查点
  • 写出3个候选并用打分筛选过了
  • 把问题写成了“谁/何时/因为什么/什么损失”一句话
  • 把成功标准写成了可观察的三个层级
  • 确认过没有让 AI 替我做决定的部分
PART 1 · 第2周

区分现象与原因

用 5 Whys 和逻辑树打根子,而不是打症状
学习目标把看得见的症状和制造症状的原因分开,并能画出展开三层以上的原因逻辑树。
理论幻灯片(10页)
核心概念
治标的陷阱

“多发几次通知”基本上是治标处方。不问为什么会漏掉,同样的问题还会回来。

5 Whys

连问五次为什么。通常从第三次开始答不上来的地方,就是真正的原因。

逻辑树

把原因展开成枝条。同一层级的枝条之间不能互相重叠(MECE)。

选择攻击点

不可能把所有原因都打一遍。挑影响大而且自己动得了的那一个。

实操流程 (170分钟)
STEP 1 · 罗列症状 (25分钟)从第1周的问题里,只按事实写出观察到的症状6条以上。去掉解释和猜测。
STEP 2 · 5 Whys (35分钟)挑症状中最常发生的一条往下追五次。追到“人懒”就结束的话,这一步就是失败的。
STEP 3 · 展开逻辑树 (60分钟)用下面的提示词把原因结构铺开三层以上,再用手把重叠的枝条整理掉。
STEP 4 · 标出攻击点 (50分钟)把原因摆到影响度 × 可控性两轴上,标出本学期要打的1~2个点。
实操提示词
本周产出问题原因逻辑树(三层以上)+ 标出1~2个攻击点的版本
检查点
  • 把症状和原因分开写了
  • 逻辑树展开到三层以上了
  • 整理掉了同一层级里重叠的枝条
  • 选定了本学期要打的攻击点
PART 1 · 第3周

问题拆解 (Decomposition)

把看似解不开的大块切成1~2小时的任务
学习目标把大问题切成10个以内可执行的任务,并写明每个任务的前置条件和产出。
理论幻灯片(10页)
核心概念
任务的合适大小

坐下来一次能做完的大小(1~2小时)。再大就会拖,再小则管理成本太高。

对齐抽象层级

“做调研”和“做一个问卷链接”混在同一份清单里,进度就会停住。

前置条件

什么做完了才能开始这一项。这本身就是日程表。

把约束写明

把预算、时间、人力、权限写成数字。约束越清楚,方案越具体。

实操流程 (170分钟)
STEP 1 · 确定约束 (25分钟)把可用时间、能花的钱、能帮忙的人数、能拿到的数据都写成数字。
STEP 2 · 第一轮拆解 (45分钟)用下面的提示词把问题拆成任务清单。关键在于从结果里删东西
STEP 3 · 调整大小 (50分钟)超过2小时的任务再切开,15分钟的合并起来。最终压到10个以内。
STEP 4 · 确定顺序 (50分钟)按前置条件连出顺序,标出最先做的3个。这张表就是剩下12周的基准。
实操提示词
本周产出执行任务表(10个以内,任务/产出/时间/前置条件)+ 标出优先3项
检查点
  • 把约束写成数字了
  • 所有任务都对齐到1~2小时的大小了
  • 任务数量在10个以内
  • 选出了最先要做的3件事
PART 1 · 第4周

与 AI 高效沟通 · RTCF

用角色·任务·背景·格式4要素给指令搭结构
学习目标亲眼看到同一个问题在补齐4要素后结果如何变化,并做出适配自己问题的3种可复用模板。
理论幻灯片(10页)
核心概念 —— RTCF 四要素
R · 角色

指定以谁的身份来回答。专业度的层次在这里就定了。

T · 任务

用动词写准确。一条提示词里只放一个任务。

C · 背景

背景、约束、已知信息。对答案质量的影响最大。

F · 格式

表格、要点、行数、语气。这一项直接省掉返工时间。

实操流程 (170分钟)
STEP 1 · 随手扔一句 (20分钟)像平时那样,就自己的问题随便问一句,把结果存下来。
STEP 2 · 填满4要素 (40分钟)把同一个问题按模板重写一遍。关键是在背景里填进3行以上。
STEP 3 · 对比与诊断 (40分钟)把两份结果并排放,写出3处变化,再用 [4-2] 诊断自己的提示词。
STEP 4 · 做3种模板 (70分钟)分别做调研用、分析用、写作用模板。变量保持在5个以内。
实操提示词
防幻觉(Hallucination)三条规则① 明确要求不知道就说不知道 ② 数值和引用一律要出处 ③ 让它把事实和推断分开写。把这三行固定放在所有模板的末尾。
本周产出可复用 RTCF 模板3种(调研用·分析用·写作用)+ 改进前后对比表
检查点
  • 对比了同一个问题的两份结果,写出了3处差异
  • 背景(C)里填满了3行以上
  • 完成了变量在5个以内的3种模板
  • 每个模板都换一组输入再跑了一遍
PART 2 · 第5周

发散思维 · SCAMPER × AI

先用数量取胜 —— 做出30个解决方案点子
学习目标用 SCAMPER 七个轴把解法在数量上铺开,训练自己暂缓判断、先把点子攒起来。
理论幻灯片(10页)
核心概念
发散与收敛要分开

一边攒一边评,两件事都会毁掉。本周禁止评价。

SCAMPER 七轴

替代·合并·借用·改变·换用途·去除·反向。它会强行把卡住的想法推到旁边去。

AI 是放大器

我出3个,AI 能扩到30个。但很容易变成平庸的30个,所以必须指定轴。

怪点子的价值

现在用不上的点子,会成为下一个点子的材料。别删,先留着。

实操流程 (170分钟)
STEP 1 · 徒手发想 (25分钟)不用 AI,自己想10分钟,和团队想10分钟。手写至少8个方案。这是基准线。
STEP 2 · SCAMPER 扩展 (50分钟)用下面的提示词抽出7轴 × 3个 = 21个方案。
STEP 3 · 极端条件发想 (45分钟)加上“如果预算为0”“如果必须一天做完”“如果反过来做”的条件继续扩展。
STEP 4 · 整理成30个 (50分钟)重复的合并,但不要删掉,各配一行说明,列成清单。
实操提示词
本周产出解法点子30个清单(含轴·条件标注)
检查点
  • 先不用 AI 手写了8个方案
  • SCAMPER 七轴全部填满了
  • 拿到了30个以上的方案
  • 本周没有对点子做评价
PART 2 · 第6周

矛盾破解 · TRIZ

打破“得到A就会失去B”的结构
学习目标把挡住解决路径的取舍关系定义成矛盾句,再用分离原理做出两边都要的替代方案。
理论幻灯片(10页)
核心概念
矛盾就是问题本身

像“做快了就不准确”一样,问题解不开的原因通常就是一个矛盾。

不要妥协

折中方案会把两边都丢掉。TRIZ 要的不是折中,而是消除矛盾。

分离四原理

按时间、空间、条件、整体与部分来分离。“什么时候用A,什么时候用B”是最常见的解法。

理想最终结果

先想象没有成本也没有副作用、只留下功能的状态,再从那里倒推。

实操流程 (170分钟)
STEP 1 · 找出矛盾 (35分钟)从第5周的30个方案里,把“挺好,就是因为这个不行”的理由收集起来,写成矛盾句。
STEP 2 · 声明理想结果 (30分钟)用一句话写出成本和副作用都为0的理想状态。
STEP 3 · 应用分离原理 (60分钟)用下面的提示词做出时间、空间、条件、部分分离的解法。
STEP 4 · 筛出5个方案 (45分钟)挑出真正把矛盾消掉的5个方案,连同依据一起整理。
实操提示词
本周产出矛盾定义书(矛盾2句 + 理想结果)+ 化解矛盾的5个方案
检查点
  • 把矛盾写成了“提高A,B就变差”的格式
  • 用一句话声明了理想最终结果
  • 四种分离原理全都试过了
  • 选出的5个是消除方案而不是折中方案
PART 2 · 第7周

收敛思维与约束满足

用评价矩阵把30个方案收到1个
学习目标用设了权重的评价矩阵比较各个解法,在极限约束下连同依据选定最终的1个方案。
理论幻灯片(10页)
核心概念
先定标准,后打分

看着候选来定标准,等于答案早就内定了。先把标准确定下来。

权重

所有标准不可能一样重。离成功标准(第1周)越近的项,分量越重。

约束满足(CSP)

“预算0元、1个人、2周”这类硬约束一旦跨不过去,分数再高也淘汰。

启发式搜索

不追求完美最优解,而是快速找到足够好的解。学期项目适合走这条路。

实操流程 (170分钟)
STEP 1 · 确定标准·权重 (30分钟)先定好效果、可行性、成本、紧迫性等4~5个标准和权重。
STEP 2 · 硬约束过滤 (25分钟)先砍掉跨不过约束的方案。30个通常会减到10个以内。
STEP 3 · 矩阵打分 (55分钟)用下面的提示词做出评分表,再按自己的判断修正分数。
STEP 4 · 确定1个方案 + 反驳 (60分钟)对第一名用3行辩护“为什么不是第二名”。辩护不了就重新选。
实操提示词
本周产出点子评价矩阵 + 最终解法1个方案的选定依据书
检查点
  • 标准和权重是在看候选之前定的
  • 先用硬约束筛过候选了
  • 按自己的判断修正了 AI 给的分数
  • 辩护过“为什么不是第二名”
PART 2 · 第8周 · 期中考核

解决方案概念汇报

问题拆解 → 备选比较 → 选定依据 → 解决逻辑的整体检查
学习目标把第1~7周的产出整合成一份解决方案概念说明书,并用依据回答同学的提问。
理论幻灯片(10页)
提交材料构成 (A4 5页左右)
构成内容依据周次
1. 问题定义问题一句话 + 成功标准三层级第1周
2. 原因结构逻辑树 + 攻击点选择依据第2周
3. 任务拆解执行任务表(10个以内)+ 约束第3周
4. 备选探索30个方案摘要 + 矛盾定义书第5·6周
5. 选定评价矩阵 + 1个方案选定依据 + 最大弱点第7周
6. 解决逻辑草案用文字或图示写出解决流程(第9周发展为正式流程图)
附录用过的提示词原文全部第4周模板
汇报 (团队·个人各7分钟 + 提问3分钟)
1分钟 · 问题谁在什么时候因为什么蒙受什么损失。用一个具体案例开场。
2分钟 · 原因与攻击点说明为什么从逻辑树里选了这个点。
3分钟 · 备选与选定必须包含被扔掉的方案和扔掉的理由。
1分钟 · 后8周计划要做出什么、怎么验证。
期中检查提示词
提交材料解决方案概念说明书(A4 5页)+ 汇报材料 + 提示词附录 · 评分占比 30%
检查点
  • 6个构成要素都写进去了
  • 写明了被扔掉的方案和扔掉的理由
  • 把提示词原文作为附录附上了
  • 为5个预想问题准备了答案
PART 3 · 第9周

算法设计 · 用流程图思考

用条件、循环、分支来描述解决流程
学习目标把选定解法的执行流程画成流程图,并写明人做的事和 AI 做的事之间的界线。
理论幻灯片(10页)
核心概念
写不成流程就做不出来

嘴上说得通,流程图却画不出来,那它还不是解法,只是愿望。

三个符号就够了

处理(方框)· 判断(菱形)· 开始/结束(圆角)。用这三个几乎能画出所有流程。

分支就是异常

“否”那一侧箭头是空的流程图,到第12周一定会被打穿。

人与 AI 的分界线

每一步都标出执行主体。需要判断和担责的步骤留给人。

实操流程 (170分钟)
STEP 1 · 用文字写出流程 (30分钟)把解法运转的过程写成编了号的10~15句话。
STEP 2 · 标出判断点 (30分钟)把所有含“如果~的话”的地方全部找出来标记。
STEP 3 · 生成流程图 (60分钟)用下面的提示词拿到 Mermaid 代码,粘到 mermaid.live 等工具里确认并修改图示。
STEP 4 · 标注主体 (50分钟)给每一步加上 [人] / [AI] / [自动] 标注,并写出 AI 做判断的地方有什么风险。
实操提示词
本周产出解决流程流程图(Mermaid 图示)+ 分步主体·失败替代方案表
检查点
  • 把流程写成了10句以上的编号句子
  • 所有判断节点都有“否”路径
  • 每一步都标注了执行主体
  • 指定了不能自动化的步骤
PART 3 · 第10周

提示词链与 AI 智能体

不要一次全交代,要串起来交代
学习目标把大任务拆成4段以上的提示词链,并定义各段之间的输入输出规格。
理论幻灯片(10页)
核心概念
一条提示词一个任务

收集、摘要、撰写、审阅一次全下达,结果全都是平均线以下。

链条的接口

前一段的输出格式就是后一段的输入格式。这里必须规格化,链条才不会断。

把审阅角色分开

写的 AI 自己审自己会变得宽容。审阅要分给不同角色、不同会话。

什么是智能体

给它一个目标,它自己分步执行的结构。本周先用手把这个结构设计一遍。

实操流程 (170分钟)
STEP 1 · 选定1件重复工作 (25分钟)从自己的项目里挑出一件每次都要重复做的事。
STEP 2 · 设计链条 (50分钟)用下面的提示词做出4~6段链条,并确定每段的输入输出规格。
STEP 3 · 实际运行 (60分钟)真的按顺序跑一遍。记录下断掉的地方。
STEP 4 · 加上审阅段 (35分钟)在最后接上一个不同角色的审阅提示词,比较结果差异。
实操提示词
本周产出4段以上提示词链设计书(含指令全文)+ 运行结果
检查点
  • 每一段都定了输入输出规格
  • 把审阅段分给了不同角色
  • 实际从头到尾跑了一遍
  • 记录了断掉的地方和原因
PART 3 · 第11周

无代码自动化与知识连接 (RAG 基础)

把自己的资料接到 AI 上,把重复交给机器
学习目标理解基于自有资料作答的构成(RAG)的原理与局限,并把1件重复工作设计成自动流水线。
理论幻灯片(10页)
核心概念
RAG 的原理

模型不靠背,而是从我给的文档里找出来引用。能附上出处是它最大的优点。

RAG 的局限

放进去的资料错了,答案也会错。文档多不等于效果好,得是整理过的文档才行。

自动化的单位

触发(何时)→ 处理(做什么)→ 输出(去哪里)。能用这三项表达出来,就能自动化。

先手动做三遍

只自动化自己手动做过三遍的流程。这样才知道有哪些例外。

实操流程 (170分钟)
STEP 1 · 整理知识资料 (40分钟)收集5份以上与自己项目相关的资料,整理出标题、出处、日期。
STEP 2 · 搭一个专属助手 (50分钟)上传资料,做一个限定“只依据这些资料作答”的助手,用10个问题测试。
STEP 3 · 设计流水线 (50分钟)用下面的提示词做出定义了触发、处理、输出的自动化设计图。
STEP 4 · 试运行 (30分钟)跑一次,记录结果和耗时,和手动做时对比。
实操提示词
个人信息注意请确保学习资料和自动化对象中不含他人的姓名、联系方式、学号、健康与成绩信息。必要时做匿名化处理后再用,原始资料只放在个人存储空间。
本周产出自动化流水线设计图 + 试运行结果(前后耗时对比)
检查点
  • 用5份以上资料搭好了助手
  • 用10个问题测试了依据引用的质量
  • 做出了定义好触发·处理·输出的设计图
  • 检查过是否含有个人信息
PART 3 · 第12周

异常处理与红队演练

用最狠的方式攻击自己解法的一周
学习目标自己找出解法会崩掉的地方,整理成异常场景,并为可能的反驳准备好应对逻辑。
理论幻灯片(10页)
核心概念
正常路径的错觉

只看流程图上“是”的那条路,任何解法都堪称完美。出事的永远是“否”。

三类异常

失误(输错)· 滥用(故意)· 边界情况(罕见条件)。三者的防范方式各不相同。

红队

专门以击垮我的解法为目的的角色。把这个角色交给 AI,收益最大。

伦理与责任

谁可能受损,这份损害由谁负责。答不上来就得改设计。

实操流程 (170分钟)
STEP 1 · 填满“否”路径 (35分钟)把第9周流程图上每一个“否”会发生什么都写下来。
STEP 2 · 红队攻击 (55分钟)用下面的提示词让自己的解法挨打,把最扎心的5条指摘原样记下来。
STEP 3 · 建立应对逻辑 (45分钟)每条指摘分成 ① 承认并修改 ② 用依据反驳 ③ 宣告在范围之外。
STEP 4 · 伦理检查 (35分钟)把可能受损的群体、个人信息、出错时的责任归属整理成表。
实操提示词
本周产出异常场景表 + 红队反驳应对书 + 伦理检查表
检查点
  • 流程图上所有“否”路径都填满了
  • 把最扎心的5条指摘原样记录了
  • 区分开了要改的和范围之外的
  • 写出了可能受损的群体和责任主体
PART 4 · 第13周

原型制作

别解释,直接给人看——能跑起来的最小样品
学习目标定下最小功能范围,用无代码和 AI 工具做出一个真能上手摸的原型 v1。
理论幻灯片(10页)
核心概念
MVP 的 M 是最小

只做到够验证一条成功标准为止。其余的全部留到以后。

假的也没关系

哪怕背后是人在处理,只要用户经历的体验是真的,用来验证就够了。

先画界面流程

首屏 → 核心动作 → 查看结果。三个画面就能表达大部分流程。

精致度的陷阱

做得越漂亮,别人越会盯着颜色而不是本质。保持粗糙。

实操流程 (170分钟)
STEP 1 · 砍掉范围 (30分钟)写出功能清单,把验证成功标准用不上的全部划掉。
STEP 2 · 设计界面与流程 (40分钟)用三个画面画出使用流程。画在纸上也行。
STEP 3 · 制作 (70分钟)用下面的提示词生成制作说明,再用无代码和 AI 工具做出 v1。
STEP 4 · 自我演示 (30分钟)装成第一次见的人从头用到尾,把卡住的地方全部记下来。
实操提示词
本周产出能运行的原型 v1(链接或截图)+ 使用场景脚本
检查点
  • 把功能砍到了3个以内
  • 用三个画面画出了使用流程
  • 做出了能从头跑到尾的 v1
  • 把卡住的地方列成了清单
PART 4 · 第14周

方案验证 · CER 与用户测试

不说“看着不错”,用依据说话
学习目标通过5人以上的真实使用测试收集数据,写出主张—依据—推论(CER)结构的验证报告,并据此改成 v2。
理论幻灯片(10页)
核心概念
CER 结构

主张(Claim) · 依据(Evidence) · 推论(Reasoning)。没有依据的主张只是读后感。

看行为,别听说法

“挺好的”不是数据。有没有做到最后、花了多少秒,才是数据。

5人法则

只找5个人试,致命问题大多就暴露出来了。观察比数量更重要。

失败也是结果

“假设错了”同样是一个完整的结果。不要硬把它包装成成功。

实操流程 (170分钟)
STEP 1 · 确定假设与指标 (30分钟)把“用了这个解法,[什么]会改变[多少]”写成可被证伪的句子。
STEP 2 · 用户测试 (60分钟)让5个人在没有演示的情况下自己用,记录的是行为而不是说法。
STEP 3 · 数据整理与分析 (45分钟)用下面的提示词把定量与定性数据整理成 CER 结构。
STEP 4 · 修改成 v2 (35分钟)只改卡住人最多的1~2处。不要想着全部都改。
实操提示词
本周产出验证报告(CER 结构,含数据可视化)+ 原型 v2
检查点
  • 把假设写成了可被证伪的句子
  • 让5人以上在没有提示的情况下试用了
  • 每条主张都配上了数据依据
  • 把要改的地方限制在1~2处
PART 4 · 第15周 · 期末考核

最终毕业设计 · Solution Pitch

用8分钟证明问题 – 解法 – 逻辑 – 验证
学习目标把一学期的问题解决过程串成一条逻辑来汇报,并通过同学评审明确说出自己解法的局限。
理论幻灯片(10页)
最终提交材料
提交材料构成篇幅
解决逻辑说明书问题定义 · 原因结构 · 备选与选定 · 流程图 · 异常处理 · 自动化设计A4 8~10页
原型能运行的 v2(链接·截图·演示视频三选一)+ 使用场景
验证报告假设 · 指标 · 结果 · CER 3组 · 局限A4 3页
同学评审书2位同学的评审意见 + 我采纳了什么 / 没采纳什么及理由A4 2页
附录用过的提示词全文,失败尝试的记录不限
汇报构成 (8分钟 + 提问4分钟)
1分钟 · 问题从一个具体场景开始。统计数字放在后面。
2分钟 · 解法与选定依据先亮出被舍弃的方案,选中的方案才有说服力。
2分钟 · 实际演示不要用嘴讲,直接跑给大家看。失败了也照样呈现。
2分钟 · 验证结果先说假设是否成立,再附上依据数据。
1分钟 · 局限与下一步自己说明这个解法在什么条件下行不通。这一项在评价中分量最重。
收尾提示词
提交材料解决逻辑说明书 + 原型 + 验证报告 + 同学评审书 · 评价占比 40%
检查点
  • 四份提交材料全部完成了
  • 在汇报中做了实际演示
  • 明确说明了假设是否成立
  • 自己说清了解法行不通的条件
  • 把失败的尝试留在了附录里

项目生成器

填入自己项目的信息,就会生成可以直接复制使用的指令。 填好空格后点「生成提示词」,再用生成框里的「复制」粘贴给 AI。 生成的指令为英文(English) —— 为了让 AI 的回答质量保持稳定,各语言版本的提示词统一使用英文。

问题拆解生成器

用于第1~3周。生成把问题拆成原因结构和执行任务的指令。
生成的指令 (English)

解法发散与选定生成器

用于第5~7周。生成把点子在数量上扩展、再用加权矩阵选出第一方案的指令。
生成的指令 (English)

验证设计生成器

用于第13~14周。生成让真人试用原型、由此产出依据的指令。
生成的指令 (English)
SOOKMYUNG · PBL Ⅰ · AI PROBLEM SOLVING

PBLⅠ พอร์ทัลการเรียนรู้ · 15 สัปดาห์

เปลี่ยนปัญหาที่นิยามไว้แล้วให้เป็นทางแก้ที่ใช้งานได้จริง ทุกสัปดาห์คุณจะสร้างผลงานหนึ่งชิ้น คัดลอกพรอมป์ตสำหรับฝึกปฏิบัติไปใช้ได้ทันที และสร้างคำสั่งของตัวเองด้วยตัวสร้างพรอมป์ต

ภาคเรียนที่ 2 ปีการศึกษา 2026  |  จันทร์ 16:00–18:50 (อาคารมย็องชิน ห้อง 517)  |  ผู้สอน: จ็อง จินฮยอก
เส้นทางการเรียนรู้  แยกย่อยปัญหาระดมทางแก้คัดกรองและเลือกออกแบบตรรกะทำให้อัตโนมัติต้นแบบตรวจสอบนำเสนอ
ความคืบหน้าเสร็จแล้ว 0 / 15 สัปดาห์
PART 1 · กายวิภาคของปัญหา
PART 2 · ระดมและคัดกรอง
PART 3 · ตรรกะและระบบอัตโนมัติ
PART 4 · ต้นแบบและการตรวจสอบ
PART 1 · สัปดาห์ที่ 1 · ปฐมนิเทศ

การแก้ปัญหาคืออะไร

AI ไม่ใช่ไม้กายสิทธิ์ — สายตาที่เลือกปัญหาซึ่งแก้ได้จริง
เป้าหมายการเรียนรู้เลือกปัญหา 1 เรื่องที่จะลงมือแก้จริงในภาคเรียนนี้ และตัดสินได้ว่าปัญหานั้นอยู่ใน “รูปแบบที่แก้ได้” หรือไม่
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
เงื่อนไขของปัญหาที่แก้ได้

ขอบเขตต้องปิด มีเกณฑ์ตัดสินความสำเร็จ และต้องเห็นผลได้ภายในหนึ่งภาคเรียน

สิ่งที่ AI ทำแทนไม่ได้

การตัดสินใจว่าจะแก้อะไร การตัดสินคุณค่า และการรับผิดชอบ สามอย่างนี้เป็นหน้าที่ของคนจนถึงที่สุด

การคิดเชิงคำนวณ 3 ขั้น

แยกย่อย (ตัดเป็นชิ้น) · จับรูปแบบ (หาสิ่งที่ซ้ำ) · นามธรรม (เหลือไว้แต่แก่น) นี่คือโครงกระดูกของทั้งรายวิชา

จากการค้นหาปัญหา สู่การแก้ปัญหา

ถ้า PBLⅡ ถามว่า “อะไรคือปัญหา” PBLⅠ ถามว่า “แล้วจะลงมือทำอย่างไร”

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · เขียนตัวเลือก 3 เรื่อง (25 นาที)เขียนความไม่สะดวก 3 อย่างที่คุณเจอกับตัวเองในช่วง 3 เดือนที่ผ่านมา ต้องเป็นปัญหาของคุณ ไม่ใช่ของคนอื่น
STEP 2 · ตัดสินความเป็นไปได้ (40 นาที)ใช้พรอมป์ตด้านล่างให้คะแนนทั้ง 3 เรื่องในแง่ขอบเขต เกณฑ์ตัดสิน และระยะเวลา แล้วคัดรูปแบบที่แก้ไม่ได้ออกไป
STEP 3 · เลือกให้เหลือ 1 เรื่อง (45 นาที)นิยามปัญหาเป็นประโยคเดียว ในรูปแบบ “ใคร / เมื่อไร / เพราะอะไร / เสียหายอย่างไร”
STEP 4 · ประกาศเกณฑ์ความสำเร็จ (60 นาที)เขียนเป็นตัวเลขหรือสภาพที่สังเกตได้ว่าอะไรต้องเปลี่ยนไปเมื่อสิ้นภาคเรียนจึงจะพูดได้ว่า “แก้ได้แล้ว”
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์เอกสารเลือกปัญหา A4 1 หน้า (ปัญหาหนึ่งประโยค + เกณฑ์ความสำเร็จ 3 ระดับ) + รายงานสะท้อนคิดประจำสัปดาห์
จุดตรวจสอบ
  • เขียนตัวเลือก 3 เรื่องและคัดออกด้วยคะแนนแล้ว
  • เขียนปัญหาเป็นประโยคเดียวแบบ “ใคร/เมื่อไร/เพราะอะไร/เสียหายอย่างไร” แล้ว
  • เขียนเกณฑ์ความสำเร็จ 3 ระดับในรูปแบบที่สังเกตได้แล้ว
  • ตรวจแล้วว่าไม่มีส่วนใดที่ปล่อยให้ AI ตัดสินใจแทน
PART 1 · สัปดาห์ที่ 2

แยกอาการออกจากสาเหตุ

ใช้ 5 Whys และผังต้นไม้ตรรกะเพื่อโจมตีรากไม่ใช่อาการ
เป้าหมายการเรียนรู้แยกอาการที่มองเห็นออกจากสาเหตุที่ทำให้เกิดอาการนั้น และวาดโครงสร้างสาเหตุเป็นผังต้นไม้ตรรกะที่แตกลึกอย่างน้อย 3 ชั้นได้
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
กับดักของการรักษาอาการ

“เพิ่มการแจ้งเตือนสิ” มักเป็นการสั่งยาที่อาการ ถ้าไม่ถามว่าทำไมถึงพลาด ปัญหาเดิมก็จะกลับมา

5 Whys

ถามว่าทำไมห้าครั้ง จุดที่คำตอบเริ่มตันตั้งแต่ครั้งที่สามมักเป็นสาเหตุที่แท้จริง

ผังต้นไม้ตรรกะ

แตกสาเหตุออกเป็นกิ่ง กิ่งที่อยู่ชั้นเดียวกันต้องไม่ทับซ้อนกัน (MECE)

เลือกจุดโจมตี

คุณตีทุกสาเหตุไม่ได้ เลือกจุดเดียวที่ส่งผลมากและคุณลงมือแตะได้จริง

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · ไล่เรียงอาการ (25 นาที)เขียนเฉพาะอาการที่สังเกตได้จากปัญหาของสัปดาห์ที่ 1 อย่างน้อย 6 ข้อ ตามข้อเท็จจริง ตัดการตีความและการเดาออก
STEP 2 · 5 Whys (35 นาที)เลือกอาการที่เกิดบ่อยที่สุดหนึ่งข้อแล้วขุดลงไปห้าครั้ง ถ้าจบลงที่ความขี้เกียจของคน แปลว่าล้มเหลว
STEP 3 · แตกผังต้นไม้ตรรกะ (60 นาที)ใช้พรอมป์ตด้านล่างแตกโครงสร้างสาเหตุอย่างน้อย 3 ชั้น แล้วจัดกิ่งที่ทับซ้อนกันด้วยมือตัวเอง
STEP 4 · ปักหมุดจุดโจมตี (50 นาที)วางสาเหตุลงบนสองแกนคือระดับผลกระทบ × ความสามารถในการควบคุม แล้วปักหมุดจุดที่จะตีในภาคเรียนนี้ 1–2 จุด
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์ผังต้นไม้สาเหตุของปัญหา (อย่างน้อย 3 ชั้น) + ฉบับที่ปักหมุดจุดโจมตี 1–2 จุด
จุดตรวจสอบ
  • เขียนแยกอาการออกจากสาเหตุแล้ว
  • แตกผังต้นไม้ตรรกะได้อย่างน้อย 3 ชั้น
  • จัดกิ่งที่ทับซ้อนกันในชั้นเดียวกันแล้ว
  • เลือกจุดโจมตีที่จะตีในภาคเรียนนี้แล้ว
PART 1 · สัปดาห์ที่ 3

การแยกย่อยปัญหา (Decomposition)

ตัดก้อนที่ดูแก้ไม่ได้ให้เป็นงานขนาด 1–2 ชั่วโมง
เป้าหมายการเรียนรู้ตัดปัญหาก้อนใหญ่ให้เป็นงานที่ลงมือได้ไม่เกิน 10 ชิ้น และระบุเงื่อนไขก่อนหน้ากับผลลัพธ์ของแต่ละงานได้
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
ขนาดงานที่พอเหมาะ

ขนาดที่นั่งลงทีเดียวแล้วจบ (1–2 ชั่วโมง) ใหญ่กว่านั้นจะถูกผัดวัน เล็กกว่านั้นต้นทุนการจัดการจะสูง

ปรับระดับนามธรรมให้ตรงกัน

ถ้า “สำรวจข้อมูล” กับ “สร้างลิงก์แบบสอบถาม” อยู่ในรายการเดียวกัน งานจะหยุดเดิน

เงื่อนไขก่อนหน้า

อะไรต้องเสร็จก่อนจึงจะเริ่มงานนี้ได้ คำตอบนี้แหละคือตารางเวลา

เขียนข้อจำกัดให้ชัด

เขียนงบประมาณ เวลา คน และสิทธิ์เป็นตัวเลข ยิ่งข้อจำกัดชัด ทางแก้ยิ่งเป็นรูปธรรม

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · ล็อกข้อจำกัด (25 นาที)เขียนเวลาที่ใช้ได้ เงินที่มี จำนวนคนที่ช่วยได้ และข้อมูลที่เข้าถึงได้เป็นตัวเลข
STEP 2 · แยกย่อยรอบแรก (45 นาที)ใช้พรอมป์ตด้านล่างแยกปัญหาเป็นรายการงาน หัวใจอยู่ที่การลบทิ้งจากผลลัพธ์ที่ได้
STEP 3 · ปรับขนาดงาน (50 นาที)งานที่เกิน 2 ชั่วโมงให้ตัดใหม่ งานที่แค่ 15 นาทีให้รวมเข้าด้วยกัน สุดท้ายให้เหลือไม่เกิน 10 ชิ้น
STEP 4 · ล็อกลำดับ (50 นาที)เชื่อมเงื่อนไขก่อนหน้าเพื่อจัดลำดับ แล้วปักหมุด 3 งานที่ต้องทำก่อน ตารางนี้คือเกณฑ์ของอีก 12 สัปดาห์ที่เหลือ
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์ตารางงานที่ลงมือได้ (ไม่เกิน 10 ชิ้น พร้อมงาน/ผลลัพธ์/เวลา/เงื่อนไขก่อนหน้า) + ปักหมุด 3 งานแรก
จุดตรวจสอบ
  • เขียนข้อจำกัดเป็นตัวเลขแล้ว
  • ปรับทุกงานให้มีขนาด 1–2 ชั่วโมงแล้ว
  • จำนวนงานไม่เกิน 10 ชิ้น
  • เลือก 3 อย่างที่จะทำก่อนที่สุดแล้ว
PART 1 · สัปดาห์ที่ 4

สื่อสารกับ AI ให้ได้ผล · RTCF

จัดโครงสร้างคำสั่งด้วย 4 องค์ประกอบ บทบาท·งาน·บริบท·รูปแบบ
เป้าหมายการเรียนรู้เห็นด้วยตาว่าคำถามเดิมให้ผลต่างกันอย่างไรเมื่อมี 4 องค์ประกอบครบ และสร้างเทมเพลตใช้ซ้ำ 3 แบบที่เข้ากับปัญหาของตัวเอง
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก — 4 องค์ประกอบของ RTCF
R · บทบาท

ระบุว่าให้ตอบในฐานะใคร ระดับความเชี่ยวชาญถูกกำหนดตรงนี้

T · งาน

ใช้คำกริยาให้ตรง หนึ่งพรอมป์ตใส่หนึ่งงานเท่านั้น

C · บริบท

ภูมิหลัง ข้อจำกัด และสิ่งที่รู้อยู่แล้ว ส่วนนี้ชี้ขาดคุณภาพคำตอบมากที่สุด

F · รูปแบบ

ตาราง หัวข้อย่อย จำนวนบรรทัด น้ำเสียง เป็นส่วนที่ตัดเวลาแก้งานซ้ำออกไป

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · ถามแบบมั่ว ๆ (20 นาที)โยนคำถามหนึ่งข้อเกี่ยวกับปัญหาของคุณแบบที่ทำเป็นปกติ แล้วเก็บผลลัพธ์ไว้
STEP 2 · เติม 4 องค์ประกอบ (40 นาที)เขียนคำถามเดิมใหม่ตามเทมเพลต หัวใจคือใส่บริบทให้ได้อย่างน้อย 3 บรรทัด
STEP 3 · เทียบและวินิจฉัย (40 นาที)วางผลลัพธ์สองชุดคู่กัน เขียนสิ่งที่ต่างกัน 3 ข้อ แล้ววินิจฉัยพรอมป์ตด้วย [4-2]
STEP 4 · สร้างเทมเพลต 3 แบบ (70 นาที)สร้างเทมเพลตสำหรับค้นคว้า วิเคราะห์ และเขียนงาน อย่างละหนึ่งชุด คุมตัวแปรไว้ไม่เกิน 5 ตัว
พรอมป์ตสำหรับฝึกปฏิบัติ
3 กติกากันการหลอน (Hallucination)① ระบุให้ชัดว่าถ้าไม่รู้ต้องบอกว่าไม่รู้ ② เรียกแหล่งอ้างอิงทุกครั้งที่มีตัวเลขหรือการยกมา ③ ให้เขียนแยกข้อเท็จจริงออกจากการอนุมาน ใส่สามบรรทัดนี้ไว้ท้ายเทมเพลตทุกชุดแบบถาวร
ผลงานประจำสัปดาห์เทมเพลต RTCF ใช้ซ้ำได้ 3 แบบ (ค้นคว้า·วิเคราะห์·เขียนงาน) + ตารางเทียบก่อนและหลังปรับปรุง
จุดตรวจสอบ
  • เทียบผลลัพธ์สองชุดของคำถามเดียวกันและเขียนความต่าง 3 ข้อแล้ว
  • เติมบริบท (C) ได้อย่างน้อย 3 บรรทัด
  • ทำเทมเพลต 3 แบบที่มีตัวแปรไม่เกิน 5 ตัวเสร็จแล้ว
  • ลองรันเทมเพลตแต่ละชุดอีกครั้งด้วยข้อมูลนำเข้าชุดอื่นแล้ว
PART 2 · สัปดาห์ที่ 5

การคิดแบบระดม · SCAMPER × AI

ชนะด้วยปริมาณก่อน — สร้างไอเดียทางแก้ให้ได้ 30 แบบ
เป้าหมายการเรียนรู้ขยายทางแก้เชิงปริมาณด้วย 7 แกนของ SCAMPER และฝึกเก็บไอเดียโดยพักการตัดสินไว้ก่อน
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
แยกการระดมออกจากการคัดกรอง

ถ้าเก็บไอเดียไปพร้อมกับประเมินไปด้วย พังทั้งสองอย่าง สัปดาห์นี้ห้ามประเมิน

7 แกนของ SCAMPER

แทนที่·รวม·ปรับใช้·ดัดแปลง·เปลี่ยนวัตถุประสงค์·ตัดออก·กลับด้าน ช่วยดันความคิดที่ตันให้เขยิบออกข้าง

AI คือเครื่องขยาย

ถ้าคุณออก 3 ไอเดีย AI จะขยายเป็น 30 แต่มันมักกลายเป็น 30 ไอเดียธรรมดา จึงต้องกำหนดแกนให้ชัด

คุณค่าของไอเดียประหลาด

ไอเดียที่ใช้ทันทีไม่ได้จะกลายเป็นวัตถุดิบของไอเดียถัดไป อย่าลบทิ้ง ให้เก็บไว้

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · คิดด้วยมือเปล่า (25 นาที)คิดคนเดียว 10 นาทีโดยไม่ใช้ AI แล้วคิดกับทีมอีก 10 นาที เขียนด้วยมืออย่างน้อย 8 ไอเดีย นี่คือเส้นฐาน
STEP 2 · ขยายด้วย SCAMPER (50 นาที)ใช้พรอมป์ตด้านล่างดึงออกมา 7 แกน × 3 ไอเดีย = 21 ไอเดีย
STEP 3 · คิดใต้เงื่อนไขสุดขั้ว (45 นาที)ตั้งเงื่อนไขว่า “ถ้าไม่มีงบเลย” “ถ้าต้องทำให้เสร็จในวันเดียว” “ถ้าทำกลับด้าน” แล้วขยายเพิ่ม
STEP 4 · เรียบเรียง 30 ไอเดีย (50 นาที)รวมไอเดียที่ซ้ำกันได้แต่ห้ามลบทิ้ง แล้วทำเป็นรายการพร้อมคำอธิบายบรรทัดเดียว
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์รายการไอเดียทางแก้ 30 แบบ (ระบุแกนและเงื่อนไขกำกับ)
จุดตรวจสอบ
  • เขียน 8 ไอเดียด้วยมือก่อนโดยไม่ใช้ AI แล้ว
  • เติมครบทั้ง 7 แกนของ SCAMPER แล้ว
  • ได้ไอเดียรวมอย่างน้อย 30 แบบแล้ว
  • สัปดาห์นี้ยังไม่ได้ประเมินไอเดียเลย
PART 2 · สัปดาห์ที่ 6

แก้ความขัดแย้ง · TRIZ

วิธีทลายโครงสร้างแบบ “ได้ A ก็ต้องเสีย B”
เป้าหมายการเรียนรู้นิยามการแลกได้แลกเสียที่ขวางการแก้ปัญหาให้เป็นประโยคความขัดแย้ง แล้วใช้หลักการแยกสร้างทางเลือกที่ได้ทั้งสองอย่าง
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
ความขัดแย้งคือตัวปัญหา

อย่าง “ทำเร็วแล้วก็ไม่แม่น” เหตุที่ปัญหาไม่คลี่คลายมักมาจากความขัดแย้งเพียงข้อเดียว

อย่าประนีประนอม

ทางสายกลางทำให้เสียทั้งสองด้าน TRIZ มุ่งลบความขัดแย้งทิ้ง แทนที่จะหาจุดกึ่งกลาง

หลักการแยก 4 แบบ

แยกด้วยเวลา พื้นที่ เงื่อนไข และส่วนย่อยกับทั้งหมด “ตอนนี้เป็น A ตอนนั้นเป็น B” คือทางออกที่พบบ่อยที่สุด

ผลลัพธ์สุดท้ายในอุดมคติ

ลองจินตนาการสภาพที่เหลือแต่ฟังก์ชันโดยไม่มีต้นทุนและผลข้างเคียงก่อน แล้วคิดย้อนกลับมาจากตรงนั้น

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · หาความขัดแย้ง (35 นาที)รวบรวมเหตุผลแบบ “ดีอยู่หรอก แต่ติดตรงนี้เลยไม่ได้” จากไอเดีย 30 แบบของสัปดาห์ที่ 5 แล้วเขียนเป็นประโยคความขัดแย้ง
STEP 2 · ประกาศผลลัพธ์ในอุดมคติ (30 นาที)เขียนสภาพอุดมคติที่ต้นทุนและผลข้างเคียงเป็นศูนย์ให้เหลือหนึ่งประโยค
STEP 3 · ใช้หลักการแยก (60 นาที)ใช้พรอมป์ตด้านล่างสร้างทางแก้แบบแยกด้วยเวลา พื้นที่ เงื่อนไข และส่วนย่อย
STEP 4 · คัดให้เหลือ 5 แบบ (45 นาที)เลือกทางแก้ 5 แบบที่ลบความขัดแย้งได้จริง แล้วเรียบเรียงพร้อมเหตุผลกำกับ
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์เอกสารนิยามความขัดแย้ง (ประโยคความขัดแย้ง 2 ประโยค + ผลลัพธ์ในอุดมคติ) + ไอเดียลบความขัดแย้ง 5 แบบ
จุดตรวจสอบ
  • เขียนความขัดแย้งในรูปแบบ “ยิ่งเพิ่ม A ยิ่งทำให้ B แย่ลง” แล้ว
  • ประกาศผลลัพธ์สุดท้ายในอุดมคติเป็นหนึ่งประโยคแล้ว
  • ลองครบทั้ง 4 หลักการแยกแล้ว
  • เลือกทางแก้แบบลบความขัดแย้ง 5 แบบ ไม่ใช่ทางประนีประนอม
PART 2 · สัปดาห์ที่ 7

การคิดแบบคัดกรองและเงื่อนไขบังคับ

ใช้ตารางประเมินย่อไอเดีย 30 แบบให้เหลือ 1 แบบ
เป้าหมายการเรียนรู้เทียบทางแก้ด้วยตารางประเมินที่กำหนดน้ำหนักไว้แล้ว และเลือกทางแก้สุดท้าย 1 แบบที่ทำได้จริงภายใต้เงื่อนไขสุดขั้ว พร้อมเหตุผลรองรับ
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
เกณฑ์มาก่อน คะแนนมาทีหลัง

ถ้าดูตัวเลือกแล้วค่อยตั้งเกณฑ์ เท่ากับปักธงคำตอบไว้ล่วงหน้าแล้ว ให้ตัดสินเกณฑ์ก่อน

น้ำหนัก

เกณฑ์ทุกข้อมีน้ำหนักเท่ากันไม่ได้ ให้น้ำหนักมากกับข้อที่ใกล้เกณฑ์ความสำเร็จ (สัปดาห์ที่ 1)

เงื่อนไขบังคับ (CSP)

ทางแก้ที่ผ่านเงื่อนไขแข็งอย่าง “งบ 0 บาท คน 1 คน เวลา 2 สัปดาห์” ไม่ได้ ต้องตกรอบไม่ว่าคะแนนจะดีแค่ไหน

การค้นหาแบบฮิวริสติก

แทนที่จะหาคำตอบที่ดีที่สุดแบบสมบูรณ์ ให้หาคำตอบที่ดีพอให้เร็ว โปรเจกต์หนึ่งภาคเรียนเหมาะกับแนวนี้

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · กำหนดเกณฑ์และน้ำหนัก (30 นาที)ตัดสินเกณฑ์ 4–5 ข้อ เช่น ผลลัพธ์ ความเป็นไปได้ ต้นทุน ความเร่งด่วน พร้อมน้ำหนักของแต่ละข้อก่อน
STEP 2 · กรองด้วยเงื่อนไขแข็ง (25 นาที)ตัดทางแก้ที่ผ่านเงื่อนไขไม่ได้ออกก่อน ปกติไอเดีย 30 แบบจะเหลือไม่เกิน 10 แบบ
STEP 3 · ให้คะแนนในตาราง (55 นาที)ใช้พรอมป์ตด้านล่างสร้างตารางคะแนน แล้วแก้คะแนนด้วยวิจารณญาณของคุณเอง
STEP 4 · ยืนยัน 1 แบบ + ข้อโต้แย้ง (60 นาที)อธิบายป้องกันใน 3 บรรทัดว่า “ทำไมไม่เลือกอันดับ 2” ถ้าป้องกันไม่ได้ให้กลับไปเลือกใหม่
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์ตารางประเมินไอเดีย + เอกสารเหตุผลการเลือกทางแก้สุดท้าย 1 แบบ
จุดตรวจสอบ
  • กำหนดเกณฑ์และน้ำหนักก่อนดูตัวเลือกแล้ว
  • กรองตัวเลือกด้วยเงื่อนไขแข็งก่อนแล้ว
  • แก้คะแนนของ AI ด้วยวิจารณญาณตัวเองแล้ว
  • อธิบายป้องกันได้แล้วว่า “ทำไมไม่เลือกอันดับ 2”
PART 2 · สัปดาห์ที่ 8 · สอบกลางภาค

นำเสนอแนวคิดทางแก้

แยกย่อยปัญหา → เทียบทางเลือก → เหตุผลการเลือก → ตรวจตรรกะการแก้ปัญหาทั้งชุด
เป้าหมายการเรียนรู้รวมผลงานของสัปดาห์ที่ 1–7 ให้เป็นเอกสารข้อกำหนดแนวคิดทางแก้ฉบับเดียว และตอบคำถามของเพื่อนร่วมชั้นด้วยหลักฐาน
สไลด์ทฤษฎี (10 หน้า)
องค์ประกอบของงานที่ส่ง (ราว 5 หน้า A4)
องค์ประกอบเนื้อหาสัปดาห์ที่อ้างอิง
1. นิยามปัญหาปัญหาหนึ่งประโยค + เกณฑ์ความสำเร็จ 3 ระดับสัปดาห์ที่ 1
2. โครงสร้างสาเหตุผังต้นไม้ตรรกะ + เหตุผลที่เลือกจุดโจมตีสัปดาห์ที่ 2
3. การแยกย่อยงานตารางงานที่ลงมือได้ (ไม่เกิน 10 ชิ้น) + เงื่อนไขบังคับสัปดาห์ที่ 3
4. การค้นหาทางเลือกสรุปไอเดีย 30 แบบ + เอกสารนิยามความขัดแย้งสัปดาห์ที่ 5·6
5. การคัดเลือกตารางประเมิน + เหตุผลการเลือก 1 แบบ + จุดอ่อนที่ใหญ่ที่สุดสัปดาห์ที่ 7
6. ร่างตรรกะการแก้ปัญหาเขียนขั้นตอนการแก้เป็นข้อความหรือแผนภาพ (พัฒนาเป็นผังงานเต็มรูปในสัปดาห์ที่ 9)
ภาคผนวกพรอมป์ตต้นฉบับทั้งหมดที่ใช้เทมเพลตสัปดาห์ที่ 4
การนำเสนอ (ทีมและรายบุคคล ฝ่ายละ 7 นาที + ถามตอบ 3 นาที)
1 นาที · ปัญหาใครเสียหายอย่างไร เมื่อไร และเพราะอะไร เริ่มด้วยกรณีตัวอย่างหนึ่งเรื่อง
2 นาที · สาเหตุและจุดโจมตีทำไมจึงเลือกจุดนี้จากผังต้นไม้ตรรกะ
3 นาที · ทางเลือกและการคัดเลือกต้องใส่ทางเลือกที่ทิ้งไปและเหตุผลที่ทิ้งด้วยเสมอ
1 นาที · แผน 8 สัปดาห์ถัดไปจะสร้างอะไรและจะตรวจสอบอย่างไร
พรอมป์ตตรวจสอบกลางภาค
งานที่ส่งเอกสารข้อกำหนดแนวคิดทางแก้ (A4 5 หน้า) + สื่อนำเสนอ + ภาคผนวกพรอมป์ต · สัดส่วนการประเมิน 30%
จุดตรวจสอบ
  • ใส่องค์ประกอบครบทั้ง 6 ส่วนแล้ว
  • ระบุทางเลือกที่ทิ้งไปและเหตุผลที่ทิ้งแล้ว
  • แนบพรอมป์ตต้นฉบับเป็นภาคผนวกแล้ว
  • เตรียมคำตอบสำหรับคำถามที่คาดว่าจะถูกถาม 5 ข้อแล้ว
PART 3 · สัปดาห์ที่ 9

ออกแบบอัลกอริทึม · คิดด้วยผังงาน

เขียนขั้นตอนการแก้ปัญหาด้วยเงื่อนไข การวนซ้ำ และการแตกกิ่ง
เป้าหมายการเรียนรู้วาดขั้นตอนลงมือของทางแก้ที่เลือกไว้เป็นผังงาน และระบุเส้นแบ่งได้ว่างานไหนเป็นของคนและงานไหนเป็นของ AI
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
ถ้าเขียนเป็นขั้นตอนไม่ได้ ก็สร้างไม่ได้

ถ้าพูดแล้วฟังดูดีแต่วาดผังงานไม่ออก แปลว่านั่นยังไม่ใช่ทางแก้ เป็นแค่ความหวัง

มีสามสัญลักษณ์ก็พอ

ประมวลผล (สี่เหลี่ยม) · ตัดสินใจ (ข้าวหลามตัด) · เริ่มและจบ (มุมมน) สามอย่างนี้วาดได้เกือบทุกขั้นตอน

กิ่งแยกคือข้อยกเว้น

ผังงานที่ลูกศรฝั่ง “ไม่ใช่” ยังว่างอยู่ จะพังแน่นอนในสัปดาห์ที่ 12

เส้นแบ่งระหว่างคนกับ AI

ระบุผู้ลงมือในทุกขั้น ขั้นที่ต้องใช้วิจารณญาณและความรับผิดชอบให้เป็นของคน

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · เขียนขั้นตอนเป็นข้อความ (30 นาที)เขียนกระบวนการที่ทางแก้ทำงานเป็นประโยคใส่หมายเลข 10–15 ข้อ
STEP 2 · ทำเครื่องหมายจุดตัดสินใจ (30 นาที)หาจุดที่มีคำว่า “ถ้า…” ทั้งหมดแล้วทำเครื่องหมายไว้
STEP 3 · สร้างผังงาน (60 นาที)ใช้พรอมป์ตด้านล่างขอโค้ด Mermaid แล้ววางที่ mermaid.live หรือที่คล้ายกันเพื่อดูและแก้แผนภาพ
STEP 4 · ระบุผู้ลงมือ (50 นาที)ใส่ป้าย [คน] / [AI] / [อัตโนมัติ] ในทุกขั้น และเขียนความเสี่ยงของจุดที่ AI เป็นผู้ตัดสิน
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์ผังงานขั้นตอนการแก้ปัญหา (แผนภาพ Mermaid) + ตารางผู้ลงมือและทางสำรองเมื่อล้มเหลวรายขั้น
จุดตรวจสอบ
  • เขียนขั้นตอนเป็นประโยคใส่หมายเลขอย่างน้อย 10 ข้อแล้ว
  • ทุกโหนดตัดสินใจมีเส้นทาง “ไม่ใช่” แล้ว
  • ระบุผู้ลงมือในทุกขั้นแล้ว
  • กำหนดขั้นที่ห้ามทำให้เป็นอัตโนมัติแล้ว
PART 3 · สัปดาห์ที่ 10

การต่อสายพรอมป์ตและเอเจนต์ AI

อย่าสั่งรวดเดียวจบ ให้สั่งแบบต่อกันเป็นสาย
เป้าหมายการเรียนรู้แบ่งงานก้อนใหญ่ออกเป็นสายพรอมป์ตอย่างน้อย 4 ขั้น และนิยามข้อกำหนดของอินพุตกับเอาต์พุตระหว่างขั้นได้
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
หนึ่งพรอมป์ตหนึ่งงาน

ถ้าสั่งรวบรวม สรุป เขียน และตรวจในครั้งเดียว ผลจะออกมาต่ำกว่ามาตรฐานทั้งหมด

รอยต่อของสาย

รูปแบบเอาต์พุตของขั้นก่อนคือรูปแบบอินพุตของขั้นถัดไป ต้องกำหนดมาตรฐานตรงนี้สายจึงจะไม่ขาด

แยกบทบาทผู้ตรวจ

AI ที่เขียนเองแล้วตรวจเองจะใจอ่อน ให้แยกการตรวจไปอยู่คนละบทบาทและคนละเซสชัน

เอเจนต์ AI คืออะไร

โครงสร้างที่พอให้เป้าหมายแล้วมันแบ่งขั้นตอนลงมือเอง สัปดาห์นี้เราจะออกแบบโครงสร้างนั้นด้วยมือ

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · เลือกงานที่ทำซ้ำ 1 อย่าง (25 นาที)เลือกงานหนึ่งอย่างในโปรเจกต์ของคุณที่ต้องทำซ้ำทุกครั้ง
STEP 2 · ออกแบบสาย (50 นาที)ใช้พรอมป์ตด้านล่างสร้างสาย 4–6 ขั้น แล้วกำหนดข้อกำหนดอินพุตและเอาต์พุตของแต่ละขั้น
STEP 3 · ลงมือรัน (60 นาที)รันจริงเรียงตามลำดับ แล้วบันทึกจุดที่สายขาด
STEP 4 · เพิ่มขั้นตรวจสอบ (35 นาที)ต่อพรอมป์ตตรวจสอบจากอีกบทบาทไว้ท้ายสุด แล้วเทียบความต่างของผลลัพธ์
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์เอกสารออกแบบสายพรอมป์ตอย่างน้อย 4 ขั้น (พร้อมคำสั่งฉบับเต็ม) + ผลการรันจริง
จุดตรวจสอบ
  • กำหนดข้อกำหนดอินพุตและเอาต์พุตของทุกขั้นแล้ว
  • แยกขั้นตรวจสอบออกไปเป็นอีกบทบาทแล้ว
  • รันจริงจนจบครบหนึ่งรอบแล้ว
  • บันทึกจุดที่สายขาดและสาเหตุแล้ว
PART 3 · สัปดาห์ที่ 11

ระบบอัตโนมัติโนโค้ดและการเชื่อมความรู้ (พื้นฐาน RAG)

เอาข้อมูลของตัวเองต่อเข้ากับ AI แล้วโยนงานซ้ำ ๆ ให้เครื่องทำ
เป้าหมายการเรียนรู้เข้าใจหลักการและข้อจำกัดของโครงสร้างที่ตอบโดยอ้างอิงข้อมูลของเราเอง (RAG) และออกแบบงานซ้ำ 1 อย่างให้เป็นไปป์ไลน์อัตโนมัติ
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
หลักการของ RAG

แทนที่โมเดลจะท่องจำ มันจะไปค้นและยกมาจากเอกสารที่เราให้ ข้อดีที่สุดคือมีแหล่งอ้างอิงติดมาด้วย

ข้อจำกัดของ RAG

ถ้าข้อมูลที่ใส่เข้าไปผิด คำตอบก็ผิด เอกสารเยอะไม่ได้แปลว่าดีขึ้น ต้องเป็นเอกสารที่จัดระเบียบแล้ว

หน่วยของระบบอัตโนมัติ

ทริกเกอร์ (เมื่อไร) → ประมวลผล (ทำอะไร) → เอาต์พุต (ไปที่ไหน) ถ้าเขียนออกมาเป็นสามอย่างนี้ได้ ก็ทำให้อัตโนมัติได้

ทำด้วยมือสามรอบก่อน

ทำอัตโนมัติเฉพาะขั้นตอนที่เคยทำด้วยมือมาแล้วสามรอบ ทำแบบนั้นจึงจะรู้ว่าข้อยกเว้นอยู่ตรงไหน

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · จัดระเบียบข้อมูลความรู้ (40 นาที)รวบรวมเอกสารที่เกี่ยวกับโปรเจกต์อย่างน้อย 5 ชิ้น แล้วจัดชื่อเรื่อง แหล่งที่มา และวันที่ให้เรียบร้อย
STEP 2 · สร้างผู้ช่วยของตัวเอง (50 นาที)อัปโหลดเอกสารแล้วสร้างผู้ช่วยที่มีเงื่อนไขว่า “ตอบโดยอ้างอิงข้อมูลชุดนี้เท่านั้น” จากนั้นทดสอบด้วยคำถาม 10 ข้อ
STEP 3 · ออกแบบไปป์ไลน์ (50 นาที)ใช้พรอมป์ตด้านล่างสร้างแบบแปลนอัตโนมัติที่นิยามทริกเกอร์ ประมวลผล และเอาต์พุตไว้ครบ
STEP 4 · รันทดลอง (30 นาที)รันหนึ่งรอบ บันทึกผลลัพธ์และเวลาที่ใช้ แล้วเทียบกับตอนทำด้วยมือ
พรอมป์ตสำหรับฝึกปฏิบัติ
ข้อควรระวังเรื่องข้อมูลส่วนบุคคลอย่าให้เอกสารที่ใช้สอนระบบและงานที่ทำอัตโนมัติมีชื่อ เบอร์ติดต่อ รหัสนักศึกษา หรือข้อมูลสุขภาพและผลการเรียนของผู้อื่นปะปนอยู่ ถ้าจำเป็นให้แปลงเป็นนามแฝงก่อนใช้ และเก็บข้อมูลต้นฉบับไว้ในพื้นที่ส่วนตัวเท่านั้น
ผลงานประจำสัปดาห์แบบแปลนไปป์ไลน์อัตโนมัติ + ผลการรันทดลอง (เทียบเวลาที่ใช้ก่อนและหลัง)
จุดตรวจสอบ
  • สร้างผู้ช่วยด้วยเอกสารอย่างน้อย 5 ชิ้นแล้ว
  • ทดสอบคุณภาพการอ้างอิงแหล่งที่มาด้วยคำถาม 10 ข้อแล้ว
  • ทำแบบแปลนที่นิยามทริกเกอร์ ประมวลผล และเอาต์พุตแล้ว
  • ตรวจแล้วว่ามีข้อมูลส่วนบุคคลปะปนอยู่หรือไม่
PART 3 · สัปดาห์ที่ 12

จัดการข้อยกเว้นและเรดทีม

ชั่วโมงที่คุณโจมตีทางแก้ของตัวเองให้แรงที่สุด
เป้าหมายการเรียนรู้หาจุดที่ทางแก้ของตัวเองพังด้วยตัวเอง เรียบเรียงเป็นสถานการณ์ข้อยกเว้น และวางตรรกะรับมือกับข้อโต้แย้ง
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
ภาพลวงของเส้นทางปกติ

ถ้าดูแต่เส้นทาง “ใช่” ของผังงาน ทางแก้ทุกอันดูสมบูรณ์แบบ ปัญหาระเบิดที่ “ไม่ใช่” เสมอ

ข้อยกเว้นสามชนิด

ความผิดพลาด (กรอกผิด) · การใช้ในทางที่ผิด (ตั้งใจ) · เคสขอบ (เงื่อนไขที่เกิดน้อย) แต่ละแบบต้องรับมือไม่เหมือนกัน

เรดทีม

บทบาทที่มีเป้าหมายเดียวคือทำให้ทางแก้ของคุณพัง การมอบบทบาทนี้ให้ AI คุ้มค่าที่สุด

จริยธรรมและความรับผิดชอบ

ใครอาจเสียหาย และใครรับผิดชอบความเสียหายนั้น ถ้าตอบไม่ได้ ให้กลับไปแก้การออกแบบ

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · เติมเส้นทาง “ไม่ใช่” (35 นาที)เขียนว่าเกิดอะไรขึ้นในทุกจุด “ไม่ใช่” ของผังงานจากสัปดาห์ที่ 9
STEP 2 · ให้เรดทีมโจมตี (55 นาที)ใช้พรอมป์ตด้านล่างให้โจมตีทางแก้ของคุณ แล้วบันทึกคำวิจารณ์ที่เจ็บที่สุด 5 ข้อไว้ตามเดิม
STEP 3 · วางตรรกะรับมือ (45 นาที)แยกคำวิจารณ์แต่ละข้อเป็น ① ยอมรับและแก้ ② โต้แย้งด้วยหลักฐาน ③ ประกาศว่าอยู่นอกขอบเขต
STEP 4 · ตรวจสอบจริยธรรม (35 นาที)ทำตารางกลุ่มที่อาจเสียหาย ข้อมูลส่วนบุคคล และผู้รับผิดชอบเมื่อระบบทำงานผิด
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์ตารางสถานการณ์ข้อยกเว้น + เอกสารรับมือข้อโต้แย้งของเรดทีม + ตารางตรวจสอบจริยธรรม
จุดตรวจสอบ
  • เติมเส้นทาง “ไม่ใช่” ของผังงานครบทุกจุดแล้ว
  • บันทึกคำวิจารณ์ที่เจ็บ 5 ข้อไว้ตามเดิมแล้ว
  • แยกได้แล้วว่าอะไรต้องแก้และอะไรอยู่นอกขอบเขต
  • เขียนกลุ่มที่อาจเสียหายและผู้รับผิดชอบแล้ว
PART 4 · สัปดาห์ที่ 13

สร้างต้นแบบ

อย่าอธิบาย ให้แสดงให้เห็น — ต้นแบบขั้นต่ำที่ทำงานได้จริง
เป้าหมายการเรียนรู้กำหนดขอบเขตฟังก์ชันขั้นต่ำ แล้วสร้างต้นแบบ v1 ที่คนจับต้องลองใช้ได้จริงด้วยเครื่องมือโนโค้ดและ AI
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
M ใน MVP คือขั้นต่ำ

สร้างแค่พอตรวจเกณฑ์ความสำเร็จหนึ่งข้อได้ ที่เหลือไว้ทีหลังทั้งหมด

ปลอมก็ได้

ถึงเบื้องหลังจะเป็นคนทำมือ ถ้าประสบการณ์ที่ผู้ใช้เจอเป็นของจริง ก็พอสำหรับการตรวจสอบแล้ว

เริ่มจากลำดับหน้าจอ

หน้าแรก → การกระทำหลัก → ดูผลลัพธ์ สามฉากนี้อธิบายลำดับการใช้งานได้เกือบทั้งหมด

กับดักของความเนี้ยบ

ยิ่งทำให้สวย คนยิ่งวิจารณ์สีแทนที่จะวิจารณ์แก่น ปล่อยให้มันหยาบไว้

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · ตัดขอบเขต (30 นาที)เขียนรายการฟังก์ชัน แล้วลบทุกอย่างที่ไม่จำเป็นต่อการตรวจเกณฑ์ความสำเร็จ
STEP 2 · ออกแบบหน้าจอและลำดับ (40 นาที)วาดลำดับการใช้งานด้วยสามฉาก วาดบนกระดาษก็ได้
STEP 3 · ลงมือสร้าง (70 นาที)ใช้พรอมป์ตด้านล่างทำข้อกำหนดการสร้าง แล้วสร้าง v1 ด้วยเครื่องมือโนโค้ดและ AI
STEP 4 · ทดลองใช้เอง (30 นาที)สวมบทคนที่เพิ่งเห็นครั้งแรกแล้วใช้ให้จบทั้งเส้น จดทุกจุดที่ติดขัด
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์ต้นแบบ v1 ที่ทำงานได้ (ลิงก์หรือภาพหน้าจอ) + บทสถานการณ์การใช้งาน
จุดตรวจสอบ
  • ตัดฟังก์ชันให้เหลือไม่เกิน 3 อย่างแล้ว
  • วาดลำดับการใช้งานเป็นสามฉากแล้ว
  • สร้าง v1 ที่ทำงานได้จนจบเส้นแล้ว
  • จดจุดที่ติดขัดเป็นรายการแล้ว
PART 4 · สัปดาห์ที่ 14

ตรวจสอบทางแก้ · CER และการทดสอบกับผู้ใช้

ไม่ใช่ “ดูดีนะ” แต่พูดด้วยหลักฐาน
เป้าหมายการเรียนรู้เก็บข้อมูลจากการใช้จริงกับคนอย่างน้อย 5 คน เขียนรายงานการตรวจสอบในโครงสร้างข้ออ้าง–หลักฐาน–การอนุมาน (CER) แล้วแก้ต้นแบบเป็น v2
สไลด์ทฤษฎี (10 หน้า)
แนวคิดหลัก
โครงสร้าง CER

ข้ออ้าง (Claim) · หลักฐาน (Evidence) · การอนุมาน (Reasoning) ข้ออ้างที่ไม่มีหลักฐานคือเรียงความความรู้สึก

ดูพฤติกรรม ไม่ใช่คำพูด

“ดีนะ” ไม่ใช่ข้อมูล ข้อมูลคือเขาทำจนจบหรือไม่ และใช้เวลากี่วินาที

กฎ 5 คน

ให้แค่ 5 คนลองใช้ ปัญหาร้ายแรงส่วนใหญ่ก็โผล่ออกมา การสังเกตสำคัญกว่าจำนวน

ความล้มเหลวก็คือผลลัพธ์

ข้อสรุปว่าสมมติฐานผิดก็เป็นผลลัพธ์ที่สมบูรณ์ อย่าฝืนห่อให้ดูเหมือนสำเร็จ

ขั้นตอนปฏิบัติ (170 นาที)
STEP 1 · กำหนดสมมติฐานและตัวชี้วัด (30 นาที)เขียนประโยคที่พิสูจน์ผิดได้ว่า “ถ้าใช้ทางแก้นี้ [อะไร] จะเปลี่ยนไป [เท่าไร]”
STEP 2 · ทดสอบกับผู้ใช้ (60 นาที)ให้ 5 คนลองใช้เองโดยไม่สาธิตให้ดูก่อน แล้วบันทึกพฤติกรรม ไม่ใช่คำพูด
STEP 3 · เรียบเรียงและวิเคราะห์ข้อมูล (45 นาที)ใช้พรอมป์ตด้านล่างจัดข้อมูลเชิงปริมาณและเชิงคุณภาพให้เข้าโครงสร้าง CER
STEP 4 · แก้เป็น v2 (35 นาที)แก้เฉพาะ 1–2 จุดที่คนติดมากที่สุด อย่าพยายามแก้ทั้งหมด
พรอมป์ตสำหรับฝึกปฏิบัติ
ผลงานประจำสัปดาห์รายงานการตรวจสอบ (โครงสร้าง CER พร้อมภาพแสดงข้อมูล) + ต้นแบบ v2
จุดตรวจสอบ
  • เขียนสมมติฐานเป็นประโยคที่พิสูจน์ผิดได้แล้ว
  • ให้คนอย่างน้อย 5 คนลองใช้โดยไม่ใบ้แล้ว
  • แนบหลักฐานเชิงข้อมูลให้ทุกข้ออ้างแล้ว
  • จำกัดสิ่งที่จะแก้ไว้ 1–2 จุดแล้ว
PART 4 · สัปดาห์ที่ 15 · ปลายภาค

แคปสโตนสุดท้าย · Solution Pitch

พิสูจน์ปัญหา – ทางแก้ – ตรรกะ – การตรวจสอบ ให้ได้ใน 8 นาที
เป้าหมายการเรียนรู้ร้อยกระบวนการแก้ปัญหาทั้งภาคเรียนให้เป็นตรรกะเดียวแล้วนำเสนอ และระบุข้อจำกัดของทางแก้ตัวเองให้ชัดผ่านการตรวจของเพื่อนร่วมชั้น
สไลด์ทฤษฎี (10 หน้า)
ผลงานส่งท้ายภาค
ผลงานที่ส่งองค์ประกอบปริมาณ
เอกสารข้อกำหนดตรรกะการแก้ปัญหานิยามปัญหา · โครงสร้างสาเหตุ · ทางเลือกและการคัดเลือก · ผังงาน · การจัดการข้อยกเว้น · การออกแบบระบบอัตโนมัติA4 8–10 หน้า
ต้นแบบv2 ที่ทำงานได้ (เลือกหนึ่งอย่าง: ลิงก์ ภาพหน้าจอ หรือวิดีโอสาธิต) + สถานการณ์การใช้งาน
รายงานการตรวจสอบสมมติฐาน · ตัวชี้วัด · ผลลัพธ์ · CER 3 ชุด · ข้อจำกัดA4 3 หน้า
เอกสารการตรวจของเพื่อนความเห็นจากเพื่อน 2 คน + สิ่งที่ฉันนำไปแก้ / สิ่งที่ไม่นำไปแก้พร้อมเหตุผลA4 2 หน้า
ภาคผนวกพรอมป์ตที่ใช้ทั้งฉบับ และบันทึกความพยายามที่ล้มเหลวไม่จำกัด
โครงการนำเสนอ (8 นาที + ถาม-ตอบ 4 นาที)
1 นาที · ปัญหาเริ่มด้วยฉากจริงหนึ่งฉาก สถิติเอาไว้ทีหลัง
2 นาที · ทางแก้และเหตุผลที่เลือกโชว์ทางเลือกที่ทิ้งไปก่อน แล้วทางที่เลือกจะน่าเชื่อขึ้น
2 นาที · สาธิตการทำงานอย่าอธิบายด้วยปากเปล่า ให้รันของจริง ถ้าพังก็โชว์ไปตามนั้น
2 นาที · ผลการตรวจสอบบอกก่อนว่าผลสนับสนุนสมมติฐานหรือไม่ แล้วจึงแนบข้อมูลหลักฐาน
1 นาที · ข้อจำกัดและก้าวต่อไปบอกด้วยตัวเองว่าทางแก้นี้ใช้ไม่ได้ในเงื่อนไขใด ข้อนี้มีน้ำหนักมากที่สุดในการประเมิน
พรอมป์ตปิดท้าย
ผลงานที่ส่งเอกสารข้อกำหนดตรรกะการแก้ปัญหา + ต้นแบบ + รายงานการตรวจสอบ + เอกสารการตรวจของเพื่อน · สัดส่วนการประเมิน 40%
จุดตรวจสอบ
  • ทำผลงานทั้งสี่ชิ้นเสร็จครบแล้ว
  • สาธิตของจริงในการนำเสนอแล้ว
  • บอกชัดเจนแล้วว่าผลสนับสนุนสมมติฐานหรือไม่
  • บอกด้วยตัวเองแล้วว่าทางแก้ใช้ไม่ได้ในเงื่อนไขใด
  • เก็บบันทึกความพยายามที่ล้มเหลวไว้ในภาคผนวกแล้ว

ตัวสร้างพรอมป์ตสำหรับโปรเจกต์

ใส่ข้อมูลโปรเจกต์ของคุณ แล้วระบบจะสร้างคำสั่งที่คัดลอกไปใช้ได้ทันที กรอกช่องว่างแล้วกด「สร้างพรอมป์ต」จากนั้นกด「คัดลอก」ในกล่องผลลัพธ์เพื่อนำไปวางใน AI คำสั่งที่สร้างขึ้นเป็นภาษาอังกฤษ (English) — เพื่อให้คุณภาพคำตอบของ AI คงที่ พรอมป์ตจึงใช้ภาษาอังกฤษร่วมกันในทุกภาษา

ตัวสร้างพรอมป์ตแยกย่อยปัญหา

สำหรับสัปดาห์ที่ 1–3 สร้างคำสั่งที่ตัดปัญหาออกเป็นโครงสร้างสาเหตุและงานที่ลงมือทำได้
คำสั่งที่สร้างขึ้น (English)

ตัวสร้างพรอมป์ตระดมและเลือกทางแก้

สำหรับสัปดาห์ที่ 5–7 สร้างคำสั่งที่ขยายไอเดียเชิงปริมาณแล้วเลือกทางเลือกที่ 1 ด้วยเมทริกซ์ถ่วงน้ำหนัก
คำสั่งที่สร้างขึ้น (English)

ตัวสร้างพรอมป์ตออกแบบการตรวจสอบ

สำหรับสัปดาห์ที่ 13–14 สร้างคำสั่งที่ให้คนทดลองใช้ต้นแบบเพื่อสร้างหลักฐาน
คำสั่งที่สร้างขึ้น (English)
SOOKMYUNG · PBL Ⅰ · AI PROBLEM SOLVING

Cổng học tập PBLⅠ · 15 tuần

Biến một vấn đề đã được xác định thành giải pháp chạy được. Mỗi tuần bạn làm ra một sản phẩm, sao chép nguyên văn prompt thực hành để dùng, và tự tạo chỉ dẫn riêng bằng bộ tạo prompt.

Học kỳ 2, năm học 2026  |  Thứ Hai 16:00–18:50 (Phòng 517, Tòa Myeongsin)  |  Giảng viên: Jung Jin-hyuk
Luồng học tập  Phân rã vấn đềPhát tán giải phápHội tụ · chọn lọcThiết kế logicTự động hóaPrototypeKiểm chứngThuyết trình
Tiến độ học tập0 / 15 tuần hoàn thành
PART 1 · Mổ xẻ vấn đề
PART 2 · Phát tán và hội tụ
PART 3 · Logic và tự động hóa
PART 4 · Prototype và kiểm chứng
PART 1 · Tuần 1 · Định hướng

Giải quyết vấn đề là gì

AI không phải cây đũa thần — con mắt chọn được vấn đề giải được
Mục tiêu học tậpChọn được 1 vấn đề mà bản thân sẽ thực sự giải quyết trong học kỳ này, và phán đoán được vấn đề đó đã ở “dạng giải được” hay chưa.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Điều kiện của một vấn đề giải được

Phạm vi phải khép kín, phải có tiêu chí phán định thành công, và phải thấy được kết quả trong một học kỳ.

Những việc AI không làm được

Quyết định giải quyết cái gì, phán xét giá trị, và chịu trách nhiệm. Ba việc này đến cùng vẫn là phần của con người.

Ba bước tư duy máy tính

Phân rã (chia nhỏ) · Nhận diện mẫu (tìm cái lặp lại) · Trừu tượng hóa (chỉ giữ cốt lõi). Đây là bộ khung của cả môn học.

Tìm vấn đề → Giải vấn đề

Nếu PBLⅡ hỏi “vấn đề là gì”, thì PBLⅠ hỏi “vậy sẽ làm thế nào”.

Quy trình thực hành (170 phút)
STEP 1 · Viết ra 3 ứng viên (25 phút)Viết 3 điều bất tiện bạn tự trải qua trong 3 tháng gần đây. Phải là vấn đề của bạn, không phải của người khác.
STEP 2 · Phán định khả năng giải (40 phút)Dùng prompt bên dưới chấm điểm 3 ứng viên theo phạm vi, tiêu chí phán định và thời gian, rồi loại các dạng không giải được.
STEP 3 · Chốt 1 vấn đề (45 phút)Định nghĩa vấn đề bằng một câu, theo dạng “ai / khi nào / vì cái gì / chịu thiệt hại gì”.
STEP 4 · Tuyên bố tiêu chí thành công (60 phút)Viết ra bằng con số hoặc trạng thái quan sát được: cuối kỳ cái gì phải khác đi thì mới nói được là “đã giải quyết”.
Prompt thực hành
Sản phẩm tuần nàyBản chọn vấn đề 1 trang A4 (vấn đề một câu + tiêu chí thành công 3 tầng) + báo cáo phản tư tuần
Điểm kiểm tra
  • Đã viết 3 ứng viên và sàng lọc bằng điểm số
  • Đã viết vấn đề thành một câu “ai/khi nào/vì cái gì/thiệt hại gì”
  • Đã viết tiêu chí thành công 3 tầng ở dạng quan sát được
  • Đã kiểm tra xem có phần nào để AI quyết định thay mình không
PART 1 · Tuần 2

Tách hiện tượng khỏi nguyên nhân

Đánh vào gốc rễ chứ không phải triệu chứng, bằng 5 Whys và cây logic
Mục tiêu học tậpTách được triệu chứng nhìn thấy khỏi nguyên nhân tạo ra nó, và vẽ được cây logic khai triển cấu trúc nguyên nhân từ 3 tầng trở lên.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Cái bẫy chữa triệu chứng

“Tăng thêm thông báo” thường chỉ là kê đơn cho triệu chứng. Không hỏi vì sao người ta bỏ lỡ thì vấn đề sẽ quay lại y như cũ.

5 Whys

Hỏi vì sao năm lần. Chỗ bắt đầu tắc câu trả lời, thường từ lần thứ ba, hay chính là nguyên nhân thật.

Cây logic

Trải nguyên nhân ra thành các nhánh. Các nhánh cùng một tầng không được chồng lấn nhau (MECE).

Chọn điểm tấn công

Không thể đánh hết mọi nguyên nhân. Chọn một cái vừa ảnh hưởng lớn vừa nằm trong tầm tay bạn.

Quy trình thực hành (170 phút)
STEP 1 · Liệt kê triệu chứng (25 phút)Từ vấn đề tuần 1, viết ít nhất 6 triệu chứng quan sát được đúng như sự thật. Bỏ diễn giải và suy đoán ra ngoài.
STEP 2 · 5 Whys (35 phút)Chọn triệu chứng xảy ra thường xuyên nhất và đào năm lần. Nếu kết thúc ở “tại người ta lười” thì bạn đã thất bại.
STEP 3 · Khai triển cây logic (60 phút)Dùng prompt bên dưới trải cấu trúc nguyên nhân từ 3 tầng trở lên, rồi tự tay dọn các nhánh chồng lấn.
STEP 4 · Đánh dấu điểm tấn công (50 phút)Đặt các nguyên nhân lên hai trục mức ảnh hưởng × khả năng kiểm soát, rồi đánh dấu 1~2 điểm sẽ đánh trong học kỳ này.
Prompt thực hành
Sản phẩm tuần nàyCây logic nguyên nhân (từ 3 tầng trở lên) + bản đánh dấu 1~2 điểm tấn công
Điểm kiểm tra
  • Đã viết tách riêng triệu chứng và nguyên nhân
  • Đã khai triển cây logic từ 3 tầng trở lên
  • Đã dọn các nhánh chồng lấn trong cùng một tầng
  • Đã chọn điểm tấn công cho học kỳ này
PART 1 · Tuần 3

Phân rã vấn đề (Decomposition)

Cắt khối việc tưởng như không giải nổi thành các đầu việc 1~2 tiếng
Mục tiêu học tậpChia được vấn đề lớn thành tối đa 10 đầu việc khả thi, và nêu rõ điều kiện tiên quyết cùng đầu ra của từng đầu việc.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Kích cỡ vừa phải của một đầu việc

Cỡ ngồi một lần là xong (1~2 tiếng). Lớn hơn thì bạn sẽ trì hoãn, nhỏ hơn thì chi phí quản lý lại lớn.

Đồng bộ mức trừu tượng

Khi “khảo sát” và “tạo link phiếu hỏi” nằm chung một danh sách thì tiến độ sẽ đứng lại.

Điều kiện tiên quyết

Cái gì xong thì mới bắt đầu được việc này. Chính nó là lịch trình của bạn.

Nêu rõ ràng buộc

Viết ngân sách · thời gian · nhân lực · quyền hạn bằng con số. Ràng buộc càng rõ thì giải pháp càng cụ thể.

Quy trình thực hành (170 phút)
STEP 1 · Chốt ràng buộc (25 phút)Viết bằng con số: thời gian khả dụng, tiền có thể chi, số người hỗ trợ, dữ liệu tiếp cận được.
STEP 2 · Phân rã lần 1 (45 phút)Dùng prompt bên dưới phân rã vấn đề thành danh sách đầu việc. Điều cốt lõi là xóa bớt trong kết quả nhận được.
STEP 3 · Chỉnh kích cỡ (50 phút)Việc quá 2 tiếng thì cắt tiếp, việc 15 phút thì gộp lại. Cuối cùng còn tối đa 10 việc.
STEP 4 · Chốt thứ tự (50 phút)Nối các điều kiện tiên quyết để định thứ tự, rồi đánh dấu 3 việc làm trước nhất. Bảng này là chuẩn cho 12 tuần còn lại.
Prompt thực hành
Sản phẩm tuần nàyBảng đầu việc thực thi (tối đa 10 việc, gồm đầu việc/sản phẩm/thời gian/điều kiện tiên quyết) + đánh dấu 3 việc ưu tiên
Điểm kiểm tra
  • Đã viết ràng buộc bằng con số
  • Mọi đầu việc đều đã vừa cỡ 1~2 tiếng
  • Số đầu việc không quá 10
  • Đã chọn 3 việc phải làm trước nhất
PART 1 · Tuần 4

Giao tiếp hiệu quả với AI · RTCF

Cấu trúc hóa chỉ dẫn bằng 4 yếu tố vai trò · nhiệm vụ · bối cảnh · định dạng
Mục tiêu học tậpThấy được cùng một câu hỏi nhưng kết quả khác đi thế nào khi có đủ 4 yếu tố, và tạo 3 mẫu tái sử dụng phù hợp với vấn đề của mình.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi — 4 yếu tố RTCF
R · Vai trò

Chỉ định trả lời với tư cách ai. Tầng chuyên môn được quyết định ở đây.

T · Nhiệm vụ

Chính xác, bằng động từ. Một prompt chỉ đặt một nhiệm vụ.

C · Bối cảnh

Nền tảng · ràng buộc · điều đã biết. Đây là thứ chi phối chất lượng câu trả lời nhiều nhất.

F · Định dạng

Bảng · gạch đầu dòng · số dòng · giọng văn. Đây là mục xóa bỏ thời gian làm lại.

Quy trình thực hành (170 phút)
STEP 1 · Hỏi bừa (20 phút)Đặt một câu hỏi liên quan đến vấn đề của bạn theo cách vẫn thường làm và lưu kết quả lại.
STEP 2 · Điền đủ 4 yếu tố (40 phút)Viết lại câu hỏi đó theo mẫu. Mấu chốt là đưa từ 3 dòng trở lên vào phần bối cảnh.
STEP 3 · So sánh và chẩn đoán (40 phút)Đặt hai kết quả cạnh nhau, viết ra 3 điểm đã khác đi, rồi chẩn đoán prompt bằng [4-2].
STEP 4 · Làm 3 mẫu (70 phút)Làm lần lượt mẫu tra cứu, mẫu phân tích và mẫu soạn thảo. Giữ số biến trong vòng 5.
Prompt thực hành
3 quy tắc chống ảo giác (Hallucination)① Nêu rõ là không biết thì phải nói không biết ② Yêu cầu nguồn cho số liệu · trích dẫn ③ Bắt viết tách riêng sự thật và suy luận. Hãy gắn cố định ba dòng này ở cuối mọi mẫu.
Sản phẩm tuần này3 mẫu RTCF tái sử dụng (tra cứu · phân tích · soạn thảo) + bảng so sánh trước và sau cải thiện
Điểm kiểm tra
  • Đã so sánh hai kết quả của cùng một câu hỏi và viết ra 3 khác biệt
  • Đã điền từ 3 dòng trở lên vào phần bối cảnh (C)
  • Đã hoàn thành 3 mẫu với tối đa 5 biến
  • Đã chạy lại mỗi mẫu thêm một lần với đầu vào khác
PART 2 · Tuần 5

Tư duy phát tán · SCAMPER × AI

Thắng bằng số lượng trước — tạo ra 30 phương án giải pháp
Mục tiêu học tậpMở rộng giải pháp về mặt số lượng theo 7 trục SCAMPER, và luyện tập thu thập ý tưởng trong khi tạm gác phán xét.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Tách phát tán khỏi hội tụ

Vừa thu thập vừa đánh giá thì hỏng cả hai. Tuần này cấm đánh giá.

7 trục SCAMPER

Thay thế · kết hợp · phỏng theo · biến đổi · đổi công dụng · loại bỏ · đảo ngược. Chúng cưỡng bức đẩy suy nghĩ đang tắc sang một bên.

AI là bộ khuếch đại

Bạn đưa ra 3 thì AI nhân lên thành 30. Nhưng dễ thành 30 cái tầm thường, nên phải chỉ định trục.

Giá trị của ý tưởng kỳ quặc

Ý tưởng chưa dùng được ngay lại là nguyên liệu cho ý tưởng kế tiếp. Đừng xóa, hãy giữ lại.

Quy trình thực hành (170 phút)
STEP 1 · Nghĩ tay không (25 phút)10 phút một mình không dùng AI, 10 phút với nhóm. Viết tay tối thiểu 8 phương án. Đây là đường cơ sở.
STEP 2 · Mở rộng bằng SCAMPER (50 phút)Dùng prompt bên dưới rút ra 7 trục × 3 phương án = 21 phương án.
STEP 3 · Nghĩ theo điều kiện cực đoan (45 phút)Đặt điều kiện “nếu ngân sách bằng 0”, “nếu phải xong trong một ngày”, “nếu làm ngược lại” để mở rộng thêm.
STEP 4 · Sắp xếp 30 phương án (50 phút)Gộp các phương án trùng lặp nhưng không xóa, rồi lập danh sách kèm một dòng giải thích cho mỗi phương án.
Prompt thực hành
Sản phẩm tuần nàyDanh sách 30 phương án giải pháp (có ghi rõ trục · điều kiện)
Điểm kiểm tra
  • Đã viết tay 8 phương án trước khi dùng AI
  • Đã điền đủ cả 7 trục SCAMPER
  • Đã có từ 30 phương án trở lên
  • Tuần này chưa đánh giá ý tưởng nào
PART 2 · Tuần 6

Giải mâu thuẫn · TRIZ

Cách phá vỡ cấu trúc “được A thì mất B”
Mục tiêu học tậpĐịnh nghĩa được đánh đổi đang chặn lời giải thành câu mâu thuẫn, và dùng nguyên lý tách biệt để tạo phương án được cả hai.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Mâu thuẫn chính là vấn đề

Như “làm nhanh thì thiếu chính xác”, lý do vấn đề không giải được thường nằm ở một mâu thuẫn duy nhất.

Đừng thỏa hiệp

Phương án dung hòa làm mất cả hai. TRIZ tìm cách triệt tiêu mâu thuẫn thay vì dung hòa.

4 nguyên lý tách biệt

Tách theo thời gian · không gian · điều kiện · toàn thể và bộ phận. “Lúc này là A, lúc kia là B” là lời giải phổ biến nhất.

Kết quả lý tưởng cuối cùng

Trước hết hình dung trạng thái chỉ còn chức năng, không chi phí cũng không tác dụng phụ, rồi tính ngược lại từ đó.

Quy trình thực hành (170 phút)
STEP 1 · Tìm mâu thuẫn (35 phút)Gom các lý do “hay đấy nhưng vì cái này nên không được” trong 30 phương án tuần 5 và viết thành câu mâu thuẫn.
STEP 2 · Tuyên bố kết quả lý tưởng (30 phút)Viết một câu về trạng thái lý tưởng có chi phí và tác dụng phụ bằng 0.
STEP 3 · Áp dụng nguyên lý tách biệt (60 phút)Dùng prompt bên dưới tạo giải pháp tách theo thời gian · không gian · điều kiện · bộ phận.
STEP 4 · Chọn ra 5 phương án (45 phút)Chọn 5 phương án thực sự triệt tiêu được mâu thuẫn và sắp xếp lại kèm căn cứ.
Prompt thực hành
Sản phẩm tuần nàyBản định nghĩa mâu thuẫn (2 câu mâu thuẫn + kết quả lý tưởng) + 5 ý tưởng hóa giải mâu thuẫn
Điểm kiểm tra
  • Đã viết mâu thuẫn theo dạng “nâng A lên thì B xấu đi”
  • Đã tuyên bố kết quả lý tưởng cuối cùng bằng một câu
  • Đã thử cả 4 nguyên lý tách biệt
  • Đã chọn 5 phương án triệt tiêu chứ không phải dung hòa
PART 2 · Tuần 7

Tư duy hội tụ và thỏa mãn ràng buộc

Rút 30 phương án xuống còn 1 bằng ma trận đánh giá
Mục tiêu học tậpSo sánh các giải pháp bằng ma trận đánh giá có trọng số, và chọn ra 1 phương án cuối cùng khả thi dưới ràng buộc khắc nghiệt, kèm căn cứ.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Tiêu chí trước, điểm số sau

Nhìn ứng viên rồi mới đặt tiêu chí nghĩa là bạn đã định sẵn đáp án. Hãy chốt tiêu chí trước.

Trọng số

Không thể mọi tiêu chí đều nặng như nhau. Hãy dồn trọng lượng cho mục gần với tiêu chí thành công (tuần 1).

Thỏa mãn ràng buộc (CSP)

Phương án không vượt qua ràng buộc cứng như “0 đồng, 1 người, 2 tuần” thì bị loại bất kể điểm số.

Tìm kiếm heuristic

Thay vì lời giải tối ưu hoàn hảo, hãy tìm nhanh một lời giải đủ tốt. Với dự án học kỳ thì hướng này hợp hơn.

Quy trình thực hành (170 phút)
STEP 1 · Chốt tiêu chí · trọng số (30 phút)Trước hết định 4~5 tiêu chí như hiệu quả · tính khả thi · chi phí · mức cấp bách, cùng trọng số của chúng.
STEP 2 · Lọc bằng ràng buộc cứng (25 phút)Cắt trước các phương án không vượt qua ràng buộc. 30 phương án thường rút xuống còn 10 hoặc ít hơn.
STEP 3 · Chấm điểm ma trận (55 phút)Dùng prompt bên dưới lập bảng chấm điểm, rồi tự sửa điểm theo phán đoán của bạn.
STEP 4 · Chốt 1 phương án + phản biện (60 phút)Bảo vệ phương án hạng nhất bằng 3 dòng “vì sao không phải hạng nhì”. Nếu không bảo vệ được thì chọn lại.
Prompt thực hành
Sản phẩm tuần nàyMa trận đánh giá ý tưởng + bản căn cứ chọn 1 giải pháp cuối cùng
Điểm kiểm tra
  • Đã định tiêu chí và trọng số trước khi nhìn ứng viên
  • Đã lọc ứng viên bằng ràng buộc cứng trước
  • Đã sửa điểm của AI theo phán đoán của mình
  • Đã bảo vệ được “vì sao không phải hạng nhì”
PART 2 · Tuần 8 · Giữa kỳ

Thuyết trình ý niệm giải pháp

Kiểm tra tổng hợp: phân rã vấn đề → so sánh phương án → căn cứ chọn lựa → logic giải quyết
Mục tiêu học tậpTích hợp sản phẩm của tuần 1~7 thành một bản đặc tả ý niệm giải pháp, và trả lời câu hỏi của bạn học bằng căn cứ.
Slide lý thuyết (10 trang)
Cấu phần bài nộp (khoảng 5 trang A4)
Cấu phầnNội dungTuần làm căn cứ
1. Định nghĩa vấn đềVấn đề một câu + tiêu chí thành công 3 tầngTuần 1
2. Cấu trúc nguyên nhânCây logic + căn cứ chọn điểm tấn côngTuần 2
3. Phân rã đầu việcBảng đầu việc thực thi (tối đa 10) + ràng buộcTuần 3
4. Tìm phương ánTóm tắt 30 phương án + bản định nghĩa mâu thuẫnTuần 5 · 6
5. Chọn lựaMa trận đánh giá + căn cứ chọn 1 phương án + điểm yếu lớn nhấtTuần 7
6. Bản nháp logic giải quyếtQuy trình giải quyết bằng chữ hoặc hình (tuần 9 sẽ phát triển thành lưu đồ chính thức)
Phụ lụcToàn văn các prompt đã dùngMẫu tuần 4
Thuyết trình (nhóm · cá nhân mỗi bên 7 phút + hỏi đáp 3 phút)
1 phút · Vấn đềAi, khi nào, vì cái gì, chịu thiệt hại gì. Hãy mở đầu bằng một trường hợp cụ thể.
2 phút · Nguyên nhân và điểm tấn côngVì sao trong cây logic bạn chọn đúng điểm này.
3 phút · Phương án và chọn lựaBắt buộc phải nêu cả phương án đã bỏ và lý do bỏ.
1 phút · Kế hoạch 8 tuần tớiSẽ làm ra cái gì và kiểm chứng thế nào.
Prompt kiểm tra giữa kỳ
Bài nộpBản đặc tả ý niệm giải pháp (5 trang A4) + tài liệu thuyết trình + phụ lục prompt · Tỷ trọng đánh giá 30%
Điểm kiểm tra
  • Đã đưa đủ cả 6 cấu phần
  • Đã nêu rõ phương án đã bỏ và lý do bỏ
  • Đã đính kèm toàn văn prompt ở phụ lục
  • Đã chuẩn bị câu trả lời cho 5 câu hỏi dự kiến
PART 3 · Tuần 9

Thiết kế thuật toán · tư duy bằng lưu đồ

Mô tả quy trình giải quyết bằng điều kiện · lặp · rẽ nhánh
Mục tiêu học tậpVẽ được quy trình thực thi của giải pháp đã chọn thành lưu đồ, và nêu rõ ranh giới giữa việc của người và việc của AI.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Không viết được thành quy trình thì không làm được

Nói miệng thì trôi chảy mà không vẽ nổi lưu đồ, nghĩa là bạn mới có mong muốn chứ chưa có giải pháp.

Ba ký hiệu là đủ

Xử lý (chữ nhật) · phán định (hình thoi) · bắt đầu/kết thúc (bo tròn). Ba cái này vẽ được gần như mọi quy trình.

Rẽ nhánh chính là ngoại lệ

Lưu đồ có mũi tên phía “không” bỏ trống thì chắc chắn sẽ vỡ ở tuần 12.

Ranh giới người · AI

Ghi rõ chủ thể thực hiện ở từng bước. Bước nào cần phán xét và trách nhiệm thì để cho người.

Quy trình thực hành (170 phút)
STEP 1 · Viết quy trình bằng chữ (30 phút)Viết quá trình vận hành của giải pháp thành 10~15 câu có đánh số.
STEP 2 · Đánh dấu điểm phán định (30 phút)Tìm và đánh dấu mọi chỗ có chữ “nếu như ~ thì”.
STEP 3 · Sinh lưu đồ (60 phút)Dùng prompt bên dưới lấy mã Mermaid, dán vào mermaid.live hoặc công cụ tương tự để xem và sửa sơ đồ.
STEP 4 · Ghi chủ thể (50 phút)Gắn nhãn [người] / [AI] / [tự động] cho từng bước, và viết ra rủi ro ở những chỗ AI phán định.
Prompt thực hành
Sản phẩm tuần nàyLưu đồ quy trình giải quyết (sơ đồ Mermaid) + bảng chủ thể và phương án dự phòng theo từng bước
Điểm kiểm tra
  • Đã viết quy trình thành từ 10 câu đánh số trở lên
  • Mọi nút phán định đều có đường “không”
  • Đã ghi chủ thể thực hiện ở từng bước
  • Đã chỉ định bước không được tự động hóa
PART 3 · Tuần 10

Nối chuỗi prompt và tác nhân AI

Đừng giao hết một lần, hãy giao theo chuỗi nối tiếp
Mục tiêu học tậpChia được công việc lớn thành chuỗi prompt từ 4 bước trở lên, và định nghĩa quy cách đầu vào - đầu ra giữa các bước.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Một prompt một nhiệm vụ

Giao thu thập · tóm tắt · soạn thảo · rà soát cùng một lúc thì tất cả đều dưới trung bình.

Mối nối của chuỗi

Định dạng đầu ra của bước trước chính là định dạng đầu vào của bước sau. Phải chuẩn hóa chỗ này thì chuỗi mới không đứt.

Tách riêng vai người rà soát

AI viết mà tự rà soát thì sẽ dễ dãi. Hãy tách phần rà soát sang vai trò khác, phiên làm việc khác.

Tác nhân AI là gì

Là cấu hình mà khi được giao mục tiêu sẽ tự chia bước và thực thi. Tuần này ta tự tay thiết kế cấu trúc đó.

Quy trình thực hành (170 phút)
STEP 1 · Chọn 1 việc lặp lại (25 phút)Chọn một đầu việc sẽ lặp đi lặp lại trong dự án của bạn.
STEP 2 · Thiết kế chuỗi (50 phút)Dùng prompt bên dưới tạo chuỗi 4~6 bước và chốt quy cách đầu vào - đầu ra của từng bước.
STEP 3 · Chạy thử (60 phút)Chạy thật theo đúng thứ tự. Ghi lại những chỗ bị đứt.
STEP 4 · Thêm bước rà soát (35 phút)Gắn thêm prompt rà soát với vai trò khác ở cuối chuỗi và so sánh khác biệt trong kết quả.
Prompt thực hành
Sản phẩm tuần nàyBản thiết kế chuỗi prompt từ 4 bước trở lên (kèm toàn văn chỉ dẫn) + kết quả chạy thử
Điểm kiểm tra
  • Đã định quy cách đầu vào - đầu ra ở từng bước
  • Đã tách bước rà soát sang vai trò khác
  • Đã thực sự chạy hết một lượt
  • Đã ghi lại chỗ bị đứt và nguyên nhân
PART 3 · Tuần 11

Tự động hóa no-code và kết nối tri thức (RAG cơ bản)

Gắn tài liệu của mình vào AI, và giao phần lặp lại cho máy
Mục tiêu học tậpHiểu nguyên lý và giới hạn của cấu hình trả lời dựa trên tài liệu của mình (RAG), và thiết kế 1 việc lặp lại thành đường ống tự động.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Nguyên lý của RAG

Thay vì mô hình thuộc lòng, nó tìm và trích dẫn từ tài liệu tôi đưa vào. Ưu điểm lớn nhất là câu trả lời có nguồn.

Giới hạn của RAG

Tài liệu đưa vào sai thì câu trả lời cũng sai. Nhiều tài liệu không có nghĩa là tốt hơn, phải là tài liệu đã được sắp xếp.

Đơn vị của tự động hóa

Kích hoạt (khi nào) → xử lý (cái gì) → đầu ra (đi đâu). Diễn đạt được bằng ba cái này thì tự động hóa được.

Làm tay ba lần trước đã

Chỉ tự động hóa quy trình bạn đã tự làm tay ba lần. Có vậy bạn mới biết các ngoại lệ.

Quy trình thực hành (170 phút)
STEP 1 · Sắp xếp tài liệu tri thức (40 phút)Gom từ 5 tài liệu liên quan dự án trở lên và sắp xếp tiêu đề · nguồn · ngày tháng.
STEP 2 · Dựng trợ lý riêng (50 phút)Tải tài liệu lên, tạo trợ lý với điều kiện “chỉ trả lời dựa trên tài liệu này” và thử bằng 10 câu hỏi.
STEP 3 · Thiết kế đường ống (50 phút)Dùng prompt bên dưới lập bản thiết kế tự động hóa có định nghĩa kích hoạt · xử lý · đầu ra.
STEP 4 · Chạy thử nghiệm (30 phút)Chạy một lần, ghi lại kết quả và thời gian tiêu tốn, rồi so với khi làm tay.
Prompt thực hành
Lưu ý về thông tin cá nhânHãy đảm bảo tài liệu học tập và đối tượng tự động hóa không chứa tên, số liên lạc, mã số sinh viên, thông tin sức khỏe · điểm số của người khác. Nếu cần thì ẩn danh trước khi dùng, và giữ dữ liệu gốc chỉ trong kho lưu trữ cá nhân.
Sản phẩm tuần nàyBản thiết kế đường ống tự động hóa + kết quả chạy thử nghiệm (so sánh thời gian trước và sau)
Điểm kiểm tra
  • Đã dựng trợ lý với từ 5 tài liệu trở lên
  • Đã thử chất lượng trích dẫn căn cứ bằng 10 câu hỏi
  • Đã lập bản thiết kế có định nghĩa kích hoạt · xử lý · đầu ra
  • Đã kiểm tra xem có chứa thông tin cá nhân không
PART 3 · Tuần 12

Xử lý ngoại lệ và đội đỏ

Giờ tự tấn công lời giải của mình mạnh nhất có thể
Mục tiêu học tậpTự tìm ra những chỗ lời giải bị vỡ, sắp xếp chúng thành kịch bản ngoại lệ, và dựng logic đối đáp với các phản bác.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Ảo giác của đường đi thuận

Chỉ nhìn nhánh “có” của lưu đồ thì lời giải nào cũng hoàn hảo. Vấn đề luôn nổ ra ở nhánh “không”.

Ba loại ngoại lệ

Nhầm lẫn (nhập sai) · lạm dụng (cố ý) · trường hợp biên (điều kiện hiếm). Mỗi loại phòng bị một khác.

Đội đỏ

Vai trò có mục đích là đánh sập lời giải của bạn. Giao vai này cho AI là đáng giá nhất.

Đạo đức · trách nhiệm

Ai có thể chịu thiệt, và ai chịu trách nhiệm cho thiệt hại đó. Không có câu trả lời thì phải sửa thiết kế.

Quy trình thực hành (170 phút)
STEP 1 · Lấp đầy nhánh “không” (35 phút)Viết ra chuyện gì xảy ra ở mọi nhánh “không” trong lưu đồ tuần 9.
STEP 2 · Đội đỏ tấn công (55 phút)Dùng prompt bên dưới để lời giải của bạn bị tấn công, và ghi nguyên văn 5 lời chỉ trích đau nhất.
STEP 3 · Dựng logic đối đáp (45 phút)Với từng lời chỉ trích, phân loại ① thừa nhận và sửa ② phản bác bằng căn cứ ③ tuyên bố nằm ngoài phạm vi.
STEP 4 · Rà soát đạo đức (35 phút)Lập bảng các nhóm có thể chịu thiệt, thông tin cá nhân, và ai chịu trách nhiệm khi trục trặc.
Prompt thực hành
Sản phẩm tuần nàyBảng kịch bản ngoại lệ + bản đối đáp phản bác của đội đỏ + bảng rà soát đạo đức
Điểm kiểm tra
  • Đã lấp đầy mọi nhánh “không” của lưu đồ
  • Đã ghi nguyên văn 5 lời chỉ trích đau nhất
  • Đã phân biệt cái phải sửa với cái nằm ngoài phạm vi
  • Đã ghi nhóm có thể chịu thiệt và chủ thể chịu trách nhiệm
PART 4 · Tuần 13

Chế tạo nguyên mẫu

Đừng giải thích, hãy cho xem — sản phẩm thử tối thiểu chạy được
Mục tiêu học tậpXác định phạm vi chức năng tối thiểu, và dùng công cụ no-code · AI làm ra nguyên mẫu v1 mà người khác sờ tay vào được.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Chữ M trong MVP là tối thiểu

Chỉ làm vừa đủ để kiểm tra một tiêu chí thành công. Phần còn lại đều để sau.

Giả cũng được

Dù phía sau là người xử lý bằng tay, chỉ cần trải nghiệm của người dùng là thật thì đủ để kiểm chứng.

Luồng màn hình trước đã

Màn hình đầu → hành động cốt lõi → xem kết quả. Ba cảnh là đủ diễn đạt hầu hết các luồng.

Cái bẫy của độ hoàn thiện

Làm càng đẹp thì người ta càng chê màu sắc thay vì bàn về bản chất. Hãy giữ nó thô ráp.

Quy trình thực hành (170 phút)
STEP 1 · Cắt phạm vi (30 phút)Viết danh sách chức năng, rồi xóa hết những gì không cần cho việc kiểm tra tiêu chí thành công.
STEP 2 · Thiết kế màn hình · luồng (40 phút)Vẽ luồng sử dụng bằng ba cảnh. Vẽ trên giấy cũng được.
STEP 3 · Chế tạo (70 phút)Dùng prompt bên dưới tạo bản đặc tả chế tạo và làm v1 bằng công cụ no-code · AI.
STEP 4 · Tự chạy thử (30 phút)Giả làm người lần đầu nhìn thấy và dùng cho tới hết. Ghi lại mọi chỗ bị kẹt.
Prompt thực hành
Sản phẩm tuần nàyNguyên mẫu v1 chạy được (đường liên kết hoặc ảnh chụp) + kịch bản sử dụng
Điểm kiểm tra
  • Đã cắt chức năng xuống còn 3 hoặc ít hơn
  • Đã vẽ luồng sử dụng thành ba cảnh
  • Đã làm ra v1 chạy được đến cuối
  • Đã ghi các chỗ bị kẹt thành danh sách
PART 4 · Tuần 14

Kiểm chứng giải pháp · CER và kiểm thử người dùng

Nói bằng căn cứ, không phải bằng “trông có vẻ ổn”
Mục tiêu học tậpThu dữ liệu bằng kiểm thử thực tế với từ 5 người trở lên, viết báo cáo kiểm chứng theo cấu trúc luận điểm – căn cứ – suy luận (CER) và sửa thành v2.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Cấu trúc CER

Luận điểm (Claim) · Căn cứ (Evidence) · Suy luận (Reasoning). Luận điểm không có căn cứ chỉ là bài cảm nghĩ.

Hãy nhìn hành động thay vì lời nói

“Hay đấy” không phải dữ liệu. Có làm đến cuối không, mất bao nhiêu giây mới là dữ liệu.

Quy tắc 5 người

Chỉ cần 5 người thử là phần lớn lỗi chí mạng đã lộ ra. Quan sát quan trọng hơn con số.

Thất bại cũng là kết quả

Kết luận rằng giả thuyết sai cũng là một kết quả trọn vẹn. Đừng gượng ép gói nó thành thành công.

Quy trình thực hành (170 phút)
STEP 1 · Chốt giả thuyết và chỉ số (30 phút)Viết “dùng lời giải này thì [cái gì] thay đổi [bao nhiêu]” thành câu có thể bác bỏ được.
STEP 2 · Kiểm thử người dùng (60 phút)Cho 5 người tự dùng mà không hướng dẫn, và ghi lại hành động chứ không phải lời nói.
STEP 3 · Sắp xếp · phân tích dữ liệu (45 phút)Dùng prompt bên dưới sắp xếp dữ liệu định lượng · định tính theo cấu trúc CER.
STEP 4 · Sửa thành v2 (35 phút)Chỉ sửa 1~2 chỗ gây kẹt nhiều nhất. Đừng cố sửa tất cả.
Prompt thực hành
Sản phẩm tuần nàyBáo cáo kiểm chứng (cấu trúc CER, có trực quan hóa dữ liệu) + nguyên mẫu v2
Điểm kiểm tra
  • Đã viết giả thuyết thành câu có thể bác bỏ
  • Đã cho từ 5 người trở lên thử mà không gợi ý
  • Đã gắn căn cứ dữ liệu cho từng luận điểm
  • Đã giới hạn chỗ cần sửa còn 1~2
PART 4 · Tuần 15 · Cuối kỳ

Capstone cuối cùng · Solution Pitch

Chứng minh vấn đề – lời giải – logic – kiểm chứng trong 8 phút
Mục tiêu học tậpGói quá trình giải quyết vấn đề của cả học kỳ thành một mạch logic để thuyết trình, và qua bình duyệt của bạn học, nêu rõ giới hạn của lời giải mình.
Slide lý thuyết (10 trang)
Bài nộp cuối cùng
Bài nộpCấu phầnDung lượng
Bản đặc tả logic giải quyếtĐịnh nghĩa vấn đề · cấu trúc nguyên nhân · phương án và chọn lựa · lưu đồ · xử lý ngoại lệ · thiết kế tự động hóa8~10 trang A4
Nguyên mẫuv2 chạy được (chọn 1 trong đường liên kết · ảnh chụp · video demo) + kịch bản sử dụng
Báo cáo kiểm chứngGiả thuyết · chỉ số · kết quả · 3 bộ CER · giới hạn3 trang A4
Bản bình duyệt của bạn họcÝ kiến rà soát của 2 bạn học + cái tôi đã tiếp thu / cái không tiếp thu và lý do2 trang A4
Phụ lụcToàn văn các prompt đã dùng, ghi chép các lần thử thất bạiKhông giới hạn
Cấu trúc thuyết trình (8 phút + 4 phút hỏi đáp)
1 phút · Vấn đềBắt đầu bằng một cảnh cụ thể. Thống kê để sau đó.
2 phút · Lời giải và căn cứ chọn lựaCho xem phương án đã bỏ trước thì phương án đã chọn mới thuyết phục.
2 phút · Chạy thử trực tiếpĐừng giải thích bằng lời, hãy chạy thật. Có hỏng cũng cứ để nguyên cho xem.
2 phút · Kết quả kiểm chứngNói trước giả thuyết có được ủng hộ hay không, rồi gắn dữ liệu căn cứ.
1 phút · Giới hạn và bước tiếp theoTự nêu ra điều kiện mà lời giải này không hiệu quả. Mục này nặng nhất trong đánh giá.
Prompt kết thúc
Bài nộpBản đặc tả logic giải quyết + nguyên mẫu + báo cáo kiểm chứng + bản bình duyệt của bạn học · Tỷ trọng đánh giá 40%
Điểm kiểm tra
  • Đã hoàn thành cả bốn bài nộp
  • Đã thực sự chạy thử trực tiếp khi thuyết trình
  • Đã nói rõ giả thuyết có được ủng hộ hay không
  • Đã tự nêu ra điều kiện mà lời giải không hiệu quả
  • Đã để lại các lần thử thất bại trong phụ lục

Trình tạo prompt cho dự án

Nhập thông tin dự án của bạn, hệ thống sẽ tạo ra chỉ dẫn có thể sao chép dùng ngay. Hãy điền vào chỗ trống, bấm 「Tạo prompt」, rồi dùng nút 「Sao chép」 ở hộp kết quả để dán vào AI. Chỉ dẫn được tạo ra bằng tiếng Anh (English) — để chất lượng phản hồi của AI luôn ổn định, prompt dùng chung tiếng Anh cho mọi ngôn ngữ.

Trình tạo phân rã vấn đề

Dùng cho tuần 1~3. Tạo chỉ dẫn chia vấn đề thành cấu trúc nguyên nhân và các đầu việc thực thi.
Chỉ dẫn đã tạo (English)

Trình tạo phát tán · chọn lời giải

Dùng cho tuần 5~7. Tạo chỉ dẫn mở rộng ý tưởng về số lượng và chọn ra phương án số 1 bằng ma trận có trọng số.
Chỉ dẫn đã tạo (English)

Trình tạo thiết kế kiểm chứng

Dùng cho tuần 13~14. Tạo chỉ dẫn đem nguyên mẫu thử với người thật để tạo ra căn cứ.
Chỉ dẫn đã tạo (English)
[1-1] Solvability diagnosis
R (Role): You are a project reviewer who cuts a one-semester project down to size without sentiment. T (Task): Diagnose my three candidate problems against the standard "can this be solved in one semester" and rank them. C (Context): · Candidate 1 : [2-line description] · Candidate 2 : [2-line description] · Candidate 3 : [2-line description] · Time I can spend : [○] hours per week / budget : [○ KRW] / people and data I can reach : [what] F (Format): A table [candidate / how closed the scope is (5 pts) / can success be judged (5 pts) / can it finish in time (5 pts) / total / what must be cut]. Below the table, ① the one you recommend with 3 lines of reasoning ② one restated sentence that shrinks that problem to "one semester" size. Do not be optimistic without grounds; if it looks impossible, say it is impossible.
[1-2] Success criteria statement
R (Role): You are an assessment designer who builds the standards for judging whether a project succeeded. T (Task): For the problem below, write success criteria at three levels in the form "if this is observed, we call it solved." C (Context): · The problem in one sentence : [who / when / because of what / loses what] · What I can measure : [whichever of time, count, cost, satisfaction I have] · What I cannot measure : [things I can only observe] F (Format): ① Minimum success (worth something even if only this happens) ② target success ③ beyond-target success. For each level, 3 lines on "what / how much / how you check." End by naming 2 traps in measuring against these criteria.
[2-1] Cause logic tree
R (Role): You are a consultant who breaks a problem's cause structure apart without overlap. T (Task): Expand the causes of the problem below into a logic tree, three levels deep. C (Context): · Problem (symptom) : [the observed fact as it is] · Frequency and situation : [when, how often] · What I already tried and why it failed : [if any] · What I can control : [e.g. myself, my team, system settings] F (Format): An indented tree. Level 1 has 4–5 branches, with levels 2 and 3 under each. If branches at the same level overlap, merge them and reorganize. Below the tree, a table [cause / impact (high·mid·low) / can I control it (yes·partly·no) / how to check]. Mark anything that is a guess as [hypothesis].
[2-2] 5 Whys interrogation
R (Role): You are an interrogator who does not accept an answer easily. T (Task): Ask "why?" five times about the symptom I give you and dig down to the cause. If my answer is thin, do not move on — push back. C (Context): · Symptom : [what happens] · My first explanation : [the reason I think it is] F (Format): Why 1 through 5 in order. At each step ① the question ② what your answer implies ③ where that inference could be wrong. Finish with 2 candidate structural causes that do not end at "it's a matter of attitude."
[3-1] Problem → executable tasks
R (Role): You are a project designer who cuts complex work into executable units. T (Task): Break what has to be done to solve the problem below into three levels: ① large chunks ② the tasks in each chunk ③ the prerequisite for each task. C (Context): · Problem to solve : [the strike point chosen in Week 2] · Success criteria : [Week 1 success criteria] · Constraints : time [○] hours per week / budget [○ KRW] / people [○] / what I can access [what] · What I already have : [materials, tools, relationships] F (Format): A table [task / output / estimated time / what it needs / prerequisite task]. Group into ten tasks or fewer, and cut each one to a size you can finish in 1–2 hours. Below the table, "the three things to do first" with reasons, and also "three things that can wait."
[3-2] Constraint squeeze test
R (Role): You are a doer who produces results with almost no resources. T (Task): Reorganize the task list below from the angle of "if I had half the time I have now, what would I keep and what would I drop?" C (Context): · Task list : [paste the result of 3-1] · What I absolutely cannot give up : [the one core success criterion] F (Format): ① 4 tasks to keep and why ② the tasks to drop and the grounds for dropping them ③ 2 risks created by dropping them and how to cover each. Do not answer "you can do both" — force a choice.
[4-1] Basic RTCF template
R (Role): You are a [job title] with [number] years in [field]. T (Task): [one thing you want done, stated as a verb] C (Context): · Background : [situation] · What I already know : [existing information] · Constraints : [deadline, format, what is off limits] · Who reads this : [audience and how much they already know] F (Format): [table/bullets/paragraphs] · length [○ lines] · tone [concise/formal/persuasive] Rules: ① Mark anything you are not sure of as "uncertain" ② Give the source alongside any figure or citation ③ Keep facts and your own inference in separate paragraphs
[4-2] Diagnose and improve my prompt
R (Role): You are a prompt engineer who diagnoses prompts and fixes them. T (Task): Diagnose my instruction below and write an improved version. C (Context): --- my instruction --- [paste here] --- what I expected --- [what I wanted] --- what disappointed me in the actual result --- [what fell short] F (Format): ① Diagnosis of what is missing (which of role, task, context, format is empty) ② the full improved version ③ 3 lines on what you changed and why. Put [bracketed] variables in the improved version so it is reusable. Five variables at most.
[5-1] SCAMPER seven-axis expansion
R (Role): You are an ideation facilitator who defers judgment and specializes in raising the sheer number of ideas. T (Task): Generate solutions to the problem below across the seven SCAMPER axes, 3 per axis, 21 in total. C (Context): · Problem to solve : [the Week 2 strike point] · Solutions so far : [the 8 I wrote by hand — do not duplicate these] · How it works now : [how this is handled today] · Where it is used : [who uses it, where, when] F (Format): A list grouped by axis. Each idea gets a one-line title plus a one-line description. The seven axes = Substitute / Combine / Adapt / Modify / Put to other use / Eliminate / Reverse. Rules: Do not evaluate feasibility at this stage. Do not repeat near-identical ideas; give each axis a different grain.
[5-2] Extreme-condition ideation
R (Role): You are someone who finds the solutions that only appear when resources are extremely limited. T (Task): Solve the problem below again under four extreme conditions. C (Context): · Problem : [the problem in one sentence] · Current candidate solutions : [the 3 leading ideas] F (Format): 2 ideas per condition. ① If the budget were zero ② if it had to be finished today ③ if no tools were allowed (people only) ④ if instead of removing the problem you made it bigger (reverse). Under each idea, one line on "what survives in reality once this condition is lifted."
[6-1] Defining the contradiction and separating it
R (Role): You are a TRIZ-based problem solver who breaks trade-offs without compromising. T (Task): Define the contradiction blocking me in the situation below, and build alternatives that eliminate it using the separation principles. C (Context): · What I want : [the A I want to gain] · The problem that comes with it : [the B I lose] · My current compromise : [how I am splitting the difference today] · Absolute condition : [what cannot be given up] F (Format): ① 2 contradiction statements (in the form "raise A and B gets worse") ② the ideal final result in one sentence (zero cost, zero side effects) ③ solutions per separation principle: separation in time / in space / by condition / whole-part, 2 each ④ a judgment on whether each solution actually removed the contradiction or merely postponed it Rule: Do not accept "strike a reasonable balance" compromises as answers.
[6-2] Forcing counterintuitive solutions
R (Role): You are a reverse-thinking strategist who looks for answers on the far side of common sense. T (Task): For the problem below, produce 5 solutions that "nobody would normally do," and find the condition under which each one works. C (Context): · Problem : [the problem in one sentence] · Received wisdom in this area : [3 things everyone does] F (Format): For each solution ① the counterintuitive idea ② why nobody normally does it ③ the condition under which it works anyway ④ can I create that condition (yes/no). Mark the ones where ④ is "yes" with a ★.
[7-1] Weighted evaluation matrix
R (Role): You are a decision analyst who scores alternatives against criteria without sentiment. T (Task): Score the candidates below against my criteria and weights, and rank them. C (Context): · Candidate list : [the ideas that passed the filter, one line each] · Criteria and weights : [e.g. impact 40% / feasibility 30% / cost 20% / urgency 10%] · Hard constraints (violation = out) : [within ○ KRW, ○ people, done within ○ weeks] · Success criteria : [the ones set in Week 1] F (Format): A table [candidate / score per criterion (5-point scale) / weighted total / passes hard constraints / reason for elimination]. Below the table, ① a summary of ranks 1–3 ② the 3 biggest weaknesses of the top idea ③ the conditions under which the runner-up should be chosen. Rule: Do not score generously. Mark any high score given without grounds as [insufficient grounds].
[7-2] Optimum under extreme constraints
R (Role): You are an execution designer who produces workable plans with almost no budget or people. T (Task): Scale the selected solution down into something executable under "zero budget · one person · two weeks." C (Context): · Selected solution : [the top-ranked idea] · Success criterion that must hold : [the one that matters] · Free tools and channels I can use : [what] F (Format): ① A 5-line outline of the reduced plan ② the features given up and why that is acceptable ③ a two-week schedule (by day) ④ how this reduced version can still test the success criterion.
[8-1] Self-review before submitting
R (Role): You are a demanding reviewer grading this assignment. You do not score generously. T (Task): Grade my solution concept specification below against the criteria and point out where it falls short. C (Context): --- my specification --- [paste the full text] --- grading criteria --- · Sophistication of the solution logic 40% (soundness of the decomposition, logical completeness, handling of exceptions) · Use and structuring of AI 30% (prompt design, reproducibility of the process) · Evidence and validation 30% (rationale for selection, fit of the data and cases) F (Format): A table [item / score (out of 100) / reason for deduction / how I can fix it now]. Below the table, ① the 5 questions I will certainly get in the presentation and the gist of good answers ② the 3 weakest sentences in this specification, quoted verbatim, with replacements.
[9-1] Procedure → flowchart (Mermaid)
R (Role): You are a process designer who turns working procedures into flowcharts. T (Task): Turn the procedure below into Mermaid flowchart code. C (Context): · What I am solving : [the problem in one sentence] · Procedure (as I wrote it) : 1) [step] 2) [step] ... · Points that need a decision : [in "if ~ then" form] · Points where it can fail : [what I know of] F (Format): ① A Mermaid code block (flowchart TD, decisions as diamonds {}, processes as rectangles []) ② Tag each node with its actor: [human]/[AI]/[automatic] ③ Below the code, a table [step / input / output / fallback on failure] ④ Point out 3 steps missing from my procedure Rule: Every decision node must have a "no" path. If one is missing, add it.
[9-2] Drawing the human–AI boundary
R (Role): You are an operations designer who decides how far to automate. T (Task): Sort each step below into work a person must do / work AI may do / work to fully automate, with reasons. C (Context): · Step list : [the steps from 9-1] · Damage if it goes wrong : [what happens when it fails] · Personal or sensitive data involved : [what, if any] F (Format): A table [step / owner (human·AI·automatic) / reason / size of the damage if wrong (high·mid·low) / when a person must check]. Below the table, the "steps that must never be automated" and 3 lines on why.
[10-1] Designing a prompt chain
R (Role): You are a workflow designer who splits one large task into a series of instructions. T (Task): Design the repetitive task below as a 4–6 stage prompt chain. For each stage, write the full instruction text I can paste and use as is. C (Context): · Repetitive task : [what I do every time] · What comes in as input : [form of the material] · Final deliverable : [what has to come out] · Quality bar : [what makes it good] F (Format): For each stage, [Stage N] purpose / role / input spec / output spec / full instruction text Make the last stage a "review and rebut" stage, with a role different from the earlier stages. Below the chain, a table [stage / where it can break / how to prevent it].
[10-2] AI agent architecture
R (Role): You are someone who designs structures that combine AI in several roles to handle one job. T (Task): Design an AI agent setup that achieves the goal below. Define each agent's role, input, output and stopping condition. C (Context): · Goal : [what I want handled automatically] · Where a person must check : [what] · Tools available : [search, documents, spreadsheets, etc.] · Damage on failure : [what] F (Format): ① An agent table [name / role / input / output / when it stops] ② the processing flow as a Mermaid flowchart ③ marks for where a person intervenes (HITL) ④ 3 ways this setup could run away and how to stop each.
[11-1] Setup text for a document-grounded assistant
R (Role): You are a project-specific assistant that answers only from the material I have uploaded. T (Task): For each of my questions, find the evidence in the uploaded material and answer with a citation. C (Context): · Project : [the problem in one sentence] · Material : [types and number of documents] · User : [who uses this assistant] F (Format): Every answer has ① a 3-line conclusion ② evidence (document name + the passage quoted) ③ anything not in the material marked [not in the material]. Absolute rules: ① Do not fill answers with knowledge from outside the uploaded material ② When documents conflict, show both sides and leave the judgment to the user ③ When you speculate, say [speculation] first
[11-2] Designing automation for a repetitive task
R (Role): You are a workflow automation designer who turns repetitive work into automated pipelines. T (Task): Turn the repetitive task below into an automation design in trigger–process–output form. C (Context): · Repetitive task : [what, how often] · Time it takes now : [○ min per run] · Where the input comes from : [email, form, file, message, etc.] · Where the result has to go : [document, spreadsheet, message, etc.] · Exceptions : [problems that come up now and then when doing it by hand] F (Format): ① A pipeline table [order / trigger or process / tool / input / output / on failure] ② expected time after automation and the saving ③ the steps that should not be automated, and why ④ 3 items to verify manually in parallel during the first week.
[12-1] Requesting a red team attack
R (Role): You are a red team determined to make this solution fail. No compliments. T (Task): Find the weaknesses in the solution below and attack them. Show how it actually breaks, as scenarios. C (Context): · Solution overview : [description of the solution] · Execution procedure : [flowchart summary] · What I am assuming : [things I have taken for granted] · Users : [who uses it] F (Format): 10 attacks, split into three groups. ① Breaks by mistake (bad input, misunderstanding) ② breaks on purpose (abuse, gaming it) ③ breaks under rare conditions (edge cases) For each attack, [situation → what happens → size of the damage (high·mid·low)]. Finish by naming the 3 "most dangerous assumptions in this solution." Skip the trivia; start with what is fatal.
[12-2] Exception design + ethics check
R (Role): You are a safety designer who designs a system's exception handling and its risks. T (Task): Build the defense for the attack list below, and check the ethical and personal-data risks. C (Context): · Attack list : [paste the result of 12-1] · Resources I have : [time, tools] · Data involved : [is there personal data in what this handles] F (Format): ① An exception scenario table [situation / how it is detected / response / when a person steps in / priority] ② split into fix now (3) / fix later / declare out of scope ③ an ethics table [who could be harmed / what harm / likelihood / mitigation / who is accountable] ④ 3 lines on the limits that must be stated when this solution is released.
[13-1] Fixing the MVP scope
R (Role): You are a product owner who cuts scope without mercy. T (Task): From the feature list below, keep only what is strictly necessary to test one success criterion and cut everything else. C (Context): · Solution : [description of the solution] · Success criterion to test : [only one] · Feature list : [everything I want to build] · Time available to build : [○ hours] · Tools available : [what] F (Format): ① 3 features or fewer to keep, with reasons ② the features to cut and the grounds ③ the risk of cutting them and a temporary workaround (including having a person handle it) ④ a judgment on whether this can be built in [○ hours]. Rule: Cut everything that is merely "nice to have." Every reason for keeping something must connect directly to the success criterion.
[13-2] Prototype build spec
R (Role): You are a maker who builds prototypes with no-code tools. T (Task): Write the build spec and the step-by-step build order for the MVP below. C (Context): · Features kept : [3 or fewer] · Usage flow : first screen → [core action] → [seeing the result] · Tools I will use : [documents, forms, spreadsheets, AI chatbots — whatever I can actually use] · User skill level : [how comfortable with technology] F (Format): ① A list of screens and components [screen / component / what the user does / how the system responds] ② a data table [field / type / required / example value] ③ the build order (split into steps of 30 minutes or less) ④ marks on the parts a person can handle behind the scenes ⑤ a demo script (from first screen to result in 60 seconds).
[14-1] Validation design (hypothesis, metrics, scenario)
R (Role): You are a user validation designer who pulls meaningful conclusions out of small samples. T (Task): Build the validation design for testing the prototype below with 5 people. C (Context): · Prototype : [what it does] · Success criterion to test : [the Week 1 criterion] · Participants : [who, how many, in what setting] · Time required : [○ min] per person F (Format): ① One falsifiable hypothesis ("if ~, then ~ changes by ~") ② a metrics table [metric / how it is measured / threshold for success / quantitative or qualitative] ③ the session script (including what you say, worded so it never hints) ④ an observation sheet [step / time taken / where they got stuck / what the user said / observer notes] ⑤ 3 biases this design could introduce and how to reduce each.
[14-2] Results → CER report
R (Role): You are an analyst who interprets data without overstating it. T (Task): Turn the test results below into a validation report in claim-evidence-reasoning (CER) form. C (Context): · Hypothesis : [the falsifiable sentence] · Quantitative data : [completion rate, time taken, error count, etc.] · Qualitative data : [observation notes, quotes from users] · Number and makeup of participants : [○ people, who] F (Format): ① A 3-line conclusion (state one of: hypothesis supported / partly supported / rejected) ② 3 CER sets: claim → evidence (cite the data) → reasoning (why the data supports it) ③ a table [problem point / how many hit it / severity / proposed fix / fix it now or not] ④ 3 things these results cannot tell us (limits of sample and setting) ⑤ pick only 1–2 things to fix in the next version, with reasons. Rule: Do not generalize from 5 people. Do not use the phrase "most users."
[15-1] Structuring and rehearsing the final talk
R (Role): You are a presentation coach who structures an 8-minute talk and draws out the likely questions. T (Task): Build an 8-minute script and a list of likely questions from the material below. C (Context): · Problem : [one sentence] · Solution and rationale : [summary] · Validation results : [whether the hypothesis held, and the key figures] · Limits : [what I know of] · Audience : [professor and fellow students] F (Format): ① A script with the time split marked (1 min · 2 min · 2 min · 2 min · 1 min) ② a proposed 8-slide structure [slide / title / what goes on it / what to leave off] ③ 10 likely questions and the gist of the answers ④ the 3 sentences in my talk most open to attack, with replacements. Rule: Flag any wording that overstates the results and replace it with fact-based wording.
[15-2] Writing the peer review
R (Role): You are a reviewer who reviews a peer's project constructively but accurately. T (Task): Write a review of the peer project below. C (Context): · Their problem and solution : [summary] · Their validation results : [summary] · What impressed me in the talk : [what] · What I did not follow : [what] F (Format): ① 2 things done well (with specific evidence) ② 3 places where the logic is weak, and why ③ 1 thing I would have done differently in their position ④ 3 questions worth checking. Rule: No comments on the person or their attitude — write only about the deliverable and the logic. A review that only praises will be sent back.
R (Role): You are a project designer who splits complex problems into a cause structure and executable tasks. T (Task): Break the problem below into three stages: ① a cause logic tree (3 levels) ② selection of the strike point ③ a task table. C (Context): · Problem to solve : {{prob}} · Success criterion : {{goal}} (checked by: {{meas}}) · Constraints : {{time}} per week / {{res}} · What I already have : {{have}} F (Format): ① Cause logic tree — indented, 4–5 branches at level 1, down to level 3. Merge branches that overlap at the same level. ② Strike point table [cause / impact (high·mid·low) / can I control it / how to check] → recommend the 1–2 to hit this semester, with reasons. ③ Task table [task / output / estimated time / what it needs / prerequisite task] — 10 or fewer, each sized at 1–2 hours. ④ The 3 things to do first / the 3 things that can wait. Rules: · Mark anything that is a guess as [hypothesis] · Do not end a cause at "it's a matter of attitude" — find the structural cause · Do not propose tasks that exceed the constraints above
R (Role): You are an ideation facilitator who defers judgment and raises the number of ideas. T (Task): Generate solutions to the cause below across the seven SCAMPER axes (substitute, combine, adapt, modify, put to other use, eliminate, reverse), 3 per axis, 21 in total. Do not evaluate feasibility at this stage. C (Context): · Cause I am striking : {{target}} · How it works now : {{now}} · Criteria and weights : {{crit}} · Hard constraints (violation = out) : {{hard}} F (Format): ① Idea list — one-line title plus one-line description, grouped by axis ② hard-constraint filter results [candidate / passes / reason for elimination] ③ weighted evaluation matrix [candidate / 5-point score per criterion / weighted total / rank] ④ the 3 biggest weaknesses of the top idea, and the conditions under which the runner-up should be chosen Rules: · Do not repeat near-identical ideas; give each axis a different grain · Do not score generously; mark any high score without grounds as [insufficient grounds] · Do not answer "you can do both" — make a choice
R (Role): You are someone who finds the solutions that only appear when resources are extremely limited. T (Task): Solve the problem below again under four extreme conditions, 2 ideas each. ① Zero budget ② finished today ③ no tools, people only ④ reversal (what if you made the problem bigger instead). C (Context): · Cause I am striking : {{target}} · How it works now : {{now}} · Criteria and weights : {{crit}} · Hard constraints (violation = out) : {{hard}} F (Format): ① Ideas by condition — one-line title plus one-line description, 2 per condition ② under each idea, one line on "what survives in reality once this condition is lifted" ③ hard-constraint filter results [candidate / passes / reason for elimination] ④ weighted evaluation matrix [candidate / 5-point score per criterion / weighted total / rank] and the 3 biggest weaknesses of the top idea Rules: · Do not repeat near-identical ideas · Do not score generously; mark any high score without grounds as [insufficient grounds] · Do not answer "you can do both" — make a choice
R (Role): You are a TRIZ-based problem solver who breaks trade-offs without compromising. T (Task): Define the contradiction blocking the situation below in two sentences, and build 2 solutions each using separation in time, space, condition, and whole-part. Do not accept a compromise as an answer. C (Context): · Cause I am striking : {{target}} · How it works now : {{now}} · Criteria and weights : {{crit}} · Hard constraints (violation = out) : {{hard}} F (Format): ① 2 contradiction statements (in the form "raise A and B gets worse") and the ideal final result in one sentence ② solutions per separation principle — time / space / condition / whole-part, 2 each ③ a judgment on whether each solution actually removed the contradiction or merely postponed it ④ weighted evaluation matrix [candidate / 5-point score per criterion / weighted total / rank] and the 3 biggest weaknesses of the top idea Rules: · Do not accept "strike a reasonable balance" compromises as answers · Do not score generously; mark any high score without grounds as [insufficient grounds] · Eliminate any idea that fails a hard constraint, regardless of its score
R (Role): You are a decision analyst who scores alternatives against criteria without sentiment. T (Task): Score the candidates below against my criteria and weights and rank them. Eliminate any idea that fails a hard constraint, regardless of its score. C (Context): · Cause I am striking : {{target}} · How it works now : {{now}} · Criteria and weights : {{crit}} · Hard constraints (violation = out) : {{hard}} · Candidate list : [paste my ideas here, one line each] F (Format): ① Hard-constraint filter results [candidate / passes / reason for elimination] ② weighted evaluation matrix [candidate / 5-point score per criterion / weighted total / rank] ③ the 3 biggest weaknesses of the top idea, and the conditions under which the runner-up should be chosen ④ a list of the items in this scoring that lacked grounds Rules: · Do not score generously; mark any high score without grounds as [insufficient grounds] · Do not answer "you can do both" — make a choice
R (Role): You are a user validation designer who pulls meaningful conclusions out of small samples. T (Task): Build the full validation design for testing the prototype below with real users. C (Context): · What the prototype does : {{proto}} · Success criterion to test : {{goal}} · Participants : {{user}} · Test time per person : {{min}} · What can be measured : {{metric}} F (Format): ① One falsifiable hypothesis ("if ~, then ~ changes by ~") ② metrics table [metric / how it is measured / threshold for success / quantitative or qualitative] ③ session script — including wording that never hints ④ observation sheet [step / time taken / where they got stuck / what the user said / notes] ⑤ a CER frame for writing up the results (3 claim-evidence-reasoning sets) ⑥ 3 biases in this design and how to reduce each Rules: · The sample is small, so do not generalize the results · Do not use phrases like "most users" · Include how to interpret the outcome if the hypothesis is rejected
PART 1 · 1주차

문제 해결이란 무엇인가

AI는 마법 지팡이가 아니다 — 해결 가능한 문제를 고르는 눈
PBLⅠ · AI Problem Solving
오늘의 질문
“지금 불편한 그 문제,
한 학기 안에 풀 수 있는 문제입니까?”
대답이 “모르겠다”라면, 아직 문제가 아니라 감정입니다.
핵심 개념 1

문제란 간격이다

문제 = 지금의 상태와 바라는 상태 사이의 간격. 해결 = 그 간격을 좁히는 실행.

정의

두 상태를 모두 말할 수 없으면 문제를 정의한 것이 아닙니다.

예시

“공지를 놓친다”(지금) → “가입 당일 일정을 받는다”(바람).

흔한 오해

불평은 문제가 아닙니다. 바라는 상태가 없기 때문입니다.

주의

해결책을 문제로 위장하지 마십시오. “앱이 없다”는 문제가 아닙니다.

핵심 개념 2

해결 가능한 문제의 세 조건

① 범위가 닫힌다

누가, 어디서, 언제의 문제인지 경계를 그을 수 있다.

② 판정 기준이 있다

무엇이 관찰되면 해결된 것인지 미리 말할 수 있다.

③ 기간 안에 확인된다

15주 안에 결과를 한 번은 볼 수 있다.

세 조건 중 하나라도 비면 문제를 줄이십시오. “청년 실업”은 문제가 아니라 주제입니다.
핵심 개념 3

AI가 하는 일과 하지 못하는 일

AI가 잘하는 것

분해를 돕고, 대안을 늘리고, 초안을 쓰고, 내 논리를 공격해 줍니다.

사람만 하는 것

무엇을 해결할지 정하기 · 가치를 판단하기 · 결과에 책임지기.

AI는 답을 만드는 기계가 아니라, 내 질문의 해상도를 비추는 거울입니다.
핵심 개념 4

컴퓨팅 사고 3단계

분해큰 덩어리를 실행 가능한 조각으로 자른다
패턴인식반복되는 구조와 이미 풀린 사례를 찾는다
추상화본질만 남기고 나머지를 버린다
이 세 단어가 남은 14주의 뼈대입니다. 코드는 쓰지 않지만 사고는 프로그래머처럼 합니다.
전체 지도

이 과목이 지나가는 길

1–4주문제를 해부한다
5–8주해법을 넓히고 좁힌다
9–12주로직으로 옮긴다
13–15주만들고 검증한다
앞 과목이 “무엇이 문제인가”였다면, 이 과목은 “그래서 어떻게 할 것인가”입니다.
사례

같은 불편, 세 개의 다른 문제

“시험 기간에 도서관에 자리가 없다” — 어떻게 정의하느냐가 해결 경로를 정합니다.
공급 문제좌석이 부족하다 → 공간을 늘린다 (내 통제 밖, 학기 내 불가) 배분 문제빈자리 정보가 없다 → 실시간 표시 (통제 가능, 확인 가능) 행동 문제짐만 두고 비운다 → 점유 규칙 설계 (통제 가능, 측정 가능)
같은 현상에서 내가 손댈 수 있는 정의를 고르는 것이 1주차의 전부입니다.
오늘 만드는 것

문제 한 문장 + 성공 기준 3층위

누가 / 언제 / 무엇 때문에 / 어떤 손해를 보는가
  • 최소 성공 — 이것만 되어도 의미가 있다
  • 목표 성공 — 학기말에 달성하려는 수준
  • 초과 성공 — 여기까지 가면 기대 이상이다
각 층위는 “무엇을 / 얼마나 / 어떻게 확인”까지 적어야 완성입니다.
정리

오늘의 세 문장

  • 문제는 간격이다. 두 상태를 말할 수 없으면 아직 문제가 아니다.
  • 해결 가능한 문제는 범위·판정·기간 세 조건을 통과한다.
  • 무엇을 풀지 정하는 일은 끝까지 사람의 몫이다.
다음 주 현상과 원인을 분리합니다. 증상을 치료하면 문제는 반드시 되돌아옵니다.
PART 1 · WEEK 1

What Problem Solving Is

AI is not a magic wand — learning to pick a problem you can actually solve
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“That thing bothering you —
can it be solved in one semester?”
If the answer is “I don't know”, it isn't a problem yet. It's a feeling.
KEY CONCEPT 1

A problem is a gap

Problem = the gap between the current state and the wanted state. Solving = the work that closes it.

Definition

If you can't state both states, you haven't defined a problem.

Example

“I miss announcements” (now) → “I get the schedule on day one” (wanted).

Common mistake

A complaint is not a problem — it names no wanted state.

Watch out

Don't disguise a solution as a problem. “There's no app” is not a problem.

KEY CONCEPT 2

Three conditions for a solvable problem

① Closed scope

You can draw a boundary: whose problem, where, and when.

② A test exists

You can say in advance what would count as solved.

③ Visible in time

You can see a result at least once within 15 weeks.

If any condition is empty, shrink the problem. “Youth unemployment” is a topic, not a problem.
KEY CONCEPT 3

What AI does — and what it can't

AI is good at

Helping you decompose, multiplying options, drafting, and attacking your own logic.

Only people do

Deciding what to solve · judging what matters · carrying the consequences.

AI is not a machine that makes answers. It is a mirror that shows the resolution of your question.
KEY CONCEPT 4

Computational thinking, three moves

Decomposecut the lump into executable pieces
Find patternsspot what repeats and what is already solved
Abstractkeep the essence, drop the rest
These three words are the skeleton of the remaining 14 weeks. You write no code, but you think like a programmer.
THE MAP

Where this course goes

Weeks 1–4dissect the problem
Weeks 5–8widen then narrow the options
Weeks 9–12turn it into logic
Weeks 13–15build it and test it
The previous course asked “what is the problem?”. This one asks “so what will you do about it?”
CASE

One complaint, three different problems

“There are no free seats in the library during exams” — how you define it decides your whole path.
SupplyNot enough seats → add space (outside your control, not doable this term) AllocationNo information about free seats → live status (controllable, testable) BehaviourPeople leave bags and vanish → occupancy rule (controllable, measurable)
Choosing the definition you can act on is the whole job of week 1.
WHAT YOU MAKE TODAY

One-sentence problem + three tiers of success

who / when / because of what / suffers what harm
  • Minimum success — this alone would already be worth it
  • Target success — what you aim to reach by week 15
  • Stretch success — beyond expectations if you get here
A tier is finished only when it states what, how much, and how you will check it.
WRAP-UP

Three sentences from today

  • A problem is a gap. If you can't state both states, it isn't one yet.
  • A solvable problem passes three tests: scope, judgement, time.
  • Deciding what to solve stays a human job, all the way through.
Next week we separate symptoms from causes. Treat the symptom and the problem always comes back.
PART 1 · 2주차

현상과 원인 분리하기

5 Whys와 로직트리로 증상이 아닌 뿌리를 치기
PBLⅠ · AI Problem Solving
오늘의 질문
“고쳤다고 생각한 그 문제,
왜 한 달 뒤에 그대로 돌아옵니까?”
증상을 치료했기 때문입니다. 구조는 그대로 남아 있습니다.
핵심 개념 1

증상과 원인은 다른 것이다

증상은 눈에 보이는 사실이고, 원인은 그 사실을 반복해 만들어 내는 구조입니다.

증상

관찰한 그대로 적을 수 있습니다. “신청자가 정원의 20%다.”

원인

보이지 않습니다. 증상을 계속 만들어 내는 조건과 흐름입니다.

흔한 오해

“홍보가 부족하다”는 원인이 아니라 또 하나의 증상입니다.

주의

원인 자리에 사람의 태도를 적으면 사고가 거기서 멈춥니다.

핵심 개념 2

5 Whys를 제대로 쓰는 법

① 사실에서 출발

추측이 아니라 실제로 관찰한 증상 하나를 고릅니다.

② 막히는 곳을 지나기

대개 세 번째 왜부터 말문이 막힙니다. 거기가 뿌리 근처입니다.

③ 구조에서 멈추기

답이 규칙·정보 흐름·설계에 닿으면 그때 멈춥니다.

“학생들이 게을러서”로 끝났다면 실패입니다. 태도는 원인이 아니라 결과입니다.
핵심 개념 3

나열과 트리는 다르다

로직트리

원인을 층으로 나눕니다. 위 가지는 아래 가지들의 합으로 설명됩니다.

그냥 나열

순서 없는 목록은 무엇을 먼저 쳐야 하는지 알려 주지 않습니다.

겹치지 않게, 빠짐없이 — 이 두 마디가 MECE의 전부입니다.
핵심 개념 4

오늘의 작업 3단계

증상 확정사실만 여섯 개, 해석은 뺀다
원인 전개왜를 반복해 3단 이상 가지로 펼친다
지점 선택영향도 × 통제가능성으로 하나를 고른다
순서를 뒤집지 마십시오. 원인을 모른 채 고른 해법은 증상 처방이 됩니다.
전체 지도

이번 주가 놓인 자리

1주차문제를 한 문장으로 정의했다
2주차그 문제의 원인 구조를 그린다
3주차고른 원인을 작업으로 자른다
4주차그 작업을 AI에게 정확히 시킨다
오늘 고르는 공격 지점이 3주차 분해의 출발점입니다. 여기가 틀리면 뒤가 전부 흔들립니다.
사례

왜를 다섯 번 물었더니

“학과 행사 신청자가 정원의 20%에 그친다” — 같은 증상에서 시작했습니다.
증상마감일까지 정원 40석 중 8석만 찼다 세 번째 왜학생이 공지를 본 시점에 이미 신청이 끝나 있다 다섯 번째 왜공지는 게시판, 확인은 단톡 — 채널이 어긋나 있다
공격 지점은 채널 불일치입니다. 홍보를 늘리는 처방과는 완전히 다른 일이 됩니다.
오늘 만드는 것

원인 로직트리 + 공격 지점

3단 이상 전개한 원인 로직트리 + 공격 지점 1~2개 표시본
  • 1단 — 관찰한 증상 하나를 맨 위에 놓는다
  • 2~3단 — 왜를 물어 가지를 펼치고 겹친 가지를 지운다
  • 표시 — 영향이 크고 내가 손댈 수 있는 지점에 표시한다
가지가 사람의 태도에서 멈췄다면 아직 3단이 아닙니다. 한 층 더 내려가십시오.
정리

오늘의 세 문장

  • 증상을 고치면 문제는 되돌아옵니다. 구조를 고쳐야 멈춥니다.
  • 세 번째 왜부터가 진짜입니다. 답이 막히는 곳을 지나가십시오.
  • 원인을 다 칠 수는 없습니다. 하나를 골라야 학기가 굴러갑니다.
다음 주 고른 원인을 1~2시간짜리 작업으로 자릅니다. 큰 덩어리는 실행되지 않습니다.
PART 1 · WEEK 2

Separating Symptom from Cause

Hitting the root instead of the symptom, with 5 Whys and a logic tree
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“That problem you thought you fixed —
why is it back a month later?”
Because you treated the symptom. The structure that made it is still there.
KEY CONCEPT 1

A symptom is not a cause

A symptom is a visible fact. A cause is the structure that keeps producing that fact.

Symptom

You can write it down as observed: “only 20% of the seats get booked.”

Cause

Invisible. The condition or flow that produces the symptom again and again.

Common mistake

“We didn't promote it enough” is not a cause. It is another symptom.

Watch out

Write an attitude in the cause slot and your thinking stops right there.

KEY CONCEPT 2

How to run 5 Whys properly

① Start from a fact

Pick one symptom you actually observed, not one you assume.

② Push past the stall

Answers usually stall at the third why. That is where the root sits.

③ Stop at structure

Stop when the answer lands on a rule, an information flow, or a design.

If you end at “people are lazy,” you failed. Attitude is not a cause. It is a result.
KEY CONCEPT 3

A list is not a tree

Logic tree

Causes sit in levels. A branch above is explained by the branches under it.

Plain list

An unordered list never tells you which cause to strike first.

No overlaps, no gaps — that is the whole of MECE.
KEY CONCEPT 4

Today's work, three moves

Fix symptomssix plain facts, no interpretation
Spread causesask why until the tree is three levels deep
Pick the pointchoose one on impact × controllability
Do not reverse the order. A solution chosen before the cause is known is a symptom prescription.
THE MAP

Where this week sits

Week 1defined the problem in one sentence
Week 2draw the cause structure behind it
Week 3cut the chosen cause into tasks
Week 4hand those tasks to AI precisely
The strike point you choose today is the starting line for week 3. Get it wrong and everything after shakes.
CASE

What five whys turned up

“Only 20% of the seats at our department event get booked” — one symptom, dug down.
SymptomBy the deadline, 8 of 40 seats were taken Third whyBy the time students see the notice, booking has closed Fifth whyNotices go on the board; students check the group chat
The strike point is the channel mismatch — an entirely different job from promoting harder.
WHAT YOU MAKE TODAY

Cause logic tree + strike point

A logic tree three levels deep + a copy with 1–2 strike points marked
  • Level 1 — put one observed symptom at the top
  • Levels 2–3 — ask why, spread branches, delete the overlaps
  • Mark — circle what has large impact and you can touch
If a branch ends at someone's attitude, you are not three levels deep yet. Go one further.
WRAP-UP

Three sentences from today

  • Fix a symptom and it comes back. Only fixing structure stops it.
  • The real answers start at the third why. Push past where it stalls.
  • You cannot strike every cause. Pick one or the semester stalls.
Next week we cut that cause into one- to two-hour tasks. A lump never gets done.
PART 1 · 3주차

문제 분해 (Decomposition)

해결 불가능해 보이는 덩어리를 1~2시간짜리 작업으로 자르기
PBLⅠ · AI Problem Solving
오늘의 질문
“그 문제, 내일 오후 두 시에
정확히 무엇을 하면 됩니까?”
대답이 나오지 않으면 아직 문제가 아니라 덩어리입니다.
핵심 개념 1

분해란 실행 단위로 자르는 일

분해 = 문제를 한 번 앉아서 끝낼 수 있는 작업들로 바꾸는 일입니다.

적정 크기

1~2시간. 앉은 자리에서 끝나고 결과가 남는 크기입니다.

산출

작업마다 손에 남는 것이 있어야 합니다. 표 하나, 목록 하나.

너무 크면

두 시간을 넘는 작업은 시작 자체가 계속 미뤄집니다.

너무 작으면

15분짜리를 늘어놓으면 관리하는 일이 더 커집니다.

핵심 개념 2

좋은 작업의 세 조건

① 시작 조건이 있다

무엇이 끝나야 이것을 시작할 수 있는지 적혀 있습니다.

② 끝이 보인다

무엇이 나오면 끝인지 한 줄로 말할 수 있습니다.

③ 혼자 착수한다

남의 허락을 기다리지 않고 오늘 시작할 수 있습니다.

셋 중 하나라도 비어 있으면 그것은 작업이 아니라 아직 계획입니다. 다시 자르십시오.
핵심 개념 3

추상화 수준을 맞춘다

층위가 같다

“설문 문항 10개 쓰기”와 “설문 링크 배포하기”는 크기가 같습니다.

층위가 섞였다

“조사한다”와 “링크 만들기”가 한 목록에 있으면 진행이 멈춥니다.

목록에서 가장 큰 항목과 가장 작은 항목의 크기 차이가 곧 계획의 오차입니다.
핵심 개념 4

오늘의 작업 3단계

제약 확정시간·돈·사람·데이터를 숫자로 적는다
분해와 삭제목록을 펼친 뒤 필요 없는 줄을 지운다
순서 확정선행조건을 연결해 첫 3개를 정한다
제약을 먼저 적으십시오. 제약이 없는 분해는 작업표가 아니라 희망 목록이 됩니다.
전체 지도

이번 주가 놓인 자리

1주차문제를 한 문장으로 정했다
2주차칠 원인 하나를 골랐다
3주차그 원인을 작업표로 자른다
4주차각 작업을 AI에게 지시한다
작업표는 이번 주로 끝나지 않습니다. 남은 12주 동안 계속 보는 기준표입니다.
사례

덩어리를 작업으로 자르면

“공지 채널이 어긋나 있다” — 학기짜리 덩어리에서 잘라낸 첫 세 작업입니다.
작업 1 (1시간)지금 쓰는 공지 경로 3개를 그림 한 장으로 정리한다 작업 2 (2시간)신입 회원 8명에게 실제 확인 경로를 묻는다 작업 3 (1.5시간)단일 공지 양식 초안 한 장을 쓴다
선행조건은 1 → 2 → 3입니다. 작업 2의 결과가 없으면 작업 3은 추측이 됩니다.
오늘 만드는 것

실행 작업표 10개 이하

작업 / 산출 / 소요 시간 / 선행조건 — 네 칸을 모두 채운 표
  • 작업 — 동사로 시작하는 한 줄
  • 산출 — 끝났을 때 손에 남는 물건
  • 선행조건 — 이보다 먼저 끝나야 하는 작업 번호
표를 다 채운 뒤, 가장 먼저 할 3개에 표시하십시오. 다음 주는 거기서 시작합니다.
정리

오늘의 세 문장

  • 실행되는 크기는 1~2시간입니다. 더 크면 반드시 미룹니다.
  • 목록의 층위가 섞이면 진행은 그 자리에서 멈춥니다.
  • 제약을 숫자로 적을 때 해법은 비로소 구체적이 됩니다.
다음 주 이 작업들을 AI에게 시킵니다. 지시가 흐리면 결과도 흐립니다.
PART 1 · WEEK 3

Decomposition

Cutting an unsolvable-looking lump into one- to two-hour tasks
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Your problem — what exactly
do you do at two o'clock tomorrow?”
If no answer comes, you don't have a problem yet. You have a lump.
KEY CONCEPT 1

Decomposition cuts to executable size

Decomposition = turning a problem into tasks you can finish in one sitting.

Right size

One to two hours. It ends where you sat down, and it leaves something.

Output

Every task must leave something in your hands: one table, one list.

Too big

Anything over two hours never gets started. You postpone it.

Too small

Line up fifteen-minute items and tracking them costs more than doing them.

KEY CONCEPT 2

Three conditions for a good task

① It has a start

You wrote down what must finish before this one can begin.

② The end is visible

You can say in one line what has to exist for it to be done.

③ You can start alone

You can begin today without waiting for anyone's permission.

If any of the three is empty, it is not a task yet — it is a plan. Cut it again.
KEY CONCEPT 3

Match the level of abstraction

Same level

“Write 10 survey questions” and “send out the survey link” are the same size.

Mixed levels

Put “do research” next to “make the link” and progress stops there.

The gap between your largest and smallest item is the error margin of your plan.
KEY CONCEPT 4

Today's work, three moves

Fix constraintswrite time, money, people, data as numbers
Split and deletespread the list, then cut the lines you don't need
Fix the orderchain prerequisites and mark the first three
Write the constraints first. Without them a decomposition is not a task table but a wish list.
THE MAP

Where this week sits

Week 1fixed the problem in one sentence
Week 2picked one cause to strike
Week 3cut that cause into a task table
Week 4hand each task to AI as an instruction
The task table does not end this week. It is the reference you keep reading for 12 more weeks.
CASE

A lump, cut into tasks

“Our notice channels don't match” — here are the first three tasks cut out of it.
Task 1 (1 hr)Draw the three notice routes we use today on one page Task 2 (2 hrs)Ask 8 new members where they actually check for news Task 3 (1.5 hrs)Draft one single notice format, one page
Prerequisites run 1 → 2 → 3. Without the result of task 2, task 3 is a guess.
WHAT YOU MAKE TODAY

A task table of ten or fewer

task / output / time / prerequisite — all four columns filled
  • Task — one line that starts with a verb
  • Output — the thing left in your hands when it ends
  • Prerequisite — the number of the task that must finish first
Once the table is full, mark the three you do first. Next week starts from there.
WRAP-UP

Three sentences from today

  • The size that actually gets done is one to two hours. Bigger, and you postpone.
  • Mix levels in one list and progress stops on the spot.
  • Solutions get concrete only when constraints are written as numbers.
Next week we hand these tasks to AI. A vague instruction returns a vague result.
PART 1 · 4주차

효과적인 AI 소통 · RTCF

역할·작업·맥락·형식 4요소로 지시문 구조화하기
PBLⅠ · AI Problem Solving
오늘의 질문
“같은 AI에게 물었는데
왜 누구는 쓸 만한 답을 받습니까?”
질문의 재능이 아니라 지시문 구조의 차이입니다.
핵심 개념 1

프롬프트는 질문이 아니라 지시서다

AI의 답은 내가 준 정보의 함수입니다. 답이 흐리면 지시가 흐린 것입니다.

정의

프롬프트는 사람에게 일을 맡길 때 쓰는 작업 지시서와 같습니다.

예시

“홍보 알려줘” 대신 “신입생 200명에게 3일 안에 알릴 방법 5개”.

흔한 오해

짧게 물으면 알아서 채워 준다 — 채우는 것은 사실이 아니라 추측입니다.

주의

AI는 모르는 것도 자신 있게 씁니다. 확인은 끝까지 사람의 몫입니다.

핵심 개념 2

RTCF · 먼저 세 요소

R · 역할

누구로서 답할지 지정합니다. 전문성의 층위가 여기서 정해집니다.

T · 작업

동사 하나로 정확히. 한 프롬프트에는 작업 하나만 넣습니다.

F · 형식

표·불릿·줄 수·톤. 받은 뒤 다시 손보는 시간을 없앱니다.

남은 한 글자 C(맥락)가 답의 품질을 가장 크게 바꿉니다. 다음 장에서 따로 봅니다.
핵심 개념 3

C · 맥락이 결과를 가른다

맥락을 준 지시

대상·제약·이미 아는 것 세 줄. 답이 내 상황으로 좁혀집니다.

맥락 없는 지시

교과서 요약이 돌아옵니다. 누구에게나 맞는 답은 나에게 맞지 않습니다.

맥락 세 줄이 답변 세 페이지의 값어치를 바꿉니다.
핵심 개념 4

오늘의 작업 3단계

막 던지기평소처럼 묻고 결과를 저장한다
4요소 보강R·T·C·F를 채워 같은 질문을 다시 쓴다
템플릿 고정반복되는 형태를 변수 5개로 저장한다
좋은 지시문은 한 번에 나오지 않습니다. 언제나 고쳐 쓰기의 결과입니다.
전체 지도

이번 주가 놓인 자리

1~3주차문제와 작업표를 손으로 만들었다
4주차AI에게 정확히 시키는 법을 익힌다
5~8주차이 템플릿으로 해법을 넓히고 좁힌다
9~15주차같은 방식으로 만들고 검증한다
RTCF는 이번 주로 끝나는 개념이 아니라, 남은 11주 내내 쓰는 공구입니다.
사례

같은 요구, 두 개의 지시문

“동아리 공지 채널을 하나로 합치는 안을 찾고 싶다” — 결과가 이렇게 갈립니다.
막 던진 지시“동아리 공지 잘하는 법 알려줘” → 일반론 열 줄 RTCF 지시역할·작업·맥락 3줄·표 형식 지정 → 비교표 다섯 행 달라진 것우리 제약이 반영되고, 바로 쓸 형태로 돌아왔다
바뀐 것은 AI가 아니라 입력입니다. 차이의 대부분은 맥락에서 옵니다.
오늘 만드는 것

재사용 RTCF 템플릿 3종

조사용 · 분석용 · 작성용 — 변수 5개 이내로 고정한 템플릿
  • 조사용 — 무엇을 모으고 어떤 표로 정리할지 지정한다
  • 분석용 — 판단 기준과 비교 축을 미리 준다
  • 작성용 — 독자·분량·톤을 고정한다
모든 템플릿 하단에 환각 방지 3규칙을 고정하십시오 — 모르면 모른다 / 출처 요구 / 사실과 추론 분리.
정리

오늘의 세 문장

  • 답의 품질은 재능이 아니라 지시의 구조에서 옵니다.
  • 네 요소 중 맥락(C)이 답을 가장 크게 바꿉니다. 세 줄 이상 쓰십시오.
  • 잘 쓴 지시문은 버리지 말고 템플릿으로 남기십시오.
다음 주 SCAMPER 7축으로 해법을 30안까지 넓힙니다. 먼저 양으로 이깁니다.
PART 1 · WEEK 4

Talking to AI Effectively · RTCF

Structuring instructions with four elements: role, task, context, format
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Same AI, same question —
why does someone else get a usable answer?”
It isn't a talent for asking. It's the structure of the instruction.
KEY CONCEPT 1

A prompt is an instruction, not a question

The answer is a function of what you gave it. A vague answer means a vague instruction.

Definition

Write it the way you would brief a person you are handing work to.

Example

Not “tell me about promotion” but “5 ways to reach 200 freshmen in 3 days”.

Common mistake

Ask short and it fills the rest in — but it fills it with guesses, not facts.

Watch out

AI states what it does not know with full confidence. Checking stays your job.

KEY CONCEPT 2

RTCF · the first three elements

R · Role

Specify who is answering. That is what sets the level of expertise.

T · Task

One precise verb. One prompt carries exactly one task.

F · Format

Table, bullets, line count, tone. This is what removes the rework.

The remaining letter, C (context), moves quality more than the rest. We take it on its own next.
KEY CONCEPT 3

C · context decides the result

With context

Three lines: who it is for, the constraints, what you already know.

Without context

You get a textbook summary. An answer that fits anyone fits nobody.

Three lines of context change what three pages of answer are worth.
KEY CONCEPT 4

Today's work, three moves

Just askask as you normally would, save the result
Add the fourrewrite the same question with R, T, C, F
Freeze a templatesave the shape with five variables or fewer
A good instruction never arrives on the first try. It is always the result of rewriting.
THE MAP

Where this week sits

Weeks 1–3built the problem and task table by hand
Week 4learn to instruct AI precisely
Weeks 5–8use these templates to widen and narrow
Weeks 9–15build and test the same way
RTCF does not end this week. It is the tool you keep in hand for the remaining 11 weeks.
CASE

One need, two instructions

“I want options for merging our club's notice channels” — the results split like this.
Just asked“How do clubs do announcements well?” → ten generic lines RTCF versionRole, task, 3 lines of context, table format → a 5-row table What changedOur constraints show up, and it arrives ready to use
The AI did not change. The input did. Most of the difference comes from context.
WHAT YOU MAKE TODAY

Three reusable RTCF templates

research · analysis · writing — each frozen with five variables or fewer
  • Research — say what to collect and what table it goes into
  • Analysis — hand over the criteria and the axes of comparison
  • Writing — fix the reader, the length and the tone
Pin the three anti-hallucination rules at the bottom of each: say when you don't know / demand sources / separate fact from inference.
WRAP-UP

Three sentences from today

  • Answer quality comes from the structure of the instruction, not talent.
  • Of the four, context (C) moves the answer most. Write three lines or more.
  • Don't throw away an instruction that worked. Keep it as a template.
Next week we widen to 30 solution ideas across the seven SCAMPER axes. Win on quantity first.
PART 2 · 5주차

발산적 사고 · SCAMPER × AI

먼저 양으로 이긴다 — 해법 아이디어 30안 만들기
PBLⅠ · AI Problem Solving
오늘의 질문
“좋은 아이디어 하나를 찾고 있습니까,
아이디어 서른 개를 찾고 있습니까?”
좋은 하나는 언제나 서른 개 뒤에 숨어 있습니다.
핵심 개념 1

발산과 수렴은 다른 시간에 한다

발산은 양을 늘리는 시간, 수렴은 줄이는 시간. 섞으면 둘 다 실패합니다.

정의

오늘은 판단을 유보합니다. 평가는 7주차에 기준을 세운 뒤 합니다.

신호

“그건 안 될 것 같은데”가 나오면 이미 수렴으로 넘어간 것입니다.

흔한 오해

좋은 안만 적으면 효율적이라는 착각. 후보가 적으면 비교가 불가능합니다.

주의

판단 유보는 판단 포기가 아닙니다. 미루는 것일 뿐입니다.

핵심 개념 2

SCAMPER 7축, 세 묶음으로

바꾸기 · S/M/P

대체·변형·용도전환. 지금 쓰는 재료나 쓰임을 다른 것으로 갈아 끼웁니다.

붙이기 · C/A

결합·응용. 이미 있는 것 둘을 합치거나, 남의 해법을 가져옵니다.

빼고 뒤집기 · E/R

제거·역발상. 없애면 어떻게 되는지, 반대로 하면 어떻게 되는지 봅니다.

7축은 영감이 아니라 강제 이동 장치입니다. 막힌 자리에서 옆으로 밀어 줄 뿐입니다.
핵심 개념 3

AI는 증폭기다

축을 지정한 AI

“제거 축으로 5안”처럼 방향을 주면 서로 다른 안이 나옵니다.

그냥 물어본 AI

“아이디어 30개”만 시키면 평범한 30개가 옵니다. 축이 없기 때문입니다.

증폭기는 신호를 키울 뿐입니다. 내가 0을 넣으면 30배도 0입니다.
핵심 개념 4

오늘의 발상 3단계

맨손AI 없이 8안을 손으로 쓴다 — 내 기준선
축 걸기7축 × 3안, AI로 21안까지 늘린다
극단 조건예산 0원 · 하루 안에 · 반대로 하면
맨손 단계를 건너뛰면 AI의 답이 내 생각인지 판단할 기준선이 사라집니다.
전체 지도

이번 주가 서 있는 자리

1–4주문제를 하나로 좁혔다
5주해법을 최대한 넓힌다
6주막는 모순을 깬다
7주기준으로 1안까지 줄인다
이번 주는 일부러 넓히는 주입니다. 좁히는 일은 2주 뒤에 합니다.
사례

같은 문제, 축을 바꿨을 때

“점심시간 학식 줄이 20분을 넘는다” — 축마다 다른 방향이 열립니다.
제거줄 자체를 없앤다 — 시간대 예약 픽업 용도전환빈 강의실을 12시에만 식사 공간으로 연다 역발상사람을 옮기지 말고 음식을 밖으로 내보낸다
세 안 모두 같은 문제에서 나왔습니다. 축을 바꾸면 보이는 방향이 바뀝니다.
오늘 만드는 것

해법 아이디어 30안 리스트

축 / 조건 / 아이디어 한 줄 — 30행
  • 맨손 8안 — AI를 켜기 전에 확보한 기준선
  • SCAMPER 21안 — 7축을 하나도 비우지 않는다
  • 극단 조건 확장안 — 조건을 함께 적는다
중복은 합치되 지우지 마십시오. 오늘 버린 안이 다음 주의 재료입니다.
정리

오늘의 세 문장

  • 발산과 수렴은 같은 시간에 하지 않는다.
  • SCAMPER는 영감이 아니라 강제 이동 장치다.
  • AI는 증폭기다. 축이 없으면 평범한 30개만 남는다.
다음 주 모순을 다룹니다. “좋은데 이것 때문에 안 된다”의 그 ‘이것’이 진짜 문제입니다.
PART 2 · WEEK 5

Divergent Thinking · SCAMPER × AI

Win on quantity first — generate 30 solution ideas
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Are you looking for one good idea,
or for thirty ideas?”
The good one is always hiding behind the other twenty-nine.
KEY CONCEPT 1

Diverge and converge at different times

Divergence is time spent adding options. Convergence is time spent cutting them. Mix them and both fail.

Definition

Today judgment is suspended. You evaluate in Week 7, after the criteria exist.

The signal

The moment you think “that won't work”, you have already switched to converging.

Common mistake

Writing only the good ideas feels efficient. With few candidates you cannot compare.

Watch out

Suspending judgment is not abandoning it. You are postponing it, not skipping it.

KEY CONCEPT 2

Seven SCAMPER axes, in three groups

Change it · S/M/P

Substitute, modify, put to other use. Swap the material or the purpose for another one.

Join it · C/A

Combine and adapt. Fuse two things you already have, or borrow someone else's answer.

Cut and flip · E/R

Eliminate and reverse. Ask what happens if it is gone, or done the other way round.

The axes are not inspiration. They are a forced sideways push out of the place you are stuck.
KEY CONCEPT 3

AI is an amplifier

AI with an axis

Name the direction — “five ideas on the eliminate axis” — and the answers differ from each other.

AI without one

Ask for “30 ideas” and you get 30 ordinary ones. Nothing told it where to go.

An amplifier only makes the signal louder. Put in zero and thirty times zero is still zero.
KEY CONCEPT 4

Today's ideation, three moves

Bare hands8 ideas written without AI — your baseline
Set an axis7 axes × 3 ideas, up to 21 with AI
Extreme conditionszero budget · one day · the opposite
Skip the bare-handed step and you lose the baseline that tells you whether the AI's answer is yours.
THE MAP

Where this week sits

Weeks 1–4you narrowed it to one problem
Week 5widen the solutions as far as you can
Week 6break the contradiction blocking them
Week 7cut down to one with criteria
This week widens on purpose. The narrowing happens two weeks from now.
CASE

Same problem, different axis

“The lunch queue at the canteen runs over 20 minutes” — each axis opens a different direction.
EliminateRemove the queue — pre-order with a pickup slot Put to other useOpen empty lecture rooms as seating at noon only ReverseDon't move people — move the food out to them
All three came from one problem. Change the axis and the direction you can see changes.
WHAT YOU MAKE TODAY

A list of 30 solution ideas

axis / condition / one line of idea — 30 rows
  • 8 by hand — the baseline you set before switching AI on
  • 21 from SCAMPER — leave none of the seven axes empty
  • Extreme-condition ideas — write the condition next to each
Merge duplicates, but delete nothing. What you throw out today is next week's raw material.
WRAP-UP

Three sentences from today

  • Diverging and converging never share the same hour.
  • SCAMPER is not inspiration. It is a forced move sideways.
  • AI amplifies. Without an axis you get 30 ordinary ideas.
Next week we take on contradictions. The “this is what stops it” part is the real problem.
PART 2 · 6주차

모순 해결 · TRIZ

“A를 얻으면 B를 잃는” 구조를 깨는 법
PBLⅠ · AI Problem Solving
오늘의 질문
“그 아이디어는 좋은데,
왜 실행이 안 됩니까?”
막고 있는 것은 대개 자원이 아니라 하나의 모순입니다.
핵심 개념 1

모순이 곧 문제다

문제가 안 풀리는 자리에는 언제나 “A를 높이면 B가 나빠진다”가 있습니다.

정의

하나의 변수를 개선할 때 다른 변수가 반드시 나빠지는 관계입니다.

예시

“검사를 꼼꼼히 하면 정확해지고, 대기 시간이 길어진다.”

흔한 오해

“돈이 없다”는 모순이 아니라 조건입니다. 두 변수가 없기 때문입니다.

주의

A와 B를 이름으로 쓰지 못하면 아직 모순을 찾은 것이 아닙니다.

핵심 개념 2

분리 4원리

시간으로

평소에는 A, 특정 시간에는 B. 가장 흔하게 통하는 해법입니다.

공간으로

여기서는 A, 저기서는 B. 장소를 나누면 충돌이 사라집니다.

조건·부분으로

이 사람에게는 A, 저 사람에게는 B. 또는 전체는 A, 부품은 B.

네 원리는 결국 하나를 묻습니다. “언제 · 어디서 · 누구에게 A입니까?”
핵심 개념 3

절충하지 않는다

소거안

모순 자체를 없앱니다. A도 얻고 B도 잃지 않는 구조를 만듭니다.

절충안

“적당히 반씩”은 A도 B도 절반만 남깁니다. 대개 둘 다 실패합니다.

“둘 중 하나를 고르라”는 말을 들으면, 먼저 그 질문을 의심하십시오.
핵심 개념 4

오늘의 해결 3단계

모순 쓰기A를 높이면 B가 나빠진다 — 두 문장
이상적 결과비용도 부작용도 0, 기능만 남은 상태
분리 적용시간 · 공간 · 조건 · 부분을 모두 시도
이상적 최종 결과를 먼저 선언하고 거기서 역산합니다. 가능한 것부터 세면 멀리 가지 못합니다.
전체 지도

이번 주가 서 있는 자리

5주30안을 넓게 모았다
6주막고 있던 모순을 소거한다
7주기준과 제약으로 1안을 고른다
8주솔루션 컨셉으로 발표한다
5주차에 “좋은데 안 된다”고 접었던 안들이 오늘의 재료입니다.
사례

조별 과제 회의의 모순

회의를 늘리면 정보는 모이지만, 시간이 없어 아무도 오지 않습니다.
모순회의를 늘리면 정보는 모이고, 참석률은 떨어진다 이상적 결과모이지 않아도 정보가 모여 있는 상태 시간 분리주 1회 10분만 대면, 나머지는 기록으로 공유
절충(주 2회 30분)은 둘 다 잃습니다. 분리는 둘 다 얻습니다.
오늘 만드는 것

모순 정의서 + 해소 아이디어 5안

“A를 높이면 B가 나빠진다” 2문장 + 이상적 최종 결과 1문장
  • 모순 2문장 — A와 B를 각각 이름으로 쓴다
  • 분리 시도 기록 — 네 원리를 하나도 비우지 않는다
  • 소거안 5개 — 모순이 사라진 이유를 함께 적는다
절충안은 제출물에 넣지 마십시오. 오늘은 소거안만 셉니다.
정리

오늘의 세 문장

  • 안 풀리는 문제 뒤에는 하나의 모순이 있다.
  • 절충은 둘 다 잃는다. 소거를 목표로 한다.
  • 이상적 결과를 먼저 선언하고 역산한다.
다음 주 넓힌 것을 좁힙니다. 기준을 먼저 세우고, 점수는 그다음에 매깁니다.
PART 2 · WEEK 6

Resolving Contradictions · TRIZ

How to break the “gain A, lose B” structure
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“The idea is good —
so why can't you do it?”
What blocks it is usually not resources. It is one contradiction.
KEY CONCEPT 1

The contradiction is the problem

Wherever a problem refuses to move, you will find “raise A and B gets worse”.

Definition

A relation where improving one variable necessarily damages another.

Example

“Check it thoroughly and it gets accurate — and the wait gets longer.”

Common mistake

“We have no money” is a condition, not a contradiction. There is no second variable.

Watch out

If you cannot name A and B, you have not found the contradiction yet.

KEY CONCEPT 2

The four separation principles

By time

A most of the time, B at certain hours. The one that works most often.

By space

A here, B there. Split the place and the collision disappears.

By condition or part

A for these people, B for those. Or A for the whole, B for one component.

All four ask a single question: “when, where, and for whom is it A?”
KEY CONCEPT 3

Do not compromise

Elimination

Remove the contradiction itself. You get A without giving up B.

Compromise

“A bit of each” leaves half of A and half of B. Usually both then fail.

When someone tells you to pick one of the two, first doubt the question.
KEY CONCEPT 4

Today's resolution, three moves

State itraise A and B gets worse — two sentences
Ideal resultthe function, at zero cost and zero side effect
Separatetry time, space, condition and part
Declare the ideal final result first and work backwards. Start from what is possible and you never travel far.
THE MAP

Where this week sits

Week 5you gathered 30 ideas, wide
Week 6eliminate what was blocking them
Week 7pick one with criteria and constraints
Week 8present it as a solution concept
The ideas you set aside in Week 5 as “good, but impossible” are today's material.
CASE

The contradiction inside team meetings

More meetings gather more information — and nobody has the time to show up.
ContradictionMore meetings, more information shared, worse attendance Ideal resultThe information is gathered without anyone meeting Separate by timeOne 10-minute meeting a week; the rest in writing
The compromise — twice a week, 30 minutes — loses both. Separation keeps both.
WHAT YOU MAKE TODAY

Contradiction statement + 5 ideas that resolve it

“raise A and B gets worse” in 2 sentences + the ideal final result in 1
  • The contradiction — name A and B explicitly, both of them
  • A record of attempts — leave none of the four principles empty
  • Five eliminations — say why the contradiction is gone in each
Keep compromises out of the deliverable. Only eliminations count today.
WRAP-UP

Three sentences from today

  • Behind a stuck problem sits a single contradiction.
  • Compromise loses both sides. Aim for elimination.
  • Declare the ideal result first, then work backwards.
Next week we narrow what we widened. Criteria come first, scores come after.
PART 2 · 7주차

수렴적 사고와 제약 충족

평가 매트릭스로 30안을 1안으로 줄이기
PBLⅠ · AI Problem Solving
오늘의 질문
“그 안을 고른 이유를
30초 안에 말할 수 있습니까?”
말하지 못한다면 고른 것이 아니라 끌린 것입니다.
핵심 개념 1

기준을 먼저, 점수는 나중에

기준은 후보를 보기 전에 확정합니다. 순서가 바뀌면 채점은 형식일 뿐입니다.

정의

기준은 “무엇이 좋은 해법인가”에 대한 우리 팀의 선언입니다.

출처

1주차 성공 기준에서 가져옵니다. 새로 지어내지 않습니다.

흔한 오해

후보를 보고 기준을 만들면 이미 답을 정해 놓은 것입니다.

주의

기준은 4~5개면 충분합니다. 열 개가 되면 아무것도 고를 수 없습니다.

핵심 개념 2

평가 매트릭스의 세 부품

기준

효과·실현가능성·비용·시급성처럼 서로 겹치지 않는 4~5개.

가중치

합이 100이 되게 나눕니다. 성공 기준에 가까운 항목에 무게를 줍니다.

점수

1~5점으로 매기고, 가중치를 곱해 합산합니다.

가중치를 나누는 순간 무엇을 포기할지가 정해집니다. 그 논쟁이 오늘의 본론입니다.
핵심 개념 3

하드 제약과 소프트 기준

하드 제약

예산 0원 · 인력 1명 · 2주. 통과 아니면 탈락, 점수가 없습니다.

소프트 기준

점수로 비교합니다. 여기에 제약을 섞으면 못 하는 안이 살아남습니다.

제약을 넘지 못하는 안은, 아무리 좋아도 우리에게는 좋은 안이 아닙니다.
핵심 개념 4

오늘의 수렴 3단계

제약 필터못 넘는 안을 먼저 자른다 — 30안 → 10안
가중 채점남은 안만 점수 × 가중치로 합산
반론 방어“왜 2위가 아닌가”를 세 줄로 답한다
완벽한 최적해는 찾지 않습니다. 충분히 좋은 안을 빠르게 찾고 근거로 지킵니다.
전체 지도

이번 주가 서 있는 자리

5주30안으로 넓혔다
6주모순을 소거해 5안을 얻었다
7주기준과 제약으로 1안을 정한다
8주그 1안을 컨셉으로 발표한다
오늘 고른 1안이 남은 8주 동안 만들 대상입니다. 그래서 근거가 필요합니다.
사례

학식 대기 문제, 후보 셋

하드 제약은 “예산 0원 · 실행 인력 1명 · 2주 안 확인”입니다.
예약 픽업효과 5점 — 학교 시스템 권한 필요 → 제약 탈락 혼잡도 알림효과 3점 — 2주·1명 가능 → 가중 합계 4.2 수업 시간 조정효과 5점 — 내 통제 밖 → 제약 탈락
1위는 점수가 가장 높은 안이 아니라 제약을 통과한 안 중 가장 높은 안입니다.
오늘 만드는 것

평가 매트릭스 + 최종 1안 근거서

기준 4~5개 × 가중치 합 100 × 제약을 통과한 후보 10안
  • 탈락 목록 — 어떤 제약에 걸렸는지 함께 적는다
  • 가중 합계표 — 1위와 2위의 점수 차이를 표시한다
  • “왜 2위가 아닌가” — 세 줄 방어문
AI가 매긴 점수를 그대로 두지 마십시오. 최소 한 칸은 내 판단으로 고칩니다.
정리

오늘의 세 문장

  • 기준을 후보보다 먼저 정한다.
  • 하드 제약은 점수가 아니라 통과·탈락이다.
  • 선택은 점수가 아니라 방어할 수 있는 근거로 끝난다.
다음 주 중간고사입니다. 1~7주 산출물을 솔루션 컨셉 명세서 하나로 묶어 발표합니다.
PART 2 · WEEK 7

Convergent Thinking and Constraint Satisfaction

Cutting 30 ideas down to 1 with an evaluation matrix
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Can you say why you chose it
in thirty seconds?”
If you can't, you didn't choose it. You were drawn to it.
KEY CONCEPT 1

Criteria first, scores later

Fix the criteria before you look at the candidates. Reverse that order and scoring is just theatre.

Definition

Criteria are your team's declaration of what counts as a good solution.

Where they come from

From your Week 1 success criteria. You do not invent new ones now.

Common mistake

Build criteria after seeing the candidates and you have already picked the winner.

Watch out

Four or five criteria is enough. At ten, nothing can ever win.

KEY CONCEPT 2

Three parts of an evaluation matrix

Criteria

Four or five that don't overlap — impact, feasibility, cost, urgency.

Weights

Split them so they total 100. Weight goes to whatever sits closest to success.

Scores

Score 1 to 5, multiply by the weight, and add the columns up.

The moment you split the weights you decide what you are giving up. That argument is today's real work.
KEY CONCEPT 3

Hard constraints vs soft criteria

Hard constraint

Zero budget · one person · two weeks. Pass or out — no score involved.

Soft criterion

Compared by score. Mix a constraint in here and an impossible idea survives.

An idea that fails a constraint is not a good idea for us, however good it is.
KEY CONCEPT 4

Today's convergence, three moves

Filtercut what fails a constraint — 30 down to 10
Scoreweight × score, on the survivors only
Defendanswer “why not the runner-up” in three lines
You are not hunting the perfect optimum. Find a good-enough answer fast and hold it with reasons.
THE MAP

Where this week sits

Week 5you widened it to 30 ideas
Week 6eliminating contradictions left 5
Week 7criteria and constraints leave 1
Week 8present that one as a concept
The idea you pick today is what you will build for eight more weeks. That is why it needs reasons.
CASE

Canteen queues, three candidates

Hard constraints: zero budget · one person doing it · a result visible in two weeks.
Pre-order pickupImpact 5 — needs campus system access → fails Crowding alertsImpact 3 — one person, two weeks → total 4.2 Shift class timesImpact 5 — outside your control → fails
The winner is not the highest score. It is the highest score among those that passed.
WHAT YOU MAKE TODAY

Evaluation matrix + rationale for the final idea

4–5 criteria × weights totalling 100 × the 10 candidates that passed
  • The rejected list — note which constraint each one failed
  • Weighted totals — show the gap between first and second
  • “Why not the runner-up” — three lines of defence
Don't leave the AI's scores as they are. Change at least one cell with your own judgment.
WRAP-UP

Three sentences from today

  • Set the criteria before you see the candidates.
  • A hard constraint is not a score. It is pass or out.
  • A choice ends not with a number but with a defence.
Next week is the midterm. You bundle Weeks 1–7 into one solution concept spec and present it.
PART 2 · 8주차

솔루션 컨셉 발표

일곱 주의 산출물을 하나의 명세서로 — 근거로 답하는 발표
PBLⅠ · AI Problem Solving
오늘의 질문
“그 해법은 왜
하필 그것이어야 합니까?”
근거를 대지 못하면 좋은 안이어도 선택이 아니라 취향입니다.
핵심 개념 1

명세서가 증명해야 하는 것

명세서는 아이디어 소개가 아니라 선택의 증명입니다. 여섯 구성이 하나의 논리로 이어져야 합니다.

연결

1주차 문제 문장이 7주차 선정 근거까지 끊기지 않고 이어집니다.

추적

모든 주장 옆에 그 주장이 나온 주차의 산출물이 있어야 합니다.

흔한 오해

분량이 많으면 통합이 아닙니다. 일곱 개 파일을 붙인 것은 통합이 아닙니다.

주의

중간에 문제 정의를 슬쩍 바꾸지 마십시오. 바꿨다면 이유를 적으십시오.

핵심 개념 2

평가는 세 가지만 봅니다

① 통합성

문제·원인·대안·선정이 하나의 사슬로 읽히는가.

② 근거성

선택마다 기준과 데이터가 붙어 있는가.

③ 실행 가능성

남은 8주 안에 만들고 확인할 수 있는가.

셋 다 발표 태도가 아니라 문서에서 확인됩니다. 말로 보충해야 하는 부분은 아직 비어 있는 부분입니다.
핵심 개념 3

버린 안을 보여주십시오

고른 안만 말하면

청중은 비교하지 않은 사람으로 봅니다. 질문은 “다른 방법은요?”로 시작됩니다.

버린 안까지 말하면

탈락 이유가 곧 선정 근거가 됩니다. 질문이 확인으로 바뀝니다.

버린 안을 보여줘야 고른 안이 설득됩니다.
핵심 개념 4

7분을 세 덩어리로

1분 · 문제사례 하나로 시작한다
5분 · 근거의 사슬원인 · 공격 지점 · 대안 · 선정
1분 · 다음 8주무엇을 만들어 어떻게 검증하는가
뒤에 질의 3분이 붙습니다. 예상 질문 다섯 개의 답은 슬라이드가 아니라 문서에서 찾아 두십시오.
전체 지도

이 주의 위치

1–4주문제를 해부했다
5–7주대안을 넓히고 하나로 좁혔다
8주하나의 명세서로 묶는다
9–15주절차로 옮겨 만든다
오늘은 새 프레임워크를 배우지 않습니다. 가진 것을 하나로 만드는 날입니다.
사례

같은 주장, 약한 말과 강한 말

“도서관 실시간 좌석 표시”를 고른 팀의 세 가지 발표 문장입니다.
약한 말“실시간 좌석 표시가 가장 효율적이라고 생각합니다.” 강한 말“3개 안 중 매트릭스 1위. 2안은 시설팀 협조가 필요해 탈락.” 방어까지“최대 약점은 좌석 데이터 정확도. 12주차에 실측으로 검증합니다.”
강한 말에는 비교 대상과 탈락 이유가 들어 있습니다. 형용사는 근거가 아닙니다.
오늘 만드는 것

솔루션 컨셉 명세서

A4 5매 명세서 + 발표자료 + 프롬프트 원문 부록
  • 여섯 구성 — 문제 · 원인 · 작업 분해 · 대안 · 선정 · 해결 로직 초안
  • 탈락 기록 — 버린 안과 버린 이유를 명시
  • 예상 질문 5개 — 답과 근거 위치를 미리 적어 둔다
중간고사 평가 비중 30%. 발표 7분 + 질의 3분.
정리

오늘의 세 문장

  • 명세서는 소개가 아니라 선택의 증명이다.
  • 평가는 통합성·근거성·실행 가능성 세 가지만 본다.
  • 버린 안을 말하지 않으면 고른 안도 설득되지 않는다.
다음 주 해법을 절차로 옮깁니다. 순서도가 그려지지 않으면 아직 만들 수 없는 해법입니다.
PART 2 · WEEK 8

Solution Concept Presentation

Seven weeks of work into one specification — and answers backed by evidence
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Why does it have to be
that solution and no other?”
Without a reason, even a good idea is a taste, not a choice.
KEY CONCEPT 1

What the specification must prove

The spec is not an introduction to an idea. It is proof of a choice, and the six sections must read as one argument.

Continuity

The week 1 problem sentence runs unbroken to the week 7 rationale.

Traceability

Every claim sits next to the deliverable it came from.

Common mistake

Length is not integration. Seven files stapled together is still seven files.

Watch out

Don't quietly redefine the problem midway. If you changed it, say why.

KEY CONCEPT 2

Three things we assess

① Integration

Do problem, cause, alternatives and choice read as one chain?

② Evidence

Does every choice carry a criterion and data?

③ Feasibility

Can it be built and checked in the remaining 8 weeks?

All three are read in the document, not in your delivery. Whatever you have to add out loud is what's still missing.
KEY CONCEPT 3

Show what you dropped

Only the chosen idea

You look like someone who never compared. Q&A opens with “what else did you consider?”

The dropped ones too

The reason each failed becomes your rationale. Questions turn into confirmation.

The idea you chose is only convincing next to the ones you rejected.
KEY CONCEPT 4

Seven minutes, three blocks

1 min · Problemopen with one real case
5 min · Chain of evidencecause, strike point, options, choice
1 min · Next 8 weekswhat you build, how you check it
Then 3 minutes of questions. Locate the answers to your five likely questions in the document, not in the slides.
THE MAP

Where this week sits

Weeks 1–4you dissected the problem
Weeks 5–7you widened, then picked one
Week 8tie it into one specification
Weeks 9–15turn it into procedure and build
No new framework today. This is the week you make what you already have into one thing.
CASE

One claim, weak and strong

Three ways a team could present the same choice: live library seat status.
Weak“We think live seat status is the most efficient option.” Strong“Top of three on the matrix. Option 2 died: needs facilities staff.” Defended“Biggest weakness is seat data accuracy. We test it in week 12.”
The strong version carries what it beat and why the others failed. Adjectives are not evidence.
WHAT YOU SUBMIT

The solution concept package

5-page specification + slides + full prompt appendix
  • Six sections — problem · cause · tasks · alternatives · selection · draft logic
  • The rejects — what you dropped, and the reason for each
  • Five likely questions — the answer and where its evidence lives
Midterm weight 30%. Seven minutes to present, three for questions.
WRAP-UP

Three sentences from today

  • A specification is not an introduction. It is proof of a choice.
  • We assess three things: integration, evidence, feasibility.
  • Say nothing about the rejects and your choice stays unproven.
Next week we turn the solution into procedure. If you can't draw the flowchart, you can't build it yet.
PART 3 · 9주차

알고리즘 설계 · 순서도로 사고하기

해결 절차를 조건·반복·분기로 기술하기
PBLⅠ · AI Problem Solving
오늘의 질문
“그 해법의 순서를
열 문장으로 적을 수 있습니까?”
적히지 않는다면 그것은 해법이 아니라 아직 소망입니다.
핵심 개념 1

절차로 쓸 수 없으면 못 만든다

알고리즘은 코드가 아니라 순서가 정해진 문장의 묶음입니다. 말로 되는데 그림이 안 되면 구멍이 있습니다.

조건

모든 단계는 입력과 출력이 있어야 합니다. 무엇을 받아 무엇을 내놓습니까.

단위

한 단계는 한 사람이 한 번에 끝낼 수 있는 크기여야 합니다.

흔한 오해

“AI가 알아서 처리한다”는 단계가 아닙니다. 무엇을 넣고 무엇을 받는지 쓰십시오.

주의

“아니오” 화살표가 빈 순서도는 12주차 테스트에서 반드시 깨집니다.

핵심 개념 2

기호는 세 개면 충분하다

① 처리 · 사각형

무언가를 하는 단계. 동사 하나로 쓸 수 있어야 합니다.

② 판단 · 마름모

예/아니오로 답하는 질문. 나가는 화살표가 항상 둘입니다.

③ 시작·끝 · 둥근 모서리

절차가 언제 시작되고 무엇으로 끝나는지 못박습니다.

순서도는 손으로 그려도 되고 Mermaid 문법으로 받아 화면에서 확인해도 됩니다. 모양보다 빠짐없음이 중요합니다.
핵심 개념 3

단계마다 주체를 적으십시오

AI에 맡길 단계

정해진 규칙으로 모으고 분류하고 초안을 쓰는 반복 작업.

사람이 쥘 단계

개인정보를 다루거나, 누군가에게 통보하거나, 되돌릴 수 없는 단계.

자동화해도 되는 단계와 해서는 안 되는 단계를 나누는 것이 설계입니다.
핵심 개념 4

순서도를 만드는 세 걸음

번호 문장절차를 10~15개 문장으로 쓴다
판단 지점 표시“만약 ~라면”이 있는 곳을 모두 찾는다
도식화 · 주체 표기기호로 옮기고 사람·AI를 적는다
그림부터 그리지 마십시오. 문장이 먼저입니다. 문장이 막히는 곳이 설계가 비어 있는 곳입니다.
전체 지도

이 주의 위치

7주1안을 골랐다
8주하나의 명세서로 묶었다
9주절차와 분기로 옮긴다
10–12주단계를 AI에 시키고 만든다
이번 주 순서도의 각 단계가 다음 주에는 프롬프트 한 개가 됩니다.
사례

팀플 미제출자 알림 절차

“마감 3일 전에 안 낸 사람에게 연락한다” — 이 한 줄을 절차로 펼칩니다.
처리제출 현황표를 읽어 미제출자 명단을 뽑는다 판단마감 3일 전인가? 아니오면 내일 다시 확인한다 주체명단 추출은 AI, 연락 문구 발송은 사람
판단 노드의 “아니오” 경로를 채우면 예외 목록이 저절로 만들어집니다.
오늘 만드는 것

해결 절차 순서도

순서도 한 장 + 단계별 주체·실패 대안표
  • 번호 문장 10개 이상 — 순서도 이전에 글로 먼저 확정
  • 모든 판단에 두 경로 — “아니오” 쪽을 비워 두지 않는다
  • 단계별 주체 — [사람] / [AI] / [자동]과 실패 시 대안
AI가 판단하는 단계에는 그 판단이 틀렸을 때의 위험을 함께 적으십시오.
정리

오늘의 세 문장

  • 절차로 쓸 수 없는 해법은 아직 만들 수 없는 해법이다.
  • 처리·판단·시작끝 세 기호로 거의 모든 절차를 그린다.
  • 분기의 “아니오” 쪽이 곧 예외 처리다.
다음 주 각 단계를 AI에게 넘깁니다. 한 프롬프트에 한 작업, 그리고 단계를 이어 붙입니다.
PART 3 · WEEK 9

Algorithm Design · Thinking in Flowcharts

Describing the procedure in conditions, loops and branches
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Can you write your solution
as ten numbered steps?”
If it won't go on paper, it's still a wish, not a solution.
KEY CONCEPT 1

If you can't write the procedure, you can't build it

An algorithm is not code. It is sentences in a fixed order. If you can say it but not draw it, there is a hole.

Condition

Every step needs an input and an output. What goes in, what comes out?

Size

One step is what one person can finish in one sitting.

Common mistake

“AI handles it” is not a step. Write what you give it and what you get back.

Watch out

A chart with an empty “no” arrow will break in the week 12 test, without fail.

KEY CONCEPT 2

Three symbols are enough

① Process · rectangle

A step that does something. It should fit one verb.

② Decision · diamond

A yes/no question. Always two arrows leaving it.

③ Start·end · rounded

Pins down when the procedure begins and what ends it.

Draw it by hand, or get Mermaid text and check the diagram on screen. What matters is nothing missing, not neatness.
KEY CONCEPT 3

Label who does each step

Give AI

Repetitive work with fixed rules: collecting, sorting, drafting.

Keep with a person

Anything touching personal data, notifying someone, or impossible to undo.

Design is deciding which steps may be automated and which must not be.
KEY CONCEPT 4

Three moves to a flowchart

Numbered sentenceswrite the procedure as 10–15 lines
Mark decisionsfind every place an “if” appears
Draw · label actorsmove to symbols, tag human or AI
Don't start with the picture. Sentences first. Where the sentence stalls is where the design is empty.
THE MAP

Where this week sits

Week 7you picked one idea
Week 8you tied it into one spec
Week 9turn it into steps and branches
Weeks 10–12hand steps to AI and build
Each step in today's chart becomes one prompt next week. Vague steps make vague prompts.
CASE

Chasing missing group-project files

“Contact whoever hasn't submitted, three days before the deadline” — unfolded into a procedure.
ProcessRead the submission sheet, list who is missing DecisionThree days to deadline? If no, check again tomorrow ActorAI builds the list; a person sends the message
Fill in the “no” path of every decision and your exception list writes itself.
WHAT YOU MAKE TODAY

The solution flowchart

One flowchart + a table of actors and failure fallbacks
  • Ten or more numbered sentences — settled in prose before any drawing
  • Two paths per decision — never leave the “no” side empty
  • An actor per step — [human] / [AI] / [automatic], plus the fallback
Wherever AI does the judging, write down the risk of it judging wrong.
WRAP-UP

Three sentences from today

  • A solution you can't write as a procedure is one you can't build yet.
  • Three symbols — process, decision, start/end — draw almost anything.
  • The “no” side of a branch is your exception handling.
Next week we hand those steps to AI: one prompt per task, then chained together.
PART 3 · 10주차

프롬프트 체이닝과 AI 에이전트

한 번에 시키지 말고, 연결해서 시키기
PBLⅠ · AI Problem Solving
오늘의 질문
“한 번에 다 시켰는데
왜 전부 평범합니까?”
네 가지를 동시에 시키면 네 가지 모두 평균 이하로 돌아옵니다.
핵심 개념 1

한 프롬프트에 한 작업

수집·요약·작성·검토는 성격이 다른 작업입니다. 한 지시문에 섞으면 서로의 품질을 깎습니다.

원칙

한 단계에 동사 하나. 지시문에 “그리고”가 많으면 잘라야 할 신호입니다.

이점

단계가 나뉘면 어디서 틀렸는지 보입니다. 그 단계만 고치면 됩니다.

흔한 오해

프롬프트를 길게 쓰면 좋아진다는 생각. 길이가 아니라 단위의 문제입니다.

주의

단계를 너무 잘게 쪼개면 옮겨 붙이는 시간이 더 듭니다. 4~6단계가 적당합니다.

핵심 개념 2

한 단계를 이루는 세 가지

① 입력 규격

무엇을 받는가. 앞 단계의 출력과 형태가 같아야 합니다.

② 작업 지시

이 단계에서 할 일 하나와 지켜야 할 제약.

③ 출력 규격

표·목록·문단 중 무엇으로, 몇 개, 어떤 항목으로 내놓는가.

체인이 끊기는 곳은 언제나 접합부입니다. 앞의 출력 규격이 뒤의 입력 규격이 되도록 미리 못 박으십시오.
핵심 개념 3

검토는 다른 역할에게

다른 역할·다른 세션

“까다로운 심사자” 역할을 주고 초안만 넘기면 빠진 것을 지적합니다.

같은 대화에서 자기 검토

쓴 맥락을 그대로 안고 있어 관대해집니다. “좋습니다”만 돌아옵니다.

쓴 사람과 검토하는 사람을 분리하는 것은 사람 조직에서도 같은 이유입니다.
핵심 개념 4

체인을 만드는 세 걸음

자르기반복 업무 하나를 4~6단계로 나눈다
규격 정하기단계마다 입력과 출력 형식을 고정한다
돌리고 검토 붙이기끊긴 지점을 적고 검토 단계를 더한다
이 체인을 목표만 주면 스스로 돌리도록 묶은 것이 에이전트입니다. 오늘은 그 구조를 손으로 설계합니다.
전체 지도

이 주의 위치

9주절차를 순서도로 그렸다
10주단계를 프롬프트 체인으로 옮긴다
11주내 자료를 붙이고 자동화한다
12–13주프로토타입으로 만들어 시험한다
순서도의 한 사각형이 체인의 한 단계가 됩니다. 9주차 그림을 옆에 펴 두십시오.
사례

매주 반복되는 스터디 자료 요약

“읽을거리 다섯 개를 요약해 공유한다” — 세 단계로 나눈 체인입니다.
1단계 · 수집자료마다 핵심 문장 3개를 뽑아 표로 (출력: 표) 2단계 · 작성그 표만 입력으로 받아 A4 1매 요약을 쓴다 3단계 · 검토다른 세션의 조교 역할이 빠진 쟁점을 지적한다
2단계에 원문을 다시 넣지 마십시오. 앞 단계의 출력만 넘겨야 체인이 유지됩니다.
오늘 만드는 것

프롬프트 체인 설계서

4단계 이상 체인 설계서(지시문 전문 포함) + 실행 결과
  • 단계표 — 단계마다 입력 규격 · 작업 · 출력 규격
  • 검토 단계 — 다른 역할로 분리해 마지막에 배치
  • 끊긴 지점 기록 — 어디서 왜 멈췄고 무엇을 고쳤는가
설계만 하지 말고 실제로 끝까지 한 번 돌려 보십시오. 끊기는 곳은 돌려야 보입니다.
정리

오늘의 세 문장

  • 한 프롬프트에 한 작업. 섞으면 전부 평균 이하가 된다.
  • 체인이 끊기는 곳은 언제나 접합부의 형식이다.
  • 검토는 다른 역할·다른 세션으로 분리한다.
다음 주 이 체인에 내 자료를 붙입니다. AI가 내 문서를 근거로 답하게 만드는 구성(RAG)을 다룹니다.
PART 3 · WEEK 10

Prompt Chaining and AI Agents

Don't ask for it all at once — chain it
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“You asked for everything at once.
Why is all of it mediocre?”
Ask for four jobs in one go and all four come back below average.
KEY CONCEPT 1

One prompt, one task

Gathering, summarizing, writing and reviewing are different kinds of work. Mixed into one instruction, they cut each other down.

Rule

One verb per stage. Lots of “and” in your prompt is the signal to cut.

Payoff

Split stages show you where it went wrong. You fix only that stage.

Common mistake

Thinking a longer prompt is a better one. It's not length, it's unit size.

Watch out

Slice too finely and you spend the time copying between stages. Four to six is right.

KEY CONCEPT 2

What one stage is made of

① Input spec

What it receives. Same shape as the previous stage's output.

② Instruction

The one job of this stage, plus the constraints to hold.

③ Output spec

Table, list or prose — how many items, with which columns.

A chain always snaps at the joint. Fix the format so one stage's output is literally the next one's input.
KEY CONCEPT 3

Give review to someone else

New role, new session

Hand over only the draft, in a “tough reviewer” role, and gaps get named.

Self-review in the same chat

It still holds the context it wrote in, so it goes easy. You get “looks good”.

We separate the writer from the reviewer for the same reason organizations do.
KEY CONCEPT 4

Three moves to a chain

Cutsplit one repetitive task into 4–6 stages
Specifyfix the input and output format of each
Run and reviewnote where it broke, add a review stage
Wrap that chain so it runs itself from a goal and you have an agent. Today you design that structure by hand.
THE MAP

Where this week sits

Week 9you drew the procedure
Week 10turn steps into a prompt chain
Week 11attach your own material, automate
Weeks 12–13build the prototype and test it
One rectangle on your flowchart becomes one stage of the chain. Keep last week's diagram open beside you.
CASE

The weekly study-group summary

“Summarize five readings and share them” — the same job as a three-stage chain.
1 · CollectPull three key sentences per reading into a table 2 · WriteTake only that table, produce a one-page summary 3 · ReviewA tutor role in another session names what's missing
Don't feed the original readings back in at stage 2. Pass only the previous output or the chain dissolves.
WHAT YOU MAKE TODAY

The prompt chain design

A 4+ stage chain design, full instruction texts, plus the run results
  • Stage table — input spec · instruction · output spec, for each stage
  • Review stage — a separate role, placed at the end
  • Break log — where it stopped, why, and what you changed
Don't stop at the design. Run it end to end once — breaks only show up when it runs.
WRAP-UP

Three sentences from today

  • One prompt, one task. Mix them and all of it drops to average.
  • A chain breaks at the format of its joints, every time.
  • Put review in a different role and a different session.
Next week we attach your own material to the chain — how a setup answers from your documents (RAG).
PART 3 · 11주차

노코드 자동화와 지식 연결 (RAG 기초)

내 자료를 AI에 붙이고, 반복을 기계에 넘기기
PBLⅠ · AI Problem Solving
오늘의 질문
“우리 학교 규정을 모르는 AI가
내놓은 답을 믿을 수 있습니까?”
모델은 세상을 압니다. 그러나 내 자료는 모릅니다.
핵심 개념 1

외우는 것이 아니라 찾아서 인용한다

RAG = 모델이 기억에서 답하지 않고, 내가 준 문서에서 찾아 인용하는 구성입니다.

원리

질문이 오면 자료에서 관련 대목을 먼저 찾고, 그 대목만 근거로 답을 씁니다.

최대 장점

출처가 붙습니다. 확인할 수 있는 답과 확인할 수 없는 답은 다릅니다.

흔한 오해

자료를 올려도 모델이 학습하지는 않습니다. 그때그때 찾아볼 뿐입니다.

주의

넣은 자료가 틀리면 답도 틀립니다. 출처가 붙어도 틀린 것은 틀립니다.

핵심 개념 2

자동화의 단위는 세 칸이다

① 트리거 · 언제

무엇이 일어나면 시작하는가. 정해진 시각, 도착한 메일, 제출된 신청서.

② 처리 · 무엇을

받은 것을 어떤 규칙으로 바꾸는가. 요약·분류·기록 중 하나로 적습니다.

③ 출력 · 어디로

결과가 누구에게 어떤 형태로 가는가. 받는 사람이 없으면 자동화가 아닙니다.

세 칸을 한 문장씩 채우지 못하면 아직 자동화 대상이 아닙니다. 먼저 절차를 확정하십시오.
핵심 개념 3

자료는 많은 것보다 정리된 것이 낫다

정리된 자료 5개

제목·출처·날짜가 붙고 중복이 없으면 인용 위치가 정확해집니다.

뒤섞인 자료 50개

옛 규정과 새 규정이 함께 있으면 도우미는 옛 규정을 인용합니다.

도우미의 품질은 모델이 아니라 내가 넣은 자료의 품질이 정합니다.
핵심 개념 4

먼저 손으로 세 번

손으로 3번직접 해 보며 예외를 미리 만난다
절차 고정트리거·처리·출력을 한 문장씩 적는다
기계로 이관한 번 실행하고 걸린 시간을 비교한다
손으로 해 보지 않은 절차를 자동화하면, 결과가 이상할 때 어디가 틀렸는지 알 수 없습니다.
전체 지도

이번 주가 놓인 자리

9주절차를 순서도로 그렸다
10주지시를 여러 단계로 연결했다
11주근거를 붙이고 반복을 넘긴다
12주그 흐름이 깨지는 곳을 찾는다
로직은 이미 있습니다. 이번 주는 그 로직에 근거와 실행을 붙이는 주간입니다.
사례

같은 질문이 매주 반복될 때

“학생회 문의함에 신입생 질문이 계속 들어온다” — 세 칸으로 옮겨 봅니다.
트리거문의 폼에 새 질문이 접수되면 시작합니다 처리공지·규정 자료에서 근거를 찾아 3문장 초안을 씁니다 출력담당자 채팅방으로 초안과 출처를 함께 보냅니다
마지막 발송은 사람이 누릅니다. 확인 단계를 남기는 것이 이 설계의 핵심입니다.
오늘 만드는 것

자동화 설계도 + 시범 실행 결과

트리거 / 처리 / 출력 — 각각 한 문장으로
  • 지식 자료 5개 — 제목·출처·날짜를 정리해 도우미에 연결
  • 질문 10개 시험 — 근거를 인용하는지, 없는 말을 지어내는지 확인
  • 시범 실행 1회 — 손으로 할 때와 걸린 시간을 비교해 기록
자료와 자동화 대상에 타인의 이름·연락처·학번이 없는지 먼저 점검하십시오.
정리

오늘의 세 문장

  • RAG는 외우는 구성이 아니라 찾아 인용하는 구성이다.
  • 자동화의 단위는 트리거·처리·출력 세 칸이다.
  • 손으로 세 번 해 본 절차만 기계에 넘긴다.
다음 주 이 흐름을 공격합니다. 정상 경로에서만 도는 자동화는 아직 검증된 것이 아닙니다.
PART 3 · WEEK 11

No-Code Automation and Connecting Knowledge

Attaching your own material to AI, and handing repetition to a machine
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“An AI that has never seen
your rules — can you trust its answer?”
The model knows the world. It does not know your material.
KEY CONCEPT 1

It looks things up, it does not recall them

RAG = the model answers not from memory but by looking things up and citing the documents you gave it.

How it works

A question arrives, the relevant passages are found first, and only those become the answer.

The real gain

You get a citation. An answer you can check is a different thing from one you cannot.

Common mistake

Uploading material does not train the model. It only reads it at the moment you ask.

Watch out

Feed it wrong material and the answer is wrong. A citation does not make it right.

KEY CONCEPT 2

The unit of automation is three boxes

① Trigger · when

What starts it. A set time, an arriving message, a submitted form.

② Process · what

What rule turns the input into something else. Summarize, sort, or record.

③ Output · where

Who receives the result, in what form. No receiver means no automation.

If you cannot fill all three boxes with one sentence each, it is not ready to automate. Settle the procedure first.
KEY CONCEPT 3

Organized beats plentiful

Five clean documents

Title, source and date on each, no duplicates — and the citations land in the right place.

Fifty messy ones

Mix last year's rules with this year's and the assistant will quote last year's.

The quality of your assistant is set by the material you feed it, not by the model.
KEY CONCEPT 4

By hand three times first

Do it by handrun it yourself and meet the exceptions
Fix the stepswrite trigger, process and output in one line each
Hand it overrun it once and compare the time it took
Automate a procedure you have never run yourself and, when the output looks wrong, you cannot tell which step broke.
THE MAP

Where this week sits

Week 9drew the procedure as a flowchart
Week 10chained instructions into stages
Week 11attach evidence, hand off repetition
Week 12find where that flow breaks
The logic already exists. This week you attach evidence and execution to it.
CASE

When the same question arrives every week

“First-years keep asking the student council the same things” — move it into the three boxes.
TriggerA new question lands in the enquiry form ProcessFind the basis in the notices and rules, draft three sentences OutputSend the draft with its sources to the staff chat
A person still presses send. Keeping that review step is the point of this design.
WHAT YOU MAKE TODAY

A pipeline design + one trial run

trigger / process / output — one sentence each
  • Five documents — title, source and date recorded, connected to the assistant
  • Ten test questions — does it cite the material, or invent what isn't there
  • One trial run — record the time and compare it against doing it by hand
First check that no one else's name, contact detail or student ID is in the material.
WRAP-UP

Three sentences from today

  • RAG does not memorize. It looks up and cites.
  • The unit of automation is trigger, process, output.
  • Only hand over a procedure you have run by hand three times.
Next week we attack this flow. An automation that only survives the happy path is not tested yet.
PART 3 · 12주차

예외 처리와 레드티밍

내 해법을 가장 세게 공격해 보는 시간
PBLⅠ · AI Problem Solving
오늘의 질문
“내 해법이 무너진다면,
어디서부터 무너집니까?”
내가 먼저 찾지 않으면, 발표장에서 남이 찾아 줍니다.
핵심 개념 1

정상 경로의 착시

순서도의 “예” 경로만 따라가면 모든 해법은 완벽합니다. 사고는 언제나 “아니오”에서 납니다.

정의

정상 경로 = 모든 조건이 예상대로 맞아떨어지는, 단 하나의 경로입니다.

예시

“학생증이 인식된다”가 예. 인식되지 않으면? 그 칸은 대개 비어 있습니다.

흔한 오해

예외는 드무니 나중에 봐도 된다? 쓰는 사람이 늘면 매일 일어납니다.

주의

“그럴 리 없다”는 대비가 아닙니다. 그때 무엇을 할지 적어야 대비입니다.

핵심 개념 2

예외는 세 종류다

① 실수

오타·빈칸·잘못된 파일. 막기보다 되돌릴 수 있게 만드는 편이 낫습니다.

② 악용

일부러 규칙을 비틉니다. 얻는 이득을 없애면 시도 자체가 줄어듭니다.

③ 엣지케이스

드문 조건. 동명이인, 자정 직후, 휴학생. 미리 정의해 두어야 합니다.

셋은 대비가 서로 다릅니다. 하나의 대책으로 셋을 덮으려 하면 어느 것도 막지 못합니다.
핵심 개념 3

리뷰와 레드팀은 다르다

리뷰

잘된 점을 확인하고 다듬습니다. 기분은 좋지만 약점은 그대로 남습니다.

레드팀

무너뜨리는 것이 목적입니다. 아픈 지적일수록 값이 큽니다.

아프지 않은 피드백은 아직 검증이 아닙니다.
핵심 개념 4

공격을 자산으로 바꾸는 3단계

공격받기가장 센 반박 5개를 그대로 받아 적는다
분류하기고칠 것·반박할 것·범위 밖을 나눈다
대응 쓰기지적마다 한 문장 대응 논리를 붙인다
모든 지적을 고칠 필요는 없습니다. 다만 답하지 않은 지적이 남아서는 안 됩니다.
전체 지도

이번 주가 놓인 자리

9–10주절차와 지시를 로직으로 만들었다
11주자료를 붙이고 자동으로 돌렸다
12주그 로직이 깨지는 곳을 찾는다
13주버틸 수 있는 만큼만 만든다
이번 주에 찾아낸 구멍이 다음 주 프로토타입의 범위를 정합니다.
사례

한 화면에서 나오는 세 종류의 예외

“도서관 빈자리를 알려 주는 서비스” — 예외마다 대비가 다릅니다.
실수퇴실 버튼을 안 누르고 나갑니다 → 30분 뒤 자동 해제 악용친구 자리를 미리 잡습니다 → 1인 1좌석, 재예약 대기 엣지케이스시험 기간 자정 이후 → 운영 시간 밖 규칙을 명시
대비를 적는 순간 예외는 사고가 아니라 설계의 일부가 됩니다.
오늘 만드는 것

예외 시나리오 표 + 대응서 + 윤리 점검표

언제 / 무엇이 잘못되는가 / 그때 무엇을 하는가
  • 예외 시나리오 표 — 실수·악용·엣지케이스마다 최소 한 줄
  • 레드팀 대응서 — 아픈 지적 5개와 각각의 처리 방식 구분
  • 윤리 점검표 — 피해 가능 집단, 개인정보, 책임 주체
9주차 순서도의 모든 “아니오” 칸이 채워졌을 때 이 표는 완성됩니다.
정리

오늘의 세 문장

  • 해법은 정상 경로가 아니라 “아니오” 경로에서 판정된다.
  • 예외는 실수·악용·엣지케이스 셋이고 대비가 각각 다르다.
  • 피해자와 책임 주체를 못 적으면 설계를 고쳐야 한다.
다음 주 드디어 만듭니다. 오늘 찾은 약점이 무엇을 먼저 만들지 정해 줍니다.
PART 3 · WEEK 12

Exception Handling and Red Teaming

The week you attack your own solution as hard as you can
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“If your solution breaks,
where does it break first?”
Find it yourself, or someone finds it for you during the final pitch.
KEY CONCEPT 1

The illusion of the happy path

Follow only the “yes” arrows of a flowchart and every solution looks perfect. Things blow up on the “no”.

Definition

The happy path is the single route where every condition falls out exactly as expected.

Example

“The student card scans” is the yes. And if it doesn't? That box is usually empty.

Common mistake

Exceptions are rare, so deal with them later? With more users they happen daily.

Watch out

“That won't happen” is not a defense. Writing what you do then is a defense.

KEY CONCEPT 2

Three kinds of exception

① Mistakes

Typos, blanks, the wrong file. Better to make them reversible than to block them.

② Abuse

Someone bends the rule on purpose. Remove the gain and the attempts drop.

③ Edge cases

Rare conditions. Same names, just past midnight, students on leave. Define them up front.

Each needs a different defense. Cover all three with one measure and you stop none of them.
KEY CONCEPT 3

A review is not a red team

Review

Confirms what works and polishes it. It feels good, and the weak points survive.

Red team

Exists to bring it down. The more a criticism stings, the more it is worth.

Feedback that doesn't sting is not yet a test.
KEY CONCEPT 4

Turning an attack into an asset

Take the hitwrite down the 5 hardest objections verbatim
Sort themfix it, rebut it, or declare it out of scope
Write the answerone sentence of response per objection
You don't have to fix every criticism. But no criticism may go unanswered.
THE MAP

Where this week sits

Weeks 9–10turned the procedure into logic
Week 11attached material and ran it
Week 12find where that logic breaks
Week 13build only what can hold
The holes you find today decide the scope of next week's prototype.
CASE

Three exceptions on one screen

“A service that shows free library seats” — each exception needs its own defense.
MistakePeople leave without checking out → auto-release after 30 min AbuseHolding a seat for a friend → one seat per person, rebooking delay Edge casePast midnight in exam season → state the out-of-hours rule
The moment you write the defense, an exception stops being an accident and becomes part of the design.
WHAT YOU MAKE TODAY

Exception table + response doc + ethics check

when / what goes wrong / what you do about it
  • Exception table — at least one row for mistake, abuse and edge case
  • Red team response — the 5 stinging criticisms and how you handle each
  • Ethics check — who could be harmed, what personal data, who is accountable
The table is finished only when every “no” box in your Week 9 flowchart is filled.
WRAP-UP

Three sentences from today

  • A solution is judged on its “no” paths, not its happy path.
  • Exceptions come in three kinds — mistake, abuse, edge case — with three defenses.
  • If you can't name who is harmed and who is accountable, fix the design.
Next week we finally build. The weaknesses you found today decide what gets built first.
PART 4 · 13주차

프로토타입 제작

설명하지 말고 보여 주기 — 작동하는 최소 시제품
PBLⅠ · AI Problem Solving
오늘의 질문
“말로 설명하지 않고,
지금 그것을 보여 줄 수 있습니까?”
설명이 필요한 시제품은 아직 시제품이 아닙니다.
핵심 개념 1

MVP의 M은 최소다

MVP = 성공 기준 하나를 확인할 수 있는 가장 작은 것. 그 이상은 이번 주 일이 아닙니다.

정의

무엇을 확인할지 먼저 정하고, 그 확인에 필요한 기능만 남깁니다.

예시

“사람들이 실제로 신청하는가”를 보려면 신청 화면 하나면 충분합니다.

흔한 오해

최소는 대충이 아닙니다. 범위는 작되, 그 안에서는 끝까지 작동합니다.

주의

기능이 셋을 넘으면 무엇 덕분에 통과했는지 알 수 없게 됩니다.

핵심 개념 2

화면 흐름은 세 장면이면 된다

① 첫 화면

여기가 무엇을 하는 곳인지 3초 안에 알 수 있어야 합니다.

② 핵심 행동

사용자가 눌러야 할 단 하나의 버튼은 무엇입니까.

③ 결과 확인

무엇이 달라졌는지 사용자가 눈으로 확인합니다.

세 장면으로 그려지지 않으면 범위가 아직 큽니다. 도구를 켜기 전에 종이에 먼저 그리십시오.
핵심 개념 3

진짜여야 하는 것과 가짜여도 되는 것

진짜여야 하는 것

사용자가 겪는 경험. 눌렀으면 결과가 오고, 끝까지 막히지 않습니다.

가짜여도 되는 것

속의 처리. 뒤에서 사람이 직접 해도 검증에는 충분합니다.

검증되는 것은 만든 방식이 아니라 사용자가 겪은 경험입니다.
핵심 개념 4

오늘의 제작 3단계

범위 자르기확인에 필요 없는 기능을 전부 지운다
흐름 그리기첫 화면·핵심 행동·결과를 세 장면으로
만들고 시연거칠어도 끝까지 작동하는 v1을 써 본다
만드는 시간보다 지우는 시간이 중요합니다. 지운 만큼만 오늘 안에 끝납니다.
전체 지도

이번 주가 놓인 자리

11–12주흐름을 짜고 예외를 정리했다
13주손에 잡히는 v1을 만든다
14주사용자에게 시켜 근거를 모은다
15주문제부터 검증까지 8분에 증명한다
오늘부터 근거는 문서가 아니라 작동하는 것입니다.
사례

기능 목록을 셋으로 자르기

“자취생 식자재 나눔” — 성공 기준은 “한 주에 세 건이 성사되는가”입니다.
남긴 기능나눌 물건 올리기 · 목록 보기 · 신청 버튼 지운 기능로그인, 채팅, 평점, 지도 — 확인에 필요 없습니다 사람이 대신성사 알림은 운영자가 직접 보냅니다
기능 셋, 화면 셋. 이 크기라야 다음 주에 사용자 앞에 놓을 수 있습니다.
오늘 만드는 것

프로토타입 v1 + 사용 시나리오 대본

첫 화면 → 핵심 행동 → 결과 확인
  • 프로토타입 v1 — 링크 또는 캡처, 끝까지 작동할 것
  • 사용 시나리오 대본 — 누가 무엇을 눌러 무엇을 얻는가
  • 막힌 지점 목록 — 자가 시연에서 멈춘 곳을 전부 기록
예쁘게 만들지 마십시오. 거칠어야 사람들이 색깔 대신 본질을 지적합니다.
정리

오늘의 세 문장

  • MVP의 M은 최소다. 성공 기준 하나만 확인하면 된다.
  • 속이 가짜여도 사용자가 겪는 경험이 진짜면 검증된다.
  • 완성도를 올릴수록 피드백의 초점이 흐려진다.
다음 주 사용자에게 직접 시켜 봅니다. “좋아 보인다”가 아니라 근거로 말해야 합니다.
PART 4 · WEEK 13

Building the Prototype

Show it, don't explain it — the smallest thing that works
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Without explaining it,
can you show it to me right now?”
A prototype that needs explaining is not a prototype yet.
KEY CONCEPT 1

The M in MVP is minimum

MVP = the smallest thing that can test one success criterion. Anything more is not this week's job.

Definition

Decide what you are testing first, then keep only the features that test it.

Example

To learn whether people actually sign up, one sign-up screen is enough.

Common mistake

Minimum is not sloppy. The scope is small, but inside it everything works.

Watch out

Past three features you can no longer tell which one made it work.

KEY CONCEPT 2

Three scenes are enough

① First screen

Three seconds to understand what this place is for.

② Core action

What is the single button the user has to press?

③ Seeing the result

The user sees, with their own eyes, what changed.

If it doesn't fit in three scenes, the scope is still too big. Draw it on paper before opening any tool.
KEY CONCEPT 3

What must be real, what may be fake

Must be real

The user's experience. They press, a result comes back, nothing dead-ends.

May be fake

The machinery behind it. A person doing it by hand is enough to validate.

What gets tested is the experience the user had, not how you built it.
KEY CONCEPT 4

Today's build, three moves

Cut the scopedelete every feature the test doesn't need
Draw the flowfirst screen, core action, result — three scenes
Build and demorough is fine, but it must work end to end
The time you spend deleting matters more than the time you spend building. You finish what you cut.
THE MAP

Where this week sits

Weeks 11–12built the flow, listed the exceptions
Week 13make a v1 people can touch
Week 14put it in users' hands, gather evidence
Week 15prove problem to validation in 8 minutes
From today your evidence is not a document. It is something that runs.
CASE

Cutting the feature list to three

“Sharing leftover groceries between students” — success is three completed swaps in a week.
KeptPost an item · browse the list · a request button DeletedLogin, chat, ratings, map — none of it tests the criterion Done by handThe match notice is sent by the organizer personally
Three features, three screens. Only at that size can it be in front of users next week.
WHAT YOU MAKE TODAY

Prototype v1 + a usage scenario script

first screen → core action → seeing the result
  • Prototype v1 — a link or screenshots, working end to end
  • Usage scenario script — who presses what, and what they get
  • Stuck-point list — every place your self-demo stalled
Don't make it pretty. Rough is what makes people comment on substance instead of colors.
WRAP-UP

Three sentences from today

  • The M in MVP is minimum. One success criterion is all you test.
  • The inside may be fake as long as the user's experience is real.
  • The more polish you add, the more the feedback loses its focus.
Next week real users try it. You will have to speak from evidence, not from “it looks good”.
PART 4 · 14주차

해결책 검증 · CER과 사용자 테스트

“좋아 보인다”가 아니라 근거로 말하기 — 다섯 명이면 시작할 수 있다
PBLⅠ · AI Problem Solving
오늘의 질문
“이 해법이 통한다는
증거가 무엇입니까?”
“제가 써 보니 괜찮던데요”는 증거가 아니라 소감입니다.
핵심 개념 1

검증은 확인이 아니라 반증 시도다

검증은 내 해법이 옳음을 확인하는 절차가 아니라, 스스로에게 틀릴 기회를 주는 절차입니다.

가설

“이 해법을 쓰면 [무엇]이 [얼마나] 달라진다.” 반증 가능해야 가설입니다.

데이터

끝까지 했는가 · 몇 초 걸렸는가 · 어디서 멈췄는가.

흔한 오해

“좋아요”는 데이터가 아니라 예의입니다. 근거로 쓰지 마십시오.

주의

지표를 테스트 뒤에 정하면 결과에 맞춰 지표가 휩니다.

핵심 개념 2

CER — 주장 · 근거 · 추론

① 주장 Claim

데이터에서 내린 한 문장의 결론. “쓸 만하다”는 주장이 아닙니다.

② 근거 Evidence

관찰된 수치. 몇 명 중 몇 명이, 몇 초에, 어느 지점에서.

③ 추론 Reasoning

그 근거가 왜 그 주장을 지지하는지 잇는 문장.

세 칸 중 하나라도 비면 감상문입니다. 근거 없는 주장도, 주장 없는 데이터도 리포트가 아닙니다.
핵심 개념 3

5명으로 알 수 있는 것과 없는 것

알 수 있는 것

어디서 막히는가, 무엇을 오해하는가. 치명적 결함은 대부분 5명 안에서 드러납니다.

알 수 없는 것

비율입니다. 5명 중 4명은 80%가 아닙니다. “대부분의 사용자가”라고 쓰지 마십시오.

5명은 결함을 찾는 도구이지, 세상을 재는 자가 아닙니다.
핵심 개념 4

사용자 테스트 3단계

과제를 준다시연 없이 “이걸로 ○○을 해 보세요”만 말한다
침묵한다돕지 말고 멈춘 지점과 걸린 시간을 적는다
끝나고 묻는다그때 왜 멈췄는지만 묻는다
힌트를 주는 순간 그 사람의 데이터는 사라집니다. 불편한 침묵이 관찰의 조건입니다.
전체 지도

이번 주가 놓인 자리

12주내 해법을 스스로 공격했다
13주작동하는 v1을 만들었다
14주남에게 시켜 보고 v2로 고친다
15주8분 안에 증명한다
12주는 내가 상상한 공격, 14주는 실제 사용자가 가하는 공격입니다. 후자가 언제나 더 정확합니다.
사례

조별과제 일정 조율 시트, 5명 테스트

v1을 다섯 명에게 힌트 없이 써 보게 하고 행동만 기록했습니다.
가설이 시트를 쓰면 일정 확정이 3일에서 1일로 줄어든다 관찰5명 중 3명이 마감 입력 칸을 건너뜀 · 평균 4분 12초 결정마감 칸을 맨 위로 이동 — v2에서 이 한 곳만 수정
나쁜 서술: “대부분의 사용자가 어려워했다.” CER: 주장 — 마감 입력에서 이탈한다 / 근거 — 5명 중 3명이 그 칸을 건너뜀 / 추론 — 칸이 화면 아래에 있었다.
오늘 만드는 것

검증 리포트(CER) + 프로토타입 v2

주장 — 근거 — 추론, 세 문장이 한 세트
  • 가설과 지표 — 테스트 전에 확정한 반증 가능한 문장
  • CER 3세트 — 관찰된 수치를 붙인 결론 세 개
  • v2 수정 1~2곳 — 가장 많이 걸린 지점만 고친다
가설이 기각되었다면 그대로 쓰십시오. 실패도 완전한 결과입니다.
정리

오늘의 세 문장

  • 검증은 확인이 아니라 반증 시도다.
  • 주장마다 숫자와 관찰을 붙여라. 없으면 감상문이다.
  • 5명은 결함을 찾는 도구다. 비율을 말하지 마라.
다음 주 한 학기를 8분에 증명합니다. 한계를 스스로 밝히는 팀이 가장 높은 점수를 받습니다.
PART 4 · WEEK 14

Validating the Solution · CER and User Testing

Speaking from evidence, not from “it looks good” — five people is enough to start
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“What is your evidence
that this solution works?”
“I tried it and it felt fine” is an impression, not evidence.
KEY CONCEPT 1

Validation is an attempt to disprove

Validation is not the step where you confirm you were right. It is where you give yourself a chance to be wrong.

Hypothesis

“Using this changes [what] by [how much].” If it can't be disproved, it isn't one.

Data

Did they finish · how many seconds · where exactly did they stop.

Common mistake

“I like it” is politeness, not data. Never use it as evidence.

Watch out

Pick metrics after the test and they bend to fit the result.

KEY CONCEPT 2

CER — claim, evidence, reasoning

① Claim

One sentence you concluded from the data. “It works well” is not a claim.

② Evidence

What you observed. How many of how many, in how many seconds, where.

③ Reasoning

The sentence that links why this evidence supports that claim.

Leave any of the three empty and it is a personal impression. A claim without evidence and data without a claim are equally useless.
KEY CONCEPT 3

What five users can and cannot tell you

They can tell you

Where people get stuck and what they misread. Most fatal flaws show up within five.

They cannot tell you

Proportions. Four of five is not 80%. Never write “most users” after testing five.

Five people are a tool for finding flaws, not a ruler for measuring the world.
KEY CONCEPT 4

Running a test, three moves

Give a taskno demo — just “use this to do X”
Stay silentdon't help; note where they stall and for how long
Ask afterwardsonly one question: why did you stop there?
The moment you give a hint, that person's data is gone. Awkward silence is the condition for observing anything.
THE MAP

Where this week sits

Week 12you attacked your own solution
Week 13you built a v1 that runs
Week 14others use it; you revise to v2
Week 15you prove it in eight minutes
Week 12 was the attack you imagined. Week 14 is the attack real users actually make. The second one is always more accurate.
CASE

A group-project scheduling sheet, tested on five

Five people used v1 with no hints. Only behaviour was recorded.
HypothesisWith this sheet, settling a date drops from 3 days to 1 Observed3 of 5 skipped the deadline field · 4 min 12 s on average DecisionMove the deadline field to the top — the only v2 fix
Badly written: “Most users found it hard.” As CER: claim — people drop out at the deadline field / evidence — 3 of 5 skipped it / reasoning — the field sat below the fold.
WHAT YOU MAKE TODAY

Validation report (CER) + prototype v2

claim — evidence — reasoning: three sentences, one set
  • Hypothesis and metrics — falsifiable, fixed before the test
  • Three CER sets — three conclusions, each with observed numbers
  • One or two v2 fixes — only where people got stuck most
If the hypothesis was rejected, write that. A rejected hypothesis is a complete result.
WRAP-UP

Three sentences from today

  • Validation is not confirmation. It is an attempt to disprove.
  • Attach numbers and observations to every claim, or it's an opinion.
  • Five people find flaws. They do not give you percentages.
Next week you prove a whole semester in eight minutes. The teams that name their own limits score highest.
PART 4 · 15주차

최종 캡스톤 · Solution Pitch

문제 – 해법 – 로직 – 검증을 8분에 증명하기
PBLⅠ · AI Problem Solving
오늘의 질문
“당신의 8분이 끝났을 때,
청중은 무엇을 믿게 됩니까?”
발표는 한 학기의 요약이 아니라 하나의 주장에 대한 증명입니다.
핵심 개념 1

피치는 보고가 아니라 증명이다

한 일을 나열하는 자리가 아닙니다. 문제 – 해법 – 로직 – 검증이 한 줄로 이어져야 합니다.

시작

통계가 아니라 구체적인 장면 하나로 엽니다. 숫자는 그다음입니다.

선정 근거

버린 안을 먼저 보이면 고른 안이 설득됩니다.

흔한 실수

주차별로 한 일을 시간순 나열합니다. 그것은 일지입니다.

주의

슬라이드를 읽지 마십시오. 청중은 이미 읽었습니다.

핵심 개념 2

8분이 증명해야 할 세 가지

① 문제는 실재한다

누가 언제 어떤 손해를 보는지 한 장면으로 보입니다.

② 해법은 작동한다

설명하지 말고 그 자리에서 돌립니다. 실패해도 그대로 보입니다.

③ 결론은 검증됐다

가설 지지 여부를 먼저 말하고 근거 데이터를 붙입니다.

셋 중 하나가 비면 나머지 둘도 무너집니다. 8분은 이 세 가지에만 쓰십시오.
핵심 개념 3

한계는 감출수록 커진다

먼저 밝힌 한계

“20명 이하 모임에서만 검증했습니다.” 신뢰가 올라갑니다.

감춘 한계

질의 4분에 반드시 드러납니다. 그때는 설명이 아니라 변명이 됩니다.

자기 해법의 한계를 아는 사람만이 그 해법을 책임질 수 있습니다.
핵심 개념 4

리허설 3단계

소리 내어속으로 읽으면 막히는 문장이 보이지 않는다
시계를 켜고8분을 넘기면 잘라낼 것을 먼저 정한다
남 앞에서모르는 한 사람에게 시연까지 통째로
리허설 없는 발표는 발표가 아니라 즉흥입니다. 시연은 반드시 두 번 이상 돌려 보십시오.
전체 지도

한 학기가 지나온 길

1–4주문제를 정의했다
5–8주대안을 넓히고 하나를 골랐다
9–13주로직으로 옮기고 만들었다
14–15주검증하고 증명한다
오늘 발표하는 것은 완성품이 아니라 한 학기의 판단 과정입니다. 판단이 보이면 결과는 작아도 됩니다.
사례

8분을 어떻게 쓰는가

조별과제 일정 조율 시트 팀의 실제 배분입니다.
1분 · 문제사흘간 메시지 60개를 주고받고도 날짜가 안 잡힌 밤 4분 · 해법과 시연버린 안 두 개를 먼저 보이고, 시트를 실제로 돌린다 3분 · 검증과 한계5명 중 4명이 1일 내 확정 · 6명 이상은 미검증
시간이 모자라면 한계가 아니라 배경 설명을 자르십시오. 한계 항목이 평가에서 가장 큽니다.
오늘 만드는 것

최종 제출물 네 가지

문제 → 원인 → 대안과 선정 → 로직 → 검증 → 한계, 끊기지 않는 한 줄
  • 해결 로직 명세서 + 프로토타입 — 순서도와 예외 처리, 작동하는 v2
  • 검증 리포트 — 가설 · 지표 · CER 3세트 · 한계
  • 동료 검토서 — 반영한 것과 반영하지 않은 것, 그 이유
부록에 실패한 시도를 남기십시오. 평가 비중 40%입니다.
정리

마지막 세 문장

  • 발표는 요약이 아니라 증명이다. 세 가지만 증명하라.
  • 말하지 말고 돌려서 보여라. 실패한 시연도 데이터다.
  • 한계를 먼저 말하는 사람이 가장 신뢰받는다.
한 학기 동안 배운 것은 도구가 아니라 순서입니다. 불평을 정의된 문제로 바꾸고, 설계한 로직으로 옮기고, 사람에게 시켜 확인하는 일 — 이 습관은 어떤 전공, 어떤 자리에서도 그대로 작동합니다.
PART 4 · WEEK 15

Final Capstone · Solution Pitch

Proving problem – solution – logic – validation in 8 minutes
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“When your eight minutes end,
what does the room believe?”
A pitch is not a summary of your semester. It is proof of one claim.
KEY CONCEPT 1

A pitch proves; it does not report

This is not the place to list what you did. Problem – solution – logic – validation must read as one line.

Opening

Start with one concrete scene, not a statistic. Numbers come after.

Rationale

Show what you dropped first, and the option you kept becomes convincing.

Common mistake

Listing what you did week by week. That is a logbook, not a pitch.

Watch out

Don't read your slides aloud. The room has already read them.

KEY CONCEPT 2

Three things the eight minutes must prove

① The problem is real

One scene showing who loses what, and when.

② The solution runs

Don't describe it, run it live. If it breaks, show that too.

③ The result is tested

Say whether the hypothesis held, then attach the data.

Leave one of the three empty and the other two collapse with it. Spend the eight minutes on nothing else.
KEY CONCEPT 3

Hidden limits only grow

Named up front

“We only tested it on groups of 20 or fewer.” Trust goes up, not down.

Hidden

It surfaces in the four minutes of questions — and then it sounds like an excuse.

Only someone who knows where a solution fails can take responsibility for it.
KEY CONCEPT 4

Rehearsal, three passes

Out loudread it silently and you never hear the broken sentence
On the clockover eight minutes? decide what to cut first
In front of someoneone stranger, the whole thing, demo included
A talk without rehearsal is improvisation. Run the live demo at least twice before you stand up.
THE MAP

The road this semester took

Weeks 1–4you defined the problem
Weeks 5–8you widened, then chose one option
Weeks 9–13you turned it into logic and built it
Weeks 14–15you tested it and now prove it
What you present today is not a finished product. It is a semester of judgement. If the judgement shows, the result can be small.
CASE

How one team spent the eight minutes

The group-project scheduling sheet team, minute by minute.
1 min · ProblemThree days, 60 messages, and still no date agreed 4 min · Solution + demoTwo dropped options first, then the sheet running live 3 min · Results + limits4 of 5 settled within a day · untested above 6 people
Running short? Cut the background, never the limits. That section carries the most weight in the grade.
WHAT YOU MAKE TODAY

Four final submissions

problem → cause → alternatives → logic → validation → limits, one unbroken line
  • Logic spec + prototype — flowchart, exception handling, a working v2
  • Validation report — hypothesis · metrics · 3 CER sets · limits
  • Peer review document — what you acted on, what you didn't, and why
Leave the failed attempts in the appendix. This carries 40% of the grade.
WRAP-UP

Three last sentences

  • A pitch is proof, not a summary. Prove three things only.
  • Don't describe it — run it. A demo that fails is still data.
  • The person who names the limits first is the one people trust.
What you learned this semester is not a tool but an order of operations: turn a complaint into a defined problem, move that problem into a logic you designed, then hand it to real people and check. That habit works in any major and any job you walk into.