我和 AI 给一个运行了 7 年的生产系统设计了一套 AI 方案，但没法落地——想找个项目一起做
即是分享贴，也是记录贴。
简单说下背景
我是一个后端开发，做 Java 和 SAP Hybris 的。我们公司有个运行了很多年的订单管理系统，代码量大概 10 万行，对接了十几个电商平台，背后有四五个独立服务在协作。
前段时间我突发奇想——能不能给这个系统加一个 AI 客服，让客服不用在四五个系统之间跳来跳去查订单状态、查日志、查物流。我几乎没有任何 AI 背景，全程靠一个 AI Agent 配合，花了两周左右，把这套方案从 0 设计到了可以拿去汇报的程度。
但是——我们没法落地。 公司出于业务和安全考虑，不可能让一个个人发起的 AI 项目接入生产系统。我们没有开发环境、没有测试数据、甚至没法本地跑起来验证任何一个假设。
所以我想找一个有真实业务系统的个人或小团队——你的项目我们来做 AI 改造，作为交换，你提供真实的业务场景和数据。
我们做了什么
最开始以为"做个 RAG 就行"，读了代码才发现完全不是
和大多数人一样，我们的第一反应是：上传 SOP 文档 → AI 检索 → 回答问题。一个 RAG 聊天助手。
但实际读了代码之后发现——这个系统不是单体，是四个独立服务协作：
▼text复制代码订单聚合服务 ──→ 订单管理系统 ──→ 寻源引擎 ──→ 仓库中间层 ──→ 仓库 (十几个平台) (SAP Hybris) (Redis Queue) (黑盒，无源码)
一个"订单为什么没发货"的问题，瓶颈可能在四层中的任何一层。光靠 RAG 检索文档回答"请检查订单状态和物流"——这解决不了任何实际问题。
所以架构从"LLM + RAG"变成了"LLM + 多数据源工具 + RAG 辅助"：
- 开发了一套 Tool Server（Java Spring Boot），通过 MySQL 只读查询对接四个服务的数据
- 工具不按系统分、按诊断链路分：查订单→查配货→查寻源→查日志→查仓库回传
- 对于拿不到源码的"仓库中间层"，设计了一套黑盒观测方案——不猜内部状态，只通过外部接口日志和状态变更推断
方案经历了 16 轮 AI 交叉审查——是真的查出问题，不是自我感动
这个方案不是一稿过的。我们用 AI Agent 做了多轮交叉审查，每轮 3-4 个 Agent 同时从不同角度审同一份方案：
| 审查视角 | 发现的问题（举例） |
|---|---|
| 源码准确性 | 方案里写了 4 个 Controller 名字，实际代码里根本不存在——纯幻觉 |
| 内部一致性 | 技能提取的触发条件在文档三个不同位置写了三个不同的规则（单次/3次/多层） |
| 开源对齐 | 我们管自己的 REST API 叫"MCP"——但 MCP 标准是 JSON-RPC 2.0，完全不是一回事 |
| 集成可行性 | 方案写了 "用 FlexibleSearch 查数据"——但 FlexibleSearch 是 Hybris 内部 API，独立服务根本调不到 |
| 合规安全 | PIPL 数据出境风险、Prompt Injection 完全没有防护 |
最大教训：前几轮审查全通过了，因为审查用的"代码库文档"也是 AI 生成的，审查也是 AI 做的——同义反复，看不出问题。后来改成直接审查真实 .java 源文件，立刻发现了 3 个严重问题。这事让我们对"AI 审 AI"的边界有了非常具体的感知。
配套产出——不是只有架构图
整个过程产出了 27 个文档，按目录分类：
- 顶层设计：方案从 v1 到 v4 四个版本，29 项变更记录（每一项写明了为什么变、怎么变、有什么好处）
- 性能设计：并发规模估算、延迟优化、工具并行策略、压力测试方案
- SOP 知识体系：从老员工脑子里挖知识→AI 生成 SOP 初稿→人工审核→RAG 命中率测试→自动孵化可执行 Skill 的完整闭环
- 合规安全：Prompt Injection 五层防护、数据脱敏方案、PIPL 合规清单
- 团队过渡方案：Java 开发转 AI 的技能清单、分阶段学习路径（不是 PPT，是可以照着学的资源列表）
- 代码库文档：把整个 OMS 的 9 个业务域从代码里读出来，写了分层文档
我们在找什么样的合作
你需要提供什么
一个真实的、在运行中的业务系统，不需要一定是订单系统。满足以下任意几条就够：
- 有多服务协作、存在人工排查链路（"这个数据在 A 系统、那个错误在 B 系统、日志在 C 系统"）
- 技术栈是 Java/Spring Boot（我们的 Tool Server 就是 Java 的，可以直接复用）
- 有 MySQL 可只读查询
- 有集中的日志系统
- 有一个"人肉排查很慢、但步骤可标准化"的业务场景
你不需要给生产数据库权限。 给一个脱敏后的只读副本、或者少量 Mock 数据就行。我们要的是真实的业务逻辑和系统结构，不是你的用户数据。
你能得到什么
- 一套针对你业务的 AI 方案——不是"套个 RAG"，是基于你的真实代码和业务逻辑设计的
- 完整的设计文档——如果我们现有的 27 份产出标准
- 你把项目借给我们跑，所有产出你一份我一份
我们做不到什么
- 不保证产出时间。我们都是在上班的 gap 时间做，一周可能只能投入几个小时
- 不保证方案一定好用。我们的方案是设计阶段的，没有实际上线验证过。如果你的项目复杂度远超预计，可能方案推倒重来
- 不保证成品级别代码。我们能产出的是方案+可运行的原型，不是上线级产品
关于 AI 的使用
我们全程用 AI Agent 配合做代码分析、方案设计、交叉审查。如果你对这个工作流感兴趣——"不懂 AI 的人怎么用 AI 来做 AI 项目"——我们也很乐意分享。整个过程的沟通记录、审查报告、迭代过程都有保留。
关于我
- 一个普通后端开发，会写 Java、会调 SQL、会看日志，不会 Python、不会 ML、没做过生产 AI 产品
- 这个项目是"人定方向、问问题、做决策，AI 读代码、写文档、跑审查"的合作模式
- 你的项目就是我第一个能真正落地的 AI 项目
不是商业合作，就是想找个项目一起做。 如果你有一个跑了几年的系统，想过"能不能用 AI 帮帮我"但不知道怎么开始——我们可以试试。
最后
贴一下我工作时候用到的 半自动 ai 工作流。如果对你有帮助，我会很开心：https://github.com/radish40/dev-pipeline
感谢阅读，祝你开心。
