让 AI 修改代码，最容易忽略的是：改完能运行，不等于业务规则正确。 本文用一个只有十几行的运费函数，练习 Claude Code 的项目读取、需求澄清、最小修改和结果验收。即使没有复杂项目，也能看清一次代码协作应该留下哪些证据。

最终交付物是 shipping.py、test_shipping.py 和修改说明，覆盖满额包邮的临界值、负数和错误类型。本文的业务数据与程序均为原创练习；参考答案的本地单元测试已执行，未把它描述为 Claude Code 现场生成结果，也未实际完成付费账号登录或模型调用。

一、先弄清工具在哪里运行

Claude Code 是可以在终端中使用的编程工具，能读取项目、解释代码、提出修改并调用工具执行工作。安装到电脑的是客户端，不代表把 Claude 模型部署到了本地。使用时仍需满足官方支持的账号、服务可用性和计费条件。

开始前准备一个空的练习文件夹、可用终端、Python 和 Git。本文按 Windows PowerShell 操作；Git 用来观察修改差异，Python 用来执行函数与标准库测试，不需要为这个练习安装第三方 Python 包。

先分别执行 python --version 和 git --version。若电脑只有 py 命令，后文的 Python 命令统一替换为 py，不要一会儿调用系统解释器，一会儿调用另一个环境。若使用组织设备，先确认允许安装客户端和发送练习代码。

二、安装客户端并确认身份

Anthropic 官方仓库目前将原生安装和包管理器列为推荐方式，并已标注 npm 安装方式弃用。因此不要照搬旧教程，把全局 npm 安装当成唯一入口。

  1. 在 PowerShell 中确认 winget 可用。
  2. 按官方 README 的 Windows 包管理器方式执行下面命令。
  3. 安装后重新打开终端，再检查客户端能否被找到。
winget install Anthropic.ClaudeCode
claude --version

如果包源找不到该软件，去文末官方仓库查看其他安装方式，核对系统支持与网络条件，不从不明网站复制安装器。claude 无法识别时，先重新打开终端，再排查安装结果与 PATH，不需要通过反复安装多个不同来源的包解决。

进入练习目录运行 claude，根据当前客户端显示的官方登录流程完成身份验证。查看实际使用的账号、组织和计费提示；安装成功和获得使用额度是两件事。本文不提供共享账号、代充入口，也不承诺特定套餐一定可用。网络、账号资格和组织策略问题应按官方说明处理。

三、把问题缩小成可复现的函数

新建 shipping-lab 文件夹，在里面保存下面的 shipping.py。金额单位统一为“分”，避免把浮点金额的精度问题和本次边界修复混在一起。

def shipping_fee(amount_cents):
    if amount_cents > 9900:
        return 0
    return 800

这个初始版本有三个问题：恰好九十九元时没有免运费，负数仍然得到普通运费，错误类型没有明确约定。不要只告诉 AI“修一下”，先把业务边界写清楚：

  1. 仅演示一个配送区域，不涉及偏远地区、重量和活动叠加。
  2. 金额必须是整数分；字符串、小数、布尔值不允许自动转换。
  3. 金额不能为负数；零元订单仍返回八百分运费。
  4. 满九千九百分，包括恰好九千九百分，运费为零。
  5. 类型错误抛 TypeError，负数抛 ValueError。

这里的九十九元门槛和八元运费是虚构规则，不应直接套用到真实商店。真正接手项目时，还要确认优惠券前后金额、退款订单、区域与税费口径。

运费函数在9899分、9900分和9901分三个边界的预期结果示意

四、先让 Claude Code 阅读，再授权修改

在这个目录执行 git init，然后运行 claude。先发只读任务，要求解释而不是立即写文件：

请先只阅读 shipping.py，说明当前行为与五条业务规则的差异。
不要修改文件，不安装依赖，不访问外部网络。
列出正常、边界、错误输入的测试建议，再等待我确认。

核对它有没有发现 > 和 >= 的区别，有没有识别布尔值问题，有没有擅自补充真实项目不存在的配送规则。若它提出重构、引入框架或连接支付平台，让它返回当前的小范围问题。

确认理解一致后，再发修改任务：

仅修改 shipping.py，并新增标准库 unittest 的 test_shipping.py。
函数名和金额单位保持不变。严格按已确认规则处理输入。
不要自动提交，不安装包，不修改其他目录。
完成后列出修改文件、测试命令、真实输出以及未验证事项。

客户端要求执行命令或修改文件时，阅读具体操作再决定是否批准。不要为了少点几次确认而放开整个磁盘或所有命令。练习目录也不要放 .env、密钥、客户代码和不相关资料；提示词限制范围不能替代对操作内容的检查。

五、参考实现为什么这样写

下面是符合本练习规则的一种实现，供对照检查，不要求 AI 必须生成完全一样的排版。

