hackathon-judge-simulator

hackathon-judge-simulator

目标

模拟由多位黑客松评委组成的评审团评估项目，生成可能提出的问题、关键质疑和预测评分结果，帮助团队完善路演和演示。

---

触发条件

在以下情况下使用此技能：

• 路演演示文稿已完成，演示视频已录制
• 团队需要在现场评审前对路演进行压力测试
• 需要准备对抗性问题和答辩策略
• 预测评分揭示了可在展示前弥补的不足
• 在第 7 阶段（评估）调用；改进路演后再次调用，进行第二轮模拟

---

输入

输入	类型	必需	描述
project_title	string	是	项目名称
problem_statement	string	是	要解决的问题
solution_summary	string	是	项目如何解决该问题
mvp_features	string[]	是	已构建的内容
tech_stack	string[]	是	使用的技术
evaluation_axes	object[]	是	来自 hackathon-track-analyzer 的评审标准
pitch_content	string	否	路演草稿或幻灯片内容，用于更有针对性的模拟
judge_personas	string[]	否	预期评委的类型（例如，技术评委、商业评委、领域专家）

---

输出

输出	描述
judge_personas_used	模拟的评委类型及其可能关注的重点
questions	评委可能提出的问题及建议答案
objections	评委可能提出的关键质疑
predicted_scores	各评审维度的评分及理由
overall_verdict	模拟的整体印象和排名可能性
pitch_improvements	针对预测弱点的具体改进措施

---

规则

1. 如果未提供 judge_personas，至少模拟 3 种不同的评委角色。
2. 每个评审维度至少生成 2 个问题。
3. 至少包含一个针对解决方案弱点的问题。
4. predicted_scores 必须使用与 hackathon-idea-scoring 相同的 1–5 分制。
5. objections 必须配有建议的答辩策略。
6. pitch_improvements 必须能在剩余的黑客松时间内执行。
7. 不要只模拟有利结果；至少纳入一种持怀疑态度的评委视角。

---

输出格式

judge_personas_used:
  - persona: "<type>"
    priorities:
      - "<priority>"

questions:
  - judge_persona: "<type>"
    question: "<question text>"
    recommended_answer: "<suggested response>"
    difficulty: "<easy|medium|hard>"

objections:
  - objection: "<concern>"
    likelihood: "<high|medium|low>"
    rebuttal_strategy: "<how to address>"

predicted_scores:
  - axis: "<axis name>"
    score: <1-5>
    reasoning: "<why>"

overall_verdict:
  impression: "<string>"
  ranking_likelihood: "<top-3|mid-field|long-shot>"
  key_strengths:
    - "<strength>"
  key_weaknesses:
    - "<weakness>"

pitch_improvements:
  - issue: "<problem>"
    action: "<what to change>"
    priority: "<high|medium|low>"

---

示例

输入：

project_title: "AnchorAI"
problem_statement: "College students wait 6 weeks for counseling while anxiety compounds."
solution_summary: "GPT-4 companion with Redis-backed session memory for persistent emotional context."
mvp_features: ["GPT-4 check-in conversation", "Session memory", "Crisis escalation (mocked)"]
tech_stack: ["Python", "FastAPI", "React", "Redis", "OpenAI GPT-4"]
evaluation_axes:
  - axis: "Innovation"
  - axis: "Impact"
  - axis: "Technical Execution"

输出：

judge_personas_used:
  - persona: "Technical judge"
    priorities: ["Working implementation", "Appropriate tech choices", "Scalability awareness"]
  - persona: "Impact/domain judge"
    priorities: ["Real user need", "Safety guardrails", "Clinical validity concerns"]
  - persona: "Business judge"
    priorities: ["Market size", "Differentiation", "Go-to-market path"]

questions:
  - judge_persona: "Technical judge"
    question: "How does the memory actually work — what are you storing and retrieving?"
    recommended_answer: "We store a GPT-4 generated summary of each session in Redis, keyed by user ID. On the next session, we prepend that summary to the system prompt. It's simple and it works for the demo."
    difficulty: "medium"
  - judge_persona: "Impact/domain judge"
    question: "Is this safe? What happens if someone is in genuine crisis?"
    recommended_answer: "We detect distress signals and surface hotline resources immediately. We're explicit that AnchorAI is not a therapist. In the roadmap, we escalate to human counselors."
    difficulty: "hard"
  - judge_persona: "Business judge"
    question: "How is this different from Woebot or BetterHelp?"
    recommended_answer: "Woebot has no memory and uses rigid scripts. BetterHelp is $80/week. AnchorAI is the only free, always-available companion that actually knows your history."
    difficulty: "medium"

objections:
  - objection: "This could give vulnerable users dangerous advice"
    likelihood: "high"
    rebuttal_strategy: "Acknowledge directly. Explain the safety guardrails and the explicit non-therapist framing. Offer to show the crisis card in the demo."
  - objection: "Memory feature is just system prompt injection — not novel"
    likelihood: "medium"
    rebuttal_strategy: "Agree it's a simple mechanism. Pivot to impact: the novelty is the UX, not the implementation. Show the user experience, not the code."

predicted_scores:
  - axis: "Innovation"
    score: 4
    reasoning: "Memory-based continuity in mental health context is genuinely novel for a hackathon"
  - axis: "Impact"
    score: 5
    reasoning: "Large, underserved audience with real demonstrated need"
  - axis: "Technical Execution"
    score: 4
    reasoning: "Working live demo with real API integration; Redis memory functions correctly"

overall_verdict:
  impression: "Strong emotional narrative with a memorable live demo moment. Safety question will come up — being prepared for it is the difference between winning and not."
  ranking_likelihood: "top-3"
  key_strengths:
    - "Emotionally resonant problem framing"
    - "Live working wow moment (memory recall)"
    - "Clear differentiation from existing tools"
  key_weaknesses:
    - "Safety and clinical validity will be scrutinized"
    - "Business model not addressed"

pitch_improvements:
  - issue: "No mention of how AnchorAI avoids causing harm"
    action: "Add one sentence to the solution slide: 'AnchorAI is not a therapist — it's a bridge to one.'"
    priority: "high"
  - issue: "No business or monetization framing"
    action: "Add one bullet to vision slide: 'Free tier for students; licensed model for universities'"
    priority: "medium"

---

上下文文件

知识库

• ../hackathon-shared-resources/knowledge/hackathon-judging-criteria.md
• ../hackathon-shared-resources/knowledge/hackathon-pitch-strategy.md
• ../hackathon-shared-resources/knowledge/hackathon-winning-patterns.md
• ../hackathon-shared-resources/knowledge/hackathon-demo-psychology.md

操作手册

• ../hackathon-shared-resources/playbooks/hackathon-workflow.md