先跑通一个最小闭环，再扩展模型能力

开始构建一个 AI 应用时，最容易先关注模型名字、框架和功能清单。我更愿意先问一个小问题：这一次输入，究竟要变成什么样的、能够验证的结果？

先写结果的边界

“做一个知识助手”不是足够清楚的任务。它没有说明资料来自哪里，也没有说明什么算回答正确。把任务缩小成“根据这一份使用说明，回答一个操作步骤，并给出对应段落”，就能明确输入、证据和输出之间的关系。这个闭环不一定复杂，但必须能被检查。

如果连这个小任务都无法稳定完成，增加更多工具通常只会让问题难以定位。此时需要观察的是模型是否看到了正确资料、指令是否清楚，以及结果是否真的遵守了要求，而不是先给它添加一个更复杂的工作流。

保留可以替换的边界

我把这四步看作学习时的基本结构。整理上下文负责选择资料，不负责伪造缺失信息；模型负责提出结果，不负责宣布结果一定正确；验证负责比较结果与要求，不应该只重复模型自己的判断。明确分工以后，更换一个模型或一种检索方式，就不必重写所有部分。

先记录失败，再增加功能

最小闭环也需要留下记录：输入的问题、使用的资料版本、模型与参数、原始输出，以及失败发生在哪一步。这里的记录不是把密码、密钥和所有用户内容无差别写入日志，而是保留足以复现问题、又经过必要脱敏的信息。

例如，回答没有引用时，先判断资料中是否存在答案，再判断相关段落是否进入上下文。如果答案本来不存在，正确的改进可能是让系统拒绝猜测；如果资料存在却没有被选中，才应该继续分析检索。两种失败不应该都被归为“模型不够聪明”。

本地推理的运行设置也应该进入记录。例如，在 PyTorch 中，inference_mode 不会自动把网络切换成 eval 模式；不记录梯度与调整某些层的评估行为，是两个不同的问题。只记录模型名称而遗漏运行设置，会让后续比较缺少条件。

什么时候才值得扩展

当一组代表性问题能够重复通过，并且失败案例已经被记录，再考虑增加资料源、工具或自动执行。每增加一个能力，也增加一种新的失败方式。原有测试应该继续保留，避免新能力改善了演示效果，却破坏了已经跑通的基本任务。

这不是要求所有应用都从零开发，而是在使用任何框架之前，先想清楚可验证的闭环。本文讨论的是构建与学习方法，不提供未经实测的效果或性能承诺。