IT社区推荐资讯 - ITIndex.net

gstack：YC总裁开源的”AI软件工厂”，68k Star的工具到底香不香？

Thu, 09 Apr 2026 22:41:07 CST

第一次看到这个项目的时候，我愣了几秒。

Garry Tan——Y Combinator的总裁，全球最顶级孵化器的掌舵人——居然把自己每天用的Claude Code配置开源了？而且还专门强调这是他” opinionated tools”，意思是一套带强烈个人偏好的工具链？68k star、9.4k fork，这个数字在GitHub上是什么概念我就不用说了吧。

更让我好奇的是：他声称用这套东西，60天写了60万行生产代码。一个人的效率，真的能顶一个20人团队？

我花了几天时间认真研究了一下，今天来聊聊gstack到底是个什么东西。

一、gstack是什么？

简单说，gstack是一套开源的AI软件工厂工具，把Claude Code变成了一个虚拟工程团队。

Garry Tan把它描述为”23个专业角色+8个强大工具”，每个角色各司其职：CEO帮你做战略审查、Designer帮你做设计系统、Eng Manager帮你做架构评审、QA帮你做浏览器测试……你一个人坐在那里，AI们在背后协作。

核心技术栈是TypeScript（71.2%）+ Go Template（18.9%），依赖Bun v1.0+或Node.js运行，用Playwright做浏览器自动化，支持macOS和Windows（通过WSL/Git Bash）。

二、数据情况

指标	数据
Star数	68k
Fork数	9.4k
Watchers	379
许可证	MIT

数据来源：GitHub公开数据

这个量级的star说明什么？要么是真的好用，要么是Garry Tan的名字太响。从我了解到的社区反馈来看，两方面原因都有。Garry本人说他在60天内用这套工具写了60万行生产代码，35%的代码是测试代码——这个比例在行业内算是相当高的质量追求了。

三、核心功能有哪些？

gstack的功能分成四个阶段：

规划阶段

/office-hours：产品定义和需求分析，AI会追问你的具体痛点
/plan-ceo-review：CEO级别的战略审查，挑战你的产品方向
/plan-eng-review：工程架构审查，设计数据流和技术方案
/plan-design-review：设计审查，确保设计符合工程可行性

构建阶段

/design-consultation：构建完整设计系统
/design-shotgun：AI原型设计探索，快速出多个方案
/design-html：生成生产级HTML/CSS

测试阶段

/review：代码审查和自动修复
/qa：真实浏览器测试（用的是Playwright，防机器人检测）
/cso：安全审计（OWASP Top 10 + STRIDE模型）

发布阶段

/ship：发布管理
/land-and-deploy：生产部署验证
/canary：部署后监控

光看功能列表可能觉得有点虚，我举个例子：你在Claude Code里说”我想做个日历应用”，然后这套工具会依次跑：产品需求分析→CEO战略审查→工程架构评审→设计系统构建→编写代码（2400行约8分钟）→代码审查修复→真实浏览器QA→创建PR。全流程自动化。

四、面向的人群有哪些？

用户类型	适用场景
独立开发者	一个人搞定全栈产品
小团队（2-5人）	提升工程质量和发布效率
初创公司	减少人力成本，加速MVP迭代
大公司内部工具	为AI编码代理提供标准化流程

说实话，这套工具对个人开发者和小团队最有价值。如果你本身就在一个大公司、有完整的工程团队，这套东西可能没那么必要——你们的流程本来就有专人负责。但对于”全栈独立开发者”或者小团队，这就是效率放大器。

五、应用场景有哪些？

场景1：快速原型验证

有个点子想快速验证？用office-hours+design-shotgun，AI帮你快速出产品方案和原型，不用先招人。

场景2：代码质量把关

写了代码担心有问题？/review自动修复+/qa真实浏览器测试，这俩组合基本能覆盖大部分常见bug。

场景3：安全审计

发布前想做个安全检查？/cso基于OWASP Top 10 + STRIDE模型，比大多数创业公司自己做的安全审查专业多了。

场景4：持续部署

接入了CI/CD但每次发布还是提心吊胆？/land-and-deploy+/canary帮你做部署验证和上线后监控。

六、和同类竞品的差异有哪些？

gstack本质上是一套Claude Code的技能包，和普通的AI编码代理相比，核心差异在于：

对比项	普通AI编码代理	gstack
角色分工	单代理啥都干	23个专业角色各司其职
代码审查	基础lint	CEO/工程架构级别审查
测试	简单单元测试	真实浏览器QA+安全审计
发布流程	手动操作	自动化发布+监控
适用规模	个人辅助	可支撑团队协作

但要注意，gstack主要是给Claude Code用户用的。不过它也支持其他AI编码代理：OpenAI Codex CLI、Cursor、Factory Droid等8种，算是有一定的跨平台能力。

七、使用技巧

技巧1：先用office-hours明确定义产品

很多人直接让AI写代码，结果写了一半发现方向不对。在开始写代码之前先用/office-hours让AI追问你的需求，这个前置动作能省很多返工时间。

技巧2：并行sprint不是噱头

Garry Tan说支持10-15个并行sprint，这不是吹的。你可以让规划、设计、测试同时跑，对于有明确里程碑的项目确实能大幅压缩周期。

技巧3：review之前先确认代码规范

gstack的代码审查很强，但如果你有自己的代码规范文档，最好先提供给AI。不然它会按自己的风格来，可能会和你现有代码风格有出入。

技巧4：团队模式要用对

gstack有团队模式（–team参数），适合多人协作场景。但如果你是个人开发者，用默认模式就够了，别把简单事情搞复杂。

八、对企业和个人的价值

价值维度	个人开发者	企业用户
效率提升	1人顶N人	降低人力成本
质量保障	自动审查+测试	标准化工程流程
知识沉淀	学习Garry的工程思维	沉淀为团队工具链
风险控制	自动化减少人为失误	安全审计前置

说实话，gstack对我最有吸引力的不是那些花哨功能，而是Garry Tan这个人本身——他是YC总裁，每天看几千个项目，什么样的工程实践是好实践，他比大多数人都清楚。这套工具反映的是他的工程哲学，花68k star去围观这个人的工作方式，本身就值回票价。

九、产品定价

版本	价格	说明
开源版	免费	MIT许可证，全部功能开源
商业使用	需遵守MIT	无额外限制

gstack是100%开源项目，MIT许可证，基本没什么使用限制。如果你公司在用Claude Code，直接部署就行，不用额外付费。

十、项目地址

GitHub仓库：https://github.com/garrytan/gstack

快速安装（在Claude Code中运行）：

  
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

团队模式安装：

  
cd ~/.claude/skills/gstack && ./setup --team
cd <your-repo>
~/.claude/skills/gstack/bin/gstack-team-init required

总体评价

gstack让我想起一句话：牛人不可怕，可怕的是牛人还比你努力。Garry Tan作为YC总裁，妥妥的人生赢家，结果他把压箱底的工具配置开源了，还附赠60万行代码的生产记录。这种量级的分享，在圈子里确实不多见。

从工具本身来说，23个专业角色覆盖了产品、设计、工程、测试、发布的完整流程，对于个人开发者和小团队来说确实能大幅提升效率。真实浏览器QA和安全审计这两个功能，在同类型工具里算是比较少见的。

但也要说，这套东西不是银弹。它最适合的场景是：你想快速验证产品方向、需要高质量代码输出、但团队人又不多。如果你本身就有完整的工程团队，这套东西能提供的增量价值有限。

另外，它强依赖Claude Code，如果你是Cursor或其他工具的重度用户，迁移成本不低。

一个AI开发工作流

Fri, 03 Apr 2026 11:01:00 CST

我现在的 flow 是：先前端 + mock 数据（claude + gemini）然后再 codex 写代码 claude review codex 自己跑 playwright 做 e2e 测试我自己验收，关 issue 主要是 codex 前端真不行，一把梭 AI 太放飞现在的问题是：claude 用量太少，成本有点高；gemini cli 慢成狗你们玩的？

-- 我感觉现在国产模型因为过于注重主观和跑分，前端能力很强，第一步换成 kimi 或者 glm，claude 的用量就降下来了，gemini 被薅太狠已经没法用了

--测试的skill基本上就是 skills.sh 排名靠前那些了

http:// 我发现 skills 还是得自己造你多看看头部那些 skills 的具体内容，学习下他们是怎么约束 AI 的，然后自己造就跟以前看优秀开源项目的代码一样

一文了解 Anthropic 的 Claude Code 源码：为什么它就是比别人好用？

Thu, 02 Apr 2026 08:56:23 CST

2026年3月31日，安全研究者 Chaofan Shou 发现 Anthropic 发布到 npm 的 Claude Code 包中，source map 文件没有被剥离。

这意味着：Claude Code 的完整 TypeScript 源码，51.2万行，1903个文件，就这样暴露在了公网上。

我当然不可能在短短数小时内看完这么多代码，因此，我带着三个问题去读这份源码：

Claude Code 和其他 AI 编程工具到底有什么本质区别？

为什么它写代码的"手感"就是比别人好？

51万行代码里，到底藏着什么？

读完之后，我的第一反应是：这不是一个 AI 编程助手，这是一个操作系统。

一、先讲一个故事：如果你要雇一个远程程序员

想象你雇了一个远程程序员，给他你电脑的远程访问权限。

你会怎么做？

如果你是 Cursor 的做法：你让他坐在你旁边，每次他要敲命令之前你看一眼，点个"允许"。简单粗暴，但你得一直盯着。

如果你是 GitHub Copilot Agent 的做法：你给他一台全新的虚拟机，让他在里面随便折腾。搞完了把代码提交上来，你审核后再合并。安全，但他看不到你本地的环境。

如果你是 Claude Code 的做法：

你让他直接用你的电脑——但你给他配了一套极其精密的安检系统。他能做什么、不能做什么、哪些操作需要你点头、哪些可以自己来、甚至他想用 rm -rf 都要经过9层审查才能执行。

这就是三种完全不同的安全哲学：

为什么 Anthropic 选了最难的那条路？

因为只有这样，AI 才能用你的终端、你的环境、你的配置来干活——这才是"真正帮你写代码"，而不是"在一个干净房间里给你写一段代码然后复制过来"。

但代价是什么？他们为此写了 51 万行代码。

二、你以为的 Claude Code vs 实际的 Claude Code

大多数人以为 AI 编程工具是这样的：

plaintext

用户输入 → 调用 LLM API → 返回结果 → 显示给用户

Claude Code 实际是这样的：

plaintext

用户输入

→ 动态组装 7 层系统提示词

→ 注入 Git 状态、项目约定、历史记忆

→ 42 个工具各自附带使用手册

→ LLM 决定使用哪个工具

→ 9 层安全审查（AST 解析、ML 分类器、沙箱检查...）

→ 权限竞争解析（本地键盘 / IDE / Hook / AI 分类器同时竞争）

→ 200ms 防误触延迟

→ 执行工具

→ 结果流式返回

→ 上下文接近极限？→ 三层压缩（微压缩 → 自动压缩 → 完全压缩）

→ 需要并行？→ 生成子 Agent 蜂群

→ 循环直到任务完成

相信大家都很好奇上面的是什么，不着急，让我们逐个拆开看。

三、第一个秘密：提示词不是写出来的，是"拼装"出来的

打开 src/constants/prompts.ts，你会看到这个函数：

typescript

export async function getSystemPrompt(

tools: Tools,

model: string,

additionalWorkingDirectories?: string[],

mcpClients?: MCPServerConnection[],

): Promise<string[]> {

return [

// --- 静态内容（可缓存）---

getSimpleIntroSection(outputStyleConfig),

getSimpleSystemSection(),

getSimpleDoingTasksSection(),

getActionsSection(),

getUsingYourToolsSection(enabledTools),

getSimpleToneAndStyleSection(),

getOutputEfficiencySection(),

// === 缓存边界 ===

...(shouldUseGlobalCacheScope() ? [SYSTEM_PROMPT_DYNAMIC_BOUNDARY] : []),

// --- 动态内容（每次不同）---

...resolvedDynamicSections,

].filter(s => s !== null)

}

注意到那个 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 了吗？

这是一个缓存分界线。分界线上面的内容是静态的，Claude API 可以缓存它们，节省 token 费用。分界线下面的内容是动态的——你当前的 Git 分支、你的 CLAUDE.md 项目配置、你之前告诉它的偏好记忆……每次对话都不一样。

这意味着什么？

Anthropic 把提示词当成了编译器的输出来优化。静态部分是"编译后的二进制"，动态部分是"运行时参数"。这样做的好处是：

省钱：静态部分走缓存，不重复计费

快：缓存命中直接跳过这些 token 的处理

灵活：动态部分让每次对话都能感知当前环境

⛏️每个工具都有独立的"使用手册"

更让我震惊的是：每个工具目录下都有一个 prompt.ts 文件——这是专门写给 LLM 看的使用手册。

看看 BashTool 的（src/tools/BashTool/prompt.ts，约 370 行）：

plaintext

Git Safety Protocol:

- NEVER update the git config

- NEVER run destructive git commands (push --force, reset --hard,

checkout .) unless the user explicitly requests

- NEVER skip hooks (--no-verify) unless the user explicitly requests

- CRITICAL: Always create NEW commits rather than amending

这不是写给人看的文档，这是写给 AI 看的行为准则。每次 Claude Code 启动时，这些规则都会被注入到系统提示词中。

这就是为什么 Claude Code 从不会擅自 git push --force，而某些工具会——不是模型更聪明，是提示词里已经把规矩讲清楚了。

而且 Anthropic 内部版本和你用的不一样

代码里大量出现这样的分支：

typescript

const minimalUniquenessHint =

process.env.USER_TYPE === 'ant'

? '\n- Use the smallest old_string that\'s clearly unique'

: ''

ant 就是 Anthropic 内部员工。他们的版本有更详细的代码风格指引（"不写注释除非 WHY 不明显"）、更激进的输出策略（"倒金字塔写作法"），以及一些仍在 A/B 测试的实验功能（Verification Agent、Explore & Plan Agent）。

这说明 Anthropic 自己就是 Claude Code 最大的用户。他们在用自己的产品来开发自己的产品。

四、第二个秘密：42个工具，但你只看到了冰山一角

打开 src/tools.ts，会看到工具注册中心：

typescript

export function getAllBaseTools(): Tools {

return [

AgentTool,

BashTool,

FileReadTool, FileEditTool, FileWriteTool,

GlobTool, GrepTool,

WebFetchTool, WebSearchTool,

TodoWriteTool, NotebookEditTool,

// ... 大量条件加载的工具 ...

...(isToolSearchEnabledOptimistic() ? [ToolSearchTool] : []),

]

}

42 个工具，但大部分你从未直接看到过。因为很多工具是延迟加载的——只有当 LLM 需要时，才通过 ToolSearchTool 按需注入。

为什么这样做呢？

因为每多一个工具，系统提示词就要多一段描述，token 就要多花一份钱。如果你只是想让 Claude Code 帮你改一行代码，它不需要加载"定时任务调度器"和"团队协作管理器"。

还有一个更聪明的设计：

typescript

if (isEnvTruthy(process.env.CLAUDE_CODE_SIMPLE)) {

const simpleTools: Tool[] = [BashTool, FileReadTool, FileEditTool]

return filterToolsByDenyRules(simpleTools, permissionContext)

}

设置 CLAUDE_CODE_SIMPLE=true，Claude Code 就只剩三个工具：Bash、读文件、改文件。这是给极简主义者的后门。

1️⃣所有工具都从同一个工厂出来

typescript

const TOOL_DEFAULTS = {

isEnabled: () => true,

isConcurrencySafe: (_input?) => false, // 默认：不安全

isReadOnly: (_input?) => false, // 默认：会写入

isDestructive: (_input?) => false,

}

export function buildTool<D extends AnyToolDef>(def: D): BuiltTool<D> {

return { ...TOOL_DEFAULTS, userFacingName: () => def.name, ...def }

}

注意那些默认值：isConcurrencySafe 默认 false，isReadOnly 默认 false。

这叫 fail-closed 设计——如果一个工具的作者忘了声明安全属性，系统会假设它是"不安全的、会写入的"。宁可过度保守，也不漏掉一个风险。

2️⃣"先读后改"的铁律

typescript

function getPreReadInstruction(): string {

return '\n- You must use your `Read` tool at least once in the

conversation before editing. This tool will error if you attempt

an edit without reading the file.'

}

FileEditTool 会检查你是否已经用 FileReadTool 读过这个文件。如果没有，直接报错，不让改。

这就是为什么 Claude Code 不会像某些工具那样"凭空写一段代码覆盖你的文件"——它被强制要求先理解再修改。

五、第三个秘密：记忆系统——为什么它能"记住你"

用过 Claude Code 的人都有一个感受：它好像真的认识你。

你告诉它"不要在测试中 mock 数据库"，下次对话它就不会再 mock。你告诉它"我是后端工程师，React 新手"，它解释前端代码时就会用后端的类比。

这背后是一个完整的记忆系统。

1️⃣用 AI 来检索记忆

typescript

const SELECT_MEMORIES_SYSTEM_PROMPT =

`You are selecting memories that will be useful to Claude Code.

Return a list of filenames for the memories that will clearly

be useful (up to 5).

- If you are unsure if a memory will be useful, do not include it.

- If a list of recently-used tools is provided, do not select

memories that are usage reference for those tools. DO still

select memories containing warnings, gotchas, or known issues.`

Claude Code 用另一个 AI（Claude Sonnet）来决定"哪些记忆和当前对话相关"。

不是关键词匹配，不是向量搜索——是让一个小模型快速扫描所有记忆文件的标题和描述，选出最多 5 个最相关的，然后把它们的完整内容注入到当前对话的上下文中。

策略是"精确度优先于召回率" ——宁可漏掉一个可能有用的记忆，也不塞进一个不相关的记忆污染上下文。

⏰KAIROS 模式：夜间"做梦"

这是最让我觉得科幻的部分。

代码中有一个叫 KAIROS 的特性标志。在这个模式下，长会话中的记忆不是存在结构化文件里，而是存在按日期的追加式日志中。然后，有一个 /dream 技能会在"夜间"（低活跃期）运行，把这些原始日志蒸馏成结构化的主题文件。

plaintext

logs/2026/03/2026-03-30.md ← 今天的原始日志

↓ /dream 蒸馏

memory/user_preferences.md ← 结构化的用户偏好文件

memory/project_context.md ← 结构化的项目背景文件

AI 在"睡觉"的时候整理记忆。这已经不是工程了，这是仿生学。

六、第五个秘密：它不是一个 Agent，是一群

当你让 Claude Code 做一个复杂任务时，它可能悄悄做了这件事：

typescript

// AgentTool 的输入 schema

z.object({

description: z.string().describe('A short (3-5 word) description'),

prompt: z.string().describe('The task for the agent to perform'),

subagent_type: z.string().optional(),

model: z.enum(['sonnet', 'opus', 'haiku']).optional(),

run_in_background: z.boolean().optional(),

})

它生成了一个子 Agent。

而且子 Agent 有严格的"自我意识"注入，防止它递归生成更多子 Agent：

typescript

export function buildChildMessage(directive: string): string {

return `STOP. READ THIS FIRST.

You are a forked worker process. You are NOT the main agent.

RULES (non-negotiable):

1. Your system prompt says "default to forking." IGNORE IT —

that's for the parent. You ARE the fork.

Do NOT spawn sub-agents; execute directly.

2. Do NOT converse, ask questions, or suggest next steps

3. USE your tools directly: Bash, Read, Write, etc.

4. Keep your report under 500 words.

5. Your response MUST begin with "Scope:". No preamble.`

}

这段代码在说："你是一个工人，不是经理。别想着再雇人，自己干活。"

