老板用AI三天写到90%，让我明天上线：Java 团队怎么接这10%的烂摊子？
昨天在掘金发了篇《Java 团队落地 AI 的三道坎》，评论区有位兄弟说了句：
让老板来。
我回他：
老板用 AI 一把梭哈，开发到了 90%，剩下 10% 自己搞不定，然后交给员工说：你看我三天就弄到 90% 了，剩下这点东西交给你了，抓紧收个尾，明天咱们上线！这肯定不是段子，这是真实的段子，哈哈哈。
发完我笑了半天，笑着笑着又有点笑不出来。
因为这个场景，我上个月才刚经历过一次。老板周一丢过来一个演示视频，说「人家 AI 三天搭了个 Agent，你这周也搞一个上线」。周三他拿着一段 cursor 生成的代码找我：「已经 90% 了，你补补安全、审计、部署就行。」
我打开代码一看：接的是公开 GPT-4 接口，日志里躺着客户手机号，工具调用链藏在某个 prompt 里，出错了没有回调。
所谓 90%，是能跑 demo 的 90%。离能上线，差的是生产级的灵魂。
这篇文章就从评论区这个真实段子出发，聊聊 Java 团队怎么把那 10% 的烂摊子，补成能上线的工程能力。
一、先看清楚：那 10% 到底藏在哪
AI 写代码确实快。一个 CRUD、一个 Agent 骨架、一段 MCP 调用，cursor / copilot / claude code 分分钟能跑出来。
但 demo 能跑 ≠ 生产能上。中间至少差着五个维度：
| 维度 | 90% 的 Demo | 100% 的生产级 |
|---|---|---|
| 模型 | 直接调 OpenAI / 云 API | 私有化 / 网关 / 限流熔断 |
| 数据 | 为了跑通，客户信息直接传 | 不出域、脱敏、可审计 |
| 工具 | 能调用就行 | 调用要可追溯、可回滚、有超时 |
| 错误 | 报错重试，不行刷新 | 异常处理、降级、人工兜底 |
| 合规 | 先上线再说 | 安全评审、审计日志、数据治理 |
发现没？AI 最擅长的是把「能跑通的那 90%」写出来。
它不擅长的，恰恰是决定能不能上线的那 10%：边界 case、数据安全、可观测、可审计、可回滚。
而这些，刚好是后端工程师的老本行。
二、Java 团队落地 AI，三道坎怎么补
上篇文章拆了三道坎，今天套进这个「90% vs 10%」的场景，你一眼就能知道自己该补哪。
坎 1：Python 鸿沟
很多老板 demo 是用 cursor + Python 脚本跑出来的，但你们公司的 ERP、权限、MyBatis、Dubbo 全是 Java。
那 10% 就是：怎么把 demo 接进现有 Java 体系，而不是推倒重来。
路线 A：Spring AI（贴合 Spring 生态）
java
// 最小骨架：把现有 Service 注册成 Agent 可调用的工具
@RestController
public class AgentController {
private final ChatClient chatClient;
public AgentController(ChatClient.Builder builder, OrderService orderService) {
this.chatClient = builder
.defaultTools(new OrderTools(orderService))
.build();
}
@PostMapping("/agent/chat")
public String chat(@RequestBody String question) {
return chatClient.prompt().user(question).call().content();
}
public record OrderTools(OrderService svc) {
@Tool("根据订单号查询订单状态")
public String queryOrder(@ToolParam("订单号") String orderNo) {
return svc.status(orderNo);
}
}
}路线 B：LangChain4j（更轻，零 Spring 也能跑）
java
public interface OrderAgent {
@UserMessage("客户问：{{it}}")
String answer(String question);
@Tool("查询订单状态")
String queryOrder(String orderNo);
}
OrderAgent agent = AiServices.builder(OrderAgent.class)
.chatLanguageModel(OpenAiChatModel.builder()
.apiKey(System.getenv("OPENAI_KEY")).modelName("gpt-4o").build())
.build();核心思路：不要为 AI 换语言，把你的 Service 变成 AI 的工具箱。
坎 2：数据出域
老板 demo 为了快，大概率接的是云上大模型。你接过来那 10%，首先要改的就是模型网关。
java
@Configuration
public class LocalModelConfig {
@Bean
public ChatClient localChatClient(ChatClient.Builder builder) {
OpenAiApi localApi = OpenAiApi.builder()
.baseUrl("http://192.168.10.20:11434/v1") // 内网 Ollama
.apiKey("ollama")
.build();
return builder
.model(OpenAiChatModel.builder().openAiApi(localApi).build())
.build();
}
@Bean
public ChatClient rateLimitedClient(ChatClient client) {
return client.mutate()
.defaultAdvisors(new RateLimitAdvisor(100))
.build();
}
}数据不出域是底线，限流熔断是体面。
坎 3：黑箱无法审计
这是那 10% 里最值钱的一块。AI 调用工具、传参、纠错全是黑箱，出了问题没法复盘。
Spring AI 2.0 把工具调用逻辑放到了 Advisor 链，正好插桩：
java
public class AuditAdvisor implements Advisor {
private static final Logger audit = LoggerFactory.getLogger("agent-audit");
@Override
public AdvisedResponse adviseCall(AdvisedRequest request, CallAroundAdvisorChain chain) {
long start = System.currentTimeMillis();
audit.info("AGENT_REQ ts={} user={} tools={}",
start, request.userText(), request.toolNames());
AdvisedResponse response = chain.nextAroundCall(request);
audit.info("AGENT_RES ts={} costMs={} contentLen={}",
start, System.currentTimeMillis() - start,
response.response().getResult().getOutput().getText().length());
return response;
}
}确定性、可审计、可回滚------这些是企业级后端的看家本领，现在把它焊到 Agent 上，就是你的护城河。
三、收尾清单：下次遇到这 10%，直接照着打勾
- 补语言桥接：用 Spring AI / LangChain4j 把 demo 接进现有 Java 栈。
- 补模型网关：私有 Ollama / vLLM，统一 baseUrl，加限流熔断。
- 补审计链路：Advisor 记录每次工具调用入参、出参、耗时。
- 补异常兜底：工具调用失败、模型超时、结果格式错误，要有降级策略。
- 补数据治理：敏感字段脱敏，日志不落原始数据，权限按业务角色隔离。
- 补发布流程：安全评审、压测、回滚演练，走完再谈上线。
记住：能上线 ≠ 能跑通。
四、写在最后
AI 不会让后端失业，但会淘汰那些只会写 demo 的后端。
老板用 AI 三天干到 90%，不是坏事。坏的是有人真觉得剩下 10% 只是「收尾」。
那 10%，是生产级的灵魂：安全、审计、稳定性、可维护性。而这恰恰是后端十年的老本行。
所以下次老板再让你「收个尾」，你可以回他：
哥，AI 写的 90% 我一天就能接过来。但后面这 10%，才是真正值钱的活儿。
你们有没有被 AI demo 丢过烂摊子？评论区聊聊，我挑真实的下篇拆。
想系统跟一遍「后端转 AI Agent 的实战路线」，完整资料见：wangzhongyang.com
#AI Agent #Java #后端开发 #Spring AI #LangChain4j #大模型落地 #程序员转AI #Agent工程化