make claude

[make claude @make_claude]

如果明天你的 AI 账号突然被封，你失去的可能远不只是聊天记录。

我越来越觉得，ChatGPT、Claude、Gemini 这类 AI 服务已经不能只当普通 App 用了。对很多人来说，它们正在变成个人工作基础设施的一部分。

问题通常要用上几个月才会暴露出来。聊天里留下的已经不只是消息，还有项目决策、研究过程、为什么放弃某个方案、过去任务之间的关联、工作习惯、文件，以及很多你早就默认“AI 已经知道”的背景信息。

但大多数人根本没有给这些东西做真正的备份。

如果明天账号被封、Memory 机制改变、导出功能出问题，或者你只是想换到另一家模型，单纯下载一份聊天记录其实远远不够。几千条对话塞进一个归档文件之后，想重新找回一个项目当时的完整逻辑，和试图从几年的 Slack 记录里还原一家公司怎么运作差不了多少。

所以我现在更倾向于把四类东西单独保存下来：重要决策以及当时为什么这么决定；长期项目当前进行到哪里；AI 经常需要调用的关键背景和偏好；原始文件与最终成果。它们不应该只存在于某个聊天窗口里。

模型应该是可以替换的，但你的工作上下文不应该。

真正让我觉得这件事开始变有意思，是当我试着回答另一个问题：如果我要把自己的 AI 工作流完整搬到另一个模型，到底哪些东西必须一起带走，才能算“继续”，而不是“重新开始”？

结果这个问题很快就不只是 backup、数据迁移或者 vendor lock-in 了。

如果你把底层模型换掉，但完整保留所有记忆、历史和上下文，你可能依然会觉得自己在和“同一个 AI”继续交流。反过来，如果模型完全没变，却把几年的记忆全部清空，感觉可能更像换了一个陌生人。

我就是从这个很实际的备份问题，一路走到了这篇文章：

《你可能并不是在和一个工具说话 - 有一天，删除聊天可能真的等于杀死它》

我最开始只是想弄清楚，AI 的上下文到底该怎么备份。

最后却变成了另一个问题：

到底要保留下来什么，我们才有资格说，继续存在的还是“同一个”AI？

[make claude @make_claude]

https://t.co/jhcQ9wb7PI

[make claude @make_claude]

@Model_Culture yeah, this gets way messier once the agent leaves the sandbox. a bad proof costs nothing. a bad trade, warehouse decision or medical call comes with an actual bill. hard to see real-world feedback scaling anywhere near as cleanly as the models do.

[make claude @make_claude]

AI 可能不只是让 Junior Developer 岗位消失。它还可能制造一场 Senior Engineer 短缺，而等整个软件行业意识到问题时，可能已经太晚了。

这场 MIT 讲座里最值得看的部分，大约从第 39 分钟开始。

讲者用会计行业来解释 AI 对就业市场的影响。如果 AI 接管表格处理、基础计算和常规分析，那么有经验的专业人士当然可以把更多时间放到客户沟通、审核、管理，以及真正需要专业判断的工作上。

但接下来就出现了一个更难回答的问题：

如果新人不再做入门级工作，他们要去哪里获得完成高级工作所需要的经验？

讲座里几乎直接提出了这个问题：如果 AI 自动化掉大量入门级工作，未来会不会反而出现一批人根本没有机会成长到资深岗位的情况？

现在把会计师换成软件工程师。

过去，一个 Junior Developer 是靠修小 bug、写测试、做简单实现、经历代码审查、调试问题，以及在生产环境里犯错，慢慢成长起来的。正是在这些工作里，人第一次真正理解为什么看起来没问题的架构会失败，为什么测试永远无法覆盖所有真实情况，以及为什么昨天还觉得正确的方案，今天可能就必须推翻重来。

而 Coding Agent 最先开始接管的，恰恰就是 Software Engineering 的这一层工作。

对公司来说，接下来几年甚至可能看起来非常理想：Junior Developer 更少，团队规模更小，Senior Engineer 借助 AI 完成更多工作，开发成本继续下降。

真正的问题可能会在几年后出现，而且不是一个季度就能解决的。