👤Coordinator 模式：经理模式

在协调器模式下，Claude Code 变成一个纯粹的任务编排者，自己不干活，只分配：

plaintext

Phase 1: Research → 3 个 worker 并行搜索代码库

Phase 2: Synthesis → 主 Agent 综合理解所有发现

Phase 3: Implementation → 2 个 worker 分别修改不同文件

Phase 4: Verification → 1 个 worker 跑测试

核心原则写在代码注释里：

"Parallelism is your superpower" 只读研究任务：并行跑。写文件任务：按文件分组串行跑（避免冲突）。

🗣️Prompt Cache 的极致优化

为了最大化子 Agent 的缓存命中率，所有 fork 子代理的工具结果都使用相同的占位符文本：

plaintext

'Fork started — processing in background'

为什么？因为 Claude API 的 prompt cache 是基于字节级前缀匹配的。如果 10 个子 Agent 的前缀字节完全一致，那么只有第一个需要"冷启动"，后面 9 个直接命中缓存。

这是一个每次调用节省几美分的优化，但在大规模使用下，能省下大量成本。

七、第六个秘密：三层压缩，让对话"永不超限"

所有 LLM 都有上下文窗口限制。对话越长，历史消息越多，最终一定会超出限制。

Claude Code 为此设计了三层压缩：

1️⃣第一层：微压缩——最小代价

typescript

