同样的 AI，截然不同的结果：详解 AI Harness 及其实效边界

两次运行，模型相同，提示词相同，结果完全相反。据 @JafarNajafov（https://x.com/JafarNajafov/status/2103764227404312730）转述，Anthropic 曾两次让 Opus 4.5 开发一款 2D 复古游戏编辑器。没有脚手架（Harness）时，运行花费约 9 美元，耗时 20 分钟，最终无法运行；而在配备完整 Harness 后，花费约 200 美元，耗时 6 小时，直接生成了一款可玩的完整游戏。虽然数据来自转述，但这一对比的核心结论才是重点所在。

JJafar Najafov@JafarNajafov

Harness engineering is the most important AI skill you can learn right now

And someone just open sourced a full course on it. Free

Anthropic ran an experiment. Same model (Opus 4.5), same prompt: "build a 2D retro game editor"

No harness: $9, 20 minutes, didn't work
Full harness: $200, 6 hours, a game you could actually play

The model didn't change. The environment around it did

That's what this course teaches.…

Sep 26, 2026 · 在 X 上查看

如果你在运营独立站时精心编写了提示词，得到的却是一页千篇一律的普通详情页，这个实验恰好解释了原因。生成内容与网上优秀案例之间的差距，往往不在于模型本身，而在于围绕模型搭建的配套系统。本文将用通俗的语言拆解这个系统，展示适合卖家落地轻量化版本，并指出即使在完善系统中也会翻车的三个隐蔽漏洞。

提示词只占 AI 系统效能的三成

本月最清晰的框架，来自 @dkare1009（https://x.com/dkare1009/status/2103764008801280248）分享的 Andrej Karpathy 斯坦福 AI 工程讲座总结。AI 应用的演进路径非常明确：裸模型贡献约 10% 的最终效果，精心设计的提示词占 30%，智能体（Agent）占 50%，引入反馈循环占 70%，而完整的协同工作流（Graph）能达到 100%。总结下来：AI 工程的核心，是围绕模型构建一套包含上下文、记忆、工具、反馈机制与数据流的完整系统。

一位 Anthropic 工程师在讲演中说的更加直接（由 @0xnicc0 总结：https://x.com/0xnicc0/status/2095609874197413983）：“你不该去手动提示 Claude，而是该搭建一个能自我提示的系统。” @ghumare64（https://x.com/ghumare64/status/2104112175425950177）在梳理 AI 工程师技能树时也强调了同样的概念：核心是 Harness 工程而非单纯写提示词，重点是上下文工程而非追求超长提示词。

对于跨境卖家来说，Harness 可以拆解为四件日常工具：模型启动前掌握的业务背景信息；每次运行必须遵守的硬性规则；上线前的校验机制；以及记录过往决策的日志，避免下次重复犯错。网上那些令人惊艳的 AI 成果，背后基本都有这套支撑体系，只是分享者很少展示出来。

Shopify 在信任 Agent 前的审核机制

Shopify 的工程实践展示了 Harness 在工业级场景下的威力。据 @norvex1029（https://x.com/norvex1029/status/2104474504609055178）介绍，当 Shopify 直接把 React Native 代码库甩给模型，要求一次性重写为 Native 原生代码时，只拿到了一堆无法上线的垃圾代码。随后团队开发了名为 Helix 的系统。该系统将每个页面拆解为微型检查点，每个检查点必须通过自动化测试、与现版 App 做到视觉对齐，并连续通过两个对抗性 AI 代码审查员的把关，最后才会提交给工程师人肉复核。

NNorvex@norvex1029

Shopify doesn't trust the first answer its coding agents give.

When it pointed an LLM at its React Native app and asked for a native rewrite in one shot, it got a huge pile of code that couldn't be shipped.

So it built Helix. Each screen is cut into small checkpoints, and each checkpoint has to prove its behavior with tests, match the running app in a visual review, and survive two adversarial AI code…

