1. 一份AI日报的诞生从信息洪流到结构化认知每天早上七点我的手机闹钟还没响RSS阅读器里已经堆了三百多条更新。arXiv上新增了四十多篇论文Hacker News首页换了三轮几个技术群里的讨论从凌晨两点就没停过。这就是做AI日报最真实的起点——你面对的不是信息匮乏而是信息过载。我做了快两年的AI日报从最开始的手忙脚乱到现在的流程化操作中间踩过的坑足够写一本避坑指南。今天这篇内容就是把这套流程完整拆开从信息采集、筛选、加工到最终成稿每一步都讲清楚背后的逻辑和实操细节。AI日报这个东西本质上解决的是一个很具体的问题在AI领域信息更新速度远超个人消化能力的当下如何用最低的时间成本获取最高密度的有效信息。它适合几类人一是需要持续跟踪技术动态的开发者二是做技术决策的管理者三是刚入行想快速建立认知框架的新人。不同的人对日报的期待不一样开发者想看代码和模型细节管理者想看趋势和影响新人想看概念和脉络。一份好的日报需要在有限篇幅里同时照顾到这些需求这本身就是个设计难题。我目前维护的日报覆盖三个板块论文速览、工具推荐、行业动态。每个板块的筛选标准和呈现方式都不一样后面会逐一展开。整个流程从早上六点半开始到八点前完成发布中间大概九十分钟。这九十分钟里真正花在“写”上的时间不到三十分钟剩下六十分钟都在做信息筛选和验证。这个时间分配很关键很多人做日报失败就是因为把大部分精力花在了写作上而忽略了前端的信息质量控制。2. 信息采集体系搭建源头决定质量上限2.1 核心信息源的分类与取舍做日报的第一步不是写是建信息源。我试过大概四十多个信息渠道最后稳定在用的只有十二个。这个筛选过程很痛苦但必须做。信息源可以分成四类论文预印本、技术社区、官方公告、个人博客。每一类的价值和时效性完全不同需要区别对待。论文预印本主要看arXiv但arXiv每天新增的AI相关论文超过两百篇全看是不可能的。我的做法是按分类订阅cs.AI、cs.CL、cs.CV、cs.LG这四个是必看的其他分类按需。订阅方式用arXiv的RSS配合关键词过滤。关键词列表我维护了大概三十个包括模型架构、训练方法、应用场景三个维度。比如“transformer”“diffusion”“RLHF”“agent”“multimodal”这些是架构层面的“fine-tuning”“prompt engineering”“quantization”这些是方法层面的“code generation”“medical imaging”“autonomous driving”这些是应用层面的。关键词过滤能把两百篇降到三十篇左右再人工扫一遍标题和摘要最后选出五到八篇值得展开的。技术社区我主要看Hacker News和Reddit的MachineLearning板块。HN的好处是讨论质量高一个帖子下面经常有作者本人出来回应能拿到论文里没写的细节。Reddit的ML板块更偏实践经常有人分享复现结果和踩坑经验。这两个地方的信息有个特点时效性极强但噪音也大。我的筛选标准是看评论数和投票数的比值比值高的说明争议大或者信息量大值得点进去看。另外就是看发帖人的历史记录如果是长期活跃的账号可信度会高很多。官方公告这块主要是各大AI公司的博客和更新日志。OpenAI、Anthropic、Google DeepMind、Meta AI这几家的博客我是每天必刷的。它们的更新频率不高但每次更新都是重磅。我一般用Feedly订阅设置成每天推送一次。这里有个小技巧不要只看标题要点进去看正文里的“whats new”部分很多重要更新藏在细节里。比如某次API更新标题只写了“性能提升”但正文里提到支持了新的结构化输出格式这个对开发者来说就是大新闻。个人博客是最容易被忽略但价值最高的信息源。我固定跟踪大概十五个研究者的博客包括一些知名教授和一线工程师。他们的更新频率很低可能一个月才一篇但每篇都是深度长文信息密度远超新闻稿。我用的工具是Inoreader可以设置成有新文章时邮件提醒。这里要注意的是个人博客的观点往往带有强烈的个人倾向引用的时候需要交叉验证不能直接当事实用。2.2 采集工具链的配置与自动化信息源确定之后下一步是自动化采集。我用的工具链是Feedly Inoreader RSSHub 一个自己写的Python脚本。Feedly负责主流媒体的订阅Inoreader负责个人博客和 newslettersRSSHub用来把没有RSS的网站转成RSSPython脚本负责去重和初步分类。去重是个大问题。同一个新闻可能在HN、Reddit、Twitter上同时出现如果不做去重日报里会出现重复内容。我的做法是用标题的SimHash做相似度计算阈值设在0.85超过这个值就认为是重复的。SimHash的好处是计算快对长文本的局部修改不敏感。具体实现是用jieba分词然后对每个词做哈希加权求和最后降维成64位指纹。两个指纹的汉明距离小于3就判定为重复。这个阈值是我试了大概二十次之后定下来的太低会漏掉真正的重复太高会把相关但不重复的内容误杀。初步分类用的是关键词匹配加规则引擎。比如标题里出现“model”“architecture”“training”就归到论文类出现“tool”“library”“framework”就归到工具类出现“funding”“acquisition”“partnership”就归到行业类。这个分类准确率大概在八成左右剩下的两成需要人工调整。我试过用机器学习做分类但训练数据太少效果还不如规则引擎稳定。所以现阶段还是规则为主人工为辅。采集频率是每三十分钟跑一次从早上六点到晚上十二点。这个频率是根据信息源的更新规律定的。arXiv的更新集中在美东时间下午和晚上HN的更新全天都有但高峰在上午个人博客的更新随机性最大。三十分钟的间隔基本能保证不漏掉重要更新同时也不会因为太频繁而浪费资源。采集到的原始数据会存到本地的SQLite数据库里字段包括标题、链接、来源、时间戳、摘要、分类标签。这个数据库是后面所有加工的基础。2.3 信息源的动态维护策略信息源不是一成不变的。我每个月会做一次信息源审查主要看三个指标命中率、时效性、独特性。命中率是指这个源提供的信息最终被日报采用的比例低于5%的源会被降级或移除。时效性是指从信息发布到被采集到的时间差超过两小时的源会检查是不是RSS配置有问题。独特性是指这个源提供的信息在其他源里是否也能找到如果重复率超过80%说明这个源的可替代性很强可以考虑移除。过去半年我移除了七个源新增了五个。移除的原因主要是更新频率下降或者内容质量下滑。比如某个之前很活跃的博客作者可能因为工作变动停更了三个月这种就会先移到“观察区”如果再过一个月还没更新就彻底移除。新增的源主要来自读者推荐和同行交流。我有个习惯每次看到一篇特别好的文章都会去看作者还写了什么如果整体质量稳定就会把作者的博客加到订阅列表里。这里有个经验不要盲目追求信息源的数量。我见过有人订阅了两百多个源结果每天光是扫标题就要花两个小时真正消化的时间反而没了。信息源的质量远比数量重要。我现在稳定在十二个核心源加二十个辅助源核心源每天必看辅助源每周扫一次。这个配置下每天的有效信息量大概在五十到八十条之间经过筛选后进入日报的通常是十到十五条。这个比例是健康的说明筛选在起作用。3. 内容筛选与价值判断什么值得写进日报3.1 论文筛选的四维评估框架论文是AI日报里最硬核的部分也是最难筛选的部分。我用的是一套四维评估框架创新性、实用性、可复现性、影响力。每个维度打分一到五分总分低于十二分的直接淘汰十二到十五分的作为备选十五分以上的重点展开。创新性主要看两点一是解决的问题是不是新的二是方法是不是新的。如果两个都是新的直接给五分。如果问题老但方法新给四分。如果方法老但问题新给三分。如果都是老的除非有特别大的改进否则给两分以下。这个判断需要一定的领域知识我一般会快速扫一下related work部分看看作者自己怎么定位的。如果作者说“据我们所知这是第一个……”那创新性基本可以给高分但也要警惕过度声称。实用性看的是这个方法能不能落地。有些论文理论很漂亮但需要巨大的计算资源或者特殊的数据集这种实用性就低。我一般看实验部分用的硬件配置和数据集大小。如果是在八个A100上跑的实用性给三分如果是单卡就能复现的给四分如果还提供了预训练模型和推理代码给五分。这个维度对开发者读者特别重要他们最关心的就是“我能不能用上”。可复现性看的是代码和数据的开放程度。完全开源的给五分只开放部分代码的给三分完全不开源的给一分。这里有个坑有些论文说“代码将在接收后开放”这种基本等于不开源因为接收周期可能长达半年。我一般只认已经挂在GitHub上的代码而且会快速扫一眼issue区看看有没有人反馈跑不通。如果issue区一片哀嚎可复现性直接降到两分。影响力看的是这个工作可能产生的影响范围。如果是一个全新范式的提出给五分如果是现有范式的重要改进给四分如果是增量式改进给三分如果是特定场景的优化给两分。这个维度最难判断因为影响力需要时间验证。我的做法是看作者团队和引用情况。如果是知名实验室的工作影响力预期会高一些如果是新团队但引用了大量前沿工作也会给高分。另外就是看社交媒体上的讨论热度如果HN上已经有几百条评论说明社区关注度高影响力可以加分。3.2 工具推荐的筛选标准与验证流程工具推荐是日报里最受欢迎的部分因为直接可用。但工具推荐的坑也最多最大的坑就是推荐了一个自己没用过的工具结果读者反馈一堆问题。所以我的原则是不亲自跑一遍的工具绝对不写进日报。验证流程分三步安装、核心功能测试、边界情况测试。安装这一步就能筛掉很多工具。有些工具文档写得天花乱坠结果pip install直接报错或者依赖冲突解决不了。这种直接淘汰不管功能多诱人。核心功能测试是跑一遍官方文档里的quick start看看能不能在十分钟内出结果。如果十分钟搞不定说明上手门槛太高不适合推荐给日报读者。边界情况测试是故意输入一些奇怪的数据看看工具会不会崩溃或者给出离谱的结果。这一步能发现很多文档里没写的限制。我目前维护了一个工具库大概有六十多个经过验证的工具按类别分数据处理、模型训练、推理部署、可视化、自动化。每次日报从里面选一个还没推荐过的或者选一个最近有重大更新的。推荐的时候会写清楚适用场景、上手难度、资源需求、替代方案。比如推荐一个推理框架会说明它在什么硬件上表现最好和ONNX Runtime比有什么优劣适合什么规模的模型。这些信息都是实测出来的不是抄文档。这里有个经验不要推荐需要复杂配置的工具。我试过推荐一个需要自己编译CUDA kernel的工具结果评论区一半人在问编译错误。后来我定了个规矩如果安装步骤超过五步或者需要手动编译就不在日报里推荐最多在附注里提一句。日报的读者是来快速获取信息的不是来折腾环境的。工具推荐的价值在于“开箱即用”不是“展示技术深度”。3.3 行业动态的取舍逻辑与信息验证行业动态这部分最容易写也最容易写砸。因为新闻稿往往带有公关色彩直接翻译过来就是给公司做宣传。我的做法是只写有实质信息量的动态不写纯公关稿。什么叫实质信息量比如融资新闻如果只写“某公司获得X轮融资”这个信息量很低因为融资不代表产品好。但如果融资稿里提到了具体的资金用途、技术路线、客户案例这些就是实质信息。我会把这些细节提取出来再结合公开信息做交叉验证。比如公司说“我们的技术领先行业”我会去查他们的论文发表情况、专利情况、开源项目活跃度看看这个说法有没有支撑。产品更新也是类似。如果只是“我们发布了新版本”这个不值得写。但如果更新日志里提到了具体的性能提升数据、新的API接口、支持的模型列表这些就值得展开。我一般会对比上一个版本看看变化在哪里然后判断这个变化对用户的实际影响。比如某个API从支持4K上下文扩展到32K这个对做长文档处理的开发者就是重大利好值得写清楚。行业动态的另一个坑是信息验证。AI领域的新闻经常有反转今天说某公司要发布新模型明天就被辟谣。我的做法是只写已经确认的信息不写传闻。确认的标准是官方渠道发布或者多个独立信源交叉验证。如果只有一家媒体报道我会先放一放等第二天看看有没有跟进。这个策略会漏掉一些独家新闻但能保证日报的可信度。做了两年日报的纠错率控制在2%以下这个代价是值得的。4. 日报撰写与结构化呈现让信息更易消化4.1 标题撰写的技巧与禁忌日报的标题决定了读者会不会点进来。我试过很多种标题风格最后稳定在“核心事件 关键数据 影响范围”这个结构。比如“某模型在MMLU上提升5个百分点推理成本降低40%”这个标题里有事件、有数据、有影响读者一眼就能判断跟自己有没有关系。标题的禁忌有几个一是不用夸张词汇比如“震撼”“颠覆”“史上最强”这些词用多了会透支信任。二是不用模糊表述比如“某公司发布重要更新”什么叫重要读者没法判断。三是不用问句比如“AI会取代程序员吗”这种标题在日报里显得很水。四是不超过三十个字太长了在手机上看不全。我有个习惯写完标题之后会问自己如果我只看到这个标题能不能判断这条信息对我有没有用如果答案是否定的就重写。这个标准看起来简单但执行起来很考验对读者需求的理解。比如同样是模型更新对开发者来说“支持动态批处理”比“性能提升30%”更有吸引力因为前者是具体功能后者是抽象指标。所以标题要根据目标读者的关注点来调整。4.2 正文结构的标准化模板日报的每一条内容都遵循一个标准结构一句话摘要、核心要点、详细说明、参考链接。这个结构看起来简单但每个部分都有讲究。一句话摘要是用一句话说清楚这条信息是什么。这句话要包含主语、动作、结果。比如“某团队发布了一个新的注意力机制在长序列任务上比标准Transformer快三倍”。这句话里有谁、做了什么、结果如何读者看完就知道要不要继续读。核心要点是用三到五个 bullet point 列出最关键的信息。这些要点要具体不能是“性能很好”这种空话。比如“在PG-19数据集上困惑度从18.3降到15.7”“推理速度在A100上达到每秒1200个token”“代码已开源支持PyTorch和JAX”。这些数字和事实是读者最需要的。详细说明是对核心要点的展开一般控制在两百字以内。这部分会解释技术细节、实验设置、局限性。比如会说明“这个改进主要来自对注意力矩阵的稀疏化处理但在短序列任务上优势不明显”。这种诚实的表述比一味吹捧更有价值读者能从中判断这个方法适不适合自己的场景。参考链接放在最后包括论文链接、代码仓库、官方博客。链接要确保可访问我一般会提前点一遍避免出现404。如果是arXiv链接会优先用abs页面而不是pdf因为abs页面加载更快而且能看到摘要和引用信息。4.3 排版与可读性优化日报的排版直接影响阅读体验。我用的工具是Markdown因为兼容性好在各种平台上都能正常显示。排版的原则是层次分明、重点突出、留白充足。层次分明靠的是标题层级和分隔线。每个板块用二级标题每条内容用三级标题板块之间用分隔线隔开。这样读者扫一眼就能知道今天有哪些内容快速定位到自己感兴趣的板块。重点突出靠的是加粗和引用块。关键数据、核心结论用加粗注意事项、避坑提示用引用块。但加粗不能滥用一条内容里加粗不超过三处否则就失去了强调的意义。引用块也要克制一般只在有重要提醒的时候用。留白充足靠的是段落长度控制。每段不超过四行段与段之间空一行。这个规则在手机上看特别重要大段文字在手机上就是灾难。我试过把一段拆成三段阅读完成率提升了大概两成。另外就是列表的使用要点用无序列表步骤用有序列表但列表项不超过七条太多了读者会失去耐心。5. 常见问题与排查技巧实录5.1 信息源失效的排查与替代方案信息源失效是做日报最常见的问题。表现是RSS不再更新、网页改版导致抓取失败、API接口变更。排查的第一步是确认是源的问题还是工具的问题。我会先用浏览器直接访问源站看看有没有新内容。如果有新内容但RSS没更新说明是RSS的问题可能是feed地址变了或者格式变了。如果浏览器也打不开说明是源站本身的问题可能是服务器挂了或者域名换了。RSS地址变更的排查方法是看网页源代码里的link标签一般会有relalternate typeapplication/rssxml的声明。如果找不到就试试常见的feed路径/feed、/rss、/atom.xml。还不行就用RSSHub的通用规则试试或者用Feed43这类工具自己生成。源站挂了的替代方案是找镜像或者缓存。比如arXiv有多个镜像站一个挂了可以换另一个。个人博客挂了可以试试Wayback Machine虽然有时效性延迟但总比没有好。如果源站彻底消失就要找替代源。替代源的寻找方法是看这个源经常引用谁或者谁经常引用这个源顺着引用关系找同类源。这里有个经验不要依赖单一源。我每个类别至少有两个源一个主源一个备源。主源挂了立刻切备源保证日报不断更。备源的更新频率可以低一些但内容质量要过关。这个策略让我在过去一年里没有因为源的问题断更过。5.2 内容重复与信息冲突的处理内容重复有两种情况同一事件在不同源出现同一源在不同时间出现。第一种情况用SimHash去重就能解决第二种情况需要设置时间窗口。我的做法是同一源的内容如果标题相似度超过0.9且时间间隔小于24小时就认为是重复只保留最新的。这个规则能过滤掉大部分重复更新。信息冲突更麻烦。比如两个源对同一事件的描述不一致一个说融资一亿一个说融资八千万。处理方法是优先采信官方源如果没有官方源就采信历史准确率高的源。如果两个源的历史准确率差不多就在日报里注明“有报道称”并列出不同说法。这种处理方式虽然不够干脆但比选一个错误的数字要好。还有一种冲突是观点冲突。比如一个源说某个方法好另一个源说这个方法有问题。这种冲突不一定要解决可以并列呈现。我会把两边的核心论据都列出来让读者自己判断。这种处理方式在技术社区里很受欢迎因为读者往往有自己的判断力不需要日报替他们做决定。5.3 时间管理与发布节奏控制做日报最大的挑战是时间管理。我试过几种节奏每天早上集中做两小时或者分散到全天随时更新。最后发现最稳定的是早上集中做因为早上的信息经过一夜的沉淀质量更高而且读者的阅读高峰也在早上。具体的时间分配是六点半到七点采集和初筛七点到七点半精读和验证七点半到八点撰写和排版八点发布。这个节奏跑了半年基本没出过问题。关键是要把采集和初筛自动化把时间留给精读和验证。如果采集也要手动做那两小时根本不够。发布节奏的控制也很重要。我固定在早上八点发布不早不晚。早了读者还没起床晚了读者已经在忙工作了。周末的日报会精简一些因为周末的信息量本来就少而且读者也不希望周末被大量信息轰炸。节假日的处理类似但会提前发个通知告诉读者日报会暂停或者精简。这里有个经验不要追求每天都有重磅内容。AI领域不是每天都有大新闻有时候一天下来就是些小更新。这种时候日报可以短一些但质量不能降。我试过为了凑篇幅把不重要的事情写得很长结果读者反馈很差。后来就定了个规矩宁可短不可水。现在日报的长度在八百到两千字之间浮动完全取决于当天的信息量。6. 工具链与自动化脚本参考6.1 核心工具清单与配置要点我的工具链不复杂但每个工具都经过长期使用验证。Feedly用于主流媒体订阅优点是界面友好、移动端体验好缺点是免费版有广告。Inoreader用于个人博客和newsletter优点是过滤规则强大、支持全文抓取缺点是免费版有数量限制。RSSHub用于生成没有RSS的网站的feed优点是规则丰富、社区活跃缺点是需要自己部署有一定的维护成本。Python脚本是整个流程的粘合剂。主要做三件事从Feedly和Inoreader的API拉取数据、去重和分类、写入SQLite数据库。脚本大概三百行用了feedparser、jieba、simhash这几个库。部署在一台旧笔记本上用cron定时执行。这台笔记本常年开机功耗大概十五瓦一个月电费不到十块钱。数据库用的是SQLite因为够用。表结构很简单id、title、link、source、timestamp、summary、category、hash。索引建在timestamp和category上查询速度很快。数据保留三个月超过三个月的自动归档到另一个表需要的时候再查。6.2 自动化脚本的关键代码解析去重部分的代码是核心。先用feedparser解析RSS提取标题和摘要然后用jieba分词去掉停用词对剩下的词做哈希。哈希用Python内置的hash函数虽然简单但够用。然后加权求和权重用词频的倒数这样高频词的影响会降低。最后降维成64位指纹用汉明距离比较。分类部分的代码用规则引擎。规则写在YAML文件里方便修改。每条规则包括关键词列表和对应的分类标签。匹配的时候用any逻辑只要标题或摘要里出现任何一个关键词就归到对应的分类。规则之间有优先级论文类的优先级最高工具类次之行业类最低。这样能保证重要的内容不会被误分类。写入数据库之前会做一次去重检查用SimHash的汉明距离。如果距离小于3就认为是重复跳过不写。这个检查在数据库层面也做了一次用hash字段的唯一索引。双重保险确保不会出现重复数据。6.3 人工干预的时机与方式自动化能解决八成的问题剩下两成需要人工干预。干预的时机主要有三个分类错误、去重误杀、源失效。分类错误的表现是论文被归到工具类或者工具被归到行业类。这种时候我会手动修改数据库里的category字段同时检查规则文件看看是不是关键词需要调整。去重误杀的表现是两条不同的内容被判定为重复。这种时候我会手动把被误杀的那条重新插入数据库同时调整SimHash的阈值。阈值调整要谨慎调低了会漏掉真正的重复调高了会误杀。我一般一次调0.01观察几天再决定要不要继续调。源失效的表现是某个源连续两天没有新内容。这种时候我会手动检查源站确认是源的问题还是工具的问题。如果是源的问题就找替代源如果是工具的问题就修配置。修完之后会手动触发一次采集确认恢复正常。人工干预的原则是能自动化就自动化不能自动化就标准化。标准化是指把干预的流程写下来每次按流程操作避免凭感觉。比如修改分类的流程是确认错误、修改数据库、检查规则、记录日志。这个流程看起来繁琐但能保证每次干预都是有效的不会引入新的问题。7. 读者反馈与迭代优化7.1 反馈渠道的建立与维护日报发布之后读者的反馈是最宝贵的改进依据。我建立了三个反馈渠道评论区、邮件、问卷。评论区是最直接的读者会在下面留言说哪条写得好、哪条有问题。邮件更正式一些适合长篇反馈。问卷每季度发一次收集结构化的意见。评论区的反馈我会每天看但不会每条都回。回复的原则是事实错误必回观点分歧选回情绪发泄不回。事实错误是指日报里写错了数字或者链接这种必须立刻更正并致谢。观点分歧是指读者对某条信息的解读不同这种如果言之有物就回复讨论如果只是抬杠就忽略。情绪发泄是指纯粹的负面情绪没有具体内容这种不回复但会记录下来看看是不是普遍问题。邮件的反馈处理周期长一些一般攒到周末统一回。问卷的结果会做统计分析看看哪些板块受欢迎、哪些需要改进。过去一年的问卷显示工具推荐板块的满意度最高论文速览板块的满意度最低主要问题是太专业、看不懂。针对这个问题我在论文速览里增加了“一句话总结”和“为什么重要”两个部分用更通俗的语言解释论文的价值。改版之后论文板块的满意度提升了大概一成五。7.2 内容迭代的方向与节奏内容迭代不是拍脑袋决定的要有数据支撑。我主要看三个指标阅读完成率、分享率、反馈率。阅读完成率低说明内容太长或者太枯燥分享率高说明内容有价值反馈率高说明读者有参与感。这三个指标结合起来看能判断出内容的质量和读者的满意度。迭代的节奏是每月一次小调整每季度一次大调整。小调整包括调整板块顺序、优化标题写法、增减关键词。大调整包括增加新板块、砍掉旧板块、改变整体风格。大调整之前会先做小范围测试比如在邮件列表里发个预览版看看反馈再决定要不要全面推行。过去半年做过几次重要的迭代。一次是增加了“本周回顾”板块把一周的重要信息串起来帮助读者建立整体认知。这个板块的阅读完成率很高说明读者需要这种总结性的内容。另一次是砍掉了“融资快讯”板块因为信息量太低而且容易变成公关稿。砍掉之后读者的反馈是“清爽了很多”说明这个决定是对的。7.3 长期维护的动力与可持续性做日报最大的挑战不是技术是坚持。每天都要做没有周末没有节假日这种强度很容易让人放弃。我能坚持两年靠的是几个习惯。一是把日报当成学习工具而不是输出任务。每天看论文、试工具、写总结这个过程本身就在提升自己。二是建立反馈循环读者的正面反馈是很大的动力。三是控制预期不追求完美允许自己偶尔水一天。可持续性的另一个关键是分工。我一个人做所有事情但有些环节可以外包或者自动化。比如排版可以用模板采集可以用脚本校对可以找朋友帮忙。把精力集中在最有价值的环节上比如筛选和验证其他环节能省则省。这个策略让我在保持质量的同时把每天的时间投入控制在一个半小时以内。最后分享一个小技巧建立一个“灵感库”。平时看到好的标题、好的表达、好的结构就随手记下来。写日报的时候从里面找参考能省很多时间。这个灵感库我用Notion维护大概有三百多条记录分标题、开头、结尾、过渡几个类别。每次写日报之前扫一眼找找感觉效果很好。