非常令人兴奋。您现在可以在自己的计算机上直接在 Claude Desktop 上执行 Claude Code 的各种疯狂操作。太棒了。这将使更多人能够释放 Claude Code 的力量。 （他们在公告中链接了我在 CC 上的帖子，真是太酷了，谢谢团队 @AnthropicAI）

我从 @Aish_Reganti 和 @KiritiBadam 关于构建成功企业 AI 产品的演讲中获得的最大收获： 1. AI 产品与传统软件在两个基本方面不同：它们是非确定性的，并且你需要不断权衡自主性与控制。传统产品开发流程在产品对相同输入给出不同答案并且能够自主执行时会崩溃。 2. 自主性与控制的权衡是每个 AI 产品的核心设计决策。Aish 和 Kiriti 将其框架化为一个光谱：一端，AI 在最小的保护措施下自主行动；另一端，系统受到严格限制，有明确的规则和人类参与的关卡。大多数成功的企业 AI 产品位于中间，动态调整控制，基于置信度评分、上下文和风险。 3. 大多数 AI 产品失败源于执行失误，而非模型限制。Aish 和 Kiriti 看到团队在责怪底层 LLM 时，真正的问题是产品范围不清晰、缺少保护措施或用户引导不佳。一个幻觉率为 5% 的模型仍然可以驱动出色的产品，只要你设计用户体验以展示置信度评分，让用户验证输出，并限制任务。可操作的见解是：在要求更好的模型之前，审计你的产品设计、评估覆盖范围和用户流程。在大多数情况下，执行纪律胜过模型性能。 4. 你的 V1 AI 产品应该解决一个狭窄的高价值问题，并设定严格的保护措施。团队在第一次尝试时失败于试图构建通用助手或代理。选择一个工作流程，自动化一个重复性任务，或非常好地回答一个类别的问题。狭窄的范围让你能够收集集中反馈，更快地调整模型，并在扩展之前证明价值。广度在你掌握核心循环后再来。 5. 可观察性和日志记录对 AI 产品比传统软件更为关键，因为 AI 行为是非确定性的，更难以调试。你应该记录的不仅仅是错误，还有模型置信度评分、输入特征、用户修正和延迟指标。当生产中出现问题时，这些日志是重建模型所见内容及其做出特定决策原因的唯一方法。尽早投资于日志记录基础设施，在你面临危机之前。 6. 评估是必要的，但不足够。评估帮助你测量模型在已知测试用例上的性能，但它们无法捕捉完整的产品体验、生产中的边缘案例或用户满意度。仅依赖评估的团队发布的产品在测试中得分良好，但在实际使用中失败。将评估与持续监控、用户反馈循环和可观察性工具结合，以捕捉自动化测试遗漏的内容。 7. “持续校准”取代了传统的迭代产品开发周期。由于 AI 模型会漂移，用户期望也会变化，团队必须不断测量现实世界的性能，并调整提示、保护措施或模型版本。Aish 和 Kiriti 建议从第一天起就对你的产品进行仪器化，以捕捉用户反馈和模型输出，然后每周审查这些数据。没有持续校准，你的 AI 产品将悄然退化，用户会在你注意到之前流失。 8. AI 的持续部署意味着将模型更新和提示更改作为代码发布，而不是手动干预。传统软件部署代码；AI 产品部署代码加上模型权重、提示和检索逻辑。Aish 和 Kiriti 主张将提示和模型配置视为你 CI/CD 管道中的版本化工件，并通过评估进行自动回归测试。这可以防止 PM 在 UI 中调整提示并破坏生产的常见反模式。好处是：你可以安全地迭代模型行为，并立即回滚不良更改。 9. AI 产品失败是因为团队低估了数据质量的重要性。Aish 和 Kiriti 看到团队急于微调模型或添加功能，而没有首先审计他们的训练和评估数据是否真实反映了现实世界的使用情况。垃圾进，垃圾出对 AI 来说适用得更为明显：如果你的数据过时、偏见或与用户需求不一致，再多的提示工程或模型调整也无法拯救你。首先要整理好你的数据。