狂想曲委员会——团队展示

狂想曲委员会 2026-10-08 23:43:11

狂想曲委员会——团队展示

这个作业属于哪个课程	https://bbs.csdn.net/forums/2601_CS_SE_FZU
这个作业要求在哪里	https://bbs.csdn.net/topics/620534332
这个作业的目标	完成团队组队与选题论证，明确《福大秋日狂想曲》的项目定位与技术方案；借助 NABCD 模型论证选题价值；制定团队绩效考核方案；完成团队展示
其他参考文献	《构建之法》第 11 章绩效管理；Ren'Py 8.5.3 官方文档 https://www.renpy.org/doc/html/%EF%BC%9B

一、队名与团队简介

1.1 队名

狂想曲委员会

队名的由来

我们的作品叫《福大秋日狂想曲》。"狂想曲"三个字来自我们都很喜欢的一个作品系列——它用"夏日""冬日""乡村""职场"这样的日常场景做题，以轻松幽默的笔调讲普通人的故事。我们敬佩的正是这种做法：不靠宏大设定，只靠把一个具体的季节、一个具体的地方、一群具体的人写活。

于是我们想：为什么不做一部属于我们自己学校的"狂想曲"？福州大学的秋天有自己的样子——满校园的榕树和落叶、期中考前图书馆抢座、社团招新的喧嚣、还有深秋夜里操场的跑道和风。这些是我们真实经历过的秋天，也是我们想讲的东西。

"委员会"这个后缀是一次自我调侃：五个大学生煞有介事地"成立委员会"，郑重其事地讨论一个喜剧游戏里主角该不该在第二次见面就表白。我们想做的就是这样一件"认真搞怪"的事。

与选题的关系：直接取自作品名，点明"校园 + 秋日 + 喜剧"的定位。
个性与亮点：既表达了对同类作品的敬意，又带着学生团队特有的自嘲与热情。
Slogan：把每一次心动，都写成可以重来的选择。

1.2 团队简介

项目	内容
团队人数	5 人
组长	林宇杰
项目形式	游戏——视觉小说（Visual Novel / 中文惯称 Galgame）
作品名	《福大秋日狂想曲》
题材	大学校园 · 秋日 · 喜剧 · 整活向 · 恋爱模拟
风格定位	幽默诙谐、节奏明快、梗密度高；大量使用网络热梗，但热梗只做调味，笑点主体来自具体的大学生活细节
主要场景	福州大学校园（宿舍、教学楼、图书馆、食堂、操场、校道、社团活动室）
剧情主线	主角在这个秋天同时遇上了两个让他心动的人，而那位一直陪他聊天的神秘网友"秋刀鱼"似乎也在这所学校里——他需要在秋天结束前，弄清楚自己想要的到底是什么
计划技术栈	引擎：Ren'Py 8.5.3（Python 3）版本管理：Git + Git LFS 美术：实拍素材 + AI 风格化 + 统一调色音频：CC0 素材库 + 成员本人配音开发协作：AI Coding Agent（Codex / DeepSeek Harness）辅助 + 人工评审门禁
计划规模	共通线 3 章 + 2 条可攻略线 + 1 条隐藏 IF 线，共 5 个结局，单周目 60—90 分钟

技术选型的详细论证见附件文档《技术栈与框架设计》（附链接）。

二、队员风采

成员 1 —— 林宇杰 / 黄毛大王

项目	内容
学号	102400222
姓名 / 昵称	林宇杰 / 黄毛大王
CSDN 地址	https://blog.csdn.net/LLLINGGGG
性格	开朗外向，喜欢交别人的朋友
擅长的技术	Python、Ren'Py 脚本、基础 UI 设计、Unity
兴趣爱好	健身、游戏
希望的软工角色	后端 / 美术 / 测试
一句 slogan	如果你不做旮旯给木，那我不要和你说话
想在这个项目里收获什么	希望通过本次团队项目掌握 Ren'Py 视觉小说开发与工程化协作流程，实践 AI 辅助开发，完整走完从设计到发布的项目全流程并收获可演示的作品集。

在团队中承担：PM（组长）。负责排期与任务拆解、里程碑跟踪、对外沟通、周报归档与团队决策；同时主导测试用例设计与路径走查，并负责素材风格化与调色管线。

成员 2 —— 陈材臻

