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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[P] 结对项目：花见小路
我在这个课程的目标是	完整参与开发一套成熟的软件，提高技术和工程能力
这个作业在哪个具体方面帮助我实现目标	熟悉结对编程的方式，增强协作能力

结对项目：博客问题清单

请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。

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

模型：Sonnet4.6

使用范围：代码骨架生成、类型报错定位。核心规则判断与测试场景由两名成员共同复核后确认。

Chapter.0 wasm从安装到入门

引入

→ 📖 Q0.1(P) 请记录下目前的时间。
答：2026-04-05 14:00

调查

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

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

I. 没有听说过；

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

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

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

Wasm ：II（仅限于听说过相关名词）。
开始前只知道“可以让非 JS 语言在 Web/Node 运行”，对实际工具链和导出接口基本不了解。

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

I. 不了解玩法和规则；

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

花见小路：I（不了解玩法和规则）。
开始前只知道是双人博弈桌游，具体行动规则是本次项目中边看文档边学习。

总结

→ 📖 Q0.3(P) 请记录下目前的时间。
2026-04-05 14:20

Chapter.1 七色之缨

结对过程

→ 📖 Q1.1(P) 请记录下目前的时间。
2026-04-05 14:20

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

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

预计耗时 40 分钟。过程上我们先共同梳理规则优先级（11分 > 4枚 > round判断 > 第三轮比较），袁子轩主导规则建模与函数拆分，初浩然主导测试样例整理与断言对照。遇到的主要问题是 AS 的 i8/i32 类型以及与 JS 测试接口对接，最终通过统一关键统计量为 i32 并固定导出签名解决。

设计

→ 📖 Q1.3(P) 请说明你们为这个判定模块设计了哪些中间量或辅助函数；如果没有额外设计，也请说明为什么认为直接实现已经足够清晰。
我们设计了 myScore/oppScore、myCount/oppCount 作为核心中间量，并设计了 tierResult(...) 用于第三轮同分时按 G > F > D/E > A/B/C 进行分档判定。这样做能够保证分支逻辑清晰，也便于后续 T2/T3 复用判定思想。

→ 📖 Q1.4(I) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。
我采用“规则清单转决策树”的方式：先把题面判定优先级线性列出，再逐条映射为代码分支，并要求每条分支至少有一个测试。实现前额外准备反例列表（例如第三轮同分且不同档位、同档位仍平局），防止只覆盖直观路径。

测试

→ 📖 Q1.5(P) 请说明你们设计了哪些测试用例，这些测试分别覆盖了哪一类规则或边界情况。
我们覆盖了 6 类核心场景：1) 11分胜利；2) 4枚胜利且对方未达11分；3) 前两轮继续返回0；4) 第三轮总分决胜；5) 第三轮同分按最高档位决胜；6) 第三轮平局返回2。另补充了输入长度异常等防御性检查。

→ 📖 Q1.6(I) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。
我理解先写测试更适合规则明确、边界多的模块，先实现再补测试更适合先打通数据链路。本项目采用折中方式：先写关键规则测试，再边实现边补反例。

总结

