构建应用时 AI 思考方式的简单思维模型

“AI 思考”对应用构建者意味着什么

当人们说“AI 在思考”时，通常的含义是：它理解你的问题、进行推理，然后决定一个答案。

对现代基于文本的 AI（LLM）来说，更有用的思维模型更简单：模型在预测下一段应该出现的文本。

这听起来可能让人觉得平淡——直到你看到“下一段文本”能达到的范围。如果模型从训练中学到了足够多的模式，预测下一个词（然后下一个，再下一个）就能产生解释、计划、代码、摘要，甚至是你应用可以使用的结构化数据。

目标：为构建者而设的模型，而不是数学推导

你不需要掌握底层数学就能构建优秀的 AI 功能。你需要的是一种实用的方式来预判行为：

• 为什么相同的提示会产生不同答案
• 为什么答案听起来很自信却可能是错的
• 为什么小的提示变动会显著改变结果
• 何时应引入外部数据或工具，而不是“更努力地问”模型

本文就是那种模型：不是炒作，也不是深奥的技术论文——只是帮助你设计可靠产品体验的概念。

在应用中“思考”长什么样

从应用构建者的角度看，模型的“思考”就是它对你提供的输入（提示、用户消息、系统规则和任何检索到的内容）生成的文本。模型默认不会核实事实，不会浏览网络，也不会“知道”你的数据库内容，除非你把这些信息传进去。

据此设定期望：LLM 非常适合用于起草、转换、分类文本，以及生成类代码输出。但它们并非神奇的真理引擎。

我们将使用的组成部分

我们把思维模型拆成几部分：

• Tokens（它预测的文本片段）
• 上下文窗口（它一次能够“记住”的内容）
• 概率（为什么输出会变化）
• 工具与检索（如何将模型与真实动作和事实连接）
• 反馈与评估（如何让输出变得可靠）

有了这些概念，你可以设计提示、UI 和保障措施，让 AI 功能感觉一致且值得信赖。

核心循环：下一个 token 的预测

当人们说 AI 在“思考”时，很容易想象它像人一样推理。更有用的思维模型更简单：它在做极快的自动补全——一次一个小片段。

什么是 token？

一个 token 是模型处理的文本片段。有时是一个完整单词（“apple”），有时是词的一部分（“app” + “le”），有时是标点，或甚至是空白。具体的分片取决于模型的 tokenizer，但要点是：模型并不是以整洁的句子处理文本——它以 token 为单位。

预测下一个 token，然后重复

模型的核心循环是：

1. 读取你给它的 tokens（你的提示和之前的对话）。
2. 预测最可能的下一个 token。
3. 将该 token 附加到文本中。
4. 把变长后的文本当作输入，重复上述步骤。

就是这样。每一个段落、项目符号列表和“推理”链都是通过重复这个下一个 token 的预测多次构建出来的。

“思考”＝被引导的自动补全

由于模型在训练时见过海量文本，它学到了诸如解释通常如何展开、礼貌邮件的语气、如何描述一个 bug 修复等模式。当你提出问题时，它生成符合所学模式并匹配你提供上下文的答案。

这就是为什么它即便错了也能听起来自信和连贯：它在优化下一段最合适的文本——而不是核对现实。

代码也是 token

代码对模型并不特殊。JavaScript、SQL、JSON 和错误信息都是 token 的序列。模型能生成有用代码是因为它学到了常见的编码模式，而不是因为它像你的工程师那样“理解”你的应用。

回答从何而来：训练中学到的模式

当人们问“模型的答案从哪里来？”时，最有用的思维模型是：它从大量示例中学到了模式，现在把这些模式重新组合来预测下一个最合适的文本。

训练是模式学习，而非记忆

在训练期间，模型会被展示大量文本片段（书籍、文章、代码、文档、问答等）。它反复练习一个简单任务：在给定文本时预测下一个 token。当预测错误时，训练过程会微调模型内部参数，使其下次更有可能预测更好的下一个 token。

