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

结对项目：博客问题清单

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

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

kimi agent生成了T1的测试用例；
主要借助Gemini在前期辅助排查并解决了 Node.js 与 Wasm 的环境编译报错。 用AI对T2进行逻辑梳理、代码纠错、函数结构优化以及问题定位，帮助我们快速排查 calcCurrentState 中的计数错误、回合归属问题和操作逻辑错误。使用范围覆盖逻辑修正、测试问题分析、报告思路提供，全程以 AI 辅助思考与优化为主，未直接调用任何模型接口。辅助生成了T3的AssemblyScript代码框架，并协助将“价值贪心策略”转化为具体的代码逻辑。

Chapter.0 wasm从安装到入门

引入

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

2026年4月3日 14:30

调查

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

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

I. 没有听说过；

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

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

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

答： I.

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

I. 不了解玩法和规则；

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

答： I.

总结

→ 📖 Q0.3(P) 请记录下目前的时间。
2026年4月3日 15:45（完成环境搭建与Guide阅读）

Chapter.1 七色之缨

结对过程

→ 📖 Q1.1(P) 请记录下目前的时间。
2026年4月5日 1:20

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

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
   我们三人首先一起阅读了任务文档，确认了T1的核心目标是实现胜负判定逻辑。由于规则逻辑看起来比较直接，我们估计总耗时约60-90分钟，其中编码30分钟，测试与调试30分钟，文档记录30分钟。
2. 完成编程任务期间，依次做了什么（例如查阅了哪些资料、如何设计判定逻辑、如何设计测试样例、遇到了什么问题、如何解决）。
   由于T1比较简单，所以过程也比较简单。逐条分析胜负判定规则，成员A在VS Code中编写AssemblyScript代码，使用大模型辅助生成了第一版。成员B和C站在远程实时审查、反馈。

设计

→ 📖 Q1.3(P) 请说明你们为这个判定模块设计了哪些中间量或辅助函数；如果没有额外设计，也请说明为什么认为直接实现已经足够清晰。
我们设计了三个核心辅助函数，将主逻辑拆解为可复用的单元：

1. calculateScore(board, player)：计算某方当前总分。将board数组与SCORES常量表映射求和，避免在主函数中写循环逻辑。
2. calculateCount(board, player)：统计某方拥有的标记数量。用于判定"4标记胜利"条件。
3. getHighestTier(board, player)：获取某方拥有的最高档位标记（返回3/2/1/0/-1）。这是为了处理第三轮平局时的档位比较，将角色映射到档位再比较。

设计理由：虽然T1逻辑相对简单可以直接写一个大的if-else块，但考虑到T2/T3会复用这些计算逻辑（比如T3的AI需要评估当前分数），我们提前做了模块化。此外，辅助函数让单元测试更容易——我们可以单独测试分数计算是否正确，而不需要走完整的判定流程。

→ 📖 Q1.4(I) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。
成员A（编码者）视角：
先把所有判断情况都梳理完整，画好决策树保证没有遗漏。代码里把立即胜利条件和第三轮特殊判定分开处理，加了判断拦截，避免提前触发第三轮逻辑。档位优先级用常量数组设定，不写死固定判断，后续改规则只需要调配置，不用动核心代码。

测试

→ 📖 Q1.5(P) 请说明你们设计了哪些测试用例，这些测试分别覆盖了哪一类规则或边界情况。
我们将测试分为三大类别、八个关键场景，覆盖所有判定分支：

一、立即胜利条件（任意小轮有效）

1. 11分边界测试：覆盖"正好11分"（G+F+A=5+4+2）和"超过11分"，验证分值计算正确性
2. 4标记基础测试：覆盖获得4个标记但总分<11分的情况（如A+B+C+D=9分）
3. 优先级冲突测试：关键测试"11分优先于4标记"——当一方满足4标记（8分）而对方满足11分（12分）时，验证11分规则优先

二、小轮继续判定（第1、2轮）
4. 非终局状态：覆盖3标记10分、2标记6分等未达到胜利条件的情况，验证返回0（继续游戏）

三、第三小轮最终判定
5. 总分决胜：覆盖双方总分差异（如6分vs5分），验证高分获胜
6. 档位决胜层级：

• 双方有G（档3）vs无G
• 双方都有G时比较F（档2）
• 双方都有G、F时比较D/E（档1）
• 验证"同分档高者胜"（如D+E=6分档1 vs A+B+C=6分档0，后者胜）

7. 平局判定：覆盖"同分同档无法区分"（如A vs B都是2分档0），以及"双方零标记"的极端情况

