[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) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。
在规则判定模块中，可通过编码前绘制完整决策树覆盖全分支、分层隔离高/低优先级逻辑并加显式拦截、用配置化替代硬编码if-else链、补充兜底分支与全分支单元测试，系统性避免漏判、错判与分支顺序错误。

测试

→ 📖 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) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。
我认为“先写测试再实现”更适合我们这种逻辑复杂、对正确性要求高的任务，它能把需求拆解成验收标准，开发过程更稳、更可控，而另一种“先实现再补测试” 适合快速原型或逻辑简单的场景，能提升效率，但容易埋下隐患。
综合来讲，针对我们的项目，我认为核心模块优先用 TDD，可以保证底层逻辑的正确性；而简单的辅助模块可以先实现再补测试，这样既能保证质量，又能提升整体开发效率。

总结

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

→ 📖 Q1.8(I) 请写下本部分的心得体会。
这是我第一次接触并使用AS来开发功能。刚开始对这些新的语法规则有点不适应，担心会有兼容性或者写错的情况，但实际操作之后发现：规则清晰、结构严谨，只要按照需求去拆解逻辑，并没有想象中那么困难（虽然还是很困难）。通过这次开发，我对 AS 语法的书写方式、字段定义、状态判断逻辑都有了更直观的理解。虽然前期学习成本有点高，但后续的可读性、可维护性都很高，也让我学会了用更严谨的方式去处理需求。总体来说，这次体验让我对自定义语法开发有了全新的认识，也提升了逻辑拆解和代码规范的能力。

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) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。 首先我们将代码拆分成parseAction（解析单次行动）和simulate（模拟整轮）两个独立函数，这样做可以在修改解析逻辑时避免影响主循环逻辑，其次我们将牌型分值、行动类型数字定义为常量，避免硬编码，以适应游戏规则调整带来的变化（修改常量值即可）。最后，为避免非法输入对程序的负面影响，我们在每个分支入口都增加了body.length和choice.length的判断，提高了代码的健壮性。

头脑风暴环节

→ 📖 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) 请写下本部分的心得体会。 在敲代码前，我们会先一起梳理逻辑，减少了逻辑错误的发生。
当我遇到 AssemblyScript 不支持解构 这种编译器报错时，搭档立刻指出了问题所在，避免了我独自摸索的时间成本。
这种 “驾驶员 + 导航员” 的模式，强迫双方不断沟通代码逻辑，降低了沟通成本，使得代码的可读性和规范性大大提高。我在任务一其实并没有感受到太多结对编程的优势，但在任务二这类逻辑较为复杂内容较为丰富的编码过程中，我深刻的体会到了结对编程所包含的优势，相信我在之后任务三的结对过程中，能更加深深爱上这种高效的编程方式。

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) 请写下本部分的心得体会。
我以前总觉得代码能跑通、功能实现就够了，但这次在处理多轮行动、状态流转、胜负判定的过程中，确确实实的深刻体会到了冗余复杂的代码不仅可读性差，后续调试、维护的成本会高到离谱，甚至会埋下很多逻辑隐患。而精简、结构清晰、逻辑严谨的代码，不仅能大幅提升开发效率，更能从根源上减少 bug，让每一步逻辑都可控并且可追溯。

结对项目总结

结对过程回顾和反思

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

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

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

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。这次结对编程的体验，让我对协作开发有了很真实的感受。两个人一起写同一套代码，一个人敲、一个人实时盯着，能在写的过程中就发现很多自己单干时注意不到的逻辑漏洞和不规范的地方，最终出来的代码质量明显更稳，也少了很多后期再修改的麻烦。而且两个人思路互补，遇到卡壳的地方能一起讨论，比一个人闷头查资料要高效很多，还能互相学习对方的编码习惯和技巧，可以学到一些平常自己代码学不到的东西。但同时也能明显感觉到它的局限：对于一些逻辑简单、需求明确的小任务，两个人一起做反而显得拖沓，效率还不如单人开发来得高。另外如果再出现两个人的节奏、想法不一致的情况，还要沟通内耗，需要花时间磨合，反而最后拖慢了进度。综合来讲，我认为选择合适的项目来进行结对编程是很重要的，不然只会成为拖开发后腿的累赘。

代码实现提交

→ 📖 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