[P] 结对项目：花见小路
结对项目：博客问题清单
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
→ 📖 Q0.0(P) 【你可以在结对结束后补充】如果你的代码仓库包含 AIGC 的部分，列举使用的工具、模型和使用范围。若未使用则填写：本组提交的全部代码不包含AI补全或生成的部分。
本项目使用了 Codex，使用范围包括：
- RUST语法纠正，项目构建+编译流程指导。
- T1自动化测试流程构建，补强测试覆盖。
- 代码质量评测和检查。
- T3策略的优化。
Chapter.0 wasm从安装到入门
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
4.8 14:28
调查
→ 📖 Q0.2(I) 【你可以在结对结束后另行补充。】作为本项目的调查：
请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I，完全没听说过
请如实标注在开始项目之前对桌游花见小路的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）
I. 不了解玩法和规则；
II. 听说过，且有一定了解；
I，完全没听说过
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
4.8 14:44
Chapter.1 七色之缨
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
4.8 14:53
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（例如查阅了哪些资料、如何设计判定逻辑、如何设计测试样例、遇到了什么问题、如何解决）。
- 读题，并看了规则视频
- 搭建项目框架
- 写代码，查阅RUST语法文档，跑通编译。（期间忘记修改.env模块路径问题、遇到RUST语法问题）
- 跑通课程组基础样例
- 补充题目要求覆盖的样例
- AI实现自动化测试流程并补充测试用例
设计
→ 📖 Q1.3(P) 请说明你们为这个判定模块设计了哪些中间量或辅助函数；如果没有额外设计，也请说明为什么认为直接实现已经足够清晰。
设计了三个辅助函数，符合封装规范，便于调试
total_points(board, side)：统计一方当前总分。marker_count(board, side)：统计一方倾心标记数量。has_group_marker(board, side, group)：判断同分时某档位（G/F/DE/ABC）是否占优。
→ 📖 Q1.4(I) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。
- 先写“规则顺序清单”，代码严格按清单顺序组织。
- 把“立即胜利条件”与“第三轮最终判定”分段实现，避免逻辑交叉。
- 对关键边界单独建例：
10->11、3->4、同分档位比较、第三轮平局。 - 对称性检查：构造我方/对手镜像样例，验证
1与-1分支一致性。
测试
→ 📖 Q1.5(P) 请说明你们设计了哪些测试用例，这些测试分别覆盖了哪一类规则或边界情况。
- 一方分值达到 11 分获胜（我方/对手）
- 一方获得至少 4 枚倾心标记获胜（我方/对手）
- 前两小轮未满足胜利条件返回
0 - 第三小轮总分不同时总分高者胜
- 第三小轮总分相同按档位（G > F > DE > ABC）判胜
- 第三小轮无法区分时返回平局
2
→ 📖 Q1.6(I) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。
先写测试再实现：可以在编写代码时有覆盖测试的意识，代码会更加严谨。但可能会受到预先编写的测试的影响。
先实现再补测试：应该是更加常见的方式，符合逻辑，更容易覆盖到更广的情况。
总结
→ 📖 Q1.7(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
4.8 15：36
→ 📖 Q1.8(I) 请写下本部分的心得体会。
题目相当于程设plus版，但是面对的是更长的题面和没有接触过的语言。感觉难度本身不算大，结对编程的体验很新奇，在交流中效率更高了，测试方面也能够互补考虑不周全的情况。
Chapter.2 不祥之影
准备
→ 📖 Q2.1(P) 请记录下目前的时间。
4.8 15：40
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
- 反复读题目，玩了几局，在游戏中强化对题目的理解
- 搭建代码框架，更改.env路径
- 讨论实现思路
- 实现
calc_current_state(history, board)：按行动记录重建双方明暗牌计数并推导新board - 处理
1/2/3/4行动及-choice响应 - 修改和检验是
3赠予和4竞争的牌组归属 - 修正语法错误，通过编译
- 执行测试，挂了
- 一起看问题，分工阅读代码，结果是边界循环少了等号
- 重新执行测试并通过
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T1 中已实现的代码进行了哪些复用和修改。
复用：“牌面索引映射”思路（A-G 映射到 [0..6]）；把字符串解析、计数更新、比较逻辑分开
修改：T2 更偏状态重建，不再是单次判定，因此新增历史 token 解析与行动回放逻辑
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
这在之前的OO课上也是一个重要的问题，结合之前的学习和此次任务过程，总结如下：
- 将问题抽象成不同层级，比如这里让“解析”和“业务更新”分层
- 对动作类型使用统一分发（
match action_type），减少散落 if 分支 - 多进行函数封装
- 为关键规则准备最小回归样例，未来规则变动时先改测试再改实现
- 尽量减少“特判”，从比较通用、普适的角度设计代码架构
头脑风暴环节
→ 📖 Q2.5(P) 头脑风暴环节：
我们终于快要开始让程序玩游戏了！请尝试分析：T2 中不带 X 的操作记录比起实际对局多出了多少信息？如果加上 X，也就是失去了这部分信息的话，如何处理对小轮结束后状态的估计？
T2 无 X 等于看到完整公开历史，信息接近“可重建状态”，不确定性小，如果引入 X，会丢失对手密约/弃牌等关键信息，可以维护候选状态集合，对不可见牌做约束采样，再按期望收益做决策。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录 A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
4.8 16：40
→ 📖 Q2.7(I) 请写下本部分的心得体会。
此部分难度也不算大，主要是要把规则读清楚，逻辑覆盖完整。行动日志解析不严谨，后续策略层会建立在错误状态上，所以动手前要多想
Chapter.3 道途之荆
准备
→ 📖 Q3.1(P) 请记录下目前的时间。
4.8 17:53
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
- 进行多次游戏对局，交流经验和想法
- 试图在网上搜索已有经验，但是结果较少
- 和其他组进行游戏，交流经验
- 搭建代码框架
- 先进行启发式算法，通过编译和测试，实现了较为稳妥的策略
- 尝试升级策略，期间导致响应不合法，重新修改
- 询问大模型寻找启发
- 使用codex编写自动对局脚本，评估策略性能
- 两人分开写不同的策略，要来其它组的策略，进行多次测试，不断修正对比
- 综合考虑工作量、稳定性和性能，确定最终版，再次编译测试
- 使用codex润色策略，给出指导意见
- 再次编译测试
头脑风暴环节
→ 📖 Q3.3(P) 头脑风暴环节：
假设提供更充裕的时间和资源，这个游戏中你能找到的最优策略有可能是什么形式的？进行调研并总结分析。你还可以在任务结束后试着实现（不计分）。
如果时间和算力都更充足，我觉得最优策略大概率会是“离线求解+在线查表”的形式：
- 先用大量自博弈把常见局面算出较优动作，做成策略表。
- 对信息不完整的部分，用概率分布维护对手可能手牌，再按期望收益选动作。
- 在线决策时不做太深搜索，优先查表+少量前瞻，保证响应稳定和合法。
- 再加一个轻量学习模块，持续从失败对局里修正评估权重。
简单说就是：离线花时间算“聪明”，在线花时间保“稳定”。
需求建模和算法设计
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么选择行动类型？选牌如何更优？如何编程实现。
我们的策略思路是“先保底，再争优势”：
-
行动类型选择：
优先选能减少损失、同时制造对手两难的行动；当局面接近时偏保守，领先时扩大优势，落后时提高进攻性。 -
选牌方式：
先给每张牌一个权重（当前分值影响、后续连锁价值、被针对风险），再在候选组合里选综合分最高的方案。 -
编程实现：
把流程拆成“状态解析 -> 候选动作生成 -> 动作评分 -> 合法性校验 -> 输出动作”；
评分函数支持参数调节，配合自动对局脚本反复试验，最后选稳定性和胜率都比较好的版本。
代码可复用性与需求变更
→ 📖 Q3.5(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
复用部分：
- 继续使用 T2 的状态重建逻辑，先根据历史动作还原当前局面。
- 复用牌面索引映射和基础数据结构，避免重复造轮子。
- 复用输入解析与合法性检查的框架，保证输出动作格式正确。
修改部分：
- 在 T2 基础上新增“候选动作生成”和“动作评分”模块。
- 增加对不同行动类型的优先级控制，支持按局势动态切换策略。
- 增加自动对局评估脚本对接，方便批量测试和参数调整。
→ 📖 Q3.6(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
- 把策略拆成：
parse -> infer -> generate -> score -> output。 - 独立“动作合法性层”与“策略偏好层”，便于替换打分而不破坏格式正确性。
- 保留 fallback 路径（如默认动作与默认选择），确保边界输入下也可返回可执行结果。
软件度量
→ 📖 Q3.7(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块决策能力很强？”，尝试提出一些可能的定量分析方式或测试方式。
我们主要用下面几种方式做量化：
- 胜率：固定局数下与基线策略对战，统计总胜率和先后手分开胜率。
- 稳定性：统计非法输出次数、超时次数、异常中断次数，要求尽量接近 0。
- 关键局面表现：抽取高风险局面做专项测试，看是否能做出合理动作。
- 回归表现：每次改动后跑同一套测试集，确认没有明显退步。
- 对不同风格对手的泛化：和保守型、激进型、随机型策略分别对战，观察是否存在明显短板。
总结
→ 📖 Q3.8(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
4.10 3：52
→ 📖 Q3.9(I) 请写下本部分的心得体会。
T3 需要平衡工作量、效能和难度，是实际工程中常见的trade off。有时候费劲写半天结果发现胜率没提高多少，反应时间倒是多了。最终还是选择了比较保守稳妥的策略作为最终版，优先保证合法性、兼容性和可复现，再逐步迭代性能，是更务实的路线。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
回顾这次结对，整体配合比较顺畅，但还有几个可改进点：
- 前期可以更早统一“规则理解文档”，减少后面来回确认细节的时间。
- 中期可以把分工再细化，比如一人主攻实现、一人主攻测试和复盘，切换更明确。
- 后期可以更早接入自动评测，不要等策略基本成型后才大量跑对局。
- 每个阶段结束做 5 分钟小复盘，及时同步问题，会比最后集中返工更省时间。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
- 思维敏捷，编码能力强
- 表达清晰，交流顺畅，能很好地表达自己的观点
- 考虑全面，测试方面贡献了比较全面的测试点
缺点：
- 推进太快，没有进行全面的代码规划就动手写了
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
- 优点：知识共享快，集思广益，有时候脑抽犯的错能够被很快纠正，不至于酿成大错
- 缺点：沟通成本更高，若角色不清晰容易重复劳动。
- 理解：结对编程不是两个人同时敲代码，而是持续对齐目标 + 快速反馈 + 质量共担的过程。
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/KarasFlowers/BUAASE-pair-SUBMIT.git
附录
附录 A：基于 PSP 2.1 修改的 PSP 表格
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 40 | 52 |
| - Estimate | - 估计任务耗时 | 40 | 52 |
| DEVELOPMENT | 开发 | 610 | 712 |
| - Analysis & Design Spec | - 需求分析与设计规格 | 90 | 122 |
| - Technical Background | - 技术背景学习 | 80 | 103 |
| - Coding Standard | - 代码规范 | 20 | 21 |
| - Design | - 具体设计 | 90 | 112 |
| - Coding | - 具体编码 | 180 | 199 |
| - Code Review | - 代码复审 | 40 | 52 |
| - Test Design | - 测试设计 | 45 | 56 |
| - Test Implement | - 测试实现 | 65 | 45 |
| REPORTING | 报告 | 130 | 152 |
| - Quality Report | - 质量评估 | 35 | 40 |
| - Size Measurement | - 工作量统计 | 20 | 25 |
| - Postmortem & Process Improvement Plan | - 事后总结与改进计划 | 75 | 85 |
| TOTAL | 合计 | 780 | 914 |
浙公网安备 33010602011771号