网站构建日志
初具形态
2026年5月29日，天气晴转暴雨
首次打包上传GitHub，部署vercel，拉通make和DeepSeek自动化流程
首次把项目打包上传托管平台，看似很简单，实则很多坑。
比如说打包代码时，涉及到隐私的.env文件不会被打包，所以部署vercel时，还需要在平台设置信任令牌。
比如说提交代码时，点击commit前，需要在message中填写修改内容。
比如说make中的update by和notion的兼容性问题。。定位这个逼问题真的把我逼疯了，整整一个下午，和Gemini反反复复检查，甚至Gemini都出现幻觉了，最后的最后，可算是定位到这个兼容性的逼问题上。太操蛋了。把我Gemini Pro额度都用光，操。
今日工作的一个小插曲是，构建make自动化流程时，我还和Gemini争论了一番。结果就是我输得一败涂地，然后理直气壮地用Gemini给的二次方案。
事情经过原委是这样的，我跟Gemini提了我的自动化需求，我在notion写文章，然后DeepSeek进行摘要总结，以便呈现在首页标题下，丰富首页信息流里的内容，并且选择了给到的make选项。Gemini根据我的需求，初步提的方案是make获取我notion上面的内容，然后过滤器选择AI Processing部分的内容，接着把获取的内容发送给DeepSeek进行摘要总结，然后返回信息，填入notion，再由网站抓取新内容进行发布。
我接受了这套方案，并且着手执行。过程中出现了bug，就是前文提到的那个update by的兼容性问题。Gemini在解决问题时发现了另一个问题，就是第二个notion节点之后，因为文章分段，会导致好几个文本内容，相当于把文章按照段落拆分成好几个部分给DeepSeek处理了。结果就是DeepSeek收到了好几个请求，然后返回好几个摘要。耗时耗力耗token。
这不是我想要的结果，但是我以为这是前置bug导致的。所以当我解决了前置bug时，我拒绝了Gemini提议的在第二个notion节点和http模块之间添加文本聚合器这一想法。
我啊，有时候还是太自以为是了。
跟Gemini一起干活时，自己的一些工程思维被Gemini夸了，也是收获了一波小确幸那般的迷之满足。人工智能的智商和情商也是可以很在线的嘛。
最后，完整拉通了make自动化流程，并且在初版方案上完善了许多许多，时间到了凌晨1点多。心满意足地躺被窝。大雨过后，原本40°C的广州甚至有了一丝凉意。
项目进度：