AI 使用笔记：从提问、开发到焦虑——一点普通使用体验的整理

AI 使用笔记：从提问、开发到焦虑——一点普通使用体验的整理

最近这一两年，AI 相关的话题确实很热。无论是学习、科研、写作，还是日常工作中的一些琐碎任务，AI 工具都开始越来越多地出现在我们的生活里。我自己在使用这些工具的过程中，也慢慢积累了一些比较真实的感受和想法，所以想借这篇文章简单聊一聊。

我并不是 AI 领域的专业研究人员，也没有什么很深的理论背景。我的身份很普通，就是一名建筑的研究生，平时接触 AI 更多是从学习、科研辅助和日常使用的角度出发。因此，这篇文章不会去做特别专业、系统的技术分析，也不敢说有什么权威结论，更多只是把自己作为一个普通使用者的体验、观察和思考整理出来。

所以，本文的定位也比较简单：不是教程，不是评测，更不是学术论文，只是一篇个人经验分享。文中的观点难免会有局限，甚至有些地方可能还比较浅显，大家看个参考就好。倘若能给同样正在使用 AI、或者准备尝试 AI 工具的朋友带来一点启发，那这篇文章的目的也就达到了。

一、和 AI 交流，不必太“端着”

在使用 AI 的过程中，我发现一个挺有意思的现象：很多人一开始和 AI 聊天的时候，反而会把自己搞得很紧张。

比如有的人在提问之前，会反复斟酌措辞，担心自己表达得不够准确；有的人会特别在意错别字、标点符号、语气是不是礼貌，甚至一句话改来改去，搞得好像不是在用工具，而是在写一篇准备发表的文章，或者是在发一段表白文案。

我觉得这种使用方式，其实有点把 AI 太“当人”了。

当然，和 AI 交流保持基本清楚的表达是有必要的，但完全没有必要把每一句话都写得特别正式、特别完美。AI 不会因为你用了口语、不小心打了错别字，或者标点符号不规范，就对你产生什么看法。很多时候，你越是想把问题包装得滴水不漏，反而越容易把自己的真实需求藏起来，最后效率也低，效果也未必好。

但反过来说，也不能把 AI 完全当成传统意义上的机器。

有些人使用 AI 的时候，又会走向另一个极端：觉得必须像写代码、写检索关键词一样，一次性输入一个非常精确、非常完整、非常严谨的问题，好像只有这样 AI 才能工作。于是提问前先憋半天，想把背景、目标、限制条件、输出格式全都一次性说清楚，生怕哪里没写明白，AI 就给不出答案。

这种方式也很容易让人用得很累。

AI 和传统搜索引擎、数据库检索、命令行工具不太一样。它的一个重要优势，恰恰在于可以多轮交流。你不需要一开始就把问题设计得非常完美，也不需要期待一次提问就得到最终答案。更自然的方式应该是：先把你现在最直接、最粗糙的问题抛出去，看它怎么回答；如果哪里没看懂，就继续问；如果回答方向不对，就让它调整；如果你发现了新的问题，就顺着往下聊。

换句话说，和 AI 交流应该是以自己为中心的，而不是以“我要怎么说 AI 才满意”为中心。

比如我因为科研任务需要，想了解街景图像中的语义分割问题，那我一开始完全可以直接问一句：“街景识别语义分割咋做？”这个问题当然不算严谨，也不算专业，甚至有点口语化。但没关系，它足够作为一个入口。AI 给出一个大致回答后，我可以先看它提到哪些概念，比如数据集、模型、标注、训练、评估指标之类的；哪个地方不懂，我就继续追问；哪个方向和我的任务有关，我就让它展开；回答太泛，我就让它结合我的具体场景再说。

这个过程更像是在和一个很有耐心的助手一起梳理问题，而不是在对一台冷冰冰的机器下达一次性命令。你可以一边问，一边学，一边修正自己的问题。很多时候，真正有价值的答案并不是第一轮就出来的，而是在反复追问、补充背景、调整方向的过程中慢慢浮现出来的。

所以我自己的一个体会是：用 AI 不要太端着，也不要太憋着。它既不是需要你小心翼翼照顾情绪的人，也不是必须用精密指令才能驱动的传统机器。更好的方式，是把它当成一个可以随时交流、随时修改、随时深入的辅助工具。先问起来，再慢慢问清楚，往往比一开始就追求“完美提问”更有效。

