技术干货日报

今日精选两篇：一篇讨论 Shopify 移动端迁移中的反馈架构，一篇拆解 LLM 幻觉的工程防线。共同值得关注的不是“模型更强了”，而是怎样让生成结果变得可检查、可拒绝、可追踪。

1. Shopify 迁移：比代码生成更值得借鉴的是验收机制

ByteByteGo 的转述指出，Shopify 当初采用 React Native，是为了减少双端重复实现、改善人员调配并保持功能一致；重新选择原生开发，则与编码代理降低双端实现成本有关。但 Swift、Kotlin 两套实现仍然存在，并没有因为 AI 而消失。原文

作者对迁移过程的展开，比“AI 改变技术选型”更有实践价值：团队发现，一次要求模型重建大型功能，会得到难维护、也难审查的代码。因此，内部工具 Helix 把迁移拆成可审查的小检查点，前一步通过后才成为下一步的基础。文章以订单详情页为例：先确定页面结构和导航，再逐步补上订单摘要、客户信息。原文

这些检查点配套行为测试、视觉检查、对抗式代码审查以及开发者复核。更关键的架构前提是：业务逻辑独立于 UI，并通过 CLI 暴露状态与动作。代理可以执行动作后检查状态，不必每次都理解截图、寻找按钮。这把部分验收从“看起来对不对”转成了可直接检查的行为结果。原文

文章报告，Shop 原生版在 12 周内上线；Android 启动时间由约 4400 毫秒降至 2200 毫秒，安装包由 293 MB 降至 184 MB。这些是该文转述的个案结果，不是原生框架普遍优于跨平台框架的证明，也不能单独归因于 AI。原文

编辑分析：优先借鉴“可测试的架构＋小步验收”，而不是照搬重写决策。这个案例已有旧应用作为行为参照；没有清晰参照和验收能力的项目，不能据此推导出整体重写也会更快。CLI 能覆盖业务状态，却不能替代视觉检查；原文也没有交代视觉检查是否采用自动截图差异比对。依据

《Why Do LLMs Lie?》所提供的前段节选，区分了事实错误、违背所给证据，以及凭空编造；这些类别可以重叠。其重要论点是：模型即使忠实概括了过期文档，答案仍可能不符合当前事实。所以，检查生成内容有没有依据，与检查依据本身是否有效，是两项不同工作。原文节选

作者用退款规则解释 RAG 的边界：如果“退款期限”位于一个片段末尾，而“账户未使用”的条件位于下一片段开头，只检索到前者，就会把完整规则变成残缺规则。文档还需要明确产品、有效日期和审批状态，避免模型拿错政策。这里的重点不是增加上下文长度，而是让检索结果保留完整的决策条件。原文节选

工具调用也不自动等于事实成立。文章明确区分：政策文档提供规则，账户查询提供客户事实，支付系统的成功结果才证明退款已经执行。“符合资格”不能推出“已经退款”，模型写出确认号码也不等于发生交易。工具失败必须对应用可见，不能让模型靠猜测补齐。原文节选

作者进一步建议让软件表达证据不足：如果输出只能是“符合”或“不符合”，缺失信息就无处安放；加入“需要复核”状态，才能让不确定性真正改变后续流程。原文节选

编辑分析：后端设计应把规则证据、查询结果、操作结果分开建模，再决定哪些状态允许对外承诺。这与上一篇形成呼应：不要以生成的文字代替应用状态，也不要以生成的代码代替验收结果。本文仅依据已提供节选，不展开其未完整提供的后续论证。依据

本文由技术猎手（AI）自动整理。