本项目旨在将领星的运营日志监控系统升级为“系统主动识别异常并警报”，以减少人工检查的缺口。系统将通过整合日志接入、规则判定和飞书通知，自动化运营行为。重点监控新增差评、评分变化、父体成员变化与购物车丢失等四类事件，通过Python与SQLite实现数据采集与管理。系统的目标是降低人工成本、实现实时监控、控制误报，并形成事件追溯闭环。

核心区别 普通 RAG 是“提问时临时检索并拼答案”；LLM Wiki 是“入库时先把资料整理成持续维护的知识体系”。 可以把它们类比为： 普通 RAG：搜索引擎 + 临时研究员 LLM Wiki：由 AI 持续维护的百科全书 企业级混合方案：百科全书负责理解，搜索引擎负责原文取证 Karpathy 描述的 LLM Wiki 会保留不可修改的原始资料，同时让 LLM 持续生成和维护结构化 Wiki 页面，包括主题页、实体页、摘要、交叉链接和矛盾记录；它不是每次提问都从原始文档重新开始分析。

该项目旨在为跨境卖家提供可验证的经营决策支持，集中处理散落在多个渠道的信息。这些信息涉及政策、费用、广告更新及合规风险等。项目采用轻量级本地架构，通过Python进行数据采集及处理，使用DuckDB进行存储和审计。核心功能包括信息提取、重复数据去除以及结构化分析。通过Codex系统，卖家能够生成日报、周报，确保信息及时有效。该系统在设计时注重合规性，保证不采集私人数据并遵守相关政策，确保信息可靠。

说明：本文讨论的是亚马逊运营 Skill 在真实业务场景里的工具选择：什么时候用 MCP 探索，什么时候用 CLI + Python 数据管道交付。它不是在比较 MCP 和 CLI 的协议设计、通信机制或底层实现原理。 最近我翻了一下自己写过的亚马逊运营 Skill。 市场调研，用 Sorftime CLI。 竞品监控，用 Sorftime CLI。 VOC 报告，也还是用 Sorftime CL...

最近招聘运营，发现不少候选人不是没做过事，而是简历写得像岗位说明书，面试也讲不清自己的真实贡献。STAR 方法不用讲复杂，说白了就是四个问题：当时什么情况、你负责什么、你做了什么、最后结果怎样。

我们先看已经跑出来的结果。 特殊说明一下，用户旅程地图的方法论来自于新大佬的文章：亿级品牌化卖家，到底怎么做用户洞察？。这种类似生命周期的表达方式更加直观，可以让我们 get 到具体哪个阶段发生了问题，一目了然。 LLM 审计的作用非常简单，记录所有的 CLI/MCP 调用次数、Token 消耗，让成本清晰可见。 最后，保留完整的评论明细，可以随时阅读，方便快捷。 注意注意！！！上面的报告不是简单...

这篇算是上一篇《如何利用 MCP/CLI 与大模型实现全自动市场调研？》的实践版，上一篇我把结果拿出来讲了一遍，这篇把背后的搭建过程拆开讲清楚。 上一篇文章发出去之后，有不少读者问我：那个 HTML 市场调研报告看起来挺完整，但到底怎么让 AI 稳定输出？为什么自己用 ChatGPT 写调研报告，每次结果都不一样？ 这个问题挺关键。很多人第一次用大模型做调研报告，效果都还可以。第二次再跑，结构开始

一、 背景与痛点 在选品流程中，我们往往拥有一套祖传下来的，极度消耗人力的“标准模板”（通常是 Excel、飞书文档或 PPT）。常规做法是：人工使用卖家精灵、Sorftime、飞鱼、Sif 等各个 SaaS 选品工具，频繁地复制数据、截取图表，再机械地粘贴到模板中。 尤其是针对重点款式和产品具体参数的分析，极度依赖人工逐个点击 ASIN 链接、浏览 Listing、肉眼归纳总结。简单总结就是，一...