二、Vibe Coding：先把项目聊清楚

说到 AI 辅助开发，就绕不开现在比较流行的一个说法：Vibe Coding。

我自己平时比较习惯的方式是 GPT + Codex：前面用 GPT 聊需求、做策划、拆任务，后面再把明确好的开发步骤交给 Codex 去实现。这个流程用下来，我最大的感受是，Vibe Coding 并不是简单地对 AI 说一句“帮我写个程序”，然后等着它一口气把项目变出来。真正关键的地方，反而是在正式写代码之前，先和 AI 把需求、功能、界面、技术路线这些东西一点点聊清楚。

拿我自己做的一个项目 gapMapAi 来说，项目地址是：https://github.com/Phenol-93/gapMapAi 一开始的时候，我脑子里其实也只是有一个比较模糊的想法：我想做一个“最短学习路径生成器”。至于它具体应该有什么功能、页面怎么设计、用户怎么使用、后端怎么组织、技术路线怎么选，其实都还没有完全想明白。

这个时候，我并没有一上来就要求 AI 直接写代码，而是先很随意地和 GPT 说了一句类似这样的话：“我要做一个最短学习路径生成器，你帮我详细做个策划，有啥细节问我就完了。”

这句话并不复杂，也不是什么精心设计过的提示词，但它很符合我前面说的那种思路：先把自己当前最直接的想法抛出去，然后让 AI 参与进来，一起把问题往下推进。之后的过程就是一轮一轮地聊。GPT 会根据我的想法提出一些问题，比如这个工具面向谁、输入是什么、输出是什么、学习路径怎么生成、页面需要哪些模块、是否需要登录、是否需要保存结果、项目规模打算做到什么程度等等。我就根据自己的实际想法一点点回答，不清楚的地方也继续问它。

在这个过程中，项目会从一个很模糊的念头，逐渐变成一个比较具体的软件方案。到后面，GPT 可以帮我整理出比较完整的软件说明，包括项目目标、核心功能、页面结构、用户流程、数据结构、技术选型和开发步骤。这个时候再进入编码阶段，就比一开始直接写代码稳得多。

比如在 gapMapAi 这个项目里，我后面根据 GPT 的介绍去下载和配置了 Rust。配置过程中遇到不懂的地方，也可以继续问 GPT。等基础环境准备好之后，我再告诉 GPT：“我要用 Codex 实现这个项目，你帮我生成一个分步的、详细的 Codex 提示词。”然后 GPT 就可以根据前面已经确定好的项目方案，把开发任务拆成一段一段比较清晰的提示词。接下来我只需要按顺序复制给 Codex，让它逐步完成对应部分的实现。

这种方式对我来说是比较舒服的。因为它不是要求我一开始就像专业项目经理一样，把所有需求文档都写得很规范；也不是让我完全不动脑子，把代码全都甩给 AI。更准确地说，它是让 AI 参与到“想清楚”这个过程里：先聊想法，再定功能，再定界面，再定技术路线，最后再拆成可以执行的开发任务。

当然，技术选择这一块也要看个人基础。如果本身有一定开发经验，那可以提前告诉 GPT 自己倾向用什么技术栈、熟悉什么语言、项目希望部署在哪里、有没有性能或平台要求。这样 AI 给出的方案会更贴近自己的实际情况。如果没有太多开发基础，也不用太紧张，可以直接让 GPT 给你讲每一种选择的区别，比如为什么用 Rust、为什么用某个前端框架、为什么需要数据库、不同方案各自有什么优缺点。

我的体会还是那句话：大胆问就完事了。

不会配置环境，就问它怎么配；不懂技术选型，就让它对比；不知道项目怎么拆，就让它分阶段；不知道怎么给 Codex 写提示词，就让 GPT 先帮你写好一段。Vibe Coding 最有价值的地方，不只是 AI 能写代码，而是它可以陪你把一个模糊的想法逐渐打磨成一个可执行的项目。

三、关于 AI 焦虑：别被“必须马上学会”牵着走

最后想聊一下关于 AI 的焦虑。

站在一个普通研究生的角度，我觉得 AI 带来的压力确实是客观存在的。无论是岗位替代、技能迭代，还是未来就业市场对人的要求变化，这些都不是一句“不要焦虑”就能完全抹掉的问题。尤其是对还在读书、准备就业或者正在做科研的人来说，看到 AI 发展这么快，心里有点紧张是很正常的。