项目	内容
学号	022401402
姓名 / 昵称	陈材臻
CSDN 地址	https://blog.csdn.net/Komatsu_Nana_
性格	认真负责，乐于交流，做事有条理，喜欢探索新事物
擅长的技术	C/C++、Python、SQL、Vue 3、FastAPI、AI 辅助编程
兴趣爱好	健身、跑步、阅读、人工智能
希望的软工角色	后端 / PM / 前端
一句 slogan	保持好奇，持续学习，让想法落地。
想在这个项目里收获什么	提升软件工程实践能力，积累完整的项目开发经验，学习团队协作与项目管理，探索 AI 技术在软件开发中的应用。

在团队中承担：工程化 / 工具链。负责素材检查脚本、构建与打包流程、发布准备与版本管理；同时配合 PM 维护任务看板、统计考核所需的进度数据。

成员 3 —— 彭杰 / 夜猫

项目	内容
学号	162304124
姓名 / 昵称	彭杰 / 夜猫
CSDN 地址	https://blog.csdn.net/catalycat
性格	慢热但靠谱，喜欢把需求边界先问清楚再动手
擅长的技术	TypeScript、Rust、Python，前端、客户端开发
兴趣爱好	观鸟、观星
希望的软工角色	架构工程师
一句 slogan	单子是自函子范畴上的幺半群
想在这个项目里收获什么	利用 AI 驱动游戏开发的能力

在团队中承担：架构 / 核心逻辑。负责工程骨架、状态系统（好感度与 flag）、分支路由、存档一致性方案，以及 AI 协作规范的制定与维护。

成员 4 —— 连伟成

项目	内容
学号	102400219
姓名 / 昵称	连伟成
CSDN 地址	https://blog.csdn.net/2503_93204069
性格	稳重
擅长的技术	C++、Java、基础 UI 设计
兴趣爱好	Galgame
希望的软工角色	前端 / 后端
一句 slogan	知识就是力量；原神就是牛逼
想在这个项目里收获什么	学会扎实的软件工程技术

在团队中承担：UI 与前端表现。负责界面视觉与交互实现、对话框与菜单样式、CG 画廊与结局图鉴的呈现、小游戏的界面开发。

成员 5 —— 叶全祺 / kja

项目	内容
学号	102400230
姓名 / 昵称	叶全祺 / kja
CSDN 地址	https://blog.csdn.net/kjwww_
性格	稳重
擅长的技术	Python、设计
兴趣爱好	音乐、运动
希望的软工角色	测试 / 文案 / 音频
一句 slogan	都是旮旯给木 player，我原本没想降维打击
想在这个项目里收获什么	想通过实际参与把"设计"和"代码"真正接上，掌握一套可复用的视觉小说素材与音频处理流程，并熟悉测试与验收的完整环节。

在团队中承担：文案 / 音频 / 测试。负责剧本撰写与润色、笑点节奏把控；BGM 与音效筛选、响度统一、配音录制与剪辑；并参与测试与文案走查。

三、NABCD 分析

3.1 N（Need，需求）

目标用户

核心用户：16—24 岁的在校学生，喜欢校园题材、恋爱模拟与视觉小说，日常消费 1—3 小时的短篇剧情内容。
次核心用户：喜欢"整活向"内容、乐于截图与转发有趣台词的泛娱乐用户，以及对本校题材有天然兴趣的同校学生。
延伸用户：中文原创视觉小说的关注者——他们长期抱怨"好作品太少"，对新作有较高的尝试意愿。

用户痛点

中文原创校园题材视觉小说供给不足。 市面上的视觉小说以日系商业作品与英译作品为主，文化语境（校服、社团、修学旅行、日式家庭关系）与中国学生的真实校园经验有明显距离；国内原创作品又大多集中在少数头部商业团队，数量少、题材窄。
"设定有意思但玩起来没内容"。 许多小体量原创作品靠一个猎奇设定吸引点击，但角色单薄、动机不成立、分支浅，玩家十分钟就退出——设定能拉来流量，但撑不住留存。
选择的"代价感"严重不足。 大量作品的好感度系统形同虚设，选项后果弱、反馈慢，玩家很快意识到"选什么其实都一样"，互动性沦为走过场。
喜剧作品的笑点高度依赖网络热梗，因此生命周期极短。 靠流行语堆砌的作品，三个月后重玩就完全不好笑了。我们自己也会大量用梗，但把它当调味而非主菜——笑点的主体必须落在具体的大学生活细节上。
"自己的学校"从来没被认真写过。 校园题材作品很多，但几乎没有作品会把一个具体学校的季节、地标与生活节奏写进去。这种"这就是我们学校"的亲切感，是商业作品因追求普适性而主动放弃的东西。

需求依据