→ 📖 Q1.7(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
答：2026-04-05 15:00

→ 📖 Q1.8(I) 请写下本部分的心得体会。
这一部分让我意识到规则类模块最难的是“分支顺序正确”，而不是语法实现本身。把规则写成可验证测试，能显著降低漏判概率。

Chapter.2 不祥之影

准备

→ 📖 Q2.1(P) 请记录下目前的时间。
2026-04-05 15:00

→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
预计耗时 70 分钟。我们先定义 history 解析格式：行动体 + 可选选择后缀，分别实现 1/2/3/4 行动对区域牌面的影响，再复用 T1 的结算思路更新 board。遇到问题主要是字符串解析容错、X 信息处理和 AS 类型细节，最终通过合法性校验与保守跳过策略解决。

代码可复用性与需求变更

→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑‍💻 T1 中已实现的代码进行了哪些复用和修改。
复用了 T1 中“按角色比较双方数量后更新得分标记”的核心思想；保留了 T1 的结果语义便于 T3 使用；并把 T1 的纯判定函数扩展为 T2 的状态推进函数。

→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
我认为关键是“解析与规则分离”：解析 history、更新区域、结算 board 分层实现。对输入异常增加防御分支，保证单点错误不扩散；把关键小函数做成无副作用，后续规则变动时可局部替换。

头脑风暴环节

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

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

T2 不带 X 的记录比真实对局多出了对手暗置信息，是“全信息回放”，可精确重建状态。若引入 X（不完全信息），可用“信念状态估计”：枚举或采样可能牌型、维护状态概率分布，并在决策时使用期望值或最坏情况准则。

总结

→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录 A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2026-04-05 16:00

→ 📖 Q2.7(I) 请写下本部分的心得体会。
我体会到解析模块的正确性主要来自数据结构约束和输入边界控制，而不是 if-else 数量。先定义清楚输入输出，再编码会更稳。

Chapter.3 道途之荆

准备

→ 📖 Q3.1(P) 请记录下目前的时间。
2026-04-05 16:00

→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
预计耗时 80 分钟。实现路线是先完成可运行基线策略（合法动作优先），再引入基于 board 的启发式优先级，最后集中处理 AS 编译问题（类型、闭包限制）。分工上成员A主导策略框架，成员B主导联调回归与报错修复。

头脑风暴环节

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

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

如果资源更充裕，我们会考虑不完全信息博弈框架（如 CFR/MCTS 结合对手建模），并用大量自博弈数据逼近稳定策略。在课程时限内，我们选择可解释、可调试的轻量启发式方案。

需求建模和算法设计

→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么选择行动类型？选牌如何更优？如何编程实现。
行动类型上优先保证四类动作均可合法执行；选牌上使用 board 作为权重，优先争夺高价值且对方占优/中立的角色；实现上拆分响应逻辑（-X/-XX）与主动出牌逻辑（1/2/3/4），并加防御返回避免非法输出。

代码可复用性与需求变更

→ 📖 Q3.5(P) 请说明针对该任务，你们对 🧑‍💻 T2 中已实现的代码进行了哪些复用和修改。
复用了 T2 的动作解析思路、board 作为局面输入的表达方式，以及输入异常时保守处理的思想；在 T3 上新增了策略评分与先后手推断模块。

→ 📖 Q3.6(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
我采用“分层策略架构”：合法性层、基线策略层、优化层分离。这样未来要替换启发式或接入搜索，只动优化层，不破坏合法性和接口层。

软件度量

→ 📖 Q3.7(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块决策能力很强？”，尝试提出一些可能的定量分析方式或测试方式。
我们计划从四个指标评估：1) 对固定基线策略的胜率；2) 多随机种子下平均得分与净胜场；3) 决策耗时（均值/P95）；4) 非法动作率和异常终止率。目标是“稳定胜率 + 接近0的异常率”。

总结

→ 📖 Q3.8(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2026-04-05 17:00

→ 📖 Q3.9(I) 请写下本部分的心得体会。
这部分我最大的体会是工程折中：在有限时间里先保证正确性与稳定性，再逐步优化决策质量，整体收益更高。

结对项目总结

结对过程回顾和反思

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

→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
结对中做得较好的是分工明确、提交记录完整、问题闭环快。可改进点是前期更早统一 AssemblyScript 类型规范，并提前准备系统化回归脚本减少后段联调压力。

→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：1) 测试意识强，边界覆盖全；2) 联调耐心好，问题跟到底；3) 文档梳理清晰。缺点：前期偏向先跑通，导致类型细节在后续集中返修。

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点是实时复审和即时纠偏，能同时覆盖“实现视角+验证视角”；缺点是沟通成本高、节奏不一致时会互相等待。总体上本项目场景下结对收益明显高于单人开发。

代码实现提交

→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/CircleCoder05/BUAASE2026-PairProgramming

附录

附录 A：基于 PSP 2.1 修改的 PSP 表格

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