AI 生成代码现在变得非常便宜和快速，但这只改变了“敲键盘”的成本。它并没有改变代码的所有权、代码审查流程，也没有缩小一旦出 bug 的影响范围（我们常说的“爆炸半径”）。

我经常听到团队里流传着 5 个听起来很现代、实则暗藏隐患的说法。这篇指南会帮你纠正这些认知，并提供一个“债务收据”清单，建议你在合并代码前一定要填好它。

我想打破的一个口号

在站会上，我常听到这样一句话：“这是模型写的，所以我们直接发布了。”

这句话直接跳过了系统设计、测试验证和影响范围评估。AI 生成代码只是增加了你的“库存”，并没有帮你“还债”。

每个代码合并请求都应该问一个更犀利的问题：凌晨两点线上出事时，谁来负责这段代码？

怎么使用这份指南

把下面这些误区当成大家常说的话，然后去代码仓库里找找证据。接着，用纠正后的思维模型来审视，并在你的代码分支上填一份“债务收据”。

我把这个收据看作是合并代码的必备产物，而不是个人日记。如果 Git 提交记录里找不到负责人的名字，那线上出故障时就没人兜底。

误区一：生成的代码越多，技术债越少

大家的说法
“我们 20 分钟加了 12 个文件，积压的任务应该很快就能清空了。”

为什么会流传
以前敲代码慢是瓶颈，现在不是了，这种速度让人产生了一种“马上要完工”的错觉。但是，增加代码行数并不等于关闭了任务工单，你的“库存”在增加，而看板却绿油油的像没问题一样。

你可以收集的证据
数一数新增了多少生产环境文件，新增了多少测试文件，在代码差异里找找谁签了名（负责人）。如果找不到负责人，那技术债就是增加了。速度不能掩盖名字缺失的事实。

# 提议：从仓库根目录运行，而不是使用发布的基准测试
git diff --name-only origin/main...HEAD | tee /tmp/changed.txt # 获取与主分支相比修改的文件名并保存
echo "changed_files=$(wc -l < /tmp/changed.txt)" # 输出修改的文件数量
rg -n "TODO|FIXME|XXX" $(cat /tmp/changed.txt) || true # 在修改的文件中搜索TODO、FIXME等技术债标记

纠正后的认知
AI 生成代码增加了需要人照顾的“库存”。库存需要主人和测试路径。只有当残余风险被确认接受时，工单才算关闭，而不是当 AI 停止吐字的时候。

误区二：模型的解释能代替设计文档

大家的说法
“聊天记录已经把架构解释得很清楚了，为什么还要写下来？”

为什么会流传
当时看聊天记录觉得什么都很明白，但它是临时的、没法搜索的。工具一换，聊天记录就没了。新来的员工可没法在系统里搜索一个已经消失的对话。

你可以收集的证据
在 Git 里找一个能长久保存的东西：一个决策、一个不可逾越的底线、一个被否决的备选方案。如果 PR（合并请求）里啥都没有，那你留下的只是“民间传说”，语法高级一点的债务而已。

<!-- 提议：将此代码块放到 DEBT_RECEIPT.md 文件中 -->
## 决策
- 问题：
- 选择：
- 被拒绝的替代方案：
- 我们不会破坏的恒定量（规则）：
- 负责人：

纠正后的认知
解释只是对理解的草稿。设计是写在代码仓库里的约束。没进 Git 的就不算决策，你能指出对应的文件吗？

误区三：以后重新生成比现在写文档便宜

大家的说法
“我们下季度再让模型跑一遍就行了，写文档是额外负担。”

为什么会流传
在当前的对话框里，重新生成看起来是免费的。但以后重建上下文可不免费。下季度那个提示词早没了，生产环境的样子早就变了。

你可以收集的证据
挑一个模块，算算在没有任何上下文的情况下重新生成要花多久。再算算对着写好的规则改代码要多久。把结果当个思想实验，别贴在 PPT 上当证据。

纠正后的认知
趁着现在记忆还热乎，写文档是“压缩”上下文；以后重新生成是“解压”，而且会丢失细节。在这个分支上把压缩的活干了，未来的你没法重播今天的聊天。

误区四：模型写的测试就是你的测试

大家的说法
“它加了 pytest 测试文件，所以我们有保障了。看，跑通了，全是绿色的。”

为什么会流传
满屏的绿色让疲惫的审查者很安心。但生成的测试往往只是断言了代码的实现细节。它们把今天的 bug 冻结成了规范。那是带着对勾的债务。

你可以收集的证据
大声读出每个新测试的名字。问问如果测试失败，用户能感知到什么。如果测试只是镜像了内部逻辑，那它只是个快照，没人管就会烂掉。

# 提议：这是一个文件名触发器，不是覆盖率检查，也不会在你的CI里执行
from pathlib import Path
import sys

changed = Path("/tmp/changed.txt").read_text().splitlines() # 读取修改的文件列表
prod = [p for p in changed if p.endswith(".py") and "test" not in Path(p).name] # 筛选出非测试的生产代码文件
tests = [p for p in changed if p.endswith(".py") and "test" in Path(p).name] # 筛选出测试文件

print(f"prod_py={len(prod)} test_py={len(tests)}") # 打印生产文件和测试文件的数量
if prod and not tests:
    print("FAIL: production python changed without test files") # 如果有生产代码改动但没有测试文件，则报错
    sys.exit(1)
