8月31日2026 · 星期一

@GitHub_Daily

想动手微调个大模型，一查显存要求就凉了，仅 4 GB 的显卡按说连模型都装不进去。 偶然发现 Soup，把基座模型放在内存里，训练时一层一层轮流搬进显卡，显存里始终只装当前这一层。 靠这个办法，4 GB 显存的笔记本显卡也能微调 80 亿参数的模型，实测显存峰值 3.32 GB，训练结果和正常跑出来的一模一样。 GitHub：http://github.com/MakazhanAlpamys/Soup 用起来就一份配置文件加一条命令，批大小、模型压缩方式这些参数全自动配好，也不用远程登录什么服务器。 作者还放了个免费的 Colab 笔记本，谁都能跑一遍验证这事是真的，这点挺实诚。 拿自己的数据调个专属小模型，现在一台游戏本就够了。

@dotey

如今 Vibe Coding 盛行，然而就算是用 AI 写代码，也少不了要考虑如何划分好模块、保障低模块之间耦合以及系统的拓展性。 如何划分好模块这些事是传统软件工程和架构设计范畴，但你做好了的话，AI 生成的代码质量更高系统也更稳定。 很多新手对于如何划分模块并没有什么概念，甚至很多编程老手也只是直觉知道怎么分，但也讲不出个所以然。 一句话：模块按“什么会变”来分，不是按“先做什么后做什么”来分 新手容易犯的一个错误是按照流程来划分模块。 拿电商网站来说，购物流程是：用户下单，先收到请求，再算钱，再扣款，再存库，再发邮件。 如果你把每个步骤拆成一个模块，当然可以，但是这其实并不利于后续的维护。 顺着步骤分，改动会顺着步骤一路扩散。举个例子，你想给订单加一个“预计送达时间”，收到请求要处理这个字段、算运费要用到它、存库要存下来、发邮件要显示它，四个步骤都会受影响，如果不小心漏掉一个地方还会出问题。 好的做法是：先列出将来最可能变的东西，然后把每一个会变的东西放到一个模块里，外面的人看不到它是怎么实现的，把信息隐藏起来。 比如说前面那个购物的例子，电商网站里会变的东西有： - 支付渠道（今天支付宝，明天加微信，后天做海外要接 Stripe） - 优惠规则（运营隔三差五改一次） - 通知方式（邮件、短信、App 推送） - 数据存哪里（MySQL 换 PostgreSQL）。 这么分下来，支付、优惠、通知这些都可以单独做成模块，各自的变化都只影响自己的模块，不会影响其他地方。比如说你要给数据库加一层缓存，只要改数据存储模块就好了，其他模块都不受影响。 要是你觉得太复杂，也可以简单的按业务功能分，因为会一起变的东西通常就属于同一个功能，所以按功能分一般不算错。 但不要按步骤分模块，这样会把本来应该放在一起的生生按照顺序拆开了。 判断标准很简单：一个需求改动来了，你需要动几个模块？理想情况是一个。 要是运营改个优惠规则要同时动好几个文件，说明模块分错了。 按照这种“什么会变”的方式拆分模块对 AI 来说也是最友好的，因为 AI 本来就受限于上下文窗口长度，如果一个变更只要在一个模块内部就能解决，那么需要的上下文会少很多。

@dotey

很好的 Vibe Coding 工程经验分享，下面是我的简单总结，具体请看原推文： 1. 合理的架构和分层依然很重要，可以让项目更好的维护和扩展 2. 自动化测试可以有效保证质量，修复 bug 还要同步添加测试覆盖，避免类似情况再次发生 3. 少做积累功能，功能清理后代码也要一起清理 4. 借助 GitHub Actions 做好 CI/CD，发布前在干净的云端机器完整的跑一次自动化测试 5. 让 AI 自动执行自动验证纠错，只在必要的阶段人工验证 6. 经常重复的工作做成 skill，这样不需要每次从头向 AI 解释

@HiTw93

