本周，你的团队并不需要更好的 AI 模型
别再盲目寻找新的 AI 模型了。你真正需要的升级是你的工作流。
大多数团队都专注于哪个模型看起来更聪明。他们对新发布的模型进行基准测试，并为智能程度争论不休。但如果你在使用 LLM 进行开发，你就会知道真正的痛点所在。问题不在于代码写得不好，而在于执行得不好。
你会看到这些问题：
- 在任务执行到一半时中断的 Agent 循环。
- 让用户感到困惑的审批提示。
- 在重试过程中断裂的上下文链。
- 因为自动化丢失了状态而需要人工进行清理。
智能水平在提升，但运维控制力却在滞后。我们正在进入“编排税”（orchestration tax）时代。如果你不为此做规划，你将不得不通过系统停机和静默失败来付出代价。
AI 的输出很少是最终产品。它是更大系统中的一个中间步骤。你必须解决以下问题：
- 任务在超时后能否恢复？
- 我们能否审计每一次审批？
- 我们能否在不产生重复操作的情况下重新运行步骤？
- 人类能否在执行过程中接管？
高级工程师多年前就在支付系统和后台任务中解决了这些问题。我们使用了幂等键（idempotency keys）、检查点（checkpoints）和事务日志（transaction logs）。AI 并没有创造这些问题，它只是让这些问题发生得更快了。
在确定执行契约（execution contract）之前，不要急着挑选模型。这就像是为一辆没有刹车的赛车挑选赛车引擎一样。
使用以下步骤构建可靠的工作流：
将 AI 工作拆分为细小的步骤 不要使用一个巨大的提示词（prompt）。将其分解为：收集上下文、提出变更建议、运行检查、请求审批以及应用变更。
使用持久化存储 使用数据库来跟踪状态、步骤和尝试次数。如果工作节点崩溃，你可以从状态中恢复，而不是从内存中恢复。
强制执行幂等性 每一个改变数据的操作都需要一个稳定的键。如果一个步骤运行了两次，结果必须保持一致。
通过分层管理权限 不要总是请求审批。创建不同的层级：
- Tier 0：只读任务（自动审批）。
- Tier 1：低风险写入（批量审批）。
- Tier 2：高影响任务（人工检查点）。
- 跟踪运维指标 不要只盯着延迟和成本。要跟踪超时率、重试成功率和回滚频率。
最优秀的 AI 团队不会吹嘘神奇的提示词。他们会运行枯燥、持久且可观测的流水线。他们的优势不在于模型，而在于严谨的系统工程。
Source: https://dev.to/chrisbuildsonline/your-team-doesnt-need-a-better-ai-model-this-week-29l4
Optional learning community: https://t.me/GyaanSetuAi