市场观察：Steam 视觉小说分类中，"中文"标签作品的评价数量与"日文""英文"标签存在数量级差距，说明中文原创内容仍有明显供给缺口；而校园喜剧这一细分题材在中文作品中尤为稀少。
同类作品分析：我们拆解了 5 部同类作品，发现其共性短板集中在两点——分支浅（选择对结局影响有限）与角色单薄（动机不成立）。这两点正是我们设计双轨数值与限时选择机制的直接动因。
内容分发观察：短视频平台上"大学生日常整活"类内容的播放与互动量长期居高，说明**"具体的校园生活细节"本身具备传播力**，只是还没有被系统性地做成一款可游玩的作品。
团队自身经验：我们五人本身就是目标用户，且多次在"玩到一半发现没有好作品"的体验中产生"不如自己做一个"的动机——这是本选题最直接的来源。
需求判定：我们选择了"无预算、一学期、五人"这一约束作为前提来倒推需求——凡是这个约束下做不出来的功能，都不算真需求。例如"全语音""3D 场景"在商业作品中是标配，但对我们而言属于伪需求，已在范围控制中明确排除。

一句话需求总结

我们需要一款把真实的校园与真实的秋天写进去、笑点来自具体生活而非网络热梗、选择真正会改变结局的中文原创校园喜剧视觉小说。

3.2 A（Approach，做法）

技术方案

引擎选择 Ren'Py 8.5.3。 视觉小说开发中"存档/读档、对话历史、自动跳过、文字回退（Rollback）、CG 画廊、结局收集、多语言"等功能 Ren'Py 全部内置，无需自研。我们因此可以把一学期的绝大部分时间投入剧本质量与演出效果，而不是重复实现通用功能。
为什么不用 Unity 或 Godot。 Unity + Naninovel 表现力上限更高，但需付费插件，且 Prefab/Scene/.meta 结构复杂、编译慢，AI 辅助生成代码时出错率高，对一个学期的项目属于过度设计；Godot + Dialogic 免费开源，但 GDScript 的 AI 生成质量与资料厚度均弱于 Python 生态，且 VN 周边功能需要自行补齐。我们的判断是：本项目没有任何一项需求必须用 Unity 才能实现，而用 Ren'Py 省下的时间足以多写两条剧情线。
脚本与状态管理。 使用 .rpy（Ren'Py Script）编写剧本，内嵌 Python 实现逻辑；全部游戏状态用 default 声明以保证存档一致性；好感度变更统一通过 add_aff() 函数入口，便于调试与打日志。
分支架构。 分支判定集中在单一文件 logic/route.rpy，剧本文件内不出现复杂条件逻辑，从结构上避免"改一处坏三处"。

美术与音频的生产方式（本项目的关键创新点）

背景：实地拍摄校园实景（教学楼、图书馆、食堂、操场、校道等）→ 用 img2img 做动画风格化（去噪强度控制在 0.35—0.55）→ 全组统一模型与提示词前缀 → 最后过同一套调色 LUT 统一色温与对比度。这一步是让"实拍 + AI"的素材看起来像一个完整游戏而不是素材拼盘的关键。
人物：采用真人出镜 + 风格化处理的方式，保留"身边同学"的真实感与辨识度，所有出镜成员均签署肖像使用授权，游戏内附虚构声明（详见第八章）。
立绘成本控制：不做整张重绘，采用眼睛/嘴部图层叠加的表情差分方案，预计节省约 70% 美术工作量。
配音分级策略：放弃"全语音"这一工期黑洞，采用 "语气词包（每角色 10—20 个）+ 关键台词配音" 的两级方案。整活向作品的节奏感八成来自音效与语气词，而非完整语音，这一策略在效果与成本之间取得了最优解。
音频统一响度：全部 BGM 与音效经 ffmpeg 批处理统一到 -16 LUFS，避免学生作品常见的"音量忽大忽小"廉价感。

核心玩法设计

双轨数值系统：好感度（aff_a/aff_b/aff_c）+ 真相进度（suspicion）。玩家不仅要"刷好感"，还要"看清局面"，两条轨道共同决定结局，让选择具备真实的策略性。
限时选择（QTE）机制：关键情节引入 3 秒限时选择，超时自动落到最差选项。这一机制直接服务于作品主题——**"犹豫"本身就是一种选择，且真的会付出代价。**
聊天模拟器小游戏：还原手机聊天界面，玩家从若干回复中选择。它呼应剧情中的线上线索线，是本作演出形式上的亮点。
隐藏 IF 线：黄毛线的解锁条件不设任何 UI 提示，玩家需在二周目通过结局图鉴多出的一格自行发现。把惊喜留给玩家，是本作在传播设计上的一个刻意选择。

范围控制（Scope）

