[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) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。
- 尽量避免散落的规则
- 尽量避免一长串的
if-else - 可以使用防御性编程来避免意料之外的情况
测试
→ 📖 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) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。
先写测试再实现：将实现限制在测试范围内，需要明确实现方案（至少函数的输入输出格式）
先实现再补测试：容易将测试编写于实现逻辑内从而遗漏bug
总结
→ 📖 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) 请写下本部分的心得体会。
我发现在一个如此简单的规则胜负判定函数中，在实现方式上存在很大的差异。原本自己尝试手搓的会存在一堆if-else和for循环，显得非常简陋。AI生成版本巧妙地使用了2进制常量来判断双方拥有的倾心标记优先级。
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
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 3 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 30 | 25 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 20 | 15 |
| - Coding Standard | - 代码规范 | 3 | 3 |
| - Design | - 具体设计（确定怎么实现） | 60 | 40 |
| - Coding | - 具体编码 | 30 | 40 |
| - Code Review | - 代码复审 | 30 | 16 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 30 | 3 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 15 | 3 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 20 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 20 | 10 |
| TOTAL | 合计 | 268 | 166 |
→ 📖 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号