线程同步原语原理与实战：互斥锁、条件变量、信号量
2026/10/8 23:56:09
AI使用心得7 — 当AI开始参与「设计」：平台从0到1、skills过拟合与RAG的细活
说明：文中涉及的项目名称、客户信息与外部平台均已做脱敏处理，统一以「某XX项目」代称，技术思路与经验不受影响。
一、新平台从0到1：AI 当"设计评审"
1.1 背景
这次是一次平台化重构，不是改功能：把原来散落在某个老项目里的能力抽出来，做成通用的数据治理平台。四大模块职责大致是：
| 模块 | 内容 |
|---|---|
| 模块一 | 各类数据源的连接与元数据管理 |
| 模块二 | 采集任务的编排与调度 |
| 模块三 | 模型定义与字段映射 |
| 模块四 | 时序数据处理规则（重采样、降采样、异常值填充等） |
工程侧还做了一次彻底剥离：所有工程去除旧业务包名的依赖，统一转成平台自己的服务名。
1.2 AI 在这里做了什么
设计阶段我基本是这么用它的：
- 把想法结构化：我口述"数据源这一块大概要管这些"，它输出功能清单 + 数据结构初版，我再改
- 补专业参数：时序数据的处理规则（重采样窗口、降采样策略、异常值填充方式），它一次给出几套可选方案和各自适用场景
- 反复评审：每轮交流完就改设计文件，前后迭代了五六版
1.3 心得：AI 在设计阶段的角色是"评审"，不是"架构师"
它不替你决定架构——模块怎么切、边界怎么定，这些还得你自己拍。但它有两个价值很实在：
- 把模糊想法变成可讨论的结构。你自己脑子里想"大概要这样"，和看到一份写出来的功能清单，质量完全不是一回事
- 强制补全"你以为不用说但其实得写"的部分。设计文档这种给别人看的东西，最容易漏的就是那些"默认大家都知道"的约定，AI 生成时会把它显式写出来
设计阶段是我这个月感受到 AI 性价比最高的场景之一——因为它产出的是"可以讨论的草稿"，而不是"需要你逐行检查的代码"。草稿错了改起来便宜，代码错了改起来贵。
二、反爬对抗：AI 能给方案，但"值不值"的判断在你
2.1 这个月采集工作占了 52.1h
四条业务线并行，进度大概是：
| 目标 | 进展与卡点 |
|---|---|
| 某汽车养护平台 | 找到可用版本→移动端自动化采集开发（滑动商品规格的交互花了很多时间）→实测约 480 条/天/设备；遭遇 6 个账号同时封号，怀疑设备标识被标记 |
| 某电商平台A | V1 从详情页取商品 ID（每次只能拿 7 条）→发现列表页就有该 ID，一次可取数十个；遭遇短封与软屏蔽；公有云机器可用但新账号实名认证受限 |
| 某电商平台B | WEB 页面采集起步→脚本化改造 |
| 某车企官网 | 日常运维；修复 token 过期未报错导致数据被跳过的问题 |
中间还有几个哭笑不得的插曲：安卓开发板一用就弹出、旧手机是鸿蒙系统没法连调试、怀疑是设备问题结果最后发现是连接线的问题。
2.2 一个静默失败的教训
其中一条线有个数据质量问题：token 过期时没有报错，导致那批数据被直接跳过了——表面上采集任务成功、数据也交付了，实际是残缺的。后来重新补采才发现。
心得：采集脚本必须显式处理失败。报错不可怕，静默跳过才可怕——你会拿到一份"看起来完整其实是残缺的"数据，并且很久之后才发现。这个问题是 AI 在帮我 review 脚本逻辑时提出来的，我自己看代码时完全没意识到"没报错"也是个问题。
2.3 心得：技术之外是成本博弈
AI 能给技术方案——自动化脚本怎么写、接口怎么分析、策略怎么调。但采集的瓶颈从来不是"能不能拿到"，而是"拿到的成本是否可持续"：
- 封号风险要不要冒？
- 为了 480 条/天的数据，值不值得投入一台设备 + 一个人运维？
- 是继续硬扛风控，还是换个数据源/换种合作方式？
这些"账单"只有你知道，AI 算不出来。它能回答 How，但 Should 在你手上。
三、skills 产品化：AI 生成的规则会过拟合
这是本月我觉得最有意思的一个发现。
3.1 过程
某健康数据项目的 skills（菌群指标→健康效应链路）这个月从"能跑"走向"能交付"：
- 交叉验证：在两个不同的 AI 工具里对比运行并协同优化；针对贫血、高血压、肥胖、肝硬化四个方向，分别用两个不同的大模型跑，结果都 OK
- 可视化改造：和同事讨论后确认输出要更可视化——改列表字段展示顺序、推荐值计算方式
- 纳入知识库平台：可行性研究结论可行并完成实施
- 智能体化：把 skills 转成智能体，嵌入问答后能直接生成可下载的 PDF 报告
3.2 关键发现：AI 自动生成的 skills 定义文件会过拟合
在测试优化阶段我翻看 AI 自动生成的 skills 定义文件，发现它针对特定问法做了过度拟合——对当前这批测试问题回答得很漂亮，但换个问法就不一定了。
原因不难理解：它优化的目标就是"让这批 case 通过"，自然会把这批 case 的表达特征写进规则里。
处理方式：做了一个新版本，尽可能减少对特定问法的依赖。
3.3 部署的两个小坑
- PDF 生成失败：服务器上尝试在容器镜像里内置浏览器生成 PDF 一直有问题，最后引入了一个 html 转 pdf 的依赖包解决
- 不该出报告时也出报告：非相关领域的问题也会生成 PDF 报告，正在尝试用意图识别来做前置判断
3.4 心得：让 AI 生成"规则/配置/提示词"，过拟合是必然的
这是我认为本月最值得记的一条经验。凡是让 AI 生成规则类内容（skills 定义、prompt、配置模板、规则引擎的规则集），它天然会优化"当前这批输入"，把特征写死。
应对方式有两个，这次都用了：
- 多模型 + 多场景交叉验证（两个大模型 × 四个方向）
- 生成时就明确要求"不要针对特定问法"
这个坑我估计以后在 prompt 工程、规则引擎配置上还会遇到——凡是"AI 生成的规则"，都要做泛化性检查。
四、RAG 的细活：天花板在"检索到什么"
三个小案例，都是"改一点点，效果好一大截"的类型。
某知识库项目（2.2h）：文件解析时把文件名录入 meta-data，并修改 RAG 检索逻辑让文件名也参与检索。这个改动是针对"某古籍书名 + 条目"这类按书名提问的场景——之前文件名根本不在索引里，问书名当然检索不到。已线上验证通过。
某健康数据项目：问答里，如果查询没命中数据，原本会走一个兜底逻辑，给出很离谱的结果（某种程度上像"问 A 答 B"那种答非所问）。已修改兜底策略。
某产品问答智能体：优化"1"这种无意义字符的回答逻辑；优化"你能做什么"这类非产品问题的回答（改完还让 AI 造了一批同类问题来验证）。
心得：RAG 效果不好时，第一反应总是"换个更强的模型"，但真正的瓶颈往往在**“检索到了什么”**——
- 文件名没进索引 → 问书名检索不到
- 兜底逻辑没改 → 未命中就给荒谬答案
- 意图没分流 → 瞎聊也走正式流程
这些都不是模型能力问题，是工程细节。RAG 的天花板，通常卡在检索侧和边界处理上，不在生成侧。
五、本月总结：四条新认知
5.1 设计阶段是 AI 性价比最高的场景之一
它产出的是"可讨论的草稿"，改起来便宜。相比让它写完整代码，设计协作的容错率高得多。
5.2 AI 生成的"规则类"内容天然过拟合
skills 定义、prompt、配置模板、规则集——凡是规则类输出，都要做泛化性检查。多模型 + 多场景交叉验证是最省事的办法。
5.3 采集和 RAG 的瓶颈，常在细节而非模型
文件名进索引、兜底逻辑、失败显式化——这些"不性感"的工程细节，决定了最终效果的上限。
5.4 静默失败比报错危险得多
采集脚本、数据同步任务里，凡是"没报错但也没干活"的路径，都要显式暴露出来。这是本月收获最实用的一条。