一条完整的 AI Engineering 路径，但不要求你从第一课开始。

心智模型

把每次生成理解成在当前输入、Context、模型参数与解码策略条件下进行的一次概率选择。

为什么重要

同一个请求可能产生不同结果，因此可靠系统需要约束与验证，而不能假设模型天然确定性。

心智模型

把模型知识与预测，同 Tool Result、数据库状态、权限、时间戳和 Side Effect 等 Runtime Fact 明确分开。

为什么重要

混淆两者会产生虚构状态、错误确认和不安全操作，而这些事实模型本身无法独立证明。

心智模型

分析 Prompt 时优先按 Token 而不是字符计数，因为不同语言和字符串消耗的 Context 可能差异很大。

为什么重要

Token 边界会影响上下文预算、截断、价格、延迟，以及模型识别某些模式的稳定性。

心智模型

把生成理解成 Autoregressive Loop：每个已选择 Token 都会成为下一步输入，因此早期选择会持续改变后续概率。

为什么重要

这解释了为什么轻微的 Decoding 或 Context 变化会产生完全不同的续写，也解释了长输出如何逐步累积不确定性。

心智模型

把 Decoding Setting 当作输出风险控制：更低随机性收窄选择，更高随机性会探索更多低概率候选。

为什么重要

Sampling 能调整多样性与稳定性，却无法修复缺失知识、错误 Context 或模型本身的能力缺口。

心智模型

把 Context 当作有硬上限的工作空间；指令、示例、检索片段、Tool Result 和历史对话都在争夺容量。

为什么重要

超过窗口或分配不当会静默丢失关键证据，让原本有能力的模型表现得不稳定。

心智模型

把 Capability 当作通过真实测量得到的 Operating Region，而不是从一个 Benchmark 分数或产品标签推导出的普遍属性。

为什么重要

如果把某个 Workload 上的成功直接外推到不同数据、Tool、语言或风险等级，系统很容易在边界外失效。

心智模型

分别分析 First-token Latency、总完成时间、Concurrency、Batching、Queueing 与资源饱和，因为优化一个指标可能恶化另一个。

为什么重要

AI 系统常在单用户 Demo 中很快，却在并发流量下因忽略 Throughput 与 Queueing 而迅速退化。

心智模型

把 Context 当作优先级问题：高 Authority、高 Relevance 的证据应该比重复、遥远或噪声信息更容易被模型利用。

为什么重要

Prompt 即使装得下所有内容，也可能因为关键信息被大量竞争信号稀释而失败。

心智模型

更多 Context 并不天然更好；每一段信息都应该因为能改变或支撑当前任务结果而获得位置。

为什么重要

无关信息会消耗 Attention 与预算、增加冲突风险，并可能在窗口尚未填满时就降低结果质量。

心智模型

把 Context 理解成有顺序的序列，而不是所有事实同等可见的信息袋；位置、邻近关系和先后次序都会产生影响。

为什么重要

当指令或检索证据存在冲突时，即使内容完全相同，仅调整顺序也可能改变模型行为。

心智模型

Memory 不是额外的神奇 Context Window；它是存储与 Retrieval 系统，需要时其选中内容仍然要重新进入当前 Context。

为什么重要

区分两者能明确 Owner、Persistence、Freshness 与 Privacy，也解释了为什么“记住”的信息仍可能没有进入某次模型调用。

心智模型

把 Embedding 看成学习得到的坐标系；向量接近表示在训练目标下相似，并不意味着事实、Authority 或含义完全等价。

为什么重要

Semantic Search 与 Clustering 都依赖这套几何，因此检索质量受限于 Embedding Space 真正能够表达的内容。

心智模型

Similarity 是 Ranking Signal 而不是事实；解释分数前要明确 Embedding Space、Distance Metric、候选集合和评测任务。

为什么重要

高相似度仍可能检索到无关或不权威证据，因此后续过滤与 Evaluation 仍然不可缺少。

心智模型

不同 Modality 保留不同 Evidence；共享表示能让它们交互，但可能丢失原始来源中的空间、时间或结构细节。

为什么重要

理解 Representation Boundary 能帮助判断跨模态 Summary 何时足够，以及什么时候必须回到原始 Modality 检查。

心智模型

多模态表示只是中间视图；重要结论仍应回到原始模态，核对其中的空间、时间或结构证据。

为什么重要

模态转换会丢失或扭曲信息，尤其容易影响精确的视觉、时序和定位判断。

心智模型

先按 Source Role 与 Trust Boundary 分配 Authority，再解决内容冲突；相关性或强烈措辞不会自动获得覆盖高层指令的权限。

为什么重要

没有清晰层级时，不可信或低 Authority 文本可能只因为更新、更强势就错误地重定向模型。

心智模型

