GLM-5与Claude Code协同重构开源项目实战

1. 项目概述：当 GLM-5 遇上 Claude Code，一场开源项目重构的实战推演

最近两周，我连续拆解了三个中等规模的开源项目——一个基于 Django + Celery 的异步任务调度系统、一个 UniApp 构建的 iOS 网络测速工具、还有一个用 Label Studio 搭建的中文标注平台。不是为了提交 PR，而是做一件事：用 GLM-5 和 Claude Code 联合完成一次端到端的代码理解、问题诊断与结构化重构。这不是概念演示，也不是 prompt 工程秀，而是一次在真实工程约束下（Python 3.11、Redis 集群、iOS 17 SDK 兼容性、Vue 3.4 响应式限制）的“人机协同编码”压力测试。核心关键词很明确：GLM-5是本地可部署、中文语义理解极强的推理模型，擅长读代码、写文档、生成逻辑清晰的函数；Claude Code则是专为代码场景深度优化的模型，对 Python/JS/SQL 的语法树感知、上下文跳转、边界条件枚举能力远超通用大模型。两者叠加，不是简单相加，而是形成“理解力 × 执行力”的乘数效应。适合谁？不是刚学 for 循环的新手，而是有 2 年以上全栈经验、正被遗留系统拖慢迭代节奏的工程师——你不需要从零造轮子，但需要快速吃透别人写的 5 万行代码，并安全地把它变成你能掌控的形态。这次实测不谈参数量、不比 benchmark 分数，只回答三个硬问题：它能不能准确识别 Celery 中 task 调度链路里的 Redis 连接泄漏点？能不能把 UniApp 里混杂着原生 iOS API 调用和 JS 逻辑的 network.ts 文件，拆解成符合 Vue 3 Composition API 规范的可维护模块？能不能给 Label Studio 的中文字段配置生成带校验规则的 JSON Schema？答案是：能，但有严格前提——你得知道在哪设“锚点”，怎么切“上下文窗口”，以及，最关键的是，如何用一句精准的自然语言指令，把模糊的“改得更好”翻译成模型能执行的原子操作。

2. 核心思路拆解：为什么是 GLM-5 + Claude Code，而不是单模型 or 其他组合？

2.1 模型能力边界的物理级错配：GLM-5 擅长“读”，Claude Code 擅长“写”

先说结论：单独用 GLM-5 去重构 Celery 项目，会卡死在第 3 步；单独用 Claude Code 去理解 UniApp 的 iOS 原生桥接逻辑，会漏掉 70% 的上下文依赖。这不是模型缺陷，而是设计哲学的根本差异。GLM-5 的底层架构决定了它对长文本、多层级嵌套逻辑（比如 Django settings.py 里层层 import 的配置继承链）有极强的全局感知力。我喂给它整个celeryconfig.py+tasks.py+redis_client.py三份文件（合计 1287 行），它能在 17 秒内输出一份带时间戳的调用关系图谱，精确标出@shared_task(bind=True)装饰器下self.retry()方法调用时，max_retries=3参数实际生效的配置来源是CELERY_TASK_DEFAULT_RETRY_DELAY还是task.retry_kwargs。这种“溯源能力”是 Claude Code 目前做不到的——它的上下文窗口虽大，但更像一个专注的外科医生，擅长在已知病灶周围做精细切除与缝合，却不太会主动回溯整条血管走向。反过来，Claude Code 对代码语法的“肌肉记忆”是碾压级的。当我让 GLM-5 把一段含 5 个嵌套 if-else 的 Celery 重试逻辑，改写成使用tenacity库的装饰器模式时，它生成的代码虽然逻辑正确，但@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10))这一行里，min=1的单位是秒还是毫秒？它没写注释，也没验证wait_exponential在 Redis 集群环境下是否会产生时钟漂移。而 Claude Code 会直接在代码块下方补上两行注释：“// 注意：min/max 单位为秒，Redis 集群节点间时钟误差需 < 500ms，否则可能触发重复重试”，并附上一个pytest测试用例，模拟时钟偏移 800ms 时的断言失败场景。这就是本质区别：GLM-5 给你一张高精度地图，Claude Code 给你一把带刻度的手术刀。

2.2 开源项目重构的三大不可妥协约束：可追溯、可验证、可交付

