Conrad Mentoring Architecture — A Simpler Design

Replaces the reference design in Reference/ebfb827a80fe961c268595d6c7e9d623.jpg (「康莱德备赛 AI 协同技术方案」: ChatGPT + Coze + 飞书/多维表 + 云盘/OSS).

1. What the reference design proposes

Four "capability engines" wired across an 8-stage season:

Stages: 团队建档 → 兴趣探索 → 选题决策 → Lean Canvas → PBL 执行 → Innovation Brief 制作 → Video + Website → 决选准备与路演训练.

The stage decomposition is good. It maps correctly onto the real competition. The problems are in the tooling and — more seriously — in the task-to-tool assignment.

2. Three problems

Problem 1 — The compliance problem (disqualifying)

The 任务—工具分工矩阵 assigns ChatGPT as 主导 ("leading") on:

• Brief 撰写 (brief writing)
• 视频脚本 (video script)
• Website 文案 (website copy)
• Lean Canvas (共创 / co-creation)

Conrad's rules say teams self-certify that they have not used AI for writing, programming, or key innovation; AI is permitted "only for partial, original submission writing" (knowledge-base/01-competition-facts.md §8).

An architecture whose central diagram places AI in the leading role on three submitted artifacts is an architecture for producing disqualifiable submissions. This is not a tuning issue — it is the design's organising principle, and it has to be inverted.

Note the asymmetry that makes this expensive: scrutiny scales with success ("we examine this more so for teams that show finalist potential"), and the Summit is a live Power Pitch and Expo Q&A. The failure mode is not "we get caught early" — it is "we get caught in Houston."

Problem 2 — The complexity problem

Four systems, four accounts, four auth models, four failure modes, and a cross-product of integrations to maintain — for a workload of, realistically, 5–20 teams on a 6-month cycle producing ~15 documents each.

Coze in particular is load-bearing for very little: "表单输入 → 结构化输出" and "自动生成阶段清单" are template-filling. Building and maintaining low-code workflow graphs to do this is a permanent maintenance surface in exchange for automating something a Markdown template already does.

The user's instinct — "especially the use of codes, and I don't think it's good" — is right. Every Coze node is a piece of logic that lives in a proprietary GUI, can't be diffed, can't be reviewed, can't be version-controlled, and breaks silently when the platform changes.

Problem 3 — The knowledge problem

The reference design has no source of truth. There is a 知识库检索 node in Coze, but nothing specifies what is in it or how it stays correct. Conrad's rules, deadlines, fees, special category, and rubric sub-criteria change every year — the 2025-26 guide added 25 sub-criteria that didn't exist in the 2024-25 materials.

An architecture without a versioned, verifiable knowledge base will confidently coach last year's competition. This is the quiet failure mode that produces good-looking, wrong advice.

3. The proposed design

One principle

Files are the system. Skills are the behaviour. Humans write the submissions.

Everything that is knowledge, process, or state is a plain file in a git repository. Everything the AI does is a skill — a versioned Markdown file describing a procedure. Everything submitted to Conrad is typed by a student.

The stack

┌──────────────────────────────────────────────────────────────────┐
│  ONE REPOSITORY (git)                                            │
│                                                                  │
│  knowledge-base/     canonical facts, rubric, judge playbook,    │
│                      winner data     ← versioned, dated, cited   │
│  conrad-skills/      12 skills = the entire coaching behaviour   │
│  topic-engine/       the discovery method                        │
│  curriculum/         slides, notes, worksheets                   │
│  teams/<team>/       one folder per team = all their state       │
│    ├─ 00-charter.md         roles, goals, calendar               │
│    ├─ 01-topic-card.md      topic engine output                  │
│    ├─ 02-lean-canvas.md     12 answers                           │
│    ├─ 03-brief.md           10 answers  ← STUDENT-WRITTEN ONLY   │
│    ├─ 04-evidence/          sources, expert emails, test data    │
│    ├─ 05-video/             script, storyboard, cut list         │
│    ├─ 06-website/           copy, brand notes, link              │
│    ├─ 07-mock-judging/      dated scorecards + judge-style notes │
│    └─ CONTRIBUTION-LOG.md   who wrote what, AI tools used        │
└──────────────────────────────────────────────────────────────────┘
                              │
                    ┌─────────┴─────────┐
                    │   Claude Code     │  reads the repo, runs skills
                    └─────────┬─────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
        Google Drive      Canva/Wix       YouTube
        (video raw)      (website)       (video host)
        ── only where a browser is genuinely required ──