随着时间推移，这些微调积累起来，模型开始编码诸如：

• 概念通常如何被解释（“上下文窗口是……”）
• 哪些术语常一起出现（API、authentication、token）
• 回答的典型结构（定义、步骤、示例）
• 代码中的模式（SQL 查询通常如何构成）

为什么它可以泛化

因为它学的是统计规律——而不是一段固定脚本——它可以把不同模式以新的方式组合。如果它见过很多“解释概念”的例子，也见过很多“你的应用场景”的例子，它通常可以把两者融合成一个定制化的回答。

这就是为什么 LLM 能为利基产品写出合理的入职邮件，或将通用的 API 集成说明适配到特定技术栈。它不是检索某一段保存的文字；它是在生成一个新的序列，匹配它学到的模式。

它不是内置的精确答案数据库

即便某些训练数据包含特定事实（例如某个定价方案或内部政策），你也不应该指望模型能可靠地“查到”该事实。训练不像建立一个可查询的知识库，它更像是压缩：大量示例被浓缩到权重中，影响未来的预测。

这意味着模型可能会用基于相似上下文中通常出现的内容来“猜测”细节，并对此表现得很自信。

模式有用，但不保证正确

模式学习在生成流畅、相关文本方面很强，但流畅性不等于真实。模型可能会：

• 混淆相近概念
• 用“最可能”的猜测填补缺失的细节
• 提供过时或不适当的细节

对应用构建者来说关键是：LLM 的答案通常源自学到的模式，而非已验证的事实。如果正确性重要，你需要用自己的数据和检查来将输出落地（后文会讲）。

概率、随机性与答案为何会变化

当 LLM 生成回复时，它并不是从数据库中拉取单一“正确句子”。在每一步，它会预测一个可能的下一个 token 的范围，这些 token 各自有概率。

如果模型总是选择概率最高的下一个 token，答案会非常一致——但也可能重复且僵硬。大多数系统选择从概率分布中采样，这就引入了可控的随机性。

“创造性 vs 一致性”的调节项

两个常见设置会影响输出的多样性：

• Temperature：更高的 temperature 会把概率分散到更多选项（更多变化）；更低则集中在顶端（更一致）。
• Top‑p（nucleus sampling）：模型只考虑概率相加达到 p 的最小 token 集合（例如 0.9）。更低的 top‑p 会把集合缩小到更安全、更可预测的选择。

如果你在构建应用，这些调节项不是在谈“艺术上的创造”，而是在选择：

• 稳定、可重复的措辞（适合客服、政策、摘要）
• 更广的探索（适合头脑风暴、命名、提供替代方案）

语气自信不等于正确

因为模型优化的是看起来合理的文本，它可能会生成听起来确定的陈述——即便该陈述有误或缺少关键上下文。语气上的自信并不等于证据。这就是为什么当事实性任务重要时，通常需要进行 grounding（检索）或验证步骤。

一个简单示例：多种正确写法

向 LLM 提问：“写一个 JavaScript 函数来移除数组重复项。”你可能会得到下面任意一种，都是有效的：

// Option A: concise
const unique = (arr) => [...new Set(arr)];

// Option B: explicit
function unique(arr) {
  return arr.filter((x, i) => arr.indexOf(x) === i);
}

不同的采样选择会导致不同风格（简洁 vs 显式）、不同的权衡（速度、可读性），甚至不同的边界行为——而模型并不是在“改变主意”，只是从多个高概率延续中做出了选择。

上下文窗口：AI 的工作记忆

当人们说模型“记得”你的对话时，它实际上是有上下文：模型当前能“看到”的文本——你的最新消息、任何系统指令，以及仍然能装进窗口的早期聊天部分。

什么是上下文窗口

上下文窗口是模型一次能考虑的固定文本量限制。当对话足够长时，早期内容会落出窗口，模型就看不到它们了。

这就是你有时会看到的现象：

• 它忘记了你早先提到的要求（“使用友好语气”、“仅返回 JSON”）。
• 它与早先决策矛盾（变量名不同、假设改变）。
• 随着小误解累积，对话逐渐偏离主题。

