【开源推广】作为一名在读博士生,我在日常是如何与 AI 协作的?——ai-collab-playbook(26.6.8版)

作为一名在读博士生,我在日常是如何与 AI 协作的?——ai-collab-playbook > 公开版本 / Public edition: 2026-06-08 cnfjlhj/ai-collab-playbook github版本~ -— 前言 我是一名人工智能方向的在读博士生,大概在 Cha...
【开源推广】作为一名在读博士生,我在日常是如何与 AI 协作的?——ai-collab-playbook(26.6.8版)
开源推广作为一名在读博士生,我在日常是如何与 AI 协作的?——ai-collab-playbook(26.6.8版)

作为一名在读博士生,我在日常是如何与 AI 协作的?——ai-collab-playbook

> 公开版本 / Public edition: 2026-06-08

cnfjlhj/ai-collab-playbook github版本~

-—

前言

我是一名人工智能方向的在读博士生,大概在 ChatGPT 出来以后还是 GPT-3.5 的时候就比较重度使用 AI 以及 AI 工具了。几年下来,AI 已经渗透到我工作和学习很多环节,有一些心得想分享一下~

当同事,不当工具(我认为至少未来几年,应该是人机协作的时代)

现在回头看,我觉得过去很多所谓“会用电脑”,其实有相当一部分是在给机器当翻译。人脑子里明明只有一个目标,落到电脑上,却总要拆成一堆很零碎的动作。很多时候事情本身并没有多么复杂,感觉复杂是因为旧系统根本听不懂你的意图,只能逼着你先把目标嚼碎,再翻译成它能执行的步骤。

比如做 SQL 查询,你脑子里明明只是想看一个简单的业务趋势,但因为系统听不懂,你不得不花一个小时去嵌套三层 LEFT JOIN、对齐 GROUP BY 的聚合字段,小心翼翼地用机器听得懂的语法去和数据库交互。

这也是为什么我现在越来越自然地把 AI 当同事,而不只是当工具。

image

> 本文的主线很简单:AI 入口要贴近任务,Agent 流程要能被复盘,人仍然掌握问题表述与验收标准。

贯穿全文的几个方法论

- 元提示词思维:让 AI 写操纵 AI 的 Prompt,人做微调

- 苏格拉底追问:让 AI 从多角度逼问自己,把模糊的想法变清晰

- 多模型协作:不同任务用不同模型,也可以让不同模型协作完成复杂任务(后文会在各个场景展开)

- 经验沉淀:把流程固化为 `Skill`(Code Agent 中的术语),越用越好,越用越快

-—

一、日常使用:AI 作为随身顾问

image

### 让 AI 入口离任务更近

我最近很久没有认真使用网页端 ChatGPT 了,重新打开以后发现,各家模型的网页端和应用端其实都变化挺大。在 API/token 变得紧张以后,我反而重新意识到:并不是所有任务都值得拉起本地 Agent、走 API、配一套完整工作流。很多轻量、一次性的小活,比如临时总结、改写、问一个不需要项目上下文的问题,直接交给网页端 ChatGPT 的 Agent 模式就够了。它不一定是最“工程化”的方案,但对这类任务来说,入口短、成本低、上下文负担小,反而是更合适的选择。

应用侧也是类似的逻辑。我现在还会用 `豆包` 的划词工具栏功能,它能在电脑全局划词唤醒。最方便的是可以自定义划词动作,比如我写了一个“概念解释器”,划词后直接给出学术概念的通俗解释,省掉了打开浏览器、复制、粘贴、重新描述问题这一整串动作。

image

另外,`豆包浏览器` 的网页翻译、页面总结、针对当前网页提问这些功能也挺实用。它的价值不一定在于模型能力一定最强,而在于它离当前网页足够近:我不用把内容搬到另一个窗口,也不用重新组织上下文,直接在当前页面处理就行。

