Claude Code 把自然语言交互带进终端：开发者可以直接描述要创建的功能、遇到的异常和期望行为，让它结合项目文件、测试结果与命令输出协助编写和调试 Python。它的价值不只是生成代码，更在于缩短“阅读代码、复现问题、修改实现、运行验证”这一整条反馈链路。
从一个可验证的小项目开始
使用编码助手时，任务边界越清楚，结果越容易验证。与其只说“写一个 Python 程序”，不如给出输入、输出、异常规则和测试要求。
可以这样实践：先创建一个带测试的最小项目。
mkdir claude-python-demo
cd claude-python-demo
python -m venv .venv
source .venv/bin/activate
python -m pip install pytest
cat > calculator.py <<'PY'
def divide(a: float, b: float) -> float:
"""Return a divided by b."""
return a / b
PY
cat > test_calculator.py <<'PY'
import pytest
from calculator import divide
def test_divide():
assert divide(10, 2) == 5
def test_divide_by_zero_has_clear_message():
with pytest.raises(ValueError, match="b must not be zero"):
divide(10, 0)
PY
pytest -q
在 Windows PowerShell 中，虚拟环境激活命令应改为：
.venv\Scripts\Activate.ps1
此时第二个测试会失败。进入项目目录后启动 Claude Code，然后用自然语言交代目标：
claude
可以输入这样的任务说明：
阅读 calculator.py 和 test_calculator.py。
运行 pytest 复现失败，只修改解决该失败所必需的代码。
当 b 为 0 时抛出 ValueError("b must not be zero")。
修改后再次运行测试，并总结改动和测试结果。
这个提示词包含四个关键约束：读取哪些文件、怎样复现、预期行为是什么、如何验收。它比“帮我修一下”更不容易产生范围失控的修改。
把调试过程变成闭环
调试 Python 项目时，Claude Code 最适合围绕可观察证据工作，而不是根据一句异常描述猜测原因。一个可靠的闭环通常包括：
- 运行失败的命令，保留完整 traceback。
- 定位最靠近业务代码的异常栈帧。
- 阅读相关实现、调用方和测试。
- 先解释根因，再做尽量小的修改。
- 重跑目标测试，然后执行更完整的测试集。
例如，处理真实项目中的失败时，可以给出下面的指令：
运行 python -m pytest tests/test_orders.py -q，分析完整 traceback。
先告诉我根因和准备修改的文件，不要立即扩大重构范围。
修复后重跑该测试；通过后再运行 python -m pytest -q。
不要改变公开函数签名，除非现有测试明确要求。
如果问题只在特定输入下出现，应把输入也固化成回归测试。这样，Claude Code 给出的修改是否有效，不依赖“看起来正确”，而由测试结果判断。
让项目上下文更明确
自然语言命令并不意味着可以省略工程约束。Python 版本、依赖管理方式、格式化工具和测试入口都应该在仓库里明确表达。可以这样实践：为项目准备一个简洁的 pyproject.toml。
[project]
name = "claude-python-demo"
version = "0.1.0"
requires-python = ">=3.11"
[tool.pytest.ini_options]
testpaths = ["tests"]
addopts = "-q"
[tool.ruff]
line-length = 100
还可以在交互开始时补充项目规则：
本项目使用 Python 3.11、pytest 和 Ruff。
优先修改现有模块，不引入新依赖。
所有缺陷修复必须增加或保留回归测试。
完成后运行 pytest -q 和 ruff check .，报告任何未解决的问题。
这类约束能帮助工具区分“技术上可行”和“符合当前仓库约定”。对于大型项目，还应指出关键目录、启动命令以及禁止修改的生成文件。
代码审查不能交给一次对话
Claude Code 可以执行命令和修改文件，因此使用前应确认当前目录和版本控制状态。对于陌生仓库或高风险脚本，先让它只分析，再授权修改。
建议在每轮修改后检查差异：
git status --short
git diff --check
git diff
python -m pytest -q
需要特别留意以下边界：
- 不要把生产密钥、访问令牌或真实用户数据写进提示词、测试夹具和日志。
- 数据库迁移、删除文件、发布包和修改 CI 权限属于高风险操作，应逐项审查。
- 测试通过只说明已有断言通过，不代表并发、性能、安全性和兼容性已经得到验证。
- 自动生成的大规模重构会提高审查成本；修复缺陷时通常应优先选择小改动。
一套适合日常开发的采用方式
可以从低风险、容易验收的任务开始，例如补充单元测试、解释 traceback、修复局部异常和完善类型标注。每个任务都明确复现命令、允许修改的范围和完成条件。
成熟的工作流不是让 Claude Code 一次写完整个项目，而是让它持续执行短循环：理解任务、读取上下文、运行测试、提交小修改、再次验证。自然语言降低了操作门槛，但测试、代码审查和版本控制仍然决定最终代码能否进入生产环境。