JastWc

Java & AI Builder 🚀 | 专注后端架构、LLM 应用与 Vibe Coding | 折腾效率工具与 Agent 落地

[JastWc @JastWcpsf8]

用户买了 10 件，系统却按 120 件去预占库存。这个Bug，AI 排障能查到哪一步？

上一篇的库存案例，在本地模拟环境复现了一遍，直接看效果👇

报错是库存预占失败，最省事的结论是库存不足。
一句话发起调查后，Agent通过MCP核对了三处：
· 日志：预占数量120
· 订单库：下单数量10
· 源码：把10件当成10箱，再按每箱12件换算成120
根因是单位换算，不是库存不足。

Skill里有一条硬规则：结论必须引用证据，证据不足就停下转人工。

这次跑通的是取证和根因分析。下一篇接修复：开分支、改代码、跑回归。

说明：故障是自己埋的；排查步骤由Skill 预先定义，每一步查询都是 Agent 实际调 MCP 完成的。视频为 10 秒节选。

[JastWc @JastWcpsf8]

经历了之前几次的经验，再次遇到一个场景团队线上问题自动化agent基建，分享下Claude Opus5.5 max和Gpt-6 Astra Extra High配合下来的落地：

这里我就挑核心点参考，实际中大型项目我们遇到的要复杂的多，不过基本能覆盖很多大家的场景，两个模型都很好的给出了类似我们之前线上跑的一些解决方案；

核心问题：线上出问题时，我们通常怎么处理？

1、打开日志平台→找traceId→追踪上下游→查数据库→定位代码→查看近期发布，服务扩展到几十个，再加上 Redis、MQ、ES 等组件，排查就成了一次跨系统的信息拼接。

即使用上AI，很多时候也只是：人查一段日志，复制给 AI；AI 提出下一步，人再去查，然后继续复制，疯狂烧你的token，一个computer use下来直接5小时额度打满。

2、这部分反复搬运上下文的工作自动化。具体思路是：在业务仓库之外，维护一个例如jestwc-skills工程，把团队的排查经验、项目映射和验证规则沉淀下来，通过MCP/API 接入日志、监控、只读数据库、代码仓库和 CI。

开发者用自然语言发起任务，流程先分两条主线。

① 这个服务报警了，帮我分析原因

进入incident-diagnosis：

确认环境和时间范围 → 判断影响等级 → 收集证据 → 验证根因假设 → 输出报告。

不同问题走不同取证路径：

CPU、内存异常先看指标和 JVM 状态；请求失败沿 traceId 查链路；构建失败先看 CI 的失败阶段。

② 帮我处理这个 BUG，修复到独立分支

进入defect-remediation：

读取→定位仓库→复现问题→创建独立worktree和修复分支→修改代码→回归验证→回填结果。

如果发现是配置、数据或依赖问题，就交付对应结论，不强行改代码。

这里的配合关系是：
1、Skill定义处理方法和完成标准;
2、Agent根据当前证据决定下一步;
3、MCP/API 提供访问实际系统的能力;
4、其实就是整体的能力交给agent看得懂的方式进行工作

比如订单服务报【库存预占失败】，Agent不应直接下结论【库存不足】，而是继续核对请求数量、库存服务日志、业务配置和对应版本代码，判断哪种解释真正成立。

所以，一句话只是入口。可复用的工程还需要几项约束：

1、日志限定服务、环境、时间窗和数量；数据库使用只读权限；代码修改有明确仓库和分支范围；报告引用证据；修复必须验证，证据不足就停止或转人工。
2、同一份Skill也不能保证不同模型得出相同答案。我们要统一的是取证方法和验收标准，再用故障样例持续评估流程。

最终交给开发者的，应当是：
1、根因报告+证据链+修复分支+测试结果；
2、审核、合并和生产发布仍由人把关。重大故障优先按应急预案控制影响，根因分析同步推进；
3、我希望 AI 能承担更多重复调查和验证工作，让开发者把时间花在判断问题、审核方案和改进系统上。

总结：其实模型的上限给你人的项目经验也有很大的关系，模型能在你们不断碰撞思维的过程中和你落地出最符合业务团队的方案

[JastWc @JastWcpsf8]