边界特殊情况
8. 跨轮次一致性：验证同一board状态在第1轮返回0（继续），在第3轮返回1/-1/2（终局判定），确保轮次参数正确处理

→ 📖 Q1.6(I) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。
在实际工程里，这两种方式并非完全对立，而是要根据场景灵活选择。像T1这样规则明确、输入输出边界清晰的模块，优先先写测试最为高效，测试用例能直接帮我们确定代码框架；如果遇到陌生语法环境或算法调优不确定的情况，先把核心流程跑通，再快速补全边缘测试的混合方式，会更贴合实际、也能兼顾项目进度。

总结

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

→ 📖 Q1.8(I) 请写下本部分的心得体会。
这次T1模块的开发让我颇有收获，核心难点在于把游戏的自然语言规则精准转换成程序逻辑，我们通过设计分值表、档位表常量数组，将数据映射与逻辑判断解耦，既避免了代码臃肿，也大幅提升了可读性与可扩展性。同时项目初期的协作也让我深有反思，初次接触AS和Wasm工具链，我们因缺少统一的环境配置标准，浪费了大量时间处理配置问题；而先编码、后补测的方式，也让我们在边界判定上出现疏漏，这让我深刻明白，面对规则明确的模块，先写测试用例再写代码，才是保障逻辑准确、避免错判漏判的最优做法。

Chapter.2 不祥之影

准备

→ 📖 Q2.1(P) 请记录下目前的时间。
2026年4月8日 16:00

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

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
   在对任务二的大致要求进行阅读后，基本明确任务二的主体，我们预估需求分析与设计需要0.5小时，通过结对编程实现编码需要1小时，调试与修复报错需要0.5小时，文档整理与总结需要0.5小时，总计预估2.5小时

2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
   首先通读游戏规则，重点了解分析了竞争与赠送行动的牌数分配和实现逻辑，在过程中，我们采用1人编写代码，另外两人负责审查以及思路的指引的”结对“组合方式，既有效保证了代码的编写效率，同时确保代码逻辑与语法完全合规。过程中我们遇到一个逻辑问题：即竞争的分组形式是否应该有多个条件分支来满足不同的排列组合情况，最后发现输入中要求已经规定明确了，我们在研讨如何以最少代码实现多余情况浪费了一些时间，好在最后发现不需要考虑此类问题。

代码可复用性与需求变更

→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑‍💻 T1 中已实现的代码进行了哪些复用和修改。
我们在实现胜负判定函数时，复用了 T1 中的字符索引转换（charToIdx）和数组结构定义；但业务逻辑、参数、返回值及遍历方式完全重写，并删除了无需的行动解析代码。

→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。 在 T2 的编码过程中，我们为了让代码后续更好改、更稳定，用了三种实用的写法思路：我们把代码按功能拆成了两个独立函数，分别负责解析行动和模拟状态，互不影响，后期改逻辑也更方便；没有把数值直接写死在代码里，而是统一设成常量，后续调整规则只需要改一处就行；还在代码里加了输入校验，防止异常数据导致程序崩溃，让整体运行更可靠。

头脑风暴环节

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

我们终于快要开始让程序玩游戏了！请尝试分析：T2 中不带 X 的操作记录比起实际对局多出了多少信息？如果加上 X，也就是失去了这部分信息的话，如何处理对小轮结束后状态的估计？ T2的输入是全知视角的，相比实际对局，T2多出了对手内部决策的细节，以及弃置牌的具体内容。我们认为如果加上X后，我们需要大量的数据来维护一个手牌概率分布表，通过已知的行动记录，反向推导出未知牌的可能分布，从而对小轮结束后的状态作出概率性的估计。

总结

→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录 A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2026年4月8日 17:30

→ 📖 Q2.7(I) 请写下本部分的心得体会。 在T2的开发中，结对编程给了我很大的收获。我们先梳理好逻辑再写代码，大幅减少了错误，避免了后期返工；搭档之间能实时纠错、互补技术短板，快速解决了AssemblyScript的语法问题，节省了大量时间。我们采用驾驶员与导航员的协作模式，全程沟通逻辑、双重校验代码，让代码更规范易读。原本在T1时我没觉得结对编程有明显优势，但面对T2复杂的逻辑处理，这种双大脑协作模式高效又省心，大大提升了交付质量，也让我对这种开发方式有了全新的认可，很期待在后续的开发中继续使用。

Chapter.3 道途之荆

准备