显式识别冲突，确定真正控制行为的 Instruction，保留不冲突要求，并暴露仍无法解决的 Constraint，而不是悄悄折中。

为什么重要

静默混合可能产生既违背用户 Intent 又违反 System Policy、但表面上看似合规的行为。

心智模型

把 Example 当作行为示范；对于必须成立的保证，仍要依赖 Runtime 校验、权限和显式 Contract。

为什么重要

区分这两者，可以避免把 Few-shot 模仿误认为安全、授权或正确性约束。

心智模型

Prompt 表达 Intent，Context 提供 Evidence，Runtime Code 负责 Authorization、State Transition、Validation 与 Side-effect Control 等 Guarantee。

为什么重要

如果把硬性 Guarantee 只写进 Prompt，就会把本应可执行的系统要求降级成概率性模型行为。

心智模型

不要只增加形容词，而要明确 Decision Boundary：做什么、不做什么、哪些 Evidence 重要，以及如何检查成功。

为什么重要

具体 Prompt 能提升一致性，但前提是它真正澄清任务；没有更清晰边界的冗长文本只会消耗 Context。

心智模型

只在输入、证据、责任或验收标准发生变化的边界上拆分，不要为了增加 Prompt 数量而切碎一个完整任务。

为什么重要

合理拆分能暴露错误并提高控制力，过度拆分则会增加延迟、协调成本和 Context Drift。

心智模型

只有额外推理可能改变 Decision 时才投入更多预算，并为收益递减情况设置停止条件与更简单的 Fallback。

为什么重要

无限推理会持续增加延迟和成本，还可能引入陈旧假设，却并不能保证答案更好。

心智模型

把 Plan 理解成对候选路径的搜索：每条路径都有成本、约束、观察结果和停止条件。

为什么重要

只有探索替代方案能够改变决策时，额外 Planning 才值得；否则它只会增加延迟和失败面。

心智模型

先问“什么证据证明它”，再问“模型为什么说自己相信它”；优先使用 Test、Source Check、Calculation、Trace 与 Independent Verifier。

为什么重要

模型可能生成很有说服力的自我检查却重复同一隐藏错误，因此独立证据通常比自我解释更可靠。

心智模型

评价系统时应依赖可检查、可复现的证据，而不是依赖模型对自己如何推理的有说服力解释。

为什么重要

不透明推理不能替代 Trace、测试、来源证据和 Runtime 事实，尤其是在调试和治理场景。

心智模型

语言模型优化的是 Plausible Continuation，因此事实可信度必须来自 Source Grounding 与 Verification，而不能来自语言流畅度。

为什么重要

没有证据的内容越自然，用户和下游自动化越容易在没有检查的情况下接受错误。

心智模型

统计不同 Confidence Band 下的真实正确率，并对不确定案例采用不同路由，而不是把置信表达当成装饰性文本。

为什么重要

高置信错误在自动化中尤其危险，因为下游系统可能把一个弱猜测直接转化成强动作。

心智模型

把 Model Quality 视为依赖 Workload Distribution 的条件属性；持续监控输入变化，并在 Operating Population 变化后重新评测。

为什么重要

即使模型本身完全没有改变，只要真实环境离开 Offline Test 覆盖条件，生产准确率也可能明显下降。

心智模型

让模型 Capability 承担灵活认知，让 Software Contract 承担 Invariant；不要因为模型多次表现正确就推断它形成了 Guarantee。

为什么重要

把概率性能力误认为 Permission、Format、Factuality 或 Transaction Correctness 的强制保证，是常见生产故障来源。

心智模型

理解模型行为时要追问：预训练奖励了什么信号、这种信号擅长学到哪些模式，以及它从未提供哪些 Guarantee。

为什么重要

许多模型局限来自优化目标本身：模型主要被训练做预测，而不是天然优化 Truth、Policy Compliance 或具体任务正确性。

心智模型

当目标行为能够由代表性样本清楚示范，并且应用层无法更低成本地解决问题时，再考虑 SFT。

为什么重要

Fine-tuning 会全局改变模型行为，低质量样本或覆盖不足会制造难以通过 Prompt 隔离的持久回归。

心智模型

把 Preference Optimization 理解成改变行为出现概率，而不是向模型安装不可违反的规则或权威事实数据库。

为什么重要

Post-training 能让模型表现更稳定，但权限、Truth 与高后果动作仍然需要 Runtime Enforcement。

心智模型

把合成样本视为带有继承偏差与错误的变换证据；用于 Supervision 前要验证多样性、正确性、覆盖和数据泄漏。

为什么重要

大量扩展生成数据的同时，也可能同样快速地放大 Teacher 的盲点和系统性错误。

心智模型

优先选择在真实 Workload 下能够满足已测任务要求的最小模型，只有证据显示能力不足时再升级。

为什么重要

默认使用最大模型会掩盖架构问题，并可能增加成本和延迟，却没有显著改善用户结果。