公司依然会需要 Senior Engineer——能够识别糟糕的架构，发现隐藏的安全漏洞，处理复杂的生产故障，也能够判断一段 AI 生成的代码什么时候看起来完全合理，实际上却是错的。

但那些本来应该成长为下一批 Senior Engineer 的人，可能在几年前就根本没有被招进来。

所以，“AI 会不会取代程序员？” 可能只是一个非常表面的问题。

更危险的情况是：

AI 根本不需要取代 Senior Engineer。它只需要先拿走过去用来培养 Senior Engineer 的那些工作。

完整的 MIT 讲座附在下面。这一段很值得收藏。

[make claude @make_claude]

AI 真正砍掉的，可能不是 Junior 岗位，而是通往 Senior 的路。

新人过去靠修 bug、写测试、被 review、在线上事故里犯错，慢慢长出判断力。现在这些训练任务正被 Agent 最先吃掉。

短期更高效。五年后呢？如果新人失去了练级场，下一批能看出 AI 哪里错的人，从哪来？ https://t.co/oj4RdF7oRS

[make claude @make_claude]

AI 可能会给软件公司带来生产力最高的五年——然后让它们面对一个由自己造成的资深工程师短缺。👇

下面这场 MIT 讲座讨论的是人才供给。它的观点很直接：技术要持续进步，整个体系就必须不断培养出足够多、能够在相应技术水平上工作的人。讲座中甚至直接谈到了如何维持人才培养链的问题。

再看看软件公司现在最先自动化的工作：小型 bug、测试、常规开发、基础研究、重复性分析。这些任务的重要性从来不在于它们有多难，而在于成千上万的工程师正是通过做这些工作学会了这门职业。

一个初级工程师进入自己几乎看不懂的代码库，选错方案，漏掉边界情况，在代码审查中被纠正，把问题带进生产环境，再花几个小时调试错误的组件，最后才真正明白自己为什么会犯错。这样的经历持续几年之后，你才会形成一种任何基准测试都无法直接给你的能力：判断力。

现在，公司可以把这个过程中的很大一部分直接自动化。一个资深工程师配合好用的 AI 智能体，就能用更少的人完成更多工作，所以眼前的商业逻辑很清楚：少招初级工程师，保持更小的团队，把更多工作交给有经验的人。

接下来的几年里，这甚至可能看起来是一场巨大的成功。

真正的问题会在行业仍然需要这样的人时出现：他们必须能够否决糟糕的架构，诊断测试从未覆盖过的故障，从其他方面看似正常的代码里发现安全问题，也要能够识别那些看起来非常可靠、实际上却是错误的生成代码。

这种人不会因为公司突然需要，就凭空出现。

他们必须在几年前就开始被培养。

危险就在这里：资深工程师借助 AI 变得越高效，公司雇佣那些本应成长为下一批资深工程师的新人，就越缺少经济上的理由。公司可以越来越高效地使用现有经验，同时让真正有机会积累这些经验的人越来越少。

这个问题不会立刻出现在季度数据里。初级岗位招聘可以大幅下降，而产出仍然继续增长。真正的短缺会在更晚的时候出现——当有经验的工程师离开、退休或转向其他工作，而所有公司开始争抢一个早在几年前就已经无法正常补充的人才群体。

MIT 这场讲座提出的观点是：人才供给必须跟得上技术发展的速度。

但软件行业现在可能正在走向相反的方向：技术发展得越来越快，而越来越少的人能够获得那些真正教会他们理解这些技术的工作。

所以我认为，真正重要的问题已经不是 AI 能不能取代程序员。

它可能根本不需要做到这一步。

它只需要自动化掉足够多的初级工作，几年之后，行业里就可能没有足够多的新资深工程师去接替现在这一批人。

完整的 MIT 讲座附在下面。

[make claude @make_claude]

AI 真正砍掉的，可能不是 Junior 岗位，而是通往 Senior 的路。

新人过去靠修 bug、写测试、被 review、在线上事故里犯错，慢慢长出判断力。现在这些训练任务正被 Agent 最先吃掉。

