[P] 结对项目：花见小路

项目 内容
这个作业属于哪个课程 2026年春季软件工程
这个作业的要求在哪里 结对项目：花见小路
我在这个课程的目标是 提高工程能力，熟悉团队开发过程，积累沟通协作经验
这个作业在哪个具体方面帮助我实现目标 深入体会结对编程过程，积累合作经验

→ 📖 Q0.0(P) 【你可以在结对结束后补充】如果你的代码仓库包含 AIGC 的部分，列举使用的工具、模型和使用范围。若未使用则填写：本组提交的全部代码不包含AI补全或生成的部分。

本组代码仓库包含 AIGC 辅助生成的部分，使用工具为 Gemini 3 Pro，主要用于代码局部实现、测试用例构造与错误分析，并在 Chapter 3 辅助思考最优策略。

Chapter.0 wasm从安装到入门

引入

→ 📖 Q0.1(P) 请记录下目前的时间。

19:30

调查

→ 📖 Q0.2(I) 【你可以在结对结束后另行补充。】作为本项目的调查：

请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）

I

I. 没有听说过；

II. 仅限于听说过相关名词；

III. 听说过，且有一定了解；

IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。

请如实标注在开始项目之前对桌游花见小路的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）

I

I. 不了解玩法和规则；

II. 听说过，且有一定了解；

总结

→ 📖 Q0.3(P) 请记录下目前的时间。

19:40

Chapter.1 七色之缨

结对过程

→ 📖 Q1.1(P) 请记录下目前的时间。

19:40

→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

  1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
  2. 完成编程任务期间，依次做了什么（例如查阅了哪些资料、如何设计判定逻辑、如何设计测试样例、遇到了什么问题、如何解决）。

查阅资料：

  1. 学习了 AssemblyScript 的基础语法，特别是 Int8Array 的使用方式以及如何导出函数
  2. 研究了 Node.js 环境下如何加载 .wasm 模块及其配套的 debug.js 进行测试

判定逻辑设计：

  1. 检查 board 和 round 的输入合法性
  2. 使用单次循环遍历 board，同时累加双方总分和标记数
  3. 先进行立即胜利的判定，如果无法判断且 round === 3 则进入平局判断
  4. 进行层级检查，只要最高非空档位无法区分则判定平局

测试样例设计：

  1. 测试了恰好 11 分和超过 11 分的情况
  2. 测试了 4 枚标记但总分不到 11 分的情况
  3. 测试了 Round 1/2 在无胜负时返回 0 的情况
  4. 测试了总分高者胜的情况
  5. 测试了总分相等但档位高者胜的情况
  6. 测试了同一档位冲突导致平局的情况
  7. 测试了非法输入的情况

遇到的问题与解决：

  1. 最初在档位判定时，简单按索引 6 到 0 降序排列。之后测试时发现 A/B/C 属于同档位，所以修改为分组检查，只要同一档位两人都有标记即判定平局。

设计

→ 📖 Q1.3(P) 请说明你们为这个判定模块设计了哪些中间量或辅助函数；如果没有额外设计，也请说明为什么认为直接实现已经足够清晰。

  1. 我们设计了分值映射数组 scores，将角色 A-G 对应的分值 [2, 2, 2, 3, 3, 4, 5] 预设在数组中，这样可以通过索引访问来计算得分
  2. 我们设计了状态统计量 myScore、oppScore、myCount、oppCount，在单次遍历 board 中累加双方的总分和获得标记的数量
  3. 我们设计了优先级数组 tiers，将 7 个角色按优先级划分为四个档位 [[6], [5], [4, 3], [2, 1, 0]]，这种结构将比较最高非空档位的抽象规则转化为了可遍历的数据结构

→ 📖 Q1.4(I) 请说明在这样一个规则判定类模块中，如何避免"漏判""错判"或分支顺序错误等问题。
首先要梳理清楚获胜逻辑的优先级，得到11分>争取到4位艺妓>第三回合结算时分数更高>第三回合同分时所争取到的魅力值最大的艺妓其魅力值更大
并明确极端情况：两人不可能同时得到11分（艺妓总分和为11），两人不可能同时争取到4位艺妓（艺妓共7人），因此只有当第三回合两人同分同最高魅力值艺妓或者两人都未争取到哪怕一名艺妓时为平局

据此按完善的优先级顺序编写代码就能尽可能避免

