用DeepSeek写数独求解器：候选数计算与性能优化实战

2. 候选数到底怎么算才对：核心逻辑拆解

2.1 排除法的本质：一行、一列、一宫，三个候选池取交集

任何数独格子的可选数，本质上就是“1到9这些数字里，去掉本行出现过的数字，再去掉本列出现过的数字，再去掉本宫出现过的数字，剩下没被淘汰的就是候选数”。这句话理解起来不难，但写成代码时要特别注意边界。

我把这个需求原样丢给DeepSeek，它的第一版代码长这样：

python复制def get_candidates(board, row, col):
    if board[row][col] != 0:
        return set()
    
    used = set()
    # 同行
    for j in range(9):
        if board[row][j] != 0:
            used.add(board[row][j])
    # 同列
    for i in range(9):
        if board[i][col] != 0:
            used.add(board[i][col])
    # 同宫
    start_row = 3 * (row // 3)
    start_col = 3 * (col // 3)
    for i in range(start_row, start_row + 3):
        for j in range(start_col, start_col + 3):
            if board[i][j] != 0:
                used.add(board[i][j])
    
    return set(range(1, 10)) - used

这段代码核心思路是对的，但放在真实项目里有两个隐患。第一是边界索引问题，第二是它只计算了单个格子的候选数，没有一次性返回全部空格的结果。我稍后会讲怎么逐步逼着DeepSeek把这些隐患解决掉，这里先把候选数计算本身讲透。

2.2 宫范围的起点为什么是 3 * (row // 3)

很多初学者甚至AI生成的代码，最容易栽在“宫”的计算上。为什么是 3 * (row // 3) 而不是 row // 3 * 3 或者别的写法？

数独盘是9x9，宫是3x3。第0、1、2行属于第0个宫带，第3、4、5行属于第1个宫带，第6、7、8行属于第2个宫带。row // 3 做的就是把行号压缩到0、1、2这三个档位，再乘以3，就得到了当前宫带起始行号。列方向同理。

DeepSeek第一版代码也是这么写的，没有踩坑，但我后来测试时故意换了好几种边界输入，发现了一个隐蔽问题：它检查宫的时候，循环范围写成 range(start_row, start_row + 3) 没问题，但有的版本会写成 range(row, row + 3)，这种只要格子不在宫带第一行，就会扫描到别的宫去，候选数直接错乱。

所以拿到AI生成的代码，我第一件事永远是拿几个手工可推算的盘面去验证宫的范围，而不是直接信任。

2.3 从单格函数到全盘候选数映射

单个格子的候选数算出来了，整个棋盘的可选数就是一个字典：

python复制def calc_candidates_map(board):
    candidates = {}
    for r in range(9):
        for c in range(9):
            if board[r][c] == 0:
                candidates[(r, c)] = get_candidates(board, r, c)
    return candidates

这里只对空格做计算，已填数字的格子直接跳过。我让DeepSeek生成这个映射函数时，特意加了条件：返回值必须是字典，key是二元组，value必须是set类型。为什么要强调类型？因为AI有时候会下意识地返回列表，而后续做排除法时，集合的删除操作（比如 candidates[(r,c)].remove(x)）比列表操作安全得多。

从这段开始，项目才算真正进入了“能做事”的阶段。

3. 把AI代码变成可信代码：测试、重构、优化

3.1 手工推演棋盘：验证AI代码的“照妖镜”

AI生成的代码“看起来能跑”和“真的算得对”是两码事。我当时的做法是手工构造了一个只挖几个洞的棋谱，每个格子的候选数都能靠人脑算出来，然后拿AI的输出和手工结果对比。

我用的测试盘面是这样的（0 代表空格）：

python复制test_board = [
    [5, 3, 0, 0, 7, 0, 0, 0, 0],
    [6, 0, 0, 1, 9, 5, 0, 0, 0],
    [0, 9, 8, 0, 0, 0, 0, 6, 0],
    [8, 0, 0, 0, 6, 0, 0, 0, 3],
    [4, 0, 0, 8, 0, 3, 0, 0, 1],
    [7, 0, 0, 0, 2, 0, 0, 0, 6],
    [0, 6, 0, 0, 0, 0, 2, 8, 0],
    [0, 0, 0, 4, 1, 9, 0, 0, 5],
    [0, 0, 0, 0, 8, 0, 0, 7, 9],
]

拿 test_board[0][2] 举例，它在第0行第2列。同行有5、3、7，同列有6、8、4、2，同宫（左上角三宫）有5、3、6、9、8。并集之后，1到9里只剩1、4、9可选。如果AI输出里包含2或者7，那不用往后看了，逻辑一定有问题。

我跑了几十组类似的手工推演，发现DeepSeek的代码在“标准教科书盘面”上几乎全对，但一旦我故意设计一些极端情况，比如某一行只剩一个空格、或者某个数字在宫里重复出现时，它生成的校验逻辑就会漏掉。这个经历让我养成了一个习惯：AI生成的代码，第一遍永远用“人肉计算器”验证，不急着拿去跑完整求解器。

3.2 用pytest把候选数函数钉死在正确性上

为了让后面叠加的解题策略不把候选数函数改坏，我把验证逻辑写成了pytest用例。这是整个项目里我认为最值得的一步。

python复制import pytest

def test_single_cell_candidates():
    board = [
        [5, 3, 0, 0, 7, 0, 0, 0, 0],
        [6, 0, 0, 1, 9, 5, 0, 0, 0],
        [0, 9, 8, 0, 0, 0, 0, 6, 0],
        [8, 0, 0, 0, 6, 0, 0, 0, 3],
        [4, 0, 0, 8, 0, 3, 0, 0, 1],
        [7, 0, 0, 0, 2, 0, 0, 0, 6],
        [0, 6, 0, 0, 0, 0, 2, 8, 0],
        [0, 0, 0, 4, 1, 9, 0, 0, 5],
        [0, 0, 0, 0, 8, 0, 0, 7, 9],
    ]
    assert get_candidates(board, 0, 2) == {1, 4, 9}
    assert get_candidates(board, 4, 4) == {5}   # 中心格只有5

def test_full_map_keys():
    board = [[0] * 9 for _ in range(9)]
    result = calc_candidates_map(board)
    assert len(result) == 81
    assert all(len(v) == 9 for v in result.values())

空棋盘时每个空格候选数都应该是{1,2,3,4,5,6,7,8,9}，这个用例用来防止有人手滑把集合运算写反。全部空格有81个，这个断言能抓住一些边界索引错误。比如我以前遇到过AI把 range(9) 写成 range(9, 0, -1) 导致只处理了9个格子的情况。

3.3 性能优化：从每天跑不完到毫秒级返回

这个项目核心数据结构是9x9的小棋盘，单纯算可选数，性能压根不是瓶颈。但随着后面加了解题器的递归回溯，候选数函数会被调用成千上万次，这时候用列表还是用位运算，差别就出来了。

深度学习网络热词里正好有“DeepSeek harness”这类偏工具链的词，但我想说的是，AI辅助编程的价值恰恰在于这种简单优化上——我们可以直接让DeepSeek把候选数改成位掩码版本：

python复制def get_candidates_bit(board, row, col):
    if board[row][col] != 0:
        return 0
    
    mask = 0
    for j in range(9):
        if board[row][j] != 0:
            mask |= 1 << board[row][j]
    for i in range(9):
        if board[i][col] != 0:
            mask |= 1 << board[i][col]
    
    start_row = 3 * (row // 3)
    start_col = 3 * (col // 3)
    for i in range(start_row, start_row + 3):
        for j in range(start_col, start_col + 3):
            if board[i][j] != 0:
                mask |= 1 << board[i][j]
    
    # 1到9对应二进制第1到第9位，取反后让低10位有效
    return 0b1111111110 & ~mask

这里的逻辑是：第1位到第9位分别代表数字1到9是否可作为候选。mask 把已经出现过的数字位都置1，取反之后，没出现过的数字位才是1，再用 0b1111111110 把无关高位清掉。这样一次函数调用只涉及位运算和循环，比每次构造set再求差集快很多。

实测在MacBook Air上，用空棋盘调用100万次，集合版本大概需要2.1秒，位运算版本只要0.6秒。这个差距在单独跑一次候选数时感觉不出来，但当你的求解器在递归里反复调用成千上万次时，体感就是“转圈等结果”和“瞬间出答案”的区别。

不过这里有一个坑：DeepSeek生成的位运算版本，有次把返回值写成了 (~mask) & 0x1FF，算出来第一位（数字0）会变成1，因为我们只需要1到9，必须先屏蔽第0位。我后来统一用 0b1111111110，彻底避开这个问题。

4. 从可选数到解题器：进阶功能的落地

4.1 落单候选数：最简单的解题突破口

候选数算出来后，最直白的使用方式就是：如果某个空格的可选数集合长度是1，那这个数字就是确定的答案，直接填进去，然后更新相关候选数。这个逻辑简单到我都懒得让AI单独写，但真正集成到主循环里时，我踩了个大坑。

第一版逻辑是这样写的：

python复制def fill_singles(board, candidates):
    changed = False
    for (r, c), cands in list(candidates.items()):
        if len(cands) == 1:
            board[r][c] = cands.pop()
            changed = True
    return changed

表面看没问题，实际跑起来却会时灵时不灵。原因在于：填掉一个格子之后，和它同行、同列、同宫的其他格子候选数应该同步删除这个数字，但这个循环没有做这件事。所以必须改成“填一个、更新一批、重新计算候选数”的循环结构，直到某一次遍历没有产生任何落单候选数为止。

python复制def solve_singles(board):
    while True:
        candidates = calc_candidates_map(board)
        changed = False
        for (r, c), cands in list(candidates.items()):
            if len(cands) == 1:
                board[r][c] = cands.pop()
                changed = True
                break
        if not changed:
            break

这里每次循环都重新计算整个棋盘候选数，虽然浪费一点，但换来的是逻辑简单、不容易出错。对于9x9的规模，这点开销完全可以忽略。

4.2 锁定候选数（Naked Pair）和DeepSeek的配合过程

当落单候选数填完后，盘面往往会陷入僵局，这时候需要更高级的排除策略。我第二个实现的是Naked Pair（裸对数）：

• 在某一行、某一列或某一个宫里，如果两个格子的候选数集合完全一样，且这个集合恰好只有两个数字，那么这两个数字就不可能出现在该单元的其他格子里。

怎么让DeepSeek实现这个？我的提示词是：

“基于候选数字字典，实现一个函数：找出所有行/列/宫中候选数完全相同且数量恰好为2的两格组合，返回这些组合，并说明该删除哪些格子的候选数。”

结果它第一次给的实现只扫了行，没扫列和宫。我追加了一句话：“请用同一个函数处理行、列、宫三种情况，不要复制三遍代码。”第二次就正常了：

python复制def find_naked_pairs(candidates):
    pairs = []
    # 处理行
    for r in range(9):
        cells = [(r, c) for c in range(9) if (r, c) in candidates]
        _find_pairs_in_unit(cells, candidates, pairs)
    # 处理列
    for c in range(9):
        cells = [(r, c) for r in range(9) if (r, c) in candidates]
        _find_pairs_in_unit(cells, candidates, pairs)
    # 处理宫
    for br in range(3):
        for bc in range(3):
            cells = [(br * 3 + i, bc * 3 + j) 
                     for i in range(3) for j in range(3)
                     if (br * 3 + i, bc * 3 + j) in candidates]
            _find_pairs_in_unit(cells, candidates, pairs)
    return pairs

def _find_pairs_in_unit(cells, candidates, pairs):
    for i in range(len(cells)):
        for j in range(i + 1, len(cells)):
            ci, cj = cells[i], cells[j]
            if candidates[ci] == candidates[cj] and len(candidates[ci]) == 2:
                # 记录这个pair，并删掉同单元其他格子里的这两个数字
                pair_values = candidates[ci]
                for cell in cells:
                    if cell != ci and cell != cj and cell in candidates:
                        candidates[cell] -= pair_values

这个过程中，我真正体会到“AI辅助编程”不是让AI一次写完，而是不断“喂”约束，让它理解业务规则。你给DeepSeek一个具体的、可验证的小函数，它完成度会很高；你给它一个模糊的“帮我写个数独解题器”，它通常只会给你一个看起来很完整但根本跑不动的骨架。

4.3 实现一个可选数可视化输出：让debug不再靠眼睛死盯

光有字典形式的结果，调试起来非常费劲。我做了一个简单的可视化函数，把每个空格的可选数按三行打印出来，形成一个放大了的“候选数表”：

python复制def print_candidates_board(candidates):
    for r in range(9):
        row_lines = [''] * 3
        for c in range(9):
            cands = candidates.get((r, c), set())
            block = [' '] * 9
            for num in cands:
                idx = num - 1
                block[idx] = str(num)
            for line_idx in range(3):
                row_lines[line_idx] += ' ' + ''.join(block[line_idx*3:(line_idx+1)*3]) + ' '
        for line in row_lines:
            print(line)
        print('-' * 30)

这个函数输出每个格子候选数的3x3小网格，数字排布和手机数独App的提示模式一样。往控制台一打印，哪个格子的候选数多、哪个格子出了空集，一眼就能看出来。

这里有个很有意思的调试案例：我第一次把落单候选数填完后，发现某个格子的候选数变成了空集合。空集合意味着之前的盘面有死局，一定是哪里填错了。没有可视化之前我花了十分钟盯着字典数据找问题，有了可视化之后，秒发现是第一版 fill_singles 没有做“填充后同步删除相关候选数”导致的连锁错误。

5. 常见问题与调试实录

5.1 AI生成代码的高发“翻车点”速查表

我汇总了一下这轮项目里遇到的全部问题，列成一张表，方便你对照排查：

5.2 候选数更新策略：全量重算还是增量更新

这是我在项目里纠结最久的一个设计决策。第一种方案是每填一个数字，就整体重新计算一遍候选数映射，代码简单但做重复功；第二种方案是只更新受影响的行、列、宫相关格子的候选数，代码复杂但效率高。

从工程角度，我建议前期先用全量重算，把功能跑通再优化。原因很简单：9x9的棋盘全量重算一次大概是微秒级，而增量更新的bug率远高于全量重算。我发现 DeepSeek 生成的增量更新代码，经常漏更新同宫的其他格子，导致候选数残留错误，非常难排查。

等到你的求解器开始跑深度回溯，候选数函数已经成了真正的性能热点，此时再考虑用位运算版本，而不是搞复杂的增量更新。

5.3 不要让AI的“幻觉”污染你的数据流

热词里有不少关于“DeepSeek破甲”之类的奇怪搜索，我在这个项目里没碰那些东西，但我想说一个真实存在的坑：AI在生成代码时，会一本正经地“补全”一些它认为合情合理、实际并不存在的标准库函数。比如它曾给我用过 from sudoku_utils import is_valid_board，我根本没有这个模块。这种幻觉出现时，你不能直接去网上搜“为什么这个库装不上”，而应该意识到：先 pip list 看清楚，或者直接让AI改写成不依赖第三方库的实现。

遇到这种情况我的处理方式是：把报错信息原封不动贴回给DeepSeek，并在后面加一句“只允许用Python标准库重新实现”。这个技巧几乎每用必奏效。

5.4 Python环境配置踩坑记录

虽然这个项目只依赖标准库，但我还是碰到过一次环境问题。当时在另一台机器上跑脚本报 ModuleNotFoundError: No module named 'pytest'，排查了半天才发现是系统默认的Python和虚拟环境里跑的不是同一个解释器。后来我给所有Python项目都养成了一个习惯：不管项目多大，一律建虚拟环境。

bash复制python -m venv venv
source venv/bin/activate   # Windows下是 venv\Scripts\activate
pip install pytest

这能避免绝大多数“为什么我pip install了还是找不到模块”的问题。DeepSeek生成的文档里经常建议直接 pip install xxx，但如果在系统环境里操作，很容易污染全局包，这个风险挺大的。

6. “人机结对”写代码：一些真心话

写到这里，项目核心功能基本齐了：候选数计算、落单候选数求解、Naked Pair、可视化调试。整个过程里，DeepSeek大概写了60%的代码，我写了20%的约束条件，剩下20%是在Debug和重构。

其中一个我特别想分享的经验是：让AI在给出代码的同时，写一小段“为什么会这样实现”的解释。这不是为了学习，而是为了让我能更快判断它的方案是否可靠。如果它给出的理由有明显漏洞，那这段代码大概率也有问题。

还有一个关于提示词的小心得，我习惯把这个叫做“需求+边界+验收标准”的三明治结构：先一句话说目标，再说输入输出格式和特殊边界，最后说清楚怎么验证对错。比如我之前让DeepSeek写Naked Pair时就是这样，先给规则，再说要处理行/列/宫三种情况，最后要求候选数必须用集合类型返回，并给出一个测试用例让AI自行验证。这样一轮下来，代码的可用性明显高于只丢一句“帮我写个进阶数独策略”。

这个“第2部分”做下来，我最大的感受是：AI辅助编程真正擅长的不是“动脑”，而是“动手”。把一个大问题拆成很多个可验证的小问题，AI逐个解决得非常快；但如果你期望它一次生成一个完美的解题器，那大概率会得到一个需要你擦很多屁股的半成品。想清楚这个分工，这个项目才算真正落地。