所以我现在会更刻意地按任务重量选择 AI 入口:轻量任务交给网页端或应用端,项目级任务再交给本地 Agent。日常使用 AI 时,最重要的不是把每件事都接入最强模型,而是尽量降低使用 AI 的摩擦力。入口越贴近工作流,越容易形成高频使用;用得越自然,AI 的价值才越容易被挖出来。(大家如果有更好用的应用侧工具,也可以留言推荐~)

通过 IM 软件远程调用 Agent

可以通过类似 `cc-connect`、`happy` 这样的应用远程调用现有的本地 Coding Agent(Claude Code、Codex),也可以直接使用类似 `OpenClaw`、`Hermes`、`cowork` 的成品。

我认为 IM 是最低摩擦的派活入口,可以随时把任务抛出去;远端机器是 Agent 的工作台,它可以下载、转写、分析、跑代码、生成 PDF、发回结果。

但最吸引我的还是可持续培养性:让 Agent 记得你的偏好、知道你的项目结构、沉淀 `skill/workflow`,逐渐变成“熟悉我的同事”。

最近我主要是拿他们当咨询类的推送助手,以及提醒我吃饭、睡觉、写日记之类的 chatbot。我会给它我的日记访问权限,让它每天去读我近期的日记,以及往年当天的日记,用来督促我继续写日记。和我一起聊我的零散碎碎念,帮我整理我的知识wiki…

4940c82f-0fed-442f-a742-d724f020a979

-—

二、科研

image

这里给大家安利一下我现在比较稳定的一条科研工作流:调研 → 筛选 → 精读 → 整合,核心目标不是让 AI 替我读完,而是让它帮我把文献网络、论文细节和个人理解接起来。

科研文献阅读

我把文献阅读分成四个阶段:调研→筛选→精读→整合。

阶段一:课题调研

我主要用 OpenAI 的 Deep Research 以及 GPT-Pro 做课题调研和可行性分析。我会要求 AI 不仅提供最新文献,还必须包含该领域的开山之作,之后再让 Agent 按照个人偏好去构建 `wiki`。

阶段二:文献网络分析(Literature Network Analysis)

找到几篇感兴趣的论文以后(也就是先找到锚点论文),借助 Paper Connect 等工具,可视化文献间的引用关系,快速判断研究热度与技术脉络。(这些数据也应该同步导出给 Agent)

image

与 Agent 沟通调研结果,搞清楚这些文献之间的逻辑关系,最终自动下载感兴趣的相关论文以供后续引用或精读。

> 如果某篇论文的引用网络图非常庞大,说明这个方向已经很"卷"了。反之,可能还是蓝海。

阶段三:确定精读 → 逐篇攻克

下载论文到相关文件夹以后,我会先和 Agent 讨论一下当下研究已经推进到了什么地步,再确定阅读顺序,去除无关或暂时不感兴趣的论文。整个过程要逐步扩充整理 `wiki`。

精读环节,我会用两个模型配合:

- Gemini 负责宏观视角:从动机 → 数学建模 → 实验 → 结论 → 评述五个角度分析一篇论文,生成 HTML 文件(这个格式也方便写周报,比较美观,可以截图放进去)。最近我发现我的gemini变傻到极致,突然这个任务也做不好了。如果大家用gemini也有这样的感觉的话,我觉得可以在粗读的时候看alpharxiv的blog模式。

image

image

- GPT 负责更细致的补充:在 Gemini 打好的 HTML 基础上继续修改和补充细节,亦或者直接让 GPT 根据模板生成 HTML 文件,同时对照原文分屏快速阅读。具体样子可以参考我的博客:[FormalEvolve Cheat-Sheet](FormalEvolve 论文精读)。

image

> 这个流程对应的 `paper2html` Skill 我也放进了这个仓库的公开 skill 包里,适合把论文 PDF / arXiv / OpenReview / LaTeX source 转成中文 HTML 精读页。

阶段四:知识整合

精读讨论清楚了以后,带着完整上下文让 Codex 调用 GPT-Image-2 生成信息图(一般一篇论文一张足矣),再带着个人理解与这张图做交叉验证,最终存档。

在执行这些过程时,通过 Agent 的 `Skill` 打通各个环节,提升速度,带来复利。