想从产品工程师视角和大伙聊聊，在代码全部由AI生成的时代，如何保证产品的代码可以持续迭代、好维护、不腐化。 最近 Mole 发布到了第 13 个版本，看了看整个项目大概有 11 万行 Swift 产品本身代码、7.3 万行测试代码和 3347 个 XCTest，测试代码部分远多余之前在公司写业务时候有QA来保障下的代码，我一直秉承一个观点，AI 写的代码应该 AI 来测试，而非人，把人引入到这个环节反而会拖慢整体的进度。 想着基于上面这个经验实操来总结一下，我都做了哪些有意思的事情，让这些代码一直可以在我和 AI 之间非常听话的实现功能。 1、即使 AI 能够大幅提升代码生产的速度，产品本身的技术架构、分层、同类抽象，什么东西放到什么地方能够让后续更好的扩展以及解耦，还是需要工程师本身的判断，这一块可以在项目第一个版本可以跑起来后就可以和你最好的 AI 仔细讨论，设定好对应的架构，并通过可沉淀可修改的文档记录下来，持续跟随项目迭代。 2、我目前最依赖的还是单测，1.0 只有 56 个 XCTest，到 1.13 已经有 3347 个，测试代码大约是生产 Swift 代码的 66%，不过数量只是顺手统计出来的结果，我平时更关心测试有没有覆盖那些容易想当然的地方，比如扫描结束以后文件又变了、进程检查失败、命令返回成功但 App 根本没有更新、旧任务很晚才回来覆盖了新结果。正常情况一般不难写，麻烦的是那些结果看起来没问题，实际上已经错了的情况如何可以及时去更新。 3、特别是修 Bug 的时候，我会多留一些东西下来，除了把问题修复，还会加一个让旧代码失败的回归测试，然后沿着同类路径去找有没有类似的问题，最后把当时为什么这么改写到规则里面去，到目前 Mole 已经有 1000 多个以 fix 开头的提交，其中 900 多个提交过测试，很多测试和规则都是用户真实踩过一次以后留下来的经验，或许我认为这个是当前这个项目最宝贵的资产。 4、测试能记住输入和结果，但记不住当时为什么放弃一种做法，所以项目里还有一批 Rules，主要记录功能边界、历史原因和不能碰的地方。比如为什么某类文件宁可漏掉也不能自动删除，为什么有些看起来重复的组件不能随便合并，哪些系统数据不属于 Mole。Rules 一多又很费上下文，我就按模块把它们拆开，只在改到相关代码时加载，再把经常重复的检查做成 Skills。bugs 会从以前的修复里找同类问题，design-system-review 看界面有没有越写越乱，release 则负责检查签名、公证、远端文件和更新链路，这样不需要每次都从头跟 AI 解释一遍。 5、还有一个对我很有用的法子，就是少做一些没有实际用的功能。现在 AI 加一个设置项、兼容分支或者后台监听太容易了，几分钟就能写出来，留下来的状态和维护成本反而腐化的最大的原因。比如Mole 现在对新功能设置了一些规则，比如尽量不增加常驻开销，不增加新的特权和系统权限，有合理默认值就不继续加设置项，更新和清理也不会因为发现一种新的可能性就一直扩范围，很多时候有很多功能是开发者自以为重要，但是使用者完全不在乎的功能，更多还是建议从用户中来，到需求中去，如无必要勿增实体。 6、需要充分利用好 Github 自动化 actions 的能力，这个会是你最后的兜底，其实代码写完、跑通、测试变绿以后也还没结束，我的项目里还有一套检查负责九种语言、网站生成结果、Appcast、Xcode 工程和公开部署文件之间的一致性，make verify 会把这些检查和测试一起跑，CI 再换到云端干净机器上重新来一次。到了发布的时候，本地代码、Git 提交、签名后的安装包、线上文件和用户实际收到的更新也是几种不同状态，我会分开确认。之前也遇到过源码完全正确，线上还在提供旧文件的情况，只看一个绿色结果很容易过早觉得已经做完了，其实是有错误的。 7、上面的一切，假如需要说特别的地方，我能想到的就是执行流程完全我没有插手干扰，每一步是 AI 自动化的去执行验证，出错了 AI 自动去解决，只不过会在不同的时候设置必要的流程卡点，让 AI 主动去验证，得到明确的结果才确定通过，并持续的去迭代规则，保持现有规则的新鲜度，并及时移除旧的逻辑，让本身的校验逻辑和本身的业务代码同步升级。 或许，这是我认为 AI 时代的工程师更需要培养的能力，如何让 AI 写的代码更好维护、更清晰、更好扩展，即使半年、一年、两年都不会腐化，而且会越来越听话，越来越符合开发者的心意，也给多 Agent 合作开发确立一个很稳靠的根基。之前手写代码的乐趣已经没有了，好在有这个弥补了一些纯 AICoding 过程无聊，让工程师的一些专业度得以延续下去。