但我也发现，很多人并不是在真正了解 AI，而是被“AI 焦虑”推着往前跑。

有些人一听到 AI 很重要，就立刻觉得自己必须马上开始学，必须紧跟最新工具，必须每天看一堆教程和资讯。于是折腾半天，最后可能只是跟着某些视频一步一步照葫芦画瓢，或者买一些不断制造焦虑的付费课程，模仿着做了几个看起来很“AI”的东西。表面上好像学了不少，但实际上自己对这些工具到底能解决什么问题、适合放在什么场景里用、背后的逻辑是什么，可能并没有形成多少真正的理解。

我不是说系统学习没有用。那种“我决定拿出一大段时间，好好看一个课程，完整学一下 AI 工具或者相关技术”的方式，当然是有效的。对于有明确目标、有学习计划的人来说，这甚至是很好的方法。

但对我自己来说，真正让我慢慢了解 AI 的，反而更多不是这种特别正式的学习，而是一些更日常、更零散的接触。

比如身边有人突然说一句：“这个工具真好用，你试试。”我就去试一下。或者是在平时刷推文、看短视频的时候，偶然看到一个别人使用 AI 的场景，觉得有点意思，就顺手点进去看看。再或者是自己做科研、写代码、整理资料的时候，刚好遇到一个具体问题，就问问 AI 能不能帮忙。很多时候就是这样一点点瞎点、瞎戳、瞎试，慢慢就知道了哪些东西有用，哪些东西只是看起来热闹。

我觉得了解 AI 更适合从两种入口开始：一种是好奇心，另一种是紧紧扣住自己的日常需求。

如果只是因为焦虑而学，很容易变成被外界推着走。今天看到别人说这个模型厉害，就去学这个；明天看到别人说那个工具会淘汰一批人，又赶紧去学那个。最后工具收藏了一大堆，教程看了一大堆，但真正用在自己学习、科研和工作里的东西并不多。

反过来，如果是从自己的需求出发，感觉就会轻松很多。比如我今天要写一段文字，那我就试试 AI 能不能帮我理顺表达；我今天要做一个项目，那我就让 AI 帮我拆需求、写计划、改代码；我今天看论文看不懂，那我就让它帮我解释概念。每次只解决一个具体问题，积累下来，理解反而会越来越扎实。

这其实和学很多软件工具是类似的。比如我作为建筑方向的研究生，平时也会接触 Photoshop、Rhino 这类软件。真正熟悉这些工具，很多时候并不是一开始就抱着一本大教程从头学到尾，而是先瞎点点，知道大概能干什么；遇到具体需求了，再单独去搜某个操作怎么做；用得多了，慢慢就形成自己的理解了。

AI 也是一样。它当然重要，也确实值得关注，但不一定非要把它变成一件特别沉重、特别焦虑的事情。与其天天想着“我是不是又落后了”，不如先从自己手头的问题开始，用一点是一点，会一点是一点。保持好奇，保持使用，保持提问，慢慢就会发现，AI 并不是一个必须立刻攻克的庞然大物，而是一个可以逐渐熟悉、逐渐纳入自己工作流的工具。

所以对我来说，面对 AI，与其焦虑地追赶，不如轻松一点地使用。真正有价值的理解，往往不是被焦虑逼出来的，而是在一次次具体需求、一次次随手尝试、一次次“原来还能这么用”的过程中慢慢长出来的。

结语

以上这些，就是我作为一个普通 AI 使用者的一点个人感受。

我并不是 AI 领域的专业人士，也没有打算在这篇文章里给出什么标准答案。这里写到的东西，更多来自我自己平时学习、科研和折腾项目时的一些零散体验，难免会有片面甚至不准确的地方。大家如果觉得有参考价值，可以拿去对照自己的使用习惯；如果觉得不适用，也完全正常。

毕竟每个人的专业背景、工作内容和使用场景都不一样，适合我的方法不一定适合所有人。我只是觉得，面对 AI 这种工具，或许不用一开始就把它想得太复杂，也不用被各种焦虑推着走。先从自己的需求出发，轻松一点地试，遇到问题就问，觉得有用就留下，觉得没用就放过。

说到底，这篇文章也不是想教谁怎么用 AI，只是把我自己一路摸索下来的一点体会记下来。要是能给同样在尝试 AI 的朋友提供一点点参考，那就已经很好了。