-—

关于科研绘图

科研绘图的三个类别

科研绘图分为三类。明白这些术语,可以更好地操纵模型绘图:

- 插图(Illustrations):阐述论文核心思想的示意图

- Teaser 图:在学术界,通常指为一篇论文制作的高度浓缩、引人注目的视觉摘要,常见于顶级期刊的封面(Cover)或亮点介绍(Highlight)

- Poster(海报):学术海报,用于在会议上展示研究成果,要求信息密度高、逻辑清晰且视觉吸引力强

策略:让 AI 写操纵 AI 的 Prompt

我发现让模型去生成 Prompt 的水平远超我自己,尤其是科研绘图方面。让我自己描述,我几乎完全描述不清楚。

我会先让大语言模型理解我的论文内容,然后由它来创造和优化用于生成图像的详细 Prompt。具体来说:

1. 把论文/想法丢给 AI,先问它在内容布局、配色、字体三个维度上如何规划

2. 可以主动指定大风格,比如 Nature / Science 风格

3. 一个很有效的技巧是使用参考图:把日常积累的优秀插图丢给 AI,让它分析风格,再基于你的论文内容生成新图像。

目前我还是把 AI 作为草图助手。出了草图以后,我会尽可能让 Agent 帮我做成 slides 或 HTML,再由我自己微调。AI 绘图需要大量迭代和多次尝试。目前 AI 最适合的角色,还是创意激发和草图设计助手;所有生成结果,尤其是涉及数据和逻辑的部分,依然必须经过严格的人工审核与修正。(严肃!)

谈谈最近的 GPT-Image-2

文字回答可以解释概念,但图像可以把层级、关系、流程、对比、因果、空间结构一次性摊开。GPT-Image-2 这类模型的价值,不只是“画得像”,而是能把前面讨论出来的上下文转成可检查、可讨论、可迭代的视觉对象。

与此前的 `nanobanana` 类似,当前 image model 正在从 image generation 迈向 visual intelligence:模型不仅仅根据提示生成图片,还需要理解上下文、规划版式、保持多图一致性、执行对话式修改,并将丰富上下文转成可视化产物。

GPT-Image-2 生成图片的“自然感”能够达到“以假乱真”的水平,这也要求我们提高评价标准,从更细致的内容层面进行检查。(如根据上下文生成科研绘图,应根据自身理解与其进行交叉验证比较)我们已经正式迈入了“有图未必有真相”、“图片内容不再可靠”的时代。未来我们很难通过肉眼以极短的时间判断出来一张高真实度的图片是否可信,可能需要仔细检查细节一致性、逻辑关系、来源链路与发布主体,而不是只看“看起来像真的”。

image

最近我真的在看到可能任何一张社交媒体传播的图片,我都会怀疑是不是 AI 生成的(特别是在这样一个魔幻的时代,看到很多很多可能不太符合正常逻辑的事情发生)

image

-—

关于科研写作

让 AI 多审几遍

现在 AI 审稿越来越严重,尤其是在 AI 领域。论文构思好以后,起稿阶段就可以先用相关的论文润色 Skill 辅助打稿。有了相对完整的草稿以后,建议多用专业的审稿 Agent 来审。我目前主要用 `paperreview` 和 `cspaper` 这两个网站,前者好像可以无限用,后者每个月有免费次数;另外我也做了一个可以给 Code Agent 调用的 `paperreview` Skill,放在 GitHub 仓库里了。拿到审稿意见以后,再和 AI 讨论哪里需要修改。在给导师看论文之前,先多迭代几轮,把一些潜在的小问题尽量提前解决掉。

另外,其实这样写出来的论文也更容易被 AI 认可;如果审稿人本身也在用 AI 审稿,可能会更容易给不错的分数。

和 AI 一起写,可以,但前提是它真的理解对了

一定一定一定要确保 AI 对内容的理解是正确的。一旦理解错了,后面越写越多,越写越偏,非常危险!

沉淀不同领域的写作 Skill

