作为一名亚马逊运营人员，我在亚马逊官方 AI 编程活动中斩获第一名。比赛限时 60 分钟，我的 Agent 在题目放出后 15 秒内完成全部 10 道考题并获满分。
这是亚马逊 SP-API 中国开发者大会上的 AI Coding Hackathon 环节。作为全场唯一非技术背景的参赛者，我全程未编写一行代码，所有逻辑均由 AI 生成。
本文将复盘如何通过六步快速搭建一个“靠谱”的订单 Agent。核心不在于代码实现，而在于对业务逻辑的把控与 Prompt 的设计。
第一步：让 AI 自读文档，搭建可用原型；
第二步：确立铁律，禁止模型心算；
第三步：构建可交互、可追溯的界面；
第四步：双路验证，自出题对抗测试；
第五步：多维巡检，排查数据与逻辑隐患；
第六步：并发压测，确保高负载下的稳定性。
01 开工前：备好三样核心要素
本次任务是构建一个订单 Agent，能够回答如“日本站总单量”、“美国站最大金额订单”等业务问题。其本质是一个能自主调用接口、计算并汇报结果的智能助手。
搭建此类 Agent 需准备三要素：
2. 大模型 API：Agent 的“大脑”，负责理解意图与组织答案；
3. AI Coding 工具：如 Claude Code，负责将需求转化为代码。
大模型 API 与 AI Coding 工具角色不同：前者是入住后的“管家”，后者是建房子的“施工队”。在实际应用中，数据源对接企业真实接口，大模型可选用主流服务商，Coding 工具本地部署即可运行。
02 第一步：AI 自读文档，快速交付可用版本
将比赛教程直接输入给 AI Coding 工具，并设定四条指令：
2. 遇到需输入密码等敏感操作时暂停；
3. 完成后对照校验清单验收；
4. 分段汇报进度，最终输出验收表。
AI 在执行写代码前，先执行了关键一步：全量拉取数据并预览。这不仅用于验证接口返回字段与文档的一致性，更为后续测试提供了基准数据集。
从获取入口到 Agent 能正确回答四道练习题，仅耗时 9 分钟。遵循“先完成再完美”原则，优先交付可用版本，为后续优化留出充足时间。
03 第二步：确立铁律，禁止模型心算
核心设计原则：模型只负责理解与表达，所有计数与算术交由代码执行。
大模型在处理复杂数值计算时易出错且不稳定。因此，涉及数据统计时，Agent 应调用工具拉取数据，通过代码过滤、求和、排序后输出结果。
基于此原则，制定五条业务规矩：
翻页必须彻底
接口通常分页返回数据（如每页 100 条）。若只读取第一页，会导致数据缺失且无报错提示。必须在代码中强制自动翻页至最后一页。
明确时间维度
区分“创建时间”与“更新时间”。查询"9 月 10 日后订单”需明确是指下单时间还是变动时间，避免口径混淆。
最小化数据获取
遵循数据最小化原则，仅请求必要字段。这既是合规要求，也能降低权限风险。
注入当前时间
大模型无法感知实时日期。涉及“最近一周”、“上月”等相对时间查询时，必须将当前时间作为参数传入。
自动重试机制
针对接口限流或波动，代码层需实现指数退避重试机制，并对高频查询进行批量处理优化。
这些规矩并非高深技术，而是源于运营对数据特性的深刻理解。
04 第三步：构建可交互、可追溯的界面
参考成熟产品交互，快速重构前端界面，包含居中提问框、预设问题建议、历史会话侧边栏及深色模式。
界面最核心的功能是过程可追溯：每个回答均可展开，显示调用的接口、传递的参数及计算代码。这解决了 AI“黑盒”信任问题，让使用者能查验数据来源与逻辑。
此外，将会话记录统一存储于服务器端，支持多人查阅与考官复核，确保评审过程的透明性与便捷性。
05 第四步：双路验证，自出题对抗测试
为避免 AI 自我逻辑闭环导致的错误，采用“双路验证法”：
路径二：用自然语言向 Agent 提问；
对比两者结果，不一致处即为 Bug，需深挖到底。
如同财务中的出纳与会计分离，Agent 与验算脚本必须互不干扰。通过 41 道自测题的反复比对，修正了多个隐蔽的口径错误：
状态定义歧义
“要发货”是否包含“部分发货”？需明确状态词对应单一状态，相邻状态单独列示，避免默认合并计算。
模型自作主张
模型可能默认排除“已取消”订单，但业务需求可能要求统计在内。原则是：未明确说明的过滤条件一律不加。
金额计算精度
订单总额与单价乘以数量之和可能存在税费差异。需明确计算口径，并在结果中标注。
AI 的错误多源于业务口径而非计算能力，这正是运营人员的价值所在。
06 第五步：多维巡检，排查数据与逻辑隐患
在自测基础上，进行两轮深度巡检：
数据一致性自检
从数据内部逻辑出发，检查跨站点币种匹配、订单号重复性、时间逻辑矛盾（如创建晚于更新）、发货状态与包裹信息一致性等。此举发现了多处刁钻数据异常，如部分发货实则已发完、含税订单金额差异等。
换位思考模拟出题
站在出题人角度，依据教程强调的规则（如分页限制、特定字段获取方式）专门设计考题。实战证明，正式比赛中的难点均在此轮巡检中被覆盖。
正如管理学所言，问题应在价值最低环节被发现。赛前修正口径成本极低，赛后修正则代价高昂。
07 第六步：并发压测，确保高负载稳定
比赛规则同分看速度。为提升响应效率，采取两项策略：
自动化监控触发
后台程序每 8 秒轮询题目发布状态，一旦释放立即自动提交任务，消除人工反应延迟。
并行处理与压测
10 道题目并发执行而非串行排队。在执行前进行压力测试，模拟 10 个会话同时提问。测试中发现临时缓存空间不足导致数据覆盖的隐患，经调整扩容后解决。
这一环节模拟了企业场景中多人同时使用工具的高并发情况，避免了上线即崩溃的风险。
最终，系统在题目发布 15 秒内完成所有作答并提交，获满分第一。
08 运营加 AI Coding，是王炸组合
回顾全程，决定胜负的关键指令均无关代码细节，而是关于业务流程、数据陷阱、用户体验及系统稳定性。
AI 已拆除代码门槛，未来的差异在于设计思路。懂业务的老司机驾驭 AI 这辆跑车，将释放出巨大效能。
09 核心方法论总结
可将此次实战经验蒸馏为以下八条通用准则：
2. AI 自读文档，先全量拉取数据再开发；
3. 快速交付可用版，预留排查时间；
4. 禁止模型心算，代码处理算术，明确翻页、时间、字段及重试机制；
5. 界面需展示推导过程，记录云端化以便查验；
6. 双路验证：独立脚本算标准答案 vs Agent 答题，重点核查口径；
7. 双重巡检：数据内在逻辑自查 + 模拟出题人视角；
8. 并发必压测，修改操作需回读确认。
10 结语
此次夺冠验证了一个观点：行业中最该掌握 AI Coding 的，正是最懂业务的那批人。无论技术如何演进，对口径的严谨、对数据的敬畏、对场景的洞察，始终是构建高质量工具的基石。