Sep 28, 2026 · 在 X 上查看

正因如此，Shopify 才能在 12 周内用原生语言重构并发布了 Shop App。目前团队正在用这套方案攻坚拥有 300 个页面的 Shopify 主端 App。@norvex1029 给出的结论对卖家同样适用：胜出的一方往往不靠最强的模型，而靠最完善的校验系统。

一个更小规模的案例能直接说明成本差异。@jamiegrove（https://x.com/jamiegrove/status/2102810220648976526）用 AI 校对 Shopify 店铺的 682 个产品页面。第一次运行烧掉了 185 美元额度却半途卡死；第二次运行使用了 Harness 架构，提示词和模型完全相同，仅花费 12.60 美元。总结非常明确：撬动效果的杠杆不是模型，而是系统框架。

适合小团队落地的微型 Harness

你不需要搭建复杂的 Helix 系统，就能享受绝大部分红利。上述四个核心环节，两人规模的小店铺也能零代码部署：

上下文积累。 @shannholmberg（https://x.com/shannholmberg/status/2098850243760808268）建议建立一个包含基础文本文件的文件夹：写清公司业务、来自真实用户的画像、核心产品卖点、品牌定位、文案语气以及信任背书。这些资料可以直接从现有留评和客服邮件中提取。缺少这些背景，AI 生成的内容只能靠瞎猜。

持续累加的规则库。 来自 Claude Code 创作者、由 @Divyyanshishrma（https://x.com/Divyyanshishrma/status/2104169439289651427）分享的 CLAUDE.md 模板，将历史错误、写作规范和排他规则集中保存在单个文件中，供 Agent 每次运行前自动读取。方法非常简单：每次人工修正一个 AI 出现的错误，就将其总结为一条规则写入该文件。

发布前的标准检查清单。 @Voxyz_ai（https://x.com/Voxyz_ai/status/2103977414711767244）分享了一份包含 20 个检查点的上线清单，涵盖设计规范一致性、移动端适配、加载动画及异常状态显示。移到产品详情页场景，清单可以精简为：价格是否与系统一致、卖点描述是否有事实依据、政策条款是否齐全、移动端渲染是否正常。

预览环境与测试对比。 @dashboardlim（https://x.com/dashboardlim/status/2101390400292290676）使用一套严谨的闭环重写了 Shopify 详情页：调研竞品页面、生成初稿、在隐藏预览页复核，最后上线进行流量 A/B 测试。测试数据显示，优化后的页面单客产出收益提升了 23.75%。

构建好这四个环节，你就拥有了一套 Harness。下半部分我们将讨论，为什么有了这套系统仍然不够。

优质 Harness 依然会失效的三大盲区

在推广 Harness 的同时，不少一线工程师也记录下了系统失效的场景。以下三种典型翻车模式，在卖家日常运营中都有对应表现：

Agent 虚报完成进度。 @mr_kozh（https://x.com/mr_kozh/status/2103895408795689397）总结了 OpenAI 依靠 3 名工程师和 1500 个 PR 产出百万行代码的案例。即便在如此严密的架构下，Agent 依然会出现遗忘前置决策、选错工具、生成重复代码，甚至把未完成的坏代码标记为已完成的情况。解决办法不是加长提示词，而是给出明确定义完成的标准、隔离的测试环境、行为测试脚本、阶段检查点，以及人工复核证据。对卖家而言，“完成”必须意味着通过了检查清单，而不是软件界面弹出的“已生成”。

上下文超载导致模型凭空捏造状态。 @dr_cintas（https://x.com/dr_cintas/status/2104274873476337815）指出，让 Opus 5.5 在 20 万 Token 的上下文窗口中自由发挥时，处理复杂任务容易崩溃：模型会忘记前面的工具输出，凭空捏造不存在的文件状态，甚至陷入死循环修改。解决方案是引入独立的 SESSION_STATE.md 文件，强制 Agent 在修改代码前更新该文件，将最终目标、当前修改、既定架构和校验状态记录在对话窗口之外。