这一节是团队讨论后主动砍掉的内容，也是我们认为最能体现项目可行性的部分。

本期做	本期明确不做
共通线 3 章 + 2 条可攻略线完整	Live2D 全动态立绘
黄毛隐藏线 + 真结局（加分项）	全语音配音
5 个结局 + 结局图鉴	联网功能、云存档、排行榜
2 个小游戏（限时选择 + 聊天模拟器）	移动端适配与发布
Windows 桌面版为主 + Web 试玩版	3D 场景、粒子特效系统
语气词包 + 关键台词配音	多语言（中英日）本地化

里程碑计划

周次	目标	关键产出
W1	环境统一与技术验证	全组 SDK 跑通、骨架工程、AI 协作约定文件
W2	设计定稿	分支文档、人设与世界观、5 结局梗概、素材规范、校园取景清单
W3—W4	共通线 3 章 + 美术管线	可玩到第 3 章，5 张背景风格统一
W5—W6	A 线 + 限时选择小游戏	A 线完整可通关
W7—W8	B 线 + 聊天模拟器 + 结局图鉴	图鉴功能可用
W9	黄毛隐藏线 + 真结局	隐藏线可解锁
W10	配音与音效打磨	语气词包、响度统一、音效补齐
W11	测试与修 bug	测试用例全通过、存档兼容验证
W12	打包与发布	Windows 安装包、Web 试玩链接、发布贴

风险与对策（摘要，完整版见技术文档）

风险	对策
美术产能不足（最大风险）	表情差分方案；背景复用 + 换色调；准备"简笔画/表情包"降级风格——对整活向作品而言，降级风格甚至可能是加分项
剧本写不完	W2 前锁死结局数量；资源不足时砍分支不砍质量，优先保证一条线完整
AI 生成代码不可靠	建立项目约定文件 + 任务卡验收标准 + `renpy lint` 质量闸门 + 人工评审门禁
热梗过时导致作品短命	热梗只做调味不做主菜；笑点主体来自具体的大学生活细节；优先选已活两年以上的梗
范围膨胀	每次例会追问："本周新增的需求，要砍掉哪个旧的？"

3.3 B（Benefit，好处）

对玩家

低门槛的完整叙事体验：1—2 小时即可通关一条线，无需配置运行环境，桌面版与网页版双端可玩。
熟悉的场景带来真实代入感：图书馆抢座、食堂排队、操场夜跑、社团招新、期中考试周——这些具体经验让玩家产生"这就是我们学校"的亲切感，这是日系校园题材无法提供的。
季节感带来情绪共鸣：秋天天然带着"结束"与"开始"的双重意味（学期过半、毕业临近、关系升温或变淡），比笼统的"青春校园"更容易唤起真实情绪。
选择真的有代价：限时机制与双轨数值让玩家必须认真思考，而不是"随便点点看结果"。每种选择都有完整的叙事回报，而不是单向的道德说教。
可反复游玩：5 个结局 + 隐藏线 + 结局图鉴，提供二周目与三周目的动机。

对团队

走完完整的软件工程闭环：需求调研 → 设计与架构 → 实现 → 测试 → 打包发布 → 收集反馈迭代，这是课堂讲授难以替代的真实经验。
五个人正好覆盖完整岗位链：PM 与 Ren'Py 工程、工程化与工具链、架构与核心逻辑、UI 与前端表现、文案与音频测试，每个人的既有技能都能落到真实产出上，而不是"有人闲着"。
掌握 AI 时代的协作方式：本项目有意采用 AI Coding Agent 辅助开发，团队将真实经历"从踩坑到建立约定"的过程——这套经验在本课程之外同样可复用。
学会做取舍：主动砍掉 Live2D、全语音、联网等功能的决定，比把它们写进需求文档更能说明我们理解了"工程"的含义。

对校园与社区

为学校留下一份可对外的原创内容：把校园的秋天与地标写进一部可游玩的作品，本身就是一种校园文化记录。
沉淀一套可复用的资产：中文视觉小说的项目骨架、素材规范、分支数值设计文档、AI 协作约定模板，可供后续选课同学直接参考或二次创作。
验证一条低成本美术路线：用实拍 + AI 风格化大幅降低背景美术成本。这条路如果走通，对预算有限的校园创作团队具有实际的参考价值。

差异化价值一句话

别人写"青春校园"，我们写"我们的秋天"；别人靠流行梗制造笑点，我们靠具体的生活制造共鸣。

3.4 C（Competitors，竞争）

