从放假回国（2 月 23 日）来就一直想着写些什么，但一直没有付诸行动。这一方面是因为没有实践或感悟而无话可说，另一方面也是因为比较严重的拖延。拖延在我这差不多有两个源头：一是感到任务太难，担心无法做好而不敢开始、二是找不到任务的意义而不想动手。有时候拖延主要是来自于其中一个，有时候则是两者都有。比如说，复习本专业的一门课是前者，语音学课程论文就是两者兼有。写这些只是简单记录一下过去学业生活上的一些事情，把这个博客当作日记用了。
因为三月份 HiWi 合同终于正式开始，一些重复性的工作（dirty work）也就出现了。把 Proposal 改写的任务称为 Dirty Work 其实是不公平的，因为想保证转换高效、申请成功，还是需要不少经验和巧思（尽管我不清楚这里面有多少我能决定的，有多少又在于 idea 本身），但眼下这对我来说确实是一种 dirty work，因为我似乎对它们的内容无能为力，只能做调整 prompt、和 AI 吵架、复制粘贴、调整格式的工作。如果这样工作下去，显然看不出这种方式能怎么提高中标率，也不知道自己能有什么成长。
这样看来，眼下急需做的是将 dirty work 变得有意义，也就是将其中的 Dirty 部分尽可能自动化，然后思考目前真正需要人力判断的是什么并且学习（我还不太清楚，human-in-the-loop 到底在哪里应该是个经验的事情）。
对于前者，最容易想到的：重复的复制、类似的 prompt 显然应该写个脚本。不过实际操作中对于每个段落的 review（尽管有时只是长度）应该如何完成就需要一些探究（prompt engineering）。另一方面，proposal 转换大部分是一种形式的翻译，但也可能出现缺少信息的情况，这种情况应该要能有效识别并要求补充。具体有什么模型能做到这一点，便宜的 DeepSeek 够用吗？这也是一个经验问题。这一切成功有一个基础，就是一份良好的 Generic Proposal Template。这个 template 可以借助 AI 和人类经验从许多申请模板中总结出来，信息应该尽量富集。显然不是每个集群都需要全部的信息——我想从使用者角度考虑，还应该维护一个集群-必填内容的映射表。否则，在没有规模化保证的时候，如果申请者只申请一个集群，为什么要填一个更复杂的模板，而不是专用模板？
思考（chain of thougt :p）到这里，和我预计的结果有点不同。我原以为人类经验真正重要的地方在于那个泛型模板，但它似乎更像一种机械的最大公约数，模型能完成这件事吗？我认为很大程度上可以。那么到底有什么必须是我来做的？我目前能想到的只有设计 workflow 取代 dirty work 的过程中，在各种循环、条件上引入的经验。我想顶尖模型也懂得用实验试错，但它们大概还没有我便宜吧。
总之，我应该尽快行动起来。技术选型可能不需要纠结太多，我想 LangGraph / n8n 就足够了。
我不太喜欢这个迷茫而憋屈的结尾。也许我是错的，那也是一件好事。