不同领域的论文,写作风格是不太一样的。

有的领域注重严谨推导;有的领域看重叙事铺垫;有的领域对实验细节特别敏感。

所以与其每次都去重新教 AI “这类论文应该怎么写”,不如先拿通用的科研写作 Skill 作为底子,然后喂本领域你认可的参考论文,慢慢沉淀出一个更适合你自己领域的写作 Skill。

这个 Skill 不需要多复杂,但它最好是:

- 知道你这个领域常见的论文结构

- 知道你偏好的写作风格

- 知道哪些地方要展开,哪些地方不能废话

- 知道你对实验、图表、相关工作、贡献总结的习惯要求

如果看到读起来特别舒服的高质量论文,也记得让 Code Agent 去学习一下。

三、Code Agent 使用指南

image

工具演变

我最先接触 Code Agent 的是 Cursor,后面逐步进化到 Claude Code 与 Codex 这些。现在构思的时候是 Claude Code、Codex、Gemini CLI 以及 OpenCode 四个一起用,通过 Claude-Code-Bridge(也就是常说的 CCB)。构思清楚以后交给 GPT 模型开 `xhigh` 模式,一步一步严格执行。通常就是睡一觉的功夫问题就解决好了。

心流状态:人和 Agent 都要减少摩擦

频繁使用 Coding Agent 以后,我反而发现自己有时候更难进入所谓的“心流状态”。原因不是 Agent 不够强,而是 Agent 介入以后,人的工作方式会被改变。GUI 来回点、鼠标切窗口、到处 `cd`、临时查命令、等 ChatGPT 解释一大段过程,这些动作单独看都不大,但叠在一起就会不断打断注意力。最后表面上是在高效使用 AI,实际上人一直在被迫切换上下文,给人带来一层“上下文税”。

人和 Agent 最好是能待在一个连续的操作回路里:搜索、打开、查看、处理、验证,尽量不要中途跳出当前现场。对人来说,CLI、快捷键和模糊搜索很重要。比如用 `fzf` 快速找历史命令或文件,用 `yazi` 在终端里浏览目录,在 macOS 上用 `open -a Preview` 直接打开 PDF 或图片。它们解决的不是“炫技”的问题,而是减少从思考到操作之间的阻力。少一次鼠标切换,少一次窗口跳转,人就更容易保持连续性。

对 Agent 也是一样。Agent 的能力不只取决于模型本身,也取决于它会不会选对工具。搜索代码时应该优先用 `rg` 或 `rg --files`,处理结构化数据时应该用 `jq`,临时 Python 依赖可以用 `uv run --with`,音视频处理应该想到 `ffmpeg`,图片处理应该想到 `magick`,PDF/LaTeX 相关任务应该知道 `poppler`、`xelatex` 这些工具。工具选错了,模型再聪明也会慢、会错、会做出很笨的方案。

所以我现在会特别注意 review Agent 的过程。重点看它用了什么工具,有没有过早退而求其次,有没有忽略 GPU、远程机器或专用工具,有没有明明存在更快路径却用慢方案硬跑。比如做 Whisper 转录时,如果本来可以走 Apple Silicon / Metal / MLX 加速,却退回 CPU 跑半小时,这就不是“慢一点而已”,而是工作流规则没有写清楚,模型也没有 get 到。我们遇到这种情况,比如一次发现 `rg` 比普通搜索更适合项目级代码检索,就不只是自己记住,而是写进 `AGENTS.md` 或 Skill。一次发现 `uv run --with` 很适合临时 Python 依赖,也写进规则。这样下次 Agent 不需要重新“猜”,而是默认走更合理的路径。

我觉得有两件事特别重要:

1. 先走最佳实践,不要一开始就退而求其次。 如果正确路径连续尝试几次仍然不可行,再有意识地 fallback,并说明为什么 fallback。

2. 人必须理解基本概念和原理,才有能力 review Agent 的自动过程。 不懂工具链、不懂任务本身的约束,就很难看出来 Agent 是真的做对了,还是只是把话说圆了。