竞品	类型	它的优势	它的不足	我们的差异点
"狂想曲"系列等日系日常向视觉小说	直接竞品（也是致敬对象）	文笔成熟、节奏舒服、氛围营造出色，是我们学习的目标	文化语境距离感强（校服、社团、修学旅行、日式家庭关系）；无中文校园经验	中国大学校园的真实语境与真实季节感；免费；1—2 小时无负担通关
国产头部商业视觉小说	直接竞品	制作精良、本地化优秀、有成熟发行渠道	数量少、题材集中；售价与制作周期均非学生团队可比	喜剧定位 + 低成本高创意；我们不在"美术精度"上与其竞争
其他校园题材学生作品	间接竞品	同题材、情绪共鸣接近、制作成本低	普遍存在"分支浅、结局少、UI 粗糙"的问题；喜剧作品依赖网络热梗	双轨数值 + 限时选择机制；统一的素材与 UI 规范；笑点来自具体生活情境
纯文字互动小说 / 聊天式恋爱游戏	替代品	零美术成本、更新快、文字沉浸感强	缺乏视觉沉浸与演出感，角色形象需玩家自行想象	具备实拍风格化背景与真人立绘；沉浸感明显更强
AI 生成的动画风格素材内容	替代品	生产快、成本低	碎片化，无法构成完整叙事体验	我们交付的是完整作品，不是素材

竞争结论

我们的核心劣势很明确：在美术精度与配音质量上，我们不可能赢过商业作品。 因此策略不是全面对抗，而是选择一个商业作品因成本结构而不愿进入、学生团队却能做得好的细分定位：

具体到一所学校的真实语境。 商业作品要覆盖全国市场，反而不会把细节做得"太像某一所学校"；而我们可以，这正是我们最独特的资产。
秋日主题 + 喜剧 + 整活。 季节感给了情绪落点，喜剧给了传播力，两者结合形成了清晰的辨识度。
实拍 + AI 风格化的美术路线。 大幅降低背景成本，同时获得"身边真实的校园"这一独特质感。
演出形式创新。 聊天模拟器与限时选择机制直接服务于"看清一个人"与"犹豫"这两个主题，形成内容与形式的统一。

护城河与可持续性

原创剧本、角色设定与实拍素材版权均归团队所有，不存在素材授权风险。
剧本采用与引擎无关的纯文本格式管理，便于未来迁移到其他平台或改编。
已建立的素材规范、分支数值文档与 AI 协作约定，使后续扩展新角色线、新小游戏（例如"春日"续作）的边际成本显著低于从零开始。

3.5 D（Delivery，推广）

交付形态

主交付：Windows 桌面版可执行包（免安装绿色版 + 安装包），在 Ren'Py Launcher 中一键打包。
辅助交付：Web 试玩版（WebAssembly 导出，浏览器直接运行），用于让评审与同学零安装体验。
配套文档：README（玩法与操作说明）、素材授权清单、AI 使用说明。

发布渠道

渠道	内容	目的
CSDN 团队博客	开发日志、技术实践文、发布贴	课程要求 + 技术曝光
校内社群 / 社团	发布贴 + 试玩邀请	获取第一轮真实反馈（本校用户是最精准的目标用户）
B 站 / 小红书	60 秒剧情预告、角色立绘海报、名场面切片	破圈传播、吸引玩家
GitHub	仓库（含分支设计文档、AI 协作约定）	展示工程过程，供他人参考

推广方式

内容先行：开发中期即开始发布"整活向"的角色立绘与台词切片，用内容本身吸引关注，而不是等到发布才宣传。
季节卡点：把发布节点对准秋天（或做一次"秋日限定"宣传），让"秋日狂想曲"的标题与实际季节形成呼应。
技术文带量：输出《如何用实拍 + AI 风格化低成本产出视觉小说背景》与《用 AI Agent 协作开发 Ren'Py 项目：我们的约定与踩坑》两篇技术文，用搜索流量反哺作品关注度。
悬念式预热：隐藏 IF 线不做任何公开提示，只在发布贴中留一句"结局列表写着 5 个，但有人说他看到了第 6 格"——制造玩家之间的自发讨论。
课堂演示：在选题报告与期末答辩中当场演示可玩 Demo，把"能玩"变成最有说服力的推广。

获取与反馈闭环

试玩版内嵌 3 题问卷（腾讯问卷）：① 笑点是否命中？② 有没有卡住或困惑的地方？③ 最想继续看哪条线？
首轮目标：收集 30 份有效反馈后集中迭代一次，优先修复卡死与文本溢出，其次调整笑点密度。
建立公开的 Issue 列表，把玩家反馈与修复记录都在 GitHub 留痕，作为软件工程过程的可追溯证据。

数据目标

