想用来写周报啊一些东西的，Github上搜了一下似乎都是偏科研的比较多。 感觉生成出来的句子还是很僵硬啊 3 个帖子 - 2 位参与者 阅读完整话题
上周的周报内容有点敏感，就没有更新。 新闻源：BBC NEWS 中文、FT中文网、法广RFI、36氪、虎嗅、爱范儿、少数派、人民日报、求是网、21世纪经济报道、央视新闻等 由AI对一天的新闻进行汇总分析，一周后再由AI分析一周的新闻并给出报告 时间范围：2026-05-24 ~ 2026-05-30 新闻there： 0524-0530.zip (554.9 KB) 1 个帖子 - 1 位参与者 阅读完整话题
本周主要围绕实时数字人链路的 Direct WebRTC 稳定性、AV 同步、空闲态数字人策略和语音上下文恢复展开。 fix：修复音画不同步 bug 之前版本存在一个问题，随着对话的持续进行，会逐渐出现音画不同步的情况。为了修复这个问题，这周认真啃了一下 WebRTC 协议。把这个问题搞清楚了。问题的原因比较复杂，总的来说主要是三个原因： 发送端 pacing 不稳定 turn 间 idle gap 处理错误 浏览器 receiver 状态跨 turn 残留 要搞懂这三个问题，必须先看一下 CyberVerse 是怎么发送音视频到前端的。在 cached_video 模式下，数字人说话是一轮一轮的；当数字人没有说话时，会播放提前生成的视频（所以叫 cached_video 模式）。整个视频流大概是这样： speaking -> idle -> speaking -> idle -> speaking 中间的停顿时长是不确定的，可能是几秒，也可能是几十秒。问题就出在这里：我用了同一个 Direct WebRTC media path 去承载一段一段的实时音视频，但这条 media path 的发送节奏、RTP 时间线和浏览器 receiver 状态，之前都更像是在按「连续直播流」来处理。 第一个原因是发送端 pacing 不稳定。之前服务端发布视频时使用的是「写一帧视频，然后 sleep 一个 frameDur 」的相对节奏。这个写法看起来简单，但每次写包、调度、sleep 都会产生误差，而且误差会在一个 session 内逐帧累积。更麻烦的是，音频 Opus 帧之前是按视频帧分组一起写出去的，没有按 20ms 的节奏平滑发送，实际效果就是跟着视频帧一组一组发送出去。浏览器收到的 arrival pattern 不均匀，视频 jitter buffer 会被逐渐拉大，最后表现为画面越来越落后于声音。 第二个原因是 speaking turn 之间的 RTP idle gap 处理不正确。两个 speaking turn 之间可能停顿 2S ，也可能停顿两分钟，但之前 RTP timestamp gap correction 最多只跳过 2 秒。对浏览器来说，这就变成了一个很异常的信号：真实网络到达时间已经过去很久，但 RTP media clock 只前进了 2 秒。浏览器的视频 jitter buffer 会把后续包当成严重异常的延迟流来处理， video_jb 被污染后，就会继续影响后面的播放。 第三个原因是浏览器 receiver 状态会跨 speaking turn 残留。前端从 WebRTC 画面切到 idle 视频，只是视觉层的切换，并不会重置 RTCPeerConnection 、receiver 或 jitter buffer 。也就是说，一旦某一轮 speaking turn 把视频 jitter buffer 拉高，后面几轮即使生成端已经恢复正常，也可能继续继承这个异常状态。这就是为什么日志里会看到某一轮开始明显漂移，后面几轮 JBDelta(window) 仍然保持很高。 一开始我尝试以 vibe coding 的方式来解决这个问题，但是 vibe 了整整一天都没搞定。因为音画不同是一件“主观”的判断，AI 感知不到这个事情。所以无论 AI 无论怎么进行逻辑推理，它都感知不到“不同步”。于是乎我想到了给整个链路添加监控，并且调研了一些方法来量化“音画同步“的差值。 Commit ad470a7 。有了真实的反馈指标后，AI 就有了调优的方向。 搞清楚原因，解决起来就简单了。 Commit 0ad5730 feat：新增 silent_inference 推理模式 CyberVerse 此前一直都是采用的 cached_video 模式，这种模式有一些好处：节省算力、对数字人的编排空间更大，用户可以使用更强大的视频生成模型来生成更好看的待机视频，而且可以生成很多很多。但这个模式也有一个不好的地方，就是整个人物不够连贯，不说话——>说话——>不说话，这个过程画面是有割裂的。所以我新增了 silent_inference 模式来解决这个问题。这个模型会一直进行推理，说话的时候用语音音频推理，不说话的时候用静音音频推理。不说话——>说话——>不说话，这个过程就会变得非常连贯。不会出现任何跳帧的情况。当然这个模式的缺点就是不说话时的画面会一直重复，而且这个画面是没有办法控制的，不管使用静音驱动还是随机噪音驱动，都不会有太大区别。 Commit 57512f7 fix：语音链路与上下文恢复 修复超时重连后上下文丢失的问题。qwen omni 模型有设置 5 分钟的超时连接，超过过后可以，再次发送文件进行唤醒。但是重连之后有个 bug：没有上一轮回话的上下文带上。 Commit 0e1c171 工程规范文档调整 补充 Truth-First Reasoning Rules 到 AGENTS.md / Claude.md ，用于抑制 AI 左右脑互搏的情况。详见： X 移除了 andrej-karpathy-skills 四个原则，听网友说这个提示词没有什么卵用，可能已经被官方吸纳了。 Commit e6788a8 祝大家周末愉快
要做私募净值产品的相关性分析，需要市场上所有私募的净值，如果没有日报的话周报也可以，佬们有什么办法吗？ 1 个帖子 - 1 位参与者 阅读完整话题
起因是我工作事项太多太杂，每次写周报都要翻聊天记录、翻邮件、翻脑子，花半小时还写得很痛苦。 所以我自己做了个桌面工具 rbtodo(之前发过一个帖子，这个是他的升级版。)，核心逻辑很简单： 平时随手把做的事记进去，支持文字、链接、截图。每天打开看今天要干什么，做完勾掉，没做完拖到明天。到了周五，一键把这周所有记录导出成 Markdown ，配上我调好的 Prompt ，直接丢给任何 AI ，几秒钟出周报，自己改一改发出去。 数据全部存本地，不上云，公司敏感内容也可以放心记。 现在还没正式发布，想先问问大家：你们平时写周报痛不痛苦？有没有类似的需求？ 做了个介绍页，感兴趣的可以看看： https://rbtodo.cornradio.org/ 如果觉得有用，可以留个邮箱，上线了第一时间通知：[https://forms.gle/yPdv3N7tNS9zgqFRA]
起因是我工作事项太多太杂，每次写周报都要翻聊天记录、翻邮件、翻脑子，花半小时还写得很痛苦。 所以我自己做了个桌面工具 rbtodo(之前发过一个帖子，这个是他的升级版。)，核心逻辑很简单： 平时随手把做的事记进去，支持文字、链接、截图。每天打开看今天要干什么，做完勾掉，没做完拖到明天。到了周五，一键把这周所有记录导出成 Markdown ，配上我调好的 Prompt ，直接丢给任何 AI ，几秒钟出周报，自己改一改发出去。 数据全部存本地，不上云，公司敏感内容也可以放心记。 现在还没正式发布，想先问问大家：你们平时写周报痛不痛苦？有没有类似的需求？ 做了个介绍页，感兴趣的可以看看： https://rbtodo.cornradio.org/ 如果觉得有用，可以留个邮箱，上线了第一时间通知：[https://forms.gle/yPdv3N7tNS9zgqFRA]
起因是我工作事项太多太杂，每次写周报都要翻聊天记录、翻邮件、翻脑子，花半小时还写得很痛苦。 所以我自己做了个桌面工具 rbtodo(之前发过一个帖子，这个是他的升级版。)，核心逻辑很简单： 平时随手把做的事记进去，支持文字、链接、截图。每天打开看今天要干什么，做完勾掉，没做完拖到明天。到了周五，一键把这周所有记录导出成 Markdown ，配上我调好的 Prompt ，直接丢给任何 AI ，几秒钟出周报，自己改一改发出去。 数据全部存本地，不上云，公司敏感内容也可以放心记。 现在还没正式发布，想先问问大家：你们平时写周报痛不痛苦？有没有类似的需求？ 做了个介绍页，感兴趣的可以看看： https://rbtodo.cornradio.org/ 如果觉得有用，可以留个邮箱，上线了第一时间通知：[https://forms.gle/yPdv3N7tNS9zgqFRA]
周报精品稿-2621.pdf (1022.2 KB) 1 个帖子 - 1 位参与者 阅读完整话题
现状：必须强制用AI，周报要体现提升效率，AI请求次数，代码百分百AI编程，让一个人顶两个人 思考：是不是公司要大幅度缩水员工了，请问元芳你怎么看？ 17 个帖子 - 11 位参与者 阅读完整话题
前两周因为考试，没时间搞周报，趁周末把前面的补上 新闻源：BBC NEWS 中文、FT中文网、法广RFI、36氪、虎嗅、爱范儿、少数派、人民日报、求是网、21世纪经济报道、央视新闻等 由AI对一天的新闻进行汇总分析，一周后再由AI分析一周的新闻并给出报告 时间范围：2026-05-03 ~ 2026-05-16 两周的日报都在这了： 0503-0516.zip (617.6 KB) 1 个帖子 - 1 位参与者 阅读完整话题
Tips:安装到全局就成～～ 地址： https://github.com/umlink/daily-report-skill [我今天做了什么？，我这周做了什么？，我这个月做了什么？....] Daily Report 程序员工作报告生成 Skill 。基于本地 Git 仓库的 commit 数据，自动生成中文工作日报、周报、季度总结、年度总结，并可推送到企业微信。 功能 多周期报告 — 日报、周报、季度总结、年度总结 自定义时间范围 — 支持指定任意起止日期 自动扫描 Git 仓库 — 递归发现工作目录下的所有 Git 项目 Commit 智能分类 — 按 conventional-commit 类型自动归类（ feat 、 fix 、 refactor 等） 遗留变更检测 — 识别超过 N 天未提交的文件并单独提醒 企业微信推送 — 一键将报告发送到企业微信群 使用方式 在 Claude Code 中直接用自然语言触发： 生成日报 写周报 Q2 总结 年度总结 今天干了什么 推送日报到企业微信 Skill 会自动采集 Git 数据、分析归纳、生成 Markdown 报告。 配置说明 编辑 scripts/config.json ： { "workspaceDirs": ["/Users/yourname/projects"], "authorEmails": [], "scan": { "maxDepth": 4, "maxRepos": 100 }, "report": { "showBranch": false, "showDate": true, "staleMaxAge": 3 }, "wechatWork": { "enabled": false, "webhookUrl": "", "mentionAll": false } } 配置项 字段 说明 默认值 workspaceDirs 要扫描的目录列表， 必填 [] authorEmails 按邮箱过滤 commit ，留空则使用 git 全局 user.email [] scan.maxDepth 目录扫描深度 4 scan.maxRepos 最多扫描仓库数 100 ignore.dirs 扫描时跳过的目录名 node_modules 、.git 等 report.showBranch 报告中是否显示分支名 false report.showDate 每条内容是否附加日期 true report.staleMaxAge 未提交文件超过此天数视为"遗留变更"， 0 禁用 3 wechatWork.enabled 是否启用企业微信推送 false wechatWork.webhookUrl 企业微信机器人 Webhook 地址 "" wechatWork.mentionAll 推送时是否 @所有人 false 工作原理 用户触发 → 采集 Git 数据（ JS 脚本） → Claude 分析归纳 → 生成 Markdown 报告 → 可选推送企业微信 脚本负责 事实采集 （ Git log 解析、仓库发现、遗留检测），Claude 负责 分析归纳 （ commit 分类、内容合并、报告润色）。 报告类型 触发方式 周期 输出 "日报"、"今天干了什么" 日报 完成内容、问题修复、技术优化、进行中工作、遗留变更 "周报"、"这周做了什么" 周报 同上，按天合并归纳 "Q1/Q2/Q3/Q4"、"季度总结" 季度 重点项目与成果、问题与解决、技术优化与基建 "年度总结"、"今年做了什么" 年度 年度重点项目、技术成长与基建、问题与反思 "从 X 月到 Y 月" 自定义 根据时间跨度自动选择合适模板 常见问题 问题 解决方法 找不到 git 命令 确认已安装 Git ，终端运行 git --version 验证 WORKSPACE_REQUIRED 在 config.json 中配置 workspaceDirs ，或使用 --workspace 参数 RISKY_WORKSPACE 不能扫描根目录（ / 、 C:\ ），请指定具体项目文件夹 报告为空 检查指定时间范围内是否有 commit 记录 目录结构 daily-report/ ├── SKILL.md # Skill 定义（ Claude Code 读取） ├── README.md # 本文件 └── scripts/ ├── config.json # 用户配置 └── daily-report.js # 数据采集与推送脚本
IT之家 5 月 8 日消息，科技媒体 Android Authority 昨日（5 月 7 日）发布博文，通过挖掘 One UI 9 早期固件版本代码， 发现三星正在开发名为 Driving Insights 的应用，通过 AI 分析用户驾驶行为。 基于代码描述，Driving Insights 应用帮助用户直观查看其驾驶习惯和模式，进而培养更好的驾驶习惯。 代码字符串显示，应用通过手机传感器，结合精确位置追踪与 AI 算法， 可追踪加速速度、转弯角度、刹车力度等数据。 该应用还支持生成周报，通过三星的 Now Brief 功能推送。IT之家援引博文介绍，报告会给出类似这样的反馈： “本周你的驾驶风格偏向保守，平稳且谨慎，请继续保持！” “本周你的驾驶呈现动态模式，尝试保持速度和转向平稳一致”。 长途驾驶后，报告会提醒“本周长途驾驶较多，注意防止疲劳驾驶，适时休息”。 技术实现上，Driving Insights 支持蓝牙自动触发。手机连接车载蓝牙后，应用自动开始记录行程。用户可查看历史行程记录，并按时间或距离筛选。泄露的截图展示了应用的开屏引导、设置界面、行程历史和权限请求页面。
5月4日消息，贾跃亭发布FF第53期业务周报，披露旗下EAI机器人业务最新进展。数据显示，4月EAI机器人出货46台，累计出货达68台且单品正毛利交付。目前计划5月加快交付节奏，冲刺首期交付季200台目标。 贾跃亭表示，巴菲特股东大会期间，将与BIBS波士顿国际商学院，联合成立AI及机器人研究院，并与加州大学洛杉矶分校展开对接，布局全美校园合作、机器人采购及EAI 教育夏令营，搭建规模化AI教育生态体系。 此外，FF EAI桥梁战略获《华尔街日报》认可，被评价为衔接全球 EAI 产业、AI技术与用户价值的重要发展路径。 公开信息显示，EAI机器人是法拉第未来（FF）推出的具身智能机器人产品线 。 法拉第未来于2026年1月8日宣布进军该领域，2026年2月5日发布了Futurist、Master、Aegis三大系列EAI机器人产品线。 据介绍，公司为该业务设定了三年内实现经营性现金流为正、毛利率达20%的目标。 查看评论
如题，有病，真的，我们大小周，上周是小周，才写了汇报的东西，实实在在想不明白才过了 4 天有什么东西好写的，能写到万字…还必须今天交 只能让 ai 瞎编了，哈哈 1 个帖子 - 1 位参与者 阅读完整话题
从 【picpi 皮皮工艺站】运营周报，和让更多人都有机会，决定收集一些佬友的建议。 继续。 工艺站主贴： 【picpi 皮皮公益站】主要自用 小规模开放 codex可用 工艺站续订方式更新 目前已经开始实施订阅续费使用LDC购买。 发放规则 号池每多 1 个账号就发放 $3/周 的有效订阅的。 例如：号池有100个账号，那么只售卖总额就是 $300/周 。 例如有 $100/周 和 $200/周 这两个商品。 卖法就有两种： $100/周 1个 + $200/周 1个 $100/周 3个。 售卖总额不超过 $300/周 绝不超卖 。 监控站: https://look.picpi.top/ 小店链接 ldc.picpi.top Picpi的小店 皮皮的小店 10 个帖子 - 9 位参与者 阅读完整话题
我想推荐一个我最近做的飞书 CLI Skill：lark-retro GitHub： https://github.com/gkzzhs/lark-retro 它的目标很简单：用一句话生成飞书工作复盘 / 周报。 比如你只要对 AI Agent 说： > 帮我做一下上周的回顾 它就会自动通过飞书 CLI 读取日历、会议纪要/会议记录、任务、消息、文档等数据，整理成一份结构化复盘报告，并写入飞书文档。还可以继续创建行动项任务、追踪上期行动项、归档到知识库或 Bitable ，甚至预约下一次回顾会议室。 我做这个 Skill 的原因是，写周报和复盘最麻烦的地方不是“写”，而是到处找材料：翻日历、翻群聊、找任务、找上期报告。lark-retro 希望把这些零散的工作痕迹串起来，让 AI Agent 真正基于飞书里的真实数据来生成报告，而不是凭空写一篇看起来很像周报的文字。 目前它已经适配到 lark-cli v1.0.21 ，支持一些比较新的能力，比如： - 会议纪要 / 会议记录分析 - OKR 对齐和进展记录分析 - 审批阻塞信号补强 - 历史回顾文档搜索和权限申请补救 - 群消息 @ 提及过滤 - Bitable 行动项归档和记录分享链接 - 多会议室名称查找、日程搜索、下期回顾预约和更新 - 知识库归档、报告文件夹和快捷方式管理 我也把真实测试记录写在仓库里了，包括哪些能力完整跑通过，哪些能力只是做了权限或边界验证，避免只写 README 不实测。 如果你也经常写周报、Sprint Retro 、项目复盘，或者想看看飞书 CLI Skill 能把一个办公流程做到什么程度，可以试试这个项目： https://github.com/gkzzhs/lark-retro
主贴： 【picpi 皮皮公益站】主要自用 小规模开放 codex可用 目前运营状况 距离上次的发放邀请码已经过去大概一周了，目前服务器压力并不大，号池非常健康。但是奥特曼总是会时不时搞一些动作，所以我目前暂时决定，保留一半余量用于应对突发状况。暂时还是保持200人的规模。 之前注册的号依然都建在，一个都没挂，我的养号方法还是非常nice的，我再多观察几周，如果依然很稳定，我就打算开始扩大规模。计划采购一台8h16G服务器专用于养号，预计号池可以扩大到10000的规模。 号池的具体状况可以看监控站： https://look.picpi.top/ 计划中的运营方法 只是计划，并不一定实施，待我和各位老友充分讨论之后，再做决定。 需要改用更好订阅的分配方式 目前的问题 之前的运营方式是只要获得本站的邀请码就可以永久使用 每周100刀 的订阅，不做任何活跃打卡要求。这就导致了几个问题，很多人注册之后占用了名额并没有充分使用，需要使用的人却进不来。 出现了账号交易，因为新版sub2api可以解绑 linuxdo和更改绑定邮箱了，这使交易我的工艺站账号变得更加容易。 解决方式（待定） 把基于用户数量的限制改为基于可用订阅的限制。也就是说，每30个openai账号分配一个100刀每周的订阅。 新用户注册默认订阅时间改为1个月。 订阅续费使用LDC购买，让大家攒攒就能买到，这样就不用去二手平台交易了。 15 个帖子 - 15 位参与者 阅读完整话题