所以 Code Agent 的“心流状态”,不是完全放手让它自己跑。更准确地说,是人把任务意图、工具选择和验收标准都约束清楚,人减少无意义操作,Agent 减少无效试错。让 Agent 在正确的轨道里高速推进。

复杂需求的处理流程

简单需求就不展开了。说说复杂需求怎么做(参考刘小排的经验):

把模糊的想法逐渐写清楚

事实上我的很多个想法都是极其模糊的,可能我想的一两句话背后有十几个决策点需要关注。具体做法是:我会先把一开始的需求同时发给四个 AI,让它们用自己的话术整理需求,然后向我提问;这里推荐一个不错的 skill,叫做 `grill-me`。接着我不断回答各个 AI 提出的问题,AI 继续追问。这个过程要让 AI 多输出可视化的 ASCII 原型图,加深自己的理解。不断让 Claude 模型去整理各个会话的内容(Claude 的模型说得容易懂),迭代直到所有 AI 都认为当前的方案已经没有问题,或者问题可以忽略不计,最终交给 GPT 模型通过 `/goal` 模式完成即可。

各个模型特点

- GPT / Codex:比较严谨。GPT-5.5 相比 GPT-5.4 有了很大的改进,特别是在语言表达上(少了很多口癖,说话没那么令人反感了 hhh,但是貌似没有找回以前第一次用 GPT-5.2 那种感觉)。

- Claude(Opus 4.8):表达能力强,速度快,工具调用各个能力都很优秀,但价格比较贵,不能随心所欲地用。虽然大家感觉都不如 Opus 4.6,但是至少相对 Opus 4.7 来说还是有进步的。

- Gemini:前端能力很不错,很适合用来发散思维,有很丰富的世界知识,有时候聊方案的时候会有意想不到的效果。

- Grok:搜索能力很优秀,在审查上应该也是最松的,还有 NSFW 模式。推荐 `grok-search` 这个 MCP 搭配其他 Code Agent 使用。

推荐的使用方法论

1. 多使用元 Prompt 或 Skill——比如造 Skill 的 Skill,把常用的工作流模板化。

2. 不会的多问 Agent——很多东西 Agent 可以给你讲懂,并且最终落实做出来可以用。就不断迭代积累经验。

3. 多向社区学习——参考他人的经验,不断完善自己的工作流,让自己的 AI 越用越方便,让自己更擅长与 AI 协作。

-—

四、多回顾,最好定期复盘

image

Skill 不是越多越好

Skill / MCP 不是见一个就安一个。 我原先就是这样,遇到一个看起来不错的 Skill,就想让我的 Code Agent 给装上。最近回头复盘才发现,自己这里已经堆了很多做同一件事的 Skill。给同样的输入,有时候模型选 A,有时候选 B,有时候选 C,结果并不稳定。毕竟模型在选 Skill 的时候,很多时候只能先看 `description`。

OpenAI 和 Anthropic 都在官方文档里提到过,相关工具最好尽量收敛一些。当工具数量太多、同类能力重叠、边界又写得不清楚时,模型更容易选错、犹豫、变慢,甚至被长输出拖垮上下文。

所以我现在会定期回头复盘自己的 Skill 和 MCP,看它们到底有没有真正给我带来增量,我到底有没有长期用到它们。如果一个 Skill 只是“当时看起来很厉害”,但后来几乎不用,或者和别的 Skill 做的是同一件事,那我就倾向于把它关掉,甚至直接删掉。相反,如果我发现一个东西自己反复在用,而且确实好用,我就会继续往里看,搞清楚它到底为什么好用,再决定要不要把它沉淀成自己更稳定的一套东西。

另外,其实现在很多网上公开的 Skill,都是遇到需求以后直接让模型写出来的,而不是“尝试 → 错误 → 修改 → 沉淀”的产物,质量未必足够好。装好以后最好自己测一下,看看“用这个 Skill”和“不用这个 Skill”之间到底有没有差别;这件事也可以交给 Code Agent 自己做。