print("PASS: at least one test file in the diff") # 通过检查：差异中至少包含一个测试文件

这个脚本只是对文件名设了个绊马索，不是质量保证。

纠正后的认知
只有当你能解释测试为什么失败时，这个测试才归你管。如果没人能说清楚这行断言是干嘛的，删了或重写它。为了覆盖率演戏，依然是债务。

误区五：免费跑通了，审查可以缓缓

大家的说法
“等代码合并后再审查吧，服务器已经跑过补丁了。”

为什么会流传
时间紧的时候，远程跑一遍看着挺正式。但那只是现实的草图。免费的运行环境只是草稿纸，它不是你合并代码的门禁，你心里清楚这一点。

你可以收集的证据
对比一下那个免费环境和你的正式 CI（持续集成环境）：语言版本、依赖包、密钥策略、网络规则。如果不一样，那绿色的运行结果就是个传说，干嘛今晚要把传说合并到主干里？

纠正后的认知
审查是赋予代码责任人的环节。拖延审查，债务就会在主分支上利滚利。早点用免费环境做探索，但人的审查关卡不能省。探索不等于接受。

一个演示（未实际运行）

假设有个 PR 加了 billing/prorate.py，模型也加了 tests/test_prorate.py。看着搞定了？先别急着欢呼，打开测试看看。

如果它只检查了一个辅助函数的返回值，那用户还是可能被扣两次钱。收据里必须写明针对用户可见行为的检查。

# 提议：这是一个行为测试的骨架，不是真正的计费测试套件
def test_proration_does_not_double_charge_on_plan_change():
    """用户可见行为：每月的扣费保持为单个条目。"""
    # 模拟用户从 pro 计划换到 team 计划，使用了10天
    invoice = prorate(old_plan="pro", new_plan="team", days_used=10)
    # 断言发票中名为 "subscription" 的条目只有一个，确保没有重复扣费
    assert invoice.line_items_named("subscription") == 1
    # 断言总金额大于0
    assert invoice.total > 0

我没拿这个去跑真实的计费系统，抄走它的结构，别抄走业务逻辑。

虽然那个触发器能通过（因为存在测试文件），但只要没写明用户可见的检查，收据就不算合格。

工作流：不骗自己地使用免费模型

我想要一个无聊的循环：探索、写收据、人工把关。

MonkeyCode 提供了免费的模型访问和免费服务器选项。这对“探索”步骤很有用，但千万别用来做“合并”步骤。声明一下：这篇文章是 MonkeyCode 产品推广的一部分。

我推荐这套流程，把它当模板用：

• 用免费的模型会话起草修改方案。
• 在免费服务器上运行上面提到的库存统计命令。
• 在同一个分支上填写 DEBT_RECEIPT.md。
• 只把通过 CI 视作唯一有效的绿色通行证。
• 只有指定了负责人和残余债务后才能合并。

# 债务收据.md (提议)

## 范围
- 用户可见的行为：
- 触及的文件：

## 所有权
- 主要负责人：
- 备用负责人：
- 故障响应路径：

## 验证
- 必须保持通过的 CI 任务：
- 我们仍然欠的手动检查：

## 残留的债务
- 我们没有做的事情：
- 为什么这在某个时间点前是可以接受的：

免费服务器能帮你跑 grep 和 Python 触发器，但它没法替你承担残余风险。别把密码贴进那个盒子里，把安全策略写进收据，而不是写进秘密。

决策清单

在关闭工单前用这个清单，填不上的空格就意味着必须停下来。

• 很多新文件：看着像速度提升，实际问题是：谁拥有这些文件？
• 聊天记录解释：看着像思路清晰，实际问题是：哪个不可逾越的规则进了 Git？
• 模型写的测试：看着像有了测试覆盖，实际问题是：什么用户行为会失败？
• 免费服务器上变绿：看着像有了信心，实际问题是：CI 环境和那个盒子一样吗？
• “我们可以重新生成”：看着像有后路，实际问题是：什么上下文会丢失？

如果哪个空填不上，工单就别关。很痛苦，但诚实，比凌晨两点被报警电话吵醒好多了。

局限性

这个收据只是个经验法则，它会漏掉那些名字起得挺好但逻辑很烂的坏代码。触发器只看文件名，改个测试名它就哑火了。免费模型的输出每次都不一样，别拿一次聊天来定死质量标准。我不提供什么配额、硬件或运行承诺，这些信息容易过期。这篇文章也不是生产环境基准测试，请在你自己的仓库里运行。

生成的测试也能是好东西，误区不在于 pytest 的存在，而在于“默认拥有了所有权”。

哪些人不适合用这套方法

如果你已经有了正式的架构审查流程，跳过这篇，你不需要更轻量的仪式。如果公司规定禁止用托管模型，那继续用本地工具和内部 CI。如果改动只有一行配置，写收据就是搞形式主义。如果你连个负责人都指派不出来，先解决招人的问题，别自动化那些民间传说。

记住这些

生成代码只是廉价的打字。债务是留在主干分支里未被理解的代码。问问谁拥有这个爆炸半径，然后把那个名字写进 Git。如果你已经有了免费模型环境，先在那跑跑触发器，然后再去讨论工单该不该关，而不是去争论自动补全好不好用。