🏭导航收藏不迷路—>制造业数据与AI践行者老蒋的技术博客全系列文章汇总（持续更新）
| 专栏 | WorkBuddy工作场景应用实践 · #04 |
| 系列 | 【场景实战】这是「WorkBuddy 工作场景应用实践」的第 4 篇。前三篇我们分别用它搞定了 CSDN 数据分析、截图批量重命名、Git 日志自动周报，今天聊聊更硬核的场景：AI 辅助代码审查。 |
| 关联主文 | 我用 WorkBuddy 分析了 30 篇 CSDN 博客，发现 3 个反直觉的流量真相 |
📝 文章摘要
针对团队代码审查 “说轻了没用、说重了得罪人” 的痛点，本文分享用 WorkBuddy 做第一轮 AI 代码审查的完整实战流程。覆盖 6 个审查维度、P0-P2 分级问题清单、代码补全与验证闭环，附可直接复用的审查 Prompt 模板，既提升审查效率，也避免人际尴尬。
目录
一、开篇：代码审查的“恶人困境”
兄弟们，问你们一个扎心的问题：
团队里让你做代码审查，你一般怎么说？
“这个地方写得不错，但建议优化一下”——这是客套话，说了等于没说。
“这个变量命名不规范，这个异常没捕获，这个逻辑有漏洞”——这是实话，但说多了你就是“那个挑刺的人”。
作为一个在IT混了十几年的老家伙，我太了解这种尴尬了——技术上都懂，人情上很难。说轻了没用，说重了得罪人。
而且还有一个更现实的问题：你真有时间一行一行看吗？
我上个月发了#01源码（CSDN后台数据分析系统），评论区不少兄弟在问代码能不能分享、能不能跑通。我当时就想——这套代码我自己跑过，但到底写得怎么样？有没有隐藏问题？
我决定换个玩法：让WorkBuddy先扛第一轮火力。
二、素材准备：三个Python文件
我选了之前发布的#01源码文章里的三个核心文件：
| 文件 | 职责 |
|---|---|
config.py | 统一配置入口（路径/字段/Sheet定义） |
import_data.py | 数据导入引擎（增量合并+归档+生成看板数据） |
start_dashboard.py | 本地服务启动器（离线静态服务） |
缺一个 index.html（HTML太长了，文章里没贴）。
正好——让WorkBuddy不仅审查，还帮我把缺的补上。这就叫“查漏补缺”。
三、第一轮：代码审查（6个维度）
我把三个Python文件丢给WorkBuddy，输入了下面这个Prompt：
【可直接复制・代码审查 Prompt】
请审查以下三个Python文件，它们是一个CSDN后台数据分析系统的核心模块。
文件列表：
1. config.py - 统一配置入口
2. import_data.py - 数据导入引擎
3. start_dashboard.py - 本地服务启动器
请从以下维度进行审查：
1. 代码规范（命名、格式、类型注解）
2. 异常处理（是否完善、是否结构化）
3. 日志记录（是否分级、是否可追溯）
4. 配置管理（是否硬编码、是否可扩展）
5. 跨平台兼容性（Windows/Linux路径处理）
6. 三个模块之间的接口设计是否合理
输出格式：
## 审查概览
[整体评价]
## 各文件详细审查
### config.py
- 优点：...
- 问题：...
- 改进建议：...
### import_data.py
...
### start_dashboard.py
...
## 综合改进建议
[优先级排序的改进清单]然后WorkBuddy给出了一份让我意外的审查报告。
四、审查报告（完整呈现）
整体评价
代码质量中上，工程化意识较好。三个模块职责清晰、接口设计合理，
pathlib.Path统一贯穿、异常处理有结构化返回（{ok, error, suggestion}）。但存在专栏归属不一致、日志配置重复、os.chdir副作用、硬编码散落等几个问题，修复后可达到专栏发布标准。
各文件详细审查
config.py
优点：
-
pathlib.Path统一跨平台路径，目录分层清晰（data→inbox/master/archive） -
.env注入格式正确，load_dotenv()不存在时不报错 -
按“路径/文件/Sheet字段/运行”分模块分组，注释可读性良好
-
常量命名全大写 + snake_case，符合规范
问题：
| 优先级 | 问题 | 说明 |
|---|---|---|
| P0 | 专栏归属错误 | 文件头写 [Python实践学习笔记]，规范要求为 AI赋能数据开发工程手册 |
| P1 | DEFAULT_PORT 无异常保护 | int(os.getenv("...")) 当环境变量为非法字符串时直接抛 ValueError |
| P2 | 缺少环境依赖 Requirements 块 | 规范要求 Python 3.10+ 及关键库版本 |
| P3 | .resolve() 冗余 | Path(__file__).parent.resolve().parent 中 .resolve() 无实际效果 |
改进建议：
# DEFAULT_PORT 加 try/except 兜底
_port_raw = os.getenv("CSDN_DASHBOARD_PORT", "8777")
try:
DEFAULT_PORT = int(_port_raw)
except ValueError:
DEFAULT_PORT = 8777import_data.py
优点：
-
文件头 + 环境依赖 + 类型注解齐全，符合V1.2规范的主体要求
-
run_import返回结构化{ok, error, suggestion}，可被AI Agent安全调用 -
增量合并逻辑正确（主键去重 +
keep="last"），新增/更新统计数据可靠 -
日期清洗
norm_date用正则优先 + pandas兜底，覆盖中文/分隔符两类格式 -
read_master_sheet单点封装，主库缺失时安全降级为None -
导入异常不会中断整体流程（单文件失败 → 跳过 + 记日志 + 继续）
问题：
| 优先级 | 问题 | 说明 |
|---|---|---|
| P0 | 专栏归属错误 | 同上，需改为 AI赋能数据开发工程手册 |
| P1 | 指标列名硬编码散落 | clean_daily 中硬编码 ["阅读量", "评论数", "粉丝数", "收藏数"]，clean_article 中硬编码 ["展现量", "阅读量", "评论数", "收藏数", "关注数"]，应从 DAILY_COLS / ARTICLE_COLS 动态提取 |
| P1 | 重复导入风险 | archive_file 只复制不删除源文件，若用户重复运行，同一文件会被重复导入（因为archive中timestamp前缀不同但源文件还在inbox） |
| P2 | 主库写入非原子 | write_master 直接用 pd.ExcelWriter 覆盖 MASTER_XLSX，若写入中途崩溃，原主库丢失 |
| P3 | 部分子函数无独立异常保护 | archive_file、export_data_js 依赖上层 try/except，若被单独调用缺少保护 |
改进建议：
# 指标列名从 config 动态提取
METRIC_COLS_DAILY = [c for c in DAILY_COLS if c not in KEY_DAILY]
METRIC_COLS_ARTICLE = [c for c in ARTICLE_COLS if c not in KEY_ARTICLE]
# 导入成功后删除 inbox 源文件（归档已留存）
path.unlink()start_dashboard.py
优点：
-
零第三方依赖（仅标准库），满足“完全离线”约束
-
端口绑定
127.0.0.1，不暴露局域网，安全性好 -
OSError/KeyboardInterrupt都有友好捕获和处理 -
浏览器打开失败静默降级，不中断服务
-
main函数接收argv参数，便于测试
问题：
| 优先级 | 问题 | 说明 |
|---|---|---|
| P0 | 专栏归属错误 | 同上 |
| P1 | os.chdir() 副作用 | os.chdir(os_chdir_target) 改变全局进程工作目录，若后续代码依赖原工作目录会出错 |
| P2 | 日志级别硬编码 | configure_logging() 中 level 固定为 logging.INFO，未读取 config.LOG_LEVEL |
| P2 | 类型注解不完整 | handlers: list 未参数化（应为 list[logging.Handler]），argv: list 同理（应为 list[str]） |
| P2 | 日志配置代码重复 | configure_logging() 与 import_data.py 几乎完全重复，应提取到 config.py 或独立模块 |
改进建议：
# 替换 os.chdir 为 directory 参数（Python 3.7+）
import functools
handler = functools.partial(
http.server.SimpleHTTPRequestHandler,
directory=str(DASHBOARD_DIR)
)综合改进建议（按优先级排序）
| 优先级 | 改进项 | 涉及文件 | 工作量 |
|---|---|---|---|
| P0 | 专栏归属统一为 AI赋能数据开发工程手册 | 全部3个 | 3行改动 |
| P1 | os.chdir() 替换为 directory 参数 | start_dashboard.py | 2行 |
| P1 | 指标列名从 config 动态提取，消除硬编码 | import_data.py | 4行 |
| P1 | 导入后删除 inbox 源文件，防止重复导入 | import_data.py | 3行 |
| P1 | DEFAULT_PORT 转换加 try/except 兜底 | config.py | 5行 |
| P2 | 主库写入先写 .tmp 再 rename（原子化） | import_data.py | 5行 |
| P2 | 日志配置提取为公共函数 | config.py + 2模块 | 10行 |
| P2 | 补全 list[str] / list[logging.Handler] 类型注解 | start_dashboard.py | 3行 |
| P3 | config.py 补充 Requirements 块、去掉 .resolve() | config.py | 3行 |
五、为什么这份审查报告质量高？
兄弟们，我见过太多代码审查工具了——它们能检查语法错误、能检查格式问题，但它们不理解代码的“意图”。
WorkBuddy这份报告强在三个地方：
| 亮点 | 说明 |
|---|---|
| 理解“为什么这么写” | 它能识别 {ok, error, suggestion} 是为了让AI Agent安全调用，而不是“随便写了个返回结构” |
| 理解“跨平台坑在哪” | 它能指出 os.chdir() 的副作用，知道Windows路径和Linux路径的差异 |
| 理解“数据流” | 它能发现“列名硬编码”的问题——这需要对数据清洗流程的理解，不是简单的字符串匹配 |
架构层面的判断也很准：
“三个模块的接口设计整体合理——config纯常量、import管线化、dashboard单服务，职责无交叉，
run_import的结构化返回是亮点。”
这不是“工具”能说出来的话，这是“有经验的架构师”才能给出的判断。
六、第二轮：代码补全
审查完三个Python文件后，我又让WorkBuddy做了一件事：
“基于这三个文件的逻辑，补全缺失的
index.html。”
结果如何？
WorkBuddy输出了一个完整的 index.html，包含：
| 模块 | 说明 |
|---|---|
| KPI卡片 | 累计阅读量、文章总数、累计评论、累计收藏（自动计算） |
| 阅读趋势图 | ECharts折线图，含阅读/评论/收藏/粉丝四条曲线 |
| 文章Top10 | 按阅读量排名的条形图 |
| 雷达图 | Top5文章在展现/阅读/评论/收藏/关注五个维度的对比 |
| 每日明细表 | 按日期倒序展示每日指标 |
| 文章明细表 | 按阅读量倒序展示文章详情 |
| 手动导入 | 用SheetJS支持拖入Excel文件（后备方案） |
关键特性：
-
依赖库完全本地化（
lib/目录），0网络请求 -
支持
window.CSDN_DATA自动加载 -
支持手动导入Excel作为后备
-
UI风格匹配专栏品牌色
七、第三轮：验证——发现并补齐依赖
HTML生成后，我双击打开 index.html，页面报错：
依赖缺失
请将echarts.min.js放入lib/目录。
这不科学啊😀😀😀...... 代码写了，但依赖库没补齐，页面跑不起来。
我把报错信息丢给WorkBuddy，它立刻识别了问题——index.html 引用了两个第三方库，但 lib/ 目录是空的：
| 依赖库 | 版本 | 大小 | 用途 |
|---|---|---|---|
echarts.min.js | v5.5.0 | 1.0 MB | ECharts图表引擎 |
xlsx.full.min.js | v0.20.1 | 923 KB | SheetJS Excel读写 |
WorkBuddy帮我把这两个库下载到了 lib/ 目录。再次打开 index.html，页面正常渲染，所有图表、表格、交互全部可用。
这时我才意识到：WorkBuddy补全代码的能力，不只是“写代码”——它还能理解“代码需要什么才能运行”，并补齐缺失的资源。
八、关于 index.html 的源码
由于 index.html 代码较长，这里只展示核心架构。完整代码已随文章发布，需要的兄弟评论区留言“要HTML”即可获取。
核心代码结构：
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<!-- 依赖：lib/echarts.min.js + lib/xlsx.full.min.js -->
</head>
<body>
<!-- Header：标题 + 数据状态 -->
<!-- KPI卡片：4个核心指标 -->
<!-- 趋势图：ECharts折线图 -->
<!-- Top10排名 + 雷达图 -->
<!-- 明细表：每日 + 文章双Tab -->
<!-- 手动导入：SheetJS后备方案 -->
<script>
// 数据加载：优先 window.CSDN_DATA，后备手动导入
// 图表渲染：ECharts 5.x
// 表格渲染：纯JS + DOM
</script>
</body>
</html>两种数据加载方式：
-
自动：
import_data.py生成dashboard/data.js（window.CSDN_DATA），双击index.html直接显示 -
手动：页面底部「📥 手动导入 Excel」直接上传CSDN导出的
.xlsx，自动识别合并
九、核心收获
| 序号 | 收获 |
|---|---|
| 1 | WorkBuddy做代码审查，是真能看懂代码。不是简单的“格式检查”，是“意图理解”——能指出 {ok, error, suggestion} 是为AI Agent设计的，也能指出 os.chdir() 的跨平台风险 |
| 2 | 审查报告的价值在于“分级”。P0（必须改）vs P1（建议改）vs P2（可优化）——有了优先级，你才知道先修什么，而不是面对一堆意见无从下手 |
| 3 | 补全代码这事，有前提。WorkBuddy生成的 index.html 是基于三个Python文件的逻辑反向推导的——如果代码逻辑不清晰，它也没法推导。所以它其实是在“验证”代码的可理解性 |
| 4 | 验证环节不可或缺。WorkBuddy能生成代码，也能帮你补齐依赖——你只需要把报错信息丢回去，它能识别“缺了什么”并给出方案。这是一个闭环：生成 → 验证 → 补齐 |
| 5 | 代码审查最怕的是“看完了等于没看”。WorkBuddy给的每一条意见都具体到文件、到行、到改进方案，你照着改就行 |
十、实在人总结
怕你忘了，我再啰嗦一遍😀😀😀：
1. WorkBuddy做代码审查，是真能看懂代码。 不是简单的“格式检查”，是“意图理解”。它能指出 {ok, error, suggestion} 是为了AI Agent设计的，也能指出 os.chdir() 的跨平台风险。
2. 审查报告的价值在于“分级”。 P0（必须改）vs P1（建议改）vs P2（可优化）——有了优先级，你才知道先修什么。
3. 补全代码这事，有前提。 WorkBuddy生成的 index.html 是基于三个Python文件的逻辑反向推导的——如果代码逻辑不清晰，它也没法推导。所以它其实是在“验证”代码的可理解性。
4. 验证环节是闭环的关键。 代码生成后，跑一遍、报错、丢回去、补齐依赖——这是一个完整的“生成→验证→补齐”闭环。别以为生成完就结束了，验证才是分水岭。
5. 代码审查最怕的是“看完了等于没看”。 WorkBuddy给的每一条意见都具体到文件、到行、到改进方案，你照着改就行。
补充说明：AI 代码审查适合做规范性、异常处理、代码风格这类常规问题的第一轮筛查，核心业务逻辑、架构设计类的问题，依然需要人工最终把关。AI 做的是 “兜底扫雷”，人做的是 “价值判断”。
十一、评论区炸弹
兄弟们，我这篇把WorkBuddy的审查报告完整公开了——有优点、有问题、有分级、有改进建议。
现在轮到你们了：
你在代码审查中遇到最尴尬的事是什么？
A. 挑完毛病对方不服，吵了一架
B. 自己写的代码被人当面指出低级错误
C. 根本没人审查，代码直接上线
D. 我从来不写代码审查（你是老板吧？）评论区扣一个，我选3位兄弟，送一份Prompt模板——就是我这篇用的那个审查Prompt。
够意思吧？评论区见！👇
📎 系列导航
| 上一篇 | #03 周五下午别再翻git log了！WorkBuddy帮我自动生成周报 |
| 下一篇 | #05 《制造MES工时异常检测：AI帮我2小时干完Excel 2天的活》 |
📌 本文所用代码源自#01源码首发文章，审查报告为WorkBuddy真实输出。完整的审查报告、补全的
index.html和依赖库已随文章公开。需要的兄弟评论区留言即可。
扫一扫
786
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