心智模型

根据 Data Boundary、Customization、Latency、Cost、Auditability 与维护能力等具体要求选择部署姿态，而不是按立场选模型。

为什么重要

错误选择可能制造不必要的基础设施负担或 Vendor Lock-in，却没有改善用户真正需要的应用行为。

心智模型

先写 Contract：定义什么叫成功以及如何验证，再把 Generation 当作这个边界内的实现步骤。

为什么重要

清晰 Spec 能减少反复改 Prompt，并让 Review 区分真实缺陷与未声明目标造成的分歧。

心智模型

先提供能够确定 Intent 与 Constraint 的最小 Repository Slice，再让 Agent 通过显式 Dependency 或 Symbol Relationship 发现更多文件。

为什么重要

真实 Coding Quality 的关键往往不是生成语法，而是遵守当前文件之外已经存在的 Repository Contract。

心智模型

有用的 Plan 是一个小型、可执行的修改假设：要改什么，以及如何证明它安全；而不是形式化长文。

为什么重要

这样可以减少不必要的大范围修改，并在代码生成放大问题之前更早发现架构回归。

心智模型

从 Evidence 向外 Review：先检查 Spec、Affected Dependency、Executable Test、Diff Boundary 与 Failure Case，再判断实现解释。

为什么重要

AI 能生成局部很合理却违反隐藏 Repository Contract 的代码，因此 Review 必须独立于 Generator 的自信。

心智模型

先把 Requirement 转成 Test 或具体 Check，再让 AI 朝固定 Target 生成；如果测试本身被修改，要单独 Review。

为什么重要

没有预先存在的 Evidence 时，Agent 可能同时修改实现与期望，最终让自己的输出看起来永远是正确的。

心智模型

映射 Transitive Change，运行 Compatibility/Migration Test，检查生成 Artifact 与 Rollback，再判断一次成功 Install/Build 是否真的完成。

为什么重要

Dependency 变化常常能够编译通过，却静默改变 Runtime Semantics、Data Compatibility 或 Deployment Behavior。

心智模型

只有确认输入独立、共享状态受控、Side Effect 有边界且存在确定的合并或验证步骤后，才进行并行。

为什么重要

并行可以降低延迟，但隐藏依赖会制造重复工作、冲突写入、相关性错误和高成本 Reconciliation。

心智模型

把模型输出当作不可信 API Response：先约束 Schema，再解析、验证语义，并显式处理拒绝或不合法结果。

为什么重要

看起来合法的 JSON 仍可能缺字段或语义错误，因此可靠自动化需要 Schema 与 Runtime Validation 同时存在。

心智模型

使用有限 Buffer、Pacing、Cancellation、Batching 或 Drop Policy 显式控制 Flow，而不是假设 Consumer 永远跟得上。

为什么重要

没有 Backpressure 时，慢 Client 会导致内存增长、延迟尖峰、连接失败，甚至把负载级联到整个应用。

心智模型

把 Durable Interaction State 存在显式 Software Structure 中，每次 Turn 只把当前相关部分重新渲染进模型 Context。

为什么重要

如果直接把聊天历史当作 State Store，长对话会变得脆弱、昂贵，并且难以验证、恢复或迁移。

心智模型

使用 Capability Need、Latency、Cost、Policy 与 Failure Class 等可观察标准进行 Routing，并在 Incident 发生前定义 Fallback。

为什么重要

故障时临时切模型可能在最糟糕的时刻静默改变质量、Context Limit、Tool Behavior 或 Policy Assumption。

心智模型

把 Rate Limit 当作正常 Capacity Signal：限制并发、Queue Work、带 Jitter Backoff、遵守 Retry Hint，并对非关键任务 Degrade/Defer。

为什么重要

忽略限制会把正常容量压力变成 Retry Storm、长 Queue、级联 Timeout 与严重用户体验问题。

心智模型

要主动分配上下文容量：先为最高 Authority、最高价值的信息保留空间，再加入可选细节。

为什么重要

没有预算时，系统会持续堆积 Context，直到关键内容被截断、稀释，或者处理成本失控。

心智模型

先区分 Stable 与 Dynamic Context，再在支持时让 Cache 利用稳定前缀；不要反过来为了 Cache 破坏上下文结构。

为什么重要

这样既能降低成本和延迟，也能保持 Context 责任边界清晰。

心智模型

压缩前先定义 Retention Objective：明确哪些 Fact、Decision、Unresolved Question、Provenance 与 Constraint 必须保留。

为什么重要

粗糙 Summary 虽然节省 Token，却可能恰好删除后续保持一致性所需的关键证据或承诺。

心智模型

把 Context 当作生命周期而不是字符串拼接；每项信息都应有 Owner、Freshness、Authority、用途和移除条件。

为什么重要

