Claude Architect · 강의

범주별 예시

보고할 항목과 무시할 항목의 예시를 보여줍니다

레슨 2/413개 단계

범주별 예시은(는) CoddyKit의 무료 Claude Architect 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Claude Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Categorical Examples Matter

When you give Claude a job that has a fuzzy boundary, vague instructions like "be more precise" rarely work. The model can't read your mind about where the line sits.

The reliable fix is categorical examples: a small set of 2-4 few-shot examples that show concrete cases of what to report and what to ignore. The model generalizes from these examples to new, unseen inputs — it does not merely repeat them.

This lesson shows how to build those examples for a classic architect task: deciding what is worth flagging and what is noise.

Explicit Criteria Beat Vague Adjectives

Before you even reach for examples, state an explicit criterion. Explicit rules consistently beat vague adjectives.

  • Vague: "Review the code carefully."
  • Explicit: "Flag a comment only when it contradicts the code it describes."

The explicit version draws a sharp line. Categorical examples then make that line unmistakable by pinning it to concrete cases on each side.

system = (
    "You review code comments. "
    "Flag a comment ONLY when it contradicts the code it describes. "
    "Ignore style, tone, and outdated-but-harmless notes."
)

The Shape of a Categorical Example Set

A good set has examples on both sides of the boundary, each with a one-line reason. Two REPORT cases and two IGNORE cases is enough for most ambiguities — 2-4 targeted examples is the sweet spot.

Each example carries three parts:

  • the input (the thing being judged)
  • the verdict (report / ignore)
  • a short reason tied to your criterion

The reason is what lets the model generalize correctly instead of pattern-matching on surface features.

Worked Example: Report vs Ignore

Here is a categorical example block for the comment-review task. Notice the symmetry: contradictions are reported; harmless mismatches are ignored.

EXAMPLES = """
<example verdict="REPORT">
  code: return price * 1.2
  comment: # applies 10% tax
  reason: comment says 10% but code applies 20% (contradiction)
</example>
<example verdict="IGNORE">
  code: timeout = 30  # seconds
  comment: # seconds
  reason: accurate; matches the code
</example>
<example verdict="IGNORE">
  code: # TODO: refactor later
  comment: # TODO: refactor later
  reason: stylistic note, not a contradiction
</example>
<example verdict="REPORT">
  code: if user.is_admin: deny()
  comment: # allow admins
  reason: comment says allow but code denies (contradiction)
</example>
"""

Generalization, Not Memorization

The power of categorical examples is that the model generalizes. It does not need an example for every possible input.

From the four cases above, Claude learns the rule "flag semantic contradictions, ignore harmless mismatches" and applies it to a brand-new comment it has never seen, such as a docstring that claims a function returns a list when it returns a dict.

This is why few-shot examples are ideal for consistency, edge cases, output format, and reducing hallucination.

Pin the Edges of the Boundary

The most valuable examples sit right at the boundary, where the decision is genuinely hard. A near-miss IGNORE next to a near-hit REPORT teaches far more than two obvious cases.

For a research agent deciding which statistics to surface, you might contrast a stale figure with a current one — and note that dates often resolve apparent contradictions rather than one number simply being wrong.

EXAMPLES = """
<example verdict="REPORT">
  fact: "Revenue was $4.1B in FY2024" (source dated 2025-02)
  reason: current, sourced, on-topic -> surface it
</example>
<example verdict="IGNORE">
  fact: "Revenue was $3.2B" (source dated 2019, no fiscal year)
  reason: stale and undated for our scope -> drop, do not treat as a conflict
</example>
"""

Examples Drive Structured Output Too

Categorical examples pair naturally with structured output. When the verdict must be machine-readable, force a tool call so the result is valid JSON every time.

Use tool_choice of type "any" to guarantee the model calls some tool (guaranteeing structured output), or force one specific tool by name. A JSON Schema then eliminates syntax errors and enforces required fields.