@GitHub_Daily

sepia 这个去 AI 味写作 Skill 真有点东西，值得看一下。 它先拿六万多篇小说作为对照实验，发现光看叙事结构就能认出 AI 写的，识别率 93.2%。 然后尝试将表面词句改得干干净净，但这个识别率几乎不降。 于是它就从结构层下手，主题别让叙述者讲出来、因果链松一松，共 30 项诊断。 GitHub：http://github.com/Nanako0129/sepia Claude、ChatGPT、Gemini、DeepSeek、Kimi 各家模型的写作指纹，还有单独的修正清单。 写公文也有对应规则，发布公告、复盘报告、工单各配一套，按场合说话不端着。 提供写、诊断、小改、重写 4 种用法，Claude Code、Codex 都能装。前阵子分享过改词句的同类工具，这个更深一层。

@GitHub_Daily

周末想在客厅电视上，观看硬盘里存的电影，得插着移动硬盘来回倒腾，颇为麻烦。 于是找了 K7 把这事做成自托管的媒体服务器，定位很明确，就给一小圈家人朋友用。 名字取自法语里「磁带」的发音，作者想找回家里那排录像带、东西都归自己的感觉，这个立意挺打动人。 电影、剧集、音乐放在一个架子上管理，自动转码，设备旧或网络差也能流畅播放。 GitHub：http://github.com/kaybi-gh/K7 客户端覆盖网页、安卓手机和电视、Windows、iOS、Mac，还能拿手机遥控电视上的播放。 还有比较少见的是串门功能，自己的 K7 能和朋友那台连起来，互相看对方的片库，文件不用来回拷。 两条 Docker 命令启动好服务，家里有 NAS 或闲置小主机的朋友，可以把片库搬进去试试。

@GitHub_Daily

给编码 Agent 做长期记忆的项目见过不少，但ai-memory 的实现思路，挺有意思的。 它将记忆当成纯 Markdown 文件笔记的 Git 仓库，没有用向量数据库。 笔记能搜索、能拿 Obsidian 打开、能整个备份走，哪天不用它了，文档还是自己的文档。 平时不用刻意维护，它靠钩子自动把提示词、工具调用、会话节点这些记下来，写代码的过程就是记录的过程。 GitHub：http://github.com/akitaonrails/ai-memory 交接是最能打的部分，Claude Code 干到一半退出，几小时后在同一目录打开 Codex，它开工前会先看到一块「上回做到哪」。 架构讲过什么、哪些路子试过不行，都不用再跟新工具交代一遍。 支持的工具列出来有 15 种往上，Claude Code、Codex、Cursor、Gemini CLI 都在里面，经常在几个工具之间换着用的，装一个能省掉不少重复交代。

@bibryam

Oracle: Agent memory is a database problem. Turso: Treat agent state like a filesystem, but implement it as a database TroveFiles: Filesystem-as-memory Mem0: Your AI Agent’s Memory Is Just a File? That’s the Problem. Neo4j: Memory should be a context graph Vercel: Agent memory is a state problem, not a memory problem ...

@bibryam

GitHub reviewed 2,500+ agents.md files. Five patterns stood out: • Put commands early • Show code, not prose • Name the exact stack • Set clear boundaries • Cover tests, structure, style, and Git An agent needs an operating manual, not a personality. https://github.blog/ai-and-ml/github-copilot/how-to-write-a-great-agents-md-lessons-from-over-2500-repositories/ 👆 Use it as a review checklist, not another generic prompt template.

How to write a great agents.md: Lessons from over 2,500 repositoriesgithub.blog · 直连原文

@mattpocockuk

This has ended up being better than expected and fills an interesting hole in my skills. Most folks don't have an AFK agent workflow set up yet. You should. It's better than /implement-spec. BUT running /implement-spec is good, especially while tokens are cheap, and very simple to set up. I'll be graduating this into my public skill set once I'm back from holiday.