为什么不用 GPT-4o 或其他闭源模型？因为开源项目重构不是写一篇博客，它有铁律。第一是可追溯性。你在 GitHub 上提交一个 PR，必须能清晰说明“这个修改解决了 Issue #287 中描述的 Redis 连接池耗尽问题，依据是 GLM-5 对 celery/app/control.py 第 412 行inspect().active_queues()返回值的分析”。如果模型只给你一个“优化后的代码”，没有引用原始行号、没有关联 issue、没有解释决策依据，那它就是个黑箱，工程师无法背书。GLM-5 的输出天然带引用标记（如[src: celery/app/control.py:412]），Claude Code 的代码块默认带文件路径前缀（# File: tasks/network_speed.py），二者组合，天然满足开源协作的审计要求。第二是可验证性。重构后的代码必须能通过原有测试套件，且不能引入新 bug。这里 Claude Code 的优势爆发：它能根据你提供的pytest配置，自动生成覆盖边界条件的测试用例。比如针对 UniApp 测速项目里一个计算网络延迟的函数，GLM-5 会指出“当前实现未处理 iOS 16.4 以上版本返回的NSNull值”，而 Claude Code 会立刻生成 3 个测试用例：test_delay_calculation_with_nsnull_on_ios164()、test_delay_calculation_with_valid_number()、test_delay_calculation_with_empty_string()，每个都带pytest.mark.parametrize的数据驱动。第三是可交付性。最终产物不是一堆聊天记录，而是可直接git add && git commit的文件。这意味着模型输出必须严格遵循项目原有的代码风格（Pylint 规则、Vue 单文件组件结构、iOS Swift 的命名规范）。GLM-5 能学习项目根目录下的.editorconfig和pyproject.toml，Claude Code 则能将这些规则编译成具体的缩进、空格、换行策略。我实测过，用它们联合重构的 Celery 项目，black --check和eslint --fix通过率是 100%，而纯靠人工改，平均要返工 2.3 次。

2.3 为什么不是 “AI Coding Agent”？——当前阶段，人仍是总控台

网络热词里频繁出现 “AI Coding Agent”，但这次实测让我彻底放弃幻想。所谓 Agent，本质是自动规划、执行、反思的闭环。但在开源项目重构中，“规划”这一步就卡住了。Agent 不知道你的 KPI 是“下周上线新测速算法”，还是“本月降低 30% 服务器成本”。它更不知道公司内部 Redis 集群的运维 SLA 是 99.95%，所以重试间隔不能低于 2 秒。这些业务约束，必须由人来注入。我们采用的是“人类指挥官 + 双模型士兵”的模式：我作为指挥官，发出三条指令——① “GLM-5，请扫描整个项目，定位所有可能造成 Redis 连接泄漏的 Celery task 实现，并按风险等级排序”；② “Claude Code，请基于 GLM-5 输出的风险 Top3 文件，为每个 task 编写tenacity重试装饰器，并生成对应的单元测试”；③ “GLM-5，请审核 Claude Code 生成的全部代码，检查是否符合pyproject.toml中定义的mypy类型检查规则”。整个过程，我只做了三件事：粘贴指令、核对输出中的关键行号、运行pytest。模型不决定“做什么”，只负责“怎么做”。这种分工，既规避了 Agent 的盲目性，又放大了双模型的专业性。记住，当前阶段最高效的 AI Coding，不是让 AI 替你思考，而是让你的思考，获得指数级的执行倍率。

3. 实操细节解析：从环境搭建到指令设计的 7 个生死关卡

3.1 环境准备：本地化部署 GLM-5 的硬性门槛与绕行方案

GLM-5 官方提供两种部署方式：Ollama 一键包，或手动加载 Hugging Face 模型权重。别信“一键包”宣传——在 macOS M2 Max 上，Ollama 启动glm5:latest后，首次推理耗时 42 秒，内存占用直逼 18GB，且无法同时加载多个量化版本。这是物理限制，不是软件 bug。我的解决方案是：放弃 Ollama，直连 vLLM。vLLM 是目前吞吐量最高的 LLM 推理引擎，对 GLM-5 的支持已非常成熟。具体步骤：先用pip install vllm，再下载官方发布的glm-5-7b-chat-int4量化模型（注意，必须是 int4，float16 版本在 32GB 显存的 A10 上都会 OOM）。启动命令是：

python -m vllm.entrypoints.api_server \ --model /path/to/glm-5-7b-chat-int4 \ --tensor-parallel-size 2 \ --dtype half \ --max-model-len 8192 \ --port 8000

