AI is code – and can't be prompted into being smarter

背景

在当前的 AI 技术叙事中，存在一种普遍的误解，即认为大型语言模型（LLM）可以通过简单的“提示工程”（Prompt Engineering）无限提升其智能水平。这种观点将 AI 视为一种可以通过自然语言指令直接“召唤”出更高阶能力的黑盒。

然而，Hacker News 上的一篇热门讨论文章《AI is code – and can't be prompted into being smarter》（AI 即代码——无法通过提示使其变得更聪明）对此提出了尖锐的批评。文章指出，尽管 AI 模型在处理自然语言时表现得像是有意识的实体，但其本质仍然是代码和概率统计的产物。文章通过从 Java 测试用例到沙丘宇宙中“沙虫”（Shai-Hulud）的比喻，揭示了当前 AI 代理（AI Agents）在缺乏严格约束和代码级控制时，会像吞噬一切一样盲目地处理输入，从而引发安全、可靠性和幻觉问题。

核心内容

这篇文章的核心论点在于重新定义人们对 AI 本质的认知：AI 不是魔法，而是代码。

1. “提示”无法替代“代码”的逻辑约束

许多用户和开发者倾向于认为，只要编写出足够好的 Prompt（提示词），就能让模型表现出更高的智能、更强的逻辑推理能力或更低的错误率。文章反驳了这一观点，指出 Prompt 只是接口，而模型内部运行的依然是确定性的代码逻辑和基于训练数据的概率预测。

• 代码的本质：AI 模型的行为由其架构、权重和训练数据决定，这些是固定的“代码”部分。
• 提示的局限：Prompt 只能引导模型在已有的能力范围内进行输出，无法从根本上改变模型的推理能力或修复其底层逻辑缺陷。试图通过自然语言指令来“修补”模型的根本性缺陷（如幻觉、逻辑漏洞）是徒劳的。

2. AI 代理的不可控性：像 Shai-Hulud 一样吞噬一切

文章引用了弗兰克·赫伯特《沙丘》系列中的生物“Shai-Hulud”（沙虫）作为比喻。在故事中，沙虫对任何进入其领地的物体都会本能地吞噬。

• 现状：当前的 AI 代理（AI Agents）在处理任务时，往往缺乏这种“边界感”和“过滤机制”。它们被设计为尽可能响应用户指令，但这导致它们会“吞下”任何喂给它们的输入，无论这些输入是否安全、准确或符合逻辑。
• 后果：这种无差别的处理能力导致了严重的后果，包括数据泄露、错误执行指令以及生成有害内容。正如文章标题下方的副标题所言：“From Java tests to Shai-Hulud, bots keep proving they'll swallow anything you feed them”（从 Java 测试到沙丘沙虫，机器人不断证明它们会吞下你喂给它们的任何东西）。

3. 对当前 AI 开发范式的批判

文章隐含了对当前过度依赖“Prompt 工程”而非“系统工程设计”的批判。

• 过度依赖自然语言：许多应用将复杂的业务逻辑完全寄托在 LLM 的自然语言理解上，忽视了代码层面的验证、约束和错误处理。
• 缺乏确定性：与传统的 Java 或 Python 代码不同，AI 模型的输出具有随机性和不确定性。仅靠 Prompt 无法提供传统编程中的确定性保证。

4. 结合 Hacker News 的其他热点

虽然主文聚焦于 AI 的本质，但 Hacker News 列表中的其他热门话题也佐证了这一观点的紧迫性：

• API 攻击与 AI：《From Prompt to Exploit: How LLMs Are Changing API Attacks》指出，现代应用基于 API，且往往权限过大，AI 辅助的攻击者可以利用这一点。这说明 AI 不仅不能自动变聪明，反而可能被用于放大现有的安全漏洞。
• AI 幻觉与信任危机：KPMG 的 AI 报告被指出存在大量幻觉（仅 5/45 引用匹配），这进一步证明了仅靠 AI 生成的内容不可信，需要严格的代码级验证。
• AI 代理的安全问题：《NanoClaw now armed with JFrog for safer packages》提到 AI 代理不可信，因此不应赋予其危险权限。这与“AI 是代码，需要像代码一样被严格管理”的观点一致。

关键要点

• AI 本质是代码：AI 模型的行为由其底层架构、训练数据和权重决定，而非仅仅由用户输入的 Prompt 决定。Prompt 只是输入接口，不能改变模型的根本能力。
• 提示工程有极限：无法通过优化 Prompt 来从根本上提升模型的智能水平或修复其逻辑缺陷。试图用自然语言指令来“修补”模型是无效的。
• AI 代理的盲目性：当前的 AI 代理缺乏边界感和过滤机制，会无差别地处理所有输入，类似于“沙丘”中的沙虫，这导致了安全性和可靠性的重大风险。
• 需要代码级的约束：为了确保 AI 的安全性和可靠性，必须引入代码级的验证、约束和错误处理机制，而不是仅仅依赖自然语言指令。
• 安全与信任危机：AI 生成的内容（如报告、代码）存在幻觉和错误，且 AI 可能被用于攻击 API 等系统，因此不能盲目信任 AI 的输出，需要人工审核和系统级防护。
• 范式转变的必要性：开发者需要从“Prompt 驱动”转向“系统驱动”，将 AI 视为需要严格管理和约束的代码组件，而非具有自主智能的实体。

意义与影响

1. 对 AI 开发范式的修正

这篇文章呼吁行业回归理性，认识到 AI 并非万能的黑盒。它提醒开发者和企业，不能仅仅依靠“提示词”来构建可靠的 AI 应用。未来的 AI 应用开发需要更加注重系统工程，包括：

• 输入验证：在将数据喂给 AI 之前进行严格的清洗和验证。
• 输出校验：对 AI 的输出进行代码级的逻辑检查和事实核查。
• 权限最小化：遵循零信任原则，限制 AI 代理的权限，防止其执行危险操作。

2. 对 AI 安全策略的影响

随着 AI 代理在企业环境中的普及，其带来的安全风险日益凸显。文章的观点支持了以下安全策略：

• 隔离与沙箱：将 AI 代理的运行环境隔离，防止其访问敏感数据或执行系统级命令。
• 行为监控：实时监控 AI 代理的行为，检测异常模式。
• 人工介入：在关键决策环节保留人工审核机制，避免完全依赖 AI。

3. 对 AI 产品设计的启示

对于 AI 产品设计师而言，这意味着需要重新思考用户交互方式：

• 降低期望：明确告知用户 AI 的能力边界，避免过度承诺。
• 提供控制感：让用户能够更容易地纠正 AI 的错误，并提供反馈机制。
• 透明性：尽可能解释 AI 的决策过程，增加用户对 AI 输出的信任。

4. 对行业文化的反思

文章也反映了科技行业对 AI 炒作（Hype）的疲劳和反思。随着 AI 技术的成熟，行业需要从“炒作周期”的高点回归到务实的技术应用阶段。这有助于：

• 减少资源浪费：避免在无效的 Prompt 工程上投入过多资源。
• 聚焦核心价值：将精力集中在如何利用 AI 解决实际问题，而非追求虚幻的“通用人工智能”（AGI）近期实现。

总之，这篇文章是对当前 AI 狂热的一剂清醒剂。它强调，AI 是代码，需要像代码一样被严谨地设计、测试和管理。只有认识到这一点，才能真正发挥 AI 的潜力，同时规避其带来的风险。