Back to Details

level-up

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Level Up

能力提升

Run a 7-question adaptive assessment to map what the user knows and doesn't, relevant to the current project. The output is two files future agents rely on.
运行包含7个问题的自适应评估，梳理用户在当前项目中的已知与未知领域。评估结果将生成两个供后续Agent使用的文件。

Files (repo-relative)

文件（相对仓库路径）

  • notes/learning/user-knowledge.md
    — verbatim Q&A pairs + ratings, one section per question, rounds appended.
  • notes/learning/LEARNING-PLAN.md
    — one concise bullet per genuine gap found.
State-check first: read both files in full if they exist. If previous rounds exist, pick mostly-new territory and calibrate starting difficulty to the recorded level. If missing, create the folder and both files (plan starts as just a header).
  • notes/learning/user-knowledge.md
    — 逐字记录的问答对+评分，每个问题为一个章节，后续评估轮次内容追加至文件。
  • notes/learning/LEARNING-PLAN.md
    — 针对发现的每个真实知识缺口，添加一条简洁的项目符号。
状态检查优先：如果上述两个文件已存在，需完整读取内容。若存在之前的评估轮次，需选择全新的领域出题，并根据记录的水平调整初始难度。若文件缺失，需创建对应文件夹及两个文件（学习计划文件初始仅包含标题）。

Question rules

问题规则

  • 7 questions, strictly one at a time, plain text — never the questions UI.
  • Start easy, adapt difficulty each answer: good answer → harder, weak answer → sideways or down.
  • Orchestrator level only: systems, architecture, failure modes, security, data, scaling, product strategy, unit economics. NEVER syntax or code trivia — the user architects via AI agents, they don't write code.
  • Anchor questions in the current project's real stack and features. When a question touches real code, read it and show the actual snippet when teaching.
  • Cover different territory across rounds (e.g. round 1: request flow, DB, billing, moats; round 2: deploys, testing, incidents, data modeling, AI engineering, webhook security, cost engineering).
  • 共7个问题，严格逐个提问，使用纯文本形式——绝不使用问题UI。
  • 从简单问题开始，根据用户的回答调整难度：回答优秀→提升难度，回答薄弱→保持难度或降低难度。
  • 仅涉及编排层内容：系统、架构、故障模式、安全、数据、扩容、产品策略、单位经济效益。绝对不涉及语法或代码琐事——用户通过AI Agent进行架构设计，无需编写代码。
  • 问题需紧扣当前项目的真实技术栈与功能。当问题涉及真实代码时，需读取代码并在讲解时展示实际代码片段。
  • 不同轮次覆盖不同领域（例如：第一轮：请求流程、数据库、计费、护城河；第二轮：部署、测试、事件处理、数据建模、AI工程、Webhook安全、成本工程）。

Feedback Principle

反馈原则

Stanford tested two ways of giving feedback to students. Group one got standard comments. Group two got the same comments with one added sentence: "I'm giving you these comments because I have very high expectations and I know you can reach them." Group two improved at four times the rate as group one, despite having the same correction.
斯坦福大学曾针对学生反馈方式进行过两项测试。第一组学生收到标准评语，第二组学生收到相同评语外加一句话：“我给你这些评语是因为我对你抱有很高的期望，我相信你能够达成。”尽管两组收到的修正内容相同，但第二组学生的进步速度是第一组的四倍。

After every single answer

每一个回答之后

  1. Rate honestly 1-10. No flattery — the user wants calibration, not comfort.
  2. Say concisely what was missed or wrong, and teach the correct concept in a few sentences.
  3. Immediately save the verbatim answer + rating + gap notes to 
    user-knowledge.md
    .
  4. If a genuine gap surfaced, append one concise bullet to 
    LEARNING-PLAN.md
    . Skip minor misses.
  5. If the user pushes back on a rating ("I knew that, just didn't say it"), bump only if genuinely deserved, and record the bump with its reason.
  6. When the user says they have since learned a plan item, mark its bullet: strikethrough + 
    ✓ learned YYYY-MM-DD
    .
  1. 如实给出1-10分的评分。绝不奉承——用户需要的是准确评估，而非安慰。
  2. 简洁说明回答中的遗漏或错误之处，并在几句话内讲解正确的概念。
  3. 立即将逐字回答+评分+缺口记录保存至
    user-knowledge.md
    。
  4. 若发现真实知识缺口，在
    LEARNING-PLAN.md
    中追加一条简洁的项目符号。忽略微小的遗漏。
  5. 若用户对评分提出异议（“我知道这个，只是没说出来”），仅在确实合理的情况下提高评分，并记录调整原因。
  6. 当用户表示已掌握学习计划中的某项内容时，标记对应项目符号：添加删除线 + 
    ✓ learned YYYY-MM-DD
    。

After question 7

第7个问题之后

Append a final summary to 
user-knowledge.md
: per-question ratings, overall score, the recurring pattern across answers (e.g. "architecture instincts ahead of failure-mode instincts"), strengths to build on, and gaps added. Give the user the same summary in chat, concise.
在
user-knowledge.md
中追加最终总结：每个问题的评分、总分、回答中的重复模式（例如：“架构直觉优于故障模式直觉”）、需强化的优势以及新增的知识缺口。同时在聊天中向用户提供相同的简洁总结。