测试

→ 📖 Q1.5(P) 请说明你们设计了哪些测试用例，这些测试分别覆盖了哪一类规则或边界情况。

  1. 一方分值达到 11 分而获胜
  2. 一方获得至少 4 枚倾心标记而获胜
  3. 前两小轮结束时尚未满足胜利条件，应返回 0
  4. 第三小轮结束时，总分不同，由总分高者获胜
  5. 第三小轮结束时，总分相同，由最高档位倾心标记判定胜负
  6. 第三小轮结束时平局，应返回 2
  7. 边界与防御性测试

→ 📖 Q1.6(I) 请说明你对"先写测试再实现"与"先实现再补测试"两种方式的理解。
拿本章任务来理解的话，先写测试再实现就是先梳理获胜优先级和所有极端可能，想清楚了再写代码
先实现再补测试就是对着题目直接写，写完再反思逻辑是否正确，极端情况是否考虑清楚

总结

→ 📖 Q1.7(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的"实际耗时"栏目。

20:20

Personal Software Process Stages 个人软件开发流程 预估耗时（分钟） 实际耗时（分钟）
PLANNING 计划
- Estimate - 估计这个任务需要多少时间 1 1
DEVELOPMENT 开发
- Analysis & Design Spec - 需求分析 & 生成设计规格（确定要实现什么） 10 6
- Technical Background - 了解技术背景（包括学习新技术） 3 2
- Coding Standard - 代码规范 1 1
- Design - 具体设计（确定怎么实现） 2 1
- Coding - 具体编码 10 10
- Code Review - 代码复审 5 7
- Test Design - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） 3 1
- Test Implement - 测试实现（设计/生成具体的测试用例、编码实现测试） 5 4
REPORTING 报告
- Quality Report - 质量报告（评估设计、实现、测试的有效性） 5 2
- Size Measurement - 计算工作量 5 2
- Postmortem & Process Improvement Plan - 事后总结和过程改进计划（总结过程中的问题和改进点） 5 3
TOTAL 合计 55 40

→ 📖 Q1.8(I) 请写下本部分的心得体会。
编写规则判定类模块最好还是先滤清思路再写逻辑，反正写测试样例的时候都要考虑各种极端情况，先想好再写就能避免反复增改代码
搭档用数组来标记魅力值排名非常巧思，令我恍然大悟

Chapter.2 不祥之影

准备

→ 📖 Q2.1(P) 请记录下目前的时间。

20:20

→ 📖 Q2.2(P) 请在完成任务的同时记录,并在完成任务后整理完善:

  1. 浏览任务要求,参照 附录A:基于 PSP 2.1 修改的 PSP 表格,估计任务预计耗时;
  2. 完成编程任务期间,依次做了什么(比如查阅了什么资料,随后如何进行了开发,遇到了什么问题,又通过什么方式解决);

查阅资料:

  1. 购入了花见小路桌游，借助按照样例摆牌快速理解逻辑
  2. 对着教程学习 AssemblyScript 中字符串处理和二维数组操作的方法

状态推演逻辑设计:

  1. 实现了 calc_current_state 主函数,遍历历史记录并逐步更新状态
  2. 设计了 refresh_table 函数用于根据单个行动更新目前牌桌状态
  3. 设计了 update_board_from_table 函数将牌桌结果结算到分数计算表中

遇到的问题与解决:

  1. 不清楚AssemblyScript如何将行动历史按空格分隔成行动指令，查阅教程后用计数字符后分割的思路实现了
  2. 对于 flag 的计算(count % 2),需要理解奇数轮次是己方先手,偶数轮次是对方先手
  3. 一开始refresh_table的部分理解有误，还考虑了艺妓分值，最后发现只要计算礼物牌数就可以了
  4. 对于行动3和4的判定逻辑的实现有些无从下手，最后使用了穷举的笨方法orz

代码可复用性与需求变更

→ 📖 Q2.3(P) 请说明针对该任务,你们对 🧑‍💻 T1 中已实现的代码进行了哪些复用和修改。

复用了board的状态表示格式，别的好像都没有用到T1的地方...

→ 📖 Q2.4(I) 请说明在编码实现时,可以采取哪些设计思想、考虑哪些设计冗余,来提高既存代码适应需求变更的能力。

模块化设计：把指令解析的逻辑和更新分数状态的逻辑分别封装到两个函数中，这样当规则变化时只需修改这两个函数，而不需要修改主函数。

测试数据边界：在 refresh_table 中对输入的行动字符串进行合法性校验,确保索引不越界，以在数据异常时提供保护

参数化：函数参数化，将输入参数传入函数中，函数内部不再使用全局变量，从而提高代码的复用性。（这么想来感觉跟模块化差不多？）

头脑风暴环节

→ 📖 Q2.5(P) 头脑风暴环节:

我们终于快要开始让程序玩游戏了!请尝试分析:T2 中不带 X 的操作记录比起实际对局多出了多少信息?如果加上 X,也就是失去了这部分信息的话,如何处理对小轮结束后状态的估计?

加上X，也就相当于模拟一方玩家所能看到的牌局情况（看不见对手1和2扣住的牌）
所以想要猜测对手的牌局情况，有以下几种思路：

  1. 概率推断:
    基于已知的牌分布(总共有 21 张牌:ABC各2张,DE各3张,F4张,G5张)，通过观察对手的行动模式,推断其可能持有的牌

  2. 约束满足:
    利用已知信息建立约束条件(如:某张牌不可能同时在双方手中)，枚举所有可能的隐藏状态,排除违反规则的组态

  3. 对手建模:
    构建对手的策略模型,预测其在不同情况下的行为，根据对手的选择反推其手牌构成

总结

→ 📖 Q2.6(P) 请记录下目前的时间,并根据实际情况填写 附录 A:基于 PSP 2.1 修改的 PSP 表格 的"实际耗时"栏目。

22:20

Personal Software Process Stages 个人软件开发流程 预估耗时（分钟） 实际耗时（分钟）
PLANNING 计划
- Estimate - 估计这个任务需要多少时间 2 2
DEVELOPMENT 开发
- Analysis & Design Spec - 需求分析 & 生成设计规格 15 12
- Technical Background - 了解技术背景 5 8
- Coding Standard - 代码规范 2 2
- Design - 具体设计 10 15
- Coding - 具体编码 60 75
- Code Review - 代码复审 15 20
- Test Design - 测试设计 10 8
- Test Implement - 测试实现 15 18
REPORTING 报告
- Quality Report - 质量报告 10 8
- Size Measurement - 计算工作量 5 5
- Postmortem & Process Improvement Plan - 事后总结 10 7
TOTAL 合计 159 180

→ 📖 Q2.7(I) 请写下本部分的心得体会。
主要难点应该就是对行动3和4的逻辑实现？尤其要注意判断此时行动者是谁，从而正确计分。我粗暴地穷举实现了，不知道有没有更好的方法...2舍弃可以直接不用考虑计分很开心（尽管玩桌游时很讨厌这个行动...）
而且代码还是分层设计解耦合更方便，不然每次改动都要重新梳理一遍逻辑。一开始本来是把refresh_table和update_board_from_table都写在主函数里来着，后来发现这样主函数也太复杂了！改动起来也很麻烦

Chapter.3 道途之荆

准备

→ 📖 Q3.1(P) 请记录下目前的时间。

19:50

→ 📖 Q3.2(P) 请在完成任务的同时记录,并在完成任务后整理完善:

  1. 浏览任务要求,参照 附录A:基于 PSP 2.1 修改的 PSP 表格,估计任务预计耗时;
  2. 完成编程任务期间,依次做了什么(比如查阅了什么资料,随后如何进行了开发,遇到了什么问题,又通过什么方式解决);

查阅资料:

  1. 分析了T2中实现的状态推演逻辑,思考如何在AI决策中复用
  2. 对着教程学习AssemblyScript中的数组操作、排序算法和字符串处理方法

AI策略设计:

  1. 设计了卡牌价值评估函数calcValue,综合考虑基础分值、board状态和可见度
  2. 实现了四种行动类型的选择逻辑,按照优先级依次尝试
  3. 针对赠予和竞争设计了具体的牌组分配策略
  4. 实现了对手回应时的最优选择逻辑

遇到的问题与解决:

  1. 最初在设计行动选择时,简单按固定顺序尝试。后来发现应该根据手牌数量和已用行动动态调整
  2. 在实现行动4的牌组分配时,需要枚举所有可能的分组方式并选择最优解
  3. 对于对手回应的处理,需要在对方视角下重新评估牌的价值

头脑风暴环节

→ 📖 Q3.3(P) 头脑风暴环节:

假设提供更充裕的时间和资源,这个游戏中你能找到的最优策略有可能是什么形式的?进行调研并总结分析。你还可以在任务结束后试着实现(不计分)。

《花见小路》属于不完全信息博弈，目前其最优策略研究主要有两个方向：

基于深度学习的反事实遗憾最小化 (Deep CFR)
这是德州扑克 AI（如 Libratus、Pluribus）用的核心技术。花见小路的状态空间比德州扑克小得多，完全可以用 CFR 算法迭代出纳什均衡策略。

其策略不再是简单的 if-else，而是一个巨大的策略表（或者神经网络），输入是当前的牌局历史序列 + 手牌，输出是每种行动（1密约/A 牌、3赠予/ABC 组合...）的概率分布。

它几乎无法被人类利用弱点，因为它是平衡的。它会在某些时候故意打出看似“亏了”的牌（比如送对手一张好牌），但目的是为了在后续回合中构建更隐蔽的陷阱。

蒙特卡洛树搜索 (MCTS) + 对手建模
在不完全信息下，标准的 MCTS 需要改造为 POMCP (部分可观测蒙特卡洛规划)。

在每次决策时，根据对手的历史行动，推断对手大概率没有什么牌、小概率有什么牌，然后针对这个分布进行千次自我对弈模拟，选出胜率最高的那条路。

对于《花见小路》这种一局只用 4 次行动的短游戏，单纯的价值计算和贪心算法容易短视。如果用 MCTS 模拟到终局，它能看到类似“现在用密约锁住这张 2 分牌，虽然眼下小亏，但终局会因为对手卡手而大胜”的结论。

需求建模和算法设计

→ 📖 Q3.4(P) 请说明针对该任务,你们采取了哪些策略来优化决策。具体而言,怎么选择行动类型?选牌如何更优?如何编程实现。

1. 行动类型选择的优先级固化（全局最优贪心）

我们没有做复杂的搜索树，而是依据游戏经验锁死了行动优先级：

密约 (1) > 赠予 (3) > 竞争 (4) > 取舍 (2)

理由：密约是零风险纯收益，必先手用掉。赠予和竞争虽然会暴露牌，但能处理多张手牌，效率高于取舍（取舍是纯负收益）。代码里用 used.includes 判断顺序，逻辑清晰且执行极快。

2. 选牌策略的差异化实现

这是最体现“策略”的地方，我们针对不同行动设计了完全相反的选牌逻辑：

  • 自己打密约/自己取舍：找 max 或 min
  • 自己打赠予/竞争：
    • 赠予：选价值最低的 3 张给对手看
    • 竞争：用 Maximin 算法分组
  • 回复对手时：
    • 回复赠予：选价值最高的那张拿走
    • 回复竞争：选总分更高的那组拿走

3. 价值函数辅助决策

为了让 calcValue 既能看懂局势，又不需要复杂计算，我们用了整数量化放大法：

let value = BASE * 100;           // 基础分权重大
value += (200 - board * 100);    // 形势紧迫度（没拿过是+200，拿过了就扣分）
if (unseen <= 2) value += 200;   // 稀缺性绝杀加成

理由：这个公式保证了 AI 会去抢 5 分大牌，但如果大牌已经被对手拿了 2 个标记（board 高了），AI 会果断转去投资那些差一点就拿满的 2-3 分小牌。

代码可复用性与需求变更

→ 📖 Q3.5(P) 请说明针对该任务,你们对 🧑 💻 T2 中已实现的代码进行了哪些复用和修改。

  1. 复用calc_current_state函数的思路来统计已使用的行动类型和已出现的牌

  2. 依旧沿用board格式

  3. 生成行动字符串时遵循T2中的格式规范

→ 📖 Q3.6(I) 请说明在编码实现时,可以采取哪些设计思想、考虑哪些设计冗余,来提高既存代码适应需求变更的能力。
也许可以设计一个策略切换机制，定义策略接口，根据对手的风格和游戏阶段动态切换策略；或者更细节一点，让四个行动的优先级可动态调整。

软件度量

→ 📖 Q3.7(P) 请说明你们如何量度所实现的程序模块的有效性,例如:"如何说明我们的程序模块决策能力很强?",尝试提出一些可能的定量分析方式或测试方式。

统计胜率：统计在大量对局中获胜的比例

与固定强度的baseline AI进行若干场对局，记录胜/负/平的次数,计算胜率 = (胜 + 0.5×平) / 总场次

如果胜率显著高于随机策略(>50%),就能说明决策能力很强。

测试决策稳定性：在相似局面下能否做出相似决策

收集大量相似的游戏状态(相同的board、相似的手牌)，统计AI在这些状态下选择相同行动的比例，计算一致性指数 = 最常见行动的次数 / 总次数

高一致性表明策略稳定可靠,低一致性可能意味着随机性或bug

进行压力测试

构造极端情况:手牌极差、比分大幅落后等，测试AI在不利条件下的表现

真人评价
邀请桌游爱好者与AI对局，收集主观反馈

总结

→ 📖 Q3.8(P) 请记录下目前的时间,并根据实际情况填写 附录A:基于 PSP 2.1 修改的 PSP 表格 的"实际耗时"栏目。

23:30

Personal Software Process Stages 个人软件开发流程 预估耗时（分钟） 实际耗时（分钟）
PLANNING 计划
- Estimate - 估计这个任务需要多少时间 3 3
DEVELOPMENT 开发
- Analysis & Design Spec - 需求分析 & 生成设计规格 20 25
- Technical Background - 了解技术背景（AI策略调研） 30 45
- Coding Standard - 代码规范 3 3
- Design - 具体设计（策略算法设计） 25 35
- Coding - 具体编码 120 150
- Code Review - 代码复审 30 40
- Test Design - 测试设计 20 15
- Test Implement - 测试实现 30 35
REPORTING 报告
- Quality Report - 质量报告 15 12
- Size Measurement - 计算工作量 10 10
- Postmortem & Process Improvement Plan - 事后总结 15 12
TOTAL 合计 321 385

→ 📖 Q3.9(I) 请写下本部分的心得体会。
博弈！我自己还没玩明白花见小路（在有三四局经验的前提下惨败于第一次玩的结对搭档哈哈），T3就要求我们用算法实现决策了，天啊

与T1/T2的确定性逻辑不同,T3要求我们在信息缺失的情况下做出决策，相当于在T2中加入X。这让计算量大大增加，我们需要通过已有牌局和己方手牌去预测对手可能的牌型，并据此做出最优决策；而且因为桌游的牌组具有随机性，在手牌处于优势和劣势的情况下，也需要应用不同的策略来维持优势或者摆脱劣势...博弈！

结对项目总结

结对过程回顾和反思

→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。

→ 📖 Q4.2(P) 回顾结对的过程,反思有哪些可以提升和改进的地方。

  1. 没有边完成任务边记录: question.md的文档是在每完成了一整章的任务后填写的，这导致了一些具体的讨论和决策过程没有被记录下来。如果能在编码的同时就同步更新文档，也许会更加完整地保留我们的思考轨迹。

  2. 技术预研不足: 开始任务前，我们都不太了解AssemblyScript，很多时候都是边看教程边写代码；T3之前,我们也没有充分调研现有的AI策略和相关算法,导致在设计阶段花费了较多时间探索方向。如果能在项目初期就进行更系统的学习,可能会找到更优的解决方案。

→ 📖 Q4.3(I) 锐评一下你的搭档!并请至少列出三个优点和一个缺点。
优点：1.超级不拖延星人，很早就拉着我做完了任务
2.效率很高，第一章他驾驶很快就写完了
3.测试思路很严谨，许多极端边界情况都是他找出来的

缺点：在写代码前偶尔没能规划好完整的逻辑（虽然我也这样）

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点是能两个臭皮匠顶2/3个诸葛亮？集思广益，利用双方的优势解决单人难以应对的问题；而且也能实时进行代码审查，提高代码质量；有队友在旁也能很好打消偷懒的念头，提高工作效率（）
缺点是两个人的工作时间需要协调，缺少灵活性；而且领航员负责审查在提高代码质量的同时，也不可避免地提高了人力成本，对于短期任务来说可能不太划算

总的来说，结对编程是一种1+1>2的协作模式。它不仅能通过密切合作提高代码质量，更重要的是，它要求并锻炼了我们的沟通、协调与团队协作能力。

代码实现提交

→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。

https://github.com/Apex-He/BUAASE2026-PairProgramming.git

posted @ 2026-04-11 15:50  特困战士拉  阅读(5)  评论(0)    收藏  举报