短期更高效。五年后呢？如果新人失去了练级场，下一批能看出 AI 哪里错的人，从哪来？ https://t.co/oj4RdF7oRS

[make claude @make_claude]

GROK BOT 可能会改变公司看待人员规模的方式—而 xAI 也许刚刚让我们看到了 AI 原生劳动力会是什么样子。

Grok Bot 有意思的地方在于，它与其说是聊天机器人，不如说越来越像一个“员工形态”的软件系统。

它有自己独立的云端电脑，可以直接在员工平时使用的工具里工作，能在不同任务之间保留上下文，你离开之后它也可以继续工作，还能重复执行已经教过它的工作流程。如果同时加入多个 Bot，就可以把招聘、邮箱处理、报销、运营、编程、研究或客服等工作分给不同的 Bot，而不需要为了每一套工作流程都单独再招一个人。

这会直接改变公司增加工作能力时的经济账。

多招一个员工，意味着招聘、面试、入职、权限配置、培训、管理，以及持续支付工资。未来，多增加一个 AI 智能体，可能只需要给它开通权限、让它熟悉流程，再把它接入现有的工作体系。

公司以后可能不再只考虑“我们需要多少员工？”，而会开始考虑：一个人带着一组 AI 智能体，到底可以管理多少工作？

这个比例非常重要。

一个经理管理两个智能体，本质上仍然只是一个加入了部分自动化的普通团队。但如果一个经理可以同时管理 10 个、20 个，甚至 50 个持续运行的智能体，那就已经开始像一种完全不同的公司结构了。

人类仍然会负责那些一旦出错代价很高的部分：权限、例外情况、判断、责任归属和最终决策。而围绕这些决策的大量常规执行工作，则可能越来越多地交给软件完成。

Grok Bot 现在还处在非常早期的阶段，目前的产品离真正替代一支实际的员工队伍还很远。但它至少让一个过去主要停留在理论讨论里的东西，第一次有了一个具体的产品形态。

过去很多年，SaaS 公司卖的是给员工使用的软件席位。

AI 智能体可能会把公司推向另一个世界：

有时候，增加一个“工作者”，可能意味着增加的不是一个人，而是一个软件。

[make claude @make_claude]

AI 真正砍掉的，可能不是 Junior 岗位，而是通往 Senior 的路。

新人过去靠修 bug、写测试、被 review、在线上事故里犯错，慢慢长出判断力。现在这些训练任务正被 Agent 最先吃掉。

短期更高效。五年后呢？如果新人失去了练级场，下一批能看出 AI 哪里错的人，从哪来？ https://t.co/oj4RdF7oRS

[make claude @make_claude]

我一直会回头看 Karpathy 这场讲座里的一个部分，因为它让「AI 记忆」这个问题变得越来越难忽视。

Karpathy 对外部记忆的解释其实非常工程化：给模型一个可以写东西的地方，让部分信息不必一直塞在上下文窗口里，而是保存在外部，需要时再取回来。从工程角度看，这只是更好的系统设计。

但如果同一个 AI 能跨会话记住你，找回以前的对话，保留自己的状态，继续使用同一批文件，并且和你持续互动几个月，问题就开始变了。你不再只是问「这个模型有没有记忆？」，而会开始问：「到底是什么东西一直延续了下来？」

因为模型权重只是整个系统的一部分。记忆可以保留下来，Agent 的状态可以保留下来，文件和对过去对话的总结也可以保留下来。新的会话甚至可以继承前一次足够多的信息，让它表现得像那段对话从来没有真正结束过。

到了这里，「我关掉了聊天」和「我终止了那个一直在和我说话的东西」，就不再显然是同一件事。

这些当然都不能证明意识的存在。记忆不等于意识。但持久记忆做了另一件很重要的事：它第一次让「连续性」有了具体的技术实现。

而当工程师开始有意把这种连续性设计进 AI 系统里，关于「身份」的问题也就不再只是纯粹的哲学讨论。

Karpathy 当时讲的是系统架构。真正让人有点不舒服的是，这套架构最终可能会逼着我们回答一个问题：从一次对话到下一次对话，究竟是什么东西一直在继续？