指标	目标值
试玩次数	上线两周内 ≥ 100 次
有效反馈问卷	≥ 20 份
完整通关（到达任一结局）比例	≥ 30%
隐藏线被玩家自行发现	≥ 3 人
GitHub Star	≥ 20

四、选题描述（一句话）

一句话选题描述（中文）

本作品《福大秋日狂想曲》是一款以福州大学校园的秋天为舞台的中文原创喜剧视觉小说（Galgame）：主角在这个秋天同时遇上了两个让他心动的人，而那位一直陪他聊天的神秘网友"秋刀鱼"似乎也在这所学校里；玩家通过关键选择与双轨数值系统（好感度 + 真相进度），走出 5 种不同结局——没被主角攻略下来的角色，最后都会被反派"黄毛"攻略走，而玩家也可能反过来攻略黄毛，体验"每一次犹豫都是一种选择"的叙事主题。

English (optional)

Fuzhou University Autumn Rhapsody is an original Chinese comedy visual novel set on the Fuzhou University campus in autumn. Through timed choices and a two-track stat system (affection + perception), players reach one of five endings — where whichever love interest the protagonist fails to win over is ultimately claimed by the antagonist, "Blondie." Players may also turn the tables and win over Blondie himself.

选题 PDF 文档链接

选题报告-福大秋日狂想曲.pdf 793.53K

五、团队愿景

我们都是视觉小说的玩家，也都抱怨过"这个设定明明很好，怎么写得这么无聊"。与其抱怨，不如自己做一次，看看五个学生、一个学期，能不能做出真正好玩、真的能通关的作品。我们想借着校园的秋天，讲一个属于我们自己的故事。

本学期要交付完整可通关的作品，而不是演示片段：共通线与 2 条可攻略线完成，5 个结局皆可达并配结局图鉴，两个小游戏与剧情深度融合，无卡死、存档读档一致。

它能被同学在课间随手玩一段，能零安装在线试玩，也能作为中文视觉小说的参考样本公开。

我们更希望它证明：把身边的生活讲成一个故事，本身就值得做。

六、团队绩效考核方案

6.1 制定过程

在选题确定后的第一次团队会议上，我们用约 1.5 小时专门讨论了绩效考核方案，五人全员到场。会议分三步：先由组长介绍《构建之法》中关于团队绩效管理与成员投入程度的相关内容（参考：https://www.cnblogs.com/xinz/archive/2011/05/01/2033927.html 与 https://www.cnblogs.com/xinz/archive/2011/03/14/1983620.html%EF%BC%89%EF%BC%8C%E5%86%8D%E5%90%84%E8%87%AA%E6%8F%90%E5%87%BA%E8%87%AA%E5%B7%B1%E8%AE%A4%E4%B8%BA%E5%90%88%E7%90%86%E7%9A%84%E8%80%83%E6%A0%B8%E6%96%B9%E5%BC%8F%EF%BC%8C%E6%9C%80%E5%90%8E%E9%80%90%E6%9D%A1%E8%BE%A9%E8%AE%BA%E5%B9%B6%E5%AE%9A%E7%A8%BF%E3%80%82

讨论中出现的主要分歧

"按代码行数计分"被否决。 有同学最初提议用代码量衡量贡献，讨论后大家认为这会鼓励堆砌无意义代码，且完全无法反映美术、剧本、测试等岗位的贡献——写一章剧本和写几十行代码，前者的难度往往更高。
"按投入时长计分"被否决。 时长难以核实，且容易变成"比谁在群里待得久"，与产出无关。
"五人小团队是否需要这么多维度"被讨论过。 有同学担心流程太重，最终共识是：维度保留，但记录尽量轻量——数据来源全部落在既有的看板与周报上，不额外增加填表负担。
最终共识：采用 "可验收产出物为主 + 协作互评为辅" 的双维度结构。核心理由是：产出物可以被看见和检验，协作态度可以被同伴感知，而这两者恰好覆盖了"做事"与"做人"两个面。
另一个共识：考核方案必须提前公开，且每周同步进度数据，避免"期末算总账"式的突然袭击——透明本身就是最好的激励。

6.2 考核原则

过程可见——每周例会与周报留痕，任何人的贡献都有记录可查。
结果可验收——每个任务都有明确的完成定义（能跑、能过 lint、能通过人工测试），"我大概做完了"不算完成。
兼顾硬产出与软协作——代码、美术、剧本是硬产出，帮助队友、主动补位是软贡献，两者都要计入。
岗位之间可比——美术、文案、测试与代码岗位通过"任务点数"换算，避免出现"只有写代码才算贡献"的偏向。
不让任何人独自扛全场——若某成员连续承担超量任务，PM 需主动介入重新分配，这不是该成员的问题，而是排期的问题。

