[P] 结对项目：花见小路
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2026年春季软件工程 |
| 这个作业的要求在哪里 | [P]结对项目：花见小路 |
| 我在这个课程的目标是 | 锻炼团队协作开发能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 深入体会结对编程，提高了两人合作的协作开发能力 |
→ 📖 Q0.0(P) 【你可以在结对结束后补充】如果你的代码仓库包含 AIGC 的部分，列举使用的工具、模型和使用范围。若未使用则填写：本组提交的全部代码不包含AI补全或生成的部分。
提交的代码中T2的测试使用了DeepSeek,完全由AI来生成。
T3的第一版使用了DeepSeek来完成。
Chapter.0 wasm从安装到入门
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
3月27日14:00。
调查
→ 📖 Q0.2(I) 【你可以在结对结束后另行补充。】作为本项目的调查：
请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）
I. 没有听说过；
请如实标注在开始项目之前对桌游花见小路的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）
I. 不了解玩法和规则；
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
3月27日14:20。
Chapter.1 七色之缨
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
3月27日14:23。
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（例如查阅了哪些资料、如何设计判定逻辑、如何设计测试样例、遇到了什么问题、如何解决）。
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 5 | 6 |
| - Estimate | - 估计这个任务需要多少时间 | 5 | 6 |
| DEVELOPMENT | 开发 | 49 | 53 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 7 | 15 |
| - Coding Standard | - 代码规范 | 2 | 3 |
| - Design | - 具体设计（确定怎么实现） | 5 | 4 |
| - Coding | - 具体编码 | 15 | 20 |
| - Code Review | - 代码复审 | 3 | 3 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 4 | 4 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 8 | 4 |
| REPORTING | 报告 | 10 | 10 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 4 | 4 |
| - Size Measurement | - 计算工作量 | 2 | 1 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 4 | 5 |
| TOTAL | 合计 | 64 | 69 |
- 对AS还不是很熟练，通过浏览网上的博客和询问大模型学习了AS的基本语法和编写规则，发现与C语言非常相似。
- 仔细阅读胜负判定规则，包括立即胜利条件和第三小轮后的最终判定规则。
- 着手编写代码，使用if-else分支逐一判断。
- 使用大模型编写测试代码。
设计
→ 📖 Q1.3(P) 请说明你们为这个判定模块设计了哪些中间量或辅助函数；如果没有额外设计，也请说明为什么认为直接实现已经足够清晰。
我们设计了以下中间量：
const scores : i8[] = [2,2,2,3,3,4,5];
let myScore : i8 = 0;
let otherScore : i8 = 0;
let myWoman : i8 = 0;
let othersWoman : i8 = 0;
通过分数计数的比较可以很容易的判断出大部分胜负。在第三轮仍未有人获胜时，通过分别加和D、E和A、B、C对应的board就可以判断双方谁占优势。
→ 📖 Q1.4(I) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。
首先详细分析题目可能出现的所有情况以及优先级，然后按照优先级和分支进行编码。编码完成后把题目情况带回代码，以及编写对应的测试样例。在结对编程中可以通过队友的监督来纠正思路和编写过程犯的错误。
测试
→ 📖 Q1.5(P) 请说明你们设计了哪些测试用例，这些测试分别覆盖了哪一类规则或边界情况。
- 一方分值达到 11 分获胜
- 一方获得至少 4 枚倾心标记获胜
- 前两小轮尚未满足胜利条件
- 第三小轮总分不同，高分获胜
- 第三小轮总分相同，最高档位判定
- 第三小轮平局
- 综合场景：自己 4 枚但对手已达 11 分；
→ 📖 Q1.6(I) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。
先写测试再实现：在编写逻辑前先定义好它在特定输入下应该输出什么。如果测试很难写说明函数或模块接口设计得太复杂。有效避免了代码的过度设计。每一个测试用例都是对规则的精确描述。
先实现再补测试：是最自然的开发模式。先通过逻辑实现把功能跑通，再通过测试来验证。开发者可以全神贯注于博弈算法的实现，不会被测试代码打断思路。这种方式的测试通常是为了提高“代码覆盖率”，确保每一行 if/else 都被走到。测试更多地作为一种“保险”，防止未来的修改导致功能退化。
| 先写测试 | 先实现再补测试 | |
|---|---|---|
| 关注点 | 需求与接口：我需要这个模块做什么？ | 逻辑与细节：我该如何实现这个功能？ |
| 代码质量 | 代码通常更简洁、耦合度低。 | 可能存在为了补测试而重构的情况。 |
| 重构难度 | 较低：测试是重构的保护伞，改完即知对错。 | 较高：重构时可能需要重写大量测试。 |
| 适用场景 | 逻辑极其复杂、规则确定的模块 (如 Token 解析)。 | 需求模糊、需要快速验证想法的实验性功能。 |
总结
→ 📖 Q1.7(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月37日15:47。
→ 📖 Q1.8(I) 请写下本部分的心得体会。
在熟悉语言和熟悉规则上面花的时间较多。这是第一个代码编写部分，这一部分我担任的是领航员的角色，由搭档完成的代码编写，我作为观察者的身份能够更冷静的思考和观察，发现错误的能力要比编写代码时要高，除此之外我还负责说明加下来要编写什么代码。实际体验下来真的很像领航员。
Chapter.2 不祥之影
准备
→ 📖 Q2.1(P) 请记录下目前的时间。
3月27日15:50。
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 10 | 9 |
| - Estimate | - 估计这个任务需要多少时间 | 10 | 9 |
| DEVELOPMENT | 开发 | 123 | 127 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 12 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 5 |
| - Coding Standard | - 代码规范 | 8 | 6 |
| - Design | - 具体设计（确定怎么实现） | 10 | 8 |
| - Coding | - 具体编码 | 40 | 55 |
| - Code Review | - 代码复审 | 10 | 6 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 20 | 25 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 15 | 10 |
| REPORTING | 报告 | 20 | 24 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 13 |
| - Size Measurement | - 计算工作量 | 5 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 8 |
| TOTAL | 合计 | 153 | 160 |
- 阅读规则和 T2 的需求，明确输入和输出。
- 讨论如何处理输入：判定行动是由哪方做出的，对不同行动如何处理。
- 着手编写代码，完成行动1、2、3的处理。
- 仿照行动3的处理编写行动4的处理。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T1 中已实现的代码进行了哪些复用和修改。
我们并没有修改复用 T1 的具体代码，T2的输出是T1的输入，代码并没有多大的关联，T1只是在逻辑理解上和新语言的熟悉上对T2有帮助。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
模块化设计：将解析、状态更新、胜负判定等模块分离，便于单独修改。
接口抽象：定义清晰的函数接口，内部实现变化不影响调用方。
头脑风暴环节
→ 📖 Q2.5(P) 头脑风暴环节：
我们终于快要开始让程序玩游戏了！请尝试分析：T2 中不带 X 的操作记录比起实际对局多出了多少信息？如果加上 X，也就是失去了这部分信息的话，如何处理对小轮结束后状态的估计？
T2中所有牌都是公开的，这意味着：所有密约牌的内容都已知，所有弃牌的内容都已知，对手的所有选择都明确。
如果加入X，需要通过概率估计来处理：根据自己的手牌、已公开的牌枚举所有可能的牌堆分布，对每种可能性模拟结算，取平均结果。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录 A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月27日19:17（中间去吃晚饭花费45分钟）。
→ 📖 Q2.7(I) 请写下本部分的心得体会。
T2部分和T1部分差不多，在理解规则的基础上很快就能完成，对结对编程更加熟悉了，两个人也更了解了些。
Chapter.3 道途之荆
准备
→ 📖 Q3.1(P) 请记录下目前的时间。
3月28日14:22。
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 10 | 9 |
| - Estimate | - 估计这个任务需要多少时间 | 10 | 9 |
| DEVELOPMENT | 开发 | 310 | 283 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 25 | 20 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 20 | 20 |
| - Coding Standard | - 代码规范 | 15 | 8 |
| - Design | - 具体设计（确定怎么实现） | 35 | 25 |
| - Coding | - 具体编码 | 150 | 175 |
| - Code Review | - 代码复审 | 15 | 10 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 30 | 15 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 10 |
| REPORTING | 报告 | 40 | 25 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 20 | 12 |
| - Size Measurement | - 计算工作量 | 5 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 15 | 10 |
| TOTAL | 合计 | 360 | 317 |
- 仔细阅读T3的任务要求，理解输入输出格式
- 尝试寻找花见小路策略分析相关博客，但没有找到
- 设计T3需要的代码模块，如输入处理，选牌策略等
- 利用大模型辅助，尝试动手实现代码
- 在第一版上重新设计选牌策略和行动选择策略，让策略更合理更严密
头脑风暴环节
→ 📖 Q3.3(P) 头脑风暴环节：
假设提供更充裕的时间和资源，这个游戏中你能找到的最优策略有可能是什么形式的？进行调研并总结分析。你还可以在任务结束后试着实现（不计分）。
如果资源不受限，最优策略可能是基于蒙特卡洛树搜索（MCTS） 的算法，模拟所有可能的未来局面。同时融入深度学习，观察对手的历史选择，推断其策略偏好，动态模拟评估每个行动的价值。
需求建模和算法设计
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么选择行动类型？选牌如何更优？如何编程实现。
行动类型：是1到4依次行动，即优先使用消耗牌数少的行动，让后期有更好的操作性。
选牌策略：使用固定权重表A:2, B:2, C:2, D:3, E:3, F:4, G:5）乘以动态局势权重（对手领先系数高，我方领先系数低）来为每张卡赋分
| 行动类型 | 选牌逻辑 |
|---|---|
| 密约 (1) | 取固定权重最高的牌 |
| 取舍 (2) | 取固定权重最低的两张牌 |
| 赠予 (3) | 取即固定权重最低的三张牌 |
| 竞争 (4) | 取 [最低, 最高, 次低, 次高] 的组合：L1 + H1 + L2 + H2。 |
代码可复用性与需求变更
→ 📖 Q3.5(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
T2和T3都有历史记录的输入，所以T3使用了相似的字符串处理方法，并对它设计了结构体来更好地存储和调用。
→ 📖 Q3.6(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
模块分离：例如把解析历史、分析场面、决策逻辑、结果输出分离为4个单独模块
抽象出集合类：StringArray, IntSet实现了简单的数组和集合管理
原子化决策解析：parseToken 将复杂的业务逻辑（谁给谁牌、选择了哪组）降维成了一个简单的 TokenInfo 结构
软件度量
→ 📖 Q3.7(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块决策能力很强？”，尝试提出一些可能的定量分析方式或测试方式。
胜率基准测试：让不同ai模型编写策略程序，使用模拟脚本测试胜率。然后通过更改决策模型的参数和增加新的决策逐步提高胜率。
例如通过对抗随机对手、贪心对手、镜像，分别验证决策能力有效性、权值分配是否合理、观察胜负是否完全取决于先/后手。
总结
→ 📖 Q3.8(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月28日19:30。
→ 📖 Q3.9(I) 请写下本部分的心得体会。
刚看到这部分要求我们两眼一黑完全不知道干什么，先是我们两个人玩了两把游戏，由于是以找到策略为目的进行游玩的，两把游戏就玩了很久，慢慢的对不同局势下卡牌的价值有了基本的想法。也总结了在某些情况下怎么出牌更好，但是始终构建不出一个完整的策略体系，最终只好放弃了很多想法，对ai给的思路进行了几点优化作为最后的版本，但是还有很多考虑空间。虽然规则不难，但是背后的逻辑还是太复杂了。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
时间规划：T3任务耗时超出预估，后续应预留更多buffer。
文档同步：部分设计决策没有及时记录，导致后续回顾时遗忘。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
习惯冷静、完整地思考而不是像我一样有一个想法就提出来。
能发现我注意不到的点，我却不可以。
包容我提出很多不完善或者不好的想法。
很专注，可以一起工作很久。
有趣，结对过程没有感觉无聊。
缺点：使用的鼠标有问题
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
结对编程的优点：
实时代码审查：两人同时关注代码，减少错误。
知识共享：双方技能互补，互相学习。
减少瓶颈：一人卡住时另一人可以提供思路，谁有想法谁写。
提高专注度：有伙伴在旁边，不易分心。
结对编程的缺点：
需要磨合：风格不合的搭档效率反而降低。
精力消耗：持续的交流和思考很累，结对过程休息的时间比单独编程少很多。
我的理解：通过实时的、持续的代码评审和知识传递机制，完成任务的质量大于单人完成。每个人都可以从另一个人身上学到新东西
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/CTS-23373/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号