[P] 结对项目：花见小路
[P] 结对项目：花见小路
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 北航2026春软件工程 |
| 这个作业的要求在哪里 | 结对项目：花见小路 |
| 我在这个课程的目标是 | 学习软工方法论，和团队一起加以实践并合力完成一个软件，提升自己的团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过实践结对编程，加深对软件工程方法论的理解 |
→ 📖 Q0.0(P) 【你可以在结对结束后补充】如果你的代码仓库包含 AIGC 的部分，列举使用的工具、模型和使用范围。若未使用则填写：本组提交的全部代码不包含AI补全或生成的部分。
github copilot用于代码生成，模型为GPT-5.3-Codex。
ChatGPT和DeepSeek用于讨论思路和查资料。
Chapter.0 wasm从安装到入门
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2026/4/3 14：43
调查
→ 📖 Q0.2(I) 【你可以在结对结束后另行补充。】作为本项目的调查：
请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）
I. 没有听说过
请如实标注在开始项目之前对桌游花见小路的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）
I. 不了解玩法和规则
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2026/4/3 15：18
Chapter.1 七色之缨
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2026/4/3 15：19
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（例如查阅了哪些资料、如何设计判定逻辑、如何设计测试样例、遇到了什么问题、如何解决）。
设计
→ 📖 Q1.3(P) 请说明你们为这个判定模块设计了哪些中间量或辅助函数；如果没有额外设计，也请说明为什么认为直接实现已经足够清晰。
TIER_XXX：倾心标记优先级档位
pickByTier()：判断玩家和对手是否拥有同一优先级的倾心标记
主函数hanamikojiJudge()中的中间量：
myScore&oppScore：玩家与对手当前分数myCount&oppCount：玩家与对手获得的倾心标记数量myMask&oppMask：玩家与对手获得的倾心标记tierRes：pickByTier()的返回值，代表了查询结果
→ 📖 Q1.4(I) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。
将规则的胜负条件列表，根据表格实现，再设计边界条件的测试用例来保证实现的正确性。
测试
→ 📖 Q1.5(P) 请说明你们设计了哪些测试用例，这些测试分别覆盖了哪一类规则或边界情况。
覆盖规则：一方分值达到 11 分而获胜
测试用例：board = [0, 0, 0, 1, 0, 1, 1]
round = 1
预期结果 = 1
覆盖规则：一方获得至少 4 枚倾心标记而获胜
测试用例：board = [1, 1, 1, 1, 0, 0, 0]
round = 2
预期结果 = 1
覆盖规则：前两小轮结束时尚未满足胜利条件，应返回 0
测试用例：board = [1, -1, 0, 0, 0, 0, 0]
round = 2
预期结果 = 0
覆盖规则：第三小轮结束时，总分不同，由总分高者获胜
测试用例：board = [1, 0, -1, 0, 0, -1, 1]
round = 3
预期结果 = 1
覆盖规则：第三小轮结束时，总分相同，由最高档位倾心标记判定胜负
测试用例：board = [1, 0, 0, -1, 0, -1, 1]
round = 3
预期结果 = 1
覆盖规则：第三小轮结束时平局，应返回 2
测试用例：board = [0, 0, 0, 0, 0, 0, 0]
round = 3
预期结果 = 2
→ 📖 Q1.6(I) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。
“先写测试再实现”是测试驱动开发的核心思想，需要事先对程序是如何运作有着清晰的了解，对程序员的要求比较高。
“先实现再补测试”是大部分人在实际开发时的真实情况，虽然直接进行开发看起来比较省事，但是可能缺乏对要实现的模块的理解或是实现中疏漏某些边界条件，导致最后花费大量时间debug。
两种方式有各自的优缺点，应该视情况决定采取哪一种方法。
总结
→ 📖 Q1.7(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2026/4/3 17:51
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 3 | 2 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 15 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 60 |
| - Coding Standard | - 代码规范 | 3 | 5 |
| - Design | - 具体设计（确定怎么实现） | 10 | 10 |
| - Coding | - 具体编码 | 5 | 5 |
| - Code Review | - 代码复审 | 10 | 15 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 2 | 20 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 5 | 5 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 7 |
| - Size Measurement | - 计算工作量 | 2 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 60 | 152 |
→ 📖 Q1.8(I) 请写下本部分的心得体会。
在本模块的开发中，我花费了很多时间来理解规则，规则虽然不复杂，但是细节很多，如果读规则不仔细就可能会不小心写错判断条件或是分支顺序。
Chapter.2 不祥之影
准备
→ 📖 Q2.1(P) 请记录下目前的时间。
2026/4/7 19:43
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
- 了解需求
- 构想程序所需辅助函数/执行流程
- 求助AI
- 游玩花间小路加深规则理解
- 复审AI给出代码
- 设计测试用例
- 将测试范围交给AI，由AI实现
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T1 中已实现的代码进行了哪些复用和修改。
T2中并没有调用T1实现的函数，因此没有进行修改
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
可以使用模块化设计的思想，将规则、游戏流程分成不同的模块，当需求变更的时候就可以更好地定位需要修改的部分。
头脑风暴环节
→ 📖 Q2.5(P) 头脑风暴环节：
我们终于快要开始让程序玩游戏了！请尝试分析：T2 中不带 X 的操作记录比起实际对局多出了多少信息？如果加上 X，也就是失去了这部分信息的话，如何处理对小轮结束后状态的估计？
不带X的操作记录相当于多了3张牌的信息（对手的操作1和2），其中操作2不影响状态的计算，只有操作1的牌会对结果产生影响，且只对同一类型卡牌数量差距为0/1的类型有影响。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录 A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2026/4/7 21:49
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 3 | 4 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 15 | 20 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 5 |
| - Coding Standard | - 代码规范 | 3 | 3 |
| - Design | - 具体设计（确定怎么实现） | 45 | 18 |
| - Coding | - 具体编码 | 20 | 7 |
| - Code Review | - 代码复审 | 30 | 20 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 20 | 15 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 10 | 14 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 9 | 10 |
| TOTAL | 合计 | 180 | 126 |
→ 📖 Q2.7(I) 请写下本部分的心得体会。
本模块要求根据输入行动来更新游戏局势，考验的是如何建模游戏局势和表示游戏中的不同状态，选择合适的数据结构来表示游戏状态可以达到事半功倍的效果。
Chapter.3 道途之荆
准备
→ 📖 Q3.1(P) 请记录下目前的时间。
2026/4/8 14:48
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
- 游玩花间小路
- 设计策略
- 讨论策略合理性
- 查网上攻略
- 和AI讨论策略合理性
- 了解AI提出的启发式搜索策略的实现
- 改为采用贪心策略
头脑风暴环节
→ 📖 Q3.3(P) 头脑风暴环节：
假设提供更充裕的时间和资源，这个游戏中你能找到的最优策略有可能是什么形式的？进行调研并总结分析。你还可以在任务结束后试着实现（不计分）。
可以从游戏过程和结果吸取经验的大模型 -- 强化学习智能体，类似于AlphaGo Zero
特点：
- 目标导向：不是为了生成"正确答案"，而是为了在环境中实现特定目标而学习"如何行动"
- 闭环学习：通过感知环境状态 → 执行动作 → 获得奖励反馈 → 调整策略的循环，不断优化自身行为
- 无需监督数据：不需要标注好的输入-输出对，而是通过与环境交互自主探索
三大类型：
- 基于值函数的智能体：维护函数并对其进行更新
- 基于策略的智能体：直接优化策略网络，通过梯度上升优化策略参数
- Actor-Critic架构：结合基于函数和策略的优势，能解决引用分配的问题
实现步骤：
- ** 环境搭建：**使用Python、PyTorch/TensorFlow、OpenAI Gym等工具
- 状态与动作空间设计：根据具体问题定义合理的状态表示和动作集合
- 奖励机制设计：设计好的奖励函数
- 算法选择：根据问题特性选择DQN、PPO、SAC等算法
- 模型训练：在环境中反复交互，调整超参数
- 部署与监控：将训练好的策略部署到实际应用场景
需求建模和算法设计
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么选择行动类型？选牌如何更优？如何编程实现。
我们首先为每张牌定义了动态价值：
牌价值 = 基础分值 × 紧迫度 × 稀缺系数。
基础分值：按规则中艺伎分值（2/3/4/5）计。
紧迫度：对方已占优的艺伎权重更高，中立次之，我方已占优最低。
稀缺系数：若某类牌在可见信息中已接近耗尽，则提高其权重。
对局中我们采用贪心策略，先根据当前手牌与已用行动生成合法候选，再对候选打分，选择分数最高的行动。
具体思路是：
1：倾向放“当前价值最高”的牌，优先争夺关键艺伎。
2：倾向丢“当前价值最低”的两张，减少关键资源损失。
3：按“对手会拿最优牌”建模，评估我方能保留的两张价值之和。
4：按“对手会选更优组”建模，评估两组中较小的一组价值，并尽量把高低价值牌交叉分组，降低被一口吃掉高价值组合的风险。
代码可复用性与需求变更
→ 📖 Q3.5(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
T3 中没有对 T2 的代码进行复用和修改
→ 📖 Q3.6(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
通过采取模块化设计，以及决策和行动模块解耦，通过决策接口来实现决策的可替换性，这样当面对规则变动，可以方便地替换策略而不必重写整个流程。
软件度量
→ 📖 Q3.7(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块决策能力很强？”，尝试提出一些可能的定量分析方式或测试方式。
可以和其他人的模块进行多轮对局，记录结果，计算胜率。
总结
→ 📖 Q3.8(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2026/4/11 14：36
→ 📖 Q3.9(I) 请写下本部分的心得体会。
本模块需要将玩游戏时的种种考虑和思路具体编写成代码，是一个不简单的挑战，和大模型讨论之后才知道不只是把我们玩游戏的行动编写成代码，还有很多基于数学、概率等概念的策略。最后由于优先保证能完成作业，我们只是实现了简单的策略，没有进一步优化。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
- 编程能力不足，太过依赖大模型
- 时间管理经验不足，对任务所需时间预估不当
- 没有及时记录思考过程，导致复盘时有遗漏的地方
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：很配合工作、比较细心可以指出我考虑不足的地方、擅长写文档
缺点：面对比较困难的问题时容易气馁
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点：可以和同伴取长补短、共同进步
缺点：需要双方配合时间
我觉得结对编程的理念是很好的，但是现实中有很多干扰，因此效果往往不那么理想。
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/xianyu9n/BUAASE2026-PairProgramming
附录
附录 A：基于 PSP 2.1 修改的 PSP 表格
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | ||
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | ||
| - Technical Background | - 了解技术背景（包括学习新技术） | ||
| - Coding Standard | - 代码规范 | ||
| - Design | - 具体设计（确定怎么实现） | ||
| - Coding | - 具体编码 | ||
| - Code Review | - 代码复审 | ||
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | ||
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | ||
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | ||
| - Size Measurement | - 计算工作量 | ||
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | ||
| TOTAL | 合计 |
浙公网安备 33010602011771号