为构建应用而设计的清晰思维模型:解释模型如何生成代码与决策——tokens、上下文、工具与测试——并给出限制与实用提示。

当人们说“AI 在思考”时,通常的含义是:它理解你的问题、进行推理,然后决定一个答案。
对现代基于文本的 AI(LLM)来说,更有用的思维模型更简单:模型在预测下一段应该出现的文本。
这听起来可能让人觉得平淡——直到你看到“下一段文本”能达到的范围。如果模型从训练中学到了足够多的模式,预测下一个词(然后下一个,再下一个)就能产生解释、计划、代码、摘要,甚至是你应用可以使用的结构化数据。
你不需要掌握底层数学就能构建优秀的 AI 功能。你需要的是一种实用的方式来预判行为:
本文就是那种模型:不是炒作,也不是深奥的技术论文——只是帮助你设计可靠产品体验的概念。
从应用构建者的角度看,模型的“思考”就是它对你提供的输入(提示、用户消息、系统规则和任何检索到的内容)生成的文本。模型默认不会核实事实,不会浏览网络,也不会“知道”你的数据库内容,除非你把这些信息传进去。
据此设定期望:LLM 非常适合用于起草、转换、分类文本,以及生成类代码输出。但它们并非神奇的真理引擎。
我们把思维模型拆成几部分:
有了这些概念,你可以设计提示、UI 和保障措施,让 AI 功能感觉一致且值得信赖。
当人们说 AI 在“思考”时,很容易想象它像人一样推理。更有用的思维模型更简单:它在做极快的自动补全——一次一个小片段。
一个 token 是模型处理的文本片段。有时是一个完整单词(“apple”),有时是词的一部分(“app” + “le”),有时是标点,或甚至是空白。具体的分片取决于模型的 tokenizer,但要点是:模型并不是以整洁的句子处理文本——它以 token 为单位。
模型的核心循环是:
就是这样。每一个段落、项目符号列表和“推理”链都是通过重复这个下一个 token 的预测多次构建出来的。
由于模型在训练时见过海量文本,它学到了诸如解释通常如何展开、礼貌邮件的语气、如何描述一个 bug 修复等模式。当你提出问题时,它生成符合所学模式并匹配你提供上下文的答案。
这就是为什么它即便错了也能听起来自信和连贯:它在优化下一段最合适的文本——而不是核对现实。
代码对模型并不特殊。JavaScript、SQL、JSON 和错误信息都是 token 的序列。模型能生成有用代码是因为它学到了常见的编码模式,而不是因为它像你的工程师那样“理解”你的应用。
当人们问“模型的答案从哪里来?”时,最有用的思维模型是:它从大量示例中学到了模式,现在把这些模式重新组合来预测下一个最合适的文本。
在训练期间,模型会被展示大量文本片段(书籍、文章、代码、文档、问答等)。它反复练习一个简单任务:在给定文本时预测下一个 token。当预测错误时,训练过程会微调模型内部参数,使其下次更有可能预测更好的下一个 token。
随着时间推移,这些微调积累起来,模型开始编码诸如:
因为它学的是统计规律——而不是一段固定脚本——它可以把不同模式以新的方式组合。如果它见过很多“解释概念”的例子,也见过很多“你的应用场景”的例子,它通常可以把两者融合成一个定制化的回答。
这就是为什么 LLM 能为利基产品写出合理的入职邮件,或将通用的 API 集成说明适配到特定技术栈。它不是检索某一段保存的文字;它是在生成一个新的序列,匹配它学到的模式。
即便某些训练数据包含特定事实(例如某个定价方案或内部政策),你也不应该指望模型能可靠地“查到”该事实。训练不像建立一个可查询的知识库,它更像是压缩:大量示例被浓缩到权重中,影响未来的预测。
这意味着模型可能会用基于相似上下文中通常出现的内容来“猜测”细节,并对此表现得很自信。
模式学习在生成流畅、相关文本方面很强,但流畅性不等于真实。模型可能会:
对应用构建者来说关键是:LLM 的答案通常源自学到的模式,而非已验证的事实。如果正确性重要,你需要用自己的数据和检查来将输出落地(后文会讲)。
当 LLM 生成回复时,它并不是从数据库中拉取单一“正确句子”。在每一步,它会预测一个可能的下一个 token 的范围,这些 token 各自有概率。
如果模型总是选择概率最高的下一个 token,答案会非常一致——但也可能重复且僵硬。大多数系统选择从概率分布中采样,这就引入了可控的随机性。
两个常见设置会影响输出的多样性:
如果你在构建应用,这些调节项不是在谈“艺术上的创造”,而是在选择:
因为模型优化的是看起来合理的文本,它可能会生成听起来确定的陈述——即便该陈述有误或缺少关键上下文。语气上的自信并不等于证据。这就是为什么当事实性任务重要时,通常需要进行 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 显式)、不同的权衡(速度、可读性),甚至不同的边界行为——而模型并不是在“改变主意”,只是从多个高概率延续中做出了选择。
当人们说模型“记得”你的对话时,它实际上是有上下文:模型当前能“看到”的文本——你的最新消息、任何系统指令,以及仍然能装进窗口的早期聊天部分。
上下文窗口是模型一次能考虑的固定文本量限制。当对话足够长时,早期内容会落出窗口,模型就看不到它们了。
这就是你有时会看到的现象:
如果你不断往线程里添加消息,你就在为有限空间竞争。重要约束会被近期的来回消息挤出去。没有摘要时,模型必须从可见内容中推断重要性——因此它可能自信地输出,但实际上忽略了关键细节。
实用的修复方法是定期总结:用简洁的段落重述目标、决策和约束,然后再继续。在应用中,这通常以自动的“会话摘要”注入提示实现。
模型更倾向于遵循靠近它将要生成输出的指令。所以如果你有必须遵守的规则(格式、语气、边界情况),把它们放在提示末尾——就在“现在生成答案”之前。
如果你在构建应用,把这当作界面设计:决定哪些必须保留在上下文中(需求、用户偏好、架构),并确保它们始终被包含——通过裁剪聊天历史或添加精炼摘要来实现。关于如何结构化提示的更多内容,请参见 /blog/prompting-as-interface-design。
LLM 非常擅长生成听起来像胜任开发者会给出的答案的文本。但“听起来正确”并不等于“就是正确”。模型在预测可能的下一个 token,而不是把输出与代码库、依赖项或现实世界核对。
如果模型建议一个修复、重构或新函数,它仍然只是文本。除非你显式把它连接到能做这些事情的工具(例如测试运行器、linter 或构建步骤),否则它不会实际运行你的应用、导入包、调用 API 或编译项目。
这是关键对比:
当 AI 出错时,通常以可预测的方式失败:
这些错误可能难以察觉,因为周围的解释通常很连贯。
把 AI 输出当作没在本地运行项目的队友给你的快速草稿。在你:
如果测试未通过,假定模型的答案只是起点——不是最终解决方案。
语言模型擅长提出“可能可行”的方案——但单靠它仍然只是文本。工具能让 AI 支撑的应用把这些建议变成已验证的动作:运行代码、查询数据库、检索文档或调用外部 API。
在应用构建工作流中,工具通常表现为:
重要的转变是:模型不再假装知道结果——它可以核验。
一个有用的思维模型是:
这就是如何减少“猜测”。如果 linter 报告未使用的导入,模型会更新代码。如果单元测试失败,模型会迭代直至通过(或解释无法通过的原因)。
eslint/ruff/prettier 来确认风格并捕获问题。工具很强大且可能危险。遵循最小权限原则:
工具不会让模型“更聪明”,但它们让你的应用 AI 更加“落地”——因为模型可以核验,而不只是叙述。
语言模型擅长在它“能看到”的文本上写作、总结并推理。但它不会自动知道你的最新产品改动、公司的政策或某个特定客户的账户细节。检索增强生成(RAG)是一个简单的修复:先获取最相关的事实,再让模型基于这些事实写作。
把 RAG 想像成“开卷式 AI”。与其让模型从记忆中回答,不如你的应用快速从可信来源检索几段相关片段并把它们加入提示。模型然后基于这些提供的材料生成答案。
当正确性依赖于模型外的信息时,RAG 常作为默认方案:
如果你应用的价值在于“为我们的业务给出正确答案”,RAG 通常比指望模型去猜要可靠得多。
RAG 的效果取决于检索到什么。如果搜索步骤返回过时、不相关或不完整的片段,模型可能会自信地给出错误答案——现在这些答案看起来“有来源依据”。在实践中,提高检索质量(分块、元数据、新鲜度和排序)往往比调整提示更能提升准确率。
“Agent”只是一个循环运行的 LLM:它制定计划、执行一步、看发生了什么,然后决定下一步做什么。它不是只回答一次,而是迭代直至达到目标。
有用的思维模型是:
计划 → 执行 → 检查 → 修正
这个循环把单次提示转变成一个小型工作流。这也解释了为何 agent 会感觉更“独立”——模型不仅生成文本,它还在选择和排序动作。
Agent 需要明确的停止规则。常见的终止条件包括:
防护措施是让循环保持安全可预测的约束:允许的工具、许可的数据源、审批步骤(人工介入)、以及输出格式。
因为 agent 总能提出“再做一步”,你必须为失败模式做好设计。没有预算、超时和步骤限制,agent 可能陷入重复动作(“用稍有不同的查询再试一次”)或产生高成本。
实用默认:限制迭代次数、记录每一步动作、要求验证工具结果,并在失败时优雅地返回部分答案加上尝试记录。这通常比让 agent 无限循环更符合产品设计。
如果你用类似 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 输出当作产品中的其他依赖项:进行衡量、监控并加以约束。
从少量真实任务开始,这些任务是你的应用必须做好的一部分。然后把它们变成可复现的检查:
不要问“好不好?”,而要跟踪“通过率是多少?”有用的指标包括:
出问题时,你应该能重放它。记录(并进行适当脱敏):
这使得调试可行,并帮助你回答“是模型变了,还是我们的数据/工具变了?”
一些默认做法可以防止常见事故:
它通常意味着模型可以生成连贯、有目标导向的文本,看起来像是在理解和推理。实际上,LLM 在做的是下一个 token 的预测:在给定你的提示、指令和任何提供的上下文后,它生成最有可能的续写文本。
对应用构建者来说,有用的结论是“思考”就是可以被塑造和约束的输出行为——不是内部保证的真理。
token 是模型处理和生成的文本单位(可能是完整单词、词的一部分、标点或空白)。因为模型以 token 为单位工作,成本、限制和截断都是以 token 计量的。
实际影响:
因为生成是概率性的。在每一步,模型会为多个可能的下一个 token 分配概率,大多数系统并非总是选择概率最高的那个,而是从分布中采样。
要让输出更可复现:
LLM 优化的是生成“看起来合理”的文本,而不是验证事实。模型能够用自信的措辞输出内容,因为自信的语气在训练数据中很常见,即使底层说法只是猜测。
在产品设计中,把流畅性看作“写得好”,而不是“正确”,当正确性重要时要增加校验(检索、工具、测试、人工审批)。
上下文窗口是模型一次能考虑的最大文本量(系统指令、会话历史、检索到的片段等)。当对话过长时,早期的信息会超出窗口,模型就看不到它们了。
缓解措施:
默认情况下模型不会自动知道你的数据库、代码库或最新产品变更。它只能访问你放入提示里的内容以及你显式连接的工具。
如果答案依赖内部或最新事实,应该通过检索(RAG)或工具调用把它们传入,而不是“更努力地问模型”。
当你需要“已验证的结果”或真实操作时,就用工具而不是仅依赖模型文本。常见例子:
一个好模式是 propose → check → adjust,模型根据工具输出迭代。
RAG(检索增强生成)即“开卷式 AI”:你的应用从可信来源(文档、工单、策略)检索相关片段,并把它们加入提示,让模型基于这些事实来回答。
当下列情况成立时采用 RAG:
主要失败模式是检索质量差——改进搜索、分块和新鲜度通常比微调提示更能提升准确性。
Agent 是在循环中运行的 LLM:它制定计划、执行操作、检查结果并修正,通常会使用工具。它适用于“查找信息 → 草拟 → 验证 → 发送”这样的工作流。
保持 agent 可控的方法:
把提示当作接口契约:定义目标、输入、约束和输出格式,让你的应用能可靠消费结果。
实用的可信度构建方法: