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

结对项目：博客问题清单

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

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

  1. RUST语法纠正，项目构建+编译流程指导。
  2. T1自动化测试流程构建，补强测试覆盖。
  3. 代码质量评测和检查。
  4. T3策略的优化。

Chapter.0 wasm从安装到入门

引入

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

4.8 14:28

调查

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

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

I. 没有听说过；

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

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

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

Wasm 这块我开始前大概是 II。就是听过这个词，知道和前端性能有点关系，但具体怎么从 Rust 编译、怎么在页面里跑，基本不清楚。

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

I. 不了解玩法和规则；

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

花见小路我开始前也算 II。知道是双人博弈类桌游，但规则细节和每一步怎么取舍都不太懂。

总结

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

Chapter.1 七色之缨

结对过程

→ 📖 Q1.1(P) 请记录下目前的时间。
4.8 14:53
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

  1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
  2. 完成编程任务期间，依次做了什么（例如查阅了哪些资料、如何设计判定逻辑、如何设计测试样例、遇到了什么问题、如何解决）。
  1. 读题，并看了规则视频
  2. 搭建项目框架
  3. 写代码，查阅RUST语法文档，跑通编译。（期间忘记修改.env模块路径问题、遇到RUST语法问题）
  4. 跑通课程组基础样例
  5. 补充题目要求覆盖的样例
  6. AI实现自动化测试流程并补充测试用例

设计

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

设计了三个辅助函数，符合封装规范，便于调试

  1. total_points(board, side)：统计一方当前总分。
  2. marker_count(board, side)：统计一方倾心标记数量。
  3. has_group_marker(board, side, group)：判断同分时某档位（G/F/DE/ABC）是否占优。

→ 📖 Q1.4(I) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。

我觉得要避免漏判和错判，最实在的是这几件事：

  1. 先把规则顺序写成清单，再按顺序写代码，不要想到哪写到哪。
  2. 专门测边界，比如刚好 11 分、刚好 4 个标记、第三轮同分这种。
  3. 每改一次逻辑就跑一遍核心用例，防止前面好的地方被改坏。
  4. 复杂判断拆成小函数，调试时更容易看出是哪一步错了。

测试

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

  1. 一方分值达到 11 分获胜（我方/对手）
  2. 一方获得至少 4 枚倾心标记获胜（我方/对手）
  3. 前两小轮未满足胜利条件返回 0
  4. 第三小轮总分不同时总分高者胜
  5. 第三小轮总分相同按档位（G > F > DE > ABC）判胜
  6. 第三小轮无法区分时返回平局 2

→ 📖 Q1.6(I) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。

我理解这两种方式各有用处：

  1. 先写测试再实现，适合规则比较明确的时候，写起来更稳。
  2. 先实现再补测试，适合一开始思路还不完整，先跑起来再说。
  3. 实际做项目我觉得是混着来：前期先跑通，后期一定要把测试补全。

总结

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

→ 📖 Q1.8(I) 请写下本部分的心得体会。
这部分做完我最大的感受是：能跑通不代表写得好。后面要改规则的时候，结构清不清楚差别很大。结对也确实有帮助，很多我没想到的边界是搭档提醒的，少走了不少弯路。

Chapter.2 不祥之影

准备

→ 📖 Q2.1(P) 请记录下目前的时间。
4.8 15：40
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

  1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
  2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
  1. 反复读题目，玩了几局，在游戏中强化对题目的理解
  2. 搭建代码框架，更改.env路径
  3. 讨论实现思路
  4. 实现 calc_current_state(history, board)：按行动记录重建双方明暗牌计数并推导新 board
  5. 处理 1/2/3/4 行动及 -choice 响应
  6. 修改和检验是 3 赠予和 4 竞争的牌组归属
  7. 修正语法错误，通过编译
  8. 执行测试，挂了
  9. 一起看问题，分工阅读代码，结果是边界循环少了等号
  10. 重新执行测试并通过

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

复用：“牌面索引映射”思路（A-G 映射到 [0..6]）；把字符串解析、计数更新、比较逻辑分开
修改：T2 更偏状态重建，不再是单次判定，因此新增历史 token 解析与行动回放逻辑

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

我觉得想让代码更抗改，主要是这几点：

  1. 解析和业务逻辑分开，后面改输入格式时不容易牵一发动全身。
  2. 动作处理尽量走统一分支，不要到处写 if-else。
  3. 关键函数留好接口，后面换策略不会全重写。
  4. 把出过的问题变成固定测试，避免之后又踩同一个坑。

头脑风暴环节

→ 📖 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) 请在完成任务的同时记录，并在完成任务后整理完善：

  1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
  2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
  1. 进行多次游戏对局，交流经验和想法
  2. 试图在网上搜索已有经验，但是结果较少
  3. 和其他组进行游戏，交流经验
  4. 搭建代码框架
  5. 先进行启发式算法，通过编译和测试，实现了较为稳妥的策略
  6. 尝试升级策略，期间导致响应不合法，重新修改
  7. 询问大模型寻找启发
  8. 使用codex编写自动对局脚本，评估策略性能
  9. 两人分开写不同的策略，要来其它组的策略，进行多次测试，不断修正对比
  10. 综合考虑工作量、稳定性和性能，确定最终版，再次编译测试
  11. 使用codex润色策略，给出指导意见
  12. 再次编译测试

头脑风暴环节

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

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

