AI写鸿蒙代码怎么算合格

一只蚂蚁、

101人浏览 · 2026-11-09 16:15:59

一只蚂蚁、 · 2026-11-09 16:15:59 发布

AI 写鸿蒙代码怎么算合格：从鸿蒙杯赛制看一套可照搬的验收标准

11 月 6 日下午，在天津社会山国际会议中心，2026 AI 辅助研发创新大赛（鸿蒙杯）决赛开考。近 40 所高校、100 余支队伍里杀出来了17 支队伍，他们在 150 分钟限时内围绕一份统一的赛题，用 AI 工具完成鸿蒙应用的开发、调试与提交。

这场比赛最值得开发者关注的，不是谁拿了奖，而是它的评分方式：AI 写的代码合不合格，不是评委看着打分，而是 Hypium 测试跑出来的。整套赛制把「AI 参与研发怎么验收」这件事拆成了四个可执行的环节，而这四个环节，几乎可以原样搬进任何一个用 Coding Agent 写鸿蒙应用的团队。

一、先看赛制：四层设计，环环扣死

鸿蒙杯由中国软件行业协会开发者生态专业委员会主办，复旦大学计算与智能创新学院、北京航空航天大学软件学院、天津大学软件学院承办，华为终端软件架构设计部、华为终端开发者平台部等单位参与。赛事通知 9 月 28 日发布，决赛 11 月 6 日在 ChinaSoft 2026 大会现场举行。

整个赛制可以拆成四层：

层	赛制里的做法	回答的问题
需求	统一发布赛题需求规格（Spec）	「做什么」不许口头传达
起点	指定工程基线，从基线开始改	改了什么必须可对比
验收	Hypium 功能测试，按 F-point 计分	「合格」由测试判定，不由人判断
留痕	提交 AI 原始记录，逐题核验参与过程	代码是谁写的心里有账

这四层合起来回答了一个所有团队都在纠结的问题：让 Agent 写代码之后，管理者怎么知道活儿干没干对、是不是真的 Agent 干的。

二、F-point：把「合格」变成一条条可执行断言

赛制最硬核的部分是计分方式。功能测试以 F-point（Feature Checkpoint，可执行功能检查点） 为单位，每个 F-point 对应依据 Spec 确定的一个可判定行为点，用 Hypium 测试方法验证：

功能测试分 = 通过的 F-point 数 ÷ 该阶段 F-point 总数 × 100

规则里有几处细节很见功力：

未提交、缺失实现、构建或安装失败、崩溃、超时、跳过，对应的 F-point 都不计通过，但仍然计入总数。 也就是说，摆烂不会拉低分母，「没做完」本身就是扣分。
允许部分任务未完成。 不逼你交完整的 App，但每一分都要靠跑得通的测试挣。
测试脚本、隐藏输入、断言和参考答案全部不公开。 想靠「对着测试用例写代码」过关，没门。

对个人开发者来说，这就是把「我感觉功能差不多了」翻译成「第 37 条断言过了」的过程。鸿蒙生态本来就有 Hypium 这套测试框架，缺的从来不是工具，而是需求阶段就把验收点写出来的纪律。

三、留痕：AI 会话记录本身是交付物

第二硬核的是对「AI 真的参与了」的核验要求。赛制明确：

每道计分题都必须能独立核验 AI 实际参与本题研发，不得拿其他题目的记录、无关对话或事后补造的交互来充数。
支持会话导出的工具须提交 DB 原始文件；不支持的，提交 JSON、JSONL 等原生完整记录。
记录范围覆盖全部主会话、子会话、失败、重试、未采用候选方案及选择过程，连 AI 走过的弯路都要交。
摘要、截图和分析报告不能替代原始记录。
人工修改代码也要留证：版本控制、编辑历史、快照或终端日志，并列明操作人、目的、文件和修改前后差异。
违规的代价很具体：核查后无法证明 AI 实际参与的题目，该题全部 F-point 不计通过，且仍计入总数。

