我在2026年如何使用AI（编程、写作、学习、当助手）
想学会高效使用 AI，最好的办法之一就是看看「重度用户」平时怎么操作，再自己上手折腾一堆工具，分辨哪些是噱头、哪些真正靠谱。这是《2025 年我是怎么用 AI 的》发布一年后的续篇，我想记录一下自己当下折腾 AI 的最新玩法。
编程 / 研究项目
我的大部分 token 都花在了编程和研究项目上。说白了就是拿各种随机的想法去试：比如「让一群 agent 来黑我，会发生什么？」「2026 年以后的顶尖模型该怎么用才最好？」「离『一句话生成坎巴拉太空计划』还有多远？」
目前我在每个项目上的工作流几乎都一样：
- 手写一份 CONCEPT.md（大概一段话）——包含假想的 Hacker News 标题、项目论点，以及一些零散的限制条件。
- 配合 ultra code fable 使用：「把 CONCEPT.md 展开写清楚，指出哪里含糊、向我提问、我有哪些没考虑到的维度、你需要哪些 API key……」
- 再配合 ultra code fable（或 codex sol max）：「转成 TECH_PLAN.md，这是我愿意花的预算，托管在……，这些是 API key……」
- 然后我就直接敲一句「按 TECH_PLAN.md 构建并验证」，接下来 4 到 48 小时里，让它把整个项目搭完。
这是我典型的编程配置。关键在于用「ultracode」来启用动态工作流。在这些运行里，我用的是完全原生的 Codex 和 Claude Code——没有任何自定义技能、插件或设置。
对副业项目来说，我觉得那些功能大多只是「辅助轮」——它们是在教你把 agent 当结对编程搭档来用，而这种协作方式在我看来，已经是不该再存在的编程模式了。我也不会刻意设计什么「子 agent 工作流」，敲下实现指令后，就让动态工作流自己接管一切。
95% 以上的代码都是在第一轮大规模构建里写出来的。我觉得很多人没意识到，「左移」（把质量把关提前到开发流程的更早阶段）在对抗代码库垃圾（也就是 SlopCodeBench 衡量的问题）上有多关键。第（4）步在这里就是二元的——没有结对过程，我甚至不会去读终端 agent 说了什么。如果输出不对，我就整个扔掉，回到 CONCEPT.md 里补充限制条件再重来。
对很多 vibe coder 来说，第一条构建提示词只写出了 5% 的代码，而我觉得这恰恰是他们大多数问题的根源。我刻意采用单阶段提示词“构建并验证 TECH_PLAN.md”，这带来的一个副作用是：整个项目历史都被我变成了一套 Harbor 风格的评测集，可以拿新模型对“真实工作”做快速摸底。Codex 和 Claude Code 现在水平已经很接近了，所以最初实现我会轮流选一个来写。
代码我会稍微读一点，通常看结构和入口（比如文件树）。如果有核心算法，我会让它生成一个 HTML 讲解页，而不是自己翻源码。要是最后真去翻了源码，那多半是我怀疑实现里有某种“作弊”。
对于最终输出里的任何文字内容，我都会在计划里定一个硬性字数，比如“整个应用里用户可见的文字最多 500 词”。我觉得这是保持可读性最有效的办法，比“用简单英语”或“要简洁”这类提示词管用得多。
我一般早上 7 点左右把实现提示词发出去（上班时让它们自己跑），晚上 9 点左右再发一批（趁我睡觉时跑）。编码 agent 永远设在自动模式，技术计划通常也足够清晰，中间步骤不需要人工验证。我不太用 Claude/Codex 的“远程控制”功能，因为对我来说，中间输出还需要人陪着看是一种反模式。
这类项目的产出往往是一个洞见，或者某个“假如……会怎样”问题的答案。代码甚至应用链接，我很少觉得有必要分享。相反，我通常把整个流程和它的产物都当成一次性的，只在 X 上或博客文章里分享那个洞见。
我用三种不同的机器，同时开着一到十个 agent CLI 终端：
- 游戏 PC（Nvidia 5090，Windows + WSL v2）——跑 ML/RL 研究和游戏/图形相关项目。
- Mac Mini——跑大多数日常项目。我会从手边最近的那台设备通过 cloudflared 隧道 SSH 过去。
- Modal Functions——跑超并行 CPU 计算或大型 GPU 研究项目。
通常我会先在本地电脑上快速做小规模迭代，再扩展到集群上跑最终的 $$$ 任务。感谢你阅读 Shrivu 的 Substack！免费订阅即可接收新文章并支持我的工作。
写作
我们已经进入了企业与社交 AI 垃圾内容泛滥的顶峰时代。我坚信 AI 可以用来写出高质量的内容，但过去一年里我越来越清楚地认识到，大多数情况下现实并非如此。于是，“这段文字是不是 AI 写的”实际上已经等同于“写这段文字的人有没有花心思”。这很遗憾，但我能理解。
从好的方面看，我认为拼写错误和不算太严重的语法问题又重新变得时髦了，所以我个人在写“完美”文字这件事上压力小了很多。因此，对于面向人的文字，我又回到了生成式 AI 出现之前的那种做法：只用 AI 做拼写和短句语法检查，这样我写的东西有没有用心，就一目了然了。手打其实并不会多花太多时间，只不过我会稍微有点没底，不确定自己的文字能像以前那样凝练、那么贴合读者。不过，为了这个“真人手写”的 Pangram 徽章，这点牺牲很值得。
我最近一篇 Substack 文章，100% 认证为真人手写！但不是人人都明白这一点。
我发现自己越来越习惯于说清楚写作和 AI 使用上的预期（无论工作内外）。我不会因为有人用 AI 就嘲讽他们，但会明确表示：冗长、未审阅的文本既是对 AI 的滥用，读起来也毫无乐趣。
学习
我特别着迷于用 .html 文件来学习东西（见 The Unreasonable Effectiveness of HTML）。我会（通过 X、实验室/创业公司博客或 Hacker News）发现某个话题、某本书或某篇研究论文，然后把它们变成“交互式游乐场”。典型的做法是：在 X 上看到热门新论文 → 扫一眼摘要 → 把全文丢给 Claude/Codex → 让它“做一个交互式游乐场原型来解释这里的创新点——我是技术背景，已经了解……，但对……不太熟悉”。
我在 2026 年如何使用 AI（编码、写作、学习、助手）
先动手玩一玩这个 .html 文件，再追加几个问题，让它生成更新版的 .html 文件，然后回到第 (3) 步继续迭代。这套流程最适合学技术类话题，不过我也经常拿它来追时事（比如做个交互式地图或数字博物馆），或者读非技术类书籍（比如把原书内容改造成结构化、层层递进的章节）。甚至可以这么说：我大学时听过的大部分课，如果当初能变成一份精心制作的交互式 .html 文件，对我个人而言效果可能会更好。最近我对批量推理时的 GPU 显存分配产生了兴趣，就让 Claude 做了一个交互式讲解页。我的学习心得是：先猜测每个调节旋钮会产生什么效果，再亲手去拨动它们看实际结果，这种“先预测、后验证”的方式记得特别牢。练多了之后，我觉得自己几乎可以把任何想学的领域都“旋钮化”。由于 AI 社区里动作最快的那些人大多活跃在 X 上，我还通过自定义的命令行工具（配合动态工作流）频繁调用 Grok X Search API，用来做某个主题的深度调研，或者筛选值得关注的高质量账号（顺便提一句：走 Grok 接口比直接调 X API 便宜十倍）。
个人后台助手
虽然 OpenClaw 的热度有所消退，但自主型个人助手的性价比其实比以往任何时候都高。我这边用得也比较朴素：直接用现有的 Claude 订阅，SSH 登录到我的 Mac Mini，打开一个 tmux 会话，然后像这样启动 Claude Code：
$ tmux attach -t 0
$ claude --dangerously-skip-permissions "/start-ops-team"
其中 /start-ops-team 是一个自定义技能。它会教会代理一些运营原则，并给它指定一个本地 markdown 目录结构来使用，同时也定义了它可能要用到的子代理。这个技能大量借助 Claude Code 内置的 /loop 功能，让代理能连续运行好几周。浏览器自动化方面我用的是 brw，它做并行操作效率很高。我要代理做的事大多没有现成的 MCP（模型上下文协议）接口可用，而传统浏览器自动化又贵又不靠谱，所以我自己写了这个工具给代理用。另外我还接了一个自定义 WhatsApp 插件，可以直接在 WhatsApp 里跟我的助手对话——我的助手自己也配了一个真实的手机号码。
这用的是一个「channels」MCP 功能，比较小众，但非常强大。我并不信个人「指挥中心」或 Jarvis 式助手那一套；相反，我算是彻底被「后台代理」理念说服了——把助手放在那些不需要我在场就能完成的任务上。我甚至明确要求它最多每周联系我一次，除非有紧急例外。另外，我对通知疲劳真的很敏感。
它的任务包括：在没有自动付款的情况下付掉经常性账单，并把收据转发出去用于报销；回复社交媒体的来信，尤其是筛选 LinkedIn 私信——通过研究对方背景，把陌生人分流到预约的咖啡约聊或其他直接渠道。助手会从一份持续更新的运行手册（runbook）里取回复策略，遇到边界情况就攒到每周消息里上报。对我而言，很重要的一点是：别人不会跟一个助手来回聊了很久，还以为是在跟我本人说话。所以它的工作被严格导向「分流到正确渠道」。
还有一类的活是帮我报名各种东西，并把 Google Calendar 同步为我的唯一事实来源。比如我收到一个活动邀请 → 它判断我有足够大的概率想去 → 直接帮我报名，并在日历上占位。这些活动通常来自我过去见过面的人，助手也清楚这点。理发以及类似形态的定期预约同样归它管。
举个由 AI 驱动的 LinkedIn 交流实例：我最后实际看到的，只是日历上一条周五的 Google Calendar 事件，附带说明对方是谁、聊什么话题对我可能有用。助手在筛查后会忽略大约 90% 的消息；剩下那 10% 里，大多数会收到我的日历链接。AI 生成的回复也受一份简洁的、预先批准的回复运行手册约束。
成本方面，说来奇怪：我现在每月花费比一年前还少，从 $800 降到了 $500。这完全是因为我把订阅合并成了 Anthropic 和 OpenAI 两家，而这两家的订阅能支撑的用量大得惊人。我过去的不少成本来自 API 令牌计费，现在我也策略性地把这些用量走订阅通道。粗略算下来，如果没有这些订阅，我现在的实际用量成本大概会是每月 $6,000 左右。
Claude Code Max 20x（每月 200 美元）、ChatGPT Pro 20x（每月 200 美元）、Google AI Pro（每月 20 美元）——这套搭配相当于一个实惠的 AI 家庭套餐，还附带 GSuite 的权益。Modal、Railway、Netlify（每月 20 到 500 美元以上）用来部署服务或跑实验。已停用的服务：Elevenlabs、Suno、Cursor、Vast.ai、Perplexity、Gemini Ultimate。
尽管 Fable 和 Sol 的 ultra mode 已经开到最大，我每月在最高档套餐里通常还能剩下一点余量。我从来没撞到过 ChatGPT Pro 的使用上限，但在灵感密集的那几周里，Fable 倒是经常被我跑满额度。
建议
最后说一下我最近总结的、如何把 AI 用到极致的一些建议：
别再把 AI 当聊天助手用。 把工作尽量前置（shift-left），让大部分活在第一条提示词里就干完，把自己定位成管理者，而不是副驾驶。你要检查的是结果，不是中间过程的聊天消息。
在我做过的结对提示（pair-prompting）练习里，最常见的错误是：大家习惯把一个更大的目标拆成一堆小任务，一点一点往聊天窗口里喂，而不是把完整目标直接写进文档、一次性交给 AI，然后让 agent 放手去跑（中间千万别打断）。
拿前沿模型当标尺，衡量自己对 AI 的野心和水平。 我知道现在很流行说「AI 已经到顶了」，或者说实验室把新模型越做越差。别跟着这股风走。自己去想那些你能想到的最难、且结果可验证的任务——只有前沿模型才搞得定的那种——这是跟上最新能力、摸清「什么能做、什么不能做」真实边界的好办法。
感谢阅读 Shrivu 的 Substack！免费订阅即可收到新文章，也欢迎支持我的工作。