AI Agent TA Skills Training Workshop: Course Outline & Technical Support Guide

This page is the complete course material for this half-day TA training. The first half (Course Information through After the Workshop) is compiled from the planning documents refs/AI-Agent-助教技能培訓工作坊-執行摘要.md and -執行方案.md, covering the workshop's positioning, training goals, audience and scale, afternoon schedule and checkpoints, hands-on scope and principles, on-site support workflow, and data safety and role boundaries. The second half applies the same training spirit concretely to Modules 1–3 on this site — hands-on material originally written for faculty — breaking down where faculty commonly get stuck module by module, what TAs should know beforehand, and quick troubleshooting tables, as concrete practice material and a technical extension for the "vibe coding build" unit.

This session is not meant to train AI experts or software engineers, nor to train TAs to design teaching materials, questions, or assessments themselves. The training emphasis is on "can you discuss something with Codex from scratch, state it clearly, and get it built" — not memorizing how to invoke one specific packaged tool. TAs learn a method, not an operating manual for a particular tool.

Course Information

This workshop may run multiple cohorts depending on registration; the actual date and registration link for each cohort follow that cohort's official announcement.

Afternoon overview (full version with checkpoints in "4. Afternoon Schedule & Checkpoints"):

1. Workshop Positioning

This is a half-day, introductory, hands-on training on personal laptops, aimed at building TAs and administrative staff who can provide first-line support for faculty and colleagues using AI Agents. The priority audience is TAs recommended by faculty or their units; if seats remain, administrative staff with basic computer and AI experience and other interested participants are also welcome. Expected scale is about 30 people, each working independently on their own laptop.

The course uses ChatGPT Codex as the demonstration tool, but the focus isn't learning one specific platform — it's building a working method that transfers to other AI Agents: state the goal, context, constraints, and completion criteria clearly; let AI help produce a tool; find and run the output yourself; test and interpret the results; then revise step by step.

This session is not a course on designing teaching materials, writing questions, or assessment design, nor is it a software-engineer training program, subject-matter review, or administrative-decision course. Its core task is building first-line staff who can support faculty using AI Agents and simple vibe-coding tools, lowering the burden non-engineering faculty face with local installation, file management, execution, testing, and basic troubleshooting. TAs and administrative staff provide technical assistance — helping with environment installation, project folders, file locations, launching tools, basic testing, and organizing problem information; the content of teaching materials, question quality, subject-matter accuracy, and administrative decisions remain the responsibility of faculty, the relevant unit, or subject-matter experts.

2. Training Goals

After this session, participants should be able to first clarify where a problem is and gather the necessary information whenever someone needs help, then assist with the following basic tasks:

1. Explain the difference between a chatbot and an AI Agent, and know which tasks can be handed to AI and which results still need human confirmation.
2. Install, open, and do a first-pass verification of local tools like VS Code, Python, and Node.js, and recognize common sign-in, permission, network, and version issues.
3. Build a clear project folder structure, distinguishing source data, program files, output files, and the run location, and be able to describe a problem using a full file path.
4. Use natural language to do small-scope vibe coding, producing a static HTML tool that can be opened locally.
5. Test a tool from a user's perspective, recording "expected result, actual result, steps taken, and error message or screen," and give the AI Agent a verifiable fix request.
6. Within role boundaries and data-safety principles, help a faculty member or colleague get past a technical hurdle so they can focus on teaching and their own professional work.

3. Audience, Scale & Logistics

4. Afternoon Schedule & Checkpoints

5. Hands-on Scope & Principles

The tool's minimum scope

• Use only HTML, CSS, and the JavaScript necessary to build a single, checkable, simple web tool.
• The tool is opened and tested in a local folder; it does not handle account systems, databases, real-time sync, formal deployment, or a formal assessment system.
• The assessment focus is whether participants can locate, run, test, and fix the tool — not the tool's topic, visual polish, content quality, or code complexity.

Suggested operating sequence