注意一个容易忽略的点：赛制不设 AI 生成代码行数或人工修改比例门槛。它不关心你人工改了多少，只关心整个过程是不是真实、可复盘。这是比「AI 使用率 KPI」成熟得多的思路，管过程真实性，不管比例。

四、答辩 20%：考的是「你是不是真的懂」

最终成绩 = 线下功能测试分 × 80% + 答辩分 × 20%。

答辩环节每队 6 分钟：讲解 4 分钟、问答 2 分钟，依据已冻结的代码和材料进行，由 3 名无利益冲突的考核专家独立评分，按 0%、25%、50%、75%、100% 五档打分，去掉主观印象分。未参加答辩的队伍不进入最终获奖名单。

这 20% 的设计意图很清楚：测试分证明代码能跑，答辩证明人真的理解代码。团队用 Agent 批量生成代码后最怕的「没人说得清这段为什么这么写」，在这里直接对应丢分。

五、可照搬：团队版验收清单

把赛制翻译成日常研发动作，下面这份清单可以直接抄进团队规范：

需求写成 Spec，不口头传达。 给 Agent 的任务和给人的任务一样，先写清输入输出、边界条件和异常行为，再开工。
固定工程基线。 每个任务从一个明确的代码版本出发，交付时附「从基线到提交版本的完整变更差异」，鸿蒙工程里就是 git diff 加上 build-profile.json5、module.json5 等配置的变更说明。
验收点前置。 需求评审时就把每个功能点写成 Hypium 可执行断言，验收 = 跑测试，而不是点一遍页面。
AI 会话当天归档。 用 DevEco Code（赛事推荐工具之一，不限厂商）这类支持导出的工具，把会话 DB 或 JSONL 按任务归档，失败的尝试也留着。
人工修改留痕。 提交信息写清谁改的、为什么改、改了哪些文件，对应到 commit 和 diff。
冻结再交付。 打包前停止所有人工修改和 AI 任务，注明冻结时点，让代码、配置、会话记录对应同一个版本；每次更新重新冻结，不做增量替换。
六分钟答辩式 review。 合入前让实现者对着冻结的代码讲 4 分钟、接受 2 分钟提问，讲不明白的，退回。

六、这套标准对个人开发者意味着什么

有人会觉得这是学生比赛的繁文缛节，个人开发没必要。恰恰相反，团队越小，这套流程的性价比越高。

大团队靠人多互相校对，个人开发者靠什么防止「Agent 生成了 3000 行我看不懂的代码」？靠的就是 Spec 前置、测试判定、会话留痕这三件事。它们不需要额外工具：DevEco Studio 自带 Hypium，DevEco Code 自带会话记录，git 自带 diff。缺的只是把它们串成习惯。

倒推一个时间点：11 月 28 日开源鸿蒙技术大会在南京设有「IDE 与 AI Coding」分论坛，AI 辅助鸿蒙开发的工程化实践大概率是重点议题。届时官方口径如果进一步明确，今天这套从鸿蒙杯提炼的验收标准，就是最好的对照底稿。

鸿蒙杯奖金最高两万元，17 支队伍里大多是学生，但它回答的问题属于每一个正在用 AI 写鸿蒙代码的人：怎么让「AI 写的」变成「可验收的」。答案是四件事：需求写成 Spec、合格交给测试、过程留成记录、理解放到答辩。

比赛会结束，这套标准不会。建议直接抄走第五节那份清单，从下一个任务开始试。

资料来源：2026 AI 辅助研发创新大赛（鸿蒙杯）官方通知及比赛章程（2026-09-28）、大赛初赛收官公告、科技日报 2026-11-08《筑基智能新时代 2026 CCF 中国软件大会在津开幕》、北方网 2026-11-07 大会开幕报道。赛事官网 swe-openharmony.tech。