用 Python 写 AI 辅助工具:从命令行小工具到团队内部效率平台

但真正落到日常流程里，你会发现还有一堆更细碎的需求：PR 太长没人想看，线上日志报错没人第一时间归类，业务同学看不懂 SQL，项目文档永远落后于代码。

这些事不一定适合塞进 IDE。它们更像团队内部的小工具。

而 Python，还是很适合干这个活。

先从命令行小工具开始

不要一上来就做平台。

最稳的方式，是先写几个命令行工具，把高频场景跑通。

比如代码审查摘要：

ai-review --pr 2381

输出内容可以很简单：

变更范围：
- 修改订单退款流程
- 新增异常重试逻辑

需要关注：
- refund_service.py 中重试没有最大次数限制
- migration 脚本缺少回滚说明

背后逻辑也不复杂：

diff = get_pr_diff(pr_id)
prompt = f"请总结这段代码变更，并指出风险点：\n{diff}"
result = llm.chat(prompt)
print(result)

别小看这种小工具。

它不需要改变团队流程，也不需要培训所有人。只要一个开发者觉得有用，就能先跑起来。

哪些场景最适合先做

我建议优先选“输入明确、输出可校验”的场景。

这些场景有一个共同点：AI 不需要替你做最终决策，只负责把信息整理得更好读。

这很关键。

如果一开始就让 AI 自动改代码、自动发版、自动操作数据库，风险会很高。先让它“读”和“解释”，比直接让它“执行”靠谱得多。

什么时候需要队列

命令行工具跑多了，很快会遇到一个问题：慢。

PR diff 长一点，日志多一点，LLM 调用就要等几十秒。更麻烦的是，多个人同时用，很容易触发限流。

这时候可以加队列。

一个简单结构是这样：

用户请求
  ↓
任务入队
  ↓
Worker 调 LLM
  ↓
结果写入数据库
  ↓
用户查询结果

Python 里可以用 Celery、RQ，也可以先用 Redis Stream。别一开始就追求架构漂亮，能稳定消费任务就行。

队列解决的不是“高级架构”问题，而是两个很现实的问题：

第一，用户不用一直等在页面前。

第二，失败任务可以重试，不至于一次 API 抖动就全挂。

缓存比你想的重要

很多 AI 工具刚上线时，最先烧钱的不是复杂推理，而是重复请求。

同一个 PR，被 5 个人点开 5 次。

同一段 SQL，被不同人解释好几遍。

同一个错误日志，每次发布后又被重新分析。

这些都应该缓存。

缓存 key 可以粗暴一点：

key = sha256((task_type + input_text + prompt_version).encode()).hexdigest()

这里有个容易忽略的点：要把 prompt_version 放进缓存 key。

因为你后面一定会改提示词。提示词变了，旧缓存就不一定可信。

缓存不是为了炫技，是为了省钱、提速，也让结果更稳定。

权限控制不能最后再补

内部 AI 工具最容易被低估的，是权限。

比如日志分析工具，里面可能有手机号、token、订单号。

SQL 解释工具，可能接触到真实表结构。

代码审查工具，可能包含还没发布的业务逻辑。

所以从第一版开始，就要有基本边界：

谁可以用
能看哪些项目
输入内容是否脱敏
结果保留多久
调用记录是否可审计

尤其是脱敏，别完全指望模型“不要泄露”。在请求 LLM 之前，先用规则把敏感字段处理掉。

比如：

text = re.sub(r"1[3-9]\d{9}", "[PHONE]", text)
text = re.sub(r"Bearer\s+[A-Za-z0-9._-]+", "Bearer [TOKEN]", text)

这类规则不完美，但比没有强很多。

从工具到平台，差别在哪里

当命令行工具被越来越多人使用，就可以考虑做成内部平台。

平台不一定复杂，核心就是把能力收拢起来：

前端页面：提交任务、查看结果
API 服务：鉴权、参数校验、任务创建
任务队列：异步执行
Worker：调用 LLM、写结果
数据库：任务记录、结果、审计日志
缓存：减少重复调用

技术栈可以很朴素：

• FastAPI 做接口
• Redis 做队列和缓存
• Postgres 存任务与结果
• Celery 或 RQ 跑 Worker
• 公司统一登录做鉴权

真正难的不是选型，而是把流程嵌进去。

比如 PR 页面里加一个“生成审查摘要”按钮；日志平台里加一个“分析这段错误”；数据库管理后台里加一个“解释 SQL”。

工具离工作流越近，越容易被用起来。

一个容易踩的坑：别把 AI 包得太神

内部 AI 工具最忌讳包装成“智能专家”。

更合适的定位是：它是一个整理信息的助理。

所以输出里最好保留不确定性：

可能原因：
1. Redis 连接超时
2. 上游服务返回 502

建议先检查：
- redis_pool 当前连接数
- 最近 10 分钟 gateway 错误率

不要让它直接下结论：

事故原因是 Redis 故障。

除非你有足够的监控数据支撑。

AI 工具越贴近生产系统，越要克制。少一点“自动判断”，多一点“辅助排查”。

最后给一个落地顺序

如果你的团队想做这类工具，可以按这个顺序来：

1. 先做一个命令行工具，只解决一个场景
2. 加日志，记录输入长度、耗时、失败原因
3. 加缓存，避免重复请求
4. 加队列，处理慢任务和并发
5. 加权限和脱敏
6. 最后再做 Web 页面和团队入口

别一开始就想着“AI 效率平台”。

先让一个小工具真的省下 10 分钟，再谈平台化。

Python 的优势就在这里：它不要求你先搭一个很重的系统。几十行脚本可以开始，几百行代码可以内部试用，等需求确定了，再慢慢补队列、缓存、权限和审计。

AI 编程辅助不只在编辑器里。

很多时候，真正有价值的工具，藏在团队每天重复三遍、没人愿意手动处理的小流程里。