良好的 Context 管理可以让长任务保持一致，同时控制 Token 成本、陈旧信息与指令冲突。

心智模型

围绕真正可复用的指令和数据设计稳定前缀，然后测量命中率、失效行为、成本和延迟。

为什么重要

设计不当的 Cache 会让 Prompt 过度绑定 Provider 细节，甚至保留陈旧 Context，却没有带来实际收益。

心智模型

围绕 Decision 选择 Chunk：足够小以隔离相关 Evidence，又足够大以保留 Definition、Relationship 与 Provenance。

为什么重要

Chunk 太大会增加噪声，太小又会把事实与限定条件拆开，两者都可能造成误导性 Retrieval。

心智模型

让不同 Retriever 分别解决自己擅长的失败模式，然后围绕同一评测目标融合或 Rerank 候选结果。

为什么重要

精确标识符与语义改写的检索特征不同，组合信号能在保留字面精度的同时提高召回。

心智模型

先用低成本 Retrieval 获得广泛 Recall，再把更高计算成本用于有限候选集，让更好的相关性判断改变最终证据顺序。

为什么重要

Rerank 能提升 Precision 而不必让第一阶段检索昂贵，但它无法找回一开始根本没有被召回的文档。

心智模型

在 Retrieval 之前先定义 Authority：区分一手来源、受治理内部记录、用户提供 Context、二手资料与模型生成结论。

为什么重要

没有 Authority 规则时，系统可能找到相关但更弱的证据，并高置信地覆盖真正应该主导决策的来源。

心智模型

对系统已经精确知道的事实使用 Metadata Constraint，再与 Semantic Retrieval 结合处理难以可靠字段化的语义。

为什么重要

只靠语义相似可能检索到错误 Customer、Version、Time Period 或 Access Scope，即使文本本身看起来高度相关。

心智模型

让每个检索阶段都可观察、可评测，从而把 Recall、Precision、Authority、延迟和成本问题归因到正确组件。

为什么重要

如果把 RAG 当成一个黑盒 Vector Search 调用，就很难知道证据在哪一步丢失，也难以稳定改进质量。

心智模型

用带标签或可人工检查的 Evidence Set 单独评测 Retrieval，并按 Query Type 分 Slice，区分 Recall、Ranking 与 Authority Failure。

为什么重要

Generator 再强也无法使用从未被检索到的证据，因此只看端到端分数会掩盖真正瓶颈。

心智模型

不要默认持久化全部内容；只有具备明确价值、作用域、Authority 与保留规则的信息才应从 Working 提升到 Durable。

为什么重要

区分两者可以防止临时猜测和短期任务状态被永久化，并在未来持续污染系统行为。

心智模型

每条 Memory 都需要 Provenance、Owner、Scope、Write Policy、Freshness 预期以及明确的 End-of-life 条件。

为什么重要

持久 Memory 会长期影响系统行为，因此陈旧或 Scope 错误的信息可能持续污染未来 Decision。

心智模型

依据 Provenance、Scope、Freshness 与 Source Authority 解决 Memory 冲突；记忆内容不能静默覆盖更强的当前来源。

为什么重要

如果不显式处理冲突，一个过期偏好或早期错误可能通过 Persistent Memory 反复压过已经修正的事实。

心智模型

每条 Durable Memory 都应回答“什么时候它不再安全可用”，通过 TTL、Source Revision、显式删除或 Policy Invalidation 实现。

为什么重要

没有 Expiry 的 Memory 会把过时偏好与事实变成长期隐藏 Context，并持续无声地影响未来输出。

心智模型

把个性化记忆和 Source of Truth 放在不同的 Authority Domain 中，并采用不同的写入、过期和纠错策略。

为什么重要

混在一起可能让某个用户的偏好覆盖权威知识，甚至污染其他用户的 Context。

心智模型

当 Identity 与 Relationship 本身就是一等事实时使用 Graph；丰富描述仍由 Unstructured Evidence 承担，并保持 Source Authority 不重复。

为什么重要

显式关系能让 Multi-hop、Dependency、Lineage 与 Constraint Query 比依赖 Embedding 猜结构更可靠。

心智模型

用非结构化搜索寻找语义，用结构化查询约束实体、日期、权限或关系，再显式融合两类结果。

为什么重要

当证据同时分布在文档和结构化记录中时，单独依赖任何一种检索方式都可能遗漏关键约束。

心智模型

把 Tool 设计成面向不确定 Caller 的窄 API：合法动作应清晰，非法动作应不可执行或显式失败，高后果影响要在执行前可见。

为什么重要

模糊 Tool Interface 会迫使模型猜测隐藏的应用语义，从而增加非法调用与不安全 Side Effect。

心智模型

HTTP 或函数调用成功只代表 Transport Success；真正使用前还要验证返回事实、标识符、状态和错误条件。

为什么重要

