Kimi-K2.7-Code实际编程-过客

前二天月之暗面发布了专为编程而生的Kimi K2.7 Code，今天就拿它来实际编程用一下。

环境

工具：OpenCode Desktop v1.17.6
模型：Kimi-K2.7-Code
提供商：OpenCode Go订阅

需求

用go写一个微服务，统计多个游戏服务中玩家的关联性。

1. 本地已经安装配置好go 1.26环境。
1. 数据库：PostgreSQL；
1. 提供POST 接口，让游戏服务器上传数据和查询玩家关联性。
1. 游戏服务器在玩家注册帐号时上传玩家ID、服务器ID、玩家手机号、设备ID、实名标识（PI国家新闻出版署实名后的用户唯一标识）；
1. 游戏服务器在玩家登录账号是上传玩家ID、设备ID。手机号和实名标识与玩家ID一一对应，一个玩家ID可以对应多个设备号（换设备登录）；
1. 提供一个查询接口查询玩家关联性，比如输入一个玩家ID或设备号等，把所有关联的玩家ID（使用过相同的设备号、实名标识符或手机号的）的列出来。
1. 添加二个日志表，分别记录上传的注册信息和登录信息日志。

执行结果

第一轮

创建一个新的项目，将需求直接发给OpenCode，等待18分钟，初步编译通过。

先看代码简单分析一下

1. 微服务的框架及整个逻辑基本完成
1. 设计了四张表，并提供了完整的SQL创建语句。
  - Link 玩家关联信息，记一个玩家ID对应唯一的实名标识和手机号
  - Device 玩家设备关联，一个玩家ID可以对应多个设备号
  - 还有二个日志表
1. 三个post接口，注册数据上传、登录数据上传及查询接口，关联查询使用了SQL语句完成。

WITH seeds AS (

-- 根据 player_id 或 device_id 找到种子玩家及其设备/实名标识/手机号

SELECT DISTINCT d.player_id, d.device_id, l.card_pi, l.phone

FROM player_device d

JOIN player_link l ON l.player_id = d.player_id

WHERE ($1 <> '' AND d.player_id = $1)

   OR ($2 <> '' AND d.device_id = $2)

UNION

-- 兼容仅有 player_link 没有设备的玩家

SELECT l.player_id, ''::varchar AS device_id, l.card_pi, l.phone

FROM player_link l

WHERE $1 <> '' AND l.player_id = $1

)

SELECT DISTINCT d.player_id

FROM player_device d

JOIN seeds s ON s.device_id <> '' AND d.device_id = s.device_id

WHERE d.player_id <> s.player_id

UNION

SELECT DISTINCT l.player_id

FROM player_link l

JOIN seeds s ON (s.card_pi <> '' AND l.card_pi = s.card_pi)

             OR (s.phone <> '' AND l.phone = s.phone)

WHERE l.player_id <> s.player_id

理解偏差

1. 查询把所有关联的玩家ID，这个理解有问题，我想要的所有相关的账号，它只做了一轮查询，并没有递归，这样查询的结果并不完整，如下面逻辑只放回了第一层。
- a.device_id = b.device_id, b.card_pi = c.card_pi, c.phone = d.phone。输入a的id，返回 b、c、d 的ID
- a.device_id = b.device_id, b.card_pi = c.card_pi, c.device = d.device, d.card_pi = e.card_pi。输入a的deviceid,返回 a、b、c、d、e的ID
1. 查询接口说的是比如输入一个玩家ID或设备号等，它忽略了我的等，我想要的是玩家ID、设备号、实名标识、手机号四个常数任意一个就可以查询出所有关联的，它只写了我说的玩家ID、设备号二个。这可能是我描述不清楚，不知道他不理解我的等。

第二轮

分别将上面二个理解偏差修正后再发给OpenCode，经过2~3分钟，把问题修复了。依然是用SQL语句实现查询，改成了 PostgreSQL 递归 CTE，支持传递闭包，将所有的工作全丢给了PostgreSQL处理。