关键参数解释：--tensor-parallel-size 2是必须的，GLM-5 的 KV Cache 极大，单卡无法承载；--max-model-len 8192是底线，低于此值，它无法完整解析一个含 5 个文件的 Celery 项目；--dtype half而非auto，因为 GLM-5 的 int4 权重在half模式下推理最稳。启动后，用 curl 测试：

curl http://localhost:8000/generate \ -H "Content-Type: application/json" \ -d '{ "prompt": "请分析以下 Celery task 代码：@shared_task def send_email(user_id): ...", "max_tokens": 512 }'

如果返回{"text": "..."}，说明成功。这里有个血泪教训：别用--host 0.0.0.0暴露端口，vLLM 默认无鉴权，一旦暴露，你的本地模型就成了公共 API。必须用--host 127.0.0.1，并确保前端工具（如 VS Code 插件）只连本地地址。

3.2 Claude Code 的接入：绕过官网限制的合规路径

Claude Code 官网中文版确实存在地域限制提示（“Note: claude code might not be available in your country”），但这不等于无法使用。官方提供了Claude Code CLI和VS Code 插件两种合规接入方式，二者均不依赖网页端。CLI 方式最稳定：下载官方claude-code-cli二进制文件（macOS/Linux/Windows 均有），解压后执行./claude-code --help。首次运行会引导你登录 Anthropic 账户（需邮箱验证），登录后自动绑定 API Key。关键在于，CLI 的请求走的是 Anthropic 的全球 CDN，而非本地 IP 地址判断，因此不受地域限制影响。我实测，在上海、深圳、成都三地的网络环境下，CLI 均能稳定连接。VS Code 插件同理，安装后在设置里填入 CLI 生成的 Key 即可。这里必须强调：绝对不要使用任何第三方封装的“Claude Code 中文版”网站或桌面应用。这些非官方渠道，要么是钓鱼页面，要么内置了未知的数据回传逻辑，对于处理公司开源项目代码，风险极高。CLI 和官方插件，是唯一经过 Anthropic 安全审计的通道。

3.3 上下文切片：决定重构成败的“第一刀”

模型再强，也受限于上下文窗口。GLM-5 的 8K 窗口，面对一个 5 万行的 Django 项目，根本不够。我的切片策略是“三层锚定法”：第一层，文件级锚定。绝不把整个django/目录扔进去。而是先让 GLM-5 扫描requirements.txt和pyproject.toml，锁定核心依赖（Celery、Django、Redis），然后只加载与这些依赖强相关的文件：settings/base.py、celery.py、tasks/目录下所有.py文件、apps/core/tasks.py。第二层，函数级锚定。对每个 task 文件，用正则提取所有@shared_task和@task装饰器下的函数定义，连同其 docstring 和紧邻的 3 行上下文（def send_notification(...):之前 3 行，之后 3 行），组成最小分析单元。第三层，错误日志锚定。如果有现成的 Sentry 错误日志，直接把报错堆栈（File "/app/celery/app/trace.py", line 412, in trace_task）作为最高优先级上下文，强制模型聚焦。这套方法，让 GLM-5 的分析准确率从盲扫的 38% 提升到 92%。一个典型例子：UniApp 项目里，network.ts文件有 2300 行，但真正涉及 iOS 原生桥接的只有 12 行（window.webkit.messageHandlers.speedTest.postMessage(...)）。如果让模型读全文件，它会把 90% 的精力花在无关的 Vue 生命周期钩子上；而用错误日志锚定，它能瞬间定位到postMessage调用处，并指出“iOS 17.4+ 要求postMessage的第二个参数必须是['*']，否则静默失败”。

3.4 指令工程：把“改得更好”翻译成机器可执行的原子指令

工程师最大的误区，是以为“请优化这段代码”就够了。模型不知道你的“优化”标准是性能、可读性，还是兼容性。我的指令模板是“角色 + 输入 + 输出 + 约束” 四段式。以重构 Celery task 为例：

角色：你是一位有 10 年 Python 经验的 SRE，专精 Redis 集群运维。
输入：[粘贴 GLM-5 输出的风险 Top3 task 函数代码，含行号]
输出：1. 用tenacity库重写该 task，保留原有 retry 逻辑；2. 为每个重试分支添加logging.warning，包含task_id和retry_count；3. 生成一个 pytest 测试用例，覆盖max_retries=3时的全部 4 种状态（成功、失败1次、失败2次、失败3次）。
约束：1. 必须使用@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=30))；2. 日志格式为f"Task {self.request.id} retry #{retry_count}"；3. 测试用例必须用monkeypatch模拟redis.Redis的execute_command方法。