Agent 常在 Tool 看似成功却返回陈旧、不完整或异常数据后失败，而模型又容易把这些数据当成权威事实。

心智模型

把权限收窄到具体 Operation 与 Resource，只有真实任务需求无法安全完成时才逐步扩大。

为什么重要

当 Runtime 根本不暴露多余能力时，模型错误和 Prompt Injection 即使发生，造成的损害也会显著缩小。

心智模型

授权 Autonomy 前先判断可逆性；通过 Preview、Draft、Staging、Soft Delete 与 Approval Gate 延迟不可逆 Commit。

为什么重要

当动作涉及资金、删除数据、发送消息或永久改变外部状态时，可接受的模型不确定性必须显著降低。

心智模型

把 Review 放在不确定性与影响不可接受的转换点，并向 Reviewer 提供足够证据来批准、拒绝或修改动作。

为什么重要

如果人工审批只是形式、发生太晚或缺少必要 Context，Human-in-the-loop 并不能真正控制风险。

心智模型

用 MCP 描述和传输 Capability，但把 Permission、Business State、Validation 与高后果 Action Policy 保留在 Host Application。

为什么重要

建立 Protocol Connection 不等于获得 Trust 或 Authority；混淆 Transport 与 Permission 会让 Tool 暴露范围失控。

心智模型

先 Discovery，再只调用双方都明确支持的 Capability；把缺失 Capability 当作正常 Compatibility State。

为什么重要

Protocol 持续演进会产生异构部署，硬编码“所有 Server/Client 都支持同样能力”会让集成非常脆弱。

心智模型

把长任务状态、Elicited 信息、取消与完成语义视为 Protocol/Application 责任，而不是隐藏在对话状态里。

为什么重要

当 MCP 工作流变成异步任务或需要跨多轮的结构化用户参与时，这个版本敏感边界会直接影响系统正确性。

心智模型

把 Agent 建模成具有 Observation、Decision、Action、Verification 与停止条件的显式状态机，而不是无限对话。

为什么重要

Retry、权限、Memory、Side Effect 与 Recovery 都在 Loop 中交汇，隐式循环会让失败难以限制和诊断。

心智模型

只有当拆解或比较替代方案能够显著改善下一步动作时才使用 Planning；否则优先保持更简单的 Direct Loop。

为什么重要

不必要的 Planning 会增加延迟、Token 成本和陈旧假设，却不一定改善结果。

心智模型

Autonomy 是 Permission Envelope，而不是性格特征；要明确系统能做什么、能走多远，以及何时必须交给人。

为什么重要

Agent 需要一定行动自由，但无边界自治会把模型不确定性直接转化为真实运营或财务后果。

心智模型

在有意义边界保存 Completed Step、Output、External Side Effect、Pending Decision、Version Metadata 与下一合法 Transition。

为什么重要

长任务必然遇到 Crash 与 Timeout，Recovery 应从已知 State 继续，而不是仅靠对话文本重新猜测执行进度。

心智模型

Cancellation 是 State Transition，不是“所有工作立刻消失”；要记录请求、传播取消、观察 Ack，并处理已经开始的 Effect。

为什么重要

没有明确语义时，用户可能以为任务已经停止，而外部 Operation 仍继续，甚至后续 Retry 又恢复了已放弃工作。

心智模型

在对话请求之外显式建模 Task Identity、Lifecycle State、Progress、Cancellation、Result Retrieval、Retry 与 Owner。

为什么重要

没有明确异步语义时，用户和 Agent 难以区分仍在运行与已经失败，也无法安全判断是否应该 Retry。

心智模型

围绕 Decision 与 Evidence 拆解，而不是按 Prompt 数量随意切分；每个阶段都应有存在理由和可检查的 Handoff。

为什么重要

合理拆解能局部化失败、在安全位置并行，并避免一个超大模型调用隐藏多种系统责任。

心智模型

遵循 Generate → Verify → Classify Failure → Revise/Stop；Verifier 要有独立标准和有限预算，而不是简单让同一模型“再试一次”。

为什么重要

只有失败信息真正改变下一步动作时迭代才会提升质量，否则无结构 Retry 可能无限重复同一错误。

心智模型

采用 Observe → Interpret → Act 循环；不要让旧 Plan 替代对实际操作目标状态的重新检查。

为什么重要

界面会变化、操作存在 Side Effect，陈旧状态会让原本正确的 Browser/Computer Use 计划变得不安全。

心智模型

通过 Fresh Observation 与 Stable Identifier 回答“这个动作到底会影响谁”，再验证 Intended Target 仍与当前可见状态一致。

为什么重要

Planning 与 Execution 之间界面会变化、元素会移动、State 会过期，因此正确 Plan 也可能在执行时变得危险。

心智模型

把 Sandbox 当作真实 Capability Boundary：Default Deny、按任务授权、隔离 Credential，并在跨入高风险 Resource 时要求更强 Approval。