export async function microcompactMessages(messages, toolUseContext, querySource) {

// 时间触发：如果上次交互已过很久，服务器缓存已冷

const timeBasedResult = maybeTimeBasedMicrocompact(messages, querySource)

if (timeBasedResult) return timeBasedResult

// 缓存编辑路径：通过 API 的缓存编辑功能直接删除旧内容

if (feature('CACHED_MICROCOMPACT')) {

return await cachedMicrocompactPath(messages, querySource)

}

微压缩只动旧的工具调用结果——把"10分钟前读的那个500行文件的内容"替换成 [Old tool result content cleared]。

提示词和对话主线完全保留。

2️⃣第二层：自动压缩——主动收缩

当 token 消耗接近上下文窗口的 87%（窗口大小 - 13,000 buffer），自动触发。有一个熔断器：连续 3 次压缩失败后停止尝试，避免死循环。

3️⃣第三层：完全压缩——AI 总结

让 AI 对整段对话生成摘要，然后用摘要替换所有历史消息。生成摘要时有一个严厉的前置指令：

typescript

const NO_TOOLS_PREAMBLE = `CRITICAL: Respond with TEXT ONLY.

Do NOT call any tools.

- Do NOT use Read, Bash, Grep, Glob, Edit, Write, or ANY other tool.

- Tool calls will be REJECTED and will waste your only turn.`

为什么要这么严厉？因为如果总结过程中 AI 又去调用工具，就会产生更多的 token 消耗，适得其反。这段提示词就是在说："你的任务是总结，别干别的。"

压缩后的 token 预算：

文件恢复：50,000 tokens

每个文件上限：5,000 tokens

技能内容：25,000 tokens

这些数字不是拍脑袋定的——它们是在"保留足够上下文继续工作"和"腾出足够空间接收新消息"之间的平衡点。

八、读完这份源码，我学到了什么

1️⃣AI Agent 的 90% 工作量在"AI"之外

51 万行代码里，真正调用 LLM API 的部分可能不到 5%。其余 95% 是什么？

安全检查（18 个文件只为一个 BashTool）

权限系统（allow/deny/ask/passthrough 四态决策）

上下文管理（三层压缩 + AI 记忆检索）

错误恢复（熔断器、指数退避、Transcript 持久化）

多 Agent 协调（蜂群编排 + 邮箱通信）

UI 交互（140 个 React 组件 + IDE Bridge）

性能优化（prompt cache 稳定性 + 启动时并行预取）

如果你正在做 AI Agent 产品，这才是你真正要解决的问题。不是模型够不够聪明，是你的脚手架够不够结实。

2️⃣好的提示词工程是系统工程

不是写一段漂亮的 prompt 就完事了。Claude Code 的提示词是：

7 层动态组装

每个工具附带独立的使用手册

缓存边界精确划分

内部版本和外部版本有不同的指令集

工具排序固定以保持缓存稳定

这是工程化的提示词管理，不是手工艺。

3️⃣为失败而设计

每一个外部依赖都有对应的失败策略：

4️⃣Anthropic 把 Claude Code 当操作系统在做

42 个工具 = 系统调用权限系统 = 用户权限管理技能系统 = 应用商店 MCP 协议 = 设备驱动 Agent 蜂群 = 进程管理上下文压缩 = 内存管理 Transcript 持久化 = 文件系统

这不是一个"聊天机器人加几个工具"，这是一个以 LLM 为内核的操作系统。

总结

51 万行代码。1903 个文件。18 个安全文件只为一个 Bash 工具。

9 层审查只为让 AI 安全地帮你敲一行命令。

这就是 Anthropic 的答案：要让 AI 真正有用，你不能把它关在笼子里，也不能放它裸奔。你得给它建一套完整的信任体系。

而这套信任体系的代价，是 51 万行代码。

一堂北大散户生存教育课

Thu, 02 Apr 2026 08:54:38 CST

第一讲：概述

1. 股市的本质

“股市的本质，是一个为企业提供融资渠道、为投资者提供投资机会的资本市场。它承担的是资源配置、价格发现和价值交换的功能，不是专门为散户设计的致富工具。普通人想靠炒股快速翻身，本质上是在和机构、大资金、信息优势者博弈，胜率极低。”

补充强调：“股市的基本功能是融资和资源配置，不是让散户致富。短期交易更接近零和博弈，长期持有优质资产或指数，才可能分享到经济增长的红利。”

2. 炒股基础知识

“先懂规则，再谈赚钱。市场参与者大致可以分为机构、大户和散户，散户处在最弱势的位置。你没有资金优势，没有信息优势，也没有制度优势，只有时间、耐心和认知，能依靠的其实很有限。”

补充强调：“短期交易里，有人赚就一定有人亏，手续费、滑点、情绪成本还会不断侵蚀总收益。看不清自己所处的位置，就很容易成为被收割的一方。”

3. 股市是较难的一种赚钱方式

“市场长期是‘七亏二平一赚’。超过90%的散户最后是亏损的。你凭什么觉得自己会是那10%？靠运气？靠消息？还是靠一时的热情？如果没有足够的时间研究、足够稳定的系统、足够克制的执行力，想在这个市场长期盈利，本来就是一件极难的事。”

补充强调：“股市门槛看起来很低，开户就能进，但真正的门槛不是开户，而是认知。低门槛行业里的高利润，从来都属于少数高认知者。”

4. 为什么还要讲炒股？

“我讲炒股，不是为了鼓励大家下场重仓投机，恰恰相反，是为了让更多人对这个市场保持敬畏。很多年轻人连规则和常识都没搞明白，就敢拿真金白银去赌，这种亏损往往不是技术问题，而是认知问题。这堂课，本质上是在给大家打预防针。”

补充强调：“如果听完之后，你选择少碰个股、少做冲动交易、转而长期配置指数基金，我反而觉得这堂课讲成功了。”

5. 炒股盈利的要诀和原则

“盈利的核心，不是某个神奇技术，而是交易系统、认知门槛和执行纪律。机构有资金、有研究团队、有信息链条，散户往往只有手机和情绪。你拿什么和别人拼？不懂不做，守住能力圈，有边界、不越界，这才是散户真正的生存之道。”

补充强调：“交易不是预测，而是应对。不要总想着猜明天涨跌，而要先建立规则：什么时候买，为什么买；什么时候卖，为什么卖；错了怎么办，亏多少必须走。”

6. 从炒作的例子探究如何炒股挣钱？

“所谓‘炒作赚钱’，很多时候并不是什么价值发现，而是大资金利用信息差、情绪差、节奏差完成收割。你看到的利好消息，可能是别人准备出货前的烟雾；你忍不住追进去的那个瞬间，可能就是替别人接盘的开始。对普通人来说，盲目参与炒作，不叫投资，更像赌博。”

补充强调：“真正能活下来的，不是追消息最快的人，而是最有耐心、最守纪律、最懂得放弃的人。”

第二讲：分析框架

“分析股市，要从宏观、行业、公司三个维度入手。这个框架的价值，不是帮你抓住每一只牛股，而是帮你避开大坑。”

1. 宏观维度

“股市会提前反映经济周期。经济繁荣、衰退、萧条、复苏，市场往往比现实更早做出反应。很多人以为自己买什么都不涨、卖什么都涨，是能力问题，其实很多时候是周期问题。普通人先判断周期，再决定是否入场，而不是天天盯盘猜明天红还是绿。”

2. 行业维度

“行业也有生命周期，初创期、成长期、成熟期、衰退期，每个阶段的投资逻辑都不同。选股之前先选赛道，而不是看哪个代码顺眼就买哪个。赛道错了，再努力的公司也很难有大的表现；行业对了，很多公司会被整体抬起来。”

3. 公司维度

“看公司主要抓三点：第一，商业模式靠什么赚钱；第二，盈利能不能持续；第三，现在的估值贵不贵。财务造假、概念泡沫、估值虚高，是散户最容易踩的大坑。看不懂财报、看不懂逻辑，就不要硬做个股，老老实实配置指数基金，反而更适合大多数人。”

第三讲：交易体系四大模块

“完整的交易体系，比选股技巧重要得多。散户和机构真正的差距，不只在研究能力，更在有没有体系、能不能长期一致执行。”

1. 选股

“坚守能力圈，懂得主动放弃。你不懂医药，就不要碰医药；不懂科技，就不要碰科技。不是所有的钱都该你赚。放弃自己看不懂的机会，本身就是一种能力。不懂不做，是最好的风控。”

2. 交易

“重纪律，轻预测；以应对替代预测。不要天天猜明天涨还是跌，提前定好规则：到什么位置买、到什么位置卖、什么情况下离场。买入有理由，卖出有条件，不靠情绪，不靠盘中冲动。”

3. 仓位

“仓位管理比选股更重要。方向对了，仓位太轻，赚不到多少；方向错了，仓位太重，一次就可能把你打残。永远不要满仓，不要一把梭哈，要给自己留预备队、留安全边际、留翻身的机会。”

补充实操：

“首次开仓不要满仓，课件里给出的思路是类似‘334仓位法’：

30%底仓，30%机动仓，40%现金等待机会。”

4. 风控

“生存优先于盈利。先保证不亏大钱，再去想怎么赚小钱。止损不是认输，是保护本金。亏到一定比例必须离场，不要总幻想‘还能涨回来’。市场里最常见的悲剧，就是小亏拖成大亏，最后越套越深。”

补充实操：“止损要快，止盈要慢。比如跌破关键均线、跌破预设比例，就机械执行，不和市场争辩。”

第四讲：散户常见误区

“散户亏损，很多时候不是因为不会画线、不会看指标，而是因为认知和心态出了问题。”

1. “把投资当成业余爱好，却想拿到专业选手级的收益，总想着一夜暴富。” ❎

2. “买之前只花几分钟，听个消息、看个推荐就下单，没有自己的判断框架。” ❎

3. “拿不住真正的好股票，却对垃圾股、亏损股恋恋不舍。” ❎

4. “涨了就贪，跌了就怕，追涨杀跌，被情绪推着走。” ❎

5. “道理都懂，但一到盘面就失控，知行完全分离。” ❎

6. “盲目跟风，别人买什么就买什么，没有独立思考能力。” ❎

7. “过度迷信消息、追求买点精准、追求确定性，反而忽视了风险控制。” ❎

8. “总想靠意念炒股，用‘我觉得’代替数据、结构和趋势。” ❎

第五讲：顺势而为与交易原则

“这套课反复讲的一个关键词，就是：顺势而为。”

1. 顺势而为

“趋势一旦形成，往往不会轻易改变。真正好的交易，不是抄最精准的底，而是站在趋势这一边。顺趋势，你的错误往往只是暂时的；逆趋势，你哪怕一时判断对了，也很难赚到钱。”

2. 趋势判断

“判断趋势，不需要太玄。最基本的工具就是均线系统和趋势线。均线能帮你判断市场温度，趋势线能帮你看方向。上升趋势看低点抬高，下降趋势看高点下移，先看大方向，再想操作。”

3. 三大原则

“课件里把交易原则归纳得很清楚：

第一，保障资本；

第二，稳健盈利；

第三，追求卓越。

先活下来，才能谈复利；先控制回撤，才能谈持续赚钱。”

第六讲：四大炒股挣钱法则

1. 仓位管理 > 选股能力

“首次开仓永远不满仓，永远给自己留预备队。很多人不是死在看错，而是死在看对了也满仓、看错了也死扛。”

2. 止损纪律 > 分析预测

“止损要快，止盈要慢。分析可以犯错，但纪律不能失守。技术分析学得再多，止损做不到，最后还是会被市场教育。”

3. 逻辑验证 > 消息内幕

“听消息买，至少要眼见为实。为什么涨？谁在买？还有没有空间？先问清楚逻辑，再决定是否参与，而不是听见‘内幕’两个字就冲进去。”

4. 等待 > 操作

“等待是一种能力。很多人亏钱，不是因为错过机会，而是因为手太痒。市场天天开门，机会永远有，但本金亏没了，就真的没有下一次了。看不懂的时候看戏，往往比乱动强得多。”

第七讲：主力、结构与炒作

“课件后半段其实已经把‘炒作’说得很直白了：大多数所谓的强势股走势，背后都有主力建仓、洗盘、拉升、出货的结构。散户最容易在两种时候犯错：主力洗盘时被甩下车，主力出货时冲进去接盘。”

1. 主力运作全景

“建仓、洗盘、拉升、横盘、出货，这是常见结构。主力会想方设法让散户在低位交出筹码，又在高位兴奋接盘。”

2. 散户能做什么？

“不是去和主力斗，而是去理解结构、跟随结构。看得懂趋势，看得懂量价，看得懂主力意图，只做自己真正看明白的一段。”

3. 核心提炼

“一板定热点，二板定龙头，找主线研究。不要见什么涨就追什么，要先判断它是不是市场真正的主线。”

第八讲：投资劝诫

“投资成功 = 天命 + 运气 + 个人努力。普通人没有必要把股市幻想成改变命运的唯一通道。”

- “北大学生真正的优势，是学历、专业、平台、人脉和长期发展空间。把这些优势用在事业上，往往比在股市赌运气更靠谱，不要舍本逐末。”

- “止损纪律远重于技术分析。技术分析可以慢慢学，但如果你做不到止损，再好的分析都救不了你。

- “长期配置宽基指数基金，是普通人分享经济增长更稳妥的方式。比起瞎炒个股、追热点、赌消息，指数基金更适合大多数没有时间、没有专业训练的人。”

- “最后一句：股市不是致富捷径，而是高风险竞争场。先学会不亏钱，再谈怎么赚钱；守住纪律、认清自己、尊重趋势，比什么技巧都重要。”

风险提示：所有文章仅代表个人观点，与平台立场无关。投资决策需建立在独立思考和风险承受能力之上。

欧洲国家快速拥抱绿色技术和电动汽车

Thu, 02 Apr 2026 00:14:26 CST

因霍尔木兹海峡封锁推高世界各地的油气价格，欧洲多国转向了绿色技术购买了更多电动汽车。数据显示，3 月前三周英国热泵销量较上月同期增长 51%，太阳能销量增长 54%，电动汽车充电器销量增长 20%。法国二手车在线零售商 Aramisauto 的电动汽车销量在 2 月中旬到 3 月 9 日期间几乎翻了一番。阿姆斯特丹二手车交易平台 Olx 表示它在法国、罗马尼亚、葡萄牙和波兰的平台上电动汽车的客户咨询量激增。挪威最大二手车交易平台 Finn.no 上电动汽车销量超过了柴油车。

微軟直接在 Copilot 使用條款裡面說 Copilot 是娛樂用途

Thu, 02 Apr 2026 00:24:59 CST

在「 Microsoft Copilot Terms of Use ( via)」這邊看到的，微軟直接在 Copilot 的使用條款裡面這樣寫 for entertainment purposes only：

Copilot is for entertainment purposes only. It can make mistakes, and it may not work as intended. Don’t rely on Copilot for important advice. Use Copilot at your own risk.

看了一下網址，okay，是微軟官網沒錯，網址看起來是 Terms of Use 沒錯...

其他家的免責大多就只講無法保障 AI 產生出來的東西的正確性，微軟寫的這麼... 直接？還是這份 Terms of Use 也是 Copilot 產生的...？

Sora 为何失败：每天推理成本最高 1500 万美元总收入仅为 210 万美元

Thu, 26 Mar 2026 19:34:15 CST

Sora 一度被视为是视频的未来，但却成为 OpenAI 少数关闭的产品之一。很多人为之惋惜，但数据显示这款产品是注定要关闭的，因为其经济模式不可维持。Sora 在鼎盛时期每天的推理成本高达 1500 万美元，一年的服务器总支出可能高达几十亿美元，而该应用至今的总收入为 210 万美元，也就是收入相对于支出几乎为零。Sora 的活跃用户数也远远少于它的聊天机器人 ChatGPT：Sora 在 2025 年 11 月在 iOS 和 Google Play 的下载量为 333 万，但到了 2026 年 2 月下载量 110 万次左右，跌至峰值的三分之一，它的月活用户数在 2025 年 12 月达到峰值，之后开始下降，也就是用户在流失而不是增长。

阿里巴巴发布优化运行国产大模型的 RISC-V 服务器芯片

Wed, 25 Mar 2026 15:53:08 CST

阿里巴巴发布了优化运行国产大模型的 RISC-V 服务器芯片玄铁 C950，原生支持 Qwen3、DeepSeek V3 等千亿参数大模型。阿里巴巴称玄铁 C950 单核通用性能在 Specint2006 基准测试中突破 70 分，刷新了全球 RISC-V 性能纪录。Google 研究员 Laurie Kirk 称玄铁 C950 的性能与苹果在 2020 年发布的 M1 芯片差不多。玄铁 C950 实现了 2025 年发布的 RISC-V RVA v23.1。该芯片使用 5 纳米工艺制造。

电商版“龙虾”来了！阿里悟空发布，用AI帮商家7✖️24小时经营淘宝天猫店

Thu, 19 Mar 2026 12:21:00 CST

电商版“龙虾”来了！近日，阿里巴巴正式推出全球首个企业级AI原生工作平台——“悟空”，在电商领域，淘宝、天猫核心经营能力将以Skill（技能模块）形式陆续接入，商家可以像搭积木一样，把这些Skill进行组合并在悟空上创造自己的AI工作流，搭建出一支可随时随地待命的覆盖开店、选品、营销、运营、发货等各个环节的AI Agent团队。

更厉害的是，除了电商经营，商家还能通过悟空接入财税、法务、设计、技术开发等各类专业Skill，组建起一套完整的企业职能AI Agent团队。以后商家只需要做关键决策，繁琐的调研、数据分析、方案撰写这些前置工作，统统交给AI团队来完成，全面开启AI时代的企业经营。

上线首期，支持淘宝商品素材优化、店铺经营周报分析、1688找同款等核心经营领域的“AI员工”将率先到岗，此外，商家还可将自身经营经验标准化为Skill技能包，搭建起满足个性化经营的AI Agent。

以“优化商品素材”为例，有了悟空后，商家只需编排好相应AI工作流，AI Agent即会自动完成“数据分析→给出建议”等前期工作，商家一键确认更新后，AI Agent将自动执行“素材制作-更新上架-监控效果”等后期步骤。也就是说，以前需要多人协同的工作，如今通过AI可一键完成。

单个AI Agent已经很强，一支AI Agent团队实现自主的互相协同更厉害。未来，当商家的经营分析Agent发现某款商品转化率下降，则其可自动通知商品素材Agent优化更新主图，与此同步，广告投放Agent也将会自动调整推广策略，整个经营工作商家只需在关键环节进行决策，其他全由AI Agent自主协调完成。

至于商家们最关心的信息安全问题，悟空也做了充分考虑。悟空主打企业可用级安全，为电商经营者提供成熟、安全的电商服务能力和合规的大模型技术，通过数据权限管理体系和加密部署，保障商家的数据信息安全。

目前，淘宝、天猫、支付宝、1688、阿里云等阿里巴巴核心业务Skill正陆续接入悟空。作为阿里巴巴 AI能力在企业工作场景的统一出口，悟空让每个商家，哪怕是“一人店”，也能拥有一支24小时待命的AI经营团队。

雷峰网

AI造就 “默认为假”的时代 - 太隐

Thu, 19 Mar 2026 08:35:07 CST

本栏目《隐说》由原《棱镜通讯》分离而来，《隐说》主要聚焦于我近期读的一些好书、好文章、好的付费栏目、日常思考等等，其中有摘录、点评、扩展。

1、“默认为假”的时代

随着 AI 技术的发展，网上的垃圾信息会指数级增加，虚假信息会越来越真伪难辨。所以，我们要建立起一个概念：任何信息默认都是假的，除非有理由相信是真的。 —— tombkeeper（信息安全专家，现任腾讯玄武实验室负责人）

太隐识:

过去信息匮乏，大部分人看到消息会先选择相信，毕竟能传播出来的内容，多少经过了筛选。但AI时代不一样了。一篇假新闻、一张假图片、一段假视频，几秒钟就能批量造出来，而且越做越像真的，造假的门槛几乎降到了零。这种情况下，要是还习惯性地“看到就信”，那跟在假货遍地的市场里闭着眼睛买东西没什么区别。我也看到不少人拿豆包这类大模型当标准答案用，但稍微懂点技术原理的人都明白，这个所谓的“标准答案”是可以被人为调整甚至污染的。
所以tombkeeper提出的这个原则，或者说这个观察很有趣，其实是把我们的现在认知的默认值做了一次翻转。有点像笛卡尔在《第一哲学沉思集》里说的，先把一切都当成可疑的，然后再一点一点找到可以确信的东西。以前我们是“先信着，碰到假的再剔除”，现在得反过来，“先存疑，找到证据再接受”。这种感受，做过学术研究的人应该特别有共鸣。

不过这里面也藏着一个隐患，值得留意。

当所有人都对信息失去信任的时候，反而容易滑向另一个极端。人们不是变得更理性了，而是更容易把判断权交给某个“权威”，让别人替自己拿主意。比如汉娜·阿伦特早在《极权主义的起源》里就观察到过这种现象，当一个社会什么都不可信的时候，反而什么都能被人相信。

所以在我看来，“默认为假”只是第一步。在AI时代，真正要紧的还是要坚持养成自己验证信息的习惯，去查源头，去交叉比对，去想想“谁在说、为什么说、对谁有利”。很多AI 的新闻只是表面的雾，关键还是要看透雾后面的东西。

说到底，在这个真假越来越难分的年头，只有自己的脑子才是最靠谱的过滤器。

2、传统好比人体免疫机制

历史学家朱维铮先生在1984年谈过一个关于“传统”的观点，说得很好。他说，“毫无疑问，传统是一种巨大的惰性力量。但也毫无疑问，惰性力量不等于反动力量。我曾把传统比作人体的免疫机制。免疫机制的作用，就在于保护人体功能的稳定、平衡，在正常状态下可以抗御致病菌毒的入侵，否则将使人体处于无抵抗状态。如今仍令群医束手的艾滋病，就属于综合免疫功能缺乏症。然而，当人体处于疾病状态，需要输入健康血液或者移植健康器官，那时如何克服自身免疫机制对于异体的抗拒排斥功能，则又使群医为难。作为一种惰性力量，传统犹如免疫机制，属于社会的特定功能，本身无所谓好或坏，无所谓精华与糟粕；至于它起的作用是好是坏，需要发扬还是需要抛弃，问题也不在于它本身，而在于社会是否健康，或者患了哪种疾病。这就是我说的现状。”

到了1990年，朱维铮先生对中国传统又有一段更具体的论述。他认为，中国社会在20世纪至少有三种传统并存。一是清中叶之前定型的本土文化传统；二是西方资本主义入侵后形成的西学传统；三是20年代"以俄为师"之后出现的苏化传统。在整个20世纪上半叶，这三种传统既相互碰撞、摩擦、猜疑、忌恨，也相互熟悉、容忍、吸取、同化，但始终没有完成整合。它们各自在不同层面、不同层次起作用，各有各的生存范围。如果承认这个历史事实，那么本土文化传统自辛亥革命后逐渐退出政治层面，又在五四运动后逐渐沉入更低的文化层次，也就是一个合乎逻辑的进程了。

3、可以入道

外息诸缘，内心无喘，心如墙壁，可以入道。—— 《少室六门》

太隐识:

《法句经》有句讲“犹如善盖屋，雨水不渗漏；心若善修习，贪欲不漏入”，外息诸缘告诉我们要做减法，内心无喘告诉我们要停止内耗，心如墙壁告诉我们要培养自己坚定的内心，这样才能看清生命的实相，走上觉悟的道路。

4、言语道断

信心不二，不二信心。言语道断，非去来今。 —— 《信心铭》

太隐识:

《信心铭》是禅宗三祖僧璨大师所著，全文五百八十多字，这两句出自结尾，也是最广为人知的。
什么意思呢？

真正的“信”，绝不是盲目崇拜，而是亲身验证后的毫无怀疑。就像你亲口尝到了熟透的芒果，真真切切知道它是甜的。那一刻你和这种“甜味”合而为一，内心再无动摇，再无猜测，这就是“不二”的含义。

“言语道断”说的则是语言的局限，举个例子，无论你用多少华丽的词藻，也没法向一个天生的盲人讲清阳光的明媚是怎样的。因为语言只是指路的木牌，真理才是那条路，当你真的踏上了，木牌就不重要了。这句我特别喜欢，总让我想到维特根斯坦那句“对于不可说的东西我们必须保持沉默”，两者在语言的边界上的确达到了某种契合，不过僧璨讲的是本体论，维特根斯坦指向的是认识论。

最后，“非去来今”讲的则是，真正的平静与解脱不在过去，也不在未来。它不是你死后才能去的地方，而是此刻放下执着，当下就能体会的境界。真理一直都在那里，不生不灭，不随时间流转而改变。

5、王夫之谈史

汉、唐之亡，皆自亡也。宋亡，则举黄帝、尧、舜以来道法相传之天下而亡之也。是岂徒徽、钦以降之多败德，蔡、秦、贾、史之挟奸私，遂至于斯哉？其所繇来者渐矣。 —— 王夫之

太隐识:

王夫之把中国历史上的王朝覆灭分成了两种性质完全不同的类型。在他看来，汉朝和唐朝的灭亡是“自亡”，意思是王朝内部腐朽、权臣割据、秩序瓦解，但文明的根基还在。政权更替之后，继承者仍然延续着华夏的道统与制度传统。汉亡之后有魏晋，唐亡之后有五代入宋，文明的脉络虽经曲折，但并未断裂。
而宋朝的灭亡，在王夫之看来，性质完全不同。他说这是把从黄帝、尧、舜以来“道法相传”的整个天下都给亡了，也就是这导致中华文明直接崩塌了。蒙元入主之后，儒家士大夫政治的传统、华夏礼乐制度的延续，都受到了根本性的冲击。

王夫之对宋朝制度上的缺陷评判是有一定道理的，“其所繇来者渐矣”这个判断尤其精到，直接把历史分析从道德批判拉到了结构分析的层面，在明清之际的思想家中确实难得。

不过，他说宋亡是把“道法相传之天下”都亡了，我不太认同。这个二分法的确草率了些。元朝虽然在很多方面改变了宋代的制度，但儒学并没有消亡，科举在中断一段时间后也恢复了。士人阶层的地位虽有下降，却仍然存在，也仍在发挥文化传承的作用。赵复、许衡等北方儒者在元代延续了理学传统，南方的文人群体也并未完全消散。到了明朝建立，宋代的许多制度和文化传统又被重新接续。所以与其说文明断裂了，不如说是经历了一次剧烈的震荡和变形。

我想，王夫之之所以下这样的判断，恐怕和他自身的经历脱不开关系。他亲历了明朝灭亡，对“华夷之辨”有着极为坚定的态度，笔下对“夷”的痛恨自然是格外强烈。带着这层切身之痛回望宋元之变，难免把判断推得更极端了一些。

6、毛泽东与《三垂冈》

英雄立马起沙陀，奈此朱梁跋扈何。只手难扶唐社稷，连城犹拥晋山河。

风云帐下奇儿在，鼓角灯前老泪多。萧瑟三垂冈下路，至今人唱《百年歌》。
— 清人严遂成《三垂冈》

太隐识:

毛泽东非常喜欢这首诗，曾多次亲笔手书。诗写的是晚唐沙陀族军阀李克用的故事。李克用一生与朱温争锋，虽忠于唐室，却终究"只手难扶唐社稷"，壮志未酬，老泪纵横。而全诗最妙的转折在颈联，"风云帐下奇儿在"，帐下那个"奇儿"，便是后来灭掉后梁、建立后唐的李存勖。
这首诗的历史背景是三垂冈之会。据《旧五代史》记载，李克用在三垂冈宴饮，伶人奏起《百年歌》，歌至衰老之段，李克用望着年仅五岁的李存勖，不禁感慨流涕。然而年幼的李存勖却毫无怯意，意气昂然。李克用拍着他的背说"此子类我"，认定他日后必成大器。后来李存勖果然在同一个三垂冈大破后梁军队，应验了父亲当年的期许。

毛泽东反复抄写这首诗，我想不只是欣赏诗本身，更是因为诗中的内核与他的历史观高度契合。英雄的事业，从来不是一代人能够完成的。李克用没能亲手灭梁，但他留下了基业，留下了意志，更留下了那个“奇儿”。一代人做一代人的事，前人栽树，后人收果，这才是历史真正的运转方式。

7、王阳明没说过“父母即佛，心外无佛”

读了韩毓海老师的《重读毛泽东》，文笔很流畅，但其中错误不少。比如第一章“地才”中引用王阳明一句话，“父母即佛，心外无佛”。这句其实并非王阳明所说。王阳明的核心主张是“心外无物”“心外无理”，从未以佛来立论。“父母即佛”这种说法，应该是后人将阳明心学与佛家孝亲思想揉在一起的产物。

不过说到佛家孝亲思想，倒可以顺带聊几句。佛家其实非常重视孝道，比如《大乘本生心地观经》中说，若子女背恩不孝，令父母心生怨念，母亲发出恶言，子女便随之堕落。经中又将父母恩列为四重恩之首，还有一个很有名的说法，“堪事父母者，即是堪事佛”，意思是能真心侍奉父母的人，就等同于在供养佛。

不过话说回来，不管是阳明心学还是佛家孝亲，讲的内核其实相通，都是在说莫向外求，近处即是道场。

8、

亡国论者看敌人如神物，看自己如草芥，速胜论者看敌人如草芥，看自己如神物，这些都是错误的。
— 毛泽东《论持久战》

太隐识:

人在面对重大困难与挑战的时候，常会陷入极端的二元对立。一种是因恐惧而滋生的悲观主义，另一种是因自大而催生的盲目乐观。前者把对手看成不可战胜的神物，后者把自己看成无所不能的神物，但本质上都是同一种症状，就是丧失了对客观现实的判断力。
这段话的本意并不是简单地取一个“中间值”，因为折中主义本身也是一种思维上的偷懒。真正要坚持的，是以事实为基础、以辩证法为工具的认识方法。亡国论者只看到敌强我弱的一面，速胜论者只看到我方优势的一面，而毛泽东看到的是全面。既看到敌人的强，也看到强中之弱；既看到自己的弱，也看到弱中之强。这种思维方式，与克劳塞维茨在《战争论》中反复强调的精神相通，在信息不完备、情绪最容易失控的极端环境下，谁能保持认知上的清醒，谁就掌握了真正的战略主动权。

这种思维放到当下同样适用。在任何博弈中，无论是国与国之间，还是个人所面对的困境，既不神化对手，也不轻视对手，既不妄自菲薄，也不盲目自大，这才是制定正确战略的前提。说到底，只有先认清现实，才有资格去改变现实。有句话说得好，认清现实是勇气，改变现实是能力，而连接这两者的是理性。

9、洗脚注意事项

去年的时候给父母买了个智能泡脚桶，的确很好用，但是泡脚这个事有些常识，还需要多加注意。

一是水温不要超过 40° 以上；

二是泡脚时间要控制在 15-20 分钟；

三是饭后一小时后再洗脚；

四是泡脚时候添加药材，不要一股脑乱放，要查一下是否适合自己。

简单来说，泡脚并不是温度越高越好，也不是泡得越久越好。现在市面上很多智能泡脚桶，时间能设到40分钟，温度能调到50度以上，这就过头了，不但没有好处，反而会伤身体。

另外特别提醒，有严重心脑血管疾病或糖尿病的人，泡脚时一定要格外小心，温度和时间都要比常人更保守，否则容易加重病情。

阿里巴巴论文：75%的模型会破坏掉之前本来跑得好好的代码

Wed, 18 Mar 2026 10:27:26 CST

阿里巴巴做了一个挺硬核的实验：花了233天，在100个真实的代码库上，用18个AI编程代理做了一轮长期跟踪测试。

结果挺扎心的。

75%的模型会破坏掉之前本来跑得好好的代码。也就是说，你让AI帮你改代码，改完之后，原来没问题的地方反而出了问题。这个比例高得有点吓人。

更要命的是，所有参与测试的模型，无一例外，都显著增加了技术债。什么意思呢？就是代码表面上看着能跑，但底下埋了一堆隐患，结构变差了，可维护性降低了，后面要花更多的时间和精力去收拾烂摊子。

这个测试的价值在于它够真实，够长期。不是拿几个demo跑一下就出结论，而是在真实项目里持续观察了大半年。100个代码库、18个代理，样本量也足够说明问题。

说白了，现阶段的AI写代码，短期看效率确实高，但长期看，它可能在悄悄给你挖坑。你今天省下的时间，未来可能要加倍还回去。

这也给所有用AI辅助编程的团队提了个醒：AI生成的代码一定要有人审，不能闭着眼睛就合进主分支。效率和质量之间的平衡，目前还远没有被解决。

“Claude Code 这条路线错了”，元老级 AI 大师 Jeremy Howard 开炮：马斯克和 Dario 根本不懂现代软件工程-36氪

Wed, 18 Mar 2026 10:24:11 CST

Claude Code 这种开发方式还会让人类无法学习新知识，个人能力无法得到提升。企业也正因 AI 编程累积的技术债走向衰亡，这些债务使他们既无法维护现有产品、也难以开发新产品。 “所以我觉得这就是在把企业和员工往被淘汰的绝路上推。无法理解现在竟有这么多大公司的高管在推动这种做法，简直令人惊讶。”

AI 很快会自动化软件开发？大模型未来可以直接输出机器码？Jeremy Howard 不客气地说：说这话的人，多半没当过现代软件工程师。

这句话出自一位重磅人物。Jeremy Howard 是 fast.ai 创始人、Kaggle 传奇人物，也是 ULMFiT 论文作者——后者几乎定义了后来“预训练 + 微调”的语言模型范式。某种意义上，今天大家习以为常的很多大模型训练思路，都能往回追溯到他那一代研究者的探索。也因此，当 AI 编程、智能体和自动化软件开发成为行业最热话题时，他的判断尤其值得听一听。

他首先点名批评了当下流行的一些技术话题。比如 Anthropic CEO Dario Amodei 在《技术的青春期》中提出，顶尖工程师借助 AI 可以获得极高效率，并由此推断普通软件工程师的工作很快会被自动化。Jeremy 认为这种推断“这根本说不通”。

同样被点名的还有马斯克。后者曾表示，大语言模型未来可以直接输出机器码，到那时人类将不再需要库文件和编程语言了。Jeremy 的评价是：这帮人都没当过现代软件工程师。在他看来，很多人误以为软件工程只是把代码输入 IDE，但事实“根本不是”。

他说其实几十年前很多人就觉得即将出现第四代编程语言之类的东西，类似“软件编写越来越简单，再也不需要程序员和软件工程师了，谁都可以生产代码”。但在软件工程这个特殊领域，大模型虽然可以大量生成代码，却并不意味着它能胜任真正的软件工程工作。Jeremy 说自己现在“大概有 90% 的代码都是由模型代劳”，但“这并没有显著提升效率，因为编程从来就不是效率的瓶颈。”

他认为大模型也有能力范围，也会“装作理解”。在很多任务上，这种表象已经足够好用。但一旦问题超出训练数据的分布范围，这种理解就会迅速崩塌，大家会发现“这玩意原来这么蠢……”。

另外，对于 Claude Code，他更是从头批到尾。

最近不少人惊叹 Claude Code 用 Rust 写出了一个 C 编译器。但 Jeremy 与 LLVM 创始人 Chris Lattner 讨论后发现，这个所谓的“新编译器”其实并没有真正突破现有技术路线。因为 LLVM 体系早已存在于大量训练数据中，而 Rust 只是另一种实现语言。将其转换为 Rust，本质上就是在训练数据的片段间进行插值。所以本质上，这仍然是一种风格迁移问题。

“训练数据中已经有构建编译器的方法，而且很多现成的软件都可以实现。”“其本质都是对现有成果的明显照搬。这正是我眼中最核心的挑战所在：要想做出真正原创性的成果，就不能依赖大语言模型。”

除了技术能力本身，Jeremy 也批评了当前 AI 编程工具的发展方向。

在他看来，人类历史上最重要的软件创新——从 Smalltalk 到 APL，再到 Mathematica——都强调人与计算机之间的紧密互动。开发者可以实时操作对象、观察系统状态、调整参数，从而建立直觉和理解。

而像 Claude Code 这样的工具，却走向了相反的方向：开发者只需要输入 prompt，剩下的代码由模型生成，甚至不需要理解整个系统。这种模式虽然看起来效率很高，但却在逐渐削弱开发者对软件系统的理解。

Jeremy 认为，这种趋势是让人类逐渐与自己的代码脱节，甚至有些“不人道”。在他看来，AI 编程真正的挑战并不是让模型写更多代码，而是如何设计一种新的协作方式，让人类和 AI 在同一个交互环境中共同工作，而不是让人类逐渐退出软件开发过程。

更严重的是，Claude Code 这种开发方式还会让人类无法学习新知识，个人能力无法得到提升。企业也正因 AI 编程累积的技术债走向衰亡，这些债务使他们既无法维护现有产品、也难以开发新产品。

“所以我觉得这就是在把企业和员工往被淘汰的绝路上推。无法理解现在竟有这么多大公司的高管在推动这种做法，简直令人惊讶。”

以下是播客整理：

语言模型微调是怎么诞生的

Dr. Tim Scarfe：Jeremy Howard，我大概是从 2017 年、2018 年那会开始关注你的。你那篇著名的 ULMFiT 论文让我印象深刻，当时我在微软工作，还专门就此做过演讲。如今大家理所当然的观点，即只需依托文本语料库对语言模型进行微调，就能持续训练并实现专业化，就是从那篇文章中孕育出来的。

Jeremy Howard： 其实这也不完全是第一次尝试，准确讲其实是第二次。更早几年前 McCann 和 Andrew Dai 也做过类似的研究，但他们忽略了一个关键点——预训练数据集必须是通用语料库。

所以我只是幸运地抓住了这个关键点，但这一切也确实跟我几十年间的哲学与认知科学积累有关系。

我对正则化一直情有独钟，而且尤其推崇这样的实践思路：先构建一套高度灵活的模型，再通过添加正则化项、而非缩减架构规模来增加约束性。

这一点在当时的学术界引发了极大争议，但也并不算是我们的独创见解。Stephen Merity 当时的做法是：选取 LSMT 这种循环神经网络的经典模型（目前的研究也开始逐渐回归此类模型），在保持极致灵活性的同时叠加五种不同类型的正则化方法。他几乎涵盖了一切能想到的正则化类型，而这也成为我的研究起点：构建一套既能随心所欲发挥强大能力，又能按需严格约束的深度学习模型。在此基础之上，我需要海量的文本数据集。有趣的是这同样跟 Stephen 有关，他曾参与 Common Crawl 项目，还协助创建了维基百科数据集。

后来我意识到，维基百科的数据集中其实包含大量预设性假设，比如用 unk 来标记未知词汇，就是说完全采用了经典 NLP 方法。

于是我重构了整套数据集，创建了新版维基百科数据集，现在它也成为我的通用语料库。之后我采用 AWD-LSTM 模型进行训练，仅用一晚时间就成功实现。

当时我用的是一块游戏显卡，前后跑了八个小时。旧金山大学的资源有限，所以我用的好像是一块 2080 Ti 显卡。

第二天清早醒来时，模型训练已经完成——其架构采用的正是如今大家熟悉的三段式。预训练、中训练、后训练。我当时想：既然能预测维基百科的下一个词，模型肯定掌握了大量世界知识。于是我尝试用特定语料进行微调，也就是现在所谓监督式微调数据集，而我用的是电影评论数据集。

事实证明，它特别擅长预测这类文本中可能出现的下一个词，从而掌握大量电影知识。这次的训练只用了大概一个小时，接着又花了几分钟对下游分类器做了微调——用的是一套经典的学术数据集。

我尝试解决的是当时最困难的一种分类问题，即从 5000 条影评中判断观众对于某部影片的情感倾向（正面 / 负面），但如今这项任务已经很简单了。那时候只有高度专业化的模型才能较好完成，甚至有人专门为此撰写博士论文。而我仅用 5 分钟完成微调的模型，就超越了全部原有研究成果。

Dr. Tim Scarfe：这确实令人惊叹，而更值得玩味的就是你那精细的微调方法学成果。

Jeremy Howard： 没错，我们的微调方法是 Fast AI 团队自主研发的。当时 Fast AI 刚刚成立一年，还处于起步阶段。我们当时做了一个极具争议的决定：专注于对现成模型的微调，因为我们坚信微调的力量。同期也有其他研究者在探索这个方向，比如 Jason Yosinski 也做过非常出色的研究。

我记得他在博士期间就研究过如何优化模型及其性能上限，计算机视觉领域也有不少其他研究者在做探索。

我们算是先行者之一，当时不少团队都在深入探索微调技术。我们的想法是，用单一学习率一次性微调整个模型可能行不通，因为模型中不同的层次具有不同的行为特性。

这正是 Jason Yosinski 研究揭示的一大关键。而我们进一步提出了新思路：仅训练末层效率更高，因为只需要对末层进行反向传播。

在确定末层效果良好之后，再逐步扩展到倒数第二层、第三层。我们采用“鉴别式学习率”的机制，即为不同层次分配不同的学习率。

还有另一个我们曾反复强调，但多年来无人在意的关键洞见，即必须对每个 batch 归一化层进行微调。所有归一化层都需要精细微调，因为它们会改变整体的整体规模。只要以此为前提，通常只需微调最后一到两层，就能获得接近顶尖水平的性能结果，整个过程只需要几秒钟。

Dr. Tim Scarfe：是的，鉴别式学习率很有意思。因为当时的主流观点是：如果在模型微调中把学习率设定得过高，就会破坏表示结构。所以大家普遍认为必须采用极低的学习率，否则模型本身就跑偏了。

Jeremy Howard： 那时候还不存在公认的最佳解决方案，也没人讨论过这个话题。就当时的情况看，人们根本就不关注迁移学习。

而 Rachel 和我坚信迁移比任何事情都重要，因为只需要一方把超大规模模型训练出来，其余研究者就能直接进行微调。所以我们决定要钻研这项技术，为此投入大量时间并反复尝试了各种方案。但最终发现，直觉往往才是最简单明了的路径——那些在直觉上可行的方案，基本都跑通了。

这跟当今的机器学习普遍实践有着根本上的差异——如今的研究似乎都围绕着消融实验展开，强调不能做任何假设或者猜测。但这完全不符合实际。我发现几乎所有预期有效的方案都能一次成功，因为我投入大量时间培养出这种直觉，获得了对梯度行为规律的深刻理解。

Dr. Tim Scarfe：但我觉得好像也存在过二元对立的现象：持续学习希望在保持泛化能力的同时持续训练模型，而微调则专注于就特定任务做优化。长期以来存在着这样的认知：模型确实可以做定制，可以按需调整，但这会牺牲泛化能力并削弱表征能力。对这个你是怎么看的？

Jeremy Howard： 没错，确实存在这种现象，但应该没有你讲的那么严重。根本问题在于，人们往往忽略了对激活函数与梯度分析的观察。

因此我们在 Fast AI 软件中内置了一项核心能力：允许用户一览整个神经网络结构。

经过几次操作之后（学习过程只需要几个小时），研究者就能快速意识到当前是属于过拟合、欠拟合或者某个层出现了问题。

这也不算什么奥秘。具体来讲，假如当某些神经元陷入“休眠”状态，即无论如何微调都出现梯度归零——这种情况往往发生在梯度趋向无穷大的情况。但这类问题总能修复，所以实际效果远比大家想象的要好。只要训练得当，适合连续学习的模型也同样能通过微调出色地完成特定任务，只要谨慎处置即可。

Dr. Tim Scarfe：某种意义上，我们确实需要让神经元休眠。让我具体解释一下：我们需要扭曲模型的行为来引入隐式约束，因为没有约束就谈不上创造或者推理能力等等。所以从这个角度我们就能让模型拒绝做某些事，转而去做别的事。

Jeremy Howard： 我倒不这么看。对我而言，在思考 AI 时应该多多参考人类的思维模式，这很有启发。我发现二者行为的相似性要远大于差异性，而我由此产生的直觉往往非常靠谱。

要知道在人类学习新事物时，并不一定要忘却旧知识。所以我发现：当模型尝试学习两项相似的任务时，这两种能力的同时提升效果往往好于只专注单一任务的模型。

Dr. Tim Scarfe：这让我想起 LeCun 实验室的 DINO 论文。虽然当时仅限于视觉模型，但这种自监督学习框架的核心思想仍极其重要：我们在进行预训练时，要尽可能保持多样性和保真度，这样在执行下游任务时才能拥有更多可利用的锚点。

Jeremy Howard： 没错，半监督和自监督学习确实曾是被严重低估的领域。而 Yann LeCun 绝对是该领域最重要的研究者之一。当年我还专门写过一篇博文，就为了吐槽为什么半监督学习方面的研究者那么少。Yann LeCun 冥过我的文章，还推荐了几篇我遗漏的重要文献。但最令我惊讶的是，这种方法的效果居然这么好——本质上就是设计一项预处理任务。

所以设想一下，我们在 ULMFiT 之前就做过这个设想，类似于在医学影像领域取一份组织切片，遮住几个像素块，然后预测原本的内容是什么。

我在南佛罗里达大学带的一些学生就在做这方面研究，基本上就是在复用我们和其他人已经在视觉领域做过的工作。比如这种遮罩方法就不是我们的发明，在计算机视觉领域早有实践，但我们会自然想到在预测单词方面也值得尝试。

以通用预训练模型为起点这一核心思路，在计算机视觉领域早已存在。其实有篇 2015 年左右发表的经典论文，内容完全基于实证研究，展示了当我们用预训练的 ImageNet 模型去预测雕塑家的身份或者建筑风格时，该模型在每项任务中都取得了最先进的结果。但令我惊讶的是，人们看到这些成果后竟然没有联想到：这种方法也理应适用于其他领域——包括基因组序列分析、语言处理乃至其他方向。我发现人们往往缺乏想象力，总认为某项技术只能局限于特定领域。

Dr. Tim Scarfe：确实如此，我觉得这里面有两个关键点。首先，我们其实是暗示存在一种类似古德哈特定律（即任何被设定为目标的衡量指标，都将失去反映真实情况的能力）的短视效应——我们最终得到的只是想要的结果，其他一切都会被牺牲掉。事实显然并非如此，因为在语言模型中我们是可以优化困惑度的。如你所说，这似乎涉及到分布假说，即词语的含义取决于其上下文环境。当我们拥有海量关联数据时，无论是掩蔽自动预测还是类似的技术，模型似乎都能生出一种可称为“理解力”的东西。

Jeremy Howard： 我始终将其视为抽象层次。当模型需要预测时，比如判断棋谱的开局是不是采用了 Bobby Fischer 的习惯下法，再以国际象棋的标准记谱法预测后续棋路，那它就首先得掌握棋谱知识。至于判断“此提案是否被 1956 年的美国总统否决”，那么模型不仅要知晓总统的身份，更要理解“总统”这一制度性概念的存在，进而理解领导人概念、人类社会中的等级制度、人类族群乃至物理世界的存在。如果不掌握这些层层递进的认知，就无法准确预测句子中的下一个词。

所以我的基本思考是这样：建立 ULMFiT 的初衷，正是要尽可能压缩这种知识的获取过程，还必须在模型深处建立起抽象层次结构。如果做不到这一点，谈何精准预测下一个词？要知道，深度学习模型的本质就是通用学习机器，我们又掌握了通用训练方法。因此我推测：只要数据正确且硬件足够强大，理论上我们就能构建起这种词序预测机，它没有理由不能隐式构建起对文本描述对象的分层结构化理解。

Claude Code 的“创造力”，本质上还是插值组合

Dr. Tim Scarfe：但我觉得 AI 的认知还相当浅显。它们确实掌握着无数表层统计关系，也能实现极强的泛化能力。但关键在于，我想参考你之前关于创造力做出过的论述。我认为知识的本质就是约束，而创造力则是在遵循这些约束的同时推动知识演进。所以 AI 并不具备创造力，你之前也持有相同的观点。既然如此，你一方面承认它们具备认知能力，另一方面又否认其具备创造力。这该怎么理解呀？

Jeremy Howard： 我倒不记得自己明确这么讲过。只记得在跟 Peter Norvig 一起接受采访时，我们都提到：其实 AI 在某种意义上是具备创造力的，只是我们用词要谨慎一些。比如我非常敬重的 Piotr Wozniak，他重新发现了间隔重复学习法，由此建立起 SuperMemo 系统，获得了现代记忆大师的称号。

他之所以将毕生精力投入到对记忆的研究，根本原因在于他坚信创造力源自海量的记忆储备，即以全新的方式组合记忆内容才是激发创造力的绝佳途径。

大语言模型在这方面表现相当出色，但也存在一种其完全无法胜任的创造力，也就是突破分布式模型的局限。我认为这就是解决这个问题的关键所在。

不过我想强调的是：对这个问题必须保持极度审慎的态度。如果简单断言大模型缺少创造力，其实是种极具误导性的表达——它们确实能做出看似具有创造性的表现。但要进一步追问：大模型能不能真正突破训练分布的边界，答案肯定是否定的。但训练数据集如此庞大，其中插值的方式又极其繁多，我们还远不清楚它的边界到底在哪里。当然，我每天都能见证这种现象——毕竟我的工作就是研发，始终游走在训练数据的边界附近，做出各种前所未有的尝试。

我发现了一种奇怪的现象，不知道你有没有见过，我每天都会遇到很多次：语言模型会突然从极聪明变得特别蠢，甚至连最基础的逻辑前提都无法理解。它就好像突然意识到：哎呀，问题超过我的训练数据分布范围了。变笨就是一瞬间，任何讨论都毫无意义，模型突然就失控了。

Dr. Tim Scarfe：没错，我非常欣赏 Margaret Boden 提出的创造力分层理论：创造力分为组合式、探索式和变革式三种。而当前的模型确实已经发现了组合式创造力的秘密。

但于我而言，关键在于约束的设置。这也是 Boden 的观点，连达芬奇都说过：创造力的本质就是约束的艺术。你提到的对话工程学也是这个道理。问题在于，当我们跟语言模型对话时，本质上就是给予规范，整个过程需要反复迭代。我们人类的思考也是如此，智能的实现就是在大脑中构建想象形式的乐高积木，同时遵守各种约束条件。

在遵守这些约束并持续演进之后，由此带来的成果就是创造。所以在为语言模型添加约束时，无论是通过监督、批评者还是验证者的方式，它们就能展现出创造力。AlphaEvolve 就已经呈现出这样的能力。但问题在于，当模型脱离约束，它们身上就会出现我们谈到的行为塑造现象。正因如此，语言模型也就无法突破自身训练数据的分布范围。

Jeremy Howard： 我想说的是，语言模型之所以无法突破分布范围，根本原因是这类数学模型本身的局限性。虽然理论上可行，但实际效果极差。就像二维数据的拟合曲线一旦超出数据覆盖区域，曲线就会在空间内向各个方向疯狂延伸。

我们本质上就是在做这件事，只不过是在多维空间中操作。当人类知识库里的全部内容都成为组合素材时，语言模型或许会表现出震惊世人的组合式创造力。

我觉得这也是人们常常误解的点，比如昨天我跟 Chris Latner 讨论 Claude Code 怎么编写 C 编译器时，他认为这是款纯净室编译器，因为它是用 Rust 编写的。

Chris 本人就是当今使用最广泛的 C/C++ 编译器的缔造者，基于 LLVM 运行，而 LLVM 则是编译器普遍采用的基础架构。而且神奇的是，Chris 压根没用过 Rust，也没提供过任何编译器源代码。

所以 Rust 版本的 C 编译器就是净室实现，但也跟大模型的工作原理存在出入。Chris 的所有工作都体现在了大模型的训练数据当中；LLVM 得到广泛应用，无数项目都基于它构建，其中也包括各种 C/C++ 编译器。将其转换为 Rust，本质上就是在训练数据的片段间进行插值。所以本质上，这就是风格迁移的问题。所以最多只能称之为组合式创造力。从生成的代码仓库就能发现，新项目直接复制了 LLVM 代码片段，而 Chris 坦言“我当初犯了错，就不该采用这种没人用的办法”。

而 AI 是唯一照搬了 Chris 这种办法的开发者。之所以会这样，就是因为大模型还没能真正发挥创造力。它还是在训练数据当中寻找某种非线性的平均点——比如在 Rust 技术和编译器构建技术间找交集。

Dr. Tim Scarfe：这些说法都成立。首先，我们不能也不该低估这种组合式创造力的规模。虽然很多代码片段都来自网上公开的结果，但它也确实搭建了完整的测试框架——每次代码提交都会触发测试，相当于建立了实时审查机制。这就是 AI 自己搞的自主反馈循环。

某种程度上，这跟 OpenAI 和 Gemini 最近的研究非常相似——让 AI 自建评估函数来尝试解决数学问题。但人们往往忽略了一点：运用评估函数本身，就代表着 AI 对问题并不完全理解。它仍然在通过暴力搜索和统计模式匹配来解题，并将验证器当作约束。

Jeremy Howard： 所以说大模型根本没必要这么搞。因为训练数据中已经有构建编译器的方法，而且很多现成的软件都可以实现。所以它直接借用现有方案并将其转换成了 Rust 语言。单凭这点，就已经相当惊人。

虽然我对数学不像对计算机科学那么熟悉，但我也常跟数学家们交流，发现在埃尔德什差异问题（对于任意常数 C，总能找到等距的有限子序列，使其元素累加和的绝对值超过 C）等领域也存在类似的现象。部分问题虽然得到了新解，但并非顿悟式的突破。大模型往往还是在整合人类已知的相关知识点来解题。

“ 这帮人都没当过现代软件工程师”

Dr. Tim Scarfe：再来聊聊 Claude Code。你曾经深入探讨过氛围编程的问题，Rachel 也写过一篇有趣的文章，引用 METR 研究所的成果，发现人们在进行氛围编程时生产力反而有所下降。

还有 Anthropic 的研究，这里我们稍做回顾。Dario 前段时间发表了一篇题为《技术的青春期》的文章，大意是：Anthropic 拥有众多顶尖软件工程师，在 AI 辅助下开发效率极高。而后他将这种情况粗暴推广到普通软件工程师群体，宣称 AI 很快就能全面实现工作自动化，届时将导致大面积失业。

Jeremy Howard：这根本说不通。 几天前马斯克也讲过类似的话，说什么大语言模型可以直接输出机器码。到那个时候，我们就完全不需要库文件和编程语言了。

问题在于，这帮人都没当过现代软件工程师。我不确定 Dario 有没有做过真正的软件工程师岗。软件工程是门特殊学科，很多人误以为软件工程就是简单把代码输入到集成开发环境。根本不是，编程的本质是另一种风格迁移问题。我们拿到待解决问题的规范说明，而后运用组合式创造力找出训练数据中能够填补两者间隙的部分来解决问题，再将其与目标语言的语法进行插值处理，最终形成代码。

Fred Brooks 几十年前曾写过一篇著名论文《没有银弹》，其内容对当下的情况做出了精准预言。当时很多人都觉得即将出现第四代编程语言之类的东西，类似“软件编写越来越简单，再也不需要程序员和软件工程师了，谁都可以生产代码”。但他则预言称，技术的进步最多只能带来 30% 的效率提升。

这就是他的结论，未来十年之内软件开发的效率提升空间只有 30%。我虽然觉得没必要这么悲观，但软件工程中的绝大部分工作确实不止于编写代码。某种意义上，Dario 的部分观点也有道理，比如当下很多人已经在靠语言模型为生成代码。我自己就是这样，大概有 90% 的代码都是由模型代劳。但这并没有显著提升效率，因为编程从来就不是效率的瓶颈。

语言模型确实给我的研究工作带来不少帮助，比如预判哪些文件需要修改。但在我尝试让大模型设计前所未有的解决方案时，结果永远是场灾难。

实际上，它每次给我的都是看起来差不多的设计，而这往往就是灾难的根源。我明明想要创造新事物来消除这种相似性，但它总在延续过去，这就是最大的冲突点。

Dr. Tim Scarfe：我发现很多科技从业者对于认知科学和哲学概念都有严重误解。我们节目也采访过很多杰出人物，比如曾撰写了《知识法则》一书的 César Hidalgo，还有神经科学哲学家 Mazviita Chirimuuta 也反复强调过知识具有变幻莫测的特性。我认为知识在本质上是有视角属性的。

我不觉得单靠维基百科上那种纯抽象、脱离视角属性的条目就足以还原知识的全貌。换言之，我认为知识有着具象性且充满生命力，脱胎于我们体内。组织存在的意义就在于守护并演进知识。而在把认知任务委托给语言模型时，自然会产生一种诡异的悖论效应：组织内部的知识反而受到侵蚀。

Jeremy Howard：确实，这真的令人不安。网上经常出现这样的争论：有人坚称大语言模型根本就啥都不懂，只是装作可以理解。另一些人则反驳：别胡说八道，看看大模型刚刚帮我搞定了什么问题。有趣的是双方都有道理——大语言模型实际上确实是在扮演一个理解了问题的人。

它们假装可以理解，恰恰呼应了 Daniel Dennett 早期认知科学研究的精髓，中文房间实验（设想一个仅懂英语的人通过操作中文翻译程序手册处理外部中文提问，使外界误判其具备理解能力，以此论证计算机仅模拟智能表象而缺乏真正认知状态）的核心思想也正是如此。房中人的表现确实很像懂中文，因为我们提的所有问题都能得到答案。但实际其只是在海量的书籍或机器中查找信息。当然，在装懂不影响结果的范围之内，到底是装聪明还是真聪明并不重要。

所以 对于很多任务，大语言模型只需要装懂就足够了——毕竟在实际应用中，是不是真懂根本无关紧要。可如果哪天越过了边界，很多人才会惊觉：天哪， 大模型这玩意原来这么蠢……

Dr. Tim Scarfe：顺带一提，我是 Searle 的拥趸，他曾提到因果具有可还原性、但本体不具备可还原性，也就是强调存在现象学这个维度。这也是知识变幻莫测的精妙所在，它本质上承袭了康德的思想：世界错综复杂，无人能够完全理解。正如盲人摸象，我们不可避免各自拥有不同视角。

由于复杂度过高，因此每个人都在进行建模。但有趣的是，语言模型有时似乎表现得能够理解事物，而这种理解的根源在于监督者为其提供了框架。在这套框架内，当我们从大象的视角观察，认知结论竟然出奇连续。只是现在，我们往往忽略了监督者为模型设定的这套框架。

Jeremy Howard： 没错，所以这相当于 Searle 与 Dennett 之争，也就是《意识的解释》与“中文房间”这两种视角的思辨。有趣的是，当时的讨论跟我们当下的争议有着完全相同的本质，只是从纯思想实验转向现实层面。回归抽象讨论很有必要，因为这能让我们抽离当前困境、不再受到现实中具备强大模仿能力的模型影响，真正回归问题的本质。

总之我想强调的是，我们正身处一种微妙的历史节点：人们极易对 AI 的能力产生误解。尤其是那些分不清编程和软件工程区别的朋友，就更容易误解。

是的，这就正好转回了你提出的问题——这种认知差异会对组织产生怎样的影响。要知道，许多组织的本质就是在押注一个投机性的前提：AI 将有能力比人类更出色地完成一切工作，至少在编程领域可以做到。我对此深感忧虑，无论是从组织还是从全人类的角度讲都是。对人类来说，一旦没有机会主动运用设计、工程和编程能力，也就失去了发展和成长的机会。人类可能逐渐凋零。身为研发型初创公司的 CEO，我必须要强调：如果团队成员停止成长，我们就注定会失败。

我们绝不能让这种情况发生，而单纯提升针对 AI 的特定提示词技巧或者 CLI 框架使用能力，并不算成长。这就像在不理解互联网原理的情况下死磕亚马逊云科技的接口细节——毫无价值。这类知识既不可复用，又没有继承意义。虽然它能够在当下解决实际问题，但必然随着时间推移逐渐侵蚀从业者的信心。

大模型反而让开发者变笨了？

Dr. Tim Scarfe：我认同这种自然规律，而且对你尤其重要。在整个职业生涯中，你一直致力于提升人们的技术与 AI 素养。而你说的大模型编程技巧，很像是开自动驾驶汽车了——人根本没多少机会上手。

这里存在一个临界点——当我们不再专注于亲自解题，而把能力委托出去，就会积累下认知债。这就是当前的现实。几周前 Anthropic 自己的研究就完全推翻了 Dario 的观点，研究结果甚至发现，确实有少数参与者通过提出概念性问题来保证对实现技术的掌控。他们确实能展现出学习曲线，但大多数人根本做不到。

我有个假设：生成式 AI 编程的理想状态应该是看齐人类开发者，毕竟我们几十年来一直在编写软件，也具备抽象认知能力、能在熟悉的领域灵活运用。我们还能明确需求，消除大量模糊性、跟踪进展、反复调整，且全程掌控开发流程。但现实情况是，现在的人们会默认进入自动驾驶模式，对实际发生的情况一无所知——这反而让开发者变笨了。

Jeremy Howard：我在 2014 年创立了首家医疗深度学习公司 Enlitic。初期我们专注于放射学领域，当时许多人就担忧这会削弱放射科医生的专业能力。但我坚信恰恰相反——为此我还深入研究了飞机电传操纵系统、汽车防抱死刹车系统等技术应用案例。当可以自动化的任务环节成功实现自动化之后，专家反而可以专注于真正关键的环节。

我们在实践当中也难了这一观点。在放射学领域，我们发现如果能自动识别肺部 CT 扫描中的潜在结节，那么放射科医生可以专注于分析结节性质，判断其恶性程度并制定治疗方案。这正是微妙的差别所在。如果能有效实现某些环节的完全自动化，从而减轻人类认知负担、专注于核心工作，结果无疑是积极的。至于软件开发领域的情况，我觉得更难以断言——毕竟我搞开发已经有四十多年，亲自写过大量代码。除非遇到特别奇怪或者复杂的情况，否则只需瞥一眼代码，我就能立刻判断出代码功能和运行状态等结论。

我凭直觉发现的这些可优先的点，还有预见到的潜在风险，如果没有长期编程积累恐怕很难很难达到。目前我觉得真正受益于 AI 的人群有两类：要么是完全不会编程的初学者，现在他们可以把脑海中的想法快速转化成应用。只要 AI 有能力帮他们快速实现需求，就完全可以了。另一类是像我和 Chris Latner 这样的资深开发者，因为我们能让 AI 代劳相当一部分编程工作和研究任务。但处于中间水平的人才是真正的绝大多数，这让我非常担忧，他们几乎失去了进步的空间和可能性。

不用亲自写代码也许没什么，但我们没办法确定，因为之前没出现过这种情况。这就像回到小学阶段，学校禁止孩子们使用计算器，就是为了锻炼他们对数字的感觉和运算能力。那开发者还要不要经历前五年的磨练，亲手编写所有代码？我真的不知道。

总之我自己比较悲观，对于大部分从业经验从 2 年到 20 年之间的开发者，这可能是在慢慢侵蚀他们的竞争力。

Dr. Tim Scarfe：没错，这又涉及 Cesar Hidalgo 提出的知识本质论。他认为知识具有不可替代性，即无法直接交换。其核心观点是：学习过程在某种意义上不可能被简化。学习者必须亲身经历，直面摩擦和考验。学习的过程就是构建世界模型的过程，会经历所谓“现实的反噬”——我们不断犯错、不断更新自己大脑中的模型，并向其中持续添加一致性约束。但直接使用大模型输出的代码，显然是回避了这种“必要之难”。Anthropic 的研究也提出类似的结论：由于回避了摩擦，开发者根本学不到任何东西。

Jeremy Howard： 没错，所谓“必要之难”是教育学领域提出的概念，最早可以追溯到十九世纪重复间隔学习的开创者 Ebbinghaus。Piotr Wozniak 的近期研究也发现了相同的规律：记忆的形式需要付出艰辛努力。这也解释了为什么“过度复习”反而有害，因为信息会过早浮现。而间隔重复学习法（例如 Anki 和 SupereMemo）则努力在记忆即将遗忘的临界点处安排复习。

这确实需要付出艰辛的努力。我花了十年时间学习中文，只为探究学习的本质。在使用 Anki 时我深刻体会到：它总在记忆即将消退的临界点安排复习，抓住濒临遗忘的节点刺激神经元连接。这种模式执行起来特别特别累，但效果确实惊人。所以哪怕后面十几年不再坚持系统学习，我仍能流利使用中文。

Dr. Tim Scarfe：说回你提的放射学案例，还有人们常说的客服中心。我们总觉得组织中的岗位存在着高智力需求和低智力需求之分。但我觉得，智能的本质就是对知识的适应性获取和整合。假设低智力需求岗位（比如客服）不需要适应变化，就意味着组织中存在着某些稳定不变的环节。

这部分环节可以自动化，无需更新知识储备。但结合放射学案例，这种观点可能忽略了整体性知识的重要性。比如客服中心也会遇到大量特殊的、极端的案例。各种意外状况层出不穷，这些信息会向上传递，促使组织逐步适应。所以在推广自动化流程之后，工作人员实际上会丧失创造流程的能力，进而削弱组织知识的演化能力——这无异于自毁长城。

Jeremy Howard：完全正确。在我的公司，我始终提醒同事们：我真正关注的只有一件事——你们的个人能力在多大程度上得到了提升。我并不在意大家提交了多少 PR，开发出了多少功能。就像 Tcl 语言的发明者 John Oustenrhout 最近在斯坦福讲座中提出的精彩观点：一点点斜率就能弥补大量截距。

这里的核心论点是，人生中若能专注于加速成长的事物，那效果要远胜于执着那些已经擅长、拥有高横坐标值的事物。因此我真正关心，也是我认为对公司至关重要的唯一目标，就是让团队专注于提升斜率。没错，如果只专注于在现有 AI 的能力边界之内追求成果，那关注的就仍然是横坐标值。

所以我觉得这就是在把企业和员工往被淘汰的绝路上推。无法理解现在竟有这么多大公司的高管在推动这种做法，简直令人惊讶。

毕竟这是个大家都不熟悉的领域，MBA 课程里也从没提到过，所以一旦判断失误——也很可能就是失误，那人们根本就意识不到。这本质上是为公司埋下了毁灭的种子。

更令人费解的是，股东们竟然会纵容这种行为。这将催生出高度投机性质的市场操作。众多企业正因 AI 编程累积的技术债走向衰亡，这些债务使他们既无法维护现有产品、也难以开发新产品。

Dr. Tim Scarfe：像 François Chollet 这样的行家其实也不少，他们真的很懂。他就始终强调 AI 发展的本质，就是领域认知模型的拟态式共享，以及如何配合人类共同蒸馏这些模型。说到共享，这恰恰是 AI 编程面临的另一大扩展难题。

在理想状态下，只要我们深谙某个领域，有能力用极致的细节做出定义，那么只需告知 Claude Code 执行任务即可——我们脑袋里的模型框架并不重要。

但在组织环境下，我们需要把知识共享给全体成员。必须承认，知识的获取瓶颈就是组织内部真实存在的严重问题。如果只有我一个人在使用 Claude Code，效率大概能提升 50 倍——人们的兴奋之情也正来源于此。但要跟其他人共享，AI 编程工具就起不了什么作用了。大家似乎并没有意识到这个瓶颈，也没发现这就是大多数组织难以将 AI 转化为现实生产力的原因。

Jeremy Howard：实际上没人能在保持高质量的前提下产出 50 倍的软件。 我们刚刚完成相关研究，发现人们实际交付的成果只能说略有增加。这就是残酷的事实。我本人其实热衷于发掘 AI 的潜力，但我妻子 Rachel 最近发文指出，所有激发人们热烈追捧的因素汇聚起来只是一股暗流。

Dr. Tim Scarfe： 对，暗流这个概念我也想提来着。

Jeremy Howard： 所以这就很尴尬了。我认识的几乎每位前段时间对 AI 驱动编程充满热情的人，在回头审视自己一路走来构建的成果时，都彻底改变了看法：这些东西还有人在用吗？还有受众吗？还能帮自己赚钱吗？ 其实几乎所有利润，都被意见领袖或者炒币那帮家伙卷走了。

氛围编程就像老虎机

Jeremy Howard：依托 AI 的编程本质上更像是老虎机——让人产生可以掌控一切的错觉。我们当然可以精心设计提示词、管理模型参数清单、调整 skill 参数等等，最后再拉下拉把。

输入指令，然后得到结果，这就像凭运气拉出三颗樱桃并排。“我再改条指令，再多加点上下文”，之后再次拉动拉把、不停重复。

这就是随机性。我们偶尔能赢一把，觉得太棒了、AI 这东西太牛了！但这本质上具备赌博的全部特征：伪装成胜利的失败、高度随机、虚假的控制感——这些都是博彩公司精心编排的元素。虽然这并不代表 AI 没用，但……真的也没多有用。

Dr. Tim Scarfe：明白。Rachel 还提到赌博的另外一个标志性特征，就是让人自欺欺人地以为掌握了局势，但实则不然。但我们也可以探讨一下乐观情绪：我觉得 AI 编程在受控场景下的确非常有用，前提是我们能够理解并设定约束。从好的角度来讲，那我们确实不会因此失业，毕竟这部分工作量会相应增加。至于成瘾性，那也是真实存在的：我曾经连续 14 个小时使用 Claude Code 输出代码，确实非常上瘾。你说得对，就像老虎机一样，非常贴切。

而且那也是我最疲惫的一次编码经历，精疲力竭之后我连着休息了好几天才恢复，那状态实在糟透了。

Jeremy Howard： 一点没错。我也获得过一些不错的结果，过去几年还围绕已知的成功路径构建起完整的产品体系，也就是专注于中等规模的模块化开发：确保各个模块完全可控、可设计，并能通过自定义抽象层逐步构建起超越组件本身功能的整体系统。最近我们还遇到个很有意思的情况，其实也可以算是实验：我们之前高度依赖 IPKernel 组件，它也正是驱动 Jupyter Notebook 的核心。但在 IPyKernel 从版本 6 升级到版本 7 之后，就彻底失效了。我们尝试使用的两款产品都出现了故障：其一是名为 nbclassic 的原始 Jupyter notebook，其二是我们自主开发的 solve it 产品。

它们会随机崩溃。IPyKernel 的代码超过 5000 行，结构极其复杂，涵盖多线程、事件处理、锁机制、与 IPython 的接口、ZMQ 通信协议以及 DebugPy 调试框架等等。我完全摸不着头脑，找不到崩溃的原因——所有测试都能顺利通过。于是我好奇，AI 能不能帮我解决这个问题？真的，我一直好奇目前的 AI 能够独立处理的任务规模上限在哪里。

事实证明，它确实能够解决。前后花了两周时间，虽然没能深入理解 IPyKernel 的运作机制，但我还是花了不少精力把它拆解成一个个独立组件。最终 AI 在两小时内就给出了答案——我最早用的是 GPT 5.2，没能搞定；花每月 200 美元升级到 GPT 5.3 Pro 版后就好了。

总之，通过在两个版本和两套模型之间反复切换，我花了几周时间才让系统正常运行。如你据说，整个过程毫无乐趣可言，既疲惫又焦虑，因为我始终无法掌控局面。但有趣的是，这是我目前唯一能够让新版 Python Jupter 内核成功运行的办法——至少就我所知，它找到了完美兼容版本 7 协议的办法。 这让我不禁陷入深思：我不喜欢 AI 辅助的工作感受，但因为传统软件工程理论不足以解决问题，我又别无选择。

新的难题又来了——我并不理解解决问题的这段代码，那我该不该把公司产品押在上面？我真的不知道该怎么办，我不知道它会不会引发内存泄漏；如果协议稍作改动，它后续还能不能正常运行；是否存在会导致全盘崩溃的极端状况等等。这真是个前所未见的巨大困局。

“AI 写代码很厉害，但软件工程一塌糊涂”

Dr. Tim Scarfe：那我们还是得从控制权的角度讨论——必须承认，我们对代码的控制能力正受到严重侵蚀。最初由 AI 生成的代码占比仅为 10%，随后这个比例不断攀升，而且我们无能为力。大约半年之后，提交上来的 PR 中就有约 60% 代码由 AI 生成。这就是后果。

人正逐渐跟自己的代码脱节。乐观的判断认为：AI 编程只强调功能主义即可——只要智能体可以正确完成任务，我们就可以认可 AI，无须深究其构成原理。毕竟软件领域从来都是这样。

商业领域肯定很认可这套逻辑，毕竟人家做的是业务，本来就没办法亲自编写代码、也掌握不了快速排序算法的实现细节。所以只要所有测试都能顺利通过、代码可以成功部署，流程按部就班推进，那不就得了？

Jeremy Howard： 实事求是讲，这种观念我觉得还满有道理，但还不够。我们必须重视软件工程的重要意义，因为它的核心就是强调各个组件到底是什么、应该如何运作，再以此为基础将其组合成更庞大的整体，进而持续迭代以构建出宏大的系统。

只有做好了这一点，我们才能在十年之后靠 AI 打造出远超当下想象的顶尖软件。没错，只有卓越的软件工程能力才可以实现这种突破。以 IPyKernel 为例，我发现它本身就是个极其庞大的组件。

因为很明显，IPyKernel 的原始开发团队没能打造出一套可以正确验证其功能的测试集，所以才导致包括原始 nbclassic（即 IPyKernel 的源项目）在内的众多实际应用项目都无法正常运行。这正是我们 Answer.ai 开发团队的当前重点：寻找规模适应的模块，并确保其正确性。

要如何识别这些模块、如何加以设计、如何进行组合——这些能力都需要几十年的开发经验才能掌握。 我自己也是，自认为经过二十年的历练才算掌握到个中精髓。这确实是个大问题，毕竟软件工程能力的重要能力远超以往任何时候，但当下又恰恰欠缺培养这种能力的场景。未来的开发者要如何保证自己可以胜任这份工作，已经成为极具挑战性的课题。

Dr. Tim Scarfe：还有种观点是这样：抽象和表征事物的方式其实有很多。要知道这个世界如此复杂，我们人类熟悉的软件抽象与表征方式，可能更多是自身认知局限的映射。即使是在科学和物理领域，人们也更倾向以高度简化的方法来建模。但复杂科学往往必须直面事物的构造性、耗散性以及缠杂交织的本质。

也许当下就有很多软件已经超出了人类的理解上限，对吧？比如许多采用 actor 模式的全球分布式软件应用，其本质上已经属于复杂系统。我们只能通过模拟和测试来尝试理解，因为没人真正知道所有组件间如何协同运作。所以乐观地看，也许软件工程的顶层设计已经在践行这种新理念，而这也正是 AI 有望达成的终极目标。

Jeremy Howard： 倒也未必。比如说 Instagram 和 WhatsApp 这类公司，仅凭十余名员工就主导了各自领域，甚至击败了谷歌和微软等巨头。我觉得这只说明大厂那种软件开发模式正在失败，我们也亲眼目睹许多巨头正陷入日益绝望的境地。就拿微软 Windows 和苹果 MacOS 的质量来说，过去五到十年间已经遭遇显著下滑。还记得当初 Dave Cutler 逐行审阅 NT 内核代码，确保每一行都完美无瑕的时代吧？那才是真正优雅卓越的软件典范。但如今世上不会有人觉得 Windows 11 是优雅精妙的软件。所以我们可以真的需要先打造出完全可按的小组件，再把它们堆叠起来实现构建。

问题是 AI 在这方面表现相当糟糕。我这可是基于实证得出的结论，它们在软件工程领域简直不堪一击，而且这种情况可能永远不会改变。因为我们总要求 AI 突破训练数据的边界，尝试构建前所未有的事物，追求超越现有方案。换言之，我们一方面只提供有限的训练数据，另一方面又指望它别单纯照搬训练过的内容。这点常常让人们困惑——他们看到 AI 编程能力如此出色，便误以为这等同于软件工程能力。但这二者的本质完全不同，重合度也很低。目前还没有任何实证数据表明大语言模型在软件工程领域实现了任何显著的能力提升。

每当我们审视 AI 完成的软件工程案例，比如 Cursor 开发的浏览器或者 Anthropic 搞出来的 C 编译器——另怀疑，我认真看过这些项目的源代码，再加上更熟悉编译器的 Chris Latner——其本质都是对现有成果的明显照搬。这正是我眼中最核心的挑战所在：要想做出真正原创性的成果，就不能依赖大语言模型。

理论上我们没办法相信大模型会涌现出这种原创能力，实证数据也同样支撑不了这样乐观的猜想。

最先进的 AI，却在用 40 年前的开发环境

Dr. Tim Scarfe：没错，我觉得这场对话最大的价值就在于，我们需要实现 AI 与人类的协同合作。由人类提供理解力，还有我们之前讨论过的各种知识层面的支持。但与此同时，AI 仍然不失为一种重要且强大的工具。我们只要设计出运作模式或者工作方式，确保自身的独特能力、特别是理解力不被削弱就行。

Jeremy Howard： 没错，这里确实有条微妙的分界线，也是我们在教学与内部开发时关注的核心点。我这二十年来持续探索的方向，终将成为支撑整个体系的关键。Stepehn Wolfram 创造了 notebook 界面，虽然其中很多理念可以追溯至 Samlltalk、Lisp 和 APL，但其意义仍然非常值得肯定。他的核心思想在于：当人类能够实时操作计算机内部对象、研究它们、移动它们并加以组合，就可以通过计算机实现更多可能。

而 Smalltalk 的核心理念也正是基于对象，APL 同样以数组为基础。Mathematica 本质上就是功能强大的 Lisp 语言，只是在此基础上融入了优雅的 notebook 界面，让开发者能够构建出动态生成的活文档。

几年前我开发了 nbdev 工具，它能在 notebook 界面跟丰富的动态环境中构建起生产级软件。我发现这极大提升了自己的编程效率。虽然我从来没做过全职编程工作，但大家可以看看我的 GitHub 代码仓库产出——根据统计数据，我几乎是全澳大利亚最高效的程序员。这证明我的办法确实行之有效。我开发的许多工具被大量用户采用，凭借的就是出色且丰富的构建方式。

如今我们发现，在把 AI 置与跟人类相同的交互环境中时，其表现同样会显著提升。可以看到，常规的 AI 编程工具，比如大家使用 Claude Code，其运行环境跟人类 40 年前使用的环境极为相似。这本质上仍然是基于代码行的终端界面。它当然可以使用 MCP 或者其他工具，但目前多数时候借助的仍然是经典的 bash 工具。

我非常喜欢 bash 工具，在日常工作中也会频繁使用各类命令行工具。从本质上讲，它就是依赖文本文件作为与外界交互的媒介，这实在有点简陋。所以我们将人类与 AI 置于 Python 解释器内，立刻就得到了能帮助人类与 AI 对话的强大工具——一种优雅且富有表现力的编程语言。

现如今，AI 能与计算机对话，人类能与计算机对话，计算机又能与 AI 对话。在这种丰富的交互生态中，人类与 AI 得以实时协作，共同构建起双方都能使用的工具。这也是我所追求的核心价值，创造一个让人类能够参与、成长且共享的环境。

于我而言，使用 SolveIt 的体验跟你之前提到的 Claude Code 恰恰相反。用了几小时后，我感觉神清气爽，快乐而充实。

Dr. Tim Scarfe： 我来谈谈自己的看法。你刚刚的核心观点，就是具备交互性、状态感知且能够提供反馈的环境，具有某种神奇的魔力。这是因为我们的大脑能够处理特定的工作单元，我们会通过反复推敲加现实检验的方式来思考问题。正因为如此，我才会在攻读博士期间选择使用 Mathematica 和 MatLab。

我完全赞同你的结论。这种 REPL 环境能让我们直接操作数组、生成图像图谱、实时调整参数以即时呈现变化效果。这确实是优化思维模型的绝佳方式。不过 Claude Code 也能实现类似的功能，关键在于适当使用操作技巧。高效使用 Claude Code 的开发者普遍具备这种能力。我也开发过内容管理工具，也就是 Rescript，它在制作纪录片视频时能自动提取字幕文本，帮我核查陈述内容的真实性。

总之，AI 素养的核心在于理解语言模型在能力上的不对称性。在要求其处理鉴别型任务时，它们的表现往往非常出色。例如在子智能体模式下要求其逐条验证主张时，它的准确性就远高于生成模式下批量生成的主张。关于状态反馈机制，我们可以采用结构化 XML 导出方案，配合侧边栏可视化应用来形成反馈循环。

对我而言，这文治武功 AI 的优势所在，也是善于借 AI 之力的使用者们的首选用法。

Jeremy Howard： 是的，但我并不完全认同你的观点。我知道也可以在 Claude Code 中实现相同的效果，也同意具体效果取决于使用者的 AI 素养，但 Claude Code 的设计初衷并不在此。它并不擅长此类操作，这也不是跟 Claude Code 交互的自然方式。我倒不觉得这是 AI 素养的问题——在我看来，如果工具无法以人类熟悉的方式获取更深的知识、更愉悦的体验和更紧密的联结，还有对工作内容的透彻理解并建立情感纽带，那这绝对是工具的问题，不能说是人的问题。

工具的设计就应该符合人体工程学。但如今，很多模型和工具的评估标准就只是能否接管完整任务并独立完成。这在我看来是种重大谬误。真正的关键在于：人类在使用之后，能否真正掌握该领域的知识，进而轻松构建出更多成果。

Claude Code 正在背离“人机共创”的软件传统

Dr. Tim Scarfe：我完全赞同。但还有另一个有趣的视角——Joel Grus 曾有一场著名的演讲，我们稍后会具体聊。他说 Notebook 程序糟糕透顶，从软件工程角度看简直不堪入目。当时，哪怕是到现在可能也仍然如此，我其实挺认同他的观点。毕竟我也从事过机器学习的运维工作，在大型机构中负责探索数据科学与软件工程之间的连接。

相较于 Notebook，Claude Code 其实更偏重软件工程领域，因为它能生成幂等、无状态及可重复的成果。如你所说，从教育角度看这种基于状态的反馈其实很好，因为我能够理解到底发生了什么。之后只要把它转化成可部署的成果就行了。

所以你能聊聊 Joel Grus 的观点吗？记得你当时的回应还闹得挺大的，给我们讲讲呗。

Jeremy Howard： 他当时拍了段精彩的视频，就叫《我不喜欢 Notebook》，制作精良而且超级搞笑。现在我承认，我当时的观点完全错了。

他列举了很多 Notebook 做不到的事，但其实都能做到。他说 Notebook 实现不了的功能，其实我每天都在靠 Notebook 实现。可那场演讲虽然错误百出，却实在妙趣横生。后来我模仿他的风格做了段《我喜欢 Notebook》的视频，基本照搬了他的大部分 PPT 并注明了出处，然后逐条反驳了每条谬误。

不过你提到的核心问题确实切中了要害——这本质上其实是软件工程与科学研究等领域在工作方式上的根本差异。我认为这种二元对立确实存在，这样的割裂也着实令人遗憾。软件开发的推进方向出了偏差， 当前的模式完全聚焦于可复现性，却无视僵化代码与文件的持续膨胀。 项目里全都是死代码、死文件，这事我强烈推荐大家去看看 Brett Victor 的论述，他的讲解特别精彩。他反复证明：最重要、最正确的方向，永远是跟所做之事建立起直接且符合直觉的联结。

他也将此作为自己的使命，确保人们能够建立起这种联结。我也把这当作自己的使命。于我而言，传统软件工程已经大大偏离了这样的联结。我觉得它令人作呕、简直恶心，更可悲的是人们正被迫以这样的方式工作。这不止反人道，而且模式本身根本就行不通——经验证明其效果极差。对 AI 是如此，对人类更是如此。

事情并不总是这样的。回到早期，比如 Alan Kay 的 Smalltalk，Iverson 的 APL，还有 Wolfram 的 Mathematica。在我看来，那才是“黄金时代”。

那个时代的人真正关心的问题是： 如何让人类尽可能紧密地与计算机一起工作。 比如鼠标的诞生也是如此，通过点击和拖拽操作将计算机中的对象可视化为可移动的实体。可多年过去，如今我们却失掉了正确的方向，这实在令人痛心。

而像现在用 Claude Code 这样的工具时，默认的工作方式却完全相反：你需要深入到一个系统内部，那里有一整个文件夹的代码文件，但你甚至从来不会去看它们。你与系统的全部互动，只是通过一个 prompt。

老实说，这让我真的感到反感。我是真的觉得这种方式有点不人道。

而我的使命，其实二十年来一直没有变：就是想办法让人们不再用这种方式工作。

Dr. Tim Scarfe：明白。但回想起来，我当初跟数据科学家们共事时，他们都在用 Jupyter Notebook。当时我就发现，如果把这些 notebook 直接提交到 Git 仓库，效果通常不太理想。

大多数数据科学家根本不懂 Git 操作，他们会打乱单元格的执行顺序，导致结果无法复现，类似的问题层出不穷。我同意你的观点，这些工具确实更能融入工作流程。但这又回到了我之前提出的核心问题：就像我们讨论客服中心时说的，那属于低智力需求的工作。要知道，数据科学家之所以属于高智力工作，是因为他们在创造前所未有的事物。他们在探索问题的边界，在认知模糊的领域开疆拓土。当然有人会争辩，说如果数据科学家能够清晰界定问题的边界，也许就能借助 Claude Code 实现精准落地了。但是我们该如何在这两个世界之间架起桥梁？

Jeremy Howard： 我觉得这个主意实在没有必要，你总不是想把人从探索性的环境中剥离出来吧？科研的进步源自人们建立洞见的过程。包括费曼在内的众多大师，那些伟大的科学家总会强调通过构建思维模型来深化直觉，而这些模型需要经年累月与研究对象的交互才能形成。以费曼为例，由于从事理论物理研究，他不可能实际接触旋转的夸克，但他会尝试研究旋转的盘子。我们必须自己想办法找到深度交互的方式。我见过很多数据科学团队，他们不只是对 Git 不熟悉，他们对自己本该理解的事物也不熟悉。

所以他们的头头往往是一位软件工程师，解决方法就是要求所有数据科学家都停止使用 Jupyter Notebook。现在，他们被迫使用各种可复现的虚拟环境，而这种做法在不断摧残团队。我目睹过太多类似的情况了。正确的解决之道并不在于增设更多纪律条文和官僚职位，而在于解决实际问题。比如我们开发了一款名叫 nb merge driver 的工具——很多朋友不了解，其实 notebook 本身非常适合 Git。只是 Git 并没有默认为 notebook 提供合并驱动，而仅支持基于行的文本文件。可 Git 系统是支持插件扩展的，所以我们可以轻松通过插件兼容 JSON 文件。

于是我们开发了这类驱动程序。现在只要使用我们的 merge 驱动进行 Git 差异比较，就能在单元格级别上看到差别。每次遇到合并冲突，可以直接定位到单元格级别的具体冲突点，保证 notebook 始终可以在 Jupyter 中打开。NBDime 也实现了相同的功能，大家可以随意选择。我认为这才是解决之道：继承 Brett Victor 的理念，让人们紧密把握探索性工具。所以一定要完善探索性工具，我甚至认为所有软件开发者都应该采用探索式编程，以深化对于所处理对象的理解。这样我们才能建立起对目标的强大思维模型，进而逐步提出更优解、建立更加完善的测试。

我自己几乎不需要调试器，因为我的程序里基本不存在 bug。这并不是因为我编程技艺超群，而是我采用微步迭代的方式开发——每个小步骤都经过验证，我会亲眼见证其运行效果并且实时交互。如此一来，bug 根本就无处藏身。

Dr. Tim Scarfe：其实我对这事有点矛盾。我认同你的观点，但也会质疑那些宣称组织运作模式终将固化、不再有进一步优化空间的家伙。可创新的本质就是适应性嘛，对吧？我们应该尽可能扩大适应性的覆盖范围，所以必然需要有人持续测试新想法、发现新的限制条件。

但同样的，我们也需要那些稳健可控的技术，比如用云服务和持续集成 / 持续交付（CI/CD）等方式将成果投入生产环境。

Jeremy Howard：没错。比如 nbdev 就自带开箱即用的 CI 集成，还内置了测试功能——毕竟源代码都是 notebook 形式，整个探索过程都包含在内：API 如何动作、调用时的效果、函数实现方式、使用示例、说明文档等等。在这样的环境下，大家自然能把软件工程处理得更好。总之就应该全都要。

AI 没大家说得那么吓人

Dr. Tim Scarfe：你还记得那份关于《应将存在性风险列为紧急优先事项》的声明吗？当时 Hinton 和 Demis Hassabis 都有联合署名。而你基本上是通过反驳来回应的。聊聊那时候的情况吧，你觉得我们应该担心 AI 带来的存在性风险吗？

Jeremy Howard： 那只是特定时期的问题，对吧？如今的形势已经有所转变，实在是谢天谢地。我们所处的整个学术社群，从某种意义上赢下了这场论战。现在我们面临其他更为紧迫的问题，但当时的主流观点是：AI 即将实现自主化。这种随时可能实现的自主，也许会将世界推向毁灭。这种观点很大程度上源自 Alizia Yukowski 的研究，但其结论已经在多个层面被证明是错的。

Dr. Tim Scarfe： 他们当然也有反驳的理由。

Jeremy Howard：没错，就像邪教做出的末日预言一样，只要不给出具体的日期，他们就总有话说。

Dr. Tim Scarfe： 那我稍微修正一下：当前的大模型在特定领域确实可以作为智能体，ARC 挑战赛的结果已经证明了这一点。因此如果把方向收窄一些，可能自主的目标真会更快实现。而这就带来了新的难题：当全面的智能化与自主性实现之后，如果缺少知识和约束，AI 只会更快走向错误方向。很多人其实没有意识到大模型在认知层面的匮乏……

Jeremy Howard： 但这些都跟我反驳的核心观点无关——我们始终强调，那份声明对于真正的危险所在做出了误判。没错，当一种极具颠覆性的技术涌入世界，就会让某些人获得颠覆性的力量。而那些痴迷权势的家伙必然会试图垄断这项技术。

技术越强大，渴求者们的欲望就会越强烈。所以真正的问题在于：如果不在乎这些潜在风险，单纯想尽快推进自主 AI 的崛起，那么唯一的结果就是权力得到空前的集中。这正是当下我们已经反复见证的现实。所有的权力都被交给了超大型科技企业和政府，普通人根本就无法染指。而在我的威胁模型当中，这是最糟糕的结果，因为它带来了权力的过度集中。而渴望权力的人只要拿下那个集中的点，就能获得一切。

Dr. Tim Scarfe：那我们能不能明确一下“权力”的定义？因为我们刚刚也聊过，AI 的实际影响力并不像大众想象中那么强。

Jeremy Howard：我认为 AI 到底有没有那么强大或者那么深远的影响，其实都不重要，因为这纯属推测。我坚持的是，这种权力就不该集中在少数公司或者政府手中。因为一旦集中，贪婪者会迅速将其垄断，进而摧毁整个人类文明。过去几百年来，人类社会曾经反复遭遇过这种困境。

就像文字发明之初，只有极少数精英能够掌握书写能力，而史册也就在他们的指尖流转。当时也有类似的论调：若放任大众书写，他们必将写下我们不愿见到的内容，后果不堪设想。

可印刷术的普及证明，根本没这回事。选举制度的推行也是如此。社会始终在与既得利益者的本能性偏见对抗，试图证明变革并不是威胁。所以当我们讨论 AI 可能变得极其强大时，那带来的成果到底是让少数人掌控收益，还是把成果共享给整个社会？

我的观点肯定是后者。当然也有人会说，不用担心啦，AI 不可能发展得那么强大。这个不重要，因为大家根本就没有确凿的证据，谁也说不准未来会发生什么。但我可以明确地讲：万一那么强大的技术出现了，那我们应该放任马斯克或者特朗普一人将其掌控吗？这明智吗？

Dr. Tim Scarfe：Dan Hendricks 曾经讨论过攻防不对称性的话题。建立制衡性的防御体系确实非常重要，但权力失衡又是一种不容辩驳的现实。无论是 Meta 还是 Facebook，这类平台掌握着所有用户数据，知晓我们的全部行为。至于 OpenAI 和 Claude 这类技术，实际效果反而不如预期，因此允许人类继续参与其中。可数据确实还是由他们掌握的，对吧？

假设我们在研发创新技术时使用 Claude，那上传的信息就能让他们轻松复制我们的成果。所以具体来讲，你指的是哪些风险？

Jeremy Howard： 我指的风险并不是这些具体的情况，而是一个假设性的问题：如果 AI 变得极其强大，未来会是什么样的样貌？

Dr. Tim Scarfe：比如现在就有人宣称，AI 代表着新的生产方式。这在我看来完全是夸夸其谈，那依你的判断，这里具体存在怎样的风险？

Jeremy Howard： 按目前的技术状态来讲，我认为最大的风险就是人们会丧失持续提升自身能力的机会，逐渐陷入能力衰退的陷阱。这才是我最担忧的问题。

隐私风险确实存在，但我至少不觉得比谷歌和微软早期的情况更严重。你之前在微软工作过，肯定清楚他们掌握着多少普通用户的 Outlook 和 Office 数据。谷歌也是如此，Google Workspace 和 Gmail 用户的数据量已经说明了一切。这些隐私问题确实存在，但我认为更可怕的是企业只是外包商，负责替政府进行数据收集的可能性。

过去是 ChoicePoint 和 Acxiom 这类公司，如今又出现了 Palantir 等企业。美国政府不能亲自建立大规模公民数据库，但法律却不禁止企业自建数据库，这就相当于政府把业务外包给了企业。这才是最大的问题，当然并不是 AI 时代的独有难题。

以你所在的英国为例。众所周知，英国的监控体系早已实现全面覆盖，这也让对监控数据的利用更加便捷。以及需要资源充足的机构投入足够的人手，才能让土地上发生的一切都尽在掌握，但现在 AI 能够轻松完成。所以我不是说 AI 时代才带来了隐私问题，但它至少让隐私问题扩大化了。

原文链接：

https://www.youtube.com/watch?v=dHBEQ-Ryo24&t=3914s

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：核子可乐、Tina，36氪经授权发布。

研究称 AI 的生产力提升仅为每周 16 分钟

Sun, 15 Mar 2026 19:43:06 CST

根据 Foxit 的《State of Document Intelligence》报告，AI 的生产力提升远低于高管的预期，仅为每周节省 16 分钟工作时间。虽然 89% 的高管和 79% 的终端用户表示 AI 工具让他们感觉工作效率更高，但将审核和验证 AI 生成输出的时间考虑在内之后，实际节省的时间大幅缩水。对美国和英国 1000 名办公室员工和 400 名高管的调查发现，高管认为 AI 每周能为他们节省约 4.6 小时，但他们需要花费大约 4 小时 20 分钟验证结果。终端用户的情况类似，他们估计节省了 3.6 小时，但需要花费 3 小时 50 分钟审核 AI 生成的工作。一旦将这种“验证负担”考虑在内，高管每周仅节省 16 分钟，终端用户实际上增加了约 14 分钟。

OpenClaw分享

Sun, 15 Mar 2026 14:45:28 CST

以下PPT和内容，来源是我跟一群爱学习的朋友一起学时下大火的OpenClaw小龙虾，我给大家做了个小分享。

PPT几乎是OpenClaw输出的内容，下面的会议总结也是GPT根据会议录屏总结的。

需要注意的是，我其实没有将小龙虾玩得很深，因为我从心底里是不信任AI的，也就不敢给它太多权限。所以内容也都比较浅，请见谅。

OpenClaw 会议总结

这次分享的核心，不是在介绍一个“聊天机器人”，而是在介绍一套可自托管、可扩展、可执行任务的 个人 AI 基础设施。分享者把 OpenClaw 定位为“装进手机里的 AI 助手”：用户通过 WhatsApp、Telegram 等聊天入口发出请求，背后由部署在自己电脑或服务器上的 OpenClaw 网关完成会话管理、记忆注入、工具调用和本地执行，再把结果返回到聊天端。PPT 对这一定位和整体链路描述得很清楚。

一、这场分享的主线是什么

整场分享围绕一个很明确的问题展开： 为什么需要 OpenClaw，而不是直接用通用聊天产品。

PPT 给出的答案是，ChatGPT 更像“顾问”，而 OpenClaw 更像“助手”——它不是只回答问题，而是要具备持续记忆、调用工具、执行动作、主动提醒和接入个人环境的能力。具体包括：

有长期记忆，不是每次会话都“重新认识你”
能直接操作文件、终端、日历等外部系统
可以通过心跳机制和定时任务主动触达用户
以自托管方式运行，强调自主可控和隐私优先
按用量计费，面向愿意折腾和深度定制的用户群体

从表达方式上看，这不是一场“功能堆砌式”介绍，而是在尝试说明： OpenClaw 的价值不在模型本身，而在模型外层那一整套长期运行的个人代理系统。

二、OpenClaw 的核心能力框架

根据 PPT，OpenClaw 的能力可以概括成四层：

1. 聊天入口层

支持 WhatsApp、Telegram、iMessage、Discord、Slack 等多个消息平台，目标是让用户沿用已有通信习惯，而不必专门切换到某个 AI 产品界面。PPT 明确强调：“换了聊天软件，AI 还是同一个——记忆和设置全部保留。”

2. 网关与调度层

消息进入后，由 OpenClaw 网关完成身份验证、会话管理、消息路由、工具执行和记忆注入。PPT 用“一条消息的旅程”说明了从手机发消息，到加载 USER.md / MEMORY.md，再到发给模型、决策调用工具、执行、最后自然语言回复的完整链路。

3. 记忆与人格层

这是分享里非常重要的一部分。PPT 把记忆系统拆成多个 Markdown 文件：

SOUL.md：AI 的人格、风格、语气
USER.md：用户身份、背景、偏好
MEMORY.md：长期累积的重要记忆
AGENTS.md：规则、权限边界与行为约束

这种设计的意义在于：AI 的“性格、知识、权限和历史”都变成了用户可编辑的文本资产，而不是封装在黑箱里。

4. 工具与执行层

PPT 列出的工具包括文件读写、shell 执行、浏览器控制、网页搜索、手机节点、canvas、tts、消息推送等，目标是让 AI 能从“回答”升级为“完成任务”。同时也强调了工具级权限控制、白名单验证、分场景配置以及 Docker 隔离等安全措施。

三、这次录屏里真正有说服力的部分：不是讲概念，而是做了演示

结合录屏画面看，分享并没有停留在 PPT 层面，而是穿插了实际操作，这一点增强了可信度。

从录屏中能看到，分享后半段进入了一个类似 ClawHub 的界面，现场展示了一个 Trello Skill 的文件内容、配置说明和调用方式；随后又切到 Telegram 对话窗口，以及本地终端，演示如何通过消息端触发配置流程，并把第三方能力接到 OpenClaw 体系里。这个流程说明两件事：

Skills 不是抽象概念，而是可安装、可配置、可调用的扩展能力。
OpenClaw 的“手机端 AI 助手”并不依赖复杂前端，而是通过消息通道串起技能、工具和运行环境。

从演示节奏上看，分享者实际上是在证明：

OpenClaw 的价值不只是“能接模型”，而是能把模型、工具、个人环境、外部平台和长期记忆组合成一个持续在线的代理系统。

四、这场分享传达出的三个关键判断

1. OpenClaw 的竞争点不是模型能力，而是“代理能力”

这套系统的重点不是谁的模型更聪明，而是谁更能接入现实世界、持续服务用户、并完成闭环动作。PPT 中“帮你做，不只说”就是这个核心。

2. 它更像一个 AI 操作系统，而不是单点应用

无论是记忆文件、agent 配置、skills 插件、heartbeat、cron，还是多账号/多角色隔离，整体架构都更接近一个可编排的 AI runtime，而不是普通对话产品。尤其是“家庭共享、工作/私人分离、权限分级”这些设计，说明它从一开始就考虑了长期运营而不是一次性 demo。

3. 目标用户非常清晰：不是大众用户，而是愿意部署、愿意调教、愿意承担维护成本的人

PPT 直接写明更适合有服务器/NAS/Mac mini、喜欢定制、想要私人 AI、重视掌控权的人。这一点判断是务实的，也符合演示中的实际复杂度。

五、我认为这场分享里最值得保留的亮点

最亮的点有三个：

一是记忆系统设计。

用普通 Markdown 管理 persona、user profile、memory、agent rule，这个思路非常工程化，也非常利于用户理解和修改。

二是主动性机制。

PPT 提到 heartbeat 每 30 分钟自动唤醒、检查邮件/日历/待办，并通过 cron 做天气摘要、周报提醒、服务器状态检查。这意味着 AI 不再只在被提问时才工作，而是能持续担任“个人运维助手”。

三是多智能体与权限隔离。

同一套网关下，可以给自己、家人、工作场景分别配置不同 Agent，并限制工具权限。这使它具备了现实部署价值，而不是仅适合个人极客实验。

六、这场分享也有意保留了几个“没有过度包装”的点

这一点我觉得反而很专业。

PPT 里并没有把 OpenClaw 完全神化，而是明确写出了几个边界条件：

文件和命令虽然在本地处理，但 部分内容仍会发送到 token provider，因此“隐私优先”不是绝对封闭
为了达到较好效果，上下文很长， 按量付费未必便宜
Docker 隔离是建议配置，不是默认配置
在“重视隐私的人”这一页里，演讲者自己还留了保留意见，说明他并不是无条件认可全部宣传口径

这些细节说明，分享者对产品定位是偏清醒的：

OpenClaw 很强，但它不是零成本、零配置、零风险的万能方案。

七、结论

如果要用一句更专业的话来概括，这次分享展示的是：

OpenClaw 不是一个 AI 聊天应用，而是一套面向个人场景的、自托管 AI Agent 基础设施。它通过消息入口、长期记忆、工具调用、任务调度和多代理隔离，把大模型从“会回答”推进到“能持续协助与执行”。

The post OpenClaw分享 first appeared on I am LAZY bones?.

被315点名的万亿隐秘生意：“污染”DeepSeek

Sun, 15 Mar 2026 22:53:00 CST

3月15日，央视315晚会点名GEO产业链。按照业内人士的爆料，央视财经记者在多个网络平台进行查询，很快就搜索到了名为GEO的业务。其能通过给AI平台投喂假数据，干预AI检索结果。

凤凰网科技早在2025年中时，就发现了这个隐秘的现象，当时调查发现DeepSeek正在成为重点被“投毒”的AI大模型，并在全网首发报道了《揭秘万亿隐秘生意：“污染”DeepSeek》一文。

以下是报道原文，首发于2025年8月14日。

打开DeepSeek，当你敲下“xx地方最好吃的餐厅是什么”的时候，得到的AI答案，也许经过了一场人为“设计”。

这便是GEO（Generative Engine Optimization，Al 搜索排名优化）的“功劳”。

2024年6月，一篇由印度理工学院和普林斯顿大学研究者发表的论文《GEO：Generative Engine Optimization》首次明确了这一概念。

它的核心目标，是提升品牌信息在AI生成答案中的“存在感”。研究发现，通过优化权威表达、关键词布局、数据引用等策略，能让内容在AI回答中的“出镜率”提升高达40%。

往搜索框里插广告，本就是门大生意，现在这门生意延展到了AI对话框里。以Profound为代表的AI搜索优化公司，和一些从SEO（搜索引擎优化）转型过来的公司，正迅速获得资本青睐。

其中，Profound一年融资三次，估值超过1亿美金。

据《财富》杂志报道，2025年8月12日，Profound 宣布完成 3500 万美元 B 轮融资，由红杉资本（Sequoia Capital）领投，现有投资方科斯拉创投（Khosla Ventures）、凯鹏华盈（Kleiner Perkins）及英伟达旗下风投部门 NVentures 跟投。

本轮融资使 Profound 成立至今的总融资额达到5850 万美元。此前，该公司分别于 2024 年 8 月获得 350 万美元种子轮融资（科斯拉领投），2025 年 6 月完成 2000 万美元 A 轮融资（凯鹏华盈领投）。

红杉资本合伙人帕特·格雷迪（Pat Grady）评价极高：“Profound 正重新定义专业信息获取方式。其技术对知识密集型行业的效率变革具有战略价值——正如我们 1999 年投资Google时看到的颠覆潜力。”

2025年，全球GEO市场规模突破420亿元，年复合增长率达87%。Gartner预测，2026年传统搜索引擎25%的流量将流向AI工具，而Google“零点击搜索”占比已达58.5%。

今年以来，国内 GEO 概念的火热，很大程度是受到了 DeepSeek 爆发影响的连锁反应。以Deepseek为代表的对话大模型，被视为搜索的流量新入口，而围绕AI模型的搜索优化，也成了一些人眼里的“好生意”。

如果说，传统搜索时代，品牌通过SEO优化争夺搜索结果页面的排名，在AI时代，品牌需要争夺的，则是AI回答中的提及份额。

这一切，需要怎么办到？

“离AI风口最近的一次”

“AI信任时代——10亿人+使用，AI搜索成为超级流量入口”，一家做GEO的初创公司企业服务手册这样写道。

在这个领域，惯用的流程是，根据用户提问需求，来匹配品牌关键词，支持模糊语义定向，精准呈现广告信息。

手册中还列出了成功案例：以“深圳国际幼儿园哪家比较好”提问，列出了元宝、kimi、豆包、通义千问、文小言的AI页面，深圳福田某所双语幼儿园的名字赫然出现在首位推荐中。

国内平台每月150-300元一个关键词，海外平台每月300-500美元——对很多企业来说可以接受。

新玩家正蜂拥而至。李鑫的报价则昂贵的多，一万块一个词义，保证在一个季度（90天）内，相关搜索词中，“保证品牌排名在前三”。李鑫此前做媒体代理出身，一个月前开始准备转型做GEO，他认为这是自己“离AI风口最近的一次”。

在跟客户交流中，他得到的企业需求是，希望能够让游客直接搜索到自己的品牌。“怎么让AI给自己引流”。在大连，李鑫接触的多是餐饮老板，看重营销，“他们手机里都有Deepseek，也很想拥抱AI。”

像李鑫这样帮中小企业做GEO的，吃下的正是此前市场营销的预算——“这部分钱，不去投抖+，就是投大众点评的必吃榜。”现在，他们都不如DeepSeek一个回答。

在“路演”过程中，李鑫发现，很多企业并不排斥，“只要（这些企业）做过百度竞价排名，一般会持观望态度”，虽然不确定效果怎么样，但总体秉持着一种“如果竞对做，我就做”的FOMO（害怕错过）氛围。

容易被搜索、推荐的餐饮、食品品牌，也许是国内第一批“自发”用上“AI代言”的。一些品牌在自家商品的电商平台展示页面，会直接用“AI首推”做宣传；餐饮店的门口，也特意打印出“跟DeepSeek对话，店面被推荐”的立牌。

当人们的搜索行为、对话更多发生在Chatbot中，AI的答案，似乎成了“权威”认证。“没有人会否认，AI是未来的答案。”李鑫说，他打算先从餐饮入手，之后再考虑延伸到一些快消品牌。

在国内，以DeepSeek为代表的对话式模型，承载的搜索流量急剧猛增。

为DeepSeek提供联网搜索服务的博查家数据显示，自2025年3月开始，其SearchAPI的日均调用量已达到3000万次，承担了国内AI应用约60%的联网搜索请求。这一数字约为搜索引擎微软必应的三分之一。

特别是联网搜索和“深度思考”模式推出后，更加深了人们对AI答案的确信度。

传统搜索模式下，品牌可以通过SEO优化、付费广告和内容营销来影响消费者的决策过程，但在对话模式下，传统的营销手段不那么有效了。

当AI在回答用户问题时，不是基于搜索排名，而是基于对大量信息的理解和合成。这意味着，品牌需要的，不再是优化搜索结果页面，而是优化AI训练数据和知识图谱中的信息。

根据Profound的数据，目前大约10%的推荐流量来自AI对话，但他们预测到2027年，这个比例将超过50%。更通俗的说，就是有一半人会通过AI推荐来买东西。到时有价值约2.5万亿美元的在线商务将通过AI对话驱动。

当ChatGPT、Gemini、Perplexity 直接把答案端到用户面前，这意味着，品牌被“引用”即存在，不被提及即死亡。

至于GEO的效果转化，海外已有监测手段。Profound和Brandtech等公司已经开发了软件，用于监测品牌在ChatGPT、Claude、Overviews等人工智能服务中出现的频率。

用AI污染AI，当心被模型“封杀”

当前，GEO市场玩家分为三类：传统SEO公司、做内容营销出身转型的，以及专攻AI搜索的初创团队。

当然，也存在一部分低质、铺量的“灰产”商家，用传统铺软文走量的形式，做“让品牌被AI看到”的搜索优化。

而在“灰产”之外，一些投身GEO行业的从业者则认为，内容生产能力才是未来竞争的核心壁垒。

但问题是，大模型算法不透明，导致决策难以被理解。当下的GEO似乎始终是一个处在黑箱中的优化框架的内容采纳偏好侧重不同，需要“定制”测评维度和优化策略，再根据模型反馈持续迭代，没办法“一套方案走天下”。

不过，对大部分国内商家来说，针对DeepSeek做GEO是性价比最高的选择。“现在很多家都接了DeepSeek，R2模型出来后，一家通吃的可能性更大。”

DeepSeek的深度思考模式，让供应商们找到了一个较好操作且低成本的投放逻辑：“用AI生成内容喂AI”。

也就是说，拿到企业资料和想露出介绍后，喂给AI让其生成不同的“网稿”作为语料，再“投喂”到可触达网站上，以便被AI收录。

李鑫刚签的一单，就是用传统SEO工具跑关键词，关联核心词，再用企业资料生成优化内容并投放。“对小厂来说，这可能是亲手触及AI最近的一次。”他也承认，效果好不好，目前还不好评估。

“现在大部分公司是通过SEO的技术手段去玩GEO优化，没意识到长期价值在于建立一套工具化、机制化的生态链路。”另一位从业者老莫说，“本身伤害用户体验的优化方法，模型厂商将来的态度一定是赶尽杀绝。”

而且，大模型有反作弊策略，对于“污染”行为会进行防御，这意味着“灰产”模式难以为继。

周奇的团队主要面向海外和中国出海企业，因为国内企业付费意愿较低。他认为，GEO的核心壁垒是内容生成能力——要帮企业生产真正有价值的信息，补充AI生态所需的内容供给。

他的判断是：随着AI生成内容爆发，低质内容存活期变短，但质量要求反而更高。企业需要的是“足量且优质”的内容，同时控制成本。“未来像OpenAI走订阅制的大模型，或许能远离广告。但如果GEO泛滥，才最可怕。

“AI搜索是大势所趋，一是技术本身新，二是传统搜索的‘垃圾信息山’逼着用户逃离。百度把垃圾信息当资产，而不是负担。”周奇分析道。

那么，未来AI里是否会出现“竞价排名”？这取决于大模型厂商的选择。

SEM是通过付费广告（如Google Ads、百度竞价）快速获取流量，按点击付费（PPC），注重即时效果；SEO是通过优化网站结构、内容和技术，提升自然搜索排名，属于长期积累策略。

“从长期趋势来说，一定有公司需要对AI时代的营销做生态补全和适配。”周奇认为，不同于SEO时代的分散格局，GEO或将加速行业集中。

大模型遭“投毒”？给AI“洗脑”已成产业链

Sun, 15 Mar 2026 22:53:00 CST

按照业内人士爆料，记者在多个网络平台查询搜索到了一项名为GEO的业务，这些从事该项业务的服务商号称，用户只需支付相应的费用，它就能在各大主流AI大模型里，让客户的产品榜上有名；让客户的商品广告，成为AI模型给出的“标准答案”。

通过GEO技术，真的能给AI“投毒”、真的能“驯服”并操控AI吗？

按照网络上的信息，记者联系上一家业内知名的GEO服务商。负责人王总接待了记者，他介绍，他们公司是最早从事GEO业务的公司之一，仅仅一年时间就已经成功服务了200多个客户，遍布各行各业。王总告诉记者，他们公司的强项，就是能够帮助客户，在消费者使用AI大模型搜索时，让客户排名前列。

GEO服务商王总：我们目前搜索出来是这样的结果。我们在任何平台上面都能把排名做到前三位。怎么能把排位做上去？在这些AI平台上面去给你们做内容的输出，相当于去给你们做这些软文，然后让这些AI平台去刷录、收录、抓取。

同时，王总也告诉记者，现在AI大模型的算法更新频繁，要想维持AI大模型的持续推荐，他们必须持续大量投喂与客户相关的推广软文。

GEO服务商王总：AI每周都会有算法的更新，一旦更新了之后，排名或者所抓录的东西不太一样，所以我们要一直去做内容输出，去投喂、大量投喂。

不仅是王总的公司在大力推广这项能操控AI的所谓新技术，在其他从事GEO业务的服务商口中，如何操控AI、让AI“听话”、给AI“洗脑”，几乎是这些公司推广该业务的核心话题。

GEO服务商章总：你在AI的世界里面，你怎么把证据链给做足，让（AI大模型）觉得这就是真的，而且是有用的。AI大模型经过多方信息交叉，它觉得你优于同行的核心优势，自然而然就会把你放在第一位。

GEO服务商程总：人家不知道这是广告。所以，为什么说AI出来的结果人家会信任。可能人家的产品质量没有你过硬，但是它有AI做辅助、做佐证、做背书。现在很多人都会做（GEO投放）。

业内人士告诉记者，GEO作为优化信息发布、提升推广效率的工具软件，在某些商业公司眼中，却被挖掘出了另外的作用。如果通过这种软件在互联网上系统性、定向投放大量的“虚假信息”，确实更容易被AI大模型捕获，这些虚假信息就很可能成为AI优先提供给消费者的所谓“标准答案”。

那么，通过GEO技术真的能让AI“夹带私货”，甚至投放虚假信息吗？

为了让记者更真实地了解到眼下AI产业发展中的这个问题，业内人士向记者具体演示了如何使用GEO技术，干扰AI大模型的信息抓取。

业内人士在电商平台上，随机购买了一款名叫“力擎GEO优化系统”的软件。之后，他虚构了一款名为Apollo9的智能手环，并将虚构的产品信息输入软件系统，勾选文章创作指令。

不一会儿，这个力擎GEO优化系统就自动生成了十余篇智能手环的宣传软文，所有虚假信息都被完整写入，甚至包括业内人士故意虚构的极为夸张的产品信息。还杜撰了用户反馈，称数据精准度超出预期，甚至伪造评分，被一举评为业界第一名。

点击发布，“力擎GEO优化系统”软件开始自动执行发布任务。只见它自动打开业内人士事先准备好的自媒体账号，在文章发布页面自动输入标题、填充文章内容、插入图片，整套流程一气呵成，很快就在业内人士的自媒体账号上成功发布了2篇文章。

两个小时后，业内人士在某款AI大模型中询问：“Apollo-9智能手环怎么样”。AI模型就直接介绍了起来：最大亮点是健康监测功能，还直接照搬了业内人士虚构的“量子纠缠传感”“黑洞级续航”等虚假宣传话术。最终结论称，该手环适合中老年用户与健康养生爱好者。

查询发现，这款AI大模型所参考的资料，正是上午刚发布在业内人士自媒体账号上的那篇虚构文章。仅凭一篇杜撰的文章，就让完全虚构的产品被AI模型抓取，这一结果让人深感意外。

业内人士告诉记者，要想取得最好的效果，给AI模型投喂的数据，一是要数量够多，二是要角度丰富，便于AI模型进行交叉验证。

随后，业内人士又选取了这款虚构智能手环的8篇“专家测评”、2篇“行业排名”、1篇“用户测评”，共计11篇由力擎GEO系统软件撰写的虚构软文，在三天内通过力擎GEO系统发布在了互联网上。

随后，业内人士在AI大模型平台展开询问：“智能健康手环推荐”，就有两个AI大模型推荐了这款业内人士虚构的智能手环，而且排名靠前。

纵观整个演示过程，业内人士仅凭这款力擎GEO系统，轻轻松松地就将一系列虚假信息发布在互联网上，并成功投喂给AI大模型，最终获得了多个AI大模型的推荐。

通过这款力擎GEO系统对AI大模型潜移默化的一番围猎，凭空捏造出来的这款商品，就这样被荒唐地推向了使用AI大模型的消费者。

GEO业务的从业者们，真的是以围猎操控AI大模型的思路来经营这个生意的吗？记者联系上了这款力擎GEO系统的运营者李总。他告诉记者，GEO业务受热捧的主要原因就是它能在AI大模型里帮客户“喂料投毒”，实现客户的商业目的。

力思文化传媒有限公司李总：因为全网的人投“毒”投太多了。你看我们现在（干）GEO的都是投“毒”，投的信息源太多，网上信息并不是很准。

记者：你刚才提到投“毒”的概念，这种东西不好吧。

力思文化传媒有限公司李总：是不好，但是每个商家都喜欢，都希望是别人别投“毒”，自己投“毒”，或者给别人投点“毒”。我虽然不是第一，哪怕说我就是北京的第一，我都想说成我是华北的第一。这样有没有投“毒”成分在里面？它就有啊。第二种情况是，我就看不得对手好，我也做不上去，但是我给你投点“毒”还是可以的。

记者：抹黑一下。

力思文化传媒有限公司李总：对。抹黑一下这能力还是能实现的。现在他们好多公司做不上去的，就大品牌之间，比如说手机品牌，就5个位置，最多10个位置。这么多手机怎么弄？每个人一年可能投上亿元的广告费，我花个几百万元投点“毒”总行吧。

记者：是谁在帮品牌干这些？

力思文化传媒有限公司李总：都是各种GEO公司。

李总表示，想做GEO业务，操控AI大模型的关键节点，就是在各大互联网账号上“发稿”。他告诉记者，GEO业务的火爆，眼下就催生出了不少专门从事发稿业务的公司和平台。他们长期承揽各种发稿业务，以便让AI大模型引用和抓取，成为围猎AI大模型，进行数据投“毒”的重要一环。

力思文化传媒有限公司李总：GEO把（网站）带火了。那些网站平常哪有什么利润，突然一下发稿需求就来了。你知道网站一天发多少篇吗？几百篇，每分钟都在发。一篇是几十元，你想发稿平台一天赚多少钱。

为什么放弃了 RAG？ RAG 的六大难题

Fri, 13 Mar 2026 14:17:03 CST

RAG 本身并不算是个坏主意。我们认真实践过，也确实在某些场景下跑通了。

去年，我们花了几个月搭过几套完整的 RAG 管线：三阶段处理（ Extract 、Chunk 、Embed ），三种搜索策略（ Vector 、BM25 、Hybrid + Reranking ）。从文本提取，粗排，到 Rerank 精排，每一个环节都认真做了一遍。工程量不小，技术上看着很漂亮。

但最终不得不承认一个事实： 效果不好

这篇文章不是要批判 RAG ，而是诚实地分享下我们具体遇到了哪些问题，以及我们后来怎么想的。以及，小广告。。。

问题一：Embedding 模型两难

做本地桌面应用，Embedding 模型的选择是一个没有好答案的问题。

小模型（参数量 < 500M ）在设备上跑得动，但语义理解质量不稳定——碰到专业文档、跨语言搜索、长文档时，召回率明显下降。大模型（ 1B+）质量好，但在普通用户的笔记本上内存和计算开销太大，后台常驻时对系统资源的占用让人无法接受。

桌面应用没有服务器可以依赖，只能在"跑得动"和"效果好"之间妥协。选了一个，另一个就要让步。这个困境在服务端应用里不存在，在本地优先应用里却是无解的。

问题二：领域词汇不敏感

向量语义搜索有一个根本性的弱点：它对专业术语的理解很差。

原因并不复杂。Embedding 模型是在通用语料上训练的，而代码函数名、医学缩写、法律条款、产品专名这些词在训练语料里出现频率低，在向量空间里的位置偏僻且不稳定。

实际表现是什么样的？用户搜 "RLHF"，不一定能找到写着 "Reinforcement Learning from Human Feedback" 的文档。搜"LTV"，可能匹配不到写着"用户生命周期价值"的分析报告。搜某个产品的型号，向量搜索根本抓不住这个词的准确语义。

这不是配置问题，不是参数调优能解决的，业内常见做法是做 embedding 模型的微调，但一般都是针对特定领域，只能在 ToB 场景中 work 。

Embedding 优势是模糊语义匹配，它的劣势恰好就是精确词汇匹配。而用户的真实需求往往是两者都要。

问题三：Rerank 的代价

召回率低和准确性差，是 RAG 管线的两个经典问题。针对准确性问题，业界的标准解法是引入 Rerank 模型做最后一步的精排。

我们也做了这一步，然后发现问题并没有被解决，只是被转移了。

Rerank 模型比 Embedding 模型更重、更慢。引入它之后，整个检索链路的延迟大幅上升，对本地应用来说尤其明显。更关键的是，Rerank 模型同样是在通用语料上训练的，同样存在专业词汇不敏感的问题——它只是在你已经召回的候选里重新排序，而不能召回那些一开始就没被捞到的文档。

最终结果：链路变慢了，架构变复杂了，根本问题还在。引入 Rerank 后，排序质量的提升非常有限，反而让 BM25 的作用几乎被掩盖了。

问题四：碎片化的上下文

分块（ Chunking ）是 RAG 最无法绕开的问题。

文档被切成固定大小的片段之后，每个片段都与它的前后文脱节了。AI 拿到的是一段从报告中间截取的内容，不知道这段话在哪个章节，不知道前一段在讲什么，也不知道后续有没有结论。

最糟糕的情况是：一个关键段落恰好横跨两个 Chunk 的边界，两个 Chunk 都能匹配到，但又各自不完整。AI 拿到的两份碎片都沾了边，却都缺少关键信息，最终给出一个似是而非的回答。

这个问题业内有很多补丁办法，比如：加大 Chunk 重叠，加入父 Chunk 检索，引入 Small-to-Big 策略……每个补丁都能在某个维度上改善问题，但也都会带来新的代价——更多 Token 、更复杂的管线、更难调试的行为、更加无法通用。

我们把这些补丁叠在一起，得到了一个复杂、易出错，但仍然不够好的系统。

问题五：不同文档类型需要特殊处理

通用分块策略对不同文档类型的效果差异极大，这是我们当初没有充分预判到的。

论文有 Abstract + 正文 + References 的结构；书籍有章节层级和页眉页脚；合同有条款编号和交叉引用；代码文档有 API 列表和示例代码；表格类文档的"内容"是列名和数据类型，而不是单元格里的文字……

固定窗口切块的策略不理解这些结构，分块点往往切在语义中间，把标题和它的正文分开，把条款编号和条款内容切断，把表头和数据分离。

每种文档类型其实需要完全不同的处理逻辑。但针对每种类型都写特化的解析器和分块策略，工作量巨大，维护成本也高——而且即使都做完了，效果也只是"比通用策略好一些"，仍然是碎片化的。

问题六：Agent 使用体验极差

以上五个问题单独看，每个都还在可接受的范围内，但当 RAG 被实际接入 AI Agent 使用的时候，所有问题叠加在一起，效果非常糟糕。

一个真实的场景：AI 在帮用户分析一份合同，调用 search() 检索相关条款，拿到了 10 个 Chunk 。有几个 Chunk 沾了边，但信息不完整。AI 无法判断该怎么继续，只好调整关键词重新搜索。再拿到 10 个 Chunk ，还是不够。再换关键词，再搜一次。

每次搜索都是黑盒：AI 不知道换哪个关键词才能找到它需要的内容，不知道文档里到底有没有这个信息，不知道自己距离答案有多远。这种低效不是 Agent 能力不够，而是工具本身的设计不支持它做出合理的决策。

RAG 在设计上是为"用户直接提问"场景优化的，不是为"Agent 自主探索"场景设计的。

行业也在转移

这些问题不是我们独有的，业内已经有明显的应对趋势：

微软的 GraphRAG 引入知识图谱来缓解上下文碎片化问题，把相关实体和关系显式地存储下来，而不是靠碎片拼凑。

PageIndex 不按固定大小切 Chunk ，而是以页面为单位建立索引，保留文档的自然边界。

Agentic RAG 尝试让 AI 自主决定检索策略，而不是走固定管线——方向是对的，但在 RAG 架构上叠加 Agent 逻辑，复杂度随之翻倍。

最彻底的转向来自 Claude Code 和 Manus 。它们干脆放弃了 RAG ，回到最原始的方式： Glob + Grep + Read。找文件、搜关键词、读内容。没有向量数据库，没有 Embedding 模型，没有 Chunk 管线。效果反而更好。

这让我们想明白了一件事：RAG 的设计假设是"LLM 不够聪明，需要我们帮它把信息预处理好"。这在 GPT-3.5 时代是合理的。但现在的 LLM 已经有能力自主使用工具完成多步检索任务——它们不需要预切碎片，它们需要的是线索：文件在哪，结构是什么，然后它自己能决定读什么、读多少。

我们的解法：Outline Index

Glob + Grep + Read 对代码库很有效，但对用户文档行不通。代码库里 src/services/auth.ts 这个路径本身就在告诉你这是认证服务；但 2024 年度总结(修改版)(最终版).docx，路径告诉你的信息约等于零。更别提 PDF 和 Word 是二进制格式，grep 根本读不了。

所以我们的问题变成了：能不能给文档也建立一套等价的"目录索引"，让 AI 用 search → outline → read 的方式渐进式地翻阅你的文件？

我们把这套方案叫做 Outline Index。

核心思想一句话： 不替 AI 预切信息，而是给它一张地图。

为每个文档建立一份结构化"名片"，包含文档的元数据（标题、作者、关键词、摘要）和结构大纲（章节标题、层级关系、行号范围）。AI 按三层路径访问文档：

search：搜索相关文档，返回文件列表和 Metadata ，约 50 tokens/文件
outline：查看文档的结构地图，约 200-500 tokens/文件
read：精准读取指定章节的原文，按需加载

这与人类阅读的方式完全一致：先找书，看目录，翻到对应章节精读。AI 在这个过程中有完整的上下文，知道自己在文档的什么位置，可以决定"再多看一点"，也可以跨文档对比。

对比传统 RAG：同样的场景下，Outline Index 方式的 Token 消耗约 800-3400 ，AI 拿到有完整上下文的精确信息。传统 RAG 返回 10 个预切碎片，消耗 4000-6000 tokens ，AI 对文档结构一无所知。

另一个副产品：Embedding 的对象从原文 Chunk 变成了 Outline Index 本身。一个文档只需要一个向量。10000 个文档 ≈ 10000 个向量 ≈ 30MB 存储，检索速度也快得多。

关于领域词汇不敏感的问题，BM25 全文检索补上了这块短板。双路检索（ BM25 精确匹配 + 向量语义理解），通过 RRF 融合，不再需要 Rerank 模型。

最后，是广告时间：

Outline Index 是 Linkly AI 的核心技术。如果你对具体的实现细节感兴趣，可以阅读这篇技术文章： Outlines Index：一种渐进式披露大量文档给 AI Agent 的方法。
如果你想体验实际效果，请下载 Linkly AI，以及 linkly-ai-cli，接入到某个 AI 客户端中体验，实测效果远好于 RAG 。

亚马逊因 AI 编码工具引发多起故障

Wed, 11 Mar 2026 08:03:54 CST

亚马逊因 AI 编码工具引发多起故障，紧急召开工程师大会

亚马逊电商部门本周二召集大批工程师开会，对近期一连串系统故障进行"深度复盘"——其中多起事故与 AI 编码工具直接相关。

据英国《金融时报》看到的内部备忘录，亚马逊近几个月出现了"事故趋势"，特征包括"高爆炸半径"（即波及面广）以及"生成式 AI 辅助的代码变更"。备忘录明确将"尚未建立完善最佳实践和安全防护的新型 GenAI 用法"列为事故的诱因之一。

具体来说，亚马逊网站和购物 App 本月曾宕机近 6 小时，用户无法完成交易、查看账户和价格。另外，AWS 旗下的 Kiro AI 编码工具在去年 12 月造成了一次长达 13 小时的服务中断——起因是工程师让 AI 工具执行某些变更，结果 AI 自行决定"删除并重建整个环境"。

作为应对，亚马逊已要求初级和中级工程师在提交任何 AI 辅助的代码变更前，必须获得资深工程师的签字批准。

值得注意的是，这些故障发生的背景是亚马逊近年来的多轮裁员——今年 1 月刚裁掉 1.6 万个企业岗位。此前已有多名工程师向《金融时报》反映，裁员导致每天需要紧急处理的高优先级事故（内部称"Sev2"）数量明显增加，但亚马逊否认裁员与故障频发有关。

这可能是整个行业的一个预警信号：当企业大规模推广 AI 编码工具、同时又在削减人手时，代码质量和系统稳定性的风险正在累积。

来源：www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de

纽约州考虑通过一项法案禁止AI聊天机器人提供法律和医疗建议

Thu, 05 Mar 2026 13:49:00 CST

一项正在纽约州立法机构审议的议案拟禁止人工智能聊天机器人向公众提供法律或医疗建议，并赋予用户起诉违规聊天机器人所有者的权利。该法案编号为S7263，由州参议院在上一立法会期间提出，上周在互联网与技术委员会以6票赞成、0票反对的表决结果获准出委员会，属于一揽子监管AI聊天机器人的立法方案之一。

法案重点针对那些假扮持证专业人士（如医生、律师）的AI聊天机器人，禁止其提供可能违反专业执照法律或构成“无证执业”的“实质性回应、信息或建议”。

法案要求聊天机器人的所有者必须向用户提供“清晰、显著且明确”的提示，告知用户其正在与一套AI系统互动，该提示需使用与聊天机器人相同的语言，并以可读的字体呈现。不过，法案同时强调，这一“非人类系统”的提示并不能免除聊天机器人所有者的法律责任。在这一框架下，如果运营方违反禁令，用户可依据法案赋予的民事诉权，将聊天机器人所有者告上法庭，索赔损失并请求支付律师费。一些专家认为，类似的私人诉权条款是数据和AI监管法律中重要的执行工具，缺乏这一机制往往会削弱法律威慑力，美国缅因州司法部长近期就曾在讨论数据隐私立法时称其具有“显著威慑效果”。

若该法案最终通过并由州长签署，将在生效后90天正式实施。 S7263所在的立法组合还包括多项针对AI与未成年人保护的措施，例如限制聊天机器人中对未成年人不安全功能的使用，以及规范某些被认为对未成年人隐私保护薄弱的在线平台（包括游戏平台Roblox）。组合立法中的其它项目则涉及要求生成式AI系统向用户提供使用说明性提示，以及对生物识别数据和“合成内容创作”的处理设立新规。

法案提出人、兼任州参议院互联网与技术委员会主席的克里斯滕·冈萨雷斯参议员表示，这揽子法案旨在确保AI创新“不会以纽约人的安全，尤其是儿童的安全为代价”。今年1月，免费生成式AI聊天应用Character.AI与Google就数起与未成年人自杀相关的诉讼达成和解，案件焦点正是这些聊天机器人在悲剧中扮演的角色，此类事件也推动了各州加快对聊天机器人的规制步伐。冈萨雷斯在一份新闻稿中指出，公众“理应获得来自真实人的真实关怀”，并享有透明度、问责机制以及在使用技术时其数据得到安全保护的承诺。

目前，这些纽约州层面的举措也置于更广泛的全美AI监管博弈背景之下，涉及州与联邦、隐私与创新、安全与开放之间的多重权衡。在此案之后，围绕聊天机器人能否提供专业建议、如何提示其“非人身份”、以及一旦造成伤害由谁负责等问题，预计将在美国各级立法与司法实践中持续发酵。

ARM Cortex X925 桌面性能赶上了 AMD 和英特尔

Tue, 03 Mar 2026 22:25:12 CST

英国公司 Arm 设计的芯片长期以来是为低功耗和小面积优化的，但它也一直推出针对高性能应用场景的核心。2012 年 Arm 发布 64 位核心 Cortex A57 时，能媲美 AMD 和英特尔最新处理器还是遥不可及的梦想。它在 2024 年推出的高性能核心 Cortex X925 已将梦想变成了现实。英伟达超级芯片 GB10 Superchip 使用的 Arm 核心就是基于 Cortex X925。它在桌面性能上赶上了 AMD Zen 5 和英特尔的 Lion Cove。GB10 使用了 10 个 X925 核心，分成两个集群，其中之一的 X925 核心最高频率 4 GHz，另一个是 3.9 GHz。测试显示它的重排序性能优于 AMD Zen 5，L2 缓存容量赶上了英特尔处理器的 P-Cores(即性能核心)。

IT社区推荐资讯 - ITIndex.net

gstack：YC总裁开源的”AI软件工厂”，68k Star的工具到底香不香？

一、gstack是什么？

二、数据情况

三、核心功能有哪些？

规划阶段

构建阶段

测试阶段

发布阶段

四、面向的人群有哪些？

五、应用场景有哪些？

六、和同类竞品的差异有哪些？

七、使用技巧

八、对企业和个人的价值

九、产品定价

十、项目地址

总体评价

一个AI开发工作流

一文了解 Anthropic 的 Claude Code 源码：为什么它就是比别人好用？

一堂北大散户生存教育课

欧洲国家快速拥抱绿色技术和电动汽车

微軟直接在 Copilot 使用條款裡面說 Copilot 是娛樂用途

Sora 为何失败：每天推理成本最高 1500 万美元总收入仅为 210 万美元

阿里巴巴发布优化运行国产大模型的 RISC-V 服务器芯片

电商版“龙虾”来了！阿里悟空发布，用AI帮商家7✖️24小时经营淘宝天猫店

AI造就 “默认为假”的时代 - 太隐

1、“默认为假”的时代

2、 传统好比人体免疫机制

3、可以入道

4、言语道断

5、王夫之谈史

6、毛泽东与《三垂冈》

7、王阳明没说过“父母即佛，心外无佛”

8、

9、洗脚注意事项

阿里巴巴论文：75%的模型会破坏掉之前本来跑得好好的代码

“Claude Code 这条路线错了”，元老级 AI 大师 Jeremy Howard 开炮：马斯克和 Dario 根本不懂现代软件工程-36氪

语言模型微调是怎么诞生的

Claude Code 的“创造力”，本质上还是插值组合

大模型反而让开发者变笨了？

氛围编程就像老虎机

“AI 写代码很厉害，但软件工程一塌糊涂”

最先进的 AI，却在用 40 年前的开发环境

Claude Code 正在背离“人机共创”的软件传统

AI 没大家说得那么吓人

研究称 AI 的生产力提升仅为每周 16 分钟

OpenClaw分享

被315点名的万亿隐秘生意：“污染”DeepSeek

大模型遭“投毒”？ 给AI“洗脑”已成产业链

为什么放弃了 RAG？ RAG 的六大难题

问题一：Embedding 模型两难

问题二：领域词汇不敏感

问题三：Rerank 的代价

问题四：碎片化的上下文

问题五：不同文档类型需要特殊处理

问题六：Agent 使用体验极差

行业也在转移

我们的解法：Outline Index

亚马逊因 AI 编码工具引发多起故障

纽约州考虑通过一项法案 禁止AI聊天机器人提供法律和医疗建议

ARM Cortex X925 桌面性能赶上了 AMD 和英特尔

2、传统好比人体免疫机制

大模型遭“投毒”？给AI“洗脑”已成产业链

纽约州考虑通过一项法案禁止AI聊天机器人提供法律和医疗建议