@aiZttt__ 确实，我甚至有时候忘记了IDEA PyChram的存在😂

[JastWc @JastWcpsf8]

@wanxubo 卸载chatgpt，然后重新下载，保证你账户有足够的金额，然后订阅。

还有可以在设置里面，订阅入口，点击续费也可以承接上

[JastWc @JastWcpsf8]

如果想看自己喜欢的AI热点，直接跳转到Google即可

[JastWc @JastWcpsf8]

热点雷达加了个小功能：一键发邮箱到Gmail

点一下，今天的榜单直接到Gmail，中文圈和英文源各取前 10，带话题标签和讨论链接，几个源都在聊的会标「也见于 GitHub」

我现在早上就手机上扫一眼邮件，不用开电脑也知道AI圈昨晚在吵啥聊啥，大大节省了我的时间

数据源还是V2EX/GitHub/HF/HN这几个免费的，一分钱没花。后面打算部署到自己服务器上，每天定时推给我

[JastWc @JastWcpsf8]

发现不少人都有这个痛点：每天找相关例如热点要刷半小时。我做了个看板，30 秒看完。

视频里：一键拉取 6 个数据源 → 按话题归并 → 跨源出现的内容自动排前面，可以根据自己喜好规则筛选

这样就可以关注到你想要的热点：例如中文圈在聊 Claude 封号和 Codex 消耗，源头在聊开源大模型和 OpenAI 的争议新闻，两边关注点完全不一样。

技术架构很轻：后端一个 Spring Boot 服务JVM进程搞定，6 个源用虚拟线程并行拉取，结果缓存 1 小时，自己用不需要数据库，除非是重要数据单任务JOB落下来数据，0 成本，想加什么源随时能加。

当然如果需求特殊，也可以接其他第三方API，可以实时精准获取到你的需求数据，进行创作和改善，省去一部分自动时间；

界面用Claude Design出设计稿，代码交给Opus 5.5在Code模式实现。

后面会写怎么做的。你们每天是怎么找选题的？

[JastWc @JastWcpsf8]

@fly3nn 很悬后面得一定注意了，相当于这个邮箱是国内IP直接网络打到A社服务器，初步肯定进风控名单，如果再频繁出现，邮件就可能发过来了

[JastWc @JastWcpsf8]

@aiZttt__ 那估计Claude也得频繁崩几次，前不久Opus5.5晚上用才遇到一次😂

[JastWc @JastWcpsf8]

@tangjinzhou 我这边暂时用了几个月还没遇到，Memory都记住习惯和信息了

[JastWc @JastWcpsf8]

@zhaoby83 @xparkzz 是的，早期我们身边一个圈子的研发就没听过说谁解封的，就最近才看到的，少的可怜

[JastWc @JastWcpsf8]

@PrismChemAI 看到了朋友

[JastWc @JastWcpsf8]

@Summer_PPG 哈哈哈确实同感，有时候感觉别人不管发啥轻松破万

[JastWc @JastWcpsf8]

@leaf_sanren 恭喜🎉👍

[JastWc @JastWcpsf8]

@lemomo_ai 是的，我们统一做了项目知识库来集中管理，这样不管是任何大家用的不同模型都能进行共享

[JastWc @JastWcpsf8]

@jianyi99 没有废的，只是这个邮箱在A社确实只有申诉或者不能用了，其他OpenAI Grok Gemini等一点儿也不影响

[JastWc @JastWcpsf8]

@clamm3y 这已经很厉害了👍

[JastWc @JastWcpsf8]

@bei351009016 希望吧，毕竟之前被他封怕了

[JastWc @JastWcpsf8]

For most scenarios, Sonnet 5.5 is more than enough and super fast. Overly high reasoning just adds unnecessary latency. Save Opus 5.5 (High) for complex architecture design. Honestly, you rarely need 'Max' unless you're tackling complex cross-project work or large-scale refactoring.

[JastWc @JastWcpsf8]

@hejushang8 试了一下使用暂时没问题，不过还是习惯了英文😆

[JastWc @JastWcpsf8]

@Jamesmv49 很实用👍

[JastWc @JastWcpsf8]

@xmglab @thsottiaux 明天工作3个号一起蹬😂