这只是其中一个例子。和 AI 协作不是不断往系统里加东西,有时候做减法更有用:留下有用的,去掉噪声。

警惕“效率幻觉”

不知道大家有没有这种感觉:每天用 AI 写代码的时候,产出看起来很多,推进也很快,但等真正沉下心回顾时,却很难说清楚自己到底做了什么,甚至有时候连当时为什么要那样做都不一定想得起来。

某种程度上,AI 把“做”的门槛压得很低,于是人很容易在需求还没想清楚的时候就先开做。想着“这个功能先 vibe 一下再说”,结果写着写着,需求开始漂,方向盘也交了出去。你没有想清楚,它也不会替你想清楚,它只会更快地把一个模糊的东西做出来。

如果只是一味把 AI 当替身,让它一路写、一路改、一路带着你走,那本来应该由自己完成的理解、判断和取舍,也会一起被外包出去。最后得到的,可能不是更强的能力,而是一种“虚假生产力”。

对我来说,一个很重要的边界就是:我是否还能清晰地主导“问题表述”和“验收标准”。如果这两样开始模糊,那就很危险了。如果你自己都还不知道想要什么,就先别急着干。否则可能后面看起来还在推进,但推进的东西到底对不对,自己其实已经没那么确定了。

我对抗“效率幻觉”大概有两步。

第一步,是把决策可视化。

image

我会尽量把自己思考的东西打出来,输入到幕布里,再转成思维导图去看。这里最关键的不是工具,而是要自己动手,尽量不要复制粘贴。AI 可以辅助,但这一步我更希望是我自己在输入、在整理、在重新组织。因为只有这样,我才能确认这些内容真的是我自己想清楚的,而不是只是看 AI 说得很顺,就默认它是对的。

某种意义上,这一步对我来说是 100% 的“人在回路”。它会在物理层面强制我把思考重新接回来,同时也能保证持续专注,因为这件事没法并行,也没法偷懒。

第二步,是主动抽离。

抽离对我来说,不只是休息一下,而是一个避免局部最优、避免反刍、恢复元认知的过程。

因为和 AI 协作久了以后,很容易出现一种情况:对话越来越顺,内容越来越连贯,于是人会慢慢产生一种“我们正在前进”的感觉。问题在于,这种流畅感本身就会削弱人的警惕性。清醒的时候,你还会不断追问:这一步的依据是什么?风险在哪里?但到了后期,尤其是累的时候,人更容易接受那些“语言上讲得通”的东西,于是决策权就会默默让渡出去。

而且这种让渡通常不是一下子发生的,它更像是一个渐变的滑坡。

所以我的做法会更偏物理一些。比如我坐在电脑前工作一段时间以后,会刻意离开电脑,站起来走一走,喝点水,强制把自己从当前状态里抽出来。我的大脑并没有停止,只是像经历了一次重启。然后我再回来重新看:我们现在到底进展到了什么地步?如果我要给别人汇报进展,我会怎么汇报?我们现在做的这件事,真的是对的吗?

对我来说,这一步很重要。因为很多时候,所谓“效率幻觉”不是你做得不够多,而是你已经做了很多,但你开始说不清自己到底为什么这么做了。

-—

## 五、AI时代生存(学习)指南

image

学会主动降噪

这是一个什么时代呢?因为我有每天听播客、看最新动态的习惯,很容易会有一些错觉:好像每天都有新模型、新工具、新 Agent 发布,感觉世界每天都在被重写。

变化当然是真的,焦虑也不是空穴来风,很多岗位裁员是真的,岗位收缩是真的,很多公司也确实把 AI、效率、组织重构这些话术和 headcount 变化绑在一起。但越是在这个时候,越不能被噪声牵着走,把所有信息都理解成“全完了,过一阵子就全部都失业了”。

同时,要明白很多信息本身也带着浮夸、博眼球的成分。不要失真地理解现实,不要被节奏带跑,焦虑地过日子,焦虑既不解决问题,也伤身。

主变量是人

目前,AI 可以辅助探索、生成、执行。但是不能替代你对问题表述、验收标准、必要取舍和决策的主导权。这应该要成为共识。