That is the whole system. One repo, one AI surface, three external tools used only where the competition itself forces a browser (video hosting, website building, large media).

What each of the four reference engines becomes

Why "no code" is the right instinct — and what replaces it

The reference design's code lives in Coze workflow graphs. Replacing it with Python scripts would be no better. The actual replacement for orchestration logic is prose procedures in skill files:

• A skill is a Markdown file. It can be read by a human mentor, diffed in a PR, and corrected in place.
• It has no runtime, no dependencies, no API keys, and no platform to deprecate it.
• When Conrad changes the rubric, you edit one Markdown file, not a workflow graph and a knowledge base.

The only executable code in this design is optional: a validator that counts words per brief question against the official limits. That is a 30-line script, and it is genuinely useful because the word limits are hard-enforced by the portal.

4. The compliance inversion

The single most important change. The reference matrix is rewritten with AI's role explicitly demoted on every submitted artifact:

The rule, in one line:

AI may evaluate, question, and teach. AI may not produce anything that is submitted.

This is enforced structurally, not by good intentions: every skill in conrad-skills/ that touches a submitted artifact carries a hard refusal clause in its instructions, and conrad-integrity-guard maintains the contribution log.

The payoff is not only compliance. Mock judging produces better briefs than co-writing does, because the student has to fix the problems themselves — which is the only way they can defend the work at the Summit.

5. Season operating model

Eight stages preserved from the reference design (they were right), retooled and gated.

Continuous, all season: conrad-judge-simulator (mock judging at each gate) and conrad-integrity-guard (contribution log).

The critical structural insight the reference design misses: the Oct 30 → Jan 8 gap is 10 weeks spanning winter holidays, and it is where teams die. Stage 5 (evidence) must start in November, not December. The gate at Stage 4 should therefore require the evidence plan, not just the canvas.

6. Comparison

7. Migration path

For someone already running the reference stack:

1. Stop first, migrate second. Immediately remove AI from the drafting role on Brief, video script, and website copy. This is the compliance fix and it needs no tooling change.
2. Create the repo. knowledge-base/, conrad-skills/, teams/. Clone this repository as the base.
3. Port the knowledge base. Anything in the Coze 知识库 that is a Conrad fact → verify against conrad.spacecenter.org → into knowledge-base/01-competition-facts.md. Discard the rest.
4. Retire Coze. For each workflow, ask: is it a template, a checklist, or a reminder? Templates → teams/_template/. Checklists → the gate table in §5. Reminders → a calendar. Nothing else survives.
5. Keep Feishu/Notion only for parent-facing status, if the audience needs it. Mirror from git; don't make it the source of truth.
6. Keep the drive for raw video only.
7. Start the contribution log for every active team, retroactively where possible.

What to keep from the reference design — credit where due:

• The 8-stage decomposition
• 模拟评委 (mock judging) — the best idea in it, now the primary AI role
• Milestone gates
• Central asset archiving for video

8. Honest limitations

• This design assumes the mentor is comfortable with git. If they are not, the teams/ folders work in Dropbox or Drive with a shared naming convention — you lose diffs and history, which is a real loss for the contribution log, but the rest holds.
• Students will still use AI on their own. The architecture cannot prevent this. What it can do is make the legitimate use easy and logged, and make the illegitimate use obviously risky by putting the Summit Q&A reality in front of them early. conrad-integrity-guard is a coaching tool, not a detector.
• The 12 skills are new and unvalidated against real outcomes. They encode a real judge's materials and five real judged briefs, but no team has yet run a season on them. Treat the rubric prescores as calibrated estimates, not predictions, until a cohort completes.
• No published price data exists for the commercial market, so the competitive positioning in knowledge-base/04-mentoring-market.md §5 is qualitative.

Conrad 辅导技术架构 —— 一个更简单的设计

用于替代 Reference/ebfb827a80fe961c268595d6c7e9d623.jpg 中的参考方案 （「康莱德备赛 AI 协同技术方案」：ChatGPT + Coze + 飞书/多维表 + 云盘/OSS）。

1. 参考方案提出了什么

四个"能力引擎"，串起一个 8 阶段赛季：

阶段：团队建档 → 兴趣探索 → 选题决策 → Lean Canvas → PBL 执行 → Innovation Brief 制作 → Video + Website → 决选准备与路演训练。

