# 评审材料总览

| 仓库 | PRD摘要 | PoC摘要 | PRD原件 | PoC/技术原件 | 骑行消息 | 效果图 | 备注 |
|---|---:|---:|---:|---:|---:|---:|---|
| `ary-grs-001-Adoraduan` | ✅ | ✅ | 1 | 2 | 2 | 3 |  |
| `ary-grs-001-INSDEL123` | ✅ | ✅ | 2 | 29 | 2 | 3 | run_all: A/B/D 通过，C 1 项失败 |
| `ary-grs-001-Learner-always99` | ✅ | ✅ | 1 | 14 | 2 | 5 |  |
| `ary-grs-001-NijigenDev` | ✅ | ✅ | 1 | 58 | 1 | 3 |  |
| `ary-grs-001-RunningKuma` | ✅ | ✅ | 2 | 25 | 3 | 3 |  |
| `ary-grs-001-SakiyaYue` | ✅ | ✅ | 1 | 58 | 3 | 5 |  |
| `ary-grs-001-Sereniu` | ✅ | ✅ | 1 | 2 | 1 | 4 |  |
| `ary-grs-001-Sukice` | ✅ | ✅ | 1 | 6 | 1 | 3 |  |
| `ary-grs-001-Wu-light` | ✅ | ✅ | 2 | 2 | 0 | 3 | 未发现骑行消息 |
| `ary-grs-001-bouderer` | ✅ | ✅ | 1 | 7 | 5 | 3 | 两仓库高度同源 |
| `ary-grs-001-dazhuang0325` | ✅ | ✅ | 1 | 6 | 2 | 3 |  |
| `ary-grs-001-elle1231` | ✅ | ✅ | 1 | 2 | 1 | 4 |  |
| `ary-grs-001-gao-xing-li` | ✅ | ✅ | 1 | 3 | 5 | 4 |  |
| `ary-grs-001-lyclycNSP` | ✅ | ✅ | 1 | 5 | 4 | 5 |  |
| `ary-grs-001-recyclable06` | ✅ | ✅ | 2 | 8 | 5 | 4 |  |
| `ary-grs-001-sinbawang` | ✅ | ✅ | 1 | 7 | 4 | 3 |  |
| `ary-grs-001-starswishes` | ✅ | ✅ | 1 | 7 | 5 | 3 | 两仓库高度同源 |
| `ary-grs-001-xiao-ruan233` | ✅ | ✅ | 1 | 6 | 6 | 5 |  |
| `ary-grs-001-yihuan-Hu` | ✅ | ✅ | 2 | 14 | 0 | 3 | 未发现骑行消息 |
| `ary-grs-001-zqinglin` | ✅ | ✅ | 1 | 3 | 2 | 5 |  |

## 评审口径

本轮评价依据课堂开赛 PPT 中对 ARY Agent Racing Yard 和 GRS 001 的要求整理，属于评审材料准备阶段的初评，不替代正式打分。重点看四件事：

1. **ARY 产品定义是否成立**：是否把 ARY 讲成智能体时代的软件开发训练场、竞技场，而不是普通比赛平台或代码提交系统；是否覆盖创建、披露、组织、运行、评审、展示等 ARY 能力。
2. **GRS 001 核心命题是否对准**：是否证明“Race 数据可存留在 Organizer 侧；ARY 不需要持久化保存完整 Race 数据；ARY 仍可完成赛事创建、披露、组织、展示；展示内容来自 Organizer 主动披露的公开元数据或公开投影”。
3. **数据安全 PoC 是否有效**：是否有可运行 Demo、接口模拟、验证脚本或证据链；是否能看出数据在哪里、ARY 不保存什么、异常状态如何处理。
4. **Agentic Engineer / Riding Skill 是否可见**：是否体现目标澄清、任务拆解、让 Agent 正确行动、观察判断、干预验收、复盘沉淀，而不是只提交一次性生成物。

## 总体综述

