凭感觉编程入门：成为100倍工程师的15个概念
- wasimships
- 发布于 2小时前
- 阅读 30
这篇文章详细介绍了成为高效AI工程师所需的15个核心概念和实践技巧，涵盖了从提示词工程（如提示链、上下文窗口、系统提示词）到模型输出管理（如RAG、温度、幻觉、Token限制），再到高级应用（如智能体循环、嵌入、函数调用、评估和防护）等关键领域，旨在帮助开发者摆脱“凭感觉”编程，系统性地构建和调试AI产品。
Vibe Coding 101：成为 100X Engineer 的 15 个概念
大多数 vibe coders 只是... prompt and pray。
没有系统。没有 mental model。只有感觉和希望。
这种做法有效，直到它失效。当它失效时，他们却不知道原因。
我为创业者发布了超过 50 个 AI 驱动产品，我一直看到同样的缺失。不是在代码中。而是在理解上。
这里有 15 个真正重要的概念。学会这些，你就不再需要猜测。
- Prompt chaining
大任务会崩溃。把它们链起来。
一个 prompt 做一份工作。它的输出成为下一个 prompt 的输入。把它想象成一条工厂生产线，而不是一把瑞士军刀。
甚至在打开 IDE 之前，先在纸上画出步骤。步骤 1 输出 X。步骤 2 接收 X 并执行 Y。就是这样。
人们犯的错误是：一个巨大的 mega-prompt 试图 "做一切"。它会失败，你却不知道问题出在哪里。
- Context window
模型看不到你的整个项目。它只能看到 Context window 中能容纳的部分。
Context window 之外的一切都是不可见的。它不会 "记住" 你 50 条消息之前的架构。那些都消失了。
保持 system prompts 简洁。总结。只传递下一步实际需要的内容。
- System prompts
这是你在任何对话开始前设定规则的地方。角色、语气、约束、格式。
把所有这些都放在这里。然后 user message 纯粹用于任务。
人们出错的地方：他们把关键指令倾倒在第一个 user message 中。然后他们在不重置的情况下，在会话中途改变行为。一切都偏离了。
- RAG
你的模型只知道它被训练过的内容。RAG 解决了这个问题。
你存储自己的文档，将其分块，然后在查询时提取相关部分并将其提供给模型。现在它用你的实际数据回答，而不是猜测。
人们走的捷径是：在 "每次请求" 中都喂给模型整个语料库。这会耗尽你的 context 并花费你的钱。正确分块，选择性检索。
- Temperature
低 Temperature = 可预测。高 Temperature = 有创造性。
代码和 SQL？保持低 Temperature。头脑风暴文案？调高它。
一个简单的概念，但我看到多少次有人在数据提取任务上使用高 Temperature，然后疑惑为什么输出会 Hallucination ID... 只要设置正确即可。
- Hallucination
模型会 "完全自信地" 说出错误的事情。
这不是一个需要你报告的 bug。它是 "系统的固有属性"。将每一个输出都视为一个 "聪明的实习生" 偶尔会编造东西的草稿。
验证事实。运行代码。为关键路径添加 evals。不验证 = 最终在客户面前出糗。
- Token limits
Tokens 是你的预算。输入 + 输出共享它。每个 token 都需要时间和金钱。
修剪你的历史记录。缩短 system prompts。停止粘贴整个文件。
这听起来很无聊，直到你的成本比预期高出 10 倍，并且你的响应时间 "严重损害用户体验"。
- Few-shot prompting
在要求模型真正执行任务之前，向它展示什么才是好的。
在 prompt 中提供两到三个示例，与你想要的精确格式匹配。不是模糊的示例。不是一个 "有点相似" 的示例。而是精确匹配你的边缘情况。
这可能是大多数 vibe coders 忽略的最简单的质量提升。
- Agent loops
模型计划、执行、查看结果，然后决定下一步做什么。每个循环不需要新的 prompt。
这就是你构建自主工作流的方式。但你需要 guardrails：步骤限制、错误处理、破坏性操作前的确认。
没有限制 + 没有错误处理 = 一个永远运行并破坏你意想不到事物的 agent。
- Embeddings
关键词查找关键词。Embeddings 查找含义。
你将文档转换为 vectors，然后通过相似性进行比较。当有人提出问题时，你通过含义而不是关键词匹配来检索最相关的 chunks。
所有不错的 RAG 系统的基础。如果你仍然对 "语义问题" 进行关键词搜索，你就会损失质量。
- Chunking
长文档无法容纳。你将它们分成足够小的片段以进行检索和使用。
但是糟糕的 chunking 几乎和不 chunking 一样糟糕。chunks 太大会失去意义。chunks 太小会失去 context。在 "句子中间" 分割会失去连贯性。
每个 chunk 使用约 500 个 tokens，并带有 overlap。正是这种 overlap 才能在边界之间保留含义。
- Function calling
模型不是返回文本，而是返回一个结构化的指令：“调用此函数，并带上这些参数。”
然后你的代码实际运行它。
这就是你将 AI 连接到现实世界中实际行动的方式。但在执行之前验证所有内容。绝不允许模型调用一个未经验证、未经净化的输入的函数。
- Evals
你的 AI 的测试。它是否如你所想地工作？
构建一小组带有预期输出的输入。每次更改 prompt 或切换模型时都运行它们。
大多数人盲目发布 prompt 更改，只有当客户向他们发送消息时才发现出了问题。运行 evals。这就像 unit tests，但用于你的 AI 层。
- Guardrails
在生产环境中，system prompt 不足以保护你。
你需要输出验证。Schema checks。Blocklists。对可以调用的工具的硬性限制。
对于任何面向客户的产品：如果你在输出到达用户之前没有验证它，你就是在赌博。
- Streaming outputs
不是等待 "完整响应"，而是在生成时发送 chunks。
极大改善了感知性能。用户会看到一些正在发生的事情，而不是长达 8 秒的空白屏幕。
问题是：小心处理 "部分 JSON"。处理连接断开。不要假设第一个 chunk 是一个 "完整或有效的响应"。
这就是完整的列表。
15 个概念。不是理论。不是学术 AI 的东西。
这是我发布的所有产品背后的实际 mental model。
大多数 vibe coders 盲目 prompt，并疑惑为什么事情会以意想不到的方式崩溃。
学习这些，你就会停止偶然调试，开始通过理解来调试。
那些更聪明地发布产品的 coders "并非更有天赋"。他们只是知道 "幕后" 实际发生了什么。
- 原文链接： x.com/wasimships/status/...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