def shipping_fee(amount_cents):
    if type(amount_cents) is not int:
        raise TypeError("amount_cents must be an integer")
    if amount_cents < 0:
        raise ValueError("amount_cents must not be negative")
    return 0 if amount_cents >= 9900 else 800

这里特意使用严格类型判断，因为 Python 的 bool 是 int 的子类。如果写成 isinstance(amount_cents, int)，True 也会通过整数检查，与本练习“布尔值不允许”的要求冲突。这是业务约束导致的选择，不代表所有函数都应该拒绝整数子类。

不要让 AI 把字符串 "9900" 自动转成整数，也不要把 99.0 猜成九十九元：那会掩盖上游传错单位的问题。真实系统可以另设解析层，但解析和运费计算应有各自明确的责任。

六、用独立样例验收，而不是只看解释

将下列内容保存为 test_shipping.py。这是原创的标准库测试，不需要安装 pytest。

import unittest
from shipping import shipping_fee

class ShippingTests(unittest.TestCase):
    def test_valid_amounts(self):
        for value, expected in [(0, 800), (9899, 800),
                                (9900, 0), (9901, 0)]:
            with self.subTest(value=value):
                self.assertEqual(shipping_fee(value), expected)

    def test_negative_amount(self):
        with self.assertRaises(ValueError):
            shipping_fee(-1)

    def test_wrong_types(self):
        for value in [True, False, 9900.0, "9900", None]:
            with self.subTest(value=value):
                with self.assertRaises(TypeError):
                    shipping_fee(value)

if __name__ == "__main__":
    unittest.main()

在同一目录运行：

python -m unittest -v
git status --short

本地参考实现通过了上述三组测试方法，包含十个子情形。三组通过不代表覆盖了所有电商情形，更不能证明支付系统正确。它只证明当前小函数在列出的规则与输入下符合预期。

AI 若只回复“测试应该通过”，请让它区分实际运行、未运行与运行失败。你也应在自己的终端重新执行命令，检查退出码和错误输出；生成的测试可能与生成的代码共享同一种误解。

代码协作的需求、差异、测试和未验证范围四项验收示意

七、看清差异和未跟踪文件

如果练习目录没有初始提交，git diff 不会把所有未跟踪文件直接显示出来。先看 git status --short，逐个打开列出的文件；有版本基线的项目再结合 git diff 对照修改。不要因为 diff 为空，就断定没有发生变化。

检查有没有只改比较符却漏掉类型校验，有没有为了让测试绿灯而改低预期，有没有出现多余依赖、联网代码、自动提交或目录外文件。满意后由你决定是否保存提交；不满意则只撤回本轮明确的改动，保留之前自己的工作。

八、补一份可交接的修改说明

把验证结果和业务依据一起放入简短说明，至少写清“为什么改、改了什么、如何检查、还没检查什么”。例如：原函数在等于门槛时收取运费，现改为包含门槛；新增输入约束，避免上游把元与分混传；参考测试覆盖四个正常金额、一个负数和五种错误类型；未接入真实订单、优惠券与配送区域。

如果 AI 给出的实现与参考实现不同，先逐条检查规则，而不是只比较字符串。它可以用普通分支代替三元表达式，也可以把异常信息写得更详细；但不能悄悄改变函数名、参数单位或异常类型。代码简短不是唯一标准，调用方是否能理解和处理错误同样重要。

下一步想支持优惠券时，应新增独立需求：门槛按优惠前还是优惠后计算，金额扣减能否为负，券是否作用于运费。先明确答案，再补样例；不要让 AI 在本轮修复时顺便猜一个规则。若原项目已有测试，除了本练习的新测试，也要运行与受影响模块有关的既有检查，防止局部修复破坏旧行为。

给团队演示时，拿一个他们能手算的输入开始，逐步追踪输入、分支与结果。初学者容易被长篇解释带走注意力，而恰好门槛、差一分和多一分这三个值能很快暴露误解。以后换成折扣、积分或额度判断，也可以沿用这种先约定边界再修改的协作方式。

九、遇到失败按层排查

命令找不到，先看安装与终端环境；登录失败，检查官方账号流程与组织策略；模型请求失败，保留错误提示并核对服务状态和额度，不把它误判为 Python 出错。

ModuleNotFoundError: shipping 通常说明执行目录或文件名不匹配。确认两个文件在同一目录，文件不是误存成 shipping.py.txt。若测试在九十九元边界失败，回看比较条件；若布尔值被接受，回看类型判断；若产生小数金额，检查输入单位约定。

用于真实项目时，先在独立分支或副本里做同样的最小任务，新增必要回归样例，再逐步扩展。交付代码、业务依据、验证证据和未覆盖范围，比一句“已修复”更有价值。

官方资料