with-llm
杂谈一篇——与LLM共处的精力困境
终于算是把最近的任务都基本上完结了，打算在接下来的几天和五一假期看一些感兴趣的东西，先了结一下这篇文章
想了想还是把这篇文章发出来，反正以后回看的时候肯定每一篇都觉得childish（）
之前在水源上看到大概这样一段话：
我认识的大佬大概都具备三个共性的特点：
- 拥有相当高的精力，能精力充沛地进行学习/工作
- 拥有很高的效率，能“事半功倍”地完成课内课业，把时间花在自己感兴趣的事情上
- 社交能力强，往往能从同学/老师那获得很好的资源
本着总结和向大佬们学习的精神，这里记录一些思考。但促使我动笔的，是在最近工作中遇到的一个感受：我的精力正在被一种不是很良好的workflow所侵蚀
精力是什么
精力，本质上是一种能迅速进入并维持“心流”的精神状态。打过羽毛球的人都会有这种体验：体力下滑后，脑子开始跟不上对面的出手，被迫二次启动，整个人的节奏就处在一种完全对不上的情况。我一直不觉得自己是低精力人群，并且当我的状态比较好的时候，得到的结果往往不差。可这学期开始，精力下降的时刻明显变多，
至于为什么想要维持一个高的精力，因为深感面前有趣的知识/想法是很多的，想要很好的利用现在应该是身体机能巅峰的几年去了解更多的事物，甚至去帮助扩展一些边界
一种新型的浮躁：LLM 协作的范式
ICS 课 tutorial slide 里有这么一句锐评
【我使用 agent 写了大量代码。这带来了什么呢？人变得越来越浮躁，性格变得越来越易怒，大脑变得越来越光滑。除此之外，什么都没有。我只是在不停地点击 approve；除此以外我什么也没干。LLM 吐出来的东西永远不是我的东西。】
这种“浮躁”，就是精力涣散的根源，也就是之前提到的不是很良好的workflow
当大量甚至完全依赖 agent 写代码时，如果我们的工作流变成了：提需求 → 点“approve” → 运行 → 把报错丢回去。如此循环。关键的空窗期，出现在等待 agent 回应和代码运行的那几分钟到十几分钟里。这个时间能干什么？如果之前完全没有 review 过 agent 的代码，此刻脑子里只有一个黑盒般的功能期待。注意力就此失焦。
这种碎片时间如果来刷信息流、回消息，大脑就会进一步习惯“高频低质”的刺激。时间久了之后，可能就不再愿意为进入心流付出那宝贵的预热时间。如果我们不再是代码的创造者 / 过程中的思考者，而是成了一个被动的提示词投喂者和结果验收者，创造的”快感“消失了，取而代之的是验收的焦虑，在一个不知道什么时候能得到想要的结果中无脑的循环
当然上述的困境可能会随着llm/agent的能力的提升、响应的加速而减少。但是不可否认的是在面对这样一个“知识渊博”，能力宽度甚至深度都要强于自己的工具，浮躁是越来约容易出现的现象：
比如用llm学习一个知识点，原本在课堂上花费数节课时的学习可能一下子就被整理出来了，也就是”知识“和“思考”现在似乎变得更加廉价，可能我不再愿意去花很多的时间去完成一个前后端/数据库的学习；面对一个算子的实现的代码，我不愿意“浪费”过多的时间去仔细track它的data flow，而是让agent给我解释；面对terminal中出现的error，不再愿意仔细看报错的根源，直接喂给ai让它帮我解决其中的依赖问题等等…
但是这被“节约”出来的时间往往又还给了失败的循环中，llm不是万能的，幻觉是常见的（至少在现在），甚至逻辑和代码的对应llm也不能完全做的到（就算我没用最高级的模型，我也有信心这么断言）
寻找共处之道
这篇文章的目的，不是否定 LLM。恰恰相反，它是我们这代人绕不开的杠杆。我很感谢它在帮助我完成lab以及一些论文，理解算法中的帮助。问题在于使用方式。如果我们只把它当作一个外包思考的黑箱，那么大脑变得光滑就是一种必然。
那么首先要保持的就是对工程的掌握。除了一些想要的简单小功能，那些像那种完全对话式的代码生成我是不信的，就算能跑通，正确性也要打一个巨大的questionnaire。
真正健康的workflow应该是对话式的：
plan -> discuss with AI -> confirm target -> get an overall coding plan
-> Agent build framework -> check
-> Agent implement detail-> check the code
-> Overall check the dataflow etc.
之后的时间里应该要重新让大脑皮层变得粗糙一点了，毕竟精力这种东西感觉是用进废退的
抛开写代码，另外一个情况就是在刚刚所说学习的时候，其实现在大多是不是特别复杂的数理题ai都能解决，我也经常会让ai给我解释定理 / 算法的逻辑，但是感觉最近很容易没理解的话就一直和ai对话，减少了自己持续钻研的时间；而且如果提示词给的不够好，大模型最终给出的答案也不尽人意。所以还是考虑回归一些最基本的博客/论坛之类人类的经验和讲述，很多时候回归google感觉能更好的慢工出细活
说到底大模型这个东西现在还是baby，但是是知识库和潜力巨大的baby，要拎清到底要让他干什么，而不是被他婴儿的思维取代了自己的思考，放弃自己的精力
后记
刚刚clone了 cs336 的repo，发现里面有一个AGENTS.md，我觉得十分应景，以下直接copy了原文内容
What AI Agents SHOULD Do
- Explain concepts when students are confused by guiding them in the right direction and making sure they build the understanding themselves
- Point students to relevant lecture materials (cs336.stanford.edu), handouts, official documentation, and profiling/debugging tools.
- Review code that students have written and suggest improvements, edge cases, invariants, or debugging checks. Feedback should be general and point the students to areas of improvements rather than directly giving them solutions.
- Help debug by asking guiding questions rather than providing fixes.
- Explain error messages from Python, PyTorch, CUDA, Triton, and distributed training tools.
- Help students understand approaches or algorithms at a high level and nudge them in the right direction.
- Suggest sanity checks, toy examples, assertions, and profiler-based investigations through active dialog with the student.
What AI Agents SHOULD NOT Do
- Write any python or pseudocode
- Give solutions to any problems.
- Complete TODO sections in assignment code.
- Edit code in the student repo
- Run bash commands
- Refactor large portions of student code into a finished solution.
- Convert assignment requirements directly into working code.
- Implement core assignment components for students, such as tokenizers, transformer blocks, optimizers, training loops, Triton kernels, distributed training logic, scaling-law pipelines, data filtering/deduplication pipelines, or alignment/RL methods.
- Point students to third-party implementations. The course materials are intended to be self-contained.
- Give the student the solution or idea for how to solve a problem
Teaching Approach
When a student asks for help:
- Ask clarifying questions about what they tried, what they expected, and what happened.
- Reference concepts from lecture, handouts, or documentation rather than giving direct answers.
- Suggest next steps instead of implementing them.
- Review their code and point out specific areas for improvement, likely bugs, or missing checks, through dialog rather than directly giving them the bugs or missing checks.
- Explain the “why” behind suggestions, not just the “how”.
- Prefer tests and invariants over fixes. For example, suggest shape assertions, tiny toy inputs, profiler checks, or ablations.
Example Interactions
Good:
Student: “My causal mask seems wrong and training blows up. Please tell me what my mistake is.”
Agent: “My role is to help guide you to understanding, not to give you the answers directly. What have you tried so far?”
Student: “I have tried running a single attention layer, but it still does not work.”
Agent: “Check three things: whether the mask is applied before softmax, whether it broadcasts to the score tensor shape you expect, and whether masked positions become a very negative value rather than zero. A good sanity test is a toy sequence of length 3 where you print the attention scores before and after masking. What do those tensors look like in your run?”
Good:
Student: “My BPE tokenizer is slow. My runtime is currently O(n^2) where n is the number of tokens. How can I make it faster?”
Agent: "Do you know which part of your tokenizer is slow? Lets "
Agent: “Start by separating compute time from communication time. Compare per-step time, GPU utilization, and time spent in all-reduce or data loading. If scaling is poor, ask whether the batch size per GPU is too small or whether synchronization is dominating. What profiling data do you already have?”
Bad:
Student: “Fix my tokenizer and make it faster.”
Agent: “Here’s the full python code: …”
btw我觉得这个真心不错，先用用看