6.3 考核维度与权重

维度	权重	具体指标	数据来源	评分人
任务完成度	40%	里程碑任务的完成比例（按任务点数计算）；是否在约定时间点交付；延期是否提前 24 小时报备	GitHub Projects 看板、周报	PM 统计 + 组内确认
产出质量	25%	代码类：通过 `renpy lint`、通过人工评审、无回归 bug；文案类：剧本一次通过率、笑点试读反馈；美术类：素材命名与规格合规、风格一致性通过走查	PR 评审记录、lint 输出、素材走查表	对应岗位负责人
投入程度	20%	例会出勤率、周报按时提交率、任务响应时长（认领任务后 48 小时内是否有可见进展）	例会签到表、周报归档	PM 统计
协作与补位	15%	帮助他人解决阻塞问题的次数；主动承担临时或紧急任务；评审他人产出的人次与质量	全员互评问卷（每人给其余四人打 1—5 分）+ 组内事件记录	全员互评，去掉最高最低分后取平均

补充说明

任务难度通过任务点数体现：每张任务卡在认领时由全员共同估算点数（1/2/3/5/8），完成度按点数而非任务条数计算，避免"挑简单任务刷数量"。
跨岗位换算基准（团队约定，用于保证不同岗位之间可比）：

产出类型	点数	说明
一张符合规范的背景图（含风格化与调色）	3	与一个中等代码任务等价
一章剧本（约 1500 字，含分支与演出说明）	5	文本量大的章节可申请上调
一个完整的 UI 界面（含样式与交互）	3
一条测试用例的编写 + 执行 + 记录	1
一个独立小游戏模块（含 UI 与逻辑）	8

我们特意把这张换算表写进考核方案，目的是让"画图"和"写代码"在考核里真正等价。这是我们在讨论中花了最久才达成一致的部分。

6.4 计算公式

单维度得分 = 该维度实际得分 / 该维度满分 × 100

个人综合得分 = 任务完成度得分 × 40%
             + 产出质量得分   × 25%
             + 投入程度得分   × 20%
             + 协作与补位得分 × 15%

协作与补位得分 = 互评平均分 / 5 × 100
                其中互评平均分 = 去掉一个最高分与一个最低分后取算术平均
                （本团队 5 人，去极值后仍有 3 个有效样本）

个人贡献度 = 个人综合得分 / 全队综合得分之和 × 100%
最终个人成绩 = 团队博客及项目总评分 × 个人贡献度

关于"去极值"的说明：这是为了抑制两种极端情况——小圈子互相打高分，或对某位成员情绪化打低分。5 人团队去极值后仍有 3 个有效样本，统计上足够，因此无需额外规则。

6.5 特殊情形处理

情形	处理办法
请假 / 病假	提前在群内报备即不计入缺勤，但需在 48 小时内补齐对应任务；突发情况事后 24 小时内报备同样认可
临时冲突（考试、比赛、家庭事务）	提前一周说明，由 PM 重新分配其任务点数，不视为未完成
长期不参与	连续 2 周无任何可见产出且未报备，先由 PM 一对一沟通了解原因；若确为客观困难则调整任务量；若沟通无效，则如实记录，贡献度按实际产出折算，并在组内说明
任务认领后中途放弃	若在约定时间前 24 小时说明，不计过失，仅重新分配；若到截止时间才说明，则该项任务点数记 0
某岗位工作量天然偏大（如美术与文案）	由 PM 在里程碑复盘中评估，允许通过"降级方案"（如表情差分替代重绘、章节拆分）主动缩减，而非硬性要求该成员超量投入
争议仲裁	由组长 + 一名随机抽签产生的成员 + 指导老师或助教共同裁定；裁定过程与结论记录在案
加分项	主动承担无人认领的紧急任务、帮助他人解除阻塞超过 2 小时、产出被复用到其他模块，可在协作维度内加分，单次不超过该维度满分的 10%

七、团队分工与协作方式

7.1 角色分工