→ 📖 Q3.1(P) 请记录下目前的时间。
2026年4月8日 17:40

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

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
   由于前期已在当前工作机上顺利完成了 T1 和 T2，底层环境已打通，且大量解析逻辑可直接复用，因此预估 T3 核心开发耗时将为 180 分钟（算法设计 90 分钟，本地联调测试 90 分钟）。
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
   在接口对接与逻辑设计上，我们查阅了 T2 的状态推演接口，然后决定在此基础上叠加基于卡牌价值的贪心逻辑。1.0时我们用If-Else写死规则，不考虑输赢，随后迭代出2.0价值权重优先算法。最后将编译好的 .wasm 产物放入裁判引擎进行多次自我对局验证。

头脑风暴环节

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

假设提供更充裕的时间和资源，这个游戏中你能找到的最优策略有可能是什么形式的？进行调研并总结分析。你还可以在任务结束后试着实现（不计分）。
经过我们的讨论与ai求证，若算力与时间完全充裕，本游戏的最优解应是蒙特卡洛树搜索与反事实遗憾最小化的结合。
分析：花见小路开局会悄悄藏 1 张废牌，大家都摸不清完整牌况。程序靠强推演能力，每次做决定前，先算出手牌所有可能的分布概率，再模拟几万遍后续对局。最后对比各种打法的平均赢率，选出既能让自己收益最大、又能压低对手收益的最佳打法。

需求建模和算法设计

→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么选择行动类型？选牌如何更优？如何编程实现。
受算力和开发周期限制，我们用兼顾效率与准确度的贪心简易策略：

1. 给7类角色卡定固定价值分；
2. 主动操作：藏最高分牌当底牌，弃最低分无用牌；高低分牌捆绑搭配，引诱对手拿走弱势牌；
3. 应对对手操作：直接算分值，选当下最优选项。

代码可复用性与需求变更

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

1. 复用T2的状态解析逻辑：直接沿用动作序列拆分规则，通过数组长度奇偶性区分我方历史动作，彻底避免重复行动的报错；
2. 复用T1的价值核算逻辑：直接使用T1定义的角色分值、档位常量，作为T3弃牌、留牌的判断依据。
   → 📖 Q3.6(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
   我们把卡牌分数单独放在一个函数里，调整分数只改这一处就行，不用动主程序；还做了防崩溃兜底，就算程序出错，也能返回合法动作，不会直接被判负。

软件度量

→ 📖 Q3.7(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块决策能力很强？”，尝试提出一些可能的定量分析方式或测试方式。
性能测试通过日志统计耗时，当前算法平均仅需0.5毫秒，远低于2000毫秒的时限要求，运行速度极快；基准测试让新版2.0贪心算法和旧版1.0算法反复对战，新版胜率碾压旧版，证明优化效果显著；对称测试让两个相同的2.0程序互相对局，频繁打出平局，验证了算法逻辑严谨、不会出现随机失误。

总结

→ 📖 Q3.8(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2026年4月9日 21:20
→ 📖 Q3.9(I) 请写下本部分的心得体会。
靠着T1、T2打下的扎实基础再开发T3，我真切感受到前期把代码拆分清楚、做好复用有多省心。T2已经把复杂的对局记录和状态都梳理明白了，我做T3时就能专心优化出牌策略。同时本地调试也让我明白，在这种复杂对战里，一套稳定不出错、能正常运行的基础框架，远比理论很强却容易超时崩溃的花哨算法更有用。

结对项目总结

结对过程回顾和反思

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

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

1. 时间预估不准、未留缓冲，导致进度拖慢。改进：后续细化预估并增加缓冲时间。
2. 远程口头沟通易出错，频繁核对规则打断开发。改进：改用书面要点+示意图，减少沟通偏差。
3. 缺少小节点即时复盘，小问题累积返工。改进：完成小模块立即快速复盘。
4. 三人结对角色冗余、效率低。改进：明确分工、各司其职，避免多人同时干预编码。
   → 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
   优点：愿意听取意见，能力强，不会推卸责任；缺点：没有第一时间同步想法。

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。这次通过远程视频、全程共用一台电脑的三人结对经历，让我对结对编程有了更全面的认识。优点被明显放大：三双眼睛实时同步审查代码，在T2复杂状态推演中大幅减少了事后调试；设计T3决策AI时，多人远程讨论碰撞出了更多优质博弈策略。但也暴露出问题：人效比极低，第三人常只能远程旁观造成资源浪费；且远程沟通成本更高，分歧时决策链条过长，易陷入无意义争论。我深刻体会到，结对编程本质是用短期效率换长期质量，核心是要有明确的角色分工和轮换机制。未来简单任务适合分头开发，但T2、T3这类高风险高复杂度的核心模块，即便远程沟通成本高，结对编程仍是保证代码质量的最优选择。

代码实现提交

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

https://github.com/Meiy800015/hanamikoji-team/tree/master

附录

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

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