为什么重要

如果 Runtime 已暴露无限 Host Capability，再严格的 Prompt 也无法可靠限制被攻击或犯错的 Agent。

心智模型

局部灵活决策适合 Loop；当 Dependency、Parallelism、Approval 或 Recovery Boundary 需要明确时使用 Graph。

为什么重要

所有任务都 Graph 化会增加 Overhead，而把强结构 Workflow 塞进开放 Loop 又会隐藏控制并使 Recovery 更困难。

心智模型

选择能够表达真实依赖的最简单 Topology，再评估 Coordination Cost、Isolation、Retry Scope 与 Join Verification。

为什么重要

更复杂的 Multi-Agent Graph 可能看起来先进，却比单一受控 Loop 更慢、更相关并且更难调试。

心智模型

Delegation 是有状态 Contract 而不是一条消息；保留 Task Identity、Expected Result、Dependency、Progress 以及谁负责 Verify/Integrate。

为什么重要

没有显式 State 时，Multi-Agent 容易丢失重复工作、陈旧 Assignment、Partial Result 与 Join 时的责任归属。

心智模型

Verifier 应获得完成检查所需的证据与验收标准，但不应继承 Producer 的全部隐含假设。

为什么重要

只有不同角色的失败不是高度相关时，增加 Agent 才可能真正提高可靠性。

心智模型

把 Coordination 当成必须由 Decomposition、Parallelism、Specialization 或 Independent Verification 收益来支付的成本，并与简单 Baseline 比较。

为什么重要

Multi-Agent 很容易增加大量消息与移动部件，却没有增加等价价值，最终反而更慢、更贵、更难可靠。

心智模型

在状态查询、Idempotency 记录或权威 System of Record 证明结果之前，把 Timeout 视为 Unknown Outcome。

为什么重要

对歧义超时盲目 Retry 可能重复付款、退款、发消息或执行其他不可逆操作。

心智模型

只 Retry 安全且可能短暂的错误，并设置有限次数、Backoff、Idempotency，同时确认原始 Operation 的真实 Outcome。

为什么重要

Incident 期间无控制 Retry 可能把一个小型依赖故障迅速放大为系统级 Outage 或重复财务动作。

心智模型

在不可逆操作之前先给 Intent 分配稳定身份，并让所有 Retry 都收敛到该身份已经记录的结果。

为什么重要

分布式系统中 Retry 无法完全避免，Idempotency 能阻止传输不确定性变成重复业务动作。

心智模型

失败后先确认实际 Commit 了什么，再根据 Side Effect 的可逆性与 Authority 选择 Resume、Compensate、Reconcile 或 Escalate。

为什么重要

分布式 Workflow 很少原子失败，因此把“报错”理解成“什么都没发生”会造成重复或损坏真实状态。

心智模型

用稳定 Identifier 保留因果执行历史，让操作者能从观察到的 Failure 反向定位负责步骤及其证据。

为什么重要

没有 Traceability 时调试会退化成猜测，Evaluation 也难以区分问题来自 Model、Retrieval、Tool 还是 Runtime。

心智模型

先从需要做出的 Decision 出发，再收集真正能够支持或否决该判断的 Test Case、Measurement、Trace 与 Verifier Output。

为什么重要

没有显式证据时，团队很容易把个别案例、模型自信或几个成功 Demo 误认为系统已经可靠。

心智模型

最终质量用 Outcome Metric 判断；当危险、浪费或脆弱路径也可能得到表面正确结果时，再加入 Trajectory Evidence。

为什么重要

两个 Agent Run 可能得到同样答案，但其中一个可能违规、浪费资源或走了不可恢复的路径。

心智模型

在发布前定义有意义的 Slice，并要求关键 Slice 各自满足 Threshold，而不是只接受更高的全局平均值。

为什么重要

AI 改动经常重新分配质量，因此总体 Metric 变好时，关键 Cohort 仍可能明显退化。

心智模型

任何分数都应同时查看样本量、离散程度、Confidence Interval 和 Slice 表现，而不是把单一平均值当成精确事实。

为什么重要

小样本或高噪声评测会轻易翻转看似的胜负，导致团队发布实际上只是随机波动的“提升”。

心智模型

把技术 Metric 转成具有 Threshold 与 Veto 的统一 Decision Surface；只有总成本与风险符合 Product Objective 的提升才有价值。

为什么重要

模型分数可能更高，却同时让产品更慢、更贵或更脆弱，因此最终 Release 仍可能是一笔坏交易。

心智模型

围绕诊断问题设计 Log、Trace、Metric 与 Model/Tool Evidence，使失败能够跨系统层被定位。

为什么重要

没有面向诊断的可观测性，团队只能看到质量下降或延迟升高，却无法确定应该修复哪个因果组件。

心智模型

沿可观察 Boundary 追踪 Failure，找到第一个 Evidence 偏离 Expected Behavior 的 Layer，再决定修复位置。

为什么重要

错误归因会导致用 Prompt 修 Data、用大模型修 Tool Bug，并投入高成本改动却保留真正 Root Cause。

心智模型

上线前先定义什么现象代表退化，再建立 Instrumentation，并让 Alert 连接到调查、Rollback 或流量控制动作。

为什么重要

Offline Evaluation 无法覆盖所有生产 Distribution Shift，因此 Release 是持续收集证据的开始，而不是验证结束。

心智模型

任何跨越边界的内容都先视为 Untrusted，直到接收层验证 Provenance、Authorization、结构与允许产生的影响。

为什么重要

Prompt Injection 与 Confused Deputy 问题往往源于不可信内容被错误继承了本不属于它的权限。

心智模型

区分 Data 与 Instruction、保留 Provenance、按 Policy 限制 Tool、验证 Requested Action，并把高后果边界放到模型之外执行。

为什么重要

仅靠 Prompt 无法稳定阻止恶意检索文本或用户内容尝试重定向拥有真实能力的 Agent。

心智模型

把 Guarantee 从说服性文本移到围绕 Tool、Data、Permission、State Transition 与 Side Effect 的 Executable Gate。

为什么重要

模型可能概率性误解或忽略指令，但生产系统仍需要对高后果行为提供确定性边界。

心智模型

记录足够让独立 Reviewer 重建 Decision 的最小证据，而不是依赖隐藏 Memory 或参与者事后回忆。

为什么重要

发生 Incident、争议或治理审查时，无法重建决策的系统也就无法可靠解释问题或持续改进。

心智模型

不要试图用 Prompt 解决所有问题；把每个要求放到真正拥有 Enforcement 权限和可观测性的那一层。

为什么重要

生产 AI 的很多失败并不是单个模型错误，而是责任在不同层之间泄漏造成的。

心智模型

使用分阶段 Exposure、显式 Success/Veto Signal，以及不依赖故障组件本身的已测试 Rollback 或 Fallback Path。

为什么重要

安全发布能限制 Blast Radius，并在模型或架构变化影响全部用户前给团队留下观察和学习空间。

心智模型

不要强迫所有 Evaluation 都变成 Pass/Fail；定义 Release Threshold 与 Veto，并为需要更多证据的不确定情况保留显式状态。

为什么重要

把缺失证据当作成功会制造高风险发布，把它自动当失败又可能阻碍学习；有时最真实的结论就是 Unknown。

心智模型

把 Queue Depth、Concurrency Limit、Admission Control、Retry 和 Cancellation 一起设计，让过载时系统能够减速或丢弃工作，而不是级联失效。

为什么重要

在长任务或 Agent 工作负载中，失控并发会把延迟尖峰放大成 Retry Storm、重复工作和资源耗尽。

心智模型

对需要可复现的部分进行 Pin，记录兼容假设，并把 Migration 当作行为变化来测试，而不是普通维护。

为什么重要

AI 组件变化很快，静默升级可能直接改变 Prompt、Tokenization、Tool Contract、延迟或评测结果。

心智模型

在模型 Context 之外维护显式 Canonical Notes 与 Review Checkpoint，让后续章节能够对照稳定决策进行检查。

为什么重要

长文漂移通常逐步发生，即使每个段落单独看都不错，跨章节的小矛盾也会持续削弱可信度。

心智模型

从 Claim 与 Evidence 构建 Outline，而不是从通用标题开始；每个 Section 都应说明为什么存在以及必须证明哪个 Source-backed Point。

为什么重要

从 Research Note 直接跳到 Drafting 容易造成重复、缺证据，并让章节结构跟随生成便利而不是论证逻辑。

心智模型

从 Evidence Set 出发写作，并保留 Claim → Source 连接，使来源变化时可以定位并更新或删除相关内容。

为什么重要

无证据的流畅文本一旦扩散到多个章节和论证中，后续验证成本会非常高。

心智模型

把 Voice 表达成可审查约束与示例，并据此检查生成文本，而不是依赖“更专业一点”这类模糊指令。

为什么重要

长内容与产品内容中的轻微风格漂移会逐步累积，因此稳定 Voice 会直接影响整体可信度。

心智模型

先抽取可验证 Claim，追踪到权威 Source，明确 Support Status，然后再基于证据进行 Revision。

为什么重要

让同一模型泛泛“检查自己的文章”容易保留原有错误假设，而 Claim-level Evidence 能打破这种耦合。

心智模型

先定义图片必须传达什么以及如何判断好坏，再描述装饰性细节或选择 Generation Model。

为什么重要

没有 Brief 时，迭代容易退化成主观改 Prompt，也很难区分是模型失败还是视觉目标本身不清晰。