阶段拆解是好的。 它正确地映射了真实比赛。问题出在工具选择上 —— 更严重的是，出在"任务—工具"的分工上。

2. 三个问题

问题 1 —— 合规问题（会导致取消资格）

任务—工具分工矩阵把 ChatGPT 设为"主导"，在以下任务上：

• Brief 撰写
• 视频脚本
• Website 文案
• Lean Canvas（共创）

而 Conrad 的规则要求团队自我认证其未使用 AI 进行写作、编程或核心创新； AI 只允许用于"部分的、原创的提交写作"（knowledge-base/01-competition-facts.zh.md §8）。

一个把 AI 放在三项提交产物主导位置的核心示意图，就是一个用来生产 "可被取消资格的提交物"的架构。这不是调参问题 —— 这是该设计的组织原则本身，必须被反转。

请注意让这件事代价高昂的不对称性：审查强度随成功放大 （"对于表现出决赛潜力的队伍，我们会更严格地审查"），而峰会是现场 Power Pitch 与 Expo 问答。 失败模式不是"我们早早被抓到"—— 而是"我们在休斯顿被抓到"。

问题 2 —— 复杂度问题

四个系统、四个账号体系、四套鉴权、四种故障模式，以及一堆需要维护的集成 —— 而实际工作量只是：5–20 支队伍、一个 6 个月的周期、每队约 15 份文档。

尤其是 Coze，承担了很重的架构地位却只做了很少的事："表单输入 → 结构化输出" 和"自动生成阶段清单"本质上是填模板。为了做一件 Markdown 模板就能做的事， 去搭建和维护低代码工作流图，等于换来一个永久的维护面。

用户的直觉 —— "especially the use of codes, and I don't think it's good" —— 是对的。 每一个 Coze 节点都是一段逻辑，它活在一个专有 GUI 里，无法 diff、无法 code review、 无法版本控制，并且会在平台变更时悄无声息地坏掉。

问题 3 —— 知识问题

参考方案没有事实来源。Coze 里有一个知识库检索节点， 但没有任何地方规定里面装什么、以及如何保持正确。

Conrad 的规则、截止日期、费用、特别赛道和评分子标准每年都变 —— 2025-26 版指南新增了 2024-25 材料里根本不存在的 25 条子标准。

一个没有版本化、可核实知识库的架构，会自信地按去年的比赛做辅导。 这是那种会产出"看起来很好但其实错了"的建议的、安静的失败模式。

3. 建议的设计

一条原则

文件即系统。技能即行为。人来写提交物。

一切属于知识、流程或状态的东西，都是 git 仓库里的纯文本文件。 AI 做的一切，都是一个技能（skill） —— 一份描述流程的、版本化的 Markdown 文件。 提交给 Conrad 的一切，都由学生亲手敲下。

技术栈

┌──────────────────────────────────────────────────────────────────┐
│  一个仓库（git）                                                  │
│                                                                  │
│  knowledge-base/     权威事实、评分表、评审手册、获奖数据          │
│                      ← 有版本、有日期、有引用                     │
│  conrad-skills/      12 个技能 = 全部辅导行为                     │
│  topic-engine/       选题发现方法                                 │
│  curriculum/         幻灯片、讲义、工作表                         │
│  teams/<队伍>/       每队一个文件夹 = 他们的全部状态              │
│    ├─ 00-charter.md         分工、目标、日历                     │
│    ├─ 01-topic-card.md      选题引擎输出                         │
│    ├─ 02-lean-canvas.md     12 个答案                            │
│    ├─ 03-brief.md           10 个答案 ← 只能由学生撰写            │
│    ├─ 04-evidence/          资料、专家邮件、测试数据              │
│    ├─ 05-video/             脚本、故事板、剪辑清单                │
│    ├─ 06-website/           文案、品牌说明、链接                  │
│    ├─ 07-mock-judging/      带日期的评分卡 + 评委式意见           │
│    └─ CONTRIBUTION-LOG.md   谁写了什么、用了哪些 AI 工具          │
└──────────────────────────────────────────────────────────────────┘
                              │
                    ┌─────────┴─────────┐
                    │   Claude Code     │  读仓库，跑技能
                    └─────────┬─────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
        Google Drive      Canva/Wix       YouTube
        （视频原始素材）  （网站）        （视频托管）
        ── 仅在比赛本身强制要求浏览器时使用 ──