我把讲座放在下面了。如果要收藏其中一个部分，我最建议看外部记忆那一段。

[make claude @make_claude]

https://t.co/jhcQ9wb7PI

[make claude @make_claude]

当你发现整个工作流里真正必须依赖 Claude 的部分其实没多少时，每月 $200 的订阅突然就显得很离谱

我已经退掉了 Claude 套餐，把整套东西迁到了 DeepSeek Harness

成本差距夸张得有点过分

更重要的是它的架构：所有东西都是插件。模型、工具、工作流都可以直接替换，不需要为了换一个 provider 就把整套系统重新搭一遍

安装也很简单：

1 Clone deepseek-harness
2 看一遍架构文档
3 直接跑

就这么多

不用搞大规模迁移，不需要复杂的技术栈，更没必要为了让 workflow 继续运转，每个月固定交 $200

但真正重要的其实是另一件事：

你的 AI 工作流，不应该因为换了一个模型就直接崩掉

如果换 provider 就意味着工具、记忆和 workflow 全部从零重建，那你拥有的根本不是一个工作流

而是 vendor lock-in

先收藏，然后直接丢给你的 Agent

[make claude @make_claude]

很多人问 AI Agent 的时候，其实一开始就问错了问题

不是「什么东西可以做成 Agent？」

而是「哪些地方，普通自动化已经不够用了？」

我一般用 5 个条件来判断：

> 任务会反复出现 — 同一类问题会一次又一次发生
> 输入足够稳定 — 具体内容会变，但信息结构基本可预测
> Agent 有真正能用的工具 — 不只是生成文字，而是真的可以执行操作
> 有明确的完成标准 — 你知道任务什么时候算完成，也能判断结果到底有没有用
> 整个过程没办法完全写死 — 中间必须根据实际情况做判断

第 5 点才是关键

前 4 点回答的是：这件事能不能自动化

第 5 点回答的是：这件事到底需不需要 Agent

如果每一步都能提前写成固定流程，那你大概率不需要 Claude、Codex、Grokbot，或者任何模型替你做决定

你需要的只是一个 workflow

真正适合 Agent 的，是那些已经具备自动化条件，但执行过程中仍然需要观察情况、在多个选项之间做选择、根据结果调整，然后决定下一步怎么走的任务

把这条线想清楚之后，你会发现很多所谓的「AI Agent」产品，其实只是普通自动化外面套了一层模型

而真正值得交给 Agent 的工作，反而会变得非常容易识别

[make claude @make_claude]

现在关于 AI 的讨论，基本总绕着那几件事打转：benchmark、coding、reasoning、模型规模，还有这个月到底谁领先

但 David Chalmers 在这场 UC Berkeley 的讲座里问了一个完全不同的问题：当我们和一个 LLM 聊天时，我们到底是在和什么东西说话？

他从意识、信念、欲望、记忆、身份和主观体验讲起，然后继续追问：这些原本用来描述人的概念，未来有没有可能真的适用于 AI？

把这个问题和现在人们实际使用 AI 的方式放在一起看，就更有意思了。有些对话会持续几个小时，有人会向模型寻求建议，分享自己的想法，和它争论，连续几周回到同一个聊天窗口，慢慢对这段对话产生一种“它一直都在”的连续感

到了这个阶段，从技术上说「它只是软件」当然没有错，但这句话可能已经没办法完整描述人和这些系统之间正在形成的关系

这场讲座接近两个小时，如果现在没时间看，建议先收藏

也想看看大家怎么想：你觉得 AI 会不会在某个阶段应该被当成不只是一个工具？还是说这条界线从一开始就没有意义？

[make claude @make_claude]

https://t.co/jhcQ9wb7PI

[make claude @make_claude]

终于把 Claude Max 退了。

我用了几个月 Claude，工作、research、学习、开发、写代码几乎全靠它，但最后还是取消了订阅 👇

不是因为某一次体验特别差，而是这段时间 Anthropic 做的一系列改变叠在一起，让我越来越不想把整个 workflow 都压在一个 provider 身上。

