3.5　应用迭代式改进方法实现逐步优化

这一条考什么

考你在与 Claude Code 迭代协作时，能否选对“让结果逐步变好”的方法：文字描述解释不一致时给 2–3 个具体输入输出示例；先写测试再迭代并反馈失败用例；在陌生领域先让 Claude 采访你（interview pattern）；用带输入和期望输出的测试用例修正边界情况；以及判断多个问题是一次性在一条消息里提出（相互影响），还是逐个顺序修正（彼此独立）。

核心概念

具体输入输出示例胜过文字描述

“把日志里的时间统一成标准格式”这类描述，每次可能被理解成不同的“标准”。直接给出 2–3 对示例，转换规则就没有歧义了：

请按以下示例转换日志行中的时间戳：

输入：[03/Feb/2025:14:05:09 +0900] GET /api
输出：2025-02-03T05:05:09Z GET /api

输入：2025/2/3 2:05:09 PM JST POST /login
输出：2025-02-03T05:05:09Z POST /login

输入：1738559109 DELETE /item/9
输出：2025-02-03T05:05:09Z DELETE /item/9

示例同时传达了输出格式、时区换算规则以及“保留其余字段不变”等隐含要求。

测试驱动迭代

在实现之前先写测试套件，覆盖期望行为、边界情况和性能要求，然后让 Claude 实现，并把失败的测试输出反馈给它继续改。好处：

• “完成”的标准客观明确，不依赖反复描述；
• 每轮迭代都有可验证的进展；
• 已通过的测试防止新改动引入回归。

例如实现一个图算法时，先写好空图、单节点、非连通、有环、带权边以及“10 万节点 2 秒内完成”的测试，再让 Claude 实现，比给它一份长篇自然语言规格更有效。

采访模式（interview pattern）

在不熟悉的领域，你自己可能都不知道需要考虑什么。与其凭粗略想法直接让 Claude 实现，不如先让它向你提问：

我想给 /products 接口加 Redis 缓存，初步想法是 TTL 5 分钟。
在写任何代码之前，请先就这个需求采访我：一次问 3–5 个问题，
覆盖缓存失效策略、数据一致性要求、缓存击穿/雪崩、Redis 故障时的降级、
监控指标等我可能没想到的方面。等我回答完再给出设计。

这样能在实现前暴露“商品价格更新后缓存怎么失效”“Redis 挂了接口是否还能用”等关键设计点。

用具体测试用例修正边界情况

当生成的迁移脚本没处理好必填字段为 null 的记录时，不要笼统地说“多考虑边界情况”或要求整体重写。给出具体的输入和期望输出：

迁移脚本对以下输入处理错误，请只修正 null 处理逻辑：

输入：{"id": 17, "email": null, "created_at": "2021-03-01"}
期望：写入 users 表，email 置为 'unknown+17@invalid.local'，并记录一条 WARN 日志
实际：抛出 NOT NULL constraint failed

输入：{"id": 18, "email": "a@b.com", "created_at": null}
期望：跳过该记录，写入 migration_errors 表，reason='missing created_at'

一次提出还是逐个修正

• 相互影响的问题：放在一条详细消息里一起提出。例如报表的列宽、日期格式、分页互相牵连——改列宽会影响日期能否放下，分页取决于内容高度。分开修会出现“修好 A 又破坏 B”的循环。
• 彼此独立的问题：按顺序逐个迭代。每次只修一个、验证后再进入下一个，更容易定位哪个改动出了问题。

判断依据是修正之间是否存在耦合，而不是问题数量多少。

正确做法与反模式

• 正确：描述被不一致地解读时，给 2–3 个具体输入输出示例。反模式：继续加长文字描述，或加“请严格遵循”之类的强调。
• 正确：先写覆盖行为、边界、性能的测试，再迭代并反馈失败结果。反模式：只给自然语言规格或参考实现，凭感觉验收。
• 正确：陌生领域先用采访模式挖掘设计考虑。反模式：带着粗略想法直接让它实现，事后补漏；或写一份满是 TBD 的规格让模型自己补。
• 正确：用具体测试用例（输入 + 期望输出）修正边界情况。反模式：提示“think harder about edge cases”并要求整体重写，或自己手改后不告知 Claude。
• 正确：相互影响的问题一次性详细提出，独立问题逐个修正。反模式：把耦合的问题拆开修来回打转，或把一堆不相关问题混在一条消息里难以验证。

常见陷阱

• “要求整个重写”：看似彻底，实则丢掉已经正确的部分，还可能引入新问题；应定点修正。
• “加强语气/让它更努力思考”：不提供新信息，无法稳定改变结果。
• “先 plan mode 分析，再给需求”：在“我不知道该考虑什么”的场景中，问题不在于不了解代码，而在于需求本身不完整，采访模式更对症。
• “给参考实现让它照着改”：参考实现并不等于你的需求，测试套件才是客观标准。
• 把耦合问题判断成独立问题：题干出现“这些问题相互影响”时，要优先考虑一次性完整说明；反之若明确独立，就选逐个迭代。注意读清题干给出的关系。

实操练习

目标：用“测试先行 + 失败反馈”的循环，让 Claude 实现一个时间戳规范化函数。

1. 新建 tests/test_normalize.py，写入下面的测试（包含示例与边界情况）。
2. 让 Claude 实现 normalize.py，只允许它读写这两个文件并运行 pytest。
3. 若有失败，把失败输出原样反馈，让它只修对应问题。
4. 全部通过后，再追加一个新的边界用例（例如空字符串），重复一轮。

# tests/test_normalize.py
import pytest
from normalize import normalize_ts

@pytest.mark.parametrize("raw,expected", [
    ("[03/Feb/2025:14:05:09 +0900]", "2025-02-03T05:05:09Z"),
    ("2025/2/3 2:05:09 PM JST", "2025-02-03T05:05:09Z"),
    ("1738559109", "2025-02-03T05:05:09Z"),
])
def test_examples(raw, expected):
    assert normalize_ts(raw) == expected

def test_none_returns_none():
    assert normalize_ts(None) is None

def test_garbage_raises():
    with pytest.raises(ValueError):
        normalize_ts("not a time")

claude -p "实现 normalize.py 中的 normalize_ts，使 tests/test_normalize.py 全部通过。运行 pytest，若失败根据失败信息修正，直到通过。" \
  --allowedTools "Read,Write,Edit,Bash(pytest:*)"
pytest -q tests/test_normalize.py

检查结果：pytest 全部通过；查看 Claude 的过程，它应在失败后针对具体用例修正，而不是整体推倒重来。

自测清单

• 为什么具体的输入输出示例比文字描述更能稳定传达转换规则？
• 测试驱动迭代的测试套件应覆盖哪三类内容？
• 采访模式适合什么场景？给出两个它能帮你发现的设计考虑。
• 迁移脚本对 null 处理不当，最有效的反馈方式是什么？
• 如何判断多个问题应一次提出还是逐个修正？各举一例。