20 个实质提交中，头部项目已经从“文档解释”推进到“可运行系统 + 安全验证 + 证据链”。这类作品不只是复述 Public Yard / Private Race Source，而是用 E2EE、签名哈希、公开投影、实时拉取、零落库、沙箱、审计、离线/撤回状态等机制去证明核心命题。

中段项目通常具备完整 PRD 和小型 PoC，能够说明 Organizer/ARY 的数据边界，但工程实现较轻，更多依靠静态 HTML、单脚本或 Streamlit 演示。它们适合评 Product Definition 和 PoC 方向，但正式评分时要重点复跑验证脚本，看是否真的覆盖敏感字段泄漏、撤回、过期、Organizer 不可达、报名/提交是否绕过 ARY 存储等关键边界。

较弱项目的问题集中在三类：一是只有概念演示，缺少可复验断言；二是 Riding Record 缺失或不足，难以体现 Agentic Engineer 的“骑行”能力；三是方案有偏题风险，把重点放在通用沙箱、OS 隔离或传统赛事平台功能上，而不是 GRS 001 的“数据安全的 Race”证明链。

需要特别注意查重/合并评阅：`ary-grs-001-bouderer` 与 `ary-grs-001-starswishes` 文件高度同源，建议作为同一方案变体并排核查；`ary-grs-001-gao-xing-li` 与 `ary-grs-001-recyclable06` 也存在明显关联，后者材料更完整。`ary-grs-001-INSDEL123` 在补装依赖后 A/B/D 场景通过，但 C 场景仍有 1 项失败，疑似日志匹配误报，正式评阅前应人工复核。

## 初评分层

| 层级 | 项目 | 初评理由 |
|---|---|---|
| 头部候选 | `zqinglin`、`bouderer` / `starswishes`、`xiao-ruan233`、`NijigenDev`、`RunningKuma`、`SakiyaYue` | 产品定义、技术方案、PoC 和证据材料相对完整，有较强可复验性或工程完整度。 |
| 有效完成 | `INSDEL123`、`Learner-always99`、`Sukice`、`lyclycNSP`、`sinbawang`、`recyclable06`、`dazhuang0325`、`Adoraduan` | 对准核心命题，有 PRD 和可运行/可展示 PoC，但实现深度、运行稳定性或证据链完整度不一。 |
| 待谨慎评阅 | `gao-xing-li`、`elle1231`、`Sereniu`、`yihuan-Hu`、`Wu-light` | 有材料和 Demo，但存在材料缺项、偏题、过程记录不足或验证链较轻的问题。 |

## 逐项目评价

