[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) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。
按照规则的自然层次组织代码，先判定立即胜利条件，再判定最终胜负，严格按照规则文档的顺序编写if-else分支，避免逻辑跳跃。先编写覆盖所有规则分支的测试用例，再实现功能。在多人合作的情况下，两人互相审查代码，特别是判定逻辑部分，以避免犯错。
测试
→ 📖 Q1.5(P) 请说明你们设计了哪些测试用例，这些测试分别覆盖了哪一类规则或边界情况。
- 一方分值达到 11 分获胜
- 一方获得至少 4 枚倾心标记获胜
- 前两小轮尚未满足胜利条件
- 第三小轮总分不同，高分获胜
- 第三小轮总分相同，最高档位判定
- 第三小轮平局
- 综合场景：自己 4 枚但对手已达 11 分；
→ 📖 Q1.6(I) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。
先写测试再实现：这样可以明确需求边界，防止过度设计，同时确保每段代码都有对应测试，即使重构也会更有信心，需要对需求有很高的理解，初期投入可能会较大。
先实现再补测试：适合需求不明确或快速迭代的场景，适合快速开发，但容易产生“测试为了通过而通过”的问题，也可能会因为初期对规则逻辑的理解不全面对后续产生影响。
总结
→ 📖 Q1.7(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月37日15:47。
→ 📖 Q1.8(I) 请写下本部分的心得体会。
胜负判定虽然逻辑不算复杂，但规则细节很多：分值计算、标记数量判断、立即胜利条件、轮次区分、第三轮的总分比较和档位逐级比较。在开始编码之前，我和搭档花了不少时间反复阅读规则，确保对每一条判定逻辑的理解一致。
在实现判定逻辑时，分支的顺序非常关键。如果交换了顺序，比如先检查第三轮总分比较，就会导致第一轮已经达到 11 分的情况被错误地当作“尚未结束”处理。
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) 请写下本部分的心得体会。
花见小路虽然规则简单，但策略深度不低。我们的策略还有很多优化空间，比如引入蒙特卡洛模拟、对手建模等。我们优先保证了程序的正确性和稳定性，性能优化留待后续，并没有实现比较复杂的策略。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
时间规划：T3任务耗时超出预估，后续应预留更多buffer。
文档同步：部分设计决策没有及时记录，导致后续回顾时遗忘。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
我的搭档在讨论策略时总能快速梳理出核心逻辑，能发现代码中的小bug和边界情况，遇到分歧时会主动沟通，不会固执己见。缺点：编码速度不够快。
对结对编程的理解
→ 📖 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号