I believe there are entire companies right now under AI psychosis

来源：HackerNews

I believe there are entire companies right now under AI psychosis

原文链接：https://twitter.com/mitchellh/status/2055380239711457578
来源：HackerNews

背景与概述

2024 年以来，AI 技术以惊人的速度渗透到软件行业的每一个角落。从 GitHub Copilot 到各类 AI 编程助手，从自动生成代码到全自动构建应用，"AI 原生"成为了最热门的创业标签。然而，在这场狂欢背后，一些冷静的声音开始浮现。HashiCorp 联合创始人 Mitchell Hashimoto 在 Twitter 上发出的警告——"我相信现在有些公司正陷入 AI 精神错乱（AI psychosis）"——如同一盆冷水，浇在了这个过热的市场上。

这里的"AI psychosis"并非医学术语，而是一种隐喻：形容企业因过度追逐 AI 潮流而丧失理性判断，将 AI 视为万能解药，忽视了软件工程的基本规律。这种现象在创业公司和传统企业的数字化转型中尤为明显。它们匆忙将 AI 集成到产品中，却未思考核心价值；它们用 AI 重构团队，却瓦解了原有的工程文化。当资本的热钱与媒体的喧嚣交织，理性决策变得异常困难。

Hashimoto 的警告之所以引发 HackerNews 社区的热议，正是因为它触及了一个深层焦虑：我们是否在重复过去技术泡沫的错误？从 Web3 到元宇宙，每一次技术浪潮都伴随着类似的集体狂热，而 AI 的门槛更低、叙事更强，使得"AI 精神错乱"的传染性也更为广泛。

核心内容

一、症状识别：AI 精神错乱的典型表现

陷入 AI 精神错乱的公司往往表现出以下特征：为 AI 而 AI——在产品中强行加入 AI 功能，即使传统算法更优；人才结构畸变——大量裁撤资深工程师，替换为"AI 提示词工程师"；技术债务加速累积——依赖 AI 生成不可维护的代码，却缺乏代码审查机制；指标幻觉——将"AI 调用次数""生成代码行数"作为成功标准，而非用户价值。

一个典型案例是某些初创公司将简单的 CRUD 应用重构为"AI 驱动"，结果系统复杂度飙升十倍，延迟和成本却难以承受。

二、根源剖析：为什么理性会失效？

AI 精神错乱的根源是多重的。资本压力是首要因素——风投的偏好迅速转向 AI 赛道，非 AI 项目融资困难；信息不对称加剧了焦虑——企业担心竞争对手用 AI 实现"十倍效率"，被迫跟风；技术神秘化让决策层高估了当前 AI 的能力边界，将其视为"黑魔法"而非统计工具；短期主义则使团队忽视长期技术健康，追求 demo 式的惊艳效果。

三、代价显现：那些被掩盖的真实成本

AI 的隐性成本常被低估。推理成本方面，GPT-4 级别的 API 调用费用可能使边际成本摧毁商业模式；可靠性成本体现在大模型的幻觉问题——在医疗、金融等场景，一次错误输出可能引发灾难；维护成本更为隐蔽，AI 生成的代码缺乏一致性，调试难度远超手写代码；组织成本则表现为团队技能退化，工程师丧失深度思考能力。

四、幸存者偏差：谁真正从 AI 中获益？

冷静观察会发现，AI 价值最大的场景往往具备特征：明确边界（如代码补全而非架构设计）、人机协同（AI 辅助而非替代）、快速验证（即时反馈循环）、容错设计（输出可被审查修正）。Cursor、Sourcegraph 等工具的成功，恰恰在于它们将 AI 嵌入成熟工作流，而非颠覆工作流本身。

技术分析

从技术架构视角看，"AI 精神错��"常表现为对 LLM 能力边界的误判。当前大语言模型的核心局限在于：

概率本质与确定性需求的冲突。LLM 基于 next-token prediction，其输出本质是概率采样，而软件系统需要确定性行为。以下对比说明了这一张力：

# 传统确定性函数：相同输入永远产生相同输出
def calculate_tax(amount: float, rate: float) -> float:
    return round(amount * rate, 2)

# LLM "函数"：相同输入可能产生不同输出
def generate_tax_advice(income: str) -> str:
    # 调用 OpenAI API，temperature > 0 时结果非确定性
    response = client.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": f"税务建议：{income}"}],
        temperature=0.7  # 随机性参数
    )
    return response.choices[0].message.content

上下文窗口的硬约束。即使是最先进的模型，上下文长度也有限（通常 128K-200K tokens），而企业级代码库动辄数百万行。RAG（检索增强生成）是常见缓解方案，但检索质量本身成为新瓶颈：

# 简化的 RAG 架构示意
class CodeAssistant:
    def __init__(self, codebase_path: str):
        self.index = VectorIndex()  # 代码向量索引
        self.llm = LLMClient()
        
    def answer_query(self, query: str) -> str:
        # 关键：检索质量决定生成质量
        relevant_chunks = self.index.similarity_search(query, top_k=5)
        context = "\n".join(relevant_chunks)
        
        # 若检索遗漏关键文件，生成必然出错
        return self.llm.generate(query, context=context)

评估困境（Evaluation is Hard）。传统软件有明确的测试标准，而 LLM 输出的质量评估本身就是开放研究问题。缺乏可靠评估，"改进"沦为主观感觉。

健康的 AI 架构应遵循防御性设计：将 LLM 视为不可靠的外部服务，用确定性层包裹不确定性，例如：

@retry_with_fallback
@validate_output_schema
@log_for_human_review
def ai_powered_feature(user_input: str) -> StructuredOutput:
    raw = llm.generate(user_input)
    return parse_and_validate(raw)  # 严格输出约束

实践建议

对于希望避免"AI 精神错乱"的开发者与团队，以下建议基于工程实践而非理论推演：

1. 建立"AI 适用性评估矩阵"

在引入 AI 前，从"错误成本""验证难度""频率""创造性需求"四个维度评分。高错误成本+难验证的场景，应优先传统方案。

2. 采用"渐进增强"而非"颠覆重构"

从具体痛点切入，如先用 AI 生成单元测试模板，再逐步扩展。保持原有系统的可回退性：

# feature flag 配置示例
ai_features:
  code_completion: 
    enabled: true
    model: "copilot"
    fallback: "snippet_based"  # 降级策略
  code_review:
    enabled: false  # 待验证后再开启
    required_human_approval: true

3. 投资"AI 时代的工程质量"

  • 强制要求 AI 生成代码通过同等审查标准
  • 建立 AI 输出的人工抽检机制
  • 保留核心模块的人工设计与文档

4. 培养"AI 素养"而非"AI 依赖"

工程师应理解 LLM 的工作原理、局限性和提示工程技巧，将其视为工具箱中的新工具，而非替代整个工具箱。

5. 设定"AI 预算"硬性约束

包括直接 API 费用、延迟 SLA、以及隐性的审查人力成本。当成本超过替代方案时，果断回退。

总结

Mitchell Hashimoto 的警告并非反技术，而是反狂热。AI 无疑是变革性的技术，但变革的价值取决于使用者的清醒程度。"AI 精神错乱"的本质，是将手段误认为目的、将可能性误认为必然性、将演示效果误认为生产就绪。对中国开发者而言，这既是一个警示——避免在资本叙事中迷失技术判断；也是一个机遇——在他人追逐泡沫时，扎实构建真正创造用户价值的 AI 应用。技术的周期永远起伏，但工程理性的价值历久弥新。当潮水退去，留在沙滩上的不会是"AI 原生"的标签，而是可靠、可维护、真正解决问题的系统。