潘锦的空间 » AI

SaaS 已死？AI 当立？

admin — Sat, 07 Mar 2026 02:16:44 +0000

在 AI 编程逛飙的年份，到当前的阶段，能感觉到速度在加快，形式也在不断的迭代，写代码这个事情也变得门槛很低。

X 上有人在讲「AI 让软件开发成本接近零，所以 SaaS 价值也接近零」

美股前段时间也因此大跌了一波，但当前这个价值为零的逻辑还是不成立的。

这里有一个概念混淆：构建软件的成本 vs 拥有软件的成本。AI 主要压低前者，后者还在，甚至在很多公司里变得更贵。

在各种自媒体、AI 编程培训或者博眼球的报道中，「一个下午做出 Linear 替代」「一个周末写完 Stripe 替代」这种话，我不觉得完全是吹牛。用 Claude Code 这类工具，把界面、CRUD、简单流程、甚至一些边角的自动化都拼出来，确实快。

但在做出来的那一刻，资产没增加多少，负债突然多了。尤其是碰钱、碰身份、碰合规、碰客户数据的时候。

以做了一个 Stripe 为例，我把 Vibe Coding 一个周末后，「现在拥有了什么」用更工程的语言翻译一下：

拥有了 规则持续变化 的税务与开票适配：欧盟 VAT、各国电子发票、免税/退税、税率变更、发票作废红冲。
拥有了 审计与认证的对话成本：PCI DSS、SOC 2、ISO 27001、渗透测试报告、供应商安全评估问卷。企业客户要的往往不是「你写得对不对」，是「谁在对这件事负责」。
拥有了 支付与账务的边界条件：拒付、部分退款、重复扣款、汇率、四舍五入、账期、对账差异、资金在途、延迟入账。
拥有了 全球化的坑：货币重估、货币小数位变化、地区性监管、某个国家突然要求强制 3DS、某个渠道突然不支持某种卡组织。
拥有了 数据与权限的事故半径：某个字段脱敏没做好、某个导出接口忘了做权限校验、某个后台操作没有审计日志。
拥有了 7×24 的值班现实：系统降级策略、容量、限流、重试风暴、第三方故障兜底、SLA 与赔付条款。

这些事大概率不是「可能发生」。按行业经验只是早晚问题。自从拥有系统开始，就等于自己签了那张无限期维护合同。

回想一个问题，SaaS 是什么？软件即服务，核心是服务，根本就没有提代码。

很多团队在内部系统上很执着，原因很直接：控制感强、改需求快、看起来省钱。上线半年以后，气氛通常变得不太好：需求排队、线上出过几次事故、业务抱怨响应慢、研发觉得自己在打杂。

这时候再看 SaaS，价值就很清晰了：SaaS 的核心商品是「运营表面积」的转移。

代码只是其中一层，除了代码还有：

基础设施与部署：多区域、容灾、备份恢复演练、变更管理。
安全：漏洞扫描、依赖升级、密钥轮换、权限最小化、WAF、DDoS。
合规：隐私条款、数据驻留、审计证据、流程制度落地。
可靠性：监控告警、事故复盘、容量规划、灰度发布、回滚策略。
支持与客户成功：工单、排障、培训、文档、FAQ、升级沟通。

当我们把软件「买回来」自己跑，这些都要自己补齐。很多公司低估的就是这一块。这也是为什么很多公司在 AI 赋能后，「运营表面积」的转移速度要慢于「代码」的转移速度。除非这些对公司不重要，如果这些都不重要，这个系统可能也不重要了。

从 SaaS 的生命周期来看，AI 提升的是「0 到 1」，然而从成本的角度看，最贵的是「1 到 ∞」

这件事可以拆成两条曲线：

vibe coded 工具：初期成本很低，后期成本增长很快。越多人用、越多数据、越多流程依赖，它的「改动风险」和「维护面」指数上升。
成熟 SaaS：初期采购成本看着不低，后期增长更接近线性。因为供应商把大量共性维护摊薄到所有客户身上。

AI 把 0→1 压得更便宜，直觉上会让人误判「买 SaaS 更不划算」。实际情况常常相反：AI 让 1→∞ 更贵了，因为我们会更频繁地改、更大胆地接更多业务进来，系统的负债增长速度被我们自己加速了。

这个成本不仅仅是 SaaS 软件的。

AI 让一个工程师单位时间产出更高，但单位工程小时的机会成本同步上升。

至少当前的认知是这样的，可能到终极形态，完成不用人介入的时候，这个机会成本也会消失掉。

那是另一个话题了。

所以我对「AI 让 SaaS 价值归零」的判断是反的：AI 越强，成熟 SaaS 越值钱，前提是它真的把服务做扎实，真的帮我们把运营表面积吃掉。

SaaS 本质上还是一种服务。

如果 SaaS 只是「界面更好看的 CRUD」，那这样的 SaaS 确实会死掉一批。

这些 SaaS 太薄了。

在 AI 时代要想活得更好，SaaS 通常需要如下的一些特征：

规则密度高，正确性要求高
合规与安全负担重
生态变化快，需要持续跟进
故障代价高，客户不想背锅
接口与集成复杂，长期维护吃人

Stripe、WorkOS、Cloudflare 这类产品的共同点很明显：它们难点不在「写出来」，难点在「长期把它跑对」。正确性要靠无数细碎决策堆出来，运营水位要常年拉满。

AI 始终会改写 SaaS，整体逻辑会有一些变化。这里的 AI 改写过程，肯定不是「加一个聊天框」「做一个总结」「做一个生成报表」。

我觉得至少有三个点在当前阶段能快速跟进：

意图驱动，SaaS 的用户最终都是想通过 SaaS 完成工作，以前靠 UI 引导的，现在可以让用户意图表达，然后把意图落为可审计的操作序列，不管是用 MCP，还是 SKILLS；
更关注结果，传统 SaaS 交付的是工具，客户负责把工具嵌进流程。AI 让厂商有机会把流程吃进去，直接交付结果，比如「自动完成对账」「自动完成入职」「自动完成工单分流」。关键点在「责任」
定制方式的迭代，企业客户永远会提定制。以前定制意味着项目制和人力黑洞；AI 让「生成」变得便宜，但不要把生成等同于可维护，可以允许客户用自然语言提出规则，系统把规则编译成可测试、可审计的约束，每次变更都能跑回归校验，出问题能定位到规则版本与变更人。

我们常听到对于自研和购买 SaaS 的一个判断逻辑是：「核心业务自研，非核心买 SaaS」。

这句话太粗，没有啥指导意义。

如下一个判断清单，可以做为决策的一些依据：

适合买 SaaS 的场景 ：

领域合规重：支付、税务、身份、隐私、审计
失败代价高：一出错就上新闻、上法务、上客户群
生态变化快：标准常变、监管常变、攻击手法常变
需要对外背书：企业客户会问「谁负责」「有没有认证」「有没有 SLA」

这种场景自研的隐性成本巨大。AI 再强，也只是让我们更快地把「维护合同」签在自己身上。

适合自研的场景

强差异化：流程就是你的竞争力，外部产品很难贴合
业务规则变化快，且只对内部负责：错了能快速纠正，不会引发合规事故
生命周期短：一个季度就会重构或下线的东西
数据高度敏感，且已经有成熟的数据治理与安全团队

这里自研的价值很实在：迭代速度、贴合度、数据控制。

AI 时代的「自研陷阱」会更隐蔽

以前自研失败，多数死在「做不出来」。现在会死在「做出来以后一路堆债」。

AI 会在早期持续正反馈：

功能做得快
Demo 好看
业务觉得爽
老板觉得省钱

债务也在同期累积：

没有威胁建模
没有权限与审计体系
没有数据分级与脱敏
没有灾备演练
没有 SLA 与值班机制
没有供应链安全策略（依赖库、镜像、密钥）

等到系统进入关键路径，会发现自己已经没有退路。再想补课，代价是「停业务」或者「带病重构」。

这也是我反复强调「拥有软件是负债」的原因。负债不会因为 AI 变聪明就消失，它只会增长得更快。

AI 把「做一个能用的软件」变成了常态，把「把软件长期跑对」推成了门槛。薄 SaaS 会被挤压，真正提供服务、背负责任、把运营表面积吃掉的 SaaS，会更值钱。

以上。

AI Agent 核心策略：如何判断 Agent 应该停止

admin — Sun, 12 Oct 2025 08:00:06 +0000

简单来讲，AI Agent 实现的的大逻辑就是一个大的循环 + 获取上下文 + 不停的 LLM 调用 + 工具的调用。

那么一个关键问题就出现了：这个循环什么时候应该停止？如果处理不当，Agent 可能会陷入无限循环，浪费计算资源，或者过早停止而无法完成任务。本文将深入探讨 AI Agent 停止策略的核心设计思路。

常用停止策略

AI Agent 停止策略无外乎以下几种情况：

1. 硬性限制

最简单粗暴的方法：

最大步数限制（比如最多循环 30 次）
执行时间限制（比如最多跑 5 分钟）
API 调用次数限制（比如最多调 100 次）
API 调用 Token 数限制

这种方法简单有效，但用户体验很差。经常出现任务做到一半被强制停止的情况。

2. 任务完成检测

让 LLM 判断任务是否完成：

# 每次循环后问 LLM
response = llm.ask("任务是否已经完成？")
if response == "是":
    stop()

3. 显式停止信号

给 Agent 一个专门的”停止”工具：

tools = [
    "search",
    "calculate", 
    "terminate"  # 专门用来停止
]

当 Agent 调用 terminate 工具时就停止。这个方法不错，但需要在 prompt 里教会 Agent 什么时候该调用它。

4. 循环检测

检测 Agent 是否在做重复的事：

连续多次调用同一个工具
动作序列出现循环模式（A→B→A→B…）
输出内容高度相似

5. 错误累积

连续失败多次就放弃：

if consecutive_errors > 3:
    stop("连续失败太多次")

6. 用户中断

让用户能随时喊停。

下面我们以 OpenManus 和 Gemini CLI 的源码来看一下他们是怎么做的。

OpenManus 的停止逻辑

OpenManus 的停止机制设计得比较完整，它用了一个多层防护的思路。

核心：terminate 工具

OpenManus 给每个 Agent 都配了一个 terminate 工具：

class Terminate(BaseTool):
    name: str = "terminate"
    description = """当请求已满足或无法继续时终止交互。
    完成所有任务后，调用此工具结束工作。"""
    
    async def execute(self, status: str) -> str:
        return f"交互已完成，状态：{status}"
        
以上为示例，原始代码：
from app.tool.base import BaseTool


_TERMINATE_DESCRIPTION = """Terminate the interaction when the request is met OR if the assistant cannot proceed further with the task.
When you have finished all the tasks, call this tool to end the work."""


class Terminate(BaseTool):
    name: str = "terminate"
    description: str = _TERMINATE_DESCRIPTION
    parameters: dict = {
        "type": "object",
        "properties": {
            "status": {
                "type": "string",
                "description": "The finish status of the interaction.",
                "enum": ["success", "failure"],
            }
        },
        "required": ["status"],
    }

    async def execute(self, status: str) -> str:
        """Finish the current execution"""
        return f"The interaction has been completed with status: {status}"

OpenManus 使用的是方案 3，把「何时停止」的决策权交给了 LLM。prompt 里会明确告诉 Agent：任务完成了就调用 terminate。

状态机管理

OpenManus 用状态机来管理 Agent 的生命周期：

class AgentState(Enum):
    IDLE = "idle"
    RUNNING = "running"  
    FINISHED = "finished"
    ERROR = "error"

当检测到特殊工具（如 terminate）被调用时，会触发状态转换：

async def _handle_special_tool(self, name: str, result: Any):
    if name.lower() == "terminate":
        self.state = AgentState.FINISHED
        logger.info(" 任务完成！")

步数限制

不同类型的 Agent 有不同的步数上限：

# ToolCallAgent: 30 步
# SWEAgent: 20 步
# PlanningFlow: 可配置

while self.current_step < self.max_steps and self.state != AgentState.FINISHED:
    self.current_step += 1
    await self.step()

if self.current_step >= self.max_steps:
    results.append(f"达到最大步数限制 ({self.max_steps})")

这是一个保底机制，防止 Agent 无限运行。

卡死检测

OpenManus 还会检测 Agent 是否卡住了：

def is_stuck(self) -> bool:
    # 检查是否有重复的 assistant 消息
    # 如果最近的回复都一样，说明卡住了
    recent_messages = self.get_recent_assistant_messages()
    if len(set(recent_messages)) == 1:
        return True
    return False

Planning Agent 的结束逻辑

1. 计划完成的判断机制

PlanningFlow 的结束判断并不是简单检查所有步骤是否完成：

# 在主执行循环中
while True:
    # 获取当前需要执行的步骤
    self.current_step_index, step_info = await self._get_current_step_info()
    
    # 如果没有更多活跃步骤，则结束计划
    if self.current_step_index is None:
        result += await self._finalize_plan()
        break

2. 步骤状态检查逻辑

_get_current_step_info() 方法负责判断是否还有未完成的步骤：

# 查找第一个非完成状态的步骤
for i, step in enumerate(steps):
    if i >= len(step_statuses):
        status = PlanStepStatus.NOT_STARTED.value
    else:
        status = step_statuses[i]
    
    # 如果步骤状态为活跃状态（未开始或进行中），返回该步骤
    if status in PlanStepStatus.get_active_statuses():
        return i, step_info

# 如果没找到活跃步骤，返回 None
return None, None

其中 get_active_statuses() 返回 ["not_started", "in_progress"]，意味着只有当所有步骤都是 "completed" 或 "blocked" 状态时，计划才会结束。

3. 计划结束处理

当没有更多活跃步骤时，会调用 _finalize_plan() 方法：

async def _finalize_plan(self) -> str:
    """使用 LLM 生成计划完成总结"""
    plan_text = await self._get_plan_text()
    
    # 使用 LLM 生成总结
    system_message = Message.system_message(
        "You are a planning assistant. Your task is to summarize the completed plan."
    )
    
    user_message = Message.user_message(
        f"The plan has been completed. Here is the final plan status:\n\n{plan_text}\n\nPlease provide a summary of what was accomplished and any final thoughts."
    )
    
    response = await self.llm.ask(messages=[user_message], system_msgs=[system_message])
    return f"Plan completed:\n\n{response}"

Gemini CLI 的停止逻辑

Gemini CLI 的设计思路完全不同，它用了一个更优雅但也更复杂的方案。

subagent 的停止逻辑

1. 达到最大轮次（MAX_TURNS）

if (this.runConfig.max_turns && turnCounter >= this.runConfig.max_turns) {
    this.output.terminate_reason = SubagentTerminateMode.MAX_TURNS;
    break;
}

这是最简单的保护机制，防止无限循环。

2. 执行超时（TIMEOUT）

let durationMin = (Date.now() - startTime) / (1000 * 60);
if (durationMin >= this.runConfig.max_time_minutes) {
    this.output.terminate_reason = SubagentTerminateMode.TIMEOUT;
    break;
}

注意这里检查了两次超时：

在调用 LLM 之前检查一次
在调用 LLM 之后又检查一次

这是因为 LLM 调用可能很耗时，要确保不会超时太多。

3. 用户中断（通过 AbortSignal）

if (abortController.signal.aborted) return;

这个检查出现在 stream 处理循环里，确保能及时响应用户的取消操作。

4. 错误异常（ERROR）

catch (error) {
    console.error('Error during subagent execution:', error);
    this.output.terminate_reason = SubagentTerminateMode.ERROR;
    throw error;
}

任何未捕获的异常都会导致停止。

5. 目标完成（GOAL）

目标完成的判断分两种情况：

情况A：没有预定输出要求

if (!this.outputConfig || Object.keys(this.outputConfig.outputs).length === 0) {
    // 没有要求特定输出，LLM 不调用工具就认为完成了
    if (functionCalls.length === 0) {
        this.output.terminate_reason = SubagentTerminateMode.GOAL;
        break;
    }
}

情况B：有预定输出要求

// 检查是否所有要求的变量都已输出
const remainingVars = Object.keys(this.outputConfig.outputs).filter(
    (key) => !(key in this.output.emitted_vars)
);

if (remainingVars.length === 0) {
    this.output.terminate_reason = SubagentTerminateMode.GOAL;
    break;
}

声明式输出系统的实现

声明式输出系统的核心是 outputConfig：

// 预先声明需要什么输出
this.outputConfig = {
    outputs: {
        "summary": "string",
        "recommendations": "array", 
        "risk_score": "number"
    }
};

// Agent 通过 self.emitvalue 工具来产生输出
// 每次调用会把值存到 this.output.emitted_vars 里
this.output.emitted_vars = {
    "summary": "这是总结...",
    "recommendations": ["建议1", "建议2"]
    // risk_score 还没输出
};

系统会不断检查 emitted_vars 是否包含了所有 outputs 中声明的变量。只有全部输出了才认为目标完成。

Nudge 机制

Nudge（轻推）机制代码：

if (functionCalls.length === 0) {  // LLM 停止调用工具了
    // 检查是否还有变量没输出
    const remainingVars = Object.keys(this.outputConfig.outputs).filter(
        (key) => !(key in this.output.emitted_vars)
    );
    
    if (remainingVars.length > 0) {
        // 还有变量没输出，"推"它一下
        const nudgeMessage = `You have stopped calling tools but have not emitted 
        the following required variables: ${remainingVars.join(', ')}. 
        Please use the 'self.emitvalue' tool to emit them now, 
        or continue working if necessary.`;
        
        // 把提醒作为新的用户消息发给 LLM
        currentMessages = [{
            role: 'user',
            parts: [{ text: nudgeMessage }]
        }];
        
        // 继续循环，不退出
    }
}

完整的 subagent 执行流程

开始
  ↓
while (true) {
  检查是否超时/超轮次 → 是 → 退出
    ↓ 否
  调用 LLM
    ↓
  LLM 返回工具调用？
    ├─ 是 → 执行工具 → 检查目标是否完成
    │         ├─ 是 → 退出
    │         └─ 否 → 继续循环
    │
    └─ 否（LLM 停止调用工具）
         ↓
       有预定输出要求吗？
         ├─ 没有 → 退出（认为完成）
         └─ 有 → 检查是否都输出了
                   ├─ 是 → 退出
                   └─ 否 → Nudge 提醒 → 继续循环
}

三层循环检测机制

第一层：工具调用重复检测

这是最简单直接的检测，针对 Agent 反复调用相同工具的情况。

private checkToolCallLoop(toolCall: { name: string; args: object }): boolean {
    // 把工具名和参数一起哈希，生成唯一标识
    const key = this.getToolCallKey(toolCall);
    
    if (this.lastToolCallKey === key) {
        // 和上次调用完全一样，计数+1
        this.toolCallRepetitionCount++;
    } else {
        // 不一样，重置计数
        this.lastToolCallKey = key;
        this.toolCallRepetitionCount = 1;
    }
    
    // 连续5次调用相同工具+相同参数 = 循环
    if (this.toolCallRepetitionCount >= TOOL_CALL_LOOP_THRESHOLD) {
        return true;
    }
}

触发条件：连续 5 次调用完全相同的工具（包括参数）。

这种检测很严格——必须是连续的、完全相同的调用。如果中间插入了其他工具调用，计数就会重置。

第二层：内容重复检测（”咒语”检测）

这是最复杂的部分，用来检测 LLM 输出重复内容的情况，就像在念咒语一样。

