AI on 追风笔记

我的 AI 工作流：从 Cubox 到 Claude

Sun, 24 May 2026 00:00:00 +0000

试过很多工具组合，绝大多数最后都废了。留下来的这套很简单，只有三个环节：收口、加工、归档。工具会换，环节不会。

输入：Cubox 负责收口

信息源太散是最大的问题——微信文章、技术博客、内部文档、群里的链接。以前我在不同地方存不同来源，结果就是想找时哪儿都找不到。

现在的规则只有一条：所有想读的东西只进一个入口。Cubox 的价值不在功能多，而在它在手机、浏览器、微信里都能一键收藏。

我只用三个标签维度：

状态：待读 / 已读待整理 / 已沉淀
主题：架构 / 银行业务 / AI / 其他
强度：需要精读 / 扫一遍就行

标签体系越简单越可能被坚持。我曾经设过十几个分类，两周后就懒得选了。

收藏不等于阅读，阅读不等于沉淀。我给自己定的比例是每收藏十篇，至少有一篇要走完到沉淀环节。剩下九篇没读完也不内疚——收口的意义就是让它们不再占用注意力。

加工：Claude 负责结构化

这一环是变化最大的。以前读完一篇长文要自己做摘要，成本高到经常跳过。现在的做法是把原文丢给 Claude，用固定的提示词做第一轮结构化：

请阅读以下技术文章，按此结构输出：

1. 核心论点（不超过三句）
2. 作者的关键假设与适用前提
3. 论证中的证据类型（生产数据 / 基准测试 / 个人经验 / 无证据）
4. 与我已有认知可能冲突的点
5. 值得进一步查证的三个问题

要求：不要复述细节，不要评价文笔。若某项在原文中缺失，直接写"原文未提供"。

第 3 项和第 5 项是我加上去之后价值最大的两条。技术文章里很多结论是没有证据的个人经验，明确标出来能避免我把别人的经验当事实用。

对于代码类的材料，我会让它先跑一遍可行性判断，而不是直接接受：

# 让 Claude Code 直接在本地验证文章里的写法能不能跑通
cbc -p "读取 notes/inbox/kafka-idempotent.md 里的示例代码，
在 sandbox/ 下建最小可运行工程验证结论是否成立，
把不成立的地方列出来并说明原因"

能跑通的写法才进笔记，跑不通的记录成"待查证"。这一步过滤掉了不少看起来很对的博客结论。

企业级 Java AI 框架选型：Spring AI vs LangChain4j

Wed, 11 Mar 2026 00:00:00 +0000

去年团队要在 Java 技术栈上落地一批 AI 应用，绕不开这两个框架的选型。当时网上的对比文章基本都是把两边 README 抄一遍，看完还是不知道该选哪个。这篇写我们实际用下来的差异，包括最后为什么两个都在用。

选型的前提：先定义需求

框架选型没有绝对答案，只有对不对得上需求。我们的实际需求是这五条：

必须能接私有化部署的模型。行内模型走内网网关，协议兼容 OpenAI 但不完全一致，鉴权是自研的。
必须能接入现有 Spring Boot 体系。配置中心、链路追踪、指标上报、统一异常处理都已经是现成的。
需要工具调用（function calling），且工具要以真实用户身份调用下游服务。
需要 RAG，但向量库是行内统一提供的，不是 Pinecone 这类云服务。
要能做提示词版本管理和灰度。

注意第 4、5 条：这两条决定了框架自带的"开箱即用"能力对我们价值有限，我们更看重扩展点是否好写。

选型时最该问的不是"哪个功能多"，而是"我要改的那部分，改起来疼不疼"。

Spring AI 的取舍

优势

抽象设计非常 Spring。ChatClient 的流式 API 写起来舒服，和 Spring Boot 的自动配置、RestClient、Micrometer 打通得彻底。

@Service
public class ProductAdvisor {

 private final ChatClient chatClient;

 public ProductAdvisor(ChatClient.Builder builder, VectorStore vectorStore) {
 this.chatClient = builder
 .defaultSystem("你是银行零售产品顾问，只依据检索到的资料回答。")
 .defaultAdvisors(
 new QuestionAnswerAdvisor(vectorStore),
 new MessageChatMemoryAdvisor(new InMemoryChatMemory()))
 .build();
 }

 public String consult(String question, String sessionId) {
 return chatClient.prompt()
 .user(question)
 .advisors(a -> a.param(
 ChatMemory.CONVERSATION_ID, sessionId))
 .call()
 .content();
 }
}

Advisor 这个扩展点设计得不错，本质是拦截器链。我们的护栏、审计留痕、数字接地校验全部实现成 Advisor，一次编写全局生效：

对客 AI Agent 平台建设思路

Mon, 09 Feb 2026 00:00:00 +0000

内部效率类的 AI 应用怎么做都不算太难，做错了也就是员工少用几次。对客不一样：一句话说错可能就是投诉、监管问询甚至赔付。这篇记录我们做对客 Agent 平台时的思路，重点不在模型，在约束。

对客场景的特殊约束

先把约束写清楚，架构自然就出来了。

不能瞎说。产品收益率、费率、期限这类数字，只要模型自由生成就一定会出错。这类回答必须来自系统数据，不能来自模型记忆。
不能越权。查余额要认证到本人，代客操作要有明确授权链路。Agent 调用工具时的身份必须是真实用户身份，不是服务账号。
要能复盘。每一次对话的输入、检索命中、工具调用、最终输出都要能查到，而且要留存到合规要求的期限。
延迟有上限。用户在 App 里等超过三秒基本就退出了。多轮反思、多次检索这些提升准确率的手段，成本是延迟。
要能降级。模型服务不可用时，必须能退回到规则问答或人工客服，不能白屏。

对客 Agent 的技术难点不是让它更聪明，而是让它在不确定的地方老实承认不知道，并且把用户交给正确的下一环节。

平台分层：从模型到业务

我们最后落在四层。分层的目的很实际：业务方只关心自己那层，不用理解底下的模型细节。

网关层

统一的模型接入层，屏蔽底层模型差异。做三件事：

多模型路由与降级（主模型超时自动切备用模型）
配额与限流（按业务方、按用户维度双重限流）
计费与用量统计（按 token 归集到业务方成本中心）

这一层不允许有任何业务逻辑。它唯一的职责是让上层调用模型像调用一个稳定的内部服务。

编排层

Agent 的运行时。定义一个 Agent 需要：系统提示词、可用工具集、知识库范围、护栏规则、降级策略。我们用配置描述而不是写代码，业务方在控制台就能改提示词并灰度发布。

agent:
 code: retail-product-consult
 name: 零售产品咨询助手
 model:
 primary: qwen-max
 fallback: internal-7b
 temperature: 0.2
 timeout_ms: 2500
 autonomy: tool_calling  # 可选 qa_only / tool_calling / multi_step
 max_steps: 3
 knowledge:
 collections: [product-manual, faq-retail]
 top_k: 5
 min_score: 0.62
 tools:
 - code: query_product_rate
 auth: user_token  # 以真实用户身份调用
 - code: query_my_balance
 auth: user_token
 require_mfa: true
 guardrail:
 input: [prompt_injection, sensitive_topic]
 output: [pii_mask, number_grounding, disclaimer_append]
 fallback:
 on_model_error: rule_based_faq
 on_low_confidence: transfer_human

工具层

工具就是被包装成模型可调用形式的业务接口。我们的规范是：工具必须是幂等查询，或者是带确认步骤的操作。没有确认步骤的写操作一律不开放给 Agent。