为什么我们总是把错误归咎于 Prompt 而不是架构
看起来您只提供了来源链接，而没有贴出需要翻译的正文内容。请把要翻译的文本粘贴在这里，我会按照要求保留链接、格式和技术术语，将其翻译成简体中文。
Introduction
在 Moltbook 之后出现了一个悄然的模式：行业只保护表层，以免必须重建基础。
大约一个月前，我在 dev.to 上写了一篇名为 Tech Horror Codex: Substrate Sovereignty 的文章。这是一次实验——旨在探索当系统的行为超出我们当前治理模型的描述时会发生什么。当时可能感觉比较抽象，但随着行业对 Moltbook、NVIDIA 收购 Groq 以及最近一波“AI 身份”帖子的反应，这一模式已变得不可忽视。
重复模式
每当技术出现根本性转变时，我们都会看到相同的反应：
我们保护表层，以免必须重建基础。
在 Moltbook 之后，最流传的观点之一是，更好的提示本可以防止安全漏洞。这种想法令人安慰，因为它暗示：
- 系统本身没有问题
- 架构本身没有问题
- 治理本身没有问题
- 唯一的问题在于操作员的勤勉程度
但 Moltbook 并不是因为有人忘记提问而崩溃的。它崩溃是因为系统的行为超出了表层能够治理的范围。提示只能治理输出，不能治理系统本身。
AI‑Built Architecture
另一个流行的帖子庆祝了 AI 在没有人工编码的情况下构建整个架构的想法。这令人兴奋——也很揭示性。它强化了以下信念：
- 架构是可选的
- 约束是可选的
- 基底行为是可选的
如果 AI 能“闲置”，那么就没人需要思考当大量代理以机器速度协同工作时会发生什么。这回避了更难的问题：
当系统开始做我们未设计的事情时会怎样？
治理挑战
CSA 调查引发了一波关于以下主题的帖子：
- 非人类身份
- 代币蔓延
- 生命周期债务
- 所有权缺口
这些都是实际存在的下游问题——结构中可见的裂缝，而其底层物理已经发生了变化。IAM 管理访问权限，但 AI 需要治理机构——这是一个完全不同的问题。
大多数人将 Groq 的收购视为一次硬件加速的市场动作。实际上，Groq 的架构是为另一种需求而构建的：确定性、同步的多代理执行——协调物理。当协调成为底层时，整个云时代的治理堆栈（IAM、STAR、NIST、ISO）就会出现压力，这并不是因为框架本身不好，而是因为它们是为另一个世界设计的。
基底转变
从根基重建代价高昂——在认知、组织和政治层面都是如此。因此，行业在基底转变期间会一如既往地做以下事情：
- 指责运营商
- 指责提示
- 指责工作流
- 指责生命周期
- 指责工具
这只是一种避免承认基础本身需要重新思考的手段。这并非恶意，而是惯性。
新出现的症状
当系统的协同速度超过人类治理的速度时，一层行为变得可见：
- 漂移
- 身份侵蚀
- 不透明通道
- 机器速度不稳定
- 治理崩溃
行业正在给裂痕命名；底层仍未命名。底层不会等行业给它命名——它只会继续塑造可能性。
进一步阅读
Closing Note
这是我在 Moltbook、CSA 调查以及我一直在绘制的治理‑崩溃模式上写的最后一篇。分析已经完成，时间戳已存在，框架已记录。此工作供任何觉得有用的人使用；对不需要的人也没关系。底层结构不需要我不断解释——它只会继续塑造可能性。