没有摘要，长对话为何会偏离

如果你不断往线程里添加消息，你就在为有限空间竞争。重要约束会被近期的来回消息挤出去。没有摘要时，模型必须从可见内容中推断重要性——因此它可能自信地输出，但实际上忽略了关键细节。

实用的修复方法是定期总结：用简洁的段落重述目标、决策和约束，然后再继续。在应用中，这通常以自动的“会话摘要”注入提示实现。

提示技巧：把约束放在末尾附近

模型更倾向于遵循靠近它将要生成输出的指令。所以如果你有必须遵守的规则（格式、语气、边界情况），把它们放在提示末尾——就在“现在生成答案”之前。

如果你在构建应用，把这当作界面设计：决定哪些必须保留在上下文中（需求、用户偏好、架构），并确保它们始终被包含——通过裁剪聊天历史或添加精炼摘要来实现。关于如何结构化提示的更多内容，请参见 /blog/prompting-as-interface-design。

AI 为什么会出错：流畅文本 vs 现实

LLM 非常擅长生成听起来像胜任开发者会给出的答案的文本。但“听起来正确”并不等于“就是正确”。模型在预测可能的下一个 token，而不是把输出与代码库、依赖项或现实世界核对。

默认情况下它不会执行任何东西

如果模型建议一个修复、重构或新函数，它仍然只是文本。除非你显式把它连接到能做这些事情的工具（例如测试运行器、linter 或构建步骤），否则它不会实际运行你的应用、导入包、调用 API 或编译项目。

这是关键对比：

• 流畅文本："这看起来像一个有效的解决方案。"
• 通过执行验证："代码能编译、测试通过，行为符合预期。"

应用构建中的常见失败模式

当 AI 出错时，通常以可预测的方式失败：

• 虚构的 API 或参数（杜撰的库方法、错误的函数签名）
• 错误的边界情况（例如空状态、时区、null 处理、分页边界）
• 缺失的导入或设置（忘记依赖、错误文件路径、缺失环境变量）
• 微妙的逻辑错误（越界、一致性命名错误、错误的布尔条件）
• 过时的假设（框架行为变化、已弃用配置）

这些错误可能难以察觉，因为周围的解释通常很连贯。

经验法则：验证后再信任

把 AI 输出当作没在本地运行项目的队友给你的快速草稿。在你：

• 运行单元/集成测试，
• 进行 lint/格式化/构建，
• 并用真实输入验证结果后，才显著提升信任度。

如果测试未通过，假定模型的答案只是起点——不是最终解决方案。

工具把文字变成动作（并减少猜测）

语言模型擅长提出“可能可行”的方案——但单靠它仍然只是文本。工具能让 AI 支撑的应用把这些建议变成已验证的动作：运行代码、查询数据库、检索文档或调用外部 API。

实践中的“工具”是什么

在应用构建工作流中，工具通常表现为：

• 运行代码（例如执行 Python 片段、编译项目、运行迁移）
• 检索文档（你的内部知识库、产品手册、API 参考）
• 调用 API（支付、邮件、CRM、功能开关、分析）
• 读/写文件（编辑配置、生成测试文件）

重要的转变是：模型不再假装知道结果——它可以核验。

循环：提出 → 检查 → 调整

一个有用的思维模型是：

1. 模型提出 一个动作（“要找出不活跃用户，运行这个 SQL 查询……”）
2. 工具执行（查询运行、测试套件执行、文档被检索）
3. 模型根据真实输出进行调整（错误信息、查询结果、失败的测试）

这就是如何减少“猜测”。如果 linter 报告未使用的导入，模型会更新代码。如果单元测试失败，模型会迭代直至通过（或解释无法通过的原因）。

映射到真实应用的示例

• 数据库查询： 模型起草 SQL，DB 工具返回行数或错误，模型据此安全地修正查询。
• Lint/格式化： 模型编辑代码，然后运行 eslint/ruff/prettier 来确认风格并捕获问题。
• 单元测试： 模型写函数和测试，运行测试套件，然后修复由失败暴露的边界情况。