1. Create a project folder, clearly named, separating source data, program files, and output.
2. Tell the AI Agent the tool's users, purpose, feature scope, constraints, and completion criteria.
3. Confirm which files the AI Agent actually created or modified — don't stop at just the chat window.
4. Open the file or start a service locally as needed, testing the feature with a specific scenario.
5. Record the expected result, the actual result, reproduction steps, relevant file paths, and error messages; ask for one verifiable fix at a time.
6. After a fix, redo the same scenario to confirm whether the issue is actually resolved; if not, gather more information or hand it to the right person.

6. How This Differs From the Material's Origin

Modules 1–3, used in this workshop's "vibe coding build" unit, were originally written as hands-on material for non-engineering university faculty (turning their materials into a practice tool). TAs work with the same material, but with a different learning focus — the table below maps the difference:

7. Module 1 for TAs: Windows / Toolchain Setup

Faculty Module 1 sets up a Vibe Coding and AI Agent environment on a Windows 11 laptop, offering three install methods (manual winget, an AI Agent prompt, or the module1-setup-windows.bat one-click script).

Where faculty most often get stuck

• A school-issued laptop lacks administrator rights → winget/UAC installs fail or are blocked.
• Running module1-setup-windows.bat prints winget not found.
• The batch script finishes, but commands are still "not found" → the terminal wasn't closed and reopened, so PATH hasn't taken effect.
• In the very run that just installed VS Code, the 5 extensions get skipped (because code wasn't yet on PATH at that point).
• Using "Install Method 2: AI Agent Prompt" and forgetting to switch Full access back to Ask for approval afterward.
• The ChatGPT account lacks Codex access, or available features vary by plan/workspace/rollout.
• gh auth login gets stuck on the browser sign-in or the one-time code.
• Insufficient disk space: node_modules and Python packages can exceed the originally estimated 10GB.

Prerequisite knowledge and skills for TAs

• The difference between the three install methods and when to switch: manual install is the fallback when school IT restricts winget; the AI-prompt method needs Full access temporarily and must be switched back afterward; the .bat file is safe to rerun and skips already-installed items.
• The 7 version-check commands, so a TA can walk a faculty member through them from scratch: code --version, git --version, node --version, npm --version, uv --version, gh --version, codex --version.
• Basic Windows File Explorer skills: reading folder paths, showing file extensions, extracting downloaded .bat/.tar files, and knowing where the Downloads folder is.
• Basic terminal operations: opening PowerShell/CMD, cd to change directories, dir to list files, opening a terminal as administrator.
• Understanding what a command like winget install --id ... --source winget --exact does, and why it can fail (permissions, network, source configuration).

Quick troubleshooting reference

8. Module 2 for TAs: Building the Exam Download / Slice / Cleanup Pipeline From Scratch

Faculty Module 2's goal is to turn a PDF exam paper into a problem-set folder of clean per-question images plus an answer-key JSON, through three stages — download, slice, clean — where each stage's output feeds the next. The TA training focus here is not memorizing how to invoke one specific packaged tool, but understanding what each stage is actually doing and why it needs to be checked, plus the ability to discuss a pipeline with Codex and design an equivalent process from scratch — so that whichever exam paper a faculty member brings, even a layout that hasn't been handled before, a TA can help think the problem through from first principles instead of getting stuck at "this approach doesn't support that."

Where faculty most often get stuck

• The prompt just says "turn this PDF into one image per question," without stating the output filename rule, the folder location, or the answer-JSON format, so what Codex produces doesn't match what the faculty member expected.
• The wrong group or subject gets matched while downloading the exam page, and it isn't eyeball-checked before moving on.
• Slicing a common-subject paper (math, Chinese, English) whose layout differs from what the processing logic was originally tuned for — filename rules and question-count assumptions built for one type of paper fail, and the faculty member doesn't know how to adjust.
• Skipping the "dry run" before the cleanup stage commits changes — cleanup overwrites images in place with no automatic backup, so a misdetected number block is hard to recover from.
• Assumptions like question count and filename rules tend to get hardcoded into the process, so a differently formatted paper breaks the whole thing, and faculty don't realize they need to spell out the new rule explicitly to Codex.

Prerequisite knowledge and skills for TAs

• Understand each stage's input/output convention (see the pipeline table above), well enough to tell at a glance which stage a faculty member is stuck in.
• Know how to discuss "download the exam and answer PDFs" with Codex by breaking it into an explicit goal, context, constraints, and completion criteria, instead of handing over one sentence and expecting Codex to work out every detail on its own (e.g. keep the original filenames, make it possible to eyeball-check the group/subject).
• Understand where the slicing stage's core limits are (e.g. a fixed page-layout assumption, how question numbers get recognized, how answers get matched to questions), well enough to help a faculty member articulate "why the original approach fails on this new paper" and propose a specific, verifiable fix — instead of redoing the whole thing.
• Know that the cleanup stage must always be dry-run first (print the detection result without touching any pixels), confirming every image detects the expected number of blocks before committing; and that cleanup overwrites in place with no backup, so the only recovery path is re-slicing that question, not patching it during cleanup.
• Be able to use File Explorer or a terminal to check that the image count matches the number of entries in keys.json — a verification method that applies at every stage.

Quick troubleshooting reference

9. Module 3 for TAs: Building the Quiz App From Scratch

Faculty Module 3 starts from a problem-set folder and works through 7 steps with Codex to design a quiz-app generator from scratch. This is the most prompt-heavy stretch of the whole faculty workshop, and the place TAs are most needed to help faculty "say it clearly" — it's also the core demonstration of the whole TA workshop: this is exactly the "discuss it with an AI Agent from scratch, design it, get it built" method the training wants TAs to walk away with, not operating some already-packaged tool.

The 7 steps (TAs should know what's easiest to omit at each one)

Where faculty most often get stuck

• The prompt just says "build me a quiz web page" without the constraints from the table above, so Codex's output drifts or becomes hard to verify.
• The output folder gets nested inside the problem-set folder (breaking the app/-and-repo/-as-siblings rule).
• Double-clicking app/quiz.html (the editable source version, still using fetch()) instead of dist/<examLabel>_quiz.html (the final deliverable) — resulting in a blank page or unresponsive buttons.
• config.json is missing "repoDir": "." (omitting it defaults to "repo", which fails to find the image folder).
• After editing config.json, forgetting to rerun build_bundle.py, and assuming dist/ updates automatically.
• A newly added examLabel collides with an existing one, overwriting it.
• Built N/M shows N<M and the faculty member doesn't notice a bundle failed.

Prerequisite knowledge and skills for TAs

• File-location conventions: app/ is a sibling of repo/; dist/<examLabel>_quiz.html is the only double-click-ready deliverable; config.json's assessments array is meant to grow by appending.
• Be able to verify things directly in a terminal:

# Testing the "editable source" version needs a local server first (the dist/ version does not)
cd module3/app && python3 -m http.server

# Rebuild only the assessment just added, instead of re-bundling everything
python3 build_bundle.py --only <examLabel>

• Know how to read the "Built N/M assessments" summary line — when N<M, look upward for the warning, which is usually a wrong path field.

Quick troubleshooting reference

10. Skills Matrix by Module

11. Troubleshooting Guide

The table below covers cross-module Windows/command-line/AI Agent error patterns; module-specific issues are in the quick-reference tables under each module section above.

12. On-site Support Workflow

When a problem comes up, a TA or administrative staff member can work through it in this order, avoiding repeated trial-and-error before the problem is understood:

1. Locate: Confirm the user, computer, account, project folder, and which module/step they're currently on.
2. Gather: Note the full or relative file path, the command or prompt used, the screen, the error message, and what's already been tried.
3. Classify: Judge whether it's most likely a sign-in/network issue, an install/permission issue, a file-path issue, an unclear prompt, or a tool functionality/result issue.
4. Minimal fix: Change exactly one reversible thing (reopen the right folder, fix one path, rerun one command per the guide), then test immediately.
5. Re-verify: Redo the exact operation that originally failed, and confirm the problem is actually gone — not just that the screen looks different for a moment.
6. Escalate appropriately: Permission, campus-network, account, security, or system-setting issues get logged and handed to IT or the instructor; subject-matter and question-quality judgment calls go back to the faculty member.

Helping faculty improve a vague prompt: the four-element check

A common vague prompt from faculty looks like "build me a quiz web page." TAs can guide them to fill in four elements — goal, context, constraints, completion criteria:

Suggested patrol timing

Mapped onto "4. Afternoon Schedule & Checkpoints" above, TAs can shift their patrol focus as follows:

13. TA Checklist

The checklists below are meant to be printed or checked off directly.

Before the workshop (equipment / accounts)

• Laptop charged, power adapter packed
• Confirmed network access
• Signed in to ChatGPT, confirmed Codex access
• GitHub account ready (if this session's flow needs it)
• Downloaded/extracted this session's sample data and module1-setup-windows.bat
• Personally ran through Modules 1–3 end to end once (not just read the tutorials)

During Module 1

• Watch for anyone stuck on winget not found or administrator-rights issues
• Remind everyone to reopen the terminal after the batch script finishes
• Confirm everyone's 7 version-check commands all print a version
• Confirm ChatGPT/Codex sign-in and access are working
• Remind everyone to switch Full access back to Ask for approval afterward

During Module 2

• Watch for prompts that don't state the download, slice, and cleanup rules clearly (filenames, folders, question counts, etc.)
• Watch whether anyone hitting a common-subject paper with a different layout got help re-deriving the rules for it
• Remind everyone to dry-run before the cleanup stage — don't skip it
• Watch that image count matches the number of entries in keys.json

During Module 3

• Confirm app/ sits alongside repo/, not nested inside it
• Watch for anyone double-clicking app/quiz.html instead of a file in dist/
• Watch for a newly added examLabel colliding with an existing one
• Remind everyone to rerun the bundler after editing config.json
• Confirm the terminal's Built N/M shows N equal to M

Wrapping up after the workshop

• Confirm every faculty member has their final dist/ artifact and the teacher-side aggregator page
• Help organize unresolved issues into a record for handoff (IT / instructor)
• Pack up / return equipment; confirm no faculty material or data was left on a TA's own device

14. Data Safety, Ethics & Role Boundaries

• Practice only with data and projects the organizer provides, that are publicly usable, or that have already been de-identified.
• Never enter student PII, grades, unpublished materials or exam questions, credentials, or internal documents into an external AI service.
• For copyright-sensitive content like Module 2's exam papers, remind faculty to confirm they have the right to distribute that content before handing out the double-click-ready HTML.
• AI-generated text, code, or suggestions are drafts or aids only — whether they're usable or correct is still the faculty member's call; TAs never substitute their own judgment for professional decisions about materials, questions, or assessment quality.
• Decisions about instructional design, subject-matter content, question quality, formal assessment, student rights, or administrative matters are never made unilaterally by a TA — always hand these back to faculty or the relevant unit.
• Before extending support into Office, web services, email, or calendar tools, confirm data permissions and institutional policy first.

15. After the Workshop & Expected Value

Afterward, keep this session's practice project, issue-recording format, and install guide as a starting point for future support work with faculty, labs, or teaching assistants. When a faculty member makes a request, trainees don't need to take on content decisions — they can instead help confirm equipment and environment, locate files, launch tools, complete basic tests, and organize any unresolved issue into information that's ready to hand off.

This training builds a pool of TA talent for future workshops, and lets faculty attending the faculty workshops arrange upfront technical training for their labs or teaching assistants beforehand. The goal is for faculty to be able to focus on teaching and their own professional work, while TAs or administrative staff with a shared technical foundation help with environment, files, execution, and initial testing.

The expected value of this session is a pool of support staff with a shared technical vocabulary and a basic way of handling problems, lowering the entry barrier non-engineering faculty face when using an AI Agent, so faculty can spend more of their time on teaching and their own professional work.

16. Resources & Relation to refs/

This page is adapted and integrated from the complete content of the two general-purpose planning documents, refs/AI-Agent-助教技能培訓工作坊-執行摘要.md and -執行方案.md (workshop positioning, training goals, audience and scale, afternoon schedule, hands-on principles, support workflow, data safety), and applies the same training spirit concretely to the actual Module 1–3 material on this site, so training content matches exactly what faculty will actually run into. Those two original planning documents remain in the refs/ folder as background context and guiding principles.

The vibe-coding practice described in "5. Hands-on Scope & Principles" and "7–9. Modules 1–3 for TAs" can draw directly on material already on this site — no separate preparation needed: