惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

美团技术团队
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - Franky
有赞技术团队
有赞技术团队
博客园 - 司徒正美
量子位
N
News and Events Feed by Topic
T
Threatpost
Last Week in AI
Last Week in AI
D
Darknet – Hacking Tools, Hacker News & Cyber Security
酷 壳 – CoolShell
酷 壳 – CoolShell
C
CERT Recently Published Vulnerability Notes
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
I
Intezer
人人都是产品经理
人人都是产品经理
T
Tenable Blog
IT之家
IT之家
雷峰网
雷峰网
腾讯CDC
博客园 - 聂微东
V
Visual Studio Blog
S
SegmentFault 最新的问题
Scott Helme
Scott Helme
Spread Privacy
Spread Privacy
月光博客
月光博客
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
V
V2EX
大猫的无限游戏
大猫的无限游戏
Apple Machine Learning Research
Apple Machine Learning Research
爱范儿
爱范儿
T
Tailwind CSS Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
罗磊的独立博客
N
Netflix TechBlog - Medium
J
Java Code Geeks
宝玉的分享
宝玉的分享
F
Full Disclosure
WordPress大学
WordPress大学
A
Arctic Wolf
小众软件
小众软件
AWS News Blog
AWS News Blog
Attack and Defense Labs
Attack and Defense Labs
NISL@THU
NISL@THU
AI
AI
Hugging Face - Blog
Hugging Face - Blog
F
Fortinet All Blogs
云风的 BLOG
云风的 BLOG
N
News | PayPal Newsroom
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org

暗无天日

读:AI Agent 安全日志——从可见性与隐私的两难说起 - 暗无天日 AI写作的语言指纹——如何让文字不那么像机器 - 暗无天日 读:50 条 Claude Code 技巧——一个工程经理的六个月使用心得 读:AI 辅助开发为什么让 E2E 测试更有价值 - 暗无天日 读:在Emacs中使用Claude Code(Spacemacs适配版) - 暗无天日 Claude Code 背后的工程哲学——读 Agent Harness Engineering 读:Agent Harness Engineering——AI 智能体不只是模型,还有套件 - 暗无天日 browser-harness:让 AI 直接接管你的浏览器 - 暗无天日 读:Security-First CI/CD —— DevSecOps 自动化实践指南 TIL: 数字小键盘的小数点陷阱与行内算术求值 - 暗无天日 读:Immutability 不是万能药,它是一种权衡 - 暗无天日 Conducty:给 Claude Code 加上项目记忆和并行执行能力 - 暗无天日 读 — GitHub Trending 里的 Claude Code 技能包 读 — Prompt Caching 省钱指南 TIL: Emacs 中那些跟鼠标配合的冷门快捷键 - 暗无天日 读:Anvil——把 Emacs 变成 AI 的工具服务器 读:Emacs 代码折叠终极指南 - 暗无天日 读:Clojure 搭车客指南 - 暗无天日 git推送失败后恢复仓库损坏的完整记录 - 暗无天日 多智能体系统的两个有效模式——以及对 Claude Code 用户的启示 - 暗无天日 用 Org Babel 写 Literate 博文:扩展执行 + 定制导出 proced:Emacs 内置的进程查看器 - 暗无天日 从 proced 定制中学到的 Elisp 模式 读:让 Emacs proced 在 macOS 上显示 CPU 和内存 异步编程的函数着色税 - 暗无天日 链式调用的代价:JavaScript 和 Clojure 的共同教训 - 暗无天日 hyperfine:命令行基准测试工具 - 暗无天日 管道中的变量去哪了?——子 shell 作用域陷阱 - 暗无天日 开源包装器的信任陷阱:四个危险信号 - 暗无天日 程序员愿意为 AI 写文档,却不愿为同事写 - 暗无天日 mktemp: Shell 脚本中临时文件的安全陷阱与最佳实践 - 暗无天日 WSL9x —— 在 Windows 9x 里跑 Linux 内核 6.19 用 ox.el 做你想做的事 —— org-export 高级编程指南 读:Hot-wiring the Lisp Machine —— 用纯 Elisp 构建零依赖的 Org 静态站点生成器 Elisp 性能优化的六个实战教训 - 暗无天日 fcitx5 下 Emacs 无法切换输入法的排查 - 暗无天日 ERT 测试交互命令的三种方式 - 暗无天日 SEM Assistant: 当 Elisp 守护进程遇上 LLM 用 dmsg 给 Elisp 加上结构化调试日志 用 org-habit 追踪非每日习惯 - 暗无天日 Clojure X-Men:当编程语言特性变成超能力 - 暗无天日 TIL: 用 diff-hl 在 fringe 中显示 git 变更 读:llm-test —— 用 LLM agent 驱动 Emacs 测试 TIL: AI 时代的橡皮鸭调试 - 暗无天日 fcitx 启动后键盘输入卡顿的排查 - 暗无天日 TIL: 早期网页的图片热区导航 - 暗无天日 读 Seeing the Whole System 用 Emacs 自动生成每周链接推荐 - 暗无天日 读:ASCII control characters in my terminal 读 What to learn - 暗无天日 Lisp 的括号之痛——一个愚人节玩笑揭开的老伤疤 - 暗无天日 一本书该"线性读"还是"并行读" - 暗无天日 读 How to Monetize a Blog:一篇伪装成变现指南的讽刺文 Python Mock 第三方依赖的四种策略 - 暗无天日 Emacs Lisp 热重载实用指南 - 暗无天日 Prot 的 Emacs 配置哲学 - 暗无天日 TIL: 从直播对谈中学到的三个 Emacs 技巧 - 暗无天日 TIL: 自动使用项目虚拟环境的 Python - 暗无天日 TIL: 让 Help buffer 自动获得焦点 一条命令让本地开发用上 HTTPS —— slim 工具介绍 用 fsck 检查和修复 Linux 文件系统 排查Linux进程"卡死"实战:从strace到gdb全流程 - 暗无天日 PostgreSQL 索引:从基础到你可能不知道的高级用法 - 暗无天日 用 .pdbrc 自定义 Python 调试器 ANSI 转义码的标准化现状 - 暗无天日 终端程序的潜规则 - 暗无天日 PARA Org-mode 测试配置 - 暗无天日 AI越强越辣鸡?控制论说这是必然的 - 暗无天日 AI 越强越需要你盯着——反馈循环实操指南 - 暗无天日 你的AI代理正在偷你的密钥——四种你没想到的泄露通道 - 暗无天日 LLM 在 DevOps 中的三种角色 - 暗无天日 写作风格的反建议 - 暗无天日 反驳本质复杂性——Dan Luu 论为什么《没有银弹》错了 - 暗无天日 文件充满了危险——Dan Luu 谈文件系统的可靠性陷阱 - 暗无天日 AI 时代的 PARA 方法:用 Org-mode 和 AI 打造个人知识管理系统 Linux 数据去重学习笔记 - 暗无天日 创建跨平台 ZIP 文件的隐藏陷阱:Extra Field - 暗无天日 X11 Forwarding 排障指南 - 暗无天日 IP欺骗端口扫描:当别人冒充你去扫描别人 - 暗无天日 Linux 输入栈全景解析:从硬件按键到屏幕响应 - 暗无天日 Unix 系统中那些被埋没的配置开关——以 FontConfig 为例 - 暗无天日 在Linux上限制儿童使用电脑 - 暗无天日 GIF不仅仅是一种图片格式——用GIF流做些奇怪的事 - 暗无天日 Leiningen 学习笔记:Clojure 项目构建与管理从入门到实战配置 - 暗无天日 Google SRE Book 读书笔记 - 暗无天日 yes 管道 head 发生了什么 - 暗无天日 为什么 nohup 在 crontab 中不起作用 Bash中的Indirection与Nameref - 暗无天日 Linux PAM 简介 - 暗无天日 从Linux ISO文件启动计算机 - 暗无天日 用 Bash 打造一个Screen Locker 用GitHub Actions自动构建EGO博客 - 暗无天日 blocking I/O 的作用 - 暗无天日 mobileog 手机端同步提示Error:2 No such file 的解决方法 回收 WSL2 VHDX 文件占用空间 使用 org-mode columnview 生成任务列表 - 暗无天日 Emacs 作为 MPD 客户端 - 暗无天日 移动文件路径却不破坏org file link的方法 - 暗无天日 如何合理的导出help link 成HTML - 暗无天日 笑话理解之Biology - 暗无天日
读:用 LLM 重构遗留代码——三个陷阱与一套方法 - 暗无天日
2026-05-10 · via 暗无天日

Jubin Abhishek Soni 干了一件每个程序员都想干的事:把自己最烂的遗留代码丢给 AI,看它怎么收拾。

他把一个 2000 行的 Python 单体脚本喂给了 Gemini 3。这个脚本有个叫 process_claim() 的函数全塞在一个函数里——验证输入、连数据库、算税额、发邮件、写日志。代码注释里还有一句 // I am sorry 。他管这次实验叫"数字考古"。

AI 做了什么

Gemini 3 把这个函数拆成了四个独立类,每个只做一件事:

def process_claim(claim_data):
    if not claim_data.get("id"):
        return "Error"
    db = connect_to_db("prod_db")
    db.execute(f"INSERT INTO claims VALUES ({claim_data['id']})")
    total = claim_data['amount'] * 1.15
    send_email("admin@company.com", f"Claim {total} processed")
    return "Success"

class ClaimValidator:
    def validate(self, data):
        if not data.get("id"):
            raise ValidationError("Missing ID")

class TaxCalculator:
    def calculate(self, amount, region_code):
        rate = self._get_rate(region_code)
        return amount * rate

class ClaimService:
    def __init__(self, validator, calculator, repository, notifier):
        self.validator = validator
        self.calculator = calculator
        self.repository = repository
        self.notifier = notifier

    def execute(self, claim_data):
        self.validator.validate(claim_data)
        total = self.calculator.calculate(claim_data['amount'], "US")
        self.repository.save(claim_data)
        self.notifier.send(f"Claim {total} processed")

AI 用了哪几条原则?原文列了五条:单一职责(拆大函数)、依赖注入(类需要什么从外面传进来,而不是自己在内部创建)、防御式编程(捕获具体异常而不是 except: pass )、不可变状态(返回新对象而不是改全局变量)、现代语法。这些原则本身都是课本内容,不展开了。值得一张对比表快速过一遍:

方面 遗留做法 改后
逻辑 几百行的函数,if/else 嵌套七八层 短小的纯函数,用 early return 减少嵌套
数据 直接改全局状态 不可变数据 + 局部状态
依赖 类内部硬编码 new 构造函数注入
错误处理 except: pass 吞掉一切 特定异常类型 + 写日志 + 向上抛
文档 注释解释代码干了什么 好命名解释做了什么,注释解释为什么

看表比看五节文字高效。

关键是:AI 不是乱改的。它遵循了一套清晰的步骤。Soni 从这次实验中总结出的三个陷阱和一套方法,是本文真正要说的。

三个陷阱

陷阱一:没测试就重构

Soni 说这是最重要的教训。重构前必须先写特征测试(characterization test)。

很多人的直觉是:代码太烂了,先重构再补测试。这个顺序简直就是灾难。烂代码的"正确行为"往往不是设计出来的,而是历史沉淀出来的——某个边界条件在线上跑了三年没出过事,但你自己看代码根本看不出这个条件。重构的时候把它改掉了,上线就炸。

特征测试跟单元测试不一样:它不验证"结果对不对",只记录"当前行为是什么"。输入 X,当前输出 Y,记录下来。重构后输入同样的 X,输出还是 Y,就说明没改坏。

具体做法:从最常出问题的模块开始。跑一遍现有输入输出,把结果录成测试。然后用 LLM 重构这个模块,跑测试,通过就继续,不通过就回退。

陷阱二:过度工程化

LLM 重构的一个特别问题:AI 太喜欢上设计模式。你给它一段简单的 if/else,它可能还你一个策略模式 + 工厂模式 + 依赖注入容器,三重抽象套在一起。

Soni 发现 Gemini 3 也有这个倾向。原文里的代码被加了四个类和一个构造函数注入,在 2000 行的单体脚本背景下,这个抽象层级可能是合适的。但如果是 50 行的工具函数,同样的做法就是浪费。

原则很简单:只引入能解决当前问题的复杂度。简单函数不需要类,一个类不需要三层抽象。"万一以后要扩展呢"不是加抽象的理由。大部分"以后"根本不会来,真来了再改也来得及。

陷阱三:别一把梭全重写

这个陷阱对 LLM 重构尤其危险。"一把梭"的意思是:把整个项目全喂给 AI,期望它吐出一个完整的重构版。听起来省事,实际是给自己挖坑。

别这么干。Soni 说他见过的最惨案例就是团队把整个系统丢给 AI,拿回来一个不能跑的 Frankenstein。

正确做法:一次重构一个模块。改完就跑测试,确认系统还在跑。再改下一个。AI 能帮你加速每个模块,但控制节奏的是你。

一套方法

Soni 从实验中提炼了五个步骤,可以当作 LLM 辅助重构的标准流程:

  1. 找最痛的点 。不是先重构最好重构的,而是先重构出问题最频繁的那个模块。最痛的那个模块如果重构完确实变好了(bug 少了、改起来快了),说明这个方向对;如果连最痛的都救不回来,那换个思路。而且痛点一解决,效果立竿见影,团队也更愿意继续。
  2. 写特征测试把当前行为固定下来 。没有测试网,不敢跳。
  3. 把业务逻辑从基础设施里抽出来 。数据库连接、网络调用、文件读写,这些都算基础设施。核心计算逻辑抽成纯函数,它就不依赖环境,可以单独测。
  4. 引入依赖注入 。上一步抽出纯函数之后,原来那些依赖外部服务的地方改成从外部传进来。测试环境传 mock,生产环境传真实服务。
  5. 用新语法改善可读性 。Python 的类型提示、dataclass、async/await 等。这一步放最后,因为它改变的是可读性而不是结构,风险最小。

这套流程最妙的地方是每一步都是可逆的。改到第三步觉得不对劲,可以停下来,系统仍然正常工作。不会出现"重构了一半,旧代码删了,新代码没跑通"的绝境。

Soni 用这段经历说了句大实话:把烂代码喂给 AI 之后,最大的收获不是 AI 帮你改了代码,而是 AI 逼你面对自己逃避的工程纪律。没有测试、职责不清、全局变量满天飞——这些不是新技术问题,是你一直知道但懒得修的问题。AI 只是让你没法再糊弄过去而已。

附录:用 LLM 生成特征测试

回头看你可能在想:特征测试得写一堆用例,自己写也太累了。能不能让 LLM 帮写?能,而且操作很自然。三步走。

第一步:喂代码,让 AI 找分支

process_claim() 的源码贴给 LLM,问:这个函数有哪些输入会导致不同的执行路径?列出所有分支条件和对应的输入用例。

AI 会扫出三条:

  • claim_data 没有 "id" 字段 → 走 return "Error" 分支
  • claim_data"id" → 走数据库写入 + 税额计算 + 发邮件分支
  • amount 值不同 → 税额不同(1.15 倍率)

第二步:你在本地跑一遍,拿真实输出

这一步不能省。LLM 可以猜输出,但猜的是"应该是"而不是"实际是"。遗留代码的"实际行为"经常跟任何人猜测都不一样。

输入 {"amount": 100} (没有 id),实际输出 Error —— 好,记录。输入 {"id": "A001", "amount": 200} ,实际输出 Success ,税额是 230 —— 好,记录。把这些输入和实际输出整理成一张表,交还给 LLM。

第三步:让 LLM 生成测试框架

把输入输出表连同原始函数一起给 LLM,说:生成 pytest 测试,assert 值严格匹配这些输出。

import pytest

def test_process_claim_missing_id():
    """输入缺 id → 当前返回 'Error'"""
    result = process_claim({"amount": 100})
    assert result == "Error"

def test_process_claim_normal():
    """正常输入 → 当前返回 'Success'"""
    result = process_claim({"id": "A001", "amount": 200})
    assert result == "Success"

def test_process_claim_tax_calculation():
    """税额 = amount * 1.15,需要 mock 掉 DB 和邮件才能验证"""
    pass  

跑一遍,全绿。此后你对这个模块做任何修改,测试红了就知道改出问题了。

一个重要限制

上面=process_claim()= 内部调了 connect_to_db()send_email() ,本地根本没有这些函数。这种情况下有两个选择:

  • 把纯计算逻辑先抽出来(税额计算 amount * 1.15 ),只给纯函数写测试。这是最干净的做法。
  • 让 LLM 生成 mock,但 mock 的行为是 LLM 猜的,不是真实行为。如果你想让测试真正可靠,mock 的输入输出映射需要去线上日志里查。

本质上 LLM 帮你做了两件事:分支分析(代替人工看代码)和样板代码生成(代替手写测试框架)。但输入输出映射这一环,机器替你跑不了。