权限：把工具当作具有生产访问的资源对待

工具很强大且可能危险。遵循最小权限原则：

• 默认给予 AI 只读 访问（尤其是数据库）
• 将 API 密钥限定到最小权限和必要环境
• 记录工具调用，并对破坏性操作（删除、退款、发送邮件）要求确认

工具不会让模型“更聪明”，但它们让你的应用 AI 更加“落地”——因为模型可以核验，而不只是叙述。

检索（RAG）：把正确事实交给模型

语言模型擅长在它“能看到”的文本上写作、总结并推理。但它不会自动知道你的最新产品改动、公司的政策或某个特定客户的账户细节。检索增强生成（RAG）是一个简单的修复：先获取最相关的事实，再让模型基于这些事实写作。

用通俗话说的 RAG

把 RAG 想像成“开卷式 AI”。与其让模型从记忆中回答，不如你的应用快速从可信来源检索几段相关片段并把它们加入提示。模型然后基于这些提供的材料生成答案。

什么时候应该使用它

当正确性依赖于模型外的信息时，RAG 常作为默认方案：

• 你的产品文档、发布说明或帮助中心文章
• 内部政策（退款、安全规则、合规语言）
• 用户特定数据（订单、工单、账户设置）
• 内容库较大，检索比把全部文本塞入提示更高效

如果你应用的价值在于“为我们的业务给出正确答案”，RAG 通常比指望模型去猜要可靠得多。

基本流程

1. 检索： 把用户问题转成检索查询，从内容存储（文档、数据库、向量索引）获取最相关的片段。
2. 片段/引用： 在模型输入中包含这些片段，通常带上标题、时间戳或标识以便你能展示“此处来自何处”。
3. 生成： 让模型在仅使用提供上下文的前提下回答，并在上下文不足时说明。

最大的局限

RAG 的效果取决于检索到什么。如果搜索步骤返回过时、不相关或不完整的片段，模型可能会自信地给出错误答案——现在这些答案看起来“有来源依据”。在实践中，提高检索质量（分块、元数据、新鲜度和排序）往往比调整提示更能提升准确率。

Agent：当模型驱动多步骤工作流时

“Agent”只是一个循环运行的 LLM：它制定计划、执行一步、看发生了什么，然后决定下一步做什么。它不是只回答一次，而是迭代直至达到目标。

最简单的 agent 周期

有用的思维模型是：

计划 → 执行 → 检查 → 修正

• 计划： 将目标拆成若干步骤（“查找数据、总结、草拟邮件”）。
• 执行： 执行一步，通常通过调用工具（检索、数据库查询、日历 API）或生成草稿。
• 检查： 将结果与目标比较（“我真的找到了客户的最新发票吗？”）。
• 修正： 调整计划并执行下一步。

这个循环把单次提示转变成一个小型工作流。这也解释了为何 agent 会感觉更“独立”——模型不仅生成文本，它还在选择和排序动作。

停止条件与防护措施

Agent 需要明确的停止规则。常见的终止条件包括：

• 达到成功标准（例如“邮件草稿包含订单号和交付日期”）。
• 达到最大步骤数。
• 达到截止时间或 token 预算。
• 必要的工具调用重复失败。

防护措施是让循环保持安全可预测的约束：允许的工具、许可的数据源、审批步骤（人工介入）、以及输出格式。

避免无限循环

因为 agent 总能提出“再做一步”，你必须为失败模式做好设计。没有预算、超时和步骤限制，agent 可能陷入重复动作（“用稍有不同的查询再试一次”）或产生高成本。

实用默认：限制迭代次数、记录每一步动作、要求验证工具结果，并在失败时优雅地返回部分答案加上尝试记录。这通常比让 agent 无限循环更符合产品设计。

像 Koder.ai 这类平台的定位