| 仓库 | 初评 | 主要优点 | 主要风险 / 复核点 |
|---|---|---|---|
| `ary-grs-001-zqinglin` | 头部候选 | PRD、技术方案、部署截图、过程记录完整；三类赛事场景、沙箱评测、违规拦截、题目/规则封存、哈希证据链和授权字段展示都对准“数据安全的 Race”。展示体验强，适合课堂评审。 | 技术方案里部分生产级设想如 PostgreSQL/K8s 与实际 PoC 的轻量实现有差异，需区分“已实现”和“目标态”。 |
| `ary-grs-001-bouderer` | 头部候选 | 全栈 Stage 1 Demo，提出浏览器端 E2EE、教师在线门控、实时密文直转、平台零存储，PoC 报告和测试断言完整，数据主权证明强。 | 与 `starswishes` 高度同源；需核查团队独立贡献和 Riding Record 是否真实区分。 |
| `ary-grs-001-starswishes` | 头部候选 / 同源复核 | 与 `bouderer` 同样具备 E2EE、零存储、在线门控、PoC 报告和测试脚本，工程完成度高。 | 与 `bouderer` 除 README 外几乎一致，建议合并查重后再分别给分。 |
| `ary-grs-001-xiao-ruan233` | 头部候选 | Next.js + Prisma + SQLite 全栈实现完整，覆盖 Organizer/Rider 账号、赛事、组队报名、代码提交、Runner 拉取评分、公开榜单和 Audience 视图，产品体验强。 | 需要重点核查完整提交数据、Runner 私有数据和平台数据库之间的边界；可能更像完整赛事系统，数据主权证明需单独看。 |
| `ary-grs-001-NijigenDev` | 头部候选 | L1/L2/L3 数据分层清晰，FastAPI BFF + 静态前端 + mock GitHub/Organizer pipeline 较完整；L2 实时拉取内存渲染、L3 永不访问的设计对准 GRS001。 | 静态前端截图部分依赖后端数据，正式评阅需跑 `scripts/start-demo.sh` 或 `scripts/demo.py` 验证实际链路。 |
| `ary-grs-001-RunningKuma` | 头部候选 | 协议化程度高，包含 canonical JSON、hash、Ed25519 签名、schema、Verifier、撤回/过期/不可访问等验证点；Control Plane / Organizer Data Plane 分离明确。 | 多服务 pnpm Demo 尚需完整复跑；当前材料截图中部分是静态入口和说明页，需确认 Playwright/Verifier 报告全绿。 |
| `ary-grs-001-SakiyaYue` | 头部候选 | 文档工作区、schema、fixture、Team/Organizer/Reviewer 节点和 public display 组织严谨，体现评审证据和包流协议思维。 | 产品体验不如全栈 UI 项目直观，需看 `run-demo` 是否能顺畅跑通端到端流程。 |
| `ary-grs-001-INSDEL123` | 有效完成 | PRD、API、安全分析、四场景 PoC 和 Agent history 完整；A/B/D 场景实际复跑通过，能从存储、代理、生命周期证明数据边界。 | 复跑 C 场景 13 PASS / 1 FAIL，疑似日志匹配误报但不能直接视为全绿；正式评审需修正验证脚本或人工复核。 |
| `ary-grs-001-Learner-always99` | 有效完成 | Streamlit Demo 小而完整，Race 广场、详情、安全 Dashboard 能清楚展示公开投影、隐藏字段和 Organizer 私有数据对照。 | 工程规模较轻，更多是概念原型；需确认提交/组织链路是否不仅停留在展示。 |
| `ary-grs-001-Sukice` | 有效完成 | PRD 和系统设计对 ARY 的“非持久化调度与展示层”定义较清楚；Organizer Node + ARY Gateway + Svelte Demo 结构简洁。 | 截图显示部分静态页面需要后端配合；正式评审需启动 Python 服务验证 `_private` 字段确实不出现在 ARY 响应里。 |
| `ary-grs-001-lyclycNSP` | 有效完成 | PRD、PoC 技术设计、演示说明 PDF、截图和多份 Riding Record 齐全；演示链路覆盖 Organizer 创建、挑战发布、Racer 提交、实时榜单、归档。 | 需要复跑 Demo 确认截图和文档描述对应真实实现；数据主权证明的断言强度需进一步看代码。 |
| `ary-grs-001-sinbawang` | 有效完成 | Node PoC、演示视频、数据位置说明和多 session Riding Record 较完整；公开 Race 列表、Organizer 本地服务切断/恢复、提交和排行榜链路清楚。 | 需要运行 `npm run verify` 复核；部分材料偏演示路径，数据不落 ARY 的自动验证强度需检查。 |
| `ary-grs-001-recyclable06` | 有效完成 | 对 Public Metadata / Projection、Registration Proxy 零落库、Evidence Dashboard、version/hash、Suspended 状态有较完整设计与最终摘要。 | 与 `gao-xing-li` 相关；需核查同源关系和增量贡献。PoC 主要是 Python/HTML，工程边界较轻。 |
| `ary-grs-001-dazhuang0325` | 有效完成 | 静态 HTML/JS PoC 很适合评审演示，能操作安全扫描、发布、撤回、过期、源数据不可访问；Riding Record 记录了人类干预和修正。 | 纯静态 Demo 无真实后端隔离，证明力度低于可运行服务/测试脚本，需要按“可解释原型”评。 |
| `ary-grs-001-Adoraduan` | 有效完成 | PRD、Python PoC、HTML Demo、用例图/消息图和两份 Riding Record 齐全；脚本声称覆盖 51 项检查，材料结构完整。 | 需实际复跑 `poc.py` 核查 51/51 是否成立；技术方案更多散落在 PRD/PoC 中，独立架构文档不足。 |
| `ary-grs-001-gao-xing-li` | 待谨慎评阅 | 有 PRD、Python PoC、Demo 页面和多名成员 Riding Record；Public Yard / Private Race Source 口径正确。 | 与 `recyclable06` 关联明显且材料较少；建议以 `recyclable06` 为增强版对照复核。 |
| `ary-grs-001-elle1231` | 待谨慎评阅 | PRD 对 Public Yard、最小知识、撤回和授权披露有较系统说明；HTML/Python Demo 可展示基本数据主权关系。 | 未发现明确 Riding Record，仅有对话记录；PoC 工程和自动验证较轻。 |
| `ary-grs-001-Sereniu` | 待谨慎评阅 | 有 PRD、HTML Demo、演示视频和 AI riding record；页面可视化较直观。 | 材料规模较小，缺少独立技术方案和自动化断言；更像概念演示。 |
| `ary-grs-001-yihuan-Hu` | 待谨慎评阅 | 角色分工目录清楚，PRD 明确要求公开页只 GET Organizer API、不使用浏览器持久化；前端管理页和公开页可截图。 | 未发现 Riding Record；需要跑后端验证“ARY 不持久化”和浏览器存储为空，而不只看 HTML。 |
| `ary-grs-001-Wu-light` | 待谨慎评阅 | `poc.py` 实际运行通过 11 个验证点，包含 OS 层隔离、Platform 层数据主权、TTL、公开投影等，运行证据清楚。 | 明显偏 OS/平台安全哲学，和 GRS001 Product Definition/ARY 赛事产品定义关联较弱；未发现骑行消息。 |