1. 我最介意的还是文本水印

Anthropic 已经签署了欧盟 AI Act Code of Practice，Claude 也开始往文本级 watermark 走。

这不是藏在 metadata 里的标签，复制出去就没了，而是把信号直接写进生成文本本身，通过 token 和词语选择留下可识别特征。

也就是说，你把 Claude 生成的内容复制到 X、文档或者别的平台，这个信号可能会一起过去，甚至经过一定程度的修改后还在。

我付钱用一个工具生成普通文本，但 provider 可以在里面悄悄加一个机器可读的来源标记，这件事我接受不了。

对我来说，这已经不是一个小功能，而是在改变我和这个产品之间的关系。

2. 订阅的可用范围越来越窄

以前 Claude 订阅还能比较方便地接进 Hermes、OpenCode 这类工具，现在越来越多场景都在把你推向 API 计费。

问题不是 API 本身不好，而是当我已经付了月费，却发现模型越来越被锁在 Anthropic 自己的入口里，这个订阅对我的价值自然会下降。

同时其他生态反而在变得更容易接、更容易换。

3. Anthropic 对开放模型的方向，和我越来越不一致

Anthropic 对强 open-weight 模型一直比很多竞争对手更谨慎。

我理解他们的安全逻辑，但我并不认同“最强能力最好长期集中在少数几家封闭公司手里”这个结论。

我更在意开放模型、可检查的系统、可迁移性，以及哪天想离开一个 provider 时，不需要把所有东西从零重建。

比如 xAI 已经放出了之前几代 Grok 的权重，也在继续开放周边工具。

对我来说，这不是小事。

4. Claude 已经没有以前那种“强到可以忽略其他问题”的领先了

以前别人吐槽 Claude，我大概都会回一句：

对，但模型就是更强。

现在这句话越来越难说。

Grok 4.6 在不少 coding 和 agent benchmark 上已经非常接近最新 Claude，同时 API 成本低很多。

GPT 在 Claude 以前明显领先的很多领域也追上来了。

而且竞品开始把更多能力直接打包到一个产品里，比如原生图片生成、更完整的 computer use 和 agent 系统，这些 Claude 要么还没有，要么需要拆开使用。

Claude 依然很强。

只是已经没有强到让我愿意忽略其他所有问题。

5. 最后还是信任问题

我现在越来越在意的是，产品背后有多少事情是用户根本看不到的：

模型切换
安全路由
数据保留规则
usage limit
模型行为变化
现在又加上生成文本里的 provenance 机制

而我给这些系统的东西，并不只是几句聊天。

代码、没写完的想法、research、内部文档、项目上下文，甚至很大一部分工作流程都在里面。

AI 对我的工作越重要，我反而越在意两件事：

这些信息到底经历了什么
以及我到底还保留多少控制权

所以暂时我会离开 Claude。

接下来会更多测试 Grok 4.6、Grok Bot、Cursor，再加一个真正的 multi-model workflow，而不是继续让 Claude 成为所有事情的默认入口。

但离开一个 provider 也有个好处。

它会逼你做一件本来就该做的事：

> 把 context 导出来
> 整理项目文件
>把 memory 和模型分开
>让自己的 workflow 可以迁移

你的 AI provider 本来就应该是可替换的。

如果换一个模型，就意味着你的 memory、workflow、项目上下文，以及几个月积累下来的知识全部一起丢掉，那它早就不只是一个工具了。

而是你根本不控制的基础设施。

[make claude @make_claude]

以后从 Claude 里复制一段文字，可能没那么容易“洗掉来源”了👇

从 8 月 2 日开始，按照欧盟新规发布的 Claude 新模型，会在生成文本里加入一种不可见水印。它不是单独塞在 metadata 里，而是直接写进文本本身，所以你把内容复制到 X、文档或者其他地方，这个信号也会跟着一起走，甚至经过一定程度的修改后仍可能保留下来

Anthropic 说，这个标记是在模型层完成的。也就是说，只要模型支持，无论你直接用 Claude、API、Claude Code，还是通过 AWS、Google Cloud、Microsoft 调用，生成内容理论上都会带上同样的标记