这次看代码逻辑上没问题了，编译运行测试，基本功能也实现了。

性能分析

功能上没问题了，但性能上可能存在一些问题。

递归 CTE 每次迭代的代价：对 related 中的每条新记录做 3 组 JOIN（device×2 + link×2×2），数据量大时会有以下风险：

风险	说明
迭代次数	关联链越长，迭代越多，最坏 O(V) 轮
扇出爆炸	一个热门 device 可能有上千玩家，一跳就能扩散巨大
UNION 去重	每轮都要对 3 路递归结果做 UNION 去重
自连接代价	`player_device` 自连接 (d1→d2) 是主要开销

现有索引覆盖了所有 JOIN 路径，对百万级数据通常没问题。但如果存在超大连通分量（如遇到工作室机刷等设备关联数千玩家），查询可能变慢。

第三轮

将可能存在的性能问题丢给OpenCode，它给我提供了二种解决办法。

在SQL语句添加深度限制，防止递归失控。最终完整的SQL语句：

WITH RECURSIVE related(player_id, depth) AS (
	-- 种子1：根据 player_id
	SELECT player_id, 1
	FROM player_link
	WHERE $1 <> '' AND player_id = $1

	UNION

	-- 种子2：根据 device_id 找到所有使用该设备的玩家
	SELECT player_id, 1
	FROM player_device
	WHERE $2 <> '' AND device_id = $2

	UNION

	-- 种子3：根据 card_pi 找到所有玩家
	SELECT player_id, 1
	FROM player_link
	WHERE $3 <> '' AND card_pi = $3

	UNION

	-- 种子4：根据 phone 找到所有玩家
	SELECT player_id, 1
	FROM player_link
	WHERE $4 <> '' AND phone = $4

	UNION

	-- 通过相同设备号扩展
	SELECT d2.player_id, r.depth + 1
	FROM related r
	JOIN player_device d1 ON d1.player_id = r.player_id
	JOIN player_device d2 ON d2.device_id = d1.device_id
	                  AND d2.player_id <> d1.player_id
	WHERE r.depth < 10

	UNION

	-- 通过相同实名标识扩展
	SELECT l2.player_id, r.depth + 1
	FROM related r
	JOIN player_link l1 ON l1.player_id = r.player_id
	JOIN player_link l2 ON l2.card_pi = l1.card_pi
	                  AND l2.card_pi <> ''
	                  AND l2.player_id <> l1.player_id
	WHERE r.depth < 10

	UNION

	-- 通过相同手机号扩展
	SELECT l2.player_id, r.depth + 1
	FROM related r
	JOIN player_link l1 ON l1.player_id = r.player_id
	JOIN player_link l2 ON l2.phone = l1.phone
	                  AND l2.phone <> ''
	                  AND l2.player_id <> l1.player_id
	WHERE r.depth < 10
)
SELECT DISTINCT player_id
FROM related
WHERE ($1 = '' OR player_id <> $1)

添加应用层逻辑处理

添加应用层处理方法QueryAssociationBFS，每层只发3条简单 SQL（用ANY数组参数），避免递归 CTE 的自JOIN开销，且可在代码中控制深度、日志、超时。然后封装了一个自动切换的逻辑

QueryAssociation(ctx, playerId, deviceId, cardId, phone)
  ├── 1. 先尝试 queryAssociationCTE（3秒超时）
  │     ├ 成功 → 直接返回
  │     └ 超时 → 降级
  └── 2. 降级到 queryAssociationBFS（逐步查询，可控）

总结

Kimi K2.7 Code 模型，整体体验优秀：理解需求快、代码结构完整、迭代迅速，SQL优化和fallback方案体现较强工程意识。适合快速原型开发，复杂场景仍需人工 review 性能与边界。总用时极短，效率很高，可用于实际编程中的一款模型。

PS：Kimi K2.7 Code写代码1小时，人工审核3小时，现在还是不太放心AI写完就不管，还是要手动过一篇才安心。

目录CONTENT

Kimi-K2.7-Code实际编程

环境

需求