## 补充评分维度

说明：以下是材料准备阶段的 **5 分制初评**，用于辅助后续正式评分。`PRD创新性` 主要看业务/功能定义是否超出模板复述，是否提出了有辨识度的 ARY 使用场景、角色流程、展示体验或赛事运营能力。`PoC数据安全保障` 主要看 PoC 技术是否能实际证明赛事项目数据不外泄，包括数据不落库、公开投影、字段白名单、E2EE、签名哈希、沙箱、审计、撤回/离线处理、自动化断言等。

| 仓库 | PRD创新性 | PoC数据安全保障 | 评价摘要 |
|---|---:|---:|---|
| `ary-grs-001-zqinglin` | 5 | 4 | PRD 将三类赛事、沙箱评测、证据链、公平性验证和授权展示整合成完整平台方案；PoC 覆盖违规拦截、字段授权、哈希证据链，保障较强，但部分生产级设计未完全落地。 |
| `ary-grs-001-bouderer` | 5 | 5 | PRD 把 ARY 做成教师在线接收、浏览器 E2EE、公开投影展示的全栈数据主权平台；PoC 用 E2EE、在线门控、实时直转和 24 项断言直接证明平台读不到也存不下提交。 |
| `ary-grs-001-starswishes` | 5 | 5 | 与 `bouderer` 同源，创新点和安全保障同样强；正式评分需先处理同源问题，再决定是否分别认可。 |
| `ary-grs-001-xiao-ruan233` | 5 | 3 | 业务功能创新较强，完整覆盖 Organizer/Rider/Runner/榜单/Audience；但数据安全 PoC 更偏赛事全流程，需复核提交、Runner 数据和平台持久化边界是否足够严格。 |
| `ary-grs-001-NijigenDev` | 4 | 4 | L1/L2/L3 数据分层、GitHub/Actions pipeline 和队伍雷达图有辨识度；PoC 通过 L1 持久化、L2 实时拉取、L3 永不访问提供较清楚的数据外泄防线。 |
| `ary-grs-001-RunningKuma` | 4 | 5 | PRD 的 Control Plane/Data Plane 分离较成熟；PoC 协议化强，签名、hash、schema、verifier、撤回/过期/不可访问验证对数据不外泄和不篡改保障充分。 |
| `ary-grs-001-SakiyaYue` | 4 | 4 | 引入 Team/Organizer/Reviewer 节点、review package、receipt、public projection，流程创新较强；PoC 的 schema、fixture、签名和包流验证较扎实，但产品体验相对弱。 |
| `ary-grs-001-INSDEL123` | 4 | 4 | PRD 和四场景设计覆盖存储、代理、直连、生命周期；PoC A/B/D 复跑通过，能证明多条数据边界，C 场景有 1 项失败需复核后再决定是否满分。 |
| `ary-grs-001-Learner-always99` | 3 | 3 | PRD 清楚但创新主要在 Streamlit 安全面板和公开投影工作流；PoC 能展示字段过滤和 Organizer 对照，但工程隔离、自动化断言和异常处理较轻。 |
| `ary-grs-001-Sukice` | 4 | 3 | PRD 对 ARY “非持久化调度与展示层”的定义有思想性；PoC 架构清楚，但需要实际启动服务确认无数据库、内存中转和 `_private` 字段隔离。 |
| `ary-grs-001-lyclycNSP` | 4 | 3 | PRD 和演示链路覆盖 Organizer、Racer、实时榜单、归档，业务体验完整；PoC 截图和技术设计丰富，但安全保障的自动化断言和真实隔离强度需进一步复跑确认。 |
| `ary-grs-001-sinbawang` | 4 | 3 | PRD 将公开详情、过程证据、排行榜和六维画像结合，展示体验有特色；PoC 有本地 Organizer 服务切断/恢复和 verify 命令，但需复跑确认数据不落 ARY。 |
| `ary-grs-001-recyclable06` | 4 | 4 | PRD 对 Public Metadata/Projection、Registration Proxy、Suspended 状态定义清楚；PoC 有 Evidence Dashboard、version/hash、泄露拒绝和零落库验证，保障较好。 |
| `ary-grs-001-dazhuang0325` | 3 | 3 | PRD 和静态 Demo 对发布、撤回、过期、不可访问讲得清楚；PoC 可交互但纯静态，能说明机制，不能充分证明真实服务层数据不外泄。 |
| `ary-grs-001-Adoraduan` | 3 | 3 | PRD 数据分类、撤回、遗忘和角色流程完整，创新中等；PoC 声称 51 项检查并有 HTML Demo，但正式评分需复跑脚本确认断言有效。 |
| `ary-grs-001-gao-xing-li` | 3 | 3 | PRD 口径正确，公开投影和 Evidence Dashboard 思路明确；但材料少于 `recyclable06`，PoC 保障能力需与相关仓库对照复核。 |
| `ary-grs-001-elle1231` | 3 | 2 | PRD 对最小知识、撤回和授权披露有一定创新；PoC 主要是轻量 HTML/Python 演示，缺少强验证脚本和真实隔离证据。 |
| `ary-grs-001-Sereniu` | 2 | 2 | PRD 和 Demo 能表达数据隔离概念，但业务/功能创新较有限；PoC 偏概念展示，缺少可复验的数据不外泄机制。 |
| `ary-grs-001-yihuan-Hu` | 3 | 2 | PRD 明确公开页只 GET、不使用浏览器持久化，有一定功能边界意识；PoC 需后端验证支撑，且缺 Riding Record，数据安全保障证据不足。 |
| `ary-grs-001-Wu-light` | 2 | 3 | PRD/业务创新较弱，明显偏 OS/平台安全哲学；PoC 脚本运行通过，TTL、公开投影和隔离概念有价值，但与赛事项目数据安全场景贴合度不足。 |

## 正式评阅建议

1. 先把 `bouderer` / `starswishes`、`gao-xing-li` / `recyclable06` 做同源对照，避免重复奖励同一实现。
2. 对头部候选项目优先复跑 PoC，确认“已实现”而不是“文档承诺”。
3. 对缺 Riding Record 的项目，在 Agentic Engineer 维度谨慎给分。
4. 对纯静态 Demo 项目，不因页面漂亮直接高分；重点看是否能证明四项 GRS001 命题。
5. 对完整赛事平台型项目，重点反查是否把提交、评测、队伍信息或隐藏数据持久化进 ARY，避免偏离“数据安全的 Race”。