如果你用类似 Koder.ai 的 vibe-coding 平台，这个“agent + 工具”的思维模型尤其实用。你不仅在聊天寻求建议——而是在使用一种工作流，助手可以帮助计划功能、生成 React/Go/PostgreSQL 或 Flutter 组件，并通过检查点（例如快照与回滚）迭代，让你在快速前进的同时不丢失对变更的控制。

将提示视为界面设计

当你把 LLM 放到应用功能的后面时，提示不再是“只是文本”。它是产品与模型之间的接口契约：模型要做什么、允许使用什么、以及必须如何回应以便你的代码可靠消费输出。

一个有益的心态是把提示当作表单来设计。好的表单减少歧义、约束选择并让下一步动作变得明显。好的提示也一样。

实用的提示清单

在你上线提示之前，确保它清晰表明：

• 目标： 成功的样子（一句话）。
• 输入： 模型接收哪些数据（以及应忽略哪些）。
• 约束： 语气、安全规则、长度限制、必须/不得做的事。
• 输出格式： 答案应如何精确结构化以便你的应用解析。

提供示例以锚定行为

模型会遵循模式。提供一个输入与输出的示例（尤其当任务有边界情况时）是教会模型你想要的模式的强力方式。

即便只有一个示例，也能减少来回并防止模型发明你的 UI 无法显示的格式。

优先结构化输出而非散文

如果另一个系统要读取响应，就要求结构化。请求 JSON、表格或严格的项目列表。

You are a helpful assistant.

Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
  "result": "string",
  "confidence": "low|medium|high",
  "warnings": ["string"],
  "next_steps": ["string"]
}

这会把“提示”转变为可预测的接口设计。

当需要时要求澄清问题

加入一条明确规则：“如果缺少关键需求，请在回答前提出澄清问题。”

这一行可以防止自信但错误的输出——因为模型被允许（且应当）暂停并要求缺失字段，而不是去猜。

让提示匹配你的构建工作流

在实践中，最可靠的提示是与产品的构建和部署方式相匹配。例如，如果你的平台支持先规划、再生成改动、再导出源码或部署，你可以在提示契约中镜像这一步骤（plan → produce diff/steps → confirm → apply）。Koder.ai 的“planning mode” 是如何将流程分为明确阶段以减少漂移并帮助团队在发布前审查变更的好例子。

如何建立信任：测试、评估与在应用中安全使用

信任并不来源于模型“听起来自信”。它来自把 AI 输出当作产品中的其他依赖项：进行衡量、监控并加以约束。

评估重要内容（而非一切）

从少量真实任务开始，这些任务是你的应用必须做好的一部分。然后把它们变成可复现的检查：

• Golden prompts： 精心挑选的提示列表 + 期望特征（或精确答案，若可能）。每次发布前运行。
• 类单元测试的检查： 如果模型输出结构化数据（JSON、字段、决策），对形状、必需键、取值范围和允许值进行断言。
• 抽样检查： 每周对最近对话做轻量审查，捕捉测试集漏掉的新失效模式。

随时间测量可靠性

不要问“好不好？”，而要跟踪“通过率是多少？”有用的指标包括：

• 在 golden prompts 上的通过率（总体和按类别划分）。
• 与上周或上个模型版本比较的回归检查，以便注意静默的行为变化。
• 工具成功率（例如返回可用结果的工具调用比例）。

记录足够信息以便复现问题

出问题时，你应该能重放它。记录（并进行适当脱敏）：

• 提示模板和最终渲染的提示。
• 模型名/版本、temperature 以及任何系统指令。
• 工具调用与工具结果（输入、输出、错误、延迟）。

这使得调试可行，并帮助你回答“是模型变了，还是我们的数据/工具变了？”

生产应用的安全基础

一些默认做法可以防止常见事故：

• 绝不将秘密（API 密钥、密码、私有 token）放入提示或聊天历史。
• 在向用户展示前过滤或屏蔽敏感输出（个人数据、医疗/法律声明、违规内容）。
• 添加明确的回退路径：当置信度低时，提出澄清问题、展示来源或交由人工处理。