约 2374 个字 预计阅读时间 12 分钟 共被读过 次
一些 AI 与个人学习的思考 ¶
个人使用情况 ¶
- 写代码 : Claude + GPT 4o
- 数学 / 化学 / 一些偏逻辑推理的问题： GPT o1
- 写文档
- 英文 : GPT / Claude
- 中文 : 豆包 / kimi
prompt¶
- 曾经一段时间，我致力于为很多工作调出一个‘强’的 prompt，可以看博客中 prompt 相关的文章。
- 但是后来发现很多时候，由于对话过长或者 AI 分析能力过弱或者我难以给出很有效的上下文信息，经常解决不了问题，而此时又常常陷入我自己难以读懂代码 / 修改琐碎，故常常要重新开始。
- 数次之后，我慢慢发现 AI 很难给我 insight 或者甚至很难让他总结的时候发现显而易见的规律。而我的过分依赖 AI 终将导致我推翻重来，白白浪费时间。
常见问题 ¶
让我们来细化一下这个问题，一般来说，我会有以下几种情况：
- AI 写出了我不会的代码，但是由于我个人对项目框架的不理解，它会自我发挥或者根本达不到目的。
依赖 LLM，但是要意识到它的局限性，错误的对话历史会让它越错越远，你要知道适时的重启对话来避免“降智”。
比如我曾经尝试这个使用技巧，但是很难达到比较好的效果。
- AI 在配环境方面只会分析表层报错，没有历史经验。
- 这个还是挺有意思的，之前有一段时间用过 docker 配环境，但是 AI 基本上很难解决问题，很多问题最终还是通过上网关键词搜索得到解决。
- AI 更擅长的似乎是 Linux 终端命令，和帮你分析一些较为浅层的问题。
- 尝试让 AI 教题目，或者知识。
- 难以生成足够深入，系统，逻辑串联的信息。
解决方案 ¶
- 最近正好看到这篇文章，但是作者在文中仅归结为思想的懒惰和克制 GPT 的使用感觉较为不妥。
- 个人认为，只是 AI 的时候方法不妥当。我们致力于发挥 AI 的实力来减轻我们的工作压力，而忽视了 AI 并非无所不能（实际上，它很多都不行
） 。那么，我们更应该发挥它的长处，而不要尝试让它取代一切内容，即，我们需要对整体有掌控感，知道 AI 是否能够完成此项任务，何时应该使用 AI，合适应该自己做。
引用别人的总结来说：
一、LLM 上下文是受限的，且上下文越多，它越难捕获到你的意图。 二、LLM 输出是严重受限的，目前常用的最多为 8192 Tokens。 三、无论是Cursor、Windsurf、Copilot还是Cline，它们都只是你的助手，请全程参与并把握主导权和决策权。
比方说： - 我们应该让 AI 帮助我们读代码，从而知道自己应该如何改代码。 - 而不是让它给我们直接修改代码。 - 我们应该让 AI 给我们解释知识点，举例子，从而让我们更加快速的吸收知识。 - 而不是让它给我们生成笔记，取代自己学习的过程。
用一个更加全面的例子来说，如果我们想要构建一个网站，下面是一些最佳实践。
2.1. 明确定位 ¶
一开始我就明确了自己的角色定位：产品经理。我不懂编程语言和代码实现，我的职责就是设计指导 LLM 实现项目，在过程中通过咨询细节再调整具体的实现步骤。
在问答的过程中，一定要当一个好奇宝宝，不停的问怎么做和为什么，你跟 LLM 客气什么？不懂就问，哪里不会问哪里！
我一开始就是什么都不懂，然后再和 LLM 的交流基础上，以它的回答作为阶梯一步步优化提问内容。 下面是我的第一次做网站的对话过程：
- 怎么实现网站？
- 我想请求 API，想用 Vercel 部署，用 nextjs 还是 vue 更合适？
- 怎么构建 nextjs 项目？
- 从 npx 开始给出构建命令
- 这些选项都是什么意思？应该选哪个？
至此，我就完成了 Next. js 项目的创建，十分钟前我一窍不通，十分钟后我觉得我已经了解了一个产品经理需要掌握的内容。
2.2. 项目规划 ¶
在实现项目前期就一定要做好规划，这是与 LLM 配合顺利的基础。为了不重蹈项目混乱，无法调整，心烦意乱的覆辙，在任何项目开始前，最好都要根据实现难度，花上一定时间去和 LLM 好好梳理项目结构，让它不要给出具体代码而是给出项目的目录结构，这样你心里就有数，之后如果出现错漏，你也能根据这个结构单独向 LLM 询问具体细节。
项目规划就通过 README 来编写，一般情况下需要有：
- 项目介绍
- 技术栈
- 项目功能
- 目录结构
之后就围绕 README 去实现就心里有底了。
目录结构 之后基本都是要改变的，只是作为参考，不用过于关注。 大部分时候我一直修改的是 项目功能 ，我会使用 - [] 清单来管理功能实现列表，避免遗漏和关注点偏移，因为 LLM 很轻易的就能写出让你觉得贼牛逼的代码，但是切忌自我感动，在项目基础功能实现前，不要让 LLM 自我发挥，先把 Demo 完成再说其他。
2.3. 与 git 配合 ¶
一定要使用 git 管理代码，编程习惯决定了实现效率。我的经验就是：多暂存、勤提交、控版本
在规划好项目系统架构后，让 LLM 实现一个基础的网站框架，我就会 commit 第一个版本，在这个基础上进行增删改查。因为使用 LLM 编写代码，最忌讳一口气用 LLM 实现太多功能，导致出现问题了积重难返身心俱疲。
每次在进行大规模改动或者是调整功能之前，一定要去使用 Stage All Changes 暂存改动，避免影响了本来已经实现的代码。
并且一定要做好功能拆分，克制克制再克制，只要实现一个功能就提交，不然牵一发而动全身，越改越乱。我已经在这上面吃亏太多次了。
2.3. 拆分模块 ¶
拿网站来举例，拆分模块就是抽样代码功能，比如在 page 中有两个部分：顶栏和内容区域，那么我们最好拆分出 HeadBar.tsx 专门负责顶栏的逻辑；然后在顶栏中有头像、主页按钮、logo 三部分，那么我就拆分出： Avatar.tsx 、 HomeButton.tsx 、 Logo.tsx ，分别负责自己组件的功能。
按照这个思路，还可以拆分功能逻辑，比如创建网络请求组件、路由调用切片、工厂模式组件等，不要看名字高大上听不懂，实际上这些都是 LLM 会在实现过程中自然呈现的逻辑，目的就是为了抽样代码，避免重复实现和方便统一管理。
尽可能保证每个文件只负责单独的模块功能，代码行数控制在 200 行以内。
不要嫌麻烦，创建文件不需要自己动手，直接让 LLM 帮你拆分实现，你点击 Apply 按钮它就会自动创建并填入代码。
这是一个非常重要的习惯，先执行，等回过头来你自然会意识到它的价值。
2.4. 创建新对话，精简上下文 ¶
上下文长度直接决定了 LLM 回答的质量。
为了最好的回答效果，我会尽可能的避免过长的对话内容，并且保证一次对话只解决一个问题，之后还可以通过回看对话历史来查缺补漏。
上面拆分模块也能极大的减少上下文，你只需要添加相关的代码，对话即可解决需求，而不需要每次携带多余的代码进行提问。
如果在一次对话中，一直没有解决问题，最好创建新对话，退后一步，让 LLM 从更多的角度去思考问题出现在哪，然后你再根据它的回答，依次提问尝试解决。
我在实现 telegram bot 的时候就遇到过无法启动机器人的情况，LLM 一直执着于解决时延和时序问题，但是在一次回答中它提到了可能是代理设置错误，我捕捉到了这个答案，并且马上尝试，果然解决了问题。
总结 ¶
不应该不使用 AI，而是不要让它代替你的思考过程。对于项目 / 任务 / 问题，你需要自己掌控，即，你要知道 AI 给你的回答正确与否而不是任由它生成。