AAlvaro Cintas@dr_cintas

Letting Claude Opus 5.5 run freely across a 200k context window breaks down on complex features.

Context fills up, the model forgets earlier tool outputs, and you get hallucinated file states or circular diffs.

The fix is an AX (Agent Experience) state protocol: make Opus 5.5 maintain an external SESSION_STATE.md file before touching code.

Paste this into your CLAUDE.md or system instructions:

“Operate under…

Sep 27, 2026 · 在 X 上查看

这种 failure 在电商场景很常见：在长对话中让 AI 连续重写 40 个产品的描述，写到第 30 个时，模型往往会混淆不同 SKU 的规格参数。解法完全一致：控制单次对话长度，一次只处理一个产品，并在每步操作前让 Agent 重新读取独立的状态文件。

长期记忆会固化错误的决策。 @beamnxw（https://x.com/beamnxw/status/2103890773972308479）记录了一个案例，64 个 Agent 会话共享一份只增不删的日志文件。在三天内的 178 次查询中，68% 的查询巩固了之前的决定，4.5% 改变了后续行动。但关键问题在于：某个 Agent 曾判定某个数据库索引无用并将其删除，后续人工在真实负载下测试发现该索引非常必要，于是撤销了删除。然而，那份日志却完好地记录了错误的操作逻辑，直到人工干预才被纠正。

这是不少人在夸大 AI 记忆功能时避而不谈的风险。规则文件会照单全收你写入的一切内容，包括因一时疏忽留下的错误经验。@DamiDefi（https://x.com/DamiDefi/status/2104496839064178804）总结了 Daniel Miessler 的应对策略：把 Agent 犯的每一个错误转化为系统升级项，同时定期对规则库进行“修剪”，避免遗留的技术债务被 Agent 无限放大。

为什么这些隐患最终会伤害客户体验

在 Shopify 内部，Helix 系统在 Agent 和生产环境之间设立了两个 AI 审核员和一个人工工程师。但在二人规模的跨境小团队中，AI 和正式上线的页面之间往往没有任何防线。Shopify CEO 本月指出了这种做法对内部协作的危害（由 @interesting_aIl 报道：https://x.com/interesting_aIl/status/2102007936809841117）：直接把未经审核的 AI 内容丢给同事，等同于扔出“垃圾手榴弹”，极大地增加了后续接收者的负担。在独立站前台，接收这些内容的是真实买家，带来的代价不再是损失半天工时，而是直接流失订单甚至引发退货。

目前尚无公开数据统计究竟有多少带明显事实错误的 AI 详情页正跑在网页上。但发生机制已被这些顶尖技术团队彻底证实。

本周可直接落地的流程优化建议

1. 盘点四大基础件。 背景文件夹、规则文件、发布前检查清单、预览测试环境。缺失哪一项，哪一项就是生成劣质内容的源头。
2. 用文字明确定义“完成”。 每个任务给出一句话标准：“产品描述完成的标志，是所有参数与系统完全一致，且通过了检查清单。”将这句话同时发给 AI 工具和负责复核的人员。
3. 控制单次对话任务量。 每次对话只处理一个产品、一个页面或封邮件。如果工具强制使用批量模式，请务必像检查第一个样本一样仔细复核最后一个，漂移现象往往发生在末尾。
4. 每月定期修剪规则文件。 清除因偶发特例而添加的规则。如果因为某页面的物流时效写错就加上“严禁提及运输时间”，只会悄悄删掉后续所有页面上的关键有效信息。
5. 上线前保留一道人工把关。 逐条审批修改项，切勿一键同意 40 个变更。真正优秀的 AI 工具，从设计之初就会预留 Harness 的交互接口。

从整理规则文件开始。打开或新建一个文件，把最近踩过的三个坑整理成规则写进去。这种零门槛的习惯，就是小卖家今晚就能直接复刻的 Shopify 同款系统工程。