前阵子在看 Hacker News 的时候注意到一个很有意思的产品概念TickClip定位是 “An AI shopping agent that can recommend not buying”。乍一看有点反常识——市面上几乎所有购物助手都在想办法让你“多买”而这个智能体的核心卖点居然是“劝你别买”。这个方向其实非常值得聊。它不只是一个购物工具更是一类典型的大模型 Agent 应用让 AI 从“信息检索”走向“决策辅助”。本文会从产品定位、系统模块、技术选型、工程实现和落地难点几个方向展开并给出一个可运行的简化版 TickClip 思路帮助你理解这类“会拒绝”的 AI Agent 是怎么被设计出来的。适合读者对 AI Agent 开发、大模型应用落地感兴趣的同学做电商推荐、智能导购、消费决策类产品的开发者以及想从“调 API”进阶到“搭系统”的人。1. 背景与核心概念为什么“推荐不买”反而更有价值1.1 传统购物助手的痛点我们平时接触到的购物推荐系统核心指标几乎都是点击率、转化率、客单价、GMV。推荐引擎的目标是让用户“尽快下单”这种情况下系统会倾向于推荐用户看过但还没买的商品推荐价格更高、佣金更多的商品用倒计时、折扣、热销等话术推高购买意愿。这种方式在平台侧是高效的但对消费者来说它并不总是友好的。尤其是当用户想买一件单价较高的商品时信息不对称的问题特别明显材质、容量、兼容性、替代方案、使用频率、成本摊销……这些因素往往在下单前很难被完整覆盖。1.2 TickClip 做了什么TickClip 的思路是反过来先别急着买我帮你分析一下到底该不该买甚至告诉你“现在最好不要买”。作为一个 AI shopping agent它需要具备几项能力理解用户需求比如用户说“想买一个跑步用的运动手环预算 500 以内”它要能解析出场景、预算、核心需求。获取商品信息通过搜索、抓取页面、调用电商 API 等方式拿到候选商品的参数、价格、评价。多维度分析不止看价格还看性价比、替代品、用户评价、使用场景匹配度。给出决策建议推荐买哪个如果不合适明确说“不推荐买”并给出理由。拦一把冲动消费发现用户的需求可以被现有物品满足或者这个价位存在明显更优选择时主动提醒。这个定位让它在跟用户的关系上天然比“促销助手”更中立也更容易建立信任。1.3 它和“普通推荐系统”的本质区别维度传统推荐系统TickClip 型 Agent目标提高转化率提高决策质量立场倾向于促成交易中立甚至偏消费者输出推荐商品列表推荐 不推荐 理由交互一次请求返回结果多轮对话可追问评价指标GMV、CTR用户满意度、退货率、省钱金额技术核心召回、排序信息获取 推理决策换句话说TickClip 本质上是一个基于大模型的决策 Agent而不是一个推荐排序系统。它的技术难点也不在“算 CTR”而在“如何让 AI 在多源信息下做出可解释的、可靠的判断”。2. AI 购物 Agent 的核心能力模型从“能搜”到“会判断”要做一个“会劝退”的购物 Agent不能只靠一个模型提示词。实际情况中系统需要拆成多个相互独立又协作的模块。2.1 意图理解与需求结构化用户的第一句话往往很模糊。比如“我想买个礼物送女朋友。”“有没有便宜好用的机械键盘”“这个吹风机值不值得买”如果直接把这句话丢给大模型让它去搜索商品效果会非常不稳定。更稳妥的做法是先把自然语言转成结构化的购物需求。一个典型的结构化需求长这样{ scene: 送礼, recipient: 女朋友, budget: {min: 200, max: 500}, category: 美妆 / 饰品 / 数码, must_have: [颜值高, 有包装], avoid: [太 personal, 护肤品类高风险], preferences: [小众, 有趣], decision_style: 谨慎 }这个步骤可以完全交给大模型做但建议限定输出 JSON Schema确保下游链路可控。2.2 商品信息获取与清洗得到结构化需求后Agent 需要去获取真实商品数据。常见方式有三种电商平台开放 API最合规但通常拿不到完整商品库。站内搜索接口很多平台有内部搜索接口但风控严格。爬虫抓取页面可行但必须遵守 robots、频率限制且结果解析成本高。TickClip 这类产品最核心的信息源包括商品规格颜色、尺寸、材质价格与历史价格用户评价尤其是差评适用场景和安装/维护成本竞品和替代品。这里要特别提醒无论使用哪种数据获取方式都要注意目标平台的条款和用户隐私。拿来做技术学习可以理解但做产品商业化前必须确认合规边界。2.3 多维分析与决策这一层是 TickClip 的灵魂。拿到信息之后Agent 需要回答三类问题这个商品本身好不好—— 材质、口碑、品牌、故障率。它适合这个用户吗—— 结合场景、预算、偏好。现在买值不值—— 价格趋势、同价位竞品对比、非必需品折扣率。一个简单但有效的办法是把决策过程拆成多个“评分卡”例如维度权重说明需求匹配度0.3是否满足用户核心诉求性价比0.25对比同品类商品评价与口碑0.2主要看差评中的共性问题购买紧迫度0.15是否有现时优惠还是常年打折风险度0.1是否容易吃灰/退货/踩坑如果最终得分低于阈值或者某几个必选项不满足Agent 就会输出“不推荐购买”并给出具体理由。2.4 输出与追问一个成熟的购物 Agent 不会只说“不推荐”它应该进一步解释为什么不推荐证据是什么是否推荐其他替代方案如果要买什么条件下值得买是否建议再等等这需要设计非常细致的 Prompt让模型在输出时保持“有理有据”并且允许用户继续追问。2.5 “不推荐”机制的产品价值“不推荐”本身也是一个产品层面的亮点。它能有效降低用户的决策焦虑同时建立起“这个助手跟我说实话”的信任感。对于复购和口碑来说这种信任比一次 GMV 更有价值。3. 技术选型与架构设计搭建 TickClip 的关键模块结合 AI Agent 的常见技术栈下面给出一套可落地的模块划分和选型参考。3.1 系统整体模块划分一个简化版的 TickClip 系统可以划分为以下模块对话管理模块负责多轮对话维护上下文。需求理解模块将自然语言转为结构化购物需求。商品检索模块检索商品返回结构化商品列表。价格与评价分析模块获取历史价格与评价摘要。决策推理模块结合上述信息生成购买/不购买建议。执行与提醒模块定期监控价格变化主动推送建议。对应技术选型模块推荐技术方案说明LLM 主模型GPT-4o / Claude / 开源 Qwen 系列负责理解与生成Agent 框架LangChain / LlamaIndex / 自研编排管理工具调用与上下文商品检索搜索 API / 爬虫 / 数据库缓存返回商品列表结构化输出Function Calling / JSON Mode保证结果可解析缓存Redis商品信息、对话状态前端交互浏览器插件 / 微信小程序 / Web App一键分析当前商品3.2 为什么用 Function Calling 而不是纯 Prompt在决策链路里Agent 必须要“调用工具”。比如用户说“帮我看看这个吹风机”Agent 需要先调用商品详情工具再调用评价分析工具最后才能给出结论。如果只用 Prompt 让模型凭空输出分析模型很容易产生幻觉编造出商品参数和价格。所以更可靠的设计是模型负责“理解”和“规划”工具负责“取证”最终结论必须基于工具返回的真实数据。这也是 Function Calling或 Tool Use在 Agent 工程中的核心价值。3.3 一个可运行的简化架构示例下面用一个最小实现来展示 TickClip 的核心推理链路。这个示例不依赖复杂框架重点展示设计思路。用户输入 ↓ 需求理解LLM JSON 输出 ↓ 商品检索模拟或搜索 ↓ 商品评分卡计算 ↓ 决策推理LLM 生成建议 ↓ 输出“推荐 / 不推荐” 理由整个链路可以理解为先取数再分析最后让 LLM 生成人话。4. 工程实战实现一个简化版 TickClip这一节我们动手实现一个本地可运行的简化版 TickClip。它包含一个用户意图解析模块一个模拟商品检索模块一个评分卡决策模块一个大模型结果生成模块可选。为了便于读者直接运行这里用 Python 编写并假设你已经安装了openai、rich、pydantic这几个常见依赖。4.1 项目结构tickclip-demo/ ├── main.py # 入口文件 ├── requirements.txt # 依赖说明 ├── intent_parser.py # 意图解析模块 ├── product_search.py # 商品检索模块模拟 ├── decision_engine.py # 决策评分模块 └── llm_suggest.py # LLM 建议生成模块4.2 安装依赖pip install openai rich pydantic说明本示例的核心逻辑并不绑定某个模型厂商你完全可以用 OpenAI、DeepSeek、Qwen 等任意兼容接口替换。示例里的llm_suggest.py只是把评分结果整理成自然语言属于可替换模块。4.3 定义需求数据结构首先需要定义一批数据模型便于下游模块统一处理。创建一个models.py# 文件路径tickclip-demo/models.py from typing import List, Optional from pydantic import BaseModel, Field class ShoppingRequest(BaseModel): 用户购物需求的结构化表示 scene: str Field(description使用场景例如运动、办公、送礼) budget_min: Optional[float] None budget_max: Optional[float] None category: str Field(description商品品类) must_have: List[str] Field(default_factorylist, description必须具备的特性) avoid: List[str] Field(default_factorylist, description需要避免的特性) urgency: str Field(defaultnormal, description紧急程度low/normal/high) class ProductInfo(BaseModel): 商品信息 id: str title: str price: float avg_rating: float review_count: int specs: dict pros: List[str] Field(default_factorylist) cons: List[str] Field(default_factorylist) class ProductScore(BaseModel): 商品评分结果 product: ProductInfo total_score: float breakdown: dict suggestion: str Field(description建议buy / not_buy / wait) reason: str Field(description建议理由)这里把“用户需求”和“商品信息”全部结构化目的是让后续的评分函数和 LLM 调用都基于稳定数据结构而不是原始字符串。4.4 意图解析模块意图解析模块负责把用户的一句话变成结构化的ShoppingRequest。# 文件路径tickclip-demo/intent_parser.py import json import os from openai import OpenAI from models import ShoppingRequest client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), # 可选兼容第三方模型服务 ) INTENT_PROMPT 你是一个购物需求解析器。请将用户的购物描述转换为 JSON 结构。 JSON 字段说明 - scene: 使用场景 - budget_min: 最低预算没有则填 null - budget_max: 最高预算没有则填 null - category: 商品品类 - must_have: 必须具备的特性列表 - avoid: 需要避免的特性列表 - urgency: low / normal / high 只输出 JSON不要输出其他内容。 def parse_intent(user_input: str) - ShoppingRequest: resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: INTENT_PROMPT}, {role: user, content: user_input}, ], response_format{type: json_object}, ) data json.loads(resp.choices[0].message.content) return ShoppingRequest(**data) if __name__ __main__: req parse_intent(想买个跑步手环预算 500 以内主要看续航和防水) print(req.json())这里要注意一下不同模型对response_format的支持程度不同。如果你用的是开源模型或第三方兼容接口不支持 JSON Mode 时可以把该参数去掉然后在 Prompt 里强调“只输出 JSON”。4.5 商品检索模块模拟数据真实的商品检索需要对接搜索 API 或爬虫。这里为了演示流程使用一组模拟数据。# 文件路径tickclip-demo/product_search.py from typing import List from models import ProductInfo # 模拟商品库 MOCK_PRODUCTS [ ProductInfo( idp001, titleA 牌运动手环 Pro, price399, avg_rating4.7, review_count12000, specs{battery: 14天, waterproof: 5ATM, screen: AMOLED}, pros[续航长, 防水等级高, 屏幕清晰], cons[表带容易过敏, 消息推送有延迟], ), ProductInfo( idp002, titleB 牌入门手环 iFit, price199, avg_rating4.2, review_count5000, specs{battery: 7天, waterproof: IP68, screen: LCD}, pros[价格便宜, 佩戴轻], cons[功能单一, 续航一般, 屏幕亮度低], ), ProductInfo( idp003, titleC 牌高端运动手表 Sport X, price1899, avg_rating4.8, review_count3000, specs{battery: 7天, waterproof: 10ATM, screen: OLED, gps: True}, pros[专业运动数据, 定位精准, 耐造], cons[价格高, 重, 学习成本高], ), ] def search_products(category: str, budget_max: float | None None) - List[ProductInfo]: 按品类和预算过滤商品列表。 results [] for p in MOCK_PRODUCTS: # 关键词匹配品类简化处理 if 手环 not in p.title and 手表 not in p.title: continue if budget_max and p.price budget_max: continue results.append(p) return results真实项目中你还需要考虑商品图片商品 SKU历史价格曲线评价主题聚类结果。这些信息都可以放入ProductInfo的扩展字段中。4.6 决策评分模块决策模块是 TickClip 的核心。它使用规则化的评分卡来判断商品是否值得购买。# 文件路径tickclip-demo/decision_engine.py from typing import List from models import ProductInfo, ShoppingRequest, ProductScore def compute_score(req: ShoppingRequest, products: List[ProductInfo]) - List[ProductScore]: scores [] for p in products: # 1. 需求匹配度must_have 覆盖情况 matched 0 for feature in req.must_have: spec_text .join(p.specs.values()) .join(p.pros) if feature in spec_text or feature in p.title: matched 1 match_ratio matched / len(req.must_have) if req.must_have else 0.5 match_score 100 * match_ratio # 2. 性价比价格越低评分越高简化处理 price_score max(0, 100 - (p.price / 10)) # 3. 用户评价结合评分与评论数 review_score p.avg_rating * 20 # 4. 风险度差评中有“过敏、续航、质量”等关键词时扣分 risk_keywords [过敏, 续航一般, 亮度低, 推送延迟] risk_penalty 0 for kw in risk_keywords: for c in p.cons: if kw in c: risk_penalty 15 # 5. 加权综合 total ( 0.3 * match_score 0.25 * price_score 0.2 * review_score - 0.1 * risk_penalty ) total max(0, min(100, round(total, 1))) breakdown { match_score: round(match_score, 1), price_score: round(price_score, 1), review_score: round(review_score, 1), risk_penalty: risk_penalty, } # 输出建议 if req.budget_max and p.price req.budget_max: suggestion not_buy reason 超出预算 elif total 60: suggestion not_buy reason 综合评分不足 elif p.price 0.9 * (req.budget_max or 0): suggestion wait reason 价格接近预算上限建议等待促销 elif total 75: suggestion buy reason 综合表现优秀适合当前需求 else: suggestion buy reason 基本满足需求但建议再做对比 scores.append(ProductScore( productp, total_scoretotal, breakdownbreakdown, suggestionsuggestion, reasonreason, )) return scores这个评分卡的逻辑比较粗但足以表达一个关键思想Agent 的“不推荐”结论不是靠 LLM 拍脑袋而是靠代码计算出来的。LLM 只负责把结论转换成用户容易理解的描述。4.7 生成自然语言建议LLM 模块评分卡给出的是结构化结论。用户感知到的是文本所以还需要一个“翻译层”。# 文件路径tickclip-demo/llm_suggest.py import os from openai import OpenAI from models import ProductScore, ShoppingRequest client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) def generate_suggestion(req: ShoppingRequest, score: ProductScore) - str: prompt f 你是一个中立、克制的购物顾问。 用户需求{req.json()} 商品信息{score.product.json()} 综合评分{score.total_score} 评分明细{score.breakdown} 系统建议{score.suggestion}理由{score.reason} 请基于以上数据输出一段 150 字以内的购物建议。 要求 1. 语言自然不要像机器翻译。 2. 如果建议是“不买”要给出具体可感知的理由。 3. 如果有替代方案可以主动提到。 resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: 你是 TickClip 购物助手。}, {role: user, content: prompt}, ], ) return resp.choices[0].message.content.strip()这一步的价值是让决策结果“有温度”。同一个结论用冷冰冰的“not_buy”输出和用“这款手环虽然便宜但屏幕在户外基本看不清如果你经常夜跑更推荐加 100 块上 A 牌 Pro”输出用户体验完全不同。4.8 入口文件串联流程# 文件路径tickclip-demo/main.py from rich.console import Console from intent_parser import parse_intent from product_search import search_products from decision_engine import compute_score from llm_suggest import generate_suggestion console Console() def main(): console.print([bold cyan]TickClip Demo[/bold cyan] - AI 购物决策助手) user_input input(你想买什么描述一下场景和预算即可\n ) # 1. 意图解析 req parse_intent(user_input) console.print(f[green]解析到的需求[/green] {req.json()}) # 2. 商品检索 products search_products(req.category, req.budget_max) if not products: console.print([red]没有找到匹配的商品。[/red]) return # 3. 决策评分 results compute_score(req, products) # 4. 展示与 LLM 建议 for score in results: console.rule() console.print(f[bold]{score.product.title}[/bold]{score.product.price}元) console.print(f综合评分{score.total_score}) console.print(f系统建议[yellow]{score.suggestion}[/yellow]) console.print(f规则理由{score.reason}) if os.getenv(ENABLE_LLM, true).lower() true: suggestion_text generate_suggestion(req, score) console.print(f[cyan]AI 建议[/cyan]{suggestion_text}) if __name__ __main__: import os, dotenv dotenv.load_dotenv() main()运行方式export OPENAI_API_KEY你的key export LLM_MODELgpt-4o-mini python main.py预期输出大概长这样 想买个跑步手环预算 500 以内主要看续航和防水 解析到的需求{scene: 跑步, budget_max: 500, category: 手环, must_have: [续航, 防水], ...} ---------------------------------------------------------------- A 牌运动手环 Pro399元 综合评分81.0 系统建议buy 规则理由综合表现优秀适合当前需求 AI 建议这款手环续航 14 天5ATM 防水对跑步场景来说完全够用…… ---------------------------------------------------------------- B 牌入门手环 iFit199元 综合评分58.0 系统建议not_buy 规则理由综合评分不足 AI 建议虽然价格便宜但屏幕亮度低户外跑步时基本看不清数据……代码本身不复杂但它体现了一个 Agent 应用的核心骨架理解 → 检索 → 计算 → 表达。5. 提升决策质量评分卡、多证据链与防幻觉上面的 demo 能跑但距离生产可用还差很远。下面几个点是把 TickClip 从“玩具”变成“产品”的关键。5.1 从“规则评分卡”到“混合决策”纯规则评分卡有个问题规则写死了难以覆盖长尾场景。比如用户说“这个手环怎么总是过敏”系统不应该只匹配“过敏”关键词还需要理解这句话的上下文。更成熟的方案是混合式决策规则层处理预算、硬性条件、合规限制。比如“超预算直接 not_buy”。模型层处理开放式分析。比如“这款产品的用户差评中是否大量出现某个共性问题”。人工层对高客单价、高风险商品支持人工审核结论。分层的好处是重要的结论有规则兜底细节的理解由模型补充。5.2 多证据链与可解释性TickClip 的未来不应该是“万能购物百科”而是一个“可以被证据支持的顾问”。因此建议系统保存分析过程中的证据链{ product_id: p001, decision: buy, score: 81.0, evidence: [ {source: product_page, content: 续航 14 天}, {source: review_summary, content: 约 8000 条评价中续航相关好评占 90%}, {source: price_history, content: 近 30 天最低价 379 元当前 399 元上涨 5%} ] }当用户问“为什么推荐我买这个”时系统可以直接展开证据列表而不是让用户去猜。5.3 防止 LLM 幻觉购物场景对“幻觉”的容忍度很低编一个不存在的促销、编一个价格都会导致信任崩塌。所以生产系统中必须采用以下策略所有事实性数据来自工具而不是模型记忆。LLM 只做文本生成不做数值判断。生成内容后做“事实校验”检查生成文本中提到的价格、品牌、型号是否与 JSON 数据一致。对于不确定的信息明确输出“我无法确认”。这些策略在 Agent 工程里非常重要尤其是涉及真金白银的决策场景。6. 从 TickClip 看 AI Agent 工程化落地要点TickClip 本身是一个产品创意但它涉及的工程方法论可以被复制到其他 Agent 场景中比如保险决策助手、理财助手、医疗健康建议类工具。6.1 对话状态管理购物决策通常是多轮的。用户可能先问“这款怎么样”再追加“那有没有白色的”最后“便宜 100 我就买了”。因此Agent 需要维护一个购物会话状态class SessionState: def __init__(self, req: ShoppingRequest): self.current_request req self.considered_products [] self.questions_asked [] self.final_decision None多轮状态下LLM 需要能够更新需求而不是每轮都从零开始。6.2 工具选择的稳定性Agent 可能需要多个工具例如商品详情查询历史价格查询差评摘要查询替代品搜索。这些工具如果交给 LLM 自由选择稳定性可能不高。更稳妥的方式是定义一个“计划模板”对于“评析某商品”的请求固定依次调用商品详情 → 差评摘要 → 价格趋势 → 更新评分卡。把高频链路“固化”能有效降低模型跑偏的概率。6.3 成本控制购物 Agent 比较特殊用户很可能同时问多个商品如果一个商品要调用好几次 LLM成本会迅速上升。成本控制建议用gpt-4o-mini或开源小模型处理简单分析只有最终生成建议时才用大模型商品检索和评分卡计算全部走代码不调模型对同一商品的多次询问做结果缓存。以本文 demo 为例一个完整流程大约消耗约 2k tokens成本可控。但一旦做成多轮对话token 消耗会快速上涨需要做预算帽和对齐。6.4 数据隐私与合规购物数据分析涉及用户偏好、支付意愿、行为轨迹等信息。生产应用中必须关注是否获得用户授权是否保存了不必要的个人信息是否在内容生成时泄露了用户隐私是否遵守目标电商平台的服务条款。建议在工程层面做到“最小化收集”默认不长期存储用户完整对话。7. 常见问题与排查思路结合 TickClip 这类 Agent 的开发过程下面列几个开发者容易踩到的坑。问题现象常见原因解决思路模型返回 JSON 解析失败模型输出夹杂说明文字使用 JSON Mode / Function Calling增加输出校验与重试搜索结果不准确品类匹配规则太粗糙引入商品分类体系利用关键词权重排序“不推荐”结论太频繁评分规则阈值设置不合理调整评分卡权重观察用户反馈AI 建议中出现虚构价格LLM 直接“回忆”商品数据强制基于结构化数据生成增加事实校验步骤多轮对话丢失上下文对话状态没有持久化把 SessionState 保存到 Redis每轮更新调用成本过高每轮都使用超大模型分级模型路由简单任务小模型复杂任务大模型用户不信任结论缺少解释和证据来源输出证据链展示价格曲线和评价摘要商品页面结构变化导致抓取失败爬虫选择器失效采用通用解析方案监控失败率自动告警8. 最佳实践与工程建议这一节梳理一下做电商/购物类 Agent 的工程经验。先定义“什么是不推荐”。不要默认让模型自己发挥先通过业务规则明确不推荐的条件比如超预算、存在高风险差评、需求不匹配、可替代方案显著更优。规则明确后模型输出才稳定。所有数值型判断不要交给 LLM 表达。评分、价格对比、折扣力度都应该由代码计算LLM 只负责把结果“翻译”成自然语言。缓存商品信息。商品参数、历史价格、评价摘要都有较高复用价值。建议为每个商品 ID 维护一个缓存条目有效期可设为 3~24 小时。保留完整的决策日志。当用户质疑“你上次说这个不推荐怎么降价就推荐了”你需要能回溯当时的评分卡和商品状态否则没办法解释。建立评价反馈闭环。记录用户最终是否采纳建议、是否购买、是否退货。用这些数据持续优化评分卡的权重。注意 Prompt 注入风险。商品页面的标题、评论区内容都可能包含攻击性文本。如果你把这些文本直接拼进 Prompt有被注入的风险。建议在接入外部文本时做“长度截断 内容脱敏 指令隔离”。灰度发布与模拟测试。别一上来就全量上线“不推荐”功能先在内部数据集上评估“不推荐准确率”。如果模型经常错误劝退用户很容易流失。9. 总结与后续学习路线TickClip 这个产品创意表面上是在做“购物推荐”实际上是在做一个具备判断与拒绝能力的 AI Agent 系统。它要求开发者同时掌握大模型应用开发、信息检索、规则引擎、数据分析和产品体验设计。如果你对它感兴趣可以从下面几个方向继续深入学 Agent 框架了解 Function Calling、ReAct、工具调用模式推荐直接阅读 LangChain 或 LlamaIndex 的官方文档。学搜索与数据清洗商品数据的抓取、解析、字段映射是这类系统准确率的上限。学评测体系给“不推荐”功能设计评测集评测维度包括不推荐准确率、理由充分性、用户采纳率。学前端集成TickClip 最有想象力的形态是浏览器插件或小程序在用户浏览商品页时实时生成分析卡片。做一个小项目练手先不做完整产品把本文 demo 扩展成支持历史价格、评论聚合的小工具足够让你理解 Agent 的完整开发链路。购物决策只是一个场景。同样的架构完全可以复用到“是否要买保险”“是否该做某个技术选型”“是否值得申请某张信用卡”等一切需要决策辅助的领域。真正有价值的不是“推荐买什么”而是帮助用户做出更理性的决定——哪怕那个决定是不买。