private checkContentLoop(content: string): boolean {
    // 1. 先检查是否在特殊内容块中（代码块、表格、列表等）
    const numFences = (content.match(/```/g) ?? []).length;
    const hasTable = /(^|\n)\s*(\|.*\||[|+-]{3,})/.test(content);
    // ... 检查各种格式
    
    // 在代码块中不检测循环（代码本来就可能有重复）
    if (this.inCodeBlock) {
        return false;
    }
    
    // 2. 把新内容加入历史
    this.streamContentHistory += content;
    
    // 3. 保持历史在 1000 字符以内
    this.truncateAndUpdate();
    
    // 4. 分析内容块是否重复
    return this.analyzeContentChunksForLoop();
}

核心算法是滑动窗口 + 哈希检测：

private analyzeContentChunksForLoop(): boolean {
    while (this.hasMoreChunksToProcess()) {
        // 提取 50 字符的块
        const currentChunk = this.streamContentHistory.substring(
            this.lastContentIndex,
            this.lastContentIndex + CONTENT_CHUNK_SIZE  // 50
        );
        
        // 计算哈希
        const chunkHash = createHash('sha256').update(currentChunk).digest('hex');
        
        // 检查这个块是否重复出现
        if (this.isLoopDetectedForChunk(currentChunk, chunkHash)) {
            return true;
        }
        
        // 滑动窗口向前移动 1 个字符
        this.lastContentIndex++;
    }
}

判断循环的条件：

private isLoopDetectedForChunk(chunk: string, hash: string): boolean {
    const existingIndices = this.contentStats.get(hash);
    
    if (!existingIndices) {
        // 第一次见到这个块，记录位置
        this.contentStats.set(hash, [this.lastContentIndex]);
        return false;
    }
    
    // 验证内容确实相同（防止哈希碰撞）
    if (!this.isActualContentMatch(chunk, existingIndices[0])) {
        return false;
    }
    
    existingIndices.push(this.lastContentIndex);
    
    // 需要出现至少 10 次
    if (existingIndices.length < CONTENT_LOOP_THRESHOLD) {  // 10
        return false;
    }
    
    // 关键：这 10 次必须距离很近（平均距离 ≤ 75 字符）
    const recentIndices = existingIndices.slice(-CONTENT_LOOP_THRESHOLD);
    const totalDistance = recentIndices[recentIndices.length - 1] - recentIndices[0];
    const averageDistance = totalDistance / (CONTENT_LOOP_THRESHOLD - 1);
    const maxAllowedDistance = CONTENT_CHUNK_SIZE * 1.5;  // 75
    
    return averageDistance <= maxAllowedDistance;
}

触发条件：同一个 50 字符的内容块，在很短的距离内重复出现 10 次。

第三层：LLM 智能检测

这是最高级的检测，用 AI 来判断 AI 是否陷入循环。

private async checkForLoopWithLLM(signal: AbortSignal) {
    // 取最近 20 轮对话
    const recentHistory = this.config
        .getGeminiClient()
        .getHistory()
        .slice(-LLM_LOOP_CHECK_HISTORY_COUNT);  // 20
    
    // 清理历史（去掉悬空的函数调用等）
    const trimmedHistory = this.trimRecentHistory(recentHistory);
    
    // 让 Gemini Flash 模型分析
    const result = await this.config.getBaseLlmClient().generateJson({
        contents: [...trimmedHistory, { role: 'user', parts: [{ text: taskPrompt }] }],
        schema: {
            type: 'object',
            properties: {
                reasoning: { type: 'string' },
                confidence: { type: 'number' }  // 0-1 之间
            }
        },
        model: DEFAULT_GEMINI_FLASH_MODEL,
        systemInstruction: LOOP_DETECTION_SYSTEM_PROMPT
    });
    
    if (result['confidence'] > 0.9) {
        // 高置信度认为是循环
        console.warn(result['reasoning']);
        return true;
    }
}

触发时机：

async turnStarted(signal: AbortSignal) {
    this.turnsInCurrentPrompt++;
    
    if (
        this.turnsInCurrentPrompt >= LLM_CHECK_AFTER_TURNS &&  // 至少 30 轮
        this.turnsInCurrentPrompt - this.lastCheckTurn >= this.llmCheckInterval
    ) {
        this.lastCheckTurn = this.turnsInCurrentPrompt;
        return await this.checkForLoopWithLLM(signal);
    }
}

必须执行超过 30 轮才开始检查（避免误判）
不是每轮都检查，有间隔（默认 3 轮）
间隔会根据置信度动态调整（5-15 轮）

// 动态调整检查频率
this.llmCheckInterval = Math.round(
    MIN_LLM_CHECK_INTERVAL +  // 5
    (MAX_LLM_CHECK_INTERVAL - MIN_LLM_CHECK_INTERVAL) * (1 - result['confidence'])
    // 置信度越高，检查越频繁
);

三种循环类型

系统定义了三种循环类型：

enum LoopType {
    CONSECUTIVE_IDENTICAL_TOOL_CALLS,  // 连续相同工具调用
    CHANTING_IDENTICAL_SENTENCES,      // 重复输出相同内容
    LLM_DETECTED_LOOP                  // LLM 检测到的逻辑循环
}

每种都有不同的检测方法和触发条件。

这比较适合处理长对话场景，既能有效检测循环，又不会因为过于敏感而误判正常的迭代操作。

小结

AI Agent 的停止策略是一个容易被忽视但极其重要的技术问题。从原理上看，Agent 就是一个大循环，不断调用 LLM 和工具来完成任务，但如果没有合理的停止机制，就会出现无限循环浪费资源，或者过早停止无法完成任务的问题。常见的停止方案包括硬性限制（步数、时间、API调用次数）、任务完成检测、显式停止信号、循环检测、错误累积和用户中断等，实际应用中需要组合使用多种策略。

OpenManus 采用了相对简单直接的设计：给每个 Agent 配备 terminate 工具，让 LLM 自己决定何时停止，同时用状态机管理生命周期，配合步数限制作为保底，并确保无论如何停止都会正确清理资源。

而 Gemini CLI 的设计更加精巧，核心是声明式输出系统——预先定义需要什么输出，只有全部输出才算完成，如果 Agent 停止调用工具但还有变量未输出，系统会通过 Nudge 机制温和提醒；在循环检测上，Gemini 实现了三层防护：工具调用重复检测（连续5次相同调用）、内容重复检测（滑动窗口+哈希算法检测”咒语”现象）、以及用 LLM 分析对话历史判断是否陷入逻辑循环。

实践中的关键是不要依赖单一停止机制，要组合使用多种策略形成多层防护，给 LLM 明确的停止指引，为不同类型的停止原因提供清晰的用户反馈，并确保资源能够可靠清理。停止策略的本质是在”让 Agent 完成任务”和”防止失控”之间找到平衡点。

以上。

关于 AI Agent：从 Manus 聊起

admin — Sat, 12 Jul 2025 03:39:54 +0000

最近几天 Manus 的新闻不停的出现在我的信息流中，从 Manus 官方账号清空了微博、小红书上的所有内容，到裁员争议，据说将核心技术人员迁往了新加坡。一个从北京、武汉出发的纯正中国公司，最终选择了离开。

还记得今年火热的 3 月，Manus 发布当天就引爆了社交网络。邀请码一码难求，甚至在二手平台被炒出天价。创始人肖弘（人称red）带领的这支年轻团队，用一个产品点燃了整个行业对 AI Agent 的热情。

2025 年是 AI Agent 元年。AI Agent 的发展速度惊人。不只是 Manus 这种通用型 Agent，还有各种垂直领域的，如设计领域的 lovart，编程领域的 Claude Code Cursor 等等。

那什么是 AI Agent，它由什么组成？今天我们聊一聊。

1. 从专家系统说起

要说 AI Agent 的历史，得从上世纪 60 年代说起。那时候，计算机科学家们就在琢磨一个事：能不能让机器像人一样，自己去感知环境、做出决策、然后采取行动？

最早的尝试是专家系统。比如 1970 年代斯坦福大学开发的 MYCIN，这是一个诊断血液感染疾病的系统。它的工作方式很简单：问医生一堆问题，然后根据预设的规则给出诊断建议。虽然现在看来很原始，但在当时，这已经算是「智能」了。

到了 80 年代，出现了更复杂的系统，比如 R1/XCON，帮助 DEC 公司配置计算机系统。这些系统有个共同特点：它们都是基于规则的。你得事先把所有可能的情况都想到，然后写成 if-then 规则。问题是，现实世界太复杂了，你不可能把所有情况都考虑进去。

90 年代，研究者们开始尝试新的路子。他们发现，与其让人去编写所有规则，不如让机器自己去学习。于是有了基于机器学习的 Agent，比如强化学习 Agent。这些 Agent 可以通过试错来学习如何完成任务。

但真正的转折点出现在 2010 年代深度学习兴起之后。特别是 2017 年 Transformer 架构的出现，彻底改变了游戏规则。有了 GPT、BERT 这些大语言模型，AI Agent 突然变得「聪明」了很多。它们不再需要人类事先编写规则，而是可以理解自然语言，根据上下文做出合理的判断。

2. 现代 AI Agent 的样子

要理解现代的 AI Agent，我们得先搞清楚它到底是什么。

简单来说，AI Agent 就是一个能够自主感知环境、制定计划、采取行动来完成特定目标的系统。听起来很抽象？我举个例子：

假设你要让 AI 帮你订一张从北京到上海的机票。一个简单的聊天机器人可能只会回答：”请您登录航空公司网站自行预订。”但一个真正的 AI Agent 会这样做：

理解你的需求（什么时间、预算多少、有什么偏好）
搜索多个航空公司的航班信息
比较价格和时间
根据你的偏好筛选
甚至可能帮你完成预订（如果有相应的接口）

这就是 AI Agent 和普通 AI 应用的区别：它不是被动地回答问题，而是主动地解决问题。

3. 核心技术和架构

现在咱们来看看 AI Agent 是怎么实现的。核心架构可以分成四个部分：

3.1 感知模块

这是 Agent 的「眼睛」和「耳朵」。它需要理解用户的输入，同时还要感知环境的状态。比如，当你让 AI Agent 帮你写代码时，它需要理解：

你想要实现什么功能
使用什么编程语言
有什么特殊要求
当前的代码结构是什么样的

但这里有个关键点：感知模块需要区分两种不同的信息——状态上下文和意图上下文。

状态上下文是环境的客观信息。比如：

当前项目使用的是 Python 3.9
代码库里已经有了用户认证模块
数据库是 MySQL
使用的是的 FastAPI 框架

这些信息是确定的、可验证的事实。Agent 需要准确地获取和理解这些信息，因为任何误判都可能导致后续行动的失败。

意图上下文则是用户想要达成的目标，这往往更加模糊和主观。比如用户说「帮我优化一下这段代码」，Agent 需要理解：

「优化」是指性能优化还是可读性优化？
用户的性能预期是什么？
有没有特定的约束条件？

区分这两种上下文至关重要。很多 AI Agent 的失败，就是因为混淆了状态和意图。比如，用户说「这个函数太慢了」，Agent 需要识别出：

状态：函数执行时间是 500ms
意图：用户希望降低到 100ms 以内

现代的 AI Agent 通过多种方式来增强感知能力：

多模态感知：不只是文字，还包括图像、语音、甚至视频。Cursor 支持图片上传，代码索引，文档等。

主动询问：当信息不充分时，优秀的 Agent 会主动提问。「你提到要优化性能，具体是想优化响应时间还是内存占用？」这种澄清式的对话，能大大提高后续行动的准确性。

历史记录：通过分析用户的历史行为，Agent 可以更好地理解当前的意图。如果用户之前多次要求「简洁的代码」，那么在新的任务中，Agent 就会倾向于生成更简洁的解决方案。

环境探测：高级的 Agent 还会主动探测环境。比如，在开始写代码前，它可能会先检查项目的配置文件、依赖列表、测试用例等，构建一个完整的环境画像。

感知的准确性直接决定了 Agent 的表现。一个看不清路的司机，再好的驾驶技术也没用。同样，一个不能准确理解用户意图和环境状态的 Agent，后续的规划和执行必然会出问题。

3.2 推理模块

这是 Agent 的「大脑」，也就是大语言模型。现在主流的做法是使用 GPT-4、Claude、Gemini 这样的大模型。但光有大模型还不够，还需要深入理解不同模型的特性，才能让它们更好地工作。

模型的性格差异

就像人有不同的性格，AI 模型也有各自的「个性」。这不是玄学，而是训练方式和优化目标的差异造成的。

以 Cursor 编辑器的实践为例，他们把模型分为两大类：

思考型模型（Thinking Models）：

Claude 3 Opus：喜欢先理解全局，会主动推断你的意图
Gemini 2.0 Flash：自信果断，经常会做出超出预期的大改动
o1：专门为复杂推理设计，会花时间深入分析问题

这类模型就像经验丰富的专家，你给它一个大方向，它会自己规划路径。适合探索性任务、大规模重构、或者当你自己也不太确定最终方案时使用。

执行型模型（Non-thinking Models）：

Claude 3.5 Sonnet：等待明确指令，不会过度推断
GPT-4 Turbo：行为可预测，适合精确控制
文心一言 4.0：在中文任务上表现稳定

这类模型像是可靠的助手，严格按照你的要求执行。适合明确的任务、需要精确控制的场景、或者当你已经知道要做什么时使用。

选择模型的艺术

选择合适的模型，就像选择合适的工具。你不会用大锤子去拧螺丝，也不会用螺丝刀去砸钉子。

根据任务类型选择：

代码生成：Claude 3.5 Sonnet 和 GPT-4 都很优秀
代码理解和重构：Gemini 2.0 Flash 的长上下文能力突出
复杂 Bug 调试：o1 的深度推理能力更适合
中文文档处理：通义千问、豆包有本土优势

根据交互风格选择：

如果你喜欢给出详细指令：选择执行型模型
如果你偏好给出大方向：选择思考型模型
如果你需要创造性方案：选择更”活跃”的模型
如果你需要稳定输出：选择更”保守”的模型

提示词工程的进化

早期的 AI Agent 严重依赖精心设计的提示词。但随着模型能力的提升，这种情况正在改变。

从复杂到简单：过去我们可能需要这样的提示词：

你是一个专业的Python开发者。请严格遵循PEP8规范。
在编写代码时，请考虑以下几点：
1. 代码的可读性
2. 性能优化
3. 错误处理
...（还有20条）

现在，一句简单的”帮我优化这段代码”就能得到不错的结果。

动态提示词策略：现代 AI Agent 会根据上下文动态调整提示词：

初次对话：使用更详细的背景说明
后续对话：只提供增量信息
错误修正：加入具体的约束条件
创造性任务：减少限制，鼓励探索

混合模型策略

越来越多的 AI Agent 开始采用混合模型策略，在一个任务流程中使用多个模型：

理解阶段：使用 Claude 3 Opus 深入分析需求
规划阶段：使用 o1 制定详细的执行计划
执行阶段：使用 GPT-4 Turbo 快速生成代码
优化阶段：使用专门的代码模型进行微调

这种方式能够充分发挥每个模型的优势，同时控制成本。

3.3 记忆模块

人做事情需要记住前面发生了什么，AI Agent 也一样。记忆分成几种：

短期记忆：当前对话的上下文
长期记忆：之前的对话历史、学到的知识
工作记忆：执行任务过程中的中间状态

但实现一个好的记忆系统，比想象中要复杂得多。

3.3.1 记忆的层次结构

就像人脑有不同类型的记忆，AI Agent 的记忆系统也需要分层设计：

感知记忆（Sensory Memory）：

保存时间：几秒到几分钟
内容：用户刚刚的输入、系统刚刚的输出
用途：处理连续对话中的指代关系

工作记忆（Working Memory）：

保存时间：整个任务周期
内容：当前任务的状态、中间结果、待办事项
用途：复杂任务的分步执行

情景记忆（Episodic Memory）：

保存时间：数天到数月
内容：完整的对话历史、任务执行记录
用途：理解用户偏好、避免重复错误

语义记忆（Semantic Memory）：

保存时间：永久
内容：领域知识、最佳实践、学到的模式
用途：积累经验、提升能力

3.3.2 实现方案-RAG（检索增强生成）

这是目前最成熟的方案。基本思路是：当 AI Agent 需要回答问题时，先去知识库里检索相关信息，然后把这些信息作为上下文提供给大模型。

比如你问：”我们公司的年假政策是什么？”Agent 会先去检索公司的政策文档，找到相关内容，然后基于这些内容生成回答。

RAG 的进化史

第一代 RAG（2020-2022）：

简单的向量检索
使用 BERT 或 Sentence-BERT 做编码
召回 Top-K 相关文档
效果一般，经常找不到真正相关的内容

第二代 RAG（2023-2024）：

引入混合检索（向量+关键词）
使用更强的编码模型（如 BGE、E5）
加入重排序（Reranking）步骤
开始考虑文档结构和语义分块

第三代 RAG（2024-现在）：

多级索引结构（摘要→章节→段落）
查询改写和扩展
动态上下文窗口调整
引入知识图谱增强检索

实践中的 RAG 优化技巧

智能分块：不要机械地按字数切分，而是按语义单元切分
- 代码：按函数/类切分
- 文档：按章节/段落切分
- 对话：按话轮切分
多路召回：同时使用多种检索策略
- 向量相似度检索
- BM25 关键词检索
- 实体链接检索
- 基于图的检索
上下文工程：检索到的内容需要精心组织
增量索引：新知识的实时更新
- 使用流式处理架构
- 支持热更新索引
- 版本控制和回滚机制

3.3.3 实现方案-超长上下文

最新的趋势是直接增加模型的上下文长度。比如 Claude 3 已经支持 200K token 的上下文，Gemini 1.5 Pro 甚至支持 200 万 token。

长上下文的真实挑战

虽然模型号称支持超长上下文，但实际使用中会遇到很多问题：

「迷失在中间」现象：模型对上下文开头和结尾的内容记忆较好，但中间部分容易遗忘
注意力稀释：上下文越长，模型对每个部分的注意力就越分散
推理退化：在超长上下文中，模型的推理能力会显著下降

混合方案：长上下文 + 选择性注意

3.3.4 主动遗忘

这是一个反直觉但很重要的概念：不是记住越多越好，而是要学会遗忘。

为什么需要遗忘？

降噪：不是所有信息都值得记住
隐私：某些敏感信息需要及时删除
效率：保持记忆系统的高效运转
相关性：过时的信息可能产生负面影响

遗忘策略

基于时间的遗忘：
- 会话结束后 24 小时删除临时信息
- 30 天后归档低频访问的记忆
- 90 天后删除无用的错误记录
基于重要性的遗忘：
- 使用 LRU（最近最少使用）策略
- 基于访问频率的动态评分
- 保留高价值的”关键时刻”
基于相关性的遗忘：
- 当新信息与旧信息冲突时，更新而非累加
- 合并相似的记忆，避免冗余
- 定期整理和压缩记忆库

3.4 行动模块

这是 Agent 的「手脚」，让它能够真正做事情。

行动模块的核心是 Function Calling（函数调用），这是目前最主流的方式。

简单来说，就是预先定义好一系列函数，比如搜索网页、查询数据库、发送邮件等，然后告诉大模型这些函数的作用和参数。

当用户提出需求时，模型会判断需要调用哪个函数，提取相应的参数，执行函数并获取结果。这个过程已经从最初的单次调用，进化到现在可以进行多步骤调用、并行执行、错误重试等复杂操作。

Anthropic 推出的 MCP（Model Context Protocol）协议，试图建立行动模块的统一标准。

MCP 采用服务器-客户端架构，工具提供方作为服务器，AI 应用作为客户端，通过标准化的协议进行通信。这种设计的好处是解耦和复用：AI 应用不需要知道工具的具体实现细节，一个 MCP 服务器可以同时服务多个 AI 应用。更重要的是，MCP 提供了统一的安全管理和权限控制机制，让行动模块的集成变得更加简单和安全。

安全性是行动模块最关键的考虑因素。

在 Manus 刚上线的时候就爆出一个问题，有人用提示词，让 AI Agent 打包了当前执行的环境的所有代码。

给 AI 执行能力就像给孩子一把剪刀，必须设置严格的安全边界。现代 Agent 通常采用多层防护：首先是沙箱环境，所有代码执行都在隔离的容器中进行，限制内存、CPU、网络访问；其次是权限管理，基于用户角色和具体场景动态分配权限；最后是审计日志，记录所有行动的执行情况，便于追溯和分析。这些措施确保 Agent 在帮助用户的同时，不会造成安全风险。

复杂任务往往需要多个行动的协调配合，这就需要工作流引擎来编排。比如”帮我分析竞品并生成报告”这个任务，可能需要先搜索竞品信息，然后提取关键数据，接着进行对比分析，最后生成可视化报告。工作流引擎负责管理这些步骤的执行顺序、处理步骤间的数据传递、应对执行失败等情况。高级的引擎还支持条件分支、循环执行、并行处理等复杂逻辑，让 Agent 能够处理更加复杂的任务。

行动模块的未来发展方向是更强的自主性。目前的 Agent 主要执行预定义的动作，但未来可能会具备动作发现和学习能力，能够自动发现新的 API、学习新的操作模式、甚至创造性地组合已有动作来完成新任务。另一个重要方向是与物理世界的交互，通过机器人或 IoT 设备执行物理动作。随着这些能力的提升，AI Agent 将真正从「会说」进化到「会做」，成为人类在数字世界和物理世界中的得力助手。

4. 当前的局限性

AI 有其局限性，了解这些局限性，对于合理使用和未来改进都很重要。

4.1 幻觉问题

这是所有基于大模型的 AI Agent 都面临的核心挑战。

Agent 可能会编造不存在的 API、虚构执行结果、或者对自己的能力过度自信。比如，当你要求 Agent 查询某个数据库时，它可能会返回看起来合理但实际上完全虚构的数据。

这种幻觉在连续多步骤的任务中会被放大，一个小错误可能导致整个任务链的崩溃。

更危险的是，这些幻觉往往很难被发现，因为它们在表面上看起来完全合理。虽然通过 RAG、工具调用验证等方法可以部分缓解，但彻底解决仍然是个开放性难题。

4.2 可靠性不足

AI Agent 的表现稳定性仍然是个大问题。

同样的任务，在不同时间执行可能得到不同的结果。

这种不确定性来源于多个方面：模型本身的随机性、上下文理解的偏差、外部环境的变化等。

在一些对可靠性要求高的场景，比如金融交易、医疗诊断、工业控制等，目前的 AI Agent 还远远达不到要求。

即使加入了重试机制、结果验证等保障措施，也只能提高而非保证可靠性。这导致在关键业务场景中，AI Agent 更多是作为辅助而非主导。

4.3 成本与效率

运行一个功能完善的 AI Agent 系统成本不菲。

首先是模型调用成本，特别是使用 GPT-4、Claude 等顶级模型时，每次交互都要花费不少钱。复杂任务可能需要多次模型调用，成本会快速累加。

其次是延迟问题，每次函数调用、每次推理都需要时间，一个看似简单的任务可能需要等待数十秒甚至几分钟。对于需要实时响应的场景，当前的 AI Agent 往往力不从心。

虽然可以通过模型蒸馏、缓存优化等手段降低成本，但在性能和成本之间找到平衡点仍然很困难。

4.4 安全与隐私挑战

AI Agent 需要访问大量数据和系统才能发挥作用，这带来了严重的安全隐私问题。

首先是数据泄露风险，Agent 可能无意中将敏感信息包含在给大模型的请求中，而这些数据可能被用于模型训练。

其次是提示注入攻击，恶意用户可能通过精心构造的输入操控 Agent 执行非预期的操作。

还有权限滥用问题，一个被赋予过多权限的 Agent 可能造成严重损害。

虽然业界正在开发各种防护措施，如差分隐私、安全沙箱、细粒度权限控制等，但攻防对抗仍在继续。

4.5 理解与推理的局限

虽然大模型展现出了惊人的能力，但 AI Agent 在深层理解和复杂推理方面仍有明显不足。它们往往只能处理相对直接的任务，面对需要长链条推理、创造性思维或深层次理解的问题时就会暴露短板。

比如，Agent 可能很擅长执行”帮我订一张机票”这样的任务，但如果要求”帮我规划一个考虑预算、时间、个人兴趣的完整旅行方案”，效果就会大打折扣。

此外，Agent 缺乏真正的常识推理能力，可能会提出一些违背基本常识的方案。即使是最新的 o1 模型，虽然推理能力有所提升，但距离人类水平的推理能力还有很大差距。

5. 写在最后

AI Agent 的发展才刚刚开始。虽然现在的技术还不完美，但进步的速度是惊人的。两年前，我们还在惊叹 ChatGPT 能够进行对话；现在，AI Agent 已经能够帮我们写代码、分析数据、制定计划了。

对于技术人员来说，现在是最好的时代。我们有机会参与到这场变革中，创造出真正有用的 AI Agent。但同时，我们也要保持清醒：AI Agent 是工具，不是魔法。它能够提高效率，但不能替代人类的创造力和判断力。

未来的世界，可能每个人都会有自己的 AI Agent 团队。就像现在每个人都有智能手机一样自然。

而现在，正是这个未来的开端。

以上。

代码生成之外：AI 编程对开发者思维的深层影响

admin — Thu, 01 May 2025 03:18:52 +0000

AI 的浪潮正以前所未有的速度席卷着各行各业，而软件开发领域无疑是这场变革的风暴中心。从代码自动生成、智能调试到需求分析，从 Copilot 到 Cursor 等 IDE，AI 编程工具如雨后春笋般涌现，极大地改变了我们日常工作的逻辑。

面对 Copilot/IDE 们日益强大的能力，许多开发者或许感到兴奋，或许也夹杂着一丝焦虑：当 AI 能写代码、能查 Bug 时，我们开发者的核心价值将何去何从？

仅仅将 AI 视为提升编码效率的「高级自动补全」工具，是对这场深刻变革的误读。真正的挑战与机遇并存，它要求我们进行一次根本性的思维转变。如果仍然固守着传统的、以手动实现细节为主的工作模式，我们很可能错失 AI 带来的巨大红利，甚至在未来逐渐失去竞争力。这不再是简单地学习一个新工具，而是需要重塑我们的工作哲学和核心能力。

今天我们将聊一下 4 个关键的思维转变和实践框架

「AI 优先」的工作流整合
「指挥官思维」的战略主导
「向 AI 学习」的持续进化态度
构建高效「人机协同」复合框架的必要性

1. AI 优先

AI 优先是重新定义开发工作流的战略基石。

1.1 核心内涵：从默认手动到优先 AI 协作

「AI 优先」并非仅仅倡导使用 AI 工具，而是一种根本性的工作流程哲学和问题解决范式的转变。

其核心在于，当我们启动任何一项开发过程中的任务——无论是需求分析、架构设计、编码实现、代码审查、联调测试、用例生成、文档撰写，还是技术学习与研究——首要的、默认的思维步骤是主动评估：「 AI 在此环节能扮演何种角色？如何利用 AI 来提升任务执行的效率、质量或创新性？」 这与传统模式形成鲜明对比，后者往往默认以纯粹的人力手动操作为起点，仅在遇到特定瓶颈时才考虑引入自动化或辅助工具。AI 优先将 AI 从「备选项」提升到了「首选项」，要求我们在流程伊始就将其视为潜在的核心协作者。

1.2 思维转变的深度体现

主动整合 vs. 被动应用 :
- 深度解析: 这标志着我们与技术生态关系的质变。过去，我们可能在 IDE 中使用代码补全，或在遇到难题时搜索特定库的 AI 辅助工具。这是一种响应式、孤立式的应用。而「AI 优先」要求前瞻性、系统性地思考如何将 AI 能力内嵌到整个开发流程中。我们不再是被动等待工具推送建议，而是主动设计包含 AI 交互点的新型工作流。这需要我们具备流程再造的意识，识别出 AI 最具潜力的介入点，并优化人机交互模式。
- 战略意义: 将 AI 视为开发环境的一等公民，而非外挂插件。这种主动整合是最大化 AI 价值、构建复合智能开发体系的前提。
效率导向 & 认知资源重分配:
- 深度解析: AI 优先的直接目标是显著提升开发效率，但这并非终点。通过将重复性、模式化、信息密集型的任务（如生成样板代码、查找 API 细节、初步代码审查、基础测试生成）委托给 AI，我们得以将宝贵的认知资源 从繁琐的底层细节中解放出来。这种解放并非为了减少工作量，而是为了战略性地聚焦于更高价值的活动，这与「从细节实现到架构设计与问题分解」的转变一脉相承。
- 战略意义: 提升的不仅是速度，更是我们价值的跃迁。我们能投入更多精力于理解业务需求、进行复杂的系统设计、处理非结构化问题、进行创新性探索以及做出关键性技术决策，这些是 AI 短期内难以完全替代的核心人类优势。
工具熟练度 & 能力边界认知:
- 深度解析: 实践「AI 优先」绝非盲目依赖。它要求我们不仅熟练掌握各种 AI 开发工具（如 Copilot, ChatGPT, Cursor, 各类 AI 驱动的测试/调试平台等）的具体操作，更要深刻理解其能力边界、适用场景、潜在偏见和局限性。这包括：知道何时 AI 的建议可靠，何时需要批判性审视；理解不同模型在不同任务上的表现差异；掌握有效的提示工程 技巧以引导 AI 产出高质量结果；并了解 AI 输出可能存在的安全风险或合规问题。
- 战略意义: 熟练度意味着精准驾驭，意味着我们需要成为聪明的「AI 用户」，能够根据任务特性选择最合适的 AI 工具和交互策略，并对结果进行有效验证和整合，确保最终产出的质量和可靠性。这是一种新的核心技能。

1.3 实践示例

「AI 优先」在实践中并非意味着所有步骤都由 AI 完成，而是以 AI 作为起点：

用 AI 初始代码框架: 不仅是生成基础结构，更可以利用 AI 快速探索多种实现方案，或根据特定设计模式生成初步代码，极大加速原型构建和技术选型验证。
让 AI 解释错误信息或提出修复建议: 超越简单的错误信息查找，可以要求 AI 结合上下文代码分析潜在的根本原因，甚至预测可能相关的其他问题区域，提供更深层次的洞察。
使用 AI 生成单元测试: 不仅是覆盖基础路径，可以利用 AI 探索边缘情况和异常输入，提升测试覆盖率和鲁棒性，甚至根据代码变更智能推荐需要更新的测试用例。
通过 AI 快速学习一个新的 API 或库的用法: 从简单的用法查询，到要求 AI 提供示例项目、对比相似库、解释设计哲学、甚至模拟一个小型应用场景，实现更高效、更深入的即时学习。
在设计阶段，询问 AI 关于不同架构模式的优缺点: 将 AI 作为技术顾问或「虚拟专家」，快速获取关于不同架构选择（如微服务 vs. 单体，不同数据库选型）在特定场景下的利弊分析、潜在挑战、行业最佳实践等信息，辅助决策制定。

「AI 优先」是一种要求我们在思维层面将 AI 视为默认协作者，在实践层面主动将 AI 整合进工作流程，并以提升效率和聚焦高价值活动为导向，同时具备对 AI 工具的深度理解和批判性使用能力的方法论。采纳「AI 优先」意味着我们正从传统的「工匠」角色，向着更具战略眼光的「技术架构师」和「智能系统构建者」进化。

2. 指挥官思维

指挥官思维是驾驭人机协同的战略核心。

2.1 核心内涵：从执行者到战略决策者的角色升维

「指挥官思维」定义了我们在与 AI 深度协作环境下的核心定位与责任模型。

尽管 AI 工具（如大型语言模型、AI 编程器）展现出强大的自动化执行能力，我们并非沦为被动的指令接收者或简单的工具操作员，而是必须承担起战略主导者的角色。

这种思维模式要求我们能够掌握全局，负责设定目标、制定实施策略、进行任务的有效分解与委派、设计并下达高质量、精确的指令（即提示工程）、对 AI 的产出进行严格的审视与评估、基于评估结果做出关键技术决策，并最终对项目或产品的整体质量、安全性、性能及业务价值承担最终责任。

在这个模型中，AI 是能力强大的「智能执行单元」或「高级参谋」，提供信息、生成方案、执行具体任务，但最终的判断权、决策权和方向掌控权牢牢掌握在我们手中。

2.2 思维转变的深度体现

战略高度 vs. 细节沉溺:
- 深度解析: 这与我们从「关注具体代码行实现」向「聚焦架构设计与复杂问题分解」的核心转变完美契合。「指挥官」的首要职责是理解并服务于业务目标 和系统级的非功能性需求（如可扩展性、可靠性、安全性、可维护性）。他们关注的是「战役」的胜利（例如，交付具有市场竞争力的产品、构建高可用的系统等等），而不是纠结于每一行代码的具体写法（这是可以有效利用 AI 的地方）。这意味着我们需要具备更强的系统思维 能力，能够从宏观层面规划技术蓝图、识别关键风险、权衡不同的架构选项。
- 战略意义: 这种视角的提升使得我们能够利用 AI 处理大量的实现细节，从而将精力集中在设计决策、技术选型、风险管理和确保长期价值等更具战略意义的工作上，这些是决定项目成败的关键因素。
结果导向与批判性思维 vs. 盲目信任:
- 深度解析: 「指挥官」的核心职责是确保任务目标的达成，并保证最终成果符合预定的质量标准。这直接对应了我们从「从零构建」到「侧重验证、调试与优化」的转变。鉴于当前 AI（尤其是生成式 AI）输出的非确定性 和潜在的「幻觉」、偏见、安全漏洞或性能陷阱，我们必须运用高度的批判性思维 和怀疑精神。对 AI 生成的代码、设计建议、测试用例等「战果」，需要进行多维度、深层次的审视：不仅要验证其功能正确性，还要评估其代码质量、可读性、效率、安全性、是否符合项目规范和最佳实践。
- 战略意义: 这是确保 AI 协作安全、有效的关键保障。缺乏批判性思维的盲目采纳可能导致技术债、安全风险甚至项目失败。「指挥官」必须扮演好质量守门人 的角色，利用自己的专业知识和经验对 AI 的贡献进行筛选、修正和确认。
有效沟通（提示工程） vs. 模糊指令:
- 深度解析: 「指挥官」向 AI 下达指令的过程，本质上是一种高精度的人机交互和知识传递。高质量的 Prompt 不仅仅是提出问题，而是需要精确定义任务目标、明确上下文信息、设定约束条件、提供示例、甚至指定输出格式。这要求我们具备优秀的需求分析和表达能力，能够将复杂的意图转化为 AI 可理解、可执行的清晰指令。这门新兴的技能——提示工程——正成为「指挥官思维」下的一项核心技术能力。
- 战略意义: 指令的质量直接决定了 AI 输出的质量和效率。有效的沟通能够最大限度地发挥 AI 的潜力，减少反复试错和无效输出，从而显著提升协作效率。精通 Prompt Engineering 能够更精准地「指挥」AI，达成预期目标。

2.3 实践示例

「指挥官思维」在实践中转化为一系列具体的行动要求：

清晰地定义 AI 任务目标与约束条件: 不仅是「写一个登录函数」，而是「使用 OAuth 2.0 协议，实现一个安全的、支持多种第三方登录（Google, GitHub）、并符合公司现有 Python 代码规范和日志标准的登录模块」。明确的边界和要求是高质量输出的前提。
将复杂问题分解为 AI 可处理的子任务: 识别出大型任务中适合 AI 处理的模块化部分（如数据解析、API 调用封装、特定算法实现），设计清晰的接口，然后分别委派给 AI，最后由我们进行整合。这体现了模块化设计和任务管理能力。
提出精确、有效的 Prompt: 运用结构化 Prompt、提供背景知识、明确角色扮演（如「假设你是一位资深安全专家…」）、要求解释推理过程等高级技巧，引导 AI 产出更符合需求的、更高质量的内容。
批判性地审查 AI 的输出，识别潜在问题: 进行代码走查 (code review)、静态分析、动态测试、安全扫描，并结合自身领域知识判断方案的合理性、潜在风险和长期影响。绝不直接复制粘贴未经验证的代码。
整合 AI 的贡献，并做出最终的技术决策: 将 AI 生成的部分与人工编写的代码或其他系统组件有机结合，解决集成中可能出现的问题。基于对整体架构、业务需求和团队能力的综合考量，做出最终的技术选型、设计方案和实现路径的决策。我们始终是技术路线的最终拍板者和负责人。

「指挥官思维」是我们在 AI 时代保持主导地位和核心价值的关键。它要求我们超越纯粹的技术执行，提升到战略规划、任务设计、质量控制和决策制定的高度。通过有效地设定目标、分解任务、精准沟通（Prompting）、严格评估和最终决策，我们能够驾驭强大的 AI 能力，将其作为实现更宏大目标、创造更高价值的有力工具，从而在人机协同的新范式中扮演不可或缺的领导角色。

3. 向 AI 学习

向 AI 学习是构建人机协同的认知增强回路

3.1 核心内涵：从工具利用到知识伙伴的认知定位转变

「向 AI 学习」代表了一种深刻的认识论转变，它要求我们将 AI 从单纯的任务执行工具 提升为动态的知识伙伴 和个性化的学习资源。

其核心在于，我们在与 AI 交互的每一个环节——无论是获取代码建议、调试错误、探索设计方案，还是理解复杂概念——都保持一种主动的学习姿态。这意味着不仅要利用 AI 的输出来完成当前任务，更要有意识地从交互过程、AI 生成的内容及其背后的逻辑解释中提取、内化新的知识、技能、方法论或甚至不同的思维视角。这是一种将日常开发工作转化为持续学习和认知增强机会的态度。

3.2 思维转变的深度体现

持续学习与适应性的加速器:
- 在技术栈日新月异、知识半衰期急剧缩短的当下，我们面临着前所未有的学习压力。传统的学习模式（如阅读文档、参加课程）往往存在时滞性或不够个性化。「向 AI 学习」直接关联并赋能了「从掌握特定语言/框架到理解核心概念与快速学习」这一关键转变。AI 可以作为一个即时响应、情境感知的学习引擎，根据我们当前遇到的具体问题或技术挑战，提供精准、个性化的知识输入。它能迅速填补知识空白，加速对新技术的理解和掌握，从而极大地提升我们的**适应性商数 (AQ)**。
- 将学习过程无缝融入日常工作流，变被动追赶为主动适应，使我们能够更敏捷地跟上技术前沿，保持长期的专业竞争力。
拓展认知边界与激发创新思维:
- 我们的知识和经验往往受限于个人背景、项目经历和信息接触范围。而 AI，特别是基于大型模型的 AI，其训练数据涵盖了极其广泛和多样化的知识语料库。当我们就某一问题向 AI 寻求解决方案时，AI 可能提供多种不同的实现路径、引入我们不熟悉的库或框架、或者应用某种新颖的设计模式。这种接触异质性信息 的过程，本身就能有效打破思维定势，拓展我们的技术视野。
- AI 成为了一个创新的催化剂。通过展示不同的可能性，即使 AI 的某些建议并非最优或完全适用，也能激发我们产生新的想法，促进“创造力与创新思维”的发展，从而在解决问题时拥有更丰富的策略储备。
深化原理理解与构建心智模型:
- 仅仅复制代码或接受建议而不求甚解，无法带来真正的能力提升。「向 AI 学习」强调要利用 AI 的解释能力。当 AI 生成一段代码、推荐一个架构或诊断一个错误时，主动追问「为什么」——「这段代码的底层逻辑是什么？」、「推荐这个库基于哪些权衡考量？」、「这个错误发生的根本原因是什么？」。通过引导 AI 进行逐步推理 或概念阐释，我们可以更深入地理解技术背后的原理、设计哲学和最佳实践，从而构建更准确、稳固的心智模型。
- 从「知其然」到「知其所以然」的转变，是区分普通开发和资深专家的关键。通过 AI 辅助深化理解，我们能够更快地掌握技术的精髓，提升独立解决复杂问题的能力，并做出更明智的技术决策。

3.3 实践示例

将「向 AI 学习」融入实践，意味着采取一系列主动的认知行为：

将 AI 作为首要信息源: 在遇到不熟悉的技术术语、API 用法或编程范式时，优先向 AI 发起探询式提问，利用其快速响应和整合信息的能力。
利用 AI 进行方案比较分析: 要求 AI 对同一问题提供多种解决方案（例如，使用不同的算法、库或设计模式实现同一功能），并明确要求其分析各自的优缺点、适用场景和性能权衡，以此培养自身的评估能力和决策水平。
代码考古与模式识别: 仔细研究 AI 生成的代码，特别是其中包含自己不熟悉或感觉「新颖」的语法、库调用或设计结构的部分。将其视为学习地道用法 或高级技巧 的机会。
追问「为什么」——寻求解释与论证: 不满足于 AI 给出的答案，持续追问其生成逻辑、推荐依据或诊断原理。例如，「请解释你为什么选择在这里使用异步处理？」或「这个错误信息背后可能涉及哪些系统组件的交互？」
利用 AI 进行知识重构与整合: 在学习一个新领域后，可以要求 AI 帮助梳理知识体系、生成概念图、总结关键要点或创建速查表，利用 AI 的结构化能力巩固和组织所学知识。

「向 AI 学习」是一种将人机交互从单纯的任务执行提升为持续认知增强过程的关键思维模式。它要求开发者以主动、探究、批判的态度，将 AI 视为一个永不疲倦、知识渊博的学习伙伴。

通过有意识地利用 AI 的信息整合、多样化方案生成和解释能力，我们可以显著加速学习进程、拓宽技术视野、深化原理理解，最终在快速变化的技术环境中保持领先地位，实现个人能力的持续进化和增值。这不仅关乎技能提升，更关乎构建一种面向未来的、与智能共生的学习生态。

4. 构建「人机协同」的复合思维框架

构建「人机协同」的复合思维框架是驾驭复杂性的智能协作新范式。

4.1 核心内涵：超越工具使用，构建结构化的智能协作体系

构建「人机协同」的复合思维框架，并非简单地倡导与 AI 工具互动，而是旨在建立一套系统化、结构化、且动态适应的思维与行动模式，以应对日益复杂的开发任务和决策场景。

其核心前提是深刻认识到当前 AI（尤其是大型模型）与人类智能的互补性：AI 在处理大规模数据、识别模式、执行标准化、高通量任务方面展现出超凡能力；而人类则在理解模糊性、进行深度推理、运用常识与领域知识、把握上下文、进行价值判断、承担伦理责任以及处理非结构化、创新性问题方面拥有不可替代的优势。

因此，该框架的目标是设计并实践一种能够最大化人机双方优势、规避各自短板的协同工作体系，确保在 AI 深度参与的背景下，依然能高效、高质量、负责任地达成目标。

4.2 框架三大支柱

4.2.1 问题拆解能力

问题拆解能力是指将模糊意图转化为可执行智能任务。

这是人机高效协同的关键起点与接口。面对诸如「优化用户体验」或「构建一个新的推荐系统」这类高层次、往往带有歧义的业务需求时，我们必须运用深刻的领域理解、系统分析能力和逻辑思维，将其层层剖析、具体化，转化为一系列边界清晰、输入输出明确、AI 模型能够理解并着手处理的子任务。这个过程不仅是对复杂性的管理，更是将我们的抽象智慧「编译」成机器可执行指令的关键步骤。

这一能力的意义在于有效弥合人机之间的认知鸿沟。精确的子任务定义能够显著提升 AI 工具的应用效率和产出质量，避免因指令模糊导致的无效计算或结果偏差。同时，良好的问题拆解使得大型复杂项目变得可管理、可追踪、可并行化，开发者可以策略性地将某些定义良好的子任务（如数据清洗、特定算法实现、API 接口生成）委托给 AI，从而将自身精力聚焦于更高层次的架构设计、核心逻辑创新和跨模块集成上，实现整体研发效能的倍增。

实践中，这意味着我们需要像一位经验丰富的项目经理或系统架构师那样思考。例如，将「构建推荐系统”」解为：用户行为数据收集与清洗（可部分利用 AI）、特征工程（人机结合，AI 提取初步特征，人筛选优化）、候选集生成（利用 AI 实现多种召回策略，如协同过滤、内容相似度）、排序模型训练（利用 AI 平台进行模型选择与调优，人设定评估指标与业务目标）、A/B 测试框架搭建（AI 生成基础代码，人设计实验方案）以及最终效果评估与迭代（人主导分析，AI 辅助数据可视化）。每一步都明确了目标、输入、预期输出及人机角色，构成了协同的基础。

4.2.2 批判性验证意识

批判性验证意识是确保人机协同成果安全、可靠、负责任的核心保障。

鉴于当前 AI（尤其是生成式模型）固有的「幻觉」、潜在偏见、知识局限性以及对上下文理解的不完美性，其输出的内容——无论是代码片段、设计文档、测试用例还是分析报告——都绝不能被视为绝对真理而直接采纳。我们必须内化一种 「默认不信任，必须验证」的专业态度，将自己定位为 AI 产出的最终质量守门人。

这种意识要求我们运用自身的专业知识、逻辑推理能力、测试技能和行业最佳实践，对 AI 的「贡献」进行全面、深入、多维度的审视。这不仅包括检查功能是否正确、代码是否高效，更要评估其安全性（是否存在漏洞）、可维护性（是否易于理解和修改）、合规性（是否符合规范标准）、鲁棒性（边界情况处理如何）以及是否存在潜在的伦理风险或偏见。缺乏严格验证的盲目依赖，可能引入难以察觉的技术债、安全后门，甚至导致系统性失败，其后果远超 AI 带来的效率提升。

在实践层面，这意味着一套系统化的验证流程。例如，对 AI 生成的代码，需进行严格的 Code Review、单元测试、集成测试、静态代码分析、安全扫描和性能基准测试；对 AI 提供的技术方案，要评估其长期影响、可扩展性及与现有系统的兼容性；对 AI 生成的分析报告，需核查数据来源、验证关键论断、审视逻辑链条的完整性与合理性。这种批判性验证不仅是技术行为，更是我们专业精神和责任担当的体现，是构建可信赖 AI 应用的基石。

4.2.3 动态协作模式

动态协作模式强调人机协同并非固定模板，而是一种需要根据具体情境灵活调整的交互策略。

我们需要具备敏锐的情境感知能力和判断力，根据任务的性质（如标准化 vs. 创新性）、复杂度、风险等级、所需创造力程度、可用 AI 工具的能力边界以及时间限制等因素，动态地选择最合适的人机角色分配和互动方式。这要求我们对自身优势和 AI 能力有清晰认知，知道何时应该由人主导，何时可以放手让 AI 发挥，何时需要紧密的人机迭代。

这种动态调整的战略价值在于实现整体效能与质量的最优平衡。在处理常规、重复性高的任务时，可以采用「AI 辅助执行」模式，最大化效率；在面对需要深度分析和复杂决策的问题时，则切换到「AI 辅助决策」模式，利用 AI 的信息处理能力辅助人类判断；对于需要高度创新和战略规划的任务，则采用「人类主导 + AI 执行」或「探索性伙伴关系」模式，确保人类的创造力和智慧在关键环节发挥主导作用，同时利用 AI 加速探索和实现过程。这种灵活性使得团队能够更有效地配置资源，更好地管理风险，并更具弹性地应对各种挑战。

实践中，我们需要掌握一个协作模式，并学会在其间自如切换。例如，编写单元测试，可能初期让 AI 大量生成（AI 辅助执行），然后由人进行细致审查和补充边缘案例（批判性验证）；设计新功能架构时，可能先由人提出核心思路和约束，然后让 AI 提供几种备选方案及其优劣分析（AI 辅助决策），最终由人拍板并指导 AI 生成部分实现代码（人类主导 + AI 执行）；探索一个全新的技术领域时，则可能与 AI 进行反复对话、头脑风暴，共同迭代想法（探索性伙伴关系）。熟练掌握并运用这些动态模式，是我们从「AI 使用者」进化为「AI 协奏者」的关键标志。

构建「人机协同」的复合思维框架，是我们在 AI 时代实现能力跃迁和价值重塑的关键。它要求我们超越简单的工具使用者角色，成为一个能够战略性地分解问题、批判性地验证结果、并动态地调整协作模式的智能系统指挥者和设计者。

掌握这一框架，意味着能够有效地驾驭 AI 的力量，将其融入到创造性的、高质量的、负责任的价值创造过程中，从而在人机共生的未来中占据核心地位。这不仅是一种方法论，更是一种面向未来的核心素养和战略智慧。

AI 编程时代并非要取代程序员，而是要求程序员进化。我们需要从纯粹的代码编写者，转变为更高级的思考者、设计者、协作者、验证者和创新者。思维层面需要变得更宏观、更具批判性、更灵活、更关注价值创造，并始终保持学习和适应的心态。

以上。

关于 AI 解决问题能力的思考

admin — Sat, 05 Apr 2025 02:01:05 +0000

我们一直有个想法，让 AI 能自动帮我们完成我们想要做的事情，让自动驾驶，自动写文章，自动做饭，自动操作设备，自动……

随着 AI 的发展，这个想法越来越接近现实，但是还没有实现。

大型语言模型已经具备了强大的知识掌握能力和语言表达能力，能够进行复杂的对话、代码生成、逻辑推理，甚至模拟某种程度的「思考过程」。但现实是，从「能说会道」到「能完成任务」之间，还有一段不小的距离。

我们不妨换个角度想一想：当我们让一个人类来完成一项任务时，我们通常会先给出一个大致的目标，然后逐步明确问题的边界、操作的步骤、可用的工具以及判断结果是否合格的标准。

这个过程，本质上就是在界定问题范围。而问题范围的界定程度，直接决定了完成任务的难易程度。

举个例子：

如果你让一个人「帮我查一下明天的天气」，这个问题的边界非常清晰：地点、时间、数据源、输出格式都相对明确。
但如果你说：「帮我设计一个新产品并提出完整的商业策略」，这个任务的边界就非常模糊：用户是谁？目标市场在哪里？预算是多少？成功的标准是什么？每个维度都可能引出一连串子问题。

同样的道理也适用于 AI。当前的 LLM 和 Agent 系统，在处理边界清晰的问题时表现良好，比如问答、摘要、代码填空等。但一旦任务的边界开始模糊、动态、依赖外部反馈，AI 的表现就会迅速下降。

我们可以将任务的难度，理解为 AI 需要「摸清楚问题边界」的程度：

边界清晰：问题的输入、输出、规则都明确，AI 可以像填空题一样一步步推出来。这类任务是目前AI的强项。
边界部分明确：有一定规则和目标，但需要自己补充部分前提或假设，比如“帮我写一段支持用户登录的代码”，AI 需要决定使用什么框架、是否带界面等等。
边界高度不确定：如「帮我规划一次创业项目」，AI 需要从目标澄清开始，到路径选择、资源调度、自我评估等多个层面进行处理，这时候它往往会陷入混乱。

换句话说，问题边界越模糊，AI 所要面对的「可能性范围」就越大。 如果不加限制，它就像在一片完全未知的森林里找路，既不知道出口在哪，也不知道有没有陷阱。于是它要么乱走一通，要么干脆原地画圈，给出一些看似合理却走不通的「方案」。

人类面对复杂或模糊的问题时，常常也不是立刻给出答案，而是先界定问题范围：

这个问题的关键变量是什么？
我需要哪些信息才能做出决策？
能不能先试着完成一个最小版本，看看方向是否正确？

这种思考方式其实是一种认知上的「范围压缩」能力，目的是在面对信息不完备或目标不清晰时，先把问题压缩到一个可以行动的范围，再逐步展开。

相比之下，当前的 LLM 与 Agent 系统，即便具备了强大的生成能力和任务执行能力，在主动界定问题范围上，仍显得笨拙甚至「无意识」。

常见的三个表现：

缺乏信息优先级判断能力：LLM 接收到一个模糊任务时，往往无法判断哪些信息是「必须现在明确」的，哪些可以「先搁置再处理」。它通常会试图一次性填满所有空白，而不是按优先级逐步推进。
不具备「最小可行路径」意识：在面对一个复杂任务时，LLM 更倾向于直接生成一个看似完整的解决方案（例如一个功能齐全的系统架构或一篇结构完整的长文），而不是像人一样，先试着完成一个最小可行版本（MVP），再逐步扩展。
无法识别自己的「知识盲区」：更关键的是，LLM 并不知道自己不知道。它不会像人那样产生「这个问题我不确定，我需要求证」的元认知反应，而是继续生成看似合理但实则无效甚至自相矛盾的内容。这种「自信且错误」的输出在真实任务中极具风险。

新的 Agent 架构正在尝试解决这一问题。这类系统强调：

多阶段任务拆解：将一个复杂任务拆成多个阶段，每个阶段都有明确的子目标与预期输出；
反思与自检机制：在生成每一步结果后，模型会对其进行「自我评估」，判断是否合理、是否遗漏、是否需要重试；
信息明确性评估：模型会尝试识别「哪些信息还不足以支持下一步推理」，并主动提出请求或假设补全；
动态路径调整能力：在发现路径错误时，能够中止当前链条，回退到上一步重新规划，而不是「硬着头皮走下去」。

这些能力构成了模型的「思维闭环」，让其在某种意义上具备了「界定问题范围」的雏形。

在真实世界中，任务从来不是开门见山、结构清晰的：

用户可能只给出一个模糊的目标（如「帮我设计一个商业模式」）；
过程中会出现信息缺失、中断、反馈变化；
执行中需要不断判断「我走的方向是否还正确」。

要应对这些情况，AI 不仅需要处理信息的能力，更需要处理「信息不足」时的自我调节能力。

这个问题的研究，已经引起了学术界的广泛关注。有一些观点：：

草图策略：让 AI 在面临复杂问题时，不再一次性给出答案，而是先生成多条解决思路的「草图」，再将其分解为子任务，逐步执行、评估、修正。这种方式的核心价值在于：先建立多个「问题理解的版本」，再逐步收敛。
「树搜索」+「奖励驱动」。让 AI 在面对不确定任务时，能够像爬山一样，不断生成多个路径，并根据「每一步的效果」来评估是否继续深入。这种「试探 + 筛选」的方式，帮助模型更加高效地界定问题边界，从而避免陷入无效探索。
仅作为助手：让 AI 作为辅助的思维工具，用于生成备选方案、补全缺失要素、解释已有路径等。

回到我们当前，作为一个 AI 的使用者，我们能做什么呢？

提出更好的问题：我们可以通过更精准的问题表述来帮助 AI 更好地工作。这意味着在提问时，不仅要描述目标，还要主动界定边界条件：具体背景是什么？可用资源有哪些？有哪些限制条件？预期的输出格式是什么？这种前置界定能显著提高 AI 的输出质量。同时，我们也可以采用渐进式引导的方式，先让 AI 完成一个小范围的子任务，验证其理解是否正确，再逐步扩展到更复杂的任务范围，形成一种「小步快跑」的合作模式。
构建人机协作的闭环流程：有效的人机协作应该是一个闭环流程，而非单向输入输出。这意味着用户需要对AI的输出进行及时评估，提供明确的反馈，指出哪些方向是正确的，哪些需要调整，哪些问题仍然存在。通过这种持续的反馈修正机制，AI 能够逐步调整其对问题边界的理解。特别是对于复杂任务，我们可以建立人在回路的工作模式，即AI负责生成备选方案和细节执行，人类负责决策方向和质量把关，形成优势互补的协作关系。
适应 AI 的认知局限性：理解并适应AI的认知局限，是高效使用 AI 的关键。目前的 AI 在处理抽象概念、因果关系和长期规划时仍有明显短板。因此，我们可以主动将复杂任务拆解为一系列明确边界的子问题，让 AI 在其擅长的领域发挥作用。同时，对于涉及价值判断、创新突破或高风险决策的任务，我们需要保持审慎态度，将AI视为辅助工具而非决策者。认识到这一点，有助于我们在期待与现实之间找到平衡点，避免对 AI 能力的过度期待或低估。

以 AI 编程为例，当前比较好的实践是：

经验先行（包括自身经验或行业最佳实践），预先为 AI 构建整体架构，并将复杂任务拆解为一系列边界清晰、认知负载适中的子任务。每一个子任务都应在模型的能力边界之内，既能被准确理解和执行，又能稳步推动整体目标的进展，避免陷入回溯式的反复试错与路径偏离。

以上。

如何面对「AI 焦虑」

admin — Sat, 29 Mar 2025 00:01:37 +0000

昨天看到网友 yuekun 发的一个消息，大概如下：

★我决定“拉黑”Al 了。。。

AI变化太他* 快了，这两天不断被 Al新闻洗脑越看越焦虑，越焦虑越想看，我还在追求那该死的确定性

我决定拉黑 AI 内容了，因为这些都他* 是【快速贬值】的内容之所以说是快速贬值因为!

1个星期后没人记得今天发生了什么别说一个星期，3天前AI发生了什么还人记得吗?

能有 AI 焦虑的已经是比较优秀的人了，已经走在大家的前面了。

最近这几年，大家的工作，生活中已经有越来越多的 AI 在进入。

工作上，同事已经开始用豆包/KIMI/灵宝/DeepSeek 写方案、改文案、写代码，效率惊人；
网络上，AI 绘画、AI 剪辑、AI 写作层出不穷，创意产业正在被改写；
朋友圈里，已经有人靠「AI+副业」赚到了第一桶金；

可能还会有这样的想法：「我会不会被 AI 取代？」、「我还能干什么？」、「未来还有我的位置吗？」

如果你有这样的焦虑感，放心，你不是一个人！

这一轮 AI 革命，以前所未有的速度冲击着我们的认知、工作与生活。今天这篇文章，我们不谈高深的技术原理，也不喊口号。我们只聊一个问题：

★面对 AI 焦虑，我们该怎么办？

什么是「AI 焦虑」？

「AI 焦虑」是一种新型的社会心理状态。它并不是因为 AI 本身带来了什么直接伤害，而是因为：

不确定感——不知道 AI 会发展到什么程度；人类天生害怕未知。AI技术发展的不可预测性让我们感到失控和无力。我们无法确切预见五年后的工作环境会是什么样子，这种不确定性是焦虑的主要来源。
被替代感——担心自己所掌握的技能很快就会被机器超越；许多人将自己的价值与工作紧密联系在一起。当AI挑战我们的专业领域，也就挑战了我们的自我认同。「如果AI能做得比我好，那我的价值在哪里？」这个问题困扰着大家。
无力感——感到自己跟不上技术变化的节奏；对于不熟悉 AI 技术的人来说，理解和适应这些变化尤为困难。这种知识差距加剧了焦虑感，让人觉得自己被时代抛弃。
落后感——看到别人借助 AI 成长飞快，自己却无从下手。

换句话说，AI 焦虑，其实是技术飞跃带来的认知落差，也是时代变化下的身份危机。

这并不是第一次。

蒸汽机时代，工人们担心机器取代人力；
电气化时代，马车夫开始失业；
互联网时代，传统媒体人不得不转型自媒体；
今天，轮到白领与知识工作者，直面 AI 的挑战。

每一次技术革命，都伴随着阵痛、焦虑与重新定位。

AI 焦虑，不是「你不够努力」，而是你活在一个剧烈变动的时代。

AI 到底会不会「抢走我们饭碗」？

我们先来看一个事实：

★AI 不会取代你，但会取代不会用 AI 的你。

这句话看似鸡汤，实则是现实。AI 的出现，并不是「人类 vs 机器」的对抗，它更像是一场「人类 + 机器」的协作革命。它和人类在当前还存在 「工具理性」到「价值理性」的鸿沟

AI的绝对优势领域

超大规模信息处理
• 数据清洗与结构化：可实时解析百万级非结构化数据（如电商评论情感分析、医疗影像归档）
• 概率推演引擎：基于历史数据预测股票波动率（误差率<1.2%）、疫情传播模型构建
• 标准化流程执行：银行反洗钱系统日均扫描2000万笔交易，准确率99.97%
确定性规则下的精准输出
• 代码生成：Cursor 辅助完成超6 0% 的函数级编程任务
• 模板化内容生产：1 分钟生成符合 AP 格式的上市公司财报摘要
• 工业级重复操作：汽车焊接机器人连续工作 2000 小时无误差
多模态感知增强
• 跨媒介转化：将设计师手稿自动转为Blender三维模型
• 环境适应性处理：会议录音实时降噪并生成带章节标记的文本纪要

AI的认知天花板

情感价值创造
• 无法真正理解《红楼梦》中林黛玉「冷月葬花魂」的悲剧美学意象
• 心理咨询时仅能套用 DSM-5 标准，无法捕捉来访者微表情中的绝望
非确定性系统整合
• 制定企业转型战略时，无法平衡股东诉求、员工情绪与政策风险
• 设计城市更新方案时，难以协调文物保护与商业开发的文化冲突
元认知突破创新
• 可生成 100 种咖啡包装设计，但无法像原研哉通过「无印良品」重新定义消费哲学
• 能复现爱因斯坦相对论公式，但无法诞生「时空弯曲」的颠覆性假设
伦理情境判断
• 面对自动驾驶「电车难题」时，算法无法承载不同文明对生命价值的权重差异
• 处理医疗资源分配时，缺乏对弱势群体生存权的道德勇气

换句话说：

★「AI是卓越的『执行者』，人类是不可替代的『决策者』」

执行维度：海量数据清洗、模式化输出、物理规则明确的任务

决策维度：情感共鸣、复杂系统博弈、伦理价值抉择、范式革命创新

因此，AI 会替代一部分工作，但也会催生大量新的岗位，比如：

Prompt 工程师（AI 提示词设计师）；
AI 教练（帮助企业训练专属 AI）；
AI 辅助创作者（人机协作）；
AI 伦理与治理专家；
数据标注、清洗、优化人员……

过去 3 年，AI 技术已经催生出许多新的职业岗位，这一趋势还在加速中。

为什么你会特别焦虑？

有这样一个现象：

越是知识密集型、创意型的行业，从业者越容易感到 AI 焦虑。

为什么？

因为大家原本以为，AI 最难的是「脑力劳动」，结果没想到 AI 写得比人快、画得比人好、剪得比人准。

一夜之间，原本「吃香」的技能变成了「谁都可以」的工具。

套在开发逻辑上，有人称之为「技术平权」

于是，很多人开始怀疑：

“我的核心竞争力还存在吗？”
“我学的东西还有价值吗？”
“再学也赶不上 AI 的更新速度啊……”

这里有一个心理机制很关键：

★AI 打破了我们对「专业性」的想象。

过去，一个人要成为专业人士，可能需要 10 年学习与积累。但今天，AI 几秒钟就能模仿出一个专业人士的成果。这种落差感，带来的不只是焦虑，更是身份的崩塌感。

但我们必须意识到：

★AI 是工具，不是目的。你不是在输给 AI，而是输给了不会使用 AI 的自己。

如何正面应对 AI 焦虑？

说了这么多，我们终于要聊关键部分：应对之道。

1. 从抗拒到接纳：停止「逃避感」

很多人焦虑的根源在于：

“我不想碰 AI，它太复杂”；
“我再怎么学，也学不过 AI”；
“我现在还没空，等将来再说”。

但事实是：你越晚接触 AI，门槛就越高。

AI 的学习曲线并不陡峭，但它在快速演进。你今天花 5 小时学习 ChatGPT，可能比你明年花 50 小时还更有效。

第一步，是接纳它的存在，就像你曾经接纳智能手机、接纳微信、接纳短视频一样。

2. 从被动到主动：开始「有手感」

我们不需要成为 AI 专家，但我们必须成为 AI 用户。

从今天起：

用豆包/KIMI/元宝/DeepSeek 帮你写一封邮件；
用 Midjourney 或 DALL·E 画一张图；
用 Notion AI/腾讯会议整理一份会议纪要；
用 AI 工具帮你润色文章、翻译文档……

这样，就会发现：AI 不是来代替你，而是来放大你。

它让我们的时间更值钱，让我们的创意更高效，让我们从「执行者」变成「指挥者」。

3. 从焦虑到学习：构建「成长感」

AI 不会终结人类的价值，但它一定会倒逼人类进化认知结构。

我们要学的，不是「如何跟 AI 竞争」，而是：

如何提问更好；
如何判断 AI 的输出质量和正确性；
如何将 AI 的结果转化为自己的成果；
如何创造 AI 做不到的价值。

这需要我们具备：

批判性思维；
多元化视角；
系统化学习能力；
情绪管理与人际沟通能力。

这些，正是人类在 AI 时代最宝贵的「护城河」。

开启人机协作时代

除了态度上的转变，我们还需要在实践中探索「人+AI」的协作方式。以下三点，或许可以提供一些启发：

1. 能力分层：让 AI 做擅长的，人类做关键的

在很多工作场景中，可以将整个业务流程划分为：

数据处理层：交给 AI，例如自动分类、信息提取、报告生成；
价值判断层：由人类主导，比如战略决策、情感共鸣、道德评估。

举个例子：在财务行业，AI 可以自动生成报表、识别异常交易，但最终的审计判断，仍需要有经验的会计师来把关。

2. 思维互补：用 AI 拓宽选择空间，人类负责价值筛选

AI 的计算能力远超人类，它可以在几秒钟内生成上百个方案。例如：

市场营销人员可以用 AI 生成 100 个广告标题；
视频创作者可以请 AI 写出 50 个脚本大纲；
产品经理可以让 AI 提出多个功能迭代建议。

但最终，哪些方案最符合用户心理？哪些创意最具文化共鸣？这仍然需要人类的大脑与直觉来判断。这种模式，本质上是：

★AI 提供「宽度」，人类决定「深度」。

3. 伦理防火墙：在关键场景中，设置人类「最后一环」

AI 的效率令人惊叹，但它不具备真正的道德意识。在一些涉及人类生命、法律、公正的场景中，必须设置「人类兜底机制」。

比如：

在医疗诊断中，AI 可以辅助分析影像、预测病灶，但最终诊断结果应由医生确认；
在司法量刑中，AI 可辅助评估风险与量刑建议，但量刑决定必须由法官裁定；
在金融风控中，AI 可快速筛查欺诈行为，但冻结账户需人工复核。

这种「人类最终确认环节」，就是我们在 AI 时代构筑的伦理防火墙。

通过这些实践启示我们可以看到，真正的 AI 时代，并不是「人退 AI 进」，而是人类与 AI 分工协作、优势互补、共同进化。

你不需要变成一台机器，但你需要学会如何驾驭一台机器。

未来的你，会感谢现在行动的自己

我们生活在一个剧变的时代。AI 是洪流，既可能将我们卷走，也可以成为我们前进的船桨。

我们可能无法阻止技术的浪潮，但我们可以选择：

成为浪潮的受害者，还是浪潮的驾驭者？
被动等待行业淘汰，还是主动创造新机会？
沉浸在焦虑中，还是走出第一步？

未来的世界，不是「AI 取代人类」，而是 人与 AI 共舞。

要做的，不是跟 AI 比赛，而是学会与 AI 搭档。

当我们真正掌握 AI，当我们将它变成自己能力的延伸，就会发现：

★焦虑，是成长前夜的灯光。

最后，送君一段话：

★「真正的焦虑，不是来自技术，而是来自我们与变化之间的距离。
AI 不是终点，它是新的起点。
与其害怕未来，不如成为未来的一部分。」

以上。

AI 时代研发同学的必备软技能：从「写好代码」到「终结问题」的进化指南

admin — Sat, 01 Feb 2025 14:08:24 +0000

当 Cursor/Windsurf 为你生成代码片段，ChatGPT/DeepSeek 为你优化技术文档，Midjourney 为你绘制精美草图，你是否也曾思考过：
「在这个 AI 时代，你工作的核心竞争力究竟是什么？」

过去，技术硬实力是研发同学的核心武器，但今天，AI 工具正在以惊人的速度让这些技能「平民化」：

代码量产：AI 几秒钟生成数百行代码；
自动调优：AI 自主优化算法参数，超越人类水平；
全栈覆盖：从前端到后端，从 DevOps 到数据分析，AI 工具无处不在。

然而，AI 的快速普及并不是威胁，而是机会。未来最优秀的研发，不再只是写代码的人，而是能够驾驭 AI，解决复杂问题、创造价值的人。而这一切的基础，就在于软技能的升级。

1. AI 时代的「新研发」画像：从执行到创造的转型

AI 时代对研发同学的要求正在发生质的变化。你需要的不仅是工具使用能力，更是掌握以下三大能力的思维跃迁：

1.1 问题定义力：从「如何做」到「做什么」

AI 工具可以为你提供实现方案，但它无法回答「我们到底要解决什么问题」。能精准定义问题的人，才能引领 AI 高效运转。

举例：用户反馈「系统太慢」，真正的瓶颈可能并不是代码性能，而是业务逻辑过于复杂，或者数据库架构不合理。
关键问题：AI 可以帮你解决「已知问题」，但只有你能找到「未知问题」。

建议实践：

在接到需求时，不急于动手写代码，而是花 30% 的时间明确核心目标。
使用「5 WHY」拆解问题，找到真正的根因。

以某电商大促系统卡顿的问题为例：

当用户反馈「下单页面卡顿」时，我们需要问：

第一层追问：卡顿发生在点击下单按钮时？还是页面加载时？（发生在哪里？）

第二层追问：只有大促期间出现？普通时段正常？（发生在什么时候？）

第三层拆解：日志显示数据库查询耗时暴增，但真的是 SQL 问题吗？（多问一次）

最终发现根本原因是优惠券叠加计算逻辑：当用户同时使用店铺券、平台券、满减券时，业务逻辑循环嵌套导致指数级复杂度上升。

用「5 WHY」法拆解问题：
比如面对「系统太慢」的反馈，可以问：
1. 为什么太慢？ -> 数据查询耗时过长。
2. 为什么查询耗时过长？ -> 数据库没有索引。
3. 为什么没有索引？ -> 设计时没有考虑这个场景。
  通过层层追问，找到问题的根因，而不是停留在表面。

多站在用户视角思考：系统性能对用户真正的影响是什么？是加载时间？响应速度？还是页面卡顿？明确目标后再行动。

1.2 跨领域协作力：从「技术孤岛」到「多维桥梁」

研发同学往往被视为技术专家，但在 AI 时代，研发工作正在从「单一技术领域」走向「跨领域协作」,能够在技术与业务、技术与设计之间建立桥梁的人更具影响力。

AI 工具的普及，让技术不再是只有工程师能看懂的「黑箱」，它正在成为每个部门都能触及的工具。这意味着，研发者的作用不再是单纯的技术专家，而是跨部门桥梁。

场景 1：向业务团队解释 AI 模型的局限性，例如：大模型生成的预测结果为何在特定场景无法应用。
场景 2：与设计师协作，优化用户体验，而不是单纯关注技术实现。

建议实践：

多关注非技术领域的语言和逻辑，例如：用「用户故事」代替技术术语。
在技术方案中，明确描述其对业务的价值和风险。

举个例子：从「技术术语」到「用户故事」假设业务部门提出一个需求：「我们需要一个 AI 模型来预测用户流失率。」

如果你直接给出技术方案，比如「我们用随机森林算法和 LSTM 模型」，业务团队可能一头雾水，也无法判断你的方案是否符合实际需求。
更好的方式是转化为业务语言，比如：「我们会用 AI 模型预测哪些用户可能流失，这样可以提醒销售团队提前联系，并减少用户流失。」

这种「跨领域翻译能力」不仅能让技术方案更落地，还能让你在团队中更具影响力。

那么，如何提升跨领域协作力？

学习对方的语言和逻辑：比如了解产品经理常用的「用户故事」格式，用场景化的方式描述技术方案。
- 比如：用户故事可以是「作为一名用户，我希望系统能在 2 秒内加载完成，这样我就不会失去耐心」。
明确技术对业务的价值：在提交技术方案时，补充说明「这个功能可以提升 xx% 的用户体验，节约 xx% 的成本」。

在 AI 时代，研发者不仅是技术的推动者，更是沟通技术与业务、技术与设计的桥梁。谁能打通这些边界，谁就掌握了更多主动权。

1.3 批判性思维：从「接受答案」到「验证答案」

AI 工具给出的代码、方案并非总是可靠。研发者必须具备质疑与验证的能力，避免高效地犯错。

AI 提供的代码是否安全？ Cursor 生成的代码可能存在漏洞。
AI 生成的方案是否符合需求场景？ 自动化工具可能忽略了业务逻辑中的特殊条件。

建议实践：

为你的 AI 工作流创建「质检清单」，例如：性能测试、安全检查、业务逻辑验证等。
从 AI 输出中学习，而不是无脑接受，学习其思路和编码的方式等等。

如何培养批判性思维？

为 AI 创建「质检清单」：
每次接受 AI 的输出前，进行以下检查：
1. 技术层面：代码是否经过边界测试？是否存在安全隐患？
2. 业务层面：输出结果是否符合实际场景？是否考虑了用户行为习惯？
3. 合规层面：生成内容是否符合公司政策或行业法规？
从失败案例中学习：多分析 AI 工具失败的案例，理解 AI 的局限性和潜在风险。比如，研究某些场景下的 AI 偏见问题，避免类似错误。

2. AI 时代的软技能到底有多重要？

如果技术硬实力是「上限」，软技能就是「下限」。AI 可以让所有人起点更高，但也会放大研发者的短板：

不会定义问题的人，会被工具束缚在错误的方向上。
缺乏沟通能力的人，会在跨部门协作中失去对话权。
思维固化的人，无法适应 AI 工具带来的工作流变化。

2.1 生存指南

用「 CTO 思维」拆需求，接到任务时先问三连：
1. 这个需求背后的商业目标是什么？（比如提升转化率？降低客诉？）
2. 如果只能用一句话描述成功标准，应该是什么？
3. 现有数据中哪些指标暗示了真正的问题？（如支付环节跳出率>80%）
给 AI 加「导航仪」，向 AI 提问时避免开放式指令，而是结构化引导：
- 错误示范：”优化系统性能”
- 正确姿势：”当前订单提交平均耗时 2.3 秒（ APM 数据），在保证 100% 数据一致性的前提下，请提供三种不同成本预算的优化方案”

2.2 话术 – 「见人说人话，见鬼说鬼话」

对老板：「投入 1 个月开发时间，能防止明年 618 大促期间服务器崩溃的风险」，关注成本和产出
对运营：「这个接口延迟降低1秒，首页UV转化率能提升0.7%（附 A/B 测试数据）」，关注指标
对客服：「新系统上线后，用户咨询’物流进度’的话术可以减少 3 次点击步骤」，关注对于其工作的影响

2.3 软技能的红利公式

AI 时代个人价值 = （技术硬实力 × 软技能系数）^ AI 工具适配度

系数破局点：

会用AI写代码 → 硬实力基准线（人人可达）
能判断该让 AI 写什么代码 → 软技能决胜区（稀缺资源）

那些软技能出色的研发同学，能够借助 AI 实现飞跃式成长，成为团队中的关键角色。

3. 打造你的「AI 时代工具箱」

软技能的提升不是一朝一夕的事，但可以通过系统化的方法论，逐步打造适应 AI 时代的「工具箱」。

3.1 练习「问题之上」的思维：从执行者到问题定义者

AI 工具可以帮助你高效地执行任务，但它无法告诉你「最重要的问题是什么」。在 AI 时代（也不仅仅是 AI 时代），研发需要从全局视角思考问题的本质：为什么做，而不仅仅是怎么做。

3.1.1 如何练习「问题之上」的思维？

每天主动问自己三个「为什么」，从执行层面上升到战略层面：

为什么这个功能重要？：真实案例：某研发团队接到任务，优化一个页面加载速度。当他们问「为什么优化加载速度重要？」时，发现问题的本质并不在于技术性能，而是用户期望在关键时刻快速获取信息。最终，他们通过简化页面结构和聚焦核心功能，比单纯优化代码更高效地解决了问题。
为什么用户需要这个解决方案？：从用户视角出发，挖掘需求背后的真实动机。例如，一款 AI 推荐系统的研发团队意识到，用户并不需要复杂的算法结果，而是想快速找到符合场景的解决方案。于是，他们优化了推荐理由的呈现方式，让用户更容易理解和采纳推荐结果。
如果资源有限，如何找到最优解？：设想一个极限场景：如果只能用 50% 的时间或资源完成任务，你会如何取舍？这种思考方式能帮助你聚焦核心问题，避免陷入无意义的细节优化中。

3.1.2 成为「破界思考者」的 4 层跃迁法

人类擅长于发现隐藏在表象下的真问题。4 层跃迁法帮助突破思维惯性：

▌认知框架

第1层：需求表象：「业务方要求 3 天上线一个推荐算法」
第2层：利益相关者分析：使用 RACI 矩阵梳理：谁决策/执行/被影响
第3层：系统动力学推演：用因果回路图分析技术方案对用户体验/后端负载/商业指标的连锁影响
第4层：第一性原理拆解：追问：用户点击转化率低的根本原因是算法不准？还是商品信息呈现方式问题？

▌实战工具包

丰田「5Why分析法」进阶版：

现象：用户投诉支付失败率上升  
Why 1 ▶ 接口超时？  
Why 2 ▶ 第三方支付网关响应慢？  
Why 3 ▶ 未适配银行新加密协议？  
Why 4 ▶ 运维监控策略未覆盖合作方变更？  
Why 5 ▶ 跨部门信息同步机制缺失？

MIT系统思考工具箱：

记住：AI 再强大，也需要你来定义问题。跳脱「怎么做」的思维框架，才能成为团队中的问题定义者。

3.2 刻意提升「非技术表达」：让技术为业务赋能

技术再高深，如果让人听不懂，价值就会大打折扣。AI 时代的研发者不仅需要写得出代码，更需要讲得清技术。能用简单、直观的方式表达技术方案，既能提高跨部门协作效率，又能让你的工作成果更具说服力。

3.2.1 如何刻意练习「非技术表达」？

用一张图解释技术架构：将复杂的技术架构简化成流程图、思维导图或者用户体验图。例如，一个后端服务的高可用方案，可以用一张图展示数据流动、容错机制以及业务价值，而不是写一长段技术描述。
用「用户视角」描述技术方案的价值：比如，你正在开发一个自动化测试工具，与其说「这个工具可以减少测试时间」，不如说「这个工具可以帮助团队提前发现潜在的产品缺陷，从而减少 30% 的用户投诉」。这样的表达更容易被非技术团队接受。
用故事化的方式呈现你的方案：例如，在解释一个推荐算法时，可以说：「想象一下用户点开首页，看到的是他最喜欢的内容，这背后是我们的 AI 模型在实时分析用户行为。」这种讲故事的方式更具感染力。

3.2.2 实践工具

▌FAB 法则（Feature-Advantage-Benefit）
表达技术方案时，从功能（Feature）入手，解释优势（Advantage），最后明确带来的好处（Benefit）。
- 功能：我们的推荐算法会实时预测用户偏好。
- 优势：它能够在用户访问的第一时间推荐最相关的内容。
- 好处：提升用户粘性和点击率，从而增加转化率。

例如：

▌SCQA模型（情境-冲突-问题-答案）

[情境] 当前订单查询 API 响应时间突破 2s  
[冲突] 用户体验下滑 vs 硬件扩容成本激增  
[问题] 如何在零成本下优化性能？  
[答案] 通过 AI 预测缓存热点数据（命中率提升至 92% ）

金字塔原理实战：技术方案文档采用「结论先行+ MECE 分类」结构

记住：技术的价值必须通过清晰的表达被团队和业务部门感知，才能真正落地并创造商业价值。

3. 搭建「AI 质检工作流」：让 AI 为你所用，而不是盲目信任

AI 工具再强大，也只是工具，其输出的内容仍然可能存在问题。研发者需要对 AI 的输出保持质疑态度，并建立一套完善的质检流程，确保工具真正符合需求。

▌四阶验证框架

阶段	检查重点	工具/方法
输入层	需求理解偏差	ChatGPT 反向提问验证法
设计层	架构合理性	架构决策记录（ADR）模板
实现层	安全隐患/技术债	SonarQube+AI 代码审计
价值层	商业目标对齐度	OKR-KPI 映射矩阵

当AI工具成为标配，建立质量管控机制比盲目追求效率更重要。

4. 用 AI 「解未来」

精准定义问题，让 AI 为你服务，而不是反过来被工具左右。
跨领域协作，用技术思维解决业务问题，成为团队的桥梁。
对 AI 保持质疑，避免高效犯错，用批判性思维守住技术底线。

AI 不会淘汰研发，只会淘汰不会用 AI 的研发。当机器开始思考时，人类的智慧应该闪耀在机器停止思考的地方。

此刻的你，不妨用 0.1 秒思考：是继续做工具的操控者，还是成为驾驭 AI 的「指挥官」？这场进化游戏没有旁观席，每个技术人都已身在局中。

未来的研发工作，不再是机械地写代码，而是以技术为工具，解决问题、创造价值、推动变革。

从今天开始，思考：

我的工作是否创造了价值？
我的技能是否放大了 AI 的潜能？
我的软技能是否已跟上时代的节奏？

AI 已来，你准备好了吗？

「你认为 AI 时代最重要的软技能是什么？欢迎评论留言讨论！」

以上。

AI 大时代要懂的 2 种「编程范式」

admin — Sun, 23 Jun 2024 00:19:01 +0000

2023 年 AI 新突破导出不穷，隔两个月就会有一个爆点出来，AI 迎来了一个新的里程碑时刻。从 OpenAI 推出的 ChatGPT 到 Midjourney 发布的 V5/V6 版本，AI 在各个领域都取得了突破性的进展。随着 AI 技术的日益成熟，我们也开始思考如何更好地利用 AI 工具来提高工作效率。

到 2024 年， AI 应用、AI 配套的框架和工具如雨后春笋。

在这个 AI 大时代，有两种「编程范式」值得我们关注。为什么要打上引号呢？

因为这里所说的编程，已经不再局限于传统意义上的写代码，而是泛指利用各种工具和模型，将它们灵活组合，创造出新的应用和价值。

第一种范式是基于 ComfyUI 的编程。ComfyUI 是一个模块化的 AI 图像生成工具，它允许用户通过拖拽和连接不同的节点，轻松创建出令人惊艳的 AI 艺术作品。在 ComfyUI 上编程，你无需掌握复杂的代码知识，只需要理解每个模块的功能，并将它们以合理的方式组合在一起，就能得到理想的结果。这种直观、易用的特点，使得 ComfyUI 成为了平面设计、插画创作等领域的得力助手。

第二种范式则是基于 LangChain 的编程。与 ComfyUI 注重视觉创作不同，LangChain 的重点在于自然语言处理。通过 LangChain，开发者可以将语言模型与外部数据源相结合，快速构建功能丰富的聊天机器人、智能文档助手等应用。LangChain 提供了一系列现成的模块和接口，使得即使是非 NLP 专业的程序员，也能在短时间内上手并应用到实际项目中。从客户服务到数据分析，LangChain 正在各行各业发挥着重要作用。

相比传统的编程范式，AI 编程更加注重模块化和灵活组合。我们无需从零开始构建一个完整的系统，而是站在巨人的肩膀上，将现有的模型和工具进行拼装和优化。这种方式不仅大大降低了开发门槛，也极大地提高了开发效率。当然，AI 编程范式也并非完美无缺。对于一些需要高度定制化的场景，传统的代码编程仍然不可或缺。此外，AI 工具的使用也对开发者提出了更高的要求，需要我们对各种模型和算法有更全面的理解和把控。

接下来，简单聊一聊这两种「编程范式」，

comfyUI

ComfyUI 是一个基于 Stable Diffusion 的开源 AI 绘图工具，采用了模块化的节点式工作流设计。它通过将 Stable Diffusion 的各个组件和处理步骤抽象为独立的节点，使得用户可以通过直观的拖拽、连接操作来构建复杂的图像生成流程。

ComfyUI 解决了传统 AI 绘图工具易用性差、扩展性低的问题。其模块化设计和直观的 Web 界面大大降低了用户的使用门槛，无需深入了解底层技术细节，即可快速构建和调整工作流。同时，ComfyUI 还提供了强大的自定义节点机制，允许开发者轻松扩展新的功能和模型，使其能够适应不断发展的AI绘图领域。

ComfyUI 最初由开发者 Comfyanonymous 在 2022 年末发起，旨在提供一个简单、直观的 Stable Diffusion Web UI。早期版本实现了基本的节点类型和 Web 界面，展示了其模块化设计的优势，吸引了一批 AI 绘图爱好者的关注。

在 2023 年春夏，ComfyUI 进入了快速发展阶段。项目不断增加新的节点类型，如 ControlNet、Inpaint、Upscale等，支持更多的图像控制和后处理功能。同时，ComfyUI 引入了自定义节点机制，大大扩展了其功能和适用范围。项目也集成了更多 Stable Diffusion 衍生模型，为用户提供了更多选择。

随着用户社区的不断壮大，ComfyUI 的生态也日益丰富。社区成员积极贡献工作流、节点脚本、训练模型等资源，推动项目的发展。ComfyUI 举办了一系列社区活动，促进了用户间的交流和创作。项目代码库也迎来了更多贡献者，社区力量成为 ComfyUI 发展的重要推动力。

2023 年冬至今，ComfyUI 开始着眼于生态融合和应用拓展。项目与其他 AI 绘图工具建立了联系，支持工作流的导入导出和 API 集成。ComfyUI 也开始探索更多应用场景，如虚拟主播、游戏 mod 等，拓宽了 AI绘图的应用范围。越来越多的开发者和公司开始关注和使用 ComfyUI，其发展前景备受看好。未来，ComfyUI 将继续完善节点系统，引入更先进的 AI 技术，并加强生态建设，有望成为 AI 绘图领域的重要基础设施。

ComfyUI 中节点之间的关联是通过连接节点的输入和输出端口来实现的。每个节点都有预定义的输入和输出端口，用户可以在 UI 界面上将一个节点的输出端口连接到另一个节点的输入端口，从而建立节点之间的数据流和执行顺序。

在 ComfyUI 的后端实现中，这种节点关联是通过一个有向无环图来表示的。DAG 是一种常用的数据结构，用于描述一组节点之间的依赖关系和执行顺序。

当用户在 UI 界面上连接两个节点时，实际上是在 DAG 中添加一条边，表示数据从源节点流向目标节点。ComfyUI 会根据 DAG 的拓扑结构，确定节点的执行顺序，并在运行时将数据在节点之间传递。

ComfyUI 中节点关联有一些关键实现细节：

端口类型匹配：每个节点的输入和输出端口都有预定义的数据类型。在连接节点时，只有类型匹配的端口才能建立连接。
数据传递：当一个节点执行完毕后，它会将结果数据发送到所有连接到其输出端口的节点的输入端口。
执行调度：ComfyUI 会根据 DAG 的拓扑顺序，确定节点的执行顺序。当一个节点的所有输入数据都准备好时，该节点就可以开始执行。
并行执行：无依赖关系的节点可以并行执行，提高执行效率。ComfyUI 会自动分析 DAG，找出可以并行执行的节点。
缓存优化：对于某些计算量大的节点，ComfyUI 会缓存其计算结果，避免重复计算。当节点的输入数据没有变化时，就可以直接使用缓存的结果。

ComfyUI 通过将节点组织成 DAG 的方式，实现了节点之间的关联和数据流控制。这种设计使得用户能够以可视化的方式创建复杂的图像处理工作流，同时也为并行优化和缓存优化提供了便利。

comfyUI 中核心工作都是围绕其节点，其主要节点如下。

Text Prompt(文本提示)节点：提供文本描述，指导图像生成，输入是用户输入的文本提示如”1girl， brown hair， smile”；输出是编码后的文本向量(tokens)。几乎所有的绘图工作流都需要文本提示节点，它是指定图像内容的主要方式。
Latent Image(潜在图像)节点：表示潜在空间中的图像，可以是随机初始化的噪音，也可以来自其他节点的输出。输入是噪音参数(如seed、尺寸等)，或其他节点传递的潜在图像。输出是潜在空间中的图像表示。作为采样起点(初始噪音)或中间结果(如图像修补、图生图等)。
Sampler(采样器)节点：根据条件迭代优化潜在图像，使其解码后符合要求。输入是潜在图像、文本向量、其他条件(如 ControlNet 输出等)、采样步数、采样方法等参数。输出是优化后的潜在图像。采样是图像生成的核心，不同的采样器节点可以权衡生成质量和多样性。
ControlNet 节点：根据附加条件(如边缘、姿态、深度等)控制生成图像。输入是潜在图像、条件图(如 Canny 边缘图)、ControlNet 模型参数等。输出是融合条件控制的潜在图像。用于生成满足特定结构、布局或属性要求的图像，如人像、动漫线稿上色等。
VAE Encode(VAE编码)节点：将 RGB 图像编码为潜在空间表示。输入是 RGB 图像，如用户上传的图片。输出是潜在空间中的图像表示。用于图生图、图像修补、图像融合等需要以图像为起点的任务。
VAE Decode(VAE解码)节点：将潜在空间表示解码为 RGB 图像。输入是潜在空间中的图像表示，通常来自采样器节点。输出是 RGB 图像。用于生成最终可见的图像结果。
Upscale(放大)节点：增加图像分辨率，提高细节。输入是 RGB 图像，放大方法和倍数等参数。输出是放大后的 RGB 图像。用于生成高分辨率图像，常在VAE解码后使用。
Inpaint(图像修补)节点：根据 mask 和提示，对图像的指定区域进行编辑。输入是原始图像、mask 图像、修改区域的文本提示等。输出是修改后的图像。用于对生成图像进行局部编辑，如去除伪影、修改细节等。

除了以上常用节点，comfyUI 还有许多其他节点，如图像保存、剪裁、格式转换等，用于图像的后处理和输出。不同节点可以灵活组合，构建多种多样的绘图工作流，满足各类需求。

举个例子，一个常见的工作流是：文本提示节点 -> 潜在图像节点(初始噪音) -> ControlNet节点(添加结构条件) -> 采样器节点(优化潜在图像) -> VAE解码节点(生成RGB图像) -> 放大节点(提高分辨率) -> 图像保存节点(输出最终结果)。

如下图所示：

+-------------------+     +------------------+     +------------------+
|                   |     |                  |     |                  |
|  Load Model Node  |---->|  Text Encode Node|---->|  Latent Image Node |
|                   |     |                  |     |                  |
+-------------------+     +------------------+     +-------------------+
                                                             |
                                                             |
                                                             v
                                                   +-------------------+
                                                   |                   |
                                                   |  ControlNet Node  |
                                                   |                   |
                                                   +-------------------+
                                                             |
                                                             |
                                                             v
+------------------+     +------------------+     +------------------+
|                  |     |                  |     |                  |
|  Upscale Node    |<----|  VAE Decode Node |<----|  Sampler Node    |
|                  |     |                  |     |                  |
+------------------+     +------------------+     +------------------+
         |
         |
         v
+------------------+
|                  |
|  Output Image    |
|                  |
+------------------+

通过对节点的连接配置和参数调整，用户可以精细控制每个步骤，实现理想的 AI 绘图效果。同时，comfyUI 也鼓励用户开发和分享自定义节点，不断扩展其功能和应用领域。

在理解 ComfyUI 的原理时，其核心还是理解 SD 的原理，简单来讲是通过大模型、CLIP 和 VAE 编码器以及采样器的协同工作，将文本提示转换为特征马赛克，再通过 VAE 解码器还原成图像，从而实现基于文本描述生成图像的功能。

LangChain

什么是 LangChain？

LangChain 是一个开源的 Python 框架，旨在帮助开发者更容易地构建基于大语言模型(LLM)的应用。它提供了一系列工具和组件，可以方便地与各种 LLM 模型集成，如OpenAI GPT、Anthropic Claude、Google PaLM等，而无需从头开始构建或进行大量的微调。

LangChain 旨在简化和统一语言模型与外部数据和应用程序的集成过程。它为开发者提供了一套灵活的工具和组件，可以轻松地将 OpenAI、Hugging Face 等流行的语言模型与知识库、API 等数据源相结合，从而快速构建功能强大的自然语言处理应用，如聊天机器人、智能文档助手、问答系统等。

LangChain 解决了语言模型应用开发中的诸多痛点。在 LangChain 出现之前，开发者需要编写大量的胶水代码来处理不同模型和数据源之间的交互，这不仅耗时耗力，也容易引入错误。LangChain 通过提供一致的接口和预构建的组件，大大简化了这一过程。它还引入了 Prompt Engineering 的理念，允许开发者通过设计优化的提示模板来引导模型生成更准确、更符合需求的输出。

LangChain 的发展历程可以追溯到 2021 年底。最初，它只是一个简单的概念验证项目，旨在探索如何将语言模型与外部数据集成。随着 ChatGPT 等大语言模型的出现和 NLP 技术的快速发展，LangChain 的潜力开始受到关注。

2022 年，LangChain 迎来了重大更新和扩展。它引入了更多的集成选项，支持了更多种类的数据源和下游应用。同时，LangChain 的社区也在不断壮大，越来越多的开发者开始贡献代码和分享经验。

2023 年，伴随着 AI 的大爆发，LangChain 迎来了爆发式增长。它成为了开发 AI 应用的必备工具之一，在各大技术论坛和社交平台上频频被提及。LangChain 也加速了版本迭代和功能更新，引入了更多高级特性，如 Agent 和 Memory，进一步增强了其适用性和性能。

如今，LangChain 已经发展成为一个成熟而强大的 NLP 应用开发框架。它不仅帮助开发者大幅提高了开发效率，也为各行各业带来了前所未有的智能化应用。展望未来，LangChain 还将持续演进，与最新的 AI 模型和技术保持同步，为开发者和用户带来更多惊喜。

LangChain 的核心是将 LLM 与外部数据源连接，并通过 prompt engineering 技术来优化 LLM 的输入输出，从而生成更加准确、相关的结果。它的主要组件和功能如下：

模型输入输出（Model I/O）：对接各种 LLM 模型的 API，提供统一的接口。支持 OpenAI、Anthropic、Hugging Face 等主流 LLM 服务商。
- 语言模型（Language Models）：支持大型语言模型（LLM）和聊天模型（ChatModel）的交互接口。
- 提示模板（Prompt Templates）：用于生成模型输入的预定义配方，支持两种主要类型是：PromptTemplate：生成字符串提示和 ChatPromptTemplate：生成聊天消息列表提示。
- 示例选择器（Example Selectors）：提供训练、调优、测试和控制模型行为的示例输入输出。
- 输出解析器（Output Parsers）：用于将模型返回的文本结果格式化为目标对象、JSON 或数组等。
数据连接（Data Connection）：在许多 LLM 应用程序中，用户特定的数据不在模型的训练集中，这可能是通过检索增强生成（RAG）实现的。RAG 的主要方法是检索外部数据，并在生成步骤中传递给 LLM。这样，LLM 就可以使用外部数据来增强生成的结果，从而提高应用程序的性能和准确性。
- 文档加载器（Document Loaders）：将不同数据源的非结构化文本加载为文档对象，并支持延迟加载。
- 文档转换器（Document Transformers）：对加载的文档进行处理，包括文本拆分、冗余过滤、元数据提取等。
- 文本嵌入模型（Text Embedding Models）：将文本转换为向量表示，用于文本检索、信息推荐、知识挖掘等。
- 矢量存储（Vector Stores）：负责存储嵌入数据并执行矢量搜索。
- 检索器（Retrievers）：从大规模文本库中检索与查询相关的文本段落，提供问答系统的额外上下文支持。
链（Chains）：组件化的方式将一系列操作连接在一起形成数据处理的工作流，如数据检索、内容生成、翻译等可复用的任务执行流程。常见的链包括 LLMChain、SequentialChain、RouterChain 等。
- 基础链（LLMChain）：围绕语言模型的简单链。由提示模板和语言模型组成，用于格式化提示并返回 LLM 输出。
- 路由链（RouterChain）：可以动态选择下一条链，包括 LLMRouterChain 和 EmbeddingRouterChain。
- 顺序链（SequentialChain）：将多个链顺序连接，支持 SimpleSequentialChain 和更通用的 SequentialChain。
- 转换链（TransformChain）：在链之间添加自定义转换函数。
- 文档链（DocumentsChain）：处理多个文档输入。
记忆（Memory）：为 Chains 和 Agents 提供对话状态记忆能力，用于在链之间存储和传递信息，实现上下文感知。常见的包括 ConversationBufferMemory、ChatMessageHistory 等。
代理（Agents）：一种特殊的 Chain，可根据目标进行工具选择、动作规划和迭代求精。使用 LLM 作为大脑自动思考和决策，执行动作完成任务。包括 ZeroShotAgent、ReAct、Self Ask With Search 等。
回调（Callbacks）：连接到 LLM 申请的各个阶段，用于日志记录、监控等。

LangChain 主要解决了以下问题：

简化了与不同语言模型的交互。
提供了标准化的方法来生成和管理提示。
允许用户为模型提供示例输入输出，以优化模型性能。
支持非结构化文本的加载、转换和处理。
使文本嵌入和检索更加方便，支持向量空间中的各种运算。
通过链的概念，允许将多个组件组合成复杂的工作流程。
实现了对话的上下文感知能力。
通过代理自动执行任务，提高了应用的智能化水平。

那如何使用呢？

使用 LangChain 的一般步骤可能包括：

根据需求选择合适的组件，如语言模型、提示模板等。
使用文档加载器加载数据，并利用文档转换器进行预处理。
配置链，将不同的组件组合起来，创建工作流程。
利用记忆组件在链之间传递上下文信息。
定义代理，使用 LLM 进行自动决策和执行。
设置回调，进行日志记录和监控。
根据具体应用场景进行调整和优化。

在使用过程中有一些注意的事项：

根据任务选择合适的 LLM：不同的 LLM 适用不同任务，并有不同的使用成本，需要根据实际情况权衡。在使用 LangChain 前，需要明确了解自己的需求和应用场景，选择和配置合适的组件和模型。
注意提示工程：LLM 的效果很大程度取决于提示的设计，需要遵循最佳实践，多进行实验和迭代。
数据的隐私和安全：在涉及用户数据时，注意数据的安全性和隐私保护，遵循相关法律法规和最佳实践。特别是在 fine-tuning 或者数据索引时，要注意数据的隐私和版权问题。
模型的公平性和伦理性：LLM 可能会放大数据中的偏见，产生有害或者不道德的内容，需要谨慎使用。
应用的可解释性：端到端的 LLM pipeline 往往是个黑盒，要考虑如何向用户解释其工作原理和局限性。
成本和效率优化：要密切关注 LLM 调用次数、向量检索等环节的耗时和费用，权衡精度和成本。对于大规模数据处理或高吞吐量的应用，需关注性能优化，可能需要并行处理、缓存机制、硬件加速等手段。

通过合理的使用和配置，LangChain 可以极大地简化复杂 AI 应用的开发流程，提高开发效率和应用性能。LangChain 的设计使得开发者可以灵活地构建和定制 AI 应用程序，以适应不同的业务需求。

LangChain 适用于构建各种 LLM 驱动的应用，比如智能对话助手、知识库问答、数据分析、文案创作等。LangChain 正在成为 LLM 应用开发领域的生产力工具，促进更多创新产品和服务的诞生。

小结

AI 编程范式正在为我们开启一个全新的创作空间。ComfyUI 让设计变得前所未有的简单，LangChain 则让智能对话唾手可得。站在时代的十字路口，拥抱 AI，学习新的编程范式，我们就能更从容地迎接未来的挑战与机遇。

但，纸上得来终觉浅，绝知此事要躬行。

在实际的工作中，这些要用起来，才能有更深刻的体会。

以上。

快速了解文生图 AIGC 的 15 个关键词

admin — Thu, 08 Feb 2024 07:44:28 +0000

冯唐在《成事心法》中提到过这样一个观点：「只要你把这 100 个相关的关键词搞清楚，而且每个关键词，你都能给出合理的答案，那么你也可以成为这个领域的专家」。

想要快速了解 AIGC 文生图，从了解下面的 15 个关键词开始吧。

AI 概念名称

AI

AI，Artificial Intelligence，人工智能

人工智能这个词在大众想象中常常会勾起有关自主思考的机器人和智能机器的画面。但核心上，AI 是关于创建智能算法的学科，目的是执行通常需要人类智慧才能完成的任务。人工智能的概念自 20 世纪中叶以来就已存在，但它是在 1956 年的达特茅斯会议上，由约翰·麦卡锡正式提出的术语。

从那时起的几十年里，AI 已经从理论概念演变成一个涵盖机器学习、神经网络和深度学习等的强大领域。如今，AI 不仅仅是一个研究领域；它已成为我们日常生活中不可或缺的一部分，改变着行业并创造出曾经只存在于科幻小说中的新可能性。

AGI

AGI，Artificial General Intelligence，人工通用智能，也称为强人工智能或全能 AI

AGI 指一种具有普遍的认知能力的机器智能，它能在各种领域和任务中表现出与人类相当或更高的效能。与目前的人工智能系统（被称为弱 AI 或专用 AI ）不同，这些系统通常设计用来解决特定问题或执行特定任务，AGI 将能够像人类一样学习、理解、推理和应用知识于新的和多样化的情境中。

AGI 的概念和 AI 一起发展，但成为独立研究的重点是在 21 世纪初

AIGC

AIGC，AI Generated Content，AI 生成内容

AIGC 指的是通过人工智能算法自动创建的内容，这些内容可以包括文字、图像、音频、视频和其它多媒体格式。

现在主要是利用了像生成对抗网络（GANs）和 Transformer 模型等技术，这些工具能够生成逼真和具有创造性的输出。

在文本领域，AIGC体现在自动撰写新闻、小说创作、营销文案编写等；在视觉艺术领域，AIGC 则能够创作出新的图像作品、动画和视频。

AIGC 技术的优势在于其高效性和能够处理大量内容的能力，从而在一定程度上减轻了人类内容创作者的负担，并为他们的工作提供辅助。例如，新闻机构可以利用 AIGC 生成初稿或基于数据的报告，艺术家可以使用 AI 来生成新颖的素材或灵感，而企业可以通过 AIGC 定制个性化的广告内容或提供客户支持。

尽管存在挑战，AIGC 的未来发展前景依然被广泛看好。随着算法的不断进步和创作工具的日益智能化，AIGC 有望在提高内容创作效率、降低成本以及驱动创新方面发挥重要作用。同时，它也将促进新的艺术形式和娱乐方式的产生，为人类文化和创意表达开辟新的可能性。

GPU

图形处理单元 (GPU) 是一种专门设计来处理计算机图形和图像处理任务的芯片。

GPU 的历史可以追溯到 1990 年代初，但是它作为通用计算设备在 21 世纪初开始流行。NVIDIA 在 1999 年推出了市场上第一个真正的GPU，名为 GeForce 256。

GPU 最初是为了加速电脑游戏中的图形渲染而设计的，但它也已经成为现代人工智能和深度学习领域的核心硬件组件。

GPU 的设计理念是处理成千上万的并行任务，这使得它在执行大规模且复杂的计算时特别高效。与 CPU 的少量核心相比，GPU 拥有大量的小核心，它们可以在同一时间处理大量的数据。

GPU 内部的核心可以分为不同的类型，包括着色器核心、纹理单元和渲染输出单元等，共同执行复杂的图形处理操作。这些核心特别适合执行深度学习所需的高度并行的矩阵和向量运算。此外，GPU 的高内存带宽允许快速的数据读取和写入，这对于处理大型深度学习模型和数据集是必需的。

在 AI 应用中，GPU 显著加速了深度学习模型的训练和推理过程。训练过程涉及到数据的前向传播和反向传播算法，用以计算损失函数并且更新网络的权重。这些计算步骤需要重复进行，并且每一步都要处理大量的数据。GPU 可以同时执行这些步骤中的多个操作，从而大大减少了训练时间。

除了硬件上的优势，GPU 制造商还提供了专门优化的软件工具和库，如 NVIDIA 的 CUDA 和 cuDNN，这些工具为深度学习任务提供了额外的加速。这些软件库简化了在 GPU 上编程的过程，使研究人员和开发人员能够更容易地利用 GPU 进行大规模并行计算，而不需要深入了解其底层硬件架构。

无论是在科学研究、游戏渲染、多媒体内容创作还是 AI 和机器学习的推进中，GPU 都已经成为不可或缺的计算工具。它的并行处理能力、高速内存带宽和专用软件库共同推动了当今最前沿技术的发展，使得AI的训练和部署更加快速和高效。随着技术的进步，GPU 在现代计算生态系统中的作用将继续扩大。

AI 产品

DALL-E 系列

DALL-E 是一个由 OpenAI 研发的人工智能系统，能够根据文本描述生成相应的图像。这个名字是对艺术家萨尔瓦多·达利（Salvador Dalí）和动画片《WALL-E》的致敬。

DALL-E 于 2021 年 1 月 5 日由 OpenAI 首次发布；2022 年 4 月，OpenAI 宣布了新版本的DALL-E 2，声称它可以从文本描述中生成照片般逼真的图像，另外还有一个允许对输出进行简单修改的编辑器。2023 年 9 月份发布 DALL・E ‍3，与 2 相比，它可以利用 ChatGPT 生成提示，然后让模型根据该提示生成图像。

DALL-E 能够生成各种风格的图像，从照相写实主义图像到绘画和表情符号。它还可以「操纵和重新排列」图像中的对象。其创作者指出DALL-E 的一项能力是在没有明确指示的情况下将设计元素正确放置在新颖的作品中

DALL-E 使用了 Transformer 架构，这种架构最初是为了处理自然语言处理任务而设计的。OpenAI 通过将 Transformer 与生成对抗网络（GANs）等图像生成技术结合，使 DALL-E 能够理解文本提示并创造出新颖的、与文本内容相符的图像。

DALL-E 的技术架构基于 GPT-3 的多模态版本，它具备 120 亿个参数，并通过网络上收集的大量文本-图像对进行训练。这种训练使得 DALL-E 能够进行零样本学习，即在没有额外训练的情况下根据描述生成图像。生成的图像随后由 CLIP 模型进行评分和筛选，以提供最高质量的输出。CLIP 自身是一个强大的图像识别系统，它使用了超过 4 亿对图像和文本对进行训练，从而能够将图像与大量文本相关联，并识别出训练集之外的图像内容。

Midjourney

Midjourney 是由 Midjourney 公司开发的一种基于扩散模型的图像生成平台，于 2022 年 7 月进入公测阶段，面向大众开放。

Midjourney 的绘画能力很强，几乎无需 prompt 能力即可得到效果很不错的图，人像、细节方面尤为突出。

与大部分同类服务不同，Midjourney 选择在 Discord 平台上运行，用户无须学习各种烦琐的操作步骤，也无须自行部署，只要在Discord 中用聊天的方式与 Midjourney 的机器人交互就能生成图片。这一平台上手门槛极低，但其生成的图片效果却不输于 DALL·E 和 Stable Diffusion ，于是很快赢得了大量用户。据 Midjourney 的创始人大卫·霍尔兹(David Holz)介绍，仅在发布一个月之后，Midjourney 就已经盈利。

在 2022 年 9 月 5 日，在美国科罗拉多州博览会的年度美术比赛中，一张名为《太空歌剧院》的画作获得了第一名，然而这幅画并非出自人类画家之手，而是由游戏设计师杰森·艾伦(Jason Allen)使用 Midjourney 生成，再经 Photoshop 润色而来。它是首批获得此类奖项的人工智能生成图像之一。

Midjourney 创始人 David Holz 在说到关于 Midjourney 背后的理念时有说到：

MJ 的目标是成为新的人类基础设施，这样才能支撑更多人构建新事物。所以 MJ 的主题是反思、想象和协调。反思自己是谁，想要什么；想象会是什么；协调大家如何抵达。同时也会思考其人性的一面，例如人类通过计算机来想象就能像汽车旅行一样，这意味着什么；又或者人类在想象的过程中以什么方式互动等。

MJ 其实是水。人们误解了人工智能是什么，就像认为其是一只老虎，会吃掉我们。但其实水也很危险，能淹死我们，但流动的河水和老虎完全不同，水是危险的，但是你可以在其中游泳，造船，建造发电站等。水虽然是危险的，但却是文明的驱动力，作为知道如何与水共处的人类，我们能过的更好。水没有意志，也没有恶意，你可以淹死在其中，但并不能应该因此惧怕并禁止水。所以 MJ 试图弄清楚的是，我们如何将其用于人们？我们如何教人们游泳？我们如何造船？我们怎么把它堵起来？我们如何从害怕溺水的人变成未来冲浪的孩子？我们正在制造冲浪板而不是制造水。这才是一些深刻的意义。

困难和有趣是事情的两面，MJ 面临的许多问题无法量化。比如什么是一张「好的狗狗照片」，这很难回答，但也因此有趣。类似的问题还有「什么是好的图像」「人们想从图像中得到什么」「他们是如何沟通的」「他们如何通过文字描绘出他们想要的东西」 —— 这些问题几近哲学，但却很让人喜欢。

关于愿景，希望能以某种方式创造一个更有想象力的世界。因为今天世界最大的问题是信仰崩溃，包括对自己的，对未来的信念。而造成这种问题的主要愿意那就是缺乏想象力，缺乏自己可以成为什么人的想象力，缺乏对未来的想象力。所以想象力才是我们在世界上所需要的东西的重要支柱。所以我想通过 MJ 来将其变成一种可以「扩展人类想象力的力量」

当计算机比 99% 的人类更善于视觉想象时，这意味着什么？这并不意味着我们将停止想象。汽车比人类快，但这并不意味着我们停止步行。当我们远距离运输大量物品时，我们需要发动机，无论是飞机、轮船还是汽车。我们将这项技术视为想象力的引擎。所以这是一个非常积极和人性化的事情。

https://midjourney.com/showcase/

Stable Diffusion

Stable Diffusion 是由 CompVis、Stability AI 和 LAION 的研究人员实现并开源的。从 Stable Diffusion 模型应用用户的角度来看，其核心是根据文本生成图像，可以通过一些技巧，或通过调整用户参数，来改变文本生成图像的过程，从而达到优化最终生成图像的目的。

得益于其卓越的图片生成效果、完全开源的特点以及相对较低的配置需求（可在消费级GPU上运行），在推出后不久它就流行开来，大量开发者以及公司加入它的社区参与共建，同时，还有很多公司基于 Stable Diffusion 推出了自己的 AI 绘画应用。

Stable Diffusion 是 AI 绘画最为重要的开源力量，创业生态的基石

Stable Diffusion 在多个方面表现出色，尤其是在图像质量和生成速度方面。它能够根据复杂的文本描述生成高分辨率和高质量的图像，这在以前的模型中往往难以实现。Stable Diffusion 还能够处理多样化的艺术风格和主题，从现实主义到超现实主义，从肖像画到风景画，甚至是科幻和奇幻的主题。用户可以通过详细的文本提示，引导模型创造出各种各样的视觉内容。

Stable Diffusion 的核心技术包括变分自编码器（VAE）和转换器网络。它通过大规模的图像和文本对数据集进行训练，学习了如何解释文本提示并将其转换为相应的图像。这种结合了自编码器和转换器的架构，不仅使得图像生成过程更为高效，而且还有助于保持生成图像的多样性和创造性。此外，Stable Diffusion 的模型训练采用了强调数据质量和多样性的方法，以确保生成的图像既准确又引人入胜。

AI 公司

OpenAI

OpenAI 成立于 2015 年 12 月，由埃隆·马斯克、萨姆·奥特曼、格雷格·布罗克曼、伊莱亚·萨斯克、约翰·舒尔茨菲尔德等科技行业领袖共同发起。OpenAI 的初衷是作为一个非营利组织，旨在推动和发展友好的人工智能，确保人工智能的发展能够惠及全人类。

在成立之初，OpenAI 提出了一系列雄心勃勃的目标，包括在人工智能领域进行开创性的研究，并且将研究成果公开分享，以促进整个领域的发展。OpenAI 迅速在人工智能研究领域崭露头角，特别是在强化学习和深度学习的应用上取得了显著的成就。

OpenAI 原本是以非营利组织的身份成立的，但在 2019 年初，OpenAI 宣布将采取一种新的「有限利润」公司结构，即 OpenAI LP，这是为了吸引更多的投资以支持其研究和开发。这个结构允许外部投资者投资，但限制了投资回报率。OpenAI LP 的创始投资者包括 Kholsa Ventures、Reid Hoffman 的基金、微软等。

所以，OpenAI 这个美国人工智能研究实验室由非营利组织OpenAI Inc，和其营利组织子公司 OpenAI LP 所组成。

OpenAI 已经推出了多个影响深远的产品和技术，其中包括 GPT 系列、DALL-E 系列、CLIP、Codex等。

除了这些产品，OpenAI 还在多个领域进行研究，包括机器人、强化学习、游戏（如Dota 2中的AI）、自然语言理解和生成等。

Stability AI

Stability AI 是由首席执行官 Emad Mostaque 创立的初创公司。Mostaque 毕业于牛津大学，拥有数学和计算机科学硕士学位（据福布斯的爆料说，其仅为学士学位）。他曾在多家对冲基金担任分析师，后来转向更加公众化的工作。Mostaque 在 2020 年创立了 Stability AI，旨在解决开源人工智能社区中的「组织」问题。

Stability AI 拥有超过 4,000 个 Nvidia A100 GPU 的集群，用于训练 AI 系统，包括 Stable Diffusion。然而，维护这个集群非常昂贵，据报道，Stability AI 的运营和云计算支出超过了 5000 万美元。但是，Mostaque 反复表示，公司的研发将使其能够更高效地训练模型。

除了 Stable Diffusion，Stability AI 还可能提供包括自然语言处理工具、数据分析服务以及 AI 模型定制和咨询服务在内的多种产品和解决方案。公司倡导开源精神，通过提供开源工具和资源，鼓励技术社区的参与与合作，以促进人工智能技术的创新和发展。

为了支持更大规模的用户定制版本的 Stable Diffusion，并投资更多的超级计算能力，Stability AI 在最近一轮融资中筹集了1.01 亿美元。这笔资金还将用于招聘更多员工，Mostaque 预计在未来一年内将员工规模从 100 人增加到 300 人。此外，Stability AI 还计划开发其他可商业化的项目，包括用于生成音频、语言、3D 和视频的 AI 模型。

模型相关

VAE

VAE，Variational Auto-Encoder，变分自编码器

VAE 是一种深度学习模型，用于学习输入数据的概率分布，并生成新的数据样本。它由两大部分组成：编码器将输入数据转换为潜在表示，解码器则将这些潜在表示转换回原始数据空间。VAE 的目标是通过最小化重构误差和正则化潜在空间来训练模型，从而能够生成与训练数据相似的新样本。

VAE 是在自编码器的基础上发展而来，它引入了概率图模型的概念，使得生成的数据能够具有多样性和连续性。自从 2013 年由 Kingma 和 Welling 提出以来，VAE 成为了无监督学习和生成模型领域的一个重要里程碑，催生了一系列相关研究和更复杂的模型变种。

VAE 模型是一个经典的生成式模型，在传统深度学习时代，GAN 的风头完全盖过了 VAE，但 VAE 简洁稳定的 Encoder-Decoder 架构，以及能够高效提取数据 Latent 特征和 Latent 特征像素级重建的关键能力，让其跨过了周期，在 AIGC 时代重新繁荣。

VAE 在 AIGC 领域中非常有用，尤其是在图像生成、文本生成、音乐创作等创造性任务中。它的特点是能够创建一个平滑且连续的潜在空间，使得我们可以通过遍历这个空间来生成具有细微变化的数据样本。此外，VAE 的正则化特性也使其在处理复杂数据分布时具有鲁棒性，并且能够有效防止过拟合。

技术上，VAE 的核心是基于神经网络的编解码器架构。编码器网络将数据映射到潜在空间的参数（均值和方差），而解码器网络则从潜在空间中采样点并重构数据。这个过程中，VAE 使用变分推断来逼近真实数据的概率分布，并通过一种特殊的损失函数（结合重构损失和KL散度）来训练网络。

CLIP

CLIP，Contrastive Language-Image Pre-training，对比图文预训练模型

CLIP 是 OpenAI 开发的一种多模态深度学习模型，设计用来理解图像内容及其对应的文本描述。通过将图像与文本匹配，CLIP 学会了识别图像中的物体、场景和动作，并理解相关的自然语言描述，如标签、说明和标题。

CLIP 包含两个主要部分：一个图像编码器和一个文本编码器。这两部分编码器在一个统一的向量空间内进行对比学习，以便最小化匹配文本和图像对之间的距离。这种方式允许 CLIP 在视觉和语言任务上表现出色。

CLIP 通过对比学习的方法进行预训练，学习了大量图像和文本对的共同表示。它超越了传统的图像分类模型，因为它不仅能够识别图像内容，还能理解与之相关的复杂文本信息。

CLIP 的主要特点是其对抗学习方式，类似于生成对抗网络（GAN）。在训练过程中，图像编码器致力于最小化匹配的文本和图像之间的距离，而文本编码器则尝试最大化它们之间的距离。这种方法有助于模型学习到更丰富、更准确的图像和文本表示。CLIP 在各种图像分类任务上都表现出色，并能够理解图像中的复杂概念，这使得它在多种视觉应用中非常有用。

CLIP 的应用非常广泛，包括但不限于图像检索、视觉问答、视觉导航以及图像生成。此外，基于 CLIP 的原理，OpenAI 还开发了 DALL-E 模型，该模型能够根据文本描述生成相应的图像。

Diffusion

Diffusion 模型是一种生成模型，用于在人工智能生成内容(AIGC)中创建高质量的图像、音频或其他数据形式。

Diffusion Model 的灵感来自 non-equilibrium thermodynamics (非平衡热力学), 理论首先定义扩散步骤的马尔可夫链，缓慢地将随机噪声添加到数据中，然后学习逆向扩散过程以从噪声中构造所需的数据样本。

与传统的生成模型如 GANs 不同， Diffusion 模型通过模拟数据的概率分布来生成新的实例。这些模型从一个随机噪声分布开始，逐渐引入结构，最终生成与训练数据类似的样本。扩散模型是通过固定过程学习，并且隐空间具有比较高的维度。

Diffusion模型建立在去噪自编码器等前期工作的基础上，并因其在生成高质量样本方面的卓越性能而受到关注。与容易出现训练困难和模式崩溃的生成对抗网络(GANs)相比，Diffusion模型的训练过程更加稳定，能够更可靠地生成多样化的高质量内容。

技术上，Diffusion模型包含正向扩散过程和逆向扩散过程。正向过程逐步加入噪声，直至数据完全随机化；而逆向过程则是学习如何从随机噪声中重建数据，这是通过训练一个神经网络来实现的，它能够在每一步预测并减少噪声，逐渐恢复出清晰的数据。

Diffusion 模型在过去几年中得到了快速发展，部分原因是它们在生成高质量样本方面的能力，尤其是在图像和音频生成上。它们在质量和多样性方面逐渐超过了 GANs，这是因为 Diffusion 模型在训练过程中更加稳定，并且它们生成数据的方式更加符合数据的内在分布。

Diffusion 模型在多种场景下都有应用，例如在图像生成领域，可以创造出不存在的逼真物体、场景和人物图像；在文本到图像的合成中，可以根据文本描述生成相应的图像；还可以用于音频合成，生成音乐和语音；或用于数据增强和图像超分辨率等领域。

Disco Diffusion

Disco Diffusion 是一个开源项目，它是一种结合了多种人工智能技术的扩散模型，旨在将文本描述转换为详细的图像。它通过理解语言提示，并将这些提示映射到丰富的视觉表现上，实现了从抽象概念到具体图像的创造性转换。该模型可以接受复杂的文本输入并生成与之相匹配的高质量图像，使用户能够直观地表达和实现他们的创意构想。

Disco Diffusion 的发展是建立在深度学习和生成模型领域的一系列创新之上的。最初的扩散模型在生成逼真图像方面已经取得了突破，但当结合了理解文本和图像关系的 CLIP 模型时，这些生成模型的能力得到了极大的扩展。Disco Diffusion 是这一进展的产物，它不仅继承了先前模型生成高质量图像的能力，还加入了对文本的理解，从而实现了更为直观和创造性的图像生成。

Disco Diffusion 的技术架构是基于扩散模型的，这是一种逐步引入并去除噪声以生成数据的方法。在这个基础上，Disco Diffusion 集成了 OpenAI 的 CLIP 模型，后者训练用于理解图像内容与自然语言描述之间的关联。该模型可能还结合了类似于生成对抗网络（GANs）的组件来提升最终图像的质量，以及变分自编码器（VAEs）来增强图像的多样性和创意表达。

Disco Diffusion 的主要特点是其能够将文本描述转化为高分辨率、高质量的图像。它通过灵活地理解和应用文本提示，结合了随机性和算法控制，生成独一无二的艺术作品。与传统的生成模型相比，Disco Diffusion 在保留图像真实感的同时，提供了更丰富的细节和更深层的创造性探索，使其成为 AIGC 领域中的一个创新和有影响力的工具。

Disco Diffusion 在艺术创作、媒体制作、设计和教育等多个领域都有广泛的应用。艺术家可以使用它来将他们的诗歌或故事变成视觉艺术作品；设计师可以通过它快速生成设计概念图；媒体制作者可以利用它为视频或游戏创造复杂的背景；教育者可以用它来激发学生的创造力并解释抽象概念。

Imagen 系列

Imagen 是 2022 年 5 月 Google Brain 团队研发的一个先进的文本到图像生成系统，它通过深度学习模型将文字描述转换为视觉图像。这种模型的核心功能是捕捉和解析人类语言中的复杂概念，并将这些概念以图像的形式表现出来，生成与文本描述高度一致且视觉上引人入胜的图像。

根据发布在 arXiv 的研究论文中，Imagen 使用了 Transformer 语言模型将文本转换成嵌入向量序列，三个连续的扩散模型将这些向量转换成高清图片。研究团队还开发了 U-Net 改进型扩散模型（Efficient U-Net）以及新的评估工具 DrawBench。Imagen 在 COCO 基准上取得了 7.27 的 FID 分数，优于 DALL-E 2。

与使用图像-文本数据集训练不同，Imagen 仅使用文本编码器（如T5）来处理输入文本。然后，扩散模型将嵌入向量转换为图像，通过迭代去噪过程生成高质量图片。

在 2023 年底 Google 发布 Imagen 2。Imagen 2 最与众不同之处在于，它能够以惊人的准确性，理解复杂抽象的概念，然后把这个概念可视化，细腻之程度令人惊叹！

Imagen 2 的核心，还是复杂的神经网络架构。经过微调的 Transformer 模型，在文本理解和图像合成上，都表现出了无与伦比的性能。

SDXL

SDXL，Stable Diffusion XL，该模型是在 2022 年 AIGC 元年后推出的。其开发历程包括从 0.9 测试版到基于用户反馈的1.0正式版的逐步迭代，不断优化以提高图像质量。

SDXL 是 Stable Diffusion 模型的进阶版，由 Stability AI 发布。这个模型通过双阶段扩散过程，即 Base 和 Refiner 模型，提供了高分辨率的图像生成和精细化处理。SDXL 特别适用于要求高细节图像的应用场景，如 AI 绘画和高级设计任务。

与原版 Stable Diffusion 相比，SDXL 引入了多项技术优化。其 U-Net 参数量显著增加，达到 2.6B，显著提高了模型的学习和图像细节处理能力。Refiner 模型的加入进一步提高了图像的精细度，而新的训练技巧，如多尺度训练，优化了整体模型性能。

当输入是图片时，Stable Diffusion XL 和 Stable Diffusion 一样，首先会使用 VAE 的 Encoder 结构将输入图像转换为Latent 特征，然后 U-Net 不断对 Latent 特征进行优化，最后使用 VAE 的 Decoder 结构将 Latent 特征重建出像素级图像。除了提取 Latent 特征和图像的像素级重建外，VAE 还可以改进生成图像中的高频细节，小物体特征和整体图像色彩。

当 Stable Diffusion XL 的输入是文字时，这时我们不需要 VAE 的 Encoder 结构，只需要 Decoder 进行图像重建。

Stable Diffusion XL 使用了和之前 Stable Diffusion 系列一样的 VAE 结构（KL-f8），但在训练中选择了更大的 Batch-Size（256 vs 9），并且对模型进行指数滑动平均操作（EMA，exponential moving average），EMA 对模型的参数做平均，从而提高性能并增加模型鲁棒性。

GPT-4 发布了，关于 AIGC 产品上线前后技术管理者要注意的五个重要事项

admin — Sat, 18 Mar 2023 14:04:31 +0000

GPT-4 于 2023 年 3 月 14 日发布。目前 GPT-4 没有免费版本，仅向 ChatGPT Plus 的付费订阅用户及企业和开发者开放。

如比尔盖茨在 reddit 回答网友提问时回答时说的：「AI is the big one. I don’t think Web3 was that big or that metaverse stuff alone was revolutionary but AI is quite revolutionary」，我们可能又到了一个历史性的转折点。

现在各家企业，包括 Google、微软，以及国内的 BAT 等大厂都在大量投入，一些中小厂也在垂直的应用赛道拔城攻寨，作为一个技术管理者一定会面对这样一个洪流，在洪流之中我们需要注意什么呢？

如果你所在企业要上线 AIGC 的产品，或者已经上线 AIGC 的产品，以下的五个重要事项需要特别注意。

1 安全

安全是产品的生命线，特别是对于 AIGC 产品来说，没有安全守护，不仅仅是产品玩完，甚至会连累其它产品甚至公司存续。

1.1 内容安全

这里内容安全的定义是指 AIGC 生成内容影响产品本身存在的领域。

在国内与内容安全相关的场景包括涉政、色情、性感（性感和色情在内容安全中是不一样的）、暴恐、违禁、恶心、涉价值观等。其中每一项都需要检测，部分项出现问题甚至会关站和约谈。

在 chatGPT 大火后，网络上有各种和 chatGPT 相关的段子，特别是一些场景下，对输入措辞的调整或多次尝试相同的提示很敏感，只要稍作改写，就可以以另一种方式回答出来。

据最新发布的 GPT-4 的 OpenAI 工程师们们说，GPT-4 的训练在去年 8 月完成，剩下的时间都在进行微调提升，以及最重要的去除危险内容生成的工作。由此可见内容安全是一个多么重要且复杂的事情。

GPT-4 在 RLHF 训练中加入了一个额外的安全奖励信号，通过训练模型拒绝对此类内容的请求来减少有害的输出。奖励是由 GPT-4 的零样本分类器提供的，它判断安全边界和安全相关 prompt 的完成方式。为了防止模型拒绝有效的请求，团队从各种来源（例如，标注的生产数据、人类的红队、模型生成的 prompt）收集多样化的数据集，在允许和不允许的类别上应用安全奖励信号（有正值或负值）。这是 OpenAI 的工程师在训练 GPT-4 时做的一些努力。

GPT-4 现在是闭源的，模型本身我们做不了什么。

除了 GPT-4 ，还有许多的 AIGC 的模型，并且更多的人只是作为一个应用开发方来实现一些功能。

除了在训练时对模型本身危险内容生成的去除，在技术应用侧，我们可以考虑如下一些方面：

接入内容安全审核平台，在输入和输出两个层面进行双重过滤。公司大的接自己的，公司内没有的接第三方，依靠审核平台的积累，规避掉涉政、色情等风险极大的情况。
实名可追溯，类似于工厂里面的批号跟踪，对于用户上传图片、文字或视频、使用 AIGC 生产出来的内容、传播的内容进行跟踪，有系统支撑后台的查询和追溯，在后台中注意对用户敏感信息的保护，保持脱敏的逻辑。
控制传播，控制传播一方面是在功能层面保证传播的内容是在上面安全审核平台的前置约束下进行，另一方面在传播进行多级防控，比如播放量达到不同的级别进行不同规格的检测，如播放量达到 10 万，需要重新进入审核等等。

在互联网行业，内容安全一直面临着挑战，各内容平台不断提升对于内容安全的治理能力，随着 AIGC 的发展，内容爆炸式的增长，内容安全的挑战将会更大。

1.2 虚假信息

在对 chatGPT 深度体验后，往往会生成一种「一本正经的胡说八道」的感觉，甚至它会编造一些事实或者不存在的东西出来回答。对于模棱两可的问题，chatGPT 通常会猜测用户的意图，而非让用户澄清问题。

举个例子，我在 chatGPT-3.5 中问：「有没有什么现成的库可以检测图片清晰度，对原图和 avif 图进行清晰度检测」，它回答了三个库可以，Sharp、ImageJS和 Pica

我接着问：「 Pica 的什么方法可以检测」，它告诉我 quality 方法可以，并给出了详细的示例，从代码上来看，像那么回事，并且代码前面的引入，输入的格式转化都没有问题，有问题的只是没有 quality 方法而已。

又或者你随便取一个书名，问他是谁写的，比如我的问题是：「《不想开车的夜晚，我在听歌》这本书是谁写的」，它的回答是：「 “不想开车的夜晚，我在听歌” 这本书的作者是中国作家韩寒。这本书是一本散文集，收录了韩寒的一些散文作品，其中包括《像少年啦飞驰》、《三重门》、《我所理解的生活》等等。这本书出版于2002年，是韩寒的第一本散文集。韩寒是中国当代著名的作家、音乐人、导演和投资人，他的作品包括小说、散文、音乐和电影等多个领域，深受年轻读者和网民的喜爱和追捧。」

除了 chatGPT 以外，图片或视频生成领域有更多的虚假信息，如诈骗团队利用 DeepFake，通过截取马斯克在 TED 采访的视频，并为其配音，为的就是推出 BitVex 比特币诈骗平台。诈骗分子还伪造了方舟投资（Ark Invest）CEO 凯瑟琳·伍德、以太坊联合创始人查尔斯·霍斯金森等多位币圈名人推荐BitVex的视频。另外，2021 年初光是靠 DeepFake 技术换脸马斯克喊出「给我一个币，我给你两个」的骗局在一周内就达到 24.3 万美元，诈骗总额高达 3000 万美元（约人民币2亿）。

诈骗团伙以及不法份子使用 AIGC 恶意使用，甚至滥用，引发新型的诈骗、色情、诽谤、假冒身份等违法犯罪行为。 AIGC 让其效率更高，鉴别难度更大。这样可能会引发人们对于个人身份的盗用，冒用，以及在网络上，或在元宇宙中数字身份安全的担忧。

以上是在 GPT-4 出现之前，在 GPT-4 出来后，情况有所改变，如前面个问题：「《不想开车的夜晚，我在听歌》这本书是谁写的」，GPT-4 的回答是：「很抱歉，我无法找到与《不想开车的夜晚，我在听歌》这本书相关的作者信息。这本书可能不存在，或者没有足够的知名度。如果您能提供更多信息，我会尽力帮助您找到相关内容。」

技术在进步，会越来越好，但是我们仍然需要结合实名制、内容安全检测等手段，我们只能尽量减少虚假信息在平台的产生和传播。

1.3 模型安全

现在 AIGC 内容生成对于我们来说是一个黑盒子，我们无法完全预知其过程和结果。我们所能做的是控制模型的参数和模型的数据输入，这里可能会导致安全问题。

算法的公正性和透明度。AI 系统的决策往往是基于其算法的结果，但是，如果这些算法存在偏见或不公平的因素，将会对用户的权利和利益造成损害。因此，AIGC 需要确保 AI 算法的公正性和透明度，避免对用户造成不公平的影响。

对模型的攻击：通过某种方式向模型中注入恶意样本、有毒数据或有误导性的数据，来破坏模型；或者以某种方式篡改或操纵模型的训练数据，以达到改变模型输出的目的。
模型后门：在模型的训练中，攻击者通过修改模型的训练数据和权重信息使模型学习到了隐藏的规则，以达到放置后门的目的（我也不知道怎么实现）。举个例子，假设有个开源的项目不想让人商用，于是采用了 GPL 的协议，但是如何判断有人商用了呢，于是在项目生成的模型中隐藏一些规则，比如某些特殊的输入能显示和特定的结果，以举证。比如「左耳朵耗子」在 Twitter 上分享的「百度的“文心一格”AI生成图片：“一只爱国的猫”，看来不但政治不正确，而且可以推测后面用的图片训练集的来源也不是自主可控的」，那只猫身上的国旗是美丽国的。不过现在你无法生成了，因为在输入层面做了限制，现在输入只会显示「请您更换输入后试试~」，这也就是我们前面说的在输入层面做一些控制。

除了模型本身的安全问题，对于模型衍生的个人隐私保护，数据安全和标准，甚至后面可能会出现的模型病毒等等都需要持续关注起来。

2 容量

AIGC 产品在面对大量用户使用时，可能会面临以下容量问题：

存储容量： AIGC 产品生成的内容包含了大型文本、视频、图像等多媒体数据。如果用户数目众多，这可能需要大量的存储空间。假设用户生成的这些内容都是放到公有云上，随着用户的增加，这些内容将会成为一个巨大的成本，因此我们在项目设计之初就考虑存储容量的问题，给每个用户的容量，总的容量，以及存储的时长，因为成本是随着时间而变化的。
处理容量： AIGC 产品处理大量数据，包括数据的采集、整合、分析和后期制作处理等多个环节。因此，AIGC 需要具备高质量的计算设备和计算能力来支持项目，将应用的各个环节结合起来，处理更多最终输出结果。如果计算能力不足，则可能会给用户带来等待时间过长的使用体验，增加流失率。
带宽容量： AIGC 产品生成内容的访问请求峰值会在高峰期不断攀升，这需要具备良好的带宽容量来实现。如果网络峰值超过供应时，将影响用户体验和产品稳定性。因此，就需要整合具有强网络连接性和容量传输能力的网络设备，包括高带宽和低延迟的数字通信方式，例如光纤和高性能互联网符合AIGC产品的要求。
内容审核容量：AIGC 产品生成的内容需要进行审核和精细化调整，以确保内容的准确性和完整性。这需要大量的人工审核，提供符合要求的人选加入审核容量的组合当中。此外，随着 AIGC 的规模发展，产品审核过程的效率和质量也需要考虑如何优化。

在应对容量问题时，AIGC 产品需要全面优化和规划系统架构、数据处理和存储、计算和运维等方面，以实现产品的高可靠性和高性能。同时，需要持续跟进技术发展和创新，以保持 AIGC 产品的竞争力和创新性。

基于这些考虑我们在应用开发过程中需要考虑以下系统的实现：

用户级的容量限制，包括存储容量，存储时长，使用次数等等。
用户试用灰度，如邀请机制，分批次邀请用户进来，以控制容量的发展，不仅仅是存储、还有处理容量和带宽的容量。
接入多个第三方审核平台，在增加灾备的同时，增加内容审核的容量。

3 成本

对于大模型，一般的企业是没有能力开发的，这种情况我们一般是接第三方的接口。

以 OpenAI 为例，3.1 日，OpenAI 开放了 ChatGPT 的 API 接口，成本优化了 90%，百万 token 只需要 2 美元，并且提炼 otken 能力也大幅优化。新上的 GPT-4 要贵一个数量级，从 0.002 到 0.06，涨了 30 倍。

此外，OpenAI 还提供了图像生成和编辑的服务，如 DALL·E。这些服务的价格取决于图像的分辨率。例如，1024×1024 的图像每张 0.02 美元，而 256×256 的图像每张 0.016 美元。

更多详情见官网： https://openai.com/pricing

在国内也有一些厂商的提供了完整方案报价，大概是 0.1 到 0.13 每张图。

除了接入 API，有时我们也会基于开源的模型微调后上线自己的服务，这部分成本主要是训练的算力成本和上线后的 GPU 机器。以 ControlNet 模型为例，在公有云上，一台带有 v100 显卡的机器也就能跑一个大模型，且单台机器只能同时为一个用户提供服务。而这样一台 v100 的机器一个月的原价为 7000 多。

不管是调用第三方的 API 还是自行构建模型服务，对于创业公司来说，成本都挺高的。

如果想在 AIGC 中创业，从一开始就需要想好商业模式和变现手段，并且对于免费用户需要从一开始就限制其试用频率，以控制成本。

从应用工程角度，我们大概可以做以下的一些事情：

排队系统，在成本方面主要是应用于自己搭建的服务，其主要是在用户体验和成本之间寻找一个平衡，通过排队的方式将用户的请求量消峰填谷，以尽可能提升机器的利用率。
限频限额，对每个用户在使用次数或产出物的量上做限额，以防止恶意的攻击或者某个用户大量占用资源的情况。在限额方面我们一般可以采用对使用次数，如做图次数，或者对产出物的数量，如生成图片的数量或生成文字的数量等等。可以是日限或者总量限制。
预约系统，提高用户的使用门槛，仅针对目标用户发放资格，减少用户量，提升用户精准度的同时能控制成本。
存储限制，第 2 点的限制主要是针对使用的，如果产品有存储的需求，那么在应用上需要对存储空间的大小或者存储的时长做一些限制，最好是在商业化的逻辑里面把这块加上，因为存储的成本是一个递进累加的成本，随着产品的发展，其成本会越来越大，如果生成的内容中有视频，且你有几百万上千万的用户，这将是一个非常大的成本。

以上主要是应用开发领域的成本，除了这些，其数据成本也是非常大块的成本。而数据是人工智能的基础，没有数据就没有模型。AIGC 需要大量的高质量的数据来训练模型，比如文本、图像、音频、视频等。这些数据的获取和处理是一个巨大的挑战，需要投入大量的时间和金钱。

一方面，数据的来源可能不容易找到或者不免费。比如想要生成游戏场景或者角色，就需要收集各种类型和风格的游戏素材；想要生成影视剧本或者小说，就需要收集各种类型和风格的文学作品；想要生成音乐或者歌曲，就需要收集各种类型和风格的音乐素材。这些数据可能涉及版权问题，需要付费购买或者授权使用。

另一方面，数据的质量可能不够高或者不一致。比如想要生成逼真的人脸图像，就需要收集各种角度和表情的人脸照片；想要生成流畅的语音或者歌声，就需要收集各种语言和口音的语音样本；想要生成合理的对话或者故事情节，就需要收集各种场景和情感的对话或者故事文本。这些数据可能存在噪声、错误、重复、缺失等问题，需要进行清洗、标注、对齐等处理。

因此，在 AIGC 中使用现有数据是一种常见而有效的方法。通过利用公开可用或者自行采集整理好了格式统一且质量较高且数量较多且符合目标任务需求且无版权争议（例如：Common Crawl）的数据集来训练模型可以节省很多时间和金钱。

4 法律法规和版权

4.1 法律法规

2022 年 11 月 25 日，国家网信办、工信部、公安部联合发布《互联网信息服务深度合成管理规定》（以下简称《规定》）。其中提出，深度合成服务提供者和技术支持者提供人脸、人声等生物识别信息编辑功能的，应当提示深度合成服务使用者依法告知被编辑的个人，并取得其单独同意。《规定》自 2023 年 1 月 10 日起施行。

该规定的第五章第二十三条，对「深度合成技术」做了规定：「利用深度学习、虚拟现实等生成合成类算法制作文本、图像、音频、视频、虚拟场景等网络信息的技术。」，这也就是我们所说的 AIGC 的范畴了。

在《规定》的第六条、第七条、第十一条等对服务提供主体责任进行了明确的定义，具体包括：

不得利用深度合成服务制作、复制、发布、传播法律、行政法规禁止的信息，或从事法律、行政法规禁止的活动。
建立健全用户注册、算法机制机理审核、科技伦理审查、信息发布审核、数据安全、个人信息保护、反电信网络诈骗、应急处置等管理制度，具有安全可控的技术保障措施。
制定和公开管理规则、平台公约，完善服务协议，落实真实身份信息认证制度。
加强深度合成内容管理，采取技术或者人工方式对输入数据和合成结果进行审核，建立健全用于识别违法和不良信息的特征库，记录并留存相关网络日志。
建立健全辟谣机制，发现利用深度合成服务制作、复制、发布、传播虚假信息的，应当及时采取辟谣措施，保存有关记录，并向网信部门和有关主管部门报告。

将上面的条文翻译成技术上的点就是要构建以下的系统或服务

用户实名注册及管理系统。
数据安全及敏感信息管理系统和体系。
内容安全管理系统，这里我们常规会采用第三方的服务，而不是自己开发。

4.2 版权

AIGC 的版权一直存在争议，其根源在于 AIGC 模型的形成和完善依赖于大量的数据训练，而用于训练的数据往往包含受版权法保护的内容。AIGC 这种不同于传统的创作方式，目前尚未有明确的法律规定和司法裁定来界定其版权归属和保护范围。

2023 年 1 月 23 日，美国三名漫画艺术家针对包括 Stability AI 在内的三家 AIGC 商业应用公司，在加州北区法院发起集体诉讼，指控 Stability AI 研发的 Stable Diffusion 模型以及三名被告各自推出的、基于上述模型开发的付费 AI 图像生成工具构成版权侵权。

这应该算是全球首例知名的 AIGC 商业化应用领域，算法模型及训练数据版权侵权案。其主要争议点在于当前国内外对于 AIGC 获取与利用版权作品进行算法训练是否合法存在诸多争议，尚无立法和司法层面的明确共识，并且对于模型训练过程中利用版权作品的方式、利用行为的版权定性仍有待分析明确。

在中国，计算机软件和作品的著作权属于开发者或者相关机构，而现行的《著作权法》框架难以直接认定人工智能或电脑算法为作品的作者。但是现阶段各界对于人工智能技术创作物的著作权保护整体上呈现积极的态度，主流的司法实践持相似的立场。AIGC 版权保护的是使用 AI 系统的人，不是 AI 本身，其保护的前提还是使用 AI 创作的人，在创作过程中付出了智力或创造性的劳动。

目前，一些机构和个人在使用 AIGC 作品时，通常会尽力寻找并遵守相应的版权规定和道德准则，尊重原作者的知识产权，同时也会尝试探索 AIGC 版权的可行性和保护方式。

我们需要持续的关注版权方面的进展。

对于版权保护我们可以做如下的一些事情：

数据授权和许可：在使用受版权保护的数据进行模型训练时，尽量获取数据所有者的授权和许可。这可以通过签订合同、购买许可证或加入版权组织等方式实现。
数据脱敏和匿名化：在使用受版权保护的数据进行模型训练时，尽量对数据进行脱敏和匿名化处理，以降低侵权风险。例如，可以删除文本中的作者名、作品名等敏感信息，或将图像中的人物、地点等特征进行模糊处理。
版权标识和归属：在发布和传播 AIGC 生成的作品时，明确标注作品的版权归属和来源。例如，可以在作品页面上添加版权声明、原作者名和许可证信息等。
遵循道德准则：在使用 AIGC 技术进行创作时，遵循行业道德准则和社会公序良俗。例如，不要使用 AIGC 技术制作和传播违法、侵权、淫秽、暴力等不良内容。

5 模型的偏见性

现在大家常用到的 AIGC 技术的核心都是在大规模数据集上预先进行训练的模型，大多数的使用者都是在特定领域或垂直场景下进行微调。这种预训练模型，对比完全由人工规则控制的专家系统来说，预训练模型就像一个黑盒子。没有人能预知其生产出来的内容是什么。

预训练模型的偏见性通常来自训练数据集中的样本分布不均或者存在系统性的偏差。比如：

在 chatGPT 模型中的语言性偏见，中文的内容语料只占了 0.1% 不到，更准确来说应该是 0.09905%，从而使得使用中文的效果远不如英文。
2.14 日情人节前夕发布的 ControlNet 模型，在测试过程中发现其会生成较多的性感卡通类图片，一些没有问题的照片或者词语都能生成极度「性感」的图片，比如痛苦这个词语。
对于时间的偏见性，模型只能了解其生成之前的情况，或者说只能了解其数据集中的信息，在其生成后就没有信息了，除非快速迭代模型。
DALL·E 2 具有显著的种族和性别刻板印象。

除了以上的例子，还有在性别、地域、文化等的偏见性，这些都是因为训练得到的模型并不是非常可控的，模型可以看做对训练集分布的一个拟合。那么反馈到生成模型中，训练数据的分布便是影响生成内容的质量最重要的一个因素。于我们可以采取一些措施来规避将模型的偏见展示给用户。

数据收集阶段：收集更多多样化的训练数据，以确保训练数据集具有平衡性和代表性，对训练数据进行分析和筛选，排除可能引入偏见的因素。
模型训练阶段：在微调阶段使用公平性指标，从而评估模型在不同群体中的表现是否公平和平衡；不断监控和更新模型，及时发现并纠正偏见性问题。对一些特定的任务，可以使用迁移学习等技术，以减少偏见的影响。
产品应用阶段：通过人工或者基于深度学习的模型判断生成的内容是否具有偏见性，以规避一些极端的场景。

我们在上线 AIGC 产品时一定需要深刻的理解其偏见性，及时使用一定的措施规避或者减少其偏见性。

想起网上看到的一句话：「在这个历史性的转折点，只能向前走，不能往后看，过往都被冲得看不着了。」

潘锦的空间 » AI

SaaS 已死？AI 当立？

AI Agent 核心策略：如何判断 Agent 应该停止

常用停止策略

OpenManus 的停止逻辑

核心：terminate 工具

状态机管理

步数限制

卡死检测

Planning Agent 的结束逻辑

1. 计划完成的判断机制

2. 步骤状态检查逻辑

3. 计划结束处理

Gemini CLI 的停止逻辑

subagent 的停止逻辑

1. 达到最大轮次（MAX_TURNS）

2. 执行超时（TIMEOUT）

3. 用户中断（通过 AbortSignal）

4. 错误异常（ERROR）

5. 目标完成（GOAL）

声明式输出系统的实现

Nudge 机制

完整的 subagent 执行流程

三层循环检测机制

第一层：工具调用重复检测

第二层：内容重复检测（”咒语”检测）

第三层：LLM 智能检测

三种循环类型

小结

关于 AI Agent： 从 Manus 聊起

1. 从专家系统说起

2. 现代 AI Agent 的样子

3. 核心技术和架构

3.1 感知模块

3.2 推理模块

3.3 记忆模块

3.3.1 记忆的层次结构

3.3.2 实现方案-RAG（检索增强生成）

3.3.3 实现方案-超长上下文

3.3.4 主动遗忘

3.4 行动模块

4. 当前的局限性

4.1 幻觉问题

4.2 可靠性不足

4.3 成本与效率

4.4 安全与隐私挑战

4.5 理解与推理的局限

5. 写在最后

代码生成之外：AI 编程对开发者思维的深层影响

1. AI 优先

1.1 核心内涵：从默认手动到优先 AI 协作

1.2 思维转变的深度体现

1.3 实践示例

2. 指挥官思维

2.1 核心内涵：从执行者到战略决策者的角色升维

2.2 思维转变的深度体现

3. 向 AI 学习

3.1 核心内涵：从工具利用到知识伙伴的认知定位转变

3.2 思维转变的深度体现

3.3 实践示例

4. 构建「人机协同」的复合思维框架

4.1 核心内涵：超越工具使用，构建结构化的智能协作体系

4.2 框架三大支柱

4.2.1 问题拆解能力

4.2.2 批判性验证意识

4.2.3 动态协作模式

关于 AI 解决问题能力的思考

如何面对「AI 焦虑」

什么是「AI 焦虑」？

AI 到底会不会「抢走我们饭碗」？

AI的绝对优势领域

AI的认知天花板

为什么你会特别焦虑？

如何正面应对 AI 焦虑？

1. 从抗拒到接纳：停止「逃避感」

2. 从被动到主动：开始「有手感」

3. 从焦虑到学习：构建「成长感」

开启人机协作时代

1. 能力分层：让 AI 做擅长的，人类做关键的

2. 思维互补：用 AI 拓宽选择空间，人类负责价值筛选

关于 AI Agent：从 Manus 聊起