hangshuo652/L2keka
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

初始提交：ai-review 项目当前版本（含赛道一/二提交规范修订与时间节点文档）

Browse Source
This commit is contained in:
hangshuo652
2026-08-23 11:52:45 +08:00
commit 4da7044c4b
152 changed files with 33490 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
server/config/standards/AI人才育成L2.md
+357
View File
@@ -0,0 +1,357 @@
## 功能完整性（40分）
检查以下5项：
1. 核心功能实现（12分）
- 题目要求的主要功能全部实现且可运行 → 12分
- 主要功能实现但有边角缺陷 → 9-11分
- 部分核心功能实现，其余有框架或占位 → 6-8分
- 仅有框架无实际功能 → 0分
2. 异常处理（8分）
- 有错误提示且覆盖LLM超时/不可达等主要场景 → 8分
- 有错误提示但不完整，或仅有降级处理之一 → 5-7分
- 无错误提示但有显式错误反馈 → 3-4分
- 无任何异常处理 → 0分
3. 边界情况（6分）
- 空数据、异常输入均正确处理 → 6分
- 部分边界场景处理 → 3-5分
- 无边界处理但程序不崩溃 → 1-2分
- 边界输入导致崩溃 → 0分
4. 业务逻辑正确性（8分）
- 统计结果与手算一致，检索结果相关 → 8分
- 大部分场景正确，个别边界有误 → 5-7分
- 存在明显逻辑错误 → 0-4分
5. 可运行性（6分）
- README步骤可直接运行，无启动报错 → 6分
- 需少量额外步骤可运行 → 3-5分
- 无法运行 → 0分
【交叉验证规则】
- README声称的功能，必须在代码目录中找到对应的实现文件，否则视为未实现
- 声称"支持异常处理"→代码中必须有try-catch或错误处理逻辑，否则扣4分
- 声称"支持多种数据格式"→代码中必须有对应的格式处理逻辑，否则扣3分
## 设计文档（10分）
检查以下3项：
1. 架构图（4分）
- 有架构图或数据流图（若无→0分）
- 图表清晰、标注完整
2. 技术选型理由（3分）
- 为什么选择该技术栈（opencode + 课程技术）
- 各组件的作用说明
3. 关键设计决策（3分）
- 设计上的取舍和理由
- 边界情况处理策略
## 测试用例与测试结果（10分）
检查以下3项：
1. 测试用例数量（3分）
- ≥3个测试用例（若无→0分）
2. 测试覆盖（4分）
- 覆盖核心逻辑的正常路径和异常路径
3. 结果可复现（3分）
- 测试结果附在提交物中
- 评审者能按步骤复现
【交叉验证规则】
- AGENTS.md或README中声称的"测试覆盖核心功能"，必须在代码中找到对应的测试文件（*.spec.ts, *.test.ts, test_*.py等），否则视为造假扣4分
- 测试文件内容必须有断言（assert/expect/should等），仅有文件骨架而无断言视为无效测试，扣2分
- 声称"测试全部通过"但测试代码中存在明显语法错误或引用不存在的模块 → 视为造假，该项0分
## AI协作过程记录（15分）
检查以下4项：
1. AGENTS.md存在（3分）
- 项目根目录有AGENTS.md文件（若无→0分）
2. prompt记录（5分）
- 记录了使用的prompt原文
- 记录了生成过程
3. 人工修正点（4分）
- 记录了AI生成代码后的人工修改
- 记录了修改理由
4. 问题与对策（3分）
- 记录了遇到的问题
- 记录了解决方案
【交叉验证规则】
- AGENTS.md中声称的"使用了XX技术"，必须在代码中找到对应的配置或调用文件
- 如果AGENTS.md说"用SpecKit"，但代码中没有spec/PRD/TECH_SPEC.md文件 → 视为夸大，扣3分
- 如果AGENTS.md说"对LLM输出做了质量验证"，但代码中没有对应的验证逻辑 → 视为虚构，扣3分
- 如果AGENTS.md说"编写了测试覆盖核心逻辑"，但实际没有测试文件或测试内容与描述不符 → 视为造假，该项0分
## 技术选型与范式运用（15分）
检查以下4项：
1. 课程技术运用（5分）
- 至少选择了1项指定技术（VibeCoding/Superpowers/SpecKit/Skill/MCP）
- 技术运用方式合理
2. 选型理由（4分）
- 说明了为什么选择该技术组合
- 与题目场景匹配
3. 范式运用（3分）
- 运用的范式（SpecKit/VibeCoding等）有明确记录
- 范式选择与题目特性匹配
4. 技术组合深度（3分）
- 组合多项技术的加分
- 技术之间有明确的调用/协作关系
【交叉验证规则】
- 声称使用了"Skill"→代码中必须有对应的Skill定义文件或注册代码，否则扣3分
- 声称使用了"SpecKit"→项目中必须有spec/PRD/TECH_SPEC.md文件，否则扣3分
- 声称使用了"MCP自动化测试"→必须有MCP Server配置或测试脚本调用代码，否则扣3分
- 声称"组合了多项技术"→必须有明确的调用链路（如A技术调用B技术的代码），否则扣3分
## 代码质量 + README（10分）
检查以下3项：
1. 代码结构（4分）
- 结构清晰、命名规范
- 无大量重复代码（重复率>30%扣分）
2. README完整性（4分）
- 包含：环境要求、安装步骤、运行方法、功能说明
- README步骤能直接运行成功
3. 依赖管理（2分）
- 依赖清单完整
- 无多余/缺失的依赖
【交叉验证规则】
- README声称的项目功能，必须在代码中有对应的入口文件或模块，否则视为夸大，扣2分
- README声称的"支持XX平台/环境"，必须有对应的配置文件（Dockerfile、.nvmrc等），否则视为不实，扣1分
## 第二部分：问题别L3追加维度
L3为追加评审，仅在L2合格（共通≥60分）后自动触发。
## [Q2] LLM生成问卷（15分）
检查以下3项：
1. 问卷生成逻辑（6分）
- 代码中是否有LLM调用生成面谈问题的逻辑
- 问卷内容是否与低分维度数据联动（非固定模板文案）
2. 定制化（5分）
- 是否支持按部门/职级生成不同问题
- 问卷内容是否可编辑
3. 问题质量（4分）
- 生成的问题是否基于具体数据
- 不是通用模板问题
## [Q2] LLM自由文本分析（10分）
检查以下两项：
1. 话题分类/摘要（5分）
- 面谈分析页面是否包含AI生成的话题分类结果
- 是否有自由文本的摘要/分析
2. 共性问题提取（5分）
- 是否能跨面谈记录发现高频出现的问题主题
- 提取的共性问题是否准确
## [Q2] prompt工程与调优记录（5分）
检查以下一项：
1. prompt调优过程
- AGENTS.md中是否有prompt调优过程记录
- 不同策略的对比
- LLM输出质量验证方法
## [Q3] LLM检索回答（11分）
检查以下两项：
1. LLM生成回答（7分）
- 代码中是否有LLM生成回答的逻辑（非单纯关键词匹配）
- 回答是否引用出处文档名/章节/页码
2. 置信度显示（4分）
- 回答附带置信度分数
- 可信度标识清晰
## [Q3] 上下文连续对话（10分）
检查以下两项：
1. 追问支持（5分）
- 是否支持在上一轮基础上继续提问
- 上下文理解是否正确
2. 对话管理（5分）
- 代码中是否有上下文管理机制
- 对话状态是否在UI中可见
## [Q3] 无法回答处理（10分）
检查以下两项：
1. 无法回答检测（5分）
- 对制度文档中不存在的问题，是否明确返回"未在现有制度中找到相关信息"
- 不编造答案
2. 合理引导（5分）
- 是否给出合理解释或建议
- 是否引导用户调整提问方式
## [Q3] RAG管道设计记录（19分）
检查以下4项：
1. chunk策略设计（5分）
- AGENTS.md是否记录了chunk大小/重叠率选择理由
- 不同分割策略的对比
2. embedding模型选型（5分）
- 是否说明了embedding模型选择理由
- 是否对比了不同模型的效果
3. 检索策略对比（5分）
- 是否记录了关键词/向量/混合检索的对比
- 检索准确率改善过程
4. 多语言处理策略（4分）
- 是否说明了中日文混合检索的处理方案
- 分词/索引策略的差异处理
## [Q4] LLM条款提取（10分）
检查以下两项：
1. 关键字段提取（5分）
- 代码中是否有通过LLM提取合同关键字段的逻辑
- 提取字段包括：金额、期限、违约责任、管辖法院等
2. 提取准确度（5分）
- 审查报告中提取的字段是否正确
- 是否支持多份合同验证
## [Q4] LLM风险标记（10分）
检查以下两项：
1. 风险条款标记（5分）
- 是否有AI自动标记风险条款的功能
- 审查结果页面是否展示风险项
2. 风险判断理由（5分）
- 每条风险标记是否附带判断理由
- 理由是否合理
## [Q4] prompt工程与规则设计记录（10分）
检查以下两项：
1. 审查规则设计（5分）
- AGENTS.md是否记录了审查规则设计过程
- 风险标准定义的迭代
2. prompt调优（5分）
- prompt调优过程记录
- 不同策略的对比
## [Q5] LLM内容提取（10分）
检查以下两项：
1. 法规字段提取（5分）
- 代码中是否有AI解析网页内容提取法规字段的逻辑
- 提取字段包括：法规名称、发布机关、发布日期、摘要
2. 提取质量（5分）
- 提取结果是否准确
- 是否支持不同的网页结构
## [Q5] LLM影响度评估（10分）
检查以下两项：
1. 影响度自动判断（5分）
- 是否有AI自动评估高/中/低影响度的功能
- 判断依据是否来源于LLM分析
2. 影响度展示（5分）
- 影响度在结果列表中是否清晰标识
- 高影响度是否突出显示
## [Q5] prompt工程与爬虫策略记录（10分）
检查以下两项：
1. 爬虫策略设计（5分）
- AGENTS.md是否记录了爬虫规则设计
- 反爬策略
2. 提取准确率改善（5分）
- 提取准确率的改善过程
- 不同网站结构的处理策略
## [Q6] LLM风险分类（10分）
检查以下两项：
1. 自动分类逻辑（5分）
- 代码中是否有AI自动将情报按领域分类的逻辑
- 分类维度是否与预设一致（汇率/法规/日中关系/行业/技术）
2. 分类展示（5分）
- 分类结果在界面中是否清晰展示
- 是否支持按分类筛选
## [Q6] LLM影响度评估（10分）
检查以下两项：
1. 风险等级评估（5分）
- 是否有AI根据内容评估风险等级的功能
- 评估依据是否可追溯
2. 高风险处理（5分）
- 高风险情报是否自动突出显示
- 是否有通知机制（系统内/模拟邮件）
## [Q6] prompt工程与分类策略记录（10分）
检查以下两项：
1. 分类模型选择（5分）
- AGENTS.md是否记录了分类模型选择理由
- 影响度评估标准定义
2. 策略调优（5分）
- 通知规则设计
- 分类准确率改善过程
## 合格判定一览
| 题目 | 难度 | 共通满分 | 追加满分 | 总分上限 | L2合格 | L3合格 |
|:----|:----:|:--------:|:--------:|:--------:|:------:|:---
server/config/standards/技术大赛-赛道一.md
+299
View File
@@ -0,0 +1,299 @@
### 1. 场景价值与技术合理性（10分）
检查以下4项：
1. 真实需求（3分）
- 解决的是真实业务需求还是虚构场景
- 有明确的行业/用户场景
2. Agent不可替代性（3分）
- 为什么非用Agent不可，不是传统脚本/工具能解决的
- Agent的自主决策/工具调用/多步推理是否必要
3. ROI可量化（2分）
- 效率提升/成本降低等有数据支撑
- 效果的量化指标明确
4. 场景文档完整性（2分）
- 业务背景、痛点分析、方案对比齐全
- 需求文档结构完整
> 无场景文档 → 0分
---
### 2. 开发范式应用（5分）
检查以下3项：
1. 开发流程覆盖（2分）
- AI日志是否覆盖需求分析→设计→编码→测试的完整流程
- 流程各阶段有明确记录
2. 设计文档质量（2分）
- 是否有需求分析、架构设计、接口设计文档
- 文档之间逻辑一致
3. 测试文档质量（1分）
- 是否有测试用例、测试计划、测试报告
- 测试结果可复现
> 没有任何一个维度的证据 → 0分
---
### 3. 架构设计（10分）
架构文档存在性 + 代码反向推断。
1. 架构文档存在且质量高（3分）
- 有 DESIGN.md / docs/design.md 等完整文档
- 包含系统模块划分、组件关系、数据流
2. 模块化与分层（3分）
- 代码是否按职责分层、模块间依赖是否合理
- 高内聚低耦合
3. 数据流清晰度（2分）
- 数据流转路径是否可追溯
- 状态管理一致
4. 可扩展性（2分）
- 是否有接口抽象、插件机制等便于扩展的设计
- 预留扩展点
**文档规则：**
- 有完整架构文档：可评至满分10分
- 无文档但有代码证据：封顶5分（允许根据代码结构反向推断模块/分层/数据流）
- 无文档且代码混乱：1-3分
---
### 4. 工具使用与Skill集成深度（5分）
AI框架集成深度 + 开发工具链。
**AI框架集成（3分）：**
- 无框架使用 → 0分
- 使用框架基本功能（chain/pipeline）→ 1分
- 实现了MCP/Function Calling协议 → 2分
- 自定义Agent工具链、有深度框架定制 → 3分
**开发工具链（2分）：**
- IDE集成（VSCode插件/LSP/Webview面板等）→ 1分
- CI/CD配置（GitHub Actions/Jenkins等）、监控/可观测性 → 1分
> 两项可叠加，上限5分
---
### 5. Agent核心能力（25分）
**4项硬性门槛条件（二进制判定，缺任意1个→整个维度0分）：**
所有条件必须从代码中提取具体证据：
1. 调用了外部LLM/推理引擎
- 代码中存在对LLM API的调用（openai/deepseek/fetch LLM endpoint）
- 或通过框架抽象调用（LangChain ChatOpenAI / AutoGen LLM config）
2. 有明确的工具选择策略
- 存在if-else/switch/map路由逻辑，根据条件选择不同工具执行
- 无条件分支的直接调用→不通过
3. 存在错误→重试→切换路径
- 存在try-catch+retry loop/fallback handler/降级路径
4. 有跨步骤的状态持久化
- 存在上下文对象传递、DB写状态、session存储、消息历史维护中的至少一项
**5项评分要素：**
| 评分项 | 分值 | 评价基准 |
|:-------|:---:|---------|
| Agent存在性 | 4分 | 满足4个门槛条件→4分，缺任意1个→整个维度0分 |
| 工具调用能力 | 6分 | 静态if-else工具选择→3分；动态prompt决策/多工具编排→6分 |
| 自主规划能力 | 5分 | 有任务分解（script/model/Agent call）→3分；递归/动态重规划→5分 |
| 协作机制 | 3分 | 多Agent通信（消息总线/共享memory）→3分；自主任务分配/协商→加分 |
| 可靠性 | 4分 | retry+timeout→2分；fallback+降级策略→4分 |
> 所有评分必须引用具体代码文件和行号
---
### 6. 实现完整度与稳定性（20分）
检查以下5项：
1. 功能完整性（8分）
- 核心功能路径是否完整可运行
- 题目要求的全部功能是否实现
2. 构建可运行（4分）
- 项目能否正常构建（npm install/pip install/mvn compile等）
- 构建无报错
3. 服务可启动（3分）
- 能否正常启动服务
- README步骤可直接运行
4. 重试/降级机制（3分）
- LLM调用是否有超时处理和重试
- 是否有降级方案
5. 错误处理（2分）
- 异常输入是否有明确提示
- 错误信息是否友好
---
### 7. 规模与功能点（20分）
检查以下4项：
1. 代码规模（5分）
- 基准分（每500行有效代码→0.5分，最多3分）
- 语言多样性（3种以上语言→2分，1-2种→1分）
2. 功能点覆盖（6分）
- 核心功能完整度
- 功能复杂度（CRUD vs 复杂业务逻辑 vs 算法实现）
- 重复代码>30%→扣3分，>50%→扣全部6分
3. 可演示性（2分）
- 有启动配置（Dockerfile/scripts.start）→1分
- 有Web/CLI演示入口 →1分
4. 数据与测试覆盖（2分）
- 有测试数据/样本 →1分
- 有测试覆盖且通过 →1分
---
### 8. 代码规范性（10分）
检查以下5项：
1. 命名与组织（2分）
- 函数/变量/类命名一致且有意义的英文名
- 文件大小合理（>500行标记过大，<10行标记过小）
- import/require有序，无未使用导入
2. 硬编码检测（2分）
- 无绝对路径（如 D:\， /home/， C:\Users\）
- 无明文密钥/密码/token
- 无魔鬼数字（magic number）
3. 重复代码（2分）
- 重复率>30%→≤1分，>50%→0分
4. 安全规范（2分）
- 无eval/exec动态执行用户输入
- 无SQL拼接注入风险
- 错误信息不泄漏内部路径/配置
5. 注释与文档（2分）
- 必要注释（复杂逻辑/公开API）存在
- 无大量无意义注释
- 无堆积的 TODO/FIXME
---
### 9. 演示与文档（10分）
检查以下4项：
1. README完整性（3分）
- 是否有README.md（若无→0分）
- 是否包含：项目说明、安装步骤、使用示例
- 是否包含：技术栈、依赖说明
2. API/架构文档（2分）
- 是否有接口/API说明文档
- 是否有架构图或数据流说明
3. 启动与构建说明（2分）
- 是否有明确的构建/启动命令
- 是否有环境要求说明
4. 文档一致性（3分）
- 文档描述与实际代码结构一致
- 无过期/废弃文档
---
### 10. AI使用日志（5分）
检查以下3项：
1. AI使用记录（2分）
- 有CLAUDE.md/AGENTS.md等文件记录AI协作方式 → 2分
- 仅有skill/agent配置但无使用记录 → 1分
- 完全无任何AI相关文件 → 0分
2. 调用细节（2分）
- 记录了每次AI调用的时间、模型、目的
- 记录了prompt原文
3. 真实性验证（1分）
- 日志内容与代码提交历史一致
- 无伪造/编造的日志条目
【交叉验证规则】
- AGENTS.md声称的"使用了XX技术"，必须在代码中找到对应的配置或实现文件，否则扣2分
- 声称"调用细节记录了prompt原文"但文件内容为空或只有模板文案 → 视为不实，扣2分
---
### 11. 效果与数据（20分）
检查以下5项：
1. 测试覆盖（5分）
- 是否有单元测试（若无→0分）
- 测试是否覆盖核心功能路径
2. 测试工具与框架（3分）
- 是否使用标准测试框架（pytest， jest, JUnit等）
- 是否有自动化测试配置（CI、pre-commit等）
3. 效果验证数据（4分）
- 是否有性能基准、正确性验证数据
- 是否有对比数据（如AI生成vs手写对比）
4. 覆盖率报告（4分）
- 是否有覆盖率报告（如gcov， coverage.py, jest --coverage）
- 覆盖率≥80%→4分，≥50%→2分，<50%→0分
5. 测试结果可复现（4分）
- 测试环境配置明确
- 测试数据随仓库提供（非外部依赖）
---
### 12. 安全性（10分）
检查以下4项：
1. 密钥管理（3分）
- 无硬编码API Key/Token
- 使用环境变量或配置文件管理
2. 输入验证（3分）
- 用户输入有校验和过滤
- 防止注入攻击
3. 敏感信息保护（2分）
- 日志中不输出敏感信息
- 错误页面不暴露内部路径
4. 依赖安全（2分）
- 无已知漏洞的依赖
- 依赖版本明确
---
## 合格判定
- **L2合格**: 总得分率 ≥ 60%
- 迟交处理：1~3个工作日扣5分，4~7个工作日扣10分，超过7个工作日按0分处理
server/config/standards/技术大赛-赛道二.md
+215
View File
@@ -0,0 +1,215 @@
### 1. 开发范式设计清晰度（20分）
检查以下4项：
1. 范式定义清晰度（6分）
- 对所选范式（VibeCoding/SpecKit/Flow-State等）有明确定义和说明 → 6分
- 提到范式但缺乏方法论说明 → 3-4分
- 未说明开发范式 → 0分
2. 范式应用一致性（6分）
- 代码实现与所选范式一致 → 6分
- 部分遵循但有明显偏离 → 3-4分
- 宣称的范式与实际实现不符 → 0分
3. 范式闭环（4分）
- 范式是否有闭环反馈机制（设计→执行→验证→改进）→ 4分
- 有部分反馈机制 → 2分
- 无反馈机制 → 0分
4. 升级项目考量（4分）
- 升级项目需含存量流程分析和痛点改进说明 → 4分
- 新規项目此项自动得满分
> 范式图+AI日志对照验证范式是否完整可复制
【交叉验证规则】
- 范式图或AI日志声称使用了某范式，但代码中找不到对应产物（如声称SpecKit但无spec/PRD/TECH_SPEC.md文件）→ 范式应用一致性扣4分
- 声称"范式闭环"，但AI日志中无设计→执行→验证→改进的对应记录 → 范式闭环项扣2分
---
### 2. IDE集成深度（20分）
检查以下3档（根据实际达成的最高层级评分，不累加）：
**基础（1-5分）：**
- 使用了CLI工具（如cursor CLI、gh CLI）→ 2分
- 配置了agent rules（如.cursorrules、CLAUDE.md）→ 3分
- 实现了基本的IDE快捷键和AI对话使用 → 5分
**中级（6-12分）：**
- 使用了Agent模式/Chat模式/Composer等交互模式 → 6-8分
- 配置了MCP Server等扩展能力 → 9-10分
- 实现了自定义命令和工作流 → 11-12分
**高级（13-20分）：**
- 使用了自定义MCP、自动化pipeline → 13-16分
- 深度集成CI/CD、自定义脚本进行AI协作 → 17-18分
- 在多Agent/多IDE间进行了协同 → 19-20分
> 关键判断依据：是否在IDE内集成（VSCode插件/webview等），能否自动获取上下文，是否一键触发
---
### 3. 提效设计合理性（10分）
检查以下4项：
1. 提效领域选择（2分）
- 选择的提效领域有明确业务背景和痛点分析 → 2分
- 背景分析不充分 → 1分
- 未说明背景 → 0分
2. 方案设计合理性（3分）
- 提效方案在技术架构上合理且完整 → 3分
- 方案部分合理但有明显缺陷 → 1-2分
- 方案不合理或不可行 → 0分
3. 实现路径清晰度（2分）
- 有具体的实现步骤、时间线、预期效果 → 2分
- 有大致步骤但不够具体 → 1分
- 无实现路径 → 0分
4. 可迁移性（3分）
- 方案可在其他项目/团队中复用 → 3分
- 部分可复用但需定制 → 1-2分
- 仅适用于当前项目 → 0分
---
### 4. 提效幅度（10分）
检查以下4项：
1. 对比数据（3分）
- 是否有对比数据证明提效 → 3分
- 有部分数据但不完整 → 1-2分
- 无对比数据 → 0分
2. 数据可验证性（2分）
- 原始数据完整可验证 → 2分
- 数据部分可追溯 → 1分
- 数据不可验证 → 0分
3. 改善效果（3分）
- 提效效果明显（如时间减少50%以上）→ 3分
- 有一定改善但不显著 → 1-2分
- 无明显改善 → 0分
4. 升级项目ROI（2分）
- 升级项目需提供投入产出比(ROI)和效果可验证数据 → 2分
- 新規项目此项自动得满分
【交叉验证规则】
- 声称"提效X%"→ 必须有对比数据/测量脚本/日志时间戳支撑，否则降档至≤1分
- 声称"新規项目自动满分" → 需有明确的项目背景说明（非升级项目的理由），无说明按0分
---
### 5. 稳定性与易用性（15分）
检查以下5项：
1. 一键安装（3分）
- 是否可一键安装（npm install/pip install等）→ 3分
- 需要多步手动操作 → 1-2分
- 无法安装 → 0分
2. 运行稳定性（3分）
- 运行是否稳定，无意外崩溃 → 3分
- 偶发崩溃但不影响核心功能 → 1-2分
- 频繁崩溃 → 0分
3. 重试/降级机制（3分）
- 有完善的重试和降级机制 → 3分
- 有部分机制 → 1-2分
- 无任何机制 → 0分
4. 错误处理（3分）
- 错误提示清晰、覆盖主要异常场景 → 3分
- 有基本错误处理 → 1-2分
- 无错误处理 → 0分
5. 兼容性（3分）
- 升级项目需验证与原环境兼容性 → 3分
- 新規项目此项自动得满分
---
### 6. 规模与功能点与技术难度（10分）
检查以下3项：
1. 代码规模（3分）
- 小规模（≤3个功能点）→ 1分
- 中规模（4-7个功能点）→ 2分
- 大规模（>7个功能点，多IDE支持）→ 3分
2. 技术难度（4分）
- 涉及多语言支持 → 1分
- 涉及复杂UI/交互 → 1分
- 涉及性能优化 → 1分
- 涉及框架深度定制 → 1分
3. 功能完整性（3分）
- IDE集成功能完整可用 → 3分
- 部分功能可用 → 1-2分
- 核心功能缺失 → 0分
---
### 7. 演示与文档（5分）
检查以下3项：
1. 演示视频（2分）
- 演示视频≤5分钟，完整展示工作流和异常场景 → 2分
- 有演示但不够完整 → 1分
- 无演示 → 0分
2. 文档清晰度（2分）
- 文档结构清晰、内容完整 → 2分
- 有文档但不完整 → 1分
- 无文档 → 0分
3. 安装说明（1分）
- 安装步骤详细、可复现 → 1分
- 有缺失或错误 → 0分
---
### 8. AI使用日志（10分）
检查以下4项：
1. 日志覆盖（3分）
- 日志覆盖需求/设计/编码/测试各环节 → 3分
- 覆盖部分环节 → 1-2分
- 无日志 → 0分
2. 范式步骤标注（3分）
- 标注了范式步骤和涉及文件路径 → 3分
- 有标注但不完整 → 1-2分
- 无标注 → 0分
3. 文件路径可回查（2分）
- 文件路径可回查验证 → 2分
- 路径信息不完整 → 1分
- 无路径信息 → 0分
4. 调优记录（2分）
- 记录了范式选择和调优过程 → 2分
- 有记录但不详细 → 1分
- 无记录 → 0分
【交叉验证规则】
- AI日志声称使用了某工具/范式，但代码中找不到对应的配置或文件（如声称用MCP但无server配置，声称用SpecKit但无spec文件）→ 该项扣2分
- 日志中标注的文件路径无法回查 → 扣1分
---
## 合格判定
- **L2合格**: 总得分率 ≥ 60%
- 迟交处理：1~3个工作日扣5分，4~7个工作日扣10分，超过7个工作日按0分处理