看到区别了吗？角色定义了专业背景，输入锁定了分析范围，输出列出了三项可验证动作，约束则用具体代码片段和字符串格式，堵死了所有歧义空间。我对比过，用这种指令，Claude Code 的首次生成通过率是 89%；而用“请改进这个 task”，通过率只有 21%。指令不是越短越好，而是越“像给同事发 Slack 消息”越好——清晰、具体、带上下文。

3.5 代码风格对齐：让 AI 产出无缝融入团队仓库

AI 生成的代码，最大的落地障碍不是功能，而是风格。一个用snake_case写了 5 年的团队，突然看到camelCase的变量名，PR 就会被打回。我的解决方案是：把.pre-commit-config.yaml和pylintrc当作模型的“宪法”。在向 Claude Code 发送指令前，我会先提取项目根目录下的这两个文件，把其中的关键规则作为系统提示词（system prompt）的一部分。例如，.pre-commit-config.yaml里有：

- repo: https://github.com/pycqa/pylint rev: v2.17.5 hooks: - id: pylint args: [--disable=C0114,C0115,C0116]

我就告诉模型：“本项目禁用 Pylint 的 C0114（missing-module-docstring）、C0115（missing-class-docstring）、C0116（missing-function-docstring）规则，因此生成的代码无需添加 docstring。” 同样，pylintrc里若定义了max-line-length=120，我就强制模型输出的代码行宽不超过 120 字符。更进一步，我会把项目里tests/conftest.py中的 fixture 定义，也作为上下文喂给模型，确保它生成的测试用例能直接import这些 fixture。这种“风格对齐”，不是靠模型自己猜，而是靠工程师把团队的隐性知识，显性化为模型的输入约束。实测表明，经此处理的 AI 代码，pre-commit run --all-files通过率从 43% 提升至 98%。

3.6 安全红线：哪些事 AI 绝对不能碰？

再强大的模型，也有不可逾越的红线。我在实测中划出三条铁律：第一，绝不生成或修改密码、密钥、Token。GLM-5 曾试图在重构settings.py时，把os.environ.get('REDIS_PASSWORD')替换成一个硬编码的字符串（它认为“这样更安全”）。我立刻中断流程，并在系统提示词里加入：“你无权访问任何环境变量的实际值，所有os.environ.get()调用必须原样保留，不得替换、不得猜测、不得生成默认值。” 第二，绝不触碰生产数据库 schema。Claude Code 有一次建议“为提高查询速度，给user_profile表添加last_login_index索引”。这是危险的——索引添加需 DBA 审批，且需评估对写入性能的影响。我的指令是：“你只能修改应用层代码，禁止提出任何 DDL（CREATE INDEX, ALTER TABLE）建议。” 第三，绝不处理 iOS/Android 原生证书和签名配置。UniApp 项目里，ios/build/目录下的.p12证书和entitlements.plist文件，AI 生成的任何修改都可能导致 App Store 审核失败。我的做法是：把这些目录明确排除在所有分析上下文之外，并在指令中强调：“你无权访问或修改任何位于ios/或android/目录下的文件。”

3.7 结果验证：用三道防线过滤 AI 的“幻觉”

AI 的幻觉（hallucination）不是 bug，是特性。我的验证体系是“静态 → 动态 → 人工”三道防线。第一道，静态检查：所有 AI 生成的代码，必须通过ruff check（替代 flake8 + isort + black 的超快检查器）和mypy --strict。Ruff 会在 0.3 秒内报告所有语法错误和风格违规；mypy 则揪出类型不匹配——比如 GLM-5 说“redis_client.get()返回str”，而实际是bytes，mypy 会立刻报错error: Incompatible types in assignment (expression has type "bytes", variable has type "str")。第二道，动态检查：运行pytest --tb=short -xvs tests/。重点不是全量通过，而是看 AI 生成的测试用例是否真的在跑。我要求每个 AI 生成的测试函数，必须包含assert语句，且assert的左侧必须是 AI 修改后的代码路径。如果测试只是pass，或者assert True，立刻打回重写。第三道，人工抽检：随机抽取 5% 的修改行，进行“逆向工程”。比如 AI 把if user.is_active:改成了if getattr(user, 'is_active', False):，我就手动查 Django 源码，确认User模型的is_active是否真有可能为None。这步耗时，但能发现模型基于“常识”做出的错误假设。三道防线下来，AI 代码的线上事故率为 0，而纯人工重构的历史事故率是 0.7%（数据来自我们团队过去 12 个月的 Sentry 统计）。

4. 实操过程全记录：从 Celery 项目切入，完成一次真实重构闭环

4.1 第一阶段：GLM-5 全局扫描与风险定位（耗时 18 分钟）

目标项目：一个基于 Django 4.2 + Celery 5.3 的用户行为分析系统，核心任务是每 5 分钟拉取一次第三方 API 数据并入库。问题现象：凌晨 3 点左右，Redis 连接数飙升至 1024（集群上限），导致任务堆积。传统排查需 3-4 小时，这次我们用 GLM-5。

第一步，构建上下文。我收集了 7 个关键文件：

• requirements.txt（确认 Celery 5.3.6、redis 4.6.0）
• celery.py（主配置）
• tasks/data_fetch.py（核心 task 文件，327 行）
• core/redis_client.py（自定义 Redis 封装，189 行）
• settings/base.py（Redis 连接配置）
• logs/celery_worker.log（最近 24 小时错误日志，含ConnectionError: Error 113 connecting to 10.0.1.5:6379. No route to host.）
• docker-compose.yml（Redis 集群服务定义）

第二步，发送 GLM-5 指令：

你是一位资深 Python SRE。请分析以上 7 个文件，定位所有可能导致 Redis 连接泄漏的代码点。特别关注：1.redis_client.py中get_connection()方法的调用链；2.data_fetch.py中@shared_task函数内redis_client.get_connection()的使用方式；3.celery.py中app.conf.broker_pool_limit和app.conf.worker_pool的配置是否冲突。请按风险等级（高/中/低）排序，每个风险点必须标注精确文件名和行号，并说明泄漏原理。

GLM-5 的输出如下（节选高风险部分）：

高风险 [src: core/redis_client.py:42]：get_connection()方法在except redis.ConnectionError:块中，调用了self._connection.close()，但未将self._connection置为None。当后续再次调用get_connection()时，会复用已关闭的连接对象，触发ConnectionResetError，而该异常未被捕获，导致连接对象无法被垃圾回收。[src: tasks/data_fetch.py:88] 处fetch_user_datatask 在try/except中调用redis_client.get_connection()，但未在finally块中显式关闭连接，违反 Celery 5.3 的连接管理最佳实践。

中风险 [src: celery.py:23]：app.conf.broker_pool_limit = 10与app.conf.worker_pool = 'gevent'冲突。gevent worker 使用协程池，每个协程会独占一个连接，broker_pool_limit仅限制主线程连接数，导致实际连接数远超 10。建议改为broker_pool_limit = None或切换为threadspool。

这个输出，精准命中了问题根源。传统排查中，工程师往往先怀疑broker_pool_limit，而忽略了redis_client.py里那个隐藏的close()后未置空的 bug。GLM-5 的全局视角，让它能跨文件追踪对象生命周期。

4.2 第二阶段：Claude Code 精准修复与测试生成（耗时 7 分钟）

基于 GLM-5 的高风险报告，我向 Claude Code 发送指令：

你是一位 Celery 专家。请基于以下代码，完成三项任务：
代码：

# File: core/redis_client.py # Line 38-45 def get_connection(self): if self._connection is None: self._connection = redis.Redis(**self.config) try: self._connection.ping() return self._connection except redis.ConnectionError: self._connection.close() # ← 问题行 raise

任务：1. 重写get_connection()方法，确保连接异常时_connection被置为None；2. 在tasks/data_fetch.py的fetch_user_datatask 中，添加with redis_client.get_connection() as conn:上下文管理；3. 为get_connection()方法编写 pytest 测试，覆盖ping()成功、ping()失败（ConnectionError）、ping()失败后再次调用三种场景。
约束：1. 必须使用contextlib.closing()或自定义__enter__/__exit__；2. 测试必须用monkeypatch模拟redis.Redis；3. 代码风格必须与pyproject.toml中ruff规则一致。

Claude Code 的输出完全符合要求。它生成了一个RedisConnectionManager类，实现了__enter__和__exit__，并在__exit__中确保_connection置空。fetch_user_datatask 的修改，也严格使用了with语句。最惊艳的是测试用例：

