大家都已经进入最后的冲刺阶段了，关于编写代码和答辩的注意事项请大家看这篇～
大赛日程
12/3 腾讯会议直播链接：
#腾讯会议：500-568-778
| 时间 | 内容 | 嘉宾 |
|---|---|---|
| 9:30 | Hackathon 开幕 & 规则再讲解 | 胡渊鸣 |
| 11:00 | 参赛队伍可自由介绍 | |
| 12:00 | 午餐闲聊 | |
| 14:00 | Taichi 知识有奖竞答 | 胡渊鸣 |
| 16:00 | Taichi 知识有奖竞答 | 匡冶 |
| 18:00 | Taichi 知识有奖竞答 | 刘天添 |
| 20:00 | 答辩顺序抽签+抽奖 | 胡渊鸣,匡冶,刘天添 |
12/4 下午 13:00 开始 （预估）
B 站太极图形直播间 或太极图形视频号或知乎视频号
项目汇总：Taichi Hackathon 赛队项目大公开！速来围观～
| 时间 | 内容 |
|---|---|
| 13:10- 15:40 | 答辩 |
| 15:40-15:50 | 中场休息 |
| 15:50-17:50 | 答辩 |
| 17:50-18:20 | 晚餐 |
| 18:20-19:20 | 答辩 |
| 19:20-19:50 | 后台汇总结果，请大家不要离开直播间～ 还会有互动抽奖环节～ |
| 19:50 | 颁奖 |
编写代码：
-
各参赛团队从 11/30 起可以编写代码，如果想和队友更好协作欢迎在 Taichi 社区 slack 中创建 channel，与团队同步代码和链接都会更加直观清晰，slack 的一键发起通话+屏幕分享功能也很方便，大家可以尝试~
-
Taichi 目前最新版本为 v1.3，如果需要用到最新版本的 feature 可以升级 Taichi。如果需要稳定性更佳比赛期间推荐使用 v1.2.2。
-
大家在做项目时遇到 Taichi 相关的问题可以在 slack #general 或者论坛提问，我们会有技术支持的同学回答哦~
- 感谢烧风同学的 cheatsheet 在线版，大家用起来！Taichi Language Cheatsheet SVG | HK-SHAO
答辩须知：
-
每个团队线上答辩展示时间为 6 分钟，主持人会分别在倒计时 1 分钟和时间到时提醒选手，由于本次答辩队伍较多，因此请答辩选手控制好时间不要超时~ 答辩结束后评委可进行提问，提问环节不超过 2 分钟，主持人会严格控制时间。
-
线上答辩内容：内容不限，但建议选手围绕评分维度尽可能展示 demo 的完成度、创新性以及技术难度。
-
为了更好展示项目 & 节约现场答辩时间，建议选手在 12/3 20:00 之前在 项目设计中更新项目背景、项目灵感来源等信息，与评分纬度相关的内容也可以更新在项目设计中，如项目的难点和技术攻克（需注明已经完成的部分）。评委会在答辩开始前再次阅读项目设计。*在 11/25 之前收到反馈的团队也可以将评委想了解的提问更新在项目设计中。
-
本次答辩不硬性要求提交 PPT，如果需要展示 PPT 的小组可以在这里下载 PPT 模板 Taichi Hackathon 2022 答辩 PPT 模板
-
本次答辩为全线上答辩，请参赛团队的答辩人提前下载好腾讯会议，我们的小助手会在近期与各团队答辩人取得联系，提前测试。
-
正式答辩时请将腾讯会议中自己的名称改为 你的答辩顺序-团队名-答辩人，便于我们确认，感谢大家~
-
答辩资料提交：
-
参赛团队代码截止提交时间为 12/4 日上午 11:00。如还有其他答辩资料如 PPT、Demo 等请一同在 12/4 上午 11:00 之前提交。
-
提交方式：PPT、Demo 请打包在一个压缩包内由队长发送至 community@taichi.graphics。邮件标题请注明：Taichi Hackathon 2022 答辩资料-团队名
-
还有部分没有提交 repo 地址的小伙伴请注意，小助手会私信队长收集项目 Repo，评委会对项目的工程质量进行打分～
-
-
答辩 Tips：
- 答辩时请控制好时间，建议可以先排练。如果项目比较难可以在项目设计中展现技术难度的部分，答辩时可以简单介绍一下项目背景帮助听众快速入门。
- 建议选手录制一个 Demo 保证答辩时运行流畅
评分维度
- 创新性：作品的创新程度，有趣程度，令人「哇哦」 的程度（30% ）
- 完成度：作品的内容完整性。Talk is cheap, show me the code（30% ）
在创新的同时找到现实可实现的方式，在规定的时间之内完成代码，能够具有较大的完成度，与创新性相互制约。
- 挑战性：项目的技术复杂度，作品的难度（25% ）
要求具有一定的技术复杂程度，让人眼前一亮。Hackathon 搭建一个炫技的平台，选手们可以放下平时的制约，将代码写的比较可读的同时实现非常 fancy 的功能。
- 工程质量：代码的可读性、质量等（15%）
作品具有可读性，能够帮助到其他社区的伙伴，具有一定影响力。如果代码可读性不太好，没有一个能够运行起来的指南，这个代码在参加完这个比赛后可能就浪费了。
比如：有没有 requirements.txt、变量名是否合理，无汉语拼音、是否有编译、运行的操作指令、README.md 展示是否直观等。指路 requirements.txt