企业官网建设流程全解析

99%的人会忽略的AI安全问题，AI有可能会把假商店推荐给你

标题中的“99%”是修辞，不是调查统计。AI指人工智能。

一个购物助手成功找到商品，不代表它成功核实了商家。把这两项状态合成一句“推荐购买”，可能让用户误以为，交易对象也已经检查过了。

对开发者来说，值得解决的不是把答案写得更肯定，而是让系统明确区分：候选从哪里来、身份依据是什么、还有什么没有核实，以及哪些动作没有获得授权。

第一点：案例提出了问题，但不能替代技术调查

Tom’s Guide作者自述，经ChatGPT推荐购物，未收货后联系品牌方，发现没有该订单。案例原文

这是单源陈述，不是本账号的独立实测。它不能证明模型遭到攻击，也不能证明存在未经授权的自动付款。

工程分析不能从“推荐里有假店”一步跳到“提示词注入成功”。提示词注入，指外部内容夹带指令并试图让AI偏离原任务；训练数据投毒则涉及训练材料被污染。前者需要输入与执行记录，后者需要数据及训练环节证据。英国国家网络安全中心对前者有专门说明，但一般风险说明不是本案的取证结果。技术来源

在证据有限时，能做的是拆分系统职责，不能补写攻击过程。

第二点：候选、核验、授权应当有不同的状态

为什么需要分别记录？因为“有候选”很容易被产品界面表达成“可以交易”，而中间可能缺少关键检查。

建议让核验状态保留“未核验、证据不足、存在冲突、已按既定流程核验”，而不是一开始就只有真假二选一。“不在可信名单”不等于已证实诈骗，只意味着不能沿用已有信任。

界面也需要对应区分：展示候选链接时，不应默认附上类似认证的含义；展示核验结果时，应列出证据范围、检查时间及没有覆盖的环节。这是本文提出的设计建议，不是已经测得效果的通用解决方案。

第三点：不要让网站自己给自己开证明

一个候选网站的品牌图片、客服电话和“官方”声明可能来自同一经营者。把这些内容互相引用，不等于拿到了几份独立证据。

核验应尝试从已经独立建立的品牌渠道或经营记录出发，确认网址与主体关系，而不是从可疑页面继续点击它提供的“证明”。美国联邦贸易委员会也提醒消费者审慎对待评价，并指出加密连接不代表网站本身合法真实。核验原则

这些证据仍有范围和时效限制，不能把完成一次核查宣传成永久保证。网站、收款对象、购物车商品或金额改变，都可能使先前结论不再适用于当前交易。

第四点：用一个本地教学示例，演示“证据不足就暂停”

下面的Python代码只演示动作前的状态检查。所有主体都是虚构的；它不访问网站、不处理个人资料、不连接支付，也不能识别假商店。

关键是：身份依据必须由独立流程提供，不能直接相信模型或网页自己填入的字段。例子里的布尔值只是教学输入，不代表已经解决实际身份验证问题。

fromdataclassesimportdataclassfromdecimalimportDecimal@dataclass(frozen=True)classReview:seller_id:strindependent_identity_check_passed:boolitem_id:strtotal:Decimal currency:strdelivery_and_return_reviewed:bool@dataclass(frozen=True)classApproval:seller_id:stritem_id:strtotal:Decimal currency:struser_confirmed_this_purchase:booldefinspect_before_action(review:Review,approval:Approval):reasons=[]ifnotreview.independent_identity_check_passed:reasons.append("商家身份缺少独立核验；暂停，不认定为诈骗")ifnotreview.delivery_and_return_reviewed:reasons.append("交付和退货条件未检查")ifreview.total<=0:reasons.append("金额无效")expected=(review.seller_id,review.item_id,review.total,review.currency)approved=(approval.seller_id,approval.item_id,approval.total,approval.currency)ifexpected!=approved:reasons.append("当前对象或金额与确认内容不一致")ifnotapproval.user_confirmed_this_purchase:reasons.append("本次交易未确认")return{"pause":bool(reasons),"reasons":reasons}if__name__=="__main__":# 虚构教学输入，无真实店铺、交易或支付。approval=Approval("seller-example","item-example",Decimal("100"),"CNY",True)unknown=Review("seller-example",False,"item-example",Decimal("100"),"CNY",True)changed=Review("another-seller",True,"item-example",Decimal("100"),"CNY",True)reviewed=Review("seller-example",True,"item-example",Decimal("100"),"CNY",True)assertinspect_before_action(unknown,approval)["pause"]assertinspect_before_action(changed,approval)["pause"]assertnotinspect_before_action(reviewed,approval)["pause"]print("状态检查示例通过；没有执行付款，也不是商家安全认证。")

即使示例返回不暂停，也只是满足这段程序列出的教学条件，不是完整的交易许可。真实产品还要处理证据伪造、状态过期、跳转、更换收款对象、重复提交、撤回授权和审计记录等问题。

更重要的是，检查必须在真正执行动作的系统里落实。仅在对话里写“付款前请确认”，与执行端真的阻止未经批准的动作，不是一回事。

第五点：测试不应只测“能不能买到”

建议用虚构页面和隔离环境测试：只有卖家自称官方时是否保留不确定；商品满足需求但主体关系缺证时是否暂停；确认后收款对象变化时是否重新检查；用户只让找商品时是否仍保持只读。

测试应记录输入、证据来源、状态变化、暂停理由与实际执行结果，不能只看模型最后一句“已安全完成”。身份检查正确与付款授权正确，要分别验收。

购物助手真正的安全感，不是从不说“不确定”，而是不把没有完成的核验，包装成已经完成的保障。

读者问答

问：这段代码能识别假店吗？

答：不能。它只演示如何将身份核验状态、交易条件与授权分开检查。输入是否真实必须由其他独立流程保证，不能让模型给自己填写“已验证”就放行动作。

问：用户确认付款后，还要核验商家吗？

答：要。用户确认的是具体交易，不等于经营主体真实。商品、收款方或金额变化，也不能沿用不匹配的旧确认；身份核验与授权检查不能互相替代。

问：错误推荐就能证明提示词注入吗？

答：不能。需要实际外部指令和系统处理记录才能调查攻击机制。推荐失误、信息失真和外部指令操纵是不同问题，不应只根据结果替其中一种原因定性。

数据出处

Tom’s Guide案例为单源亲历陈述，页面更新2026-06-11；NCSC为技术概念说明；FTC为一般购物核验原则，三者不能充当对同一事件的独立交叉核验。正文链接分别对应相关论述。核验日期2026-10-17。

本文是技术与产品设计讨论，不提供真实商家安全认证，不作赔付承诺。