这就是整个系统。 一个仓库、一个 AI 界面、三个只在比赛本身强制要求浏览器时才用的外部工具 （视频托管、建站、大文件媒体）。

参考方案的四个引擎各自变成什么

为什么"不要代码"的直觉是对的 —— 以及用什么取代它

参考方案里的"代码"活在 Coze 工作流图里。用 Python 脚本替代它并不会更好。 编排逻辑真正的替代物是技能文件里的散文流程：

• 一个技能就是一份 Markdown。人类导师能读，能在 PR 里 diff，能就地改正。
• 它没有运行时、没有依赖、没有 API key，也没有会把它废弃掉的平台。
• 当 Conrad 改评分表时，你改一份 Markdown，而不是改一张工作流图加一个知识库。

本设计中唯一的可执行代码是可选的：一个按官方字数上限逐题统计简述词数的校验器。 那是 30 行脚本，而且确实有用，因为字数限制是被提交后台硬性执行的。

4. 合规反转

最重要的一处改动。参考方案的矩阵被重写，AI 在每一项提交产物上的角色被明确降级：

一句话规则：

AI 可以评估、追问、教学。AI 不得生产任何被提交的东西。

这一点靠结构而非善意来执行：conrad-skills/ 中每一个触及提交产物的技能， 其指令里都带有一条硬拒绝条款，而 conrad-integrity-guard 维护贡献日志。

回报不只是合规。模拟评审产出的简述质量比共同写作更高， 因为学生必须自己修复问题 —— 而那是他们唯一能在峰会上捍卫这份工作的方式。

5. 赛季运行模型

保留参考方案的 8 个阶段（它们是对的），换掉工具，加上关卡。

全季持续进行：conrad-judge-simulator（每个关卡做模拟评审）与 conrad-integrity-guard（贡献日志）。

参考方案漏掉的关键结构性洞察： 10 月 30 日 → 1 月 8 日是 横跨寒假的 10 周，而队伍就死在这里。阶段 5（证据）必须在 11 月开始，而不是 12 月。 因此阶段 4 的关卡应当要求交出证据计划，而不只是画布。

6. 对比

7. 迁移路径

给已经在跑参考方案的人：

1. 先停，再迁。 立刻把 AI 从 Brief、视频脚本、网站文案的起草角色上撤下来。 这是合规修复，不需要任何工具变更。
2. 建仓库。 knowledge-base/、conrad-skills/、teams/。以本仓库为基底克隆。
3. 搬运知识库。 Coze 知识库里凡是 Conrad 事实 的内容 → 对照 conrad.spacecenter.org 核实 → 放进 knowledge-base/01-competition-facts.zh.md。其余丢弃。
4. 退役 Coze。 对每个工作流问：它是模板、清单，还是提醒？ 模板 → teams/_template/。清单 → §5 的关卡表。提醒 → 一个日历。 其余的什么都不用留。
5. 飞书/Notion 只保留给面向家长的状态同步（如果受众需要）。从 git 镜像过去， 不要让它成为事实来源。
6. 网盘只保留给视频原始素材。
7. 为每支在跑的队伍开始记贡献日志，尽可能补录。

参考方案里值得保留的东西 —— 该给的信誉要给：

• 8 阶段拆解
• 模拟评委 —— 其中最好的想法，现在成了 AI 的首要角色
• 里程碑 Gate
• 视频素材的集中归档

8. 诚实的局限

• 本设计假设导师能用 git。 如果不能，teams/ 文件夹在 Dropbox 或 Drive 里配合 统一命名约定也能跑；你会失去 diff 和历史 —— 这对贡献日志是真实损失 —— 但其余部分成立。
• 学生仍然会自己用 AI。 架构无法阻止这一点。它能做的是让合法用法变得容易且被记录， 并通过尽早把"峰会问答"的现实摆在他们面前，让非法用法显得明显有风险。 conrad-integrity-guard 是一个辅导工具，不是检测器。
• 这 12 个技能是新的，尚未用真实结果验证。 它们编码了一位真实评委的材料和五份真实已评审简述， 但还没有任何一支队伍完整跑过一个赛季。在一届学生跑完之前， 请把评分表预打分当作经过校准的估计，而不是预测。
• 商业市场没有公开价格数据，因此 knowledge-base/04-mentoring-market.zh.md §5 中的竞争定位是定性的。