tools = [{
    "name": "record_finding",
    "description": "Record a review verdict for one item.",
    "input_schema": {
        "type": "object",
        "properties": {
            "verdict": {"enum": ["report", "ignore"]},
            "reason": {"type": "string"}
        },
        "required": ["verdict", "reason"]
    }
}]

resp = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=512,
    tools=tools,
    tool_choice={"type": "any"},
    system=system,
    messages=[{"role": "user", "content": EXAMPLES + new_item}],
)

Only Require Fields That Always Exist

A subtle trap: in your finding schema, mark a field required only if it is always present. If you require a field that may be absent — say a line_number for findings that aren't line-specific — the model will fabricate a value to satisfy the schema.

For categories that may grow, use an enum plus an "other" value and a free-text detail field. That keeps the output structured while staying extensible.

"category": {"enum": ["contradiction", "security", "other"]},
"category_detail": {"type": "string"}  # filled when category == other
# line_number is NOT required: many findings are file-level

When Examples Are the Wrong Tool

Categorical examples sharpen a judgment boundary. They do not invent missing information.

If the model returns an empty or wrong result because the needed fact is simply absent from the source, more examples won't help — and neither will retry-with-feedback. Retry fixes format, structural, and arithmetic errors, not absent data.

Distinguish a genuine empty result ("no matches found") from an access failure (the source couldn't be read). Treat them differently in your recovery logic.

Categorical Examples in CLAUDE.md and Reviews

Bake your report/ignore policy where the work happens. For a CI review job, put the examples in project-level CLAUDE.md (shared via VCS) so every run and every teammate inherits the same boundary.

In CI, run the review in an isolated session (less biased than the generation context) with -p for non-interactive output. Explicit criteria plus categorical examples are exactly how you minimize false positives.

## Review policy (categorical)
REPORT: a comment that contradicts the code it describes.
IGNORE: style nits, tone, outdated-but-harmless TODOs.

Example REPORT -> `# 10% tax` over `price * 1.2`
Example IGNORE -> `timeout = 30  # seconds` (accurate)

Putting It Together

The full recipe for a clean report/ignore decision:

  • Write one explicit criterion for the boundary.
  • Add 2-4 categorical examples split across both sides, each with a reason.
  • Pin examples at the hard edges, not the obvious cases.
  • Force structured output with a tool; require only ever-present fields.
  • Remember: examples shape judgment, not missing data.

Do this and Claude generalizes your intent reliably across inputs it has never seen.

Quick Check

A review agent flags too many harmless comments as problems. You want it to report only genuine contradictions. Which change will most reliably tighten the boundary?

Recap

Key takeaways:

  • Explicit criteria + categorical examples beat vague adjectives for fuzzy boundaries.
  • Use 2-4 examples split across report and ignore, each with a reason; the model generalizes, it doesn't just repeat.
  • Pin examples at the hard edges; remember dates often resolve apparent contradictions.
  • Pair with structured output (tool_choice "any" + JSON Schema); require only ever-present fields, use enum+"other" for extensibility.
  • Examples sharpen judgment, not missing data — absent facts need a different fix, and retry only repairs format/arithmetic errors.
무료로 시작

AI 튜터와 함께 Python을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스
26
레슨
104

자주 묻는 질문

“범주별 예시” 강의는 무료인가요?

네 — “범주별 예시” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Claude Architect 강의 전체를 잠금 해제할 수 있습니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

“범주별 예시”에서 뭘 배우나요?

보고할 항목과 무시할 항목의 예시를 보여줍니다 브라우저에서 직접 실행하는 실습 코드로 Claude Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Claude Architect을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Claude Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“범주별 예시” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Claude Architect 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Claude Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 모호한 지시보다 명시적인 기준
  2. 범주별 예시
  3. 예시를 활용한 심각도 기준
  4. 거짓 양성 줄이기
← Claude Architect(으)로 돌아가기