变化是真的,所以不能躺平;起码在现在这个阶段,大家能用到的 AI,无论是 GPT、Claude、Gemini,还是国内的 GLM、DeepSeek、Kimi、MiniMax 等等,差距没有大到离谱的程度。(当然,能用最好的还是用最好的)

更大的区别还是在于用 AI 的人。同样的一个模型,不同的人用出来的效果是不一样的。小学生和数学家用同一个 AI 去做数学,最后发挥出来的力量肯定是不一样的。所以说,这个时代,要学习。

如果把“人是主变量”这件事再画得更直接一点,大概就是下面这个样子。

image

不能只会用 AI

如果你完全不懂你现在让 AI 做的事情,那你几乎是无法判断和分辨好坏的,也是无法做到经验累积的,你只能做一个搬运工。而这样长期下去,过度依赖 AI 而不学习会导致能力萎缩,最终个人能力可能逐渐倒退至完全被 AI 的能力所 cover,这是很可怕的一件事情。

如果你发现 AI 在跑,你只是盯着控制台发呆,刷手机,最后再把结果原样拿来用,或许该警惕了。

学什么,怎么学

学什么呢?去学概念、原理、表达、审美、判断。

决定能不能进入一个领域的概念与原理的知识是不会太多的。抓住这些主干,你就能够更快进入这个领域的 space,知道它的大致边界、结构和内在关系。

所以不要碎片化地去追热点,什么火去学什么,可能这样学到的只是表象。应该要去学概念,学原理。建立起自己的地图,知道自己在哪,知道哪些概念是主干,哪些是枝叶。然后让 AI 帮你逐步展开、解释、练习。

这是一个非常适合学习的时代。我个人深切感受到了,很多过去晦涩难懂的知识,现在都可以让 AI 用你能理解的话解释;也可以扮演导师的角色拷打你,可以用苏格拉底式的问答逼你去把问题想得更深一点。

人机关系

有关人机关系,我想到的最差的关系是:自己不思考,只会搬运 AI 的答案。

最理想的路线是:自己有知识基础,有判断力,知道什么是好的,知道自己想要什么,然后让 AI 去帮你探索、生成、执行。

推荐的一些材料

如果你暂时找不到意义,不知道这样飞速发展的时代应该做什么,感到焦虑和迷茫,那么去学习吧。如果暂时不知道学什么,或者想从 coding agent 这条线入门,我推荐几个对我来说帮助比较大的材料:

- Learn ClaudeCode / `shareAI-lab/learn-claude-code`

适合从 0 到 1 理解 agent harness。

- Auto-claude-code-research-in-sleep / ARIS 的 skills

适合做学术研究,尤其是如果将 coding agent 与学术研究结合。

- `obra/superpowers`

适合看一套完整的 agentic skills framework 和软件工程方法论。

-—

六、对于我来说,不得不思考的一些问题

当未来 AI 产品与我们生活方方面面紧密结合时,会发生什么?

我现在也会警惕另一件事:人和 AI 协作久了以后,不一定只是效率更高了,也可能是在慢慢学会用 AI 听得懂的方式去表达自己。目标可能会变得更结构化,更 AI friendly,原本那些模糊、犹豫的东西是不是会慢慢变少?短期看,是沟通成本变低,执行变快,效率变高了;但反过来看,是不是也意味着我们也正在一点点变成一个更容易被系统理解、也更容易被系统预测的人呢?

另外,这种变化不是单向的,AI 会通过我的历史行为学习我,而我也会通过和 AI 协作的反馈学会怎么更快地得到结果。久而久之,就可能形成一种闭环:我越来越习惯某种提问方式、某种表达风格,而 AI 也会越来越顺着我。可这就是问题,它这样做太容易让人觉得“这就是我的想法”了,实际上可能是一种坍缩。看似是 AI 和人共同进化,实际上有可能只是你变简单了。

image

4 个帖子 - 4 位参与者

阅读完整话题

来源: LinuxDo 最新话题查看原文