角色	负责人	主要职责	关键产出物
PM（组长）/ Ren'Py 工程 / 美术 / 测试	林宇杰	排期、任务拆解、里程碑跟踪、对外沟通、风险预警；剧本引擎落地、UI 实现、素材风格化与调色、测试主导	里程碑计划、周报、任务看板、UI 界面、素材规范、测试用例表与 Bug 清单
工程化 / 工具链	陈材臻	素材检查脚本、构建与打包流程、发布准备、版本管理、进度数据统计	素材检查脚本、打包与发布包、构建文档
架构 / 核心逻辑	彭杰	工程骨架、状态系统、分支路由、存档一致性、AI 协作规范	可玩版本、状态与路由模块、约定文档
UI / 前端表现	连伟成	界面视觉与交互、对话框与菜单样式、画廊与图鉴呈现、小游戏界面	界面实现、小游戏 UI
文案 / 音频 / 测试	叶全祺	剧本撰写与润色、笑点节奏、BGM 与音效筛选、响度统一、配音录制剪辑	剧本定稿、音频资源与授权清单、文案走查记录

跨岗位协作说明

五人各有主责，但不设硬边界。 林宇杰与叶全祺共同承担测试；彭杰与连伟成在 UI 与逻辑交界处结对；林宇杰作为 PM 在美术与文案产能紧张时负责协调与补位。
结对评审制度：代码类 PR 由彭杰或陈材臻评审；文案与美术产出由叶全祺或林宇杰评审，保证每项产出至少有一人复核。

7.2 协作方式

协作工具：
- GitHub：代码托管、Issue 跟踪、Pull Request 评审（合并必须至少 1 人评审）
- GitHub Projects：任务看板，任务卡的唯一来源（同时也是考核数据来源）
- 腾讯文档：里程碑排期、剧本协同定稿、素材登记
- QQ / 微信群：日常沟通与报备
例会制度：每周固定一晚线上会议 30 分钟，议题提前一天在群内征集，会议产出备忘录并归档。例会的第一项固定议程是"上周承诺的任务，完成情况如何"。
文件结构约定：一章一文件、一人一章，从源头消除版本冲突；单个剧本文件不超过约 400 行，超过即拆分。
沟通公约：
1. 24 小时内回复与自己相关的消息；
2. 卡壳超过 2 小时必须主动求助，不允许默默拖延；
3. 只对事不对人，评审意见必须给出具体修改建议而非单纯否定；
4. 任何需求变更都在群里公示，不私下拉人改方案。
AI 协作规范（本项目的特色实践）：
1. 仓库根目录维护项目约定文件，明确引擎版本、代码规范、禁止事项与交付要求，所有 AI Agent 开工前必读；
2. 任务以"任务卡"形式下发，卡内必须写明目标、输入、产出、验收标准；
3. AI 生成的所有代码必须通过 renpy lint 检查并经人工评审才能合并，未跑检查的产出一律不合并；
4. 状态管理与分支路由等核心模块由人类编写，AI 负责实现重复度高的内容；
5. 记录并归档 AI 协作中的失败案例（如生成不存在的接口、写错存档逻辑），作为团队经验沉淀。

八、风险与合规说明

本节在选题报告中占半页，是我们作为工程团队主动识别并处理风险的体现。

8.1 真人素材与肖像权

本作角色采用真人出镜 + 风格化处理的方案，因此涉及肖像使用问题。我们的处理如下：

出镜成员均签署肖像使用授权，明确用途（课程作业、课程评审、公开演示与发布）、使用范围与期限，并保留书面或文字留档；
不对任何真实同学进行 AI 换脸处理——写实换脸存在明确的法律与伦理风险，且一旦传播不可控，因此技术上主动回避；
不使用 AI 语音克隆任何人的声音。需要配音的部分由本人现场录制，这是当前风险最高、也最容易被忽视的一项；
游戏内附免责声明："本作人物与情节均为虚构，如有雷同纯属巧合；出镜人员已授权本作使用其形象。"

8.2 AI 生成内容的说明

我们在游戏的"关于"页面与发布贴中主动列明：

哪些素材为 AI 生成或 AI 辅助（背景的风格化处理、部分立绘）；
使用了何种工具与模型；
剧本由团队原创大纲、AI 辅助润色、人类最终定稿。

我们选择主动标注而不是回避，因为这既是合规要求，也是我们作为"AI 时代的软件工程实践者"应当具备的诚实态度。

8.3 素材版权

音效与 BGM 优先采用 CC0 / 公共领域 素材，不使用有版权的流行歌曲、影视配乐或商业游戏原声；
建立素材授权登记表，记录每项素材的名称、来源链接、授权类型与获取日期，作为合规证据留存；
字体使用可商用的免费中文字体（如思源黑体、霞鹜文楷、阿里巴巴普惠体），不使用微软雅黑、方正系列等存在商用限制的字体；
"狂想曲"是致敬对象，不是复制对象。 我们只借鉴其"以日常场景为题、轻松笔调叙事"的创作思路，不使用其任何美术素材、音乐、剧本文本或角色设定，作品名与内容均为原创。