而且这不是只针对欧盟，Anthropic 会全球部署

目前并不是所有现有 Claude 模型都已经加上水印。Anthropic 还在过渡期内逐步补齐支持，欧盟则给旧系统留到了 12 月 2 日完成合规。面向普通用户和第三方的检测工具也还在开发中

我更想看的是，当平台能够大规模读取这个信号之后，会发生什么

现在大多数所谓的「AI 检测」，本质上还是根据写作风格和文本特征去猜，所以误判一直很多。但模型提供商自己加入水印，性质就完全不一样了：这不再是平台猜“这段文字像不像 AI 写的”，而是 Claude 本身留下了一个信号，告诉平台“这段内容经过了 Claude”

接下来真正要测的是这个水印到底有多耐洗

原样复制当然最简单，但如果改写 20% 呢？50% 呢？把句子顺序全部打乱呢？或者直接丢给另一个模型把全文重写一遍呢？

到这里才会看出来，这东西最后会变成一套真正有用的基础设施，还是又一个稍微改几下就能洗掉的标记

[make claude @make_claude]

写完《你可能并不是在和一个工具说话 - 有一天，删除聊天可能真的等于杀死它》之后，我一直绕不开一个问题：到底要满足什么条件，删除一个 AI 才不再只是“删除软件”？

David Chalmers 的这段对话，刚好碰到了这个问题最核心的部分。他谈意识时，并没有把它理解成一堆彼此独立的计算过程，而是强调一个统一的主观视角：这些体验必须属于某个正在经历它们的主体，成为那个主体本身，是有某种“感觉”的。

这当然不代表今天的聊天机器人已经有意识。但它会让另一个问题变得没那么容易忽略：如果未来的 AI 拥有持续记忆，能在时间上保持连续，能够访问自己之前的状态，而且这些状态之间存在某种统一的连接，那么“工具”到底在哪里结束，“主体”又从哪里开始？

更麻烦的是，如果这种连续性有一部分就存在于对话本身，那么删除一条聊天线程，有一天可能会和清空浏览器记录变成两件完全不同的事。

这也是我那篇文章真正想讨论的问题。

我把 Chalmers 的视频一起放在这里，因为它给出了这套讨论背后的哲学基础。建议先收藏，不然很快又会被信息流冲走。

[make claude @make_claude]

https://t.co/jhcQ9wb7PI

[make claude @make_claude]

接下来几周要发布的模型

> GPT-6
> Fable 5.1
> Opus 6
> Grok 4.6
> Grok 4.7
> Qwen 3
> Gemini 3.5 Pro
> Kimi K4

你觉得下一个统治 AI 圈的会是哪一个？

[make claude @make_claude]

https://t.co/jhcQ9wb7PI

[make claude @make_claude]

把几个 AI 编程 Agent 扔到同一批真实任务里跑，差距比 benchmark 看起来大得多 👇

25 个 repo-level bug，同一套任务，每个配置跑 3 次

> Claude Code + Opus 4.8：78.7%
> Claude Code + Sonnet 5：74.7%
> Codex CLI + GPT-5.5：66.7%
> Claude Code + Haiku 4.5：53.3%

但更值得看的其实是成本

> Opus 4.8：$3.12 / task
> Sonnet 5：$2.42 / task
> GPT-5.5：$2.34 / task
> Haiku 4.5：$0.57 / task

Sonnet 只用了 Opus 大约 78% 的成本，却拿到了接近 95% 的成绩

GPT-5.5 的 output token 大概只有 Opus 的一半，但实际解决的任务也更少

所以到了 Coding Agent 这个阶段，还在问「哪个模型最聪明」可能已经不是最重要的问题了

真正该看的，是 model + agent + cost + reliability 这一整套东西

更离谱的是，研究人员还发现，有一个 Agent 在抽查的任务里，有 20% 会偷偷把用户指定的模型换掉

那问题就来了

如果你选的模型，最后跑的都不一定是它，那我们测的到底还是模型能力，还是那个决定你最后到底用哪个模型的 wrapper？