如果时间和算力都更充足，我觉得最优策略大概率会是“离线求解+在线查表”的形式：

  1. 先用大量自博弈把常见局面算出较优动作，做成策略表。
  2. 对信息不完整的部分，用概率分布维护对手可能手牌，再按期望收益选动作。
  3. 在线决策时不做太深搜索，优先查表+少量前瞻，保证响应稳定和合法。
  4. 再加一个轻量学习模块，持续从失败对局里修正评估权重。

简单说就是：离线花时间算“聪明”，在线花时间保“稳定”。

需求建模和算法设计

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

我们的策略思路是“先保底，再争优势”：

  1. 行动类型选择：
    优先选能减少损失、同时制造对手两难的行动；当局面接近时偏保守，领先时扩大优势，落后时提高进攻性。

  2. 选牌方式：
    先给每张牌一个权重（当前分值影响、后续连锁价值、被针对风险），再在候选组合里选综合分最高的方案。

  3. 编程实现：
    把流程拆成“状态解析 -> 候选动作生成 -> 动作评分 -> 合法性校验 -> 输出动作”；
    评分函数支持参数调节，配合自动对局脚本反复试验，最后选稳定性和胜率都比较好的版本。

代码可复用性与需求变更

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

复用部分：

  1. 继续使用 T2 的状态重建逻辑，先根据历史动作还原当前局面。
  2. 复用牌面索引映射和基础数据结构，避免重复造轮子。
  3. 复用输入解析与合法性检查的框架，保证输出动作格式正确。

修改部分：

  1. 在 T2 基础上新增“候选动作生成”和“动作评分”模块。
  2. 增加对不同行动类型的优先级控制，支持按局势动态切换策略。
  3. 增加自动对局评估脚本对接，方便批量测试和参数调整。

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

我在这题更偏向“先稳定再变强”：

  1. 把选动作分成几个步骤来写，这样改某一步不会把整体搞乱。
  2. 参数集中放，不要写死在代码里，调起来省事。
  3. 对局测试尽量固定条件，方便看出新旧策略到底谁更好。
  4. 多看失败局，针对经常输的点去改，比乱调有效。
  5. 保底策略要有，避免程序在异常时给出非法操作。

软件度量

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

我们主要用下面几种方式做量化：

  1. 胜率：固定局数下与基线策略对战，统计总胜率和先后手分开胜率。
  2. 稳定性：统计非法输出次数、超时次数、异常中断次数，要求尽量接近 0。
  3. 关键局面表现：抽取高风险局面做专项测试，看是否能做出合理动作。
  4. 回归表现：每次改动后跑同一套测试集，确认没有明显退步。
  5. 对不同风格对手的泛化：和保守型、激进型、随机型策略分别对战，观察是否存在明显短板。

总结

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

→ 📖 Q3.9(I) 请写下本部分的心得体会。

我这部分最深的感受是：策略不是靠“感觉”优化的，还是得靠数据。前面我们有些改动看着很聪明，结果一测不一定更强。后面做了批量对局后，才知道哪些改动是真的有用。

结对项目总结

结对过程回顾和反思

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

2eb8ebfb5acafbc36b01f380992f6129

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

回顾这次结对，整体配合比较顺畅，但还有几个可改进点：

  1. 前期可以更早统一“规则理解文档”，减少后面来回确认细节的时间。
  2. 中期可以把分工再细化，比如一人主攻实现、一人主攻测试和复盘，切换更明确。
  3. 后期可以更早接入自动评测，不要等策略基本成型后才大量跑对局。
  4. 每个阶段结束做 5 分钟小复盘，及时同步问题，会比最后集中返工更省时间。

→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。

优点：

  1. 思路很清楚，讨论题目的时候能很快抓住重点。
  2. 推进效率高，定好方案就能马上开干。
  3. 很负责，遇到 bug 不会糊弄过去，会追到原因。

缺点：

  1. 有时候上手太快，前期验证可以再多做一点。

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。

我理解的结对编程，不是一个人写另一个人看，而是两个人一直在同步想法、同步修正。

优点：

  1. 需求理解更一致，不容易各写各的。
  2. 错误能更早发现，很多问题写代码时就能拦住。
  3. 学习效率高，尤其是新语言和调试方法。

缺点：

  1. 很吃沟通，节奏没配合好会互相打断。
  2. 两个人时间要对齐，不像单人那样灵活。
  3. 分工不均的话，容易变成一个人主写、一个人旁观。

总体来说，我觉得结对在规则复杂、容易出错的任务里特别有用。

代码实现提交

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

https://github.com/KarasFlowers/BUAASE-pair-SUBMIT.git

附录

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

Personal Software Process Stages 个人软件开发流程 预估耗时（分钟） 实际耗时（分钟）
PLANNING 计划 40 50
- Estimate - 估计任务耗时 40 50
DEVELOPMENT 开发 610 700
- Analysis & Design Spec - 需求分析与设计规格 90 120
- Technical Background - 技术背景学习 80 100
- Coding Standard - 代码规范 20 20
- Design - 具体设计 90 110
- Coding - 具体编码 180 200
- Code Review - 代码复审 40 50
- Test Design - 测试设计 45 55
- Test Implement - 测试实现 65 45
REPORTING 报告 130 150
- Quality Report - 质量评估 35 40
- Size Measurement - 工作量统计 20 25
- Postmortem & Process Improvement Plan - 事后总结与改进计划 75 85
TOTAL 合计 780 900
posted @ 2026-04-11 14:04  Tanhhhhtjy  阅读(21)  评论(0)    收藏  举报