def test_get_connection_retry_on_failure(monkeypatch): """Test that connection is reset after ConnectionError.""" mock_redis = Mock() mock_redis.ping.side_effect = [redis.ConnectionError, None] # Patch the Redis constructor to return our mock monkeypatch.setattr(redis, 'Redis', lambda **kwargs: mock_redis) client = RedisClient(config={}) # First call fails, second succeeds conn1 = client.get_connection() conn2 = client.get_connection() # Assert conn1 and conn2 are different objects assert conn1 is not conn2 # Assert ping was called twice assert mock_redis.ping.call_count == 2

这个测试，精准验证了“连接重置”这一核心修复点。运行pytest tests/test_redis_client.py，全部通过。

4.3 第三阶段：GLM-5 交叉验证与文档生成（耗时 5 分钟）

Claude Code 的代码生成完毕，但还不能提交。我让 GLM-5 扮演“代码审查员”，对生成物进行交叉验证：

你是一位严格的开源项目 Maintainer。请审查以下代码：
代码：[粘贴 Claude Code 生成的RedisConnectionManager类和fetch_user_data修改片段]
审查点：1. 是否符合 PEP 8？2.__exit__方法中，self._connection = None是否在所有异常路径下都执行？3.fetch_user_data中with语句的as conn变量，是否在所有代码路径下都被使用？4. 生成一份简明的CHANGES.md片段，说明本次修改解决了什么问题，影响范围是什么。

GLM-5 的审查报告指出一个细节：__exit__方法中，self._connection = None语句在exc_type is not None的if块内，而exc_type is None（即正常退出）时，该赋值未执行。这是一个致命疏漏！Claude Code 生成的代码，只处理了异常路径，忽略了正常路径。我立刻让 Claude Code 修正，它迅速补上了else分支。随后，GLM-5 生成的CHANGES.md片段如下：

Fixed Redis connection leak in data fetch tasks

• Problem:core/redis_client.py'sget_connection()method failed to reset_connectiontoNoneafterConnectionError, causing stale connection objects to accumulate.
• Impact: Affected all Celery tasks usingredis_client.get_connection(), primarilyfetch_user_dataandprocess_analytics.
• Fix: IntroducedRedisConnectionManagercontext manager with proper__exit__cleanup. All task calls now usewith redis_client.get_connection() as conn:.
• Verification: Addedtest_get_connection_retry_on_failurecovering connection reset logic.

这份文档，可直接放入 PR 描述，清晰、专业、无歧义。

4.4 第四阶段：全流程回归与性能压测（耗时 22 分钟）

所有代码修改、测试、文档就绪后，进入最后的工程验证。我执行了四步操作：

1. 全量测试：pytest --tb=short -xvs tests/。所有 127 个原有测试 + 3 个新测试，全部通过。特别关注了test_celery_worker_restart，它模拟 worker 进程崩溃后重启，验证连接池是否能自动恢复——通过。

2. 静态检查：ruff check . && mypy .。零错误。ruff报告了 2 个E501 line too long警告（AI 生成的测试用例里有一行超长字符串），我手动调整了换行，符合团队规范。

3. 本地压测：用locust模拟 100 个并发用户，持续 5 分钟调用fetch_user_datatask。监控 Redis 连接数：峰值稳定在 87，远低于 1024 上限，且无波动。而压测前，同样场景下连接数在 3 分钟内就冲到了 982。

4. Git 差异审查：git diff --no-index /dev/null <(cat modified_files_list)。我手动检查了每一个修改文件，确认：

   • 没有意外修改requirements.txt（AI 从未被允许修改依赖）
   • docker-compose.yml未被改动（AI 无权修改基础设施）
   • 所有新增代码都有对应测试（test_redis_client.py新增 3 个函数）

整个闭环，从 GLM-5 扫描到压测完成，耗时 52 分钟。而团队历史平均排查修复时间是 6.5 小时。效率提升 7.5 倍，且结果可审计、可验证、可交付。

5. 常见问题与独家避坑指南：那些文档里不会写的实战真相

5.1 问题速查表：高频故障与根因定位

5.2 独家避坑心得：来自 17 次失败重构的教训

心得一：永远不要让 AI “理解业务逻辑”，只让它“执行技术契约”。我曾让 GLM-5 分析一个电商项目的“满减优惠券”逻辑，它