心智模型

每次重要修改后都直接查看或听取真实 Modality；文字描述不能替代对最终图像或音频结果的检查。

为什么重要

很多视觉和音频缺陷在真实产物中很明显，却不会出现在 Prompt 或 Metadata 中，因此 Inspection 必须留在 Loop 内。

心智模型

在目标 Size 与 Channel 中直接 Review 最终 Rendered Asset，并使用显式 Criteria；Metadata 与 Prompt 只能描述 Intent，不能证明产物成功。

为什么重要

Generation Pipeline 即使产出技术合法文件，仍可能包含视觉错误、不可读文字、品牌不一致或 Accessibility 问题。

心智模型

把 Objective 写成可观察的 Capability Change，再让 Content、Practice 与 Assessment 对齐到同一个 Decision 或 Behavior。

为什么重要

没有清晰目标时，AI 课程可能看起来内容很多，却无法证明学习者行为或能力发生了真实变化。

心智模型

按照 Learner Dependency 而不是内容类别拆课程；每个 Unit 都应为后续某个具体能力或 Decision 提供准备。

为什么重要

如果高级内容出现在必要心智模型和 Practice 之前，再大的内容库也不能形成真正 Curriculum。

心智模型

把 Publishing 当作 Release：发布前检查完整性、媒体质量、版权、导航、版本以及后续维护责任。

为什么重要

即使课程内容很好，如果学习者无法导航、无法确认版本或得不到持续更新，知识产品仍会失败。

心智模型

把 Knowledge Base 当作需要持续维护且有 Owner/Freshness Policy 的产品，而不是一次性把文档上传到 Vector Store。

为什么重要

即使 Retrieval 很强，只要底层知识陈旧、重复、相互冲突或无人负责，整体质量仍会持续下降。

心智模型

把 Ingestion 当作带 Owner、Provenance、Freshness、去重和删除规则的编辑生命周期，而不是一次性上传任务。

为什么重要

如果 Corpus 不断积累陈旧、冲突或无人负责的材料，再好的 Retrieval 也无法长期保持质量。

心智模型

围绕会改变最终结论的 Claim 来拆解，并为每个子问题映射能够支持或推翻它所需的 Evidence。

为什么重要

如果不先拆问题，AI Research 容易收集大量“相关资料”，却无法证明最终结论真正依赖的具体 Claim。

心智模型

寻找失败模式不同的来源，并记录它们在哪些地方一致、冲突或仍未解决，而不是简单把多份资料平均处理。

为什么重要

如果多个 Citation 都复制同一个上游错误，数量并不能提高可信度；独立性才让交叉验证真正有意义。

心智模型

把 Claim 与 Source 视为 Many-to-many Structure，记录 Evidence Strength、Independence、Freshness 与 Disagreement，而不是每段随手贴一个 Citation。

为什么重要

Matrix 会在结论被包装成流畅文本之前暴露 Unsupported Claim 与相关性来源，降低后续纠错成本。

心智模型

先区分已支持的共识、冲突证据和开放缺口，再综合 Evidence Structure，最后才形成叙事性结论。

为什么重要

流畅摘要很容易隐藏真正应该改变决策或触发继续研究的关键分歧。

心智模型

把 Extraction 当作数据 Pipeline：保留 Source Coordinate、解析置信、Schema Validation 与可恢复错误，而不是自由摘要。

为什么重要

如果抽取后的数字、字段和 Citation 与原文失去联系，后续分析就难以验证和追责。

心智模型

先把杂乱材料转成明确的表格、字段、假设和中间结果，再让模型生成最终叙事。

为什么重要

如果原始证据和解释被压在一次黑盒生成里，最容易混入无法验证的推断。

心智模型

把 Pipeline 拆成 Source Data → Structured Data → Calculation → Interpretation，并用可复现证据验证每个 Transition。

为什么重要

再流畅的分析叙事也可能隐藏一个抽取或算术错误，而这个错误足以让最终业务结论完全失效。

心智模型

先独立研究 Problem，而不是围绕自己的 Product Idea 找支持：观察重复高成本行为、当前 Workaround、Decision Trigger 与用户已经在意的证据。

为什么重要

AI 降低了 Build Cost，也让团队更容易高效做出无人真正需要或不愿付费的 Solution。

心智模型

把内容当作有输入、节奏、渠道、转化信号和维护责任的 Pipeline，而不是一堆独立 AI 生成帖子。

为什么重要

对一人公司而言，可重复流程和反馈会产生复利，而一次性生成只会快速积累难以维护的素材。

心智模型

先让人保持 Decision Owner，再只自动化那些知识可靠、Tool 安全且后果有边界的 Support Action。

为什么重要

客服是高频真实环境，陈旧知识或错误动作会迅速影响真实客户、账户和资金，因此自动化边界尤其重要。