Tw93

强迫症必备！ 这款屏幕清理湿纸巾擦完电脑屏幕和刚拆封时候一样的感觉！

Mole 依然非常简单易用，但更加 Pro 了～ 终于支持网络和测试的能力了，此外点击状态面板上的每一个标签可以看到非常丰富的系统数据，欢迎喜欢尝鲜的小伙伴去打开设置里面的 beta 开关，等我正式版！

假如把我的 AI Coding 经验沉淀成一些最佳实践规则，可以给到大伙复用，会是怎么样的，于是乎，今天一下午我就在琢磨这个事情，手写反复调整后给到大伙，可以让你和你的 Agent 一起去学习。 需求 1. 从技术实现细节编程转变成许愿式编程，现在模型能力已经住足够强大，你只需要大胆把自己想法说出来，给它提足够高的要求和任务，不要担心 AI 实现不了。 2. 多给你的 Agent 讲做这件事情的背景和目标，少替他考虑技术细节，告诉它为什么要做，是给谁用的，做成什么样子你认为是最好的，具体的技术细节让它自己去判断，学会放手。 3. 优先用业界最好的模型，用差模型浪费的时候，一来回让你很不高兴的干活，二来也浪费了很多时间。 4. 要不要做一个新功能以及加一个新配置、开关的时候，让 Agent 来先问你找你确定，没有人用的功能、开关、文案都不要让他去加，慢慢把这一套你的产品规范让他沉淀起来。 5. 你的想法可以很大，但是让 Agent 干活的时候，尽量让他每次拆分成最小的可用功能版本，不要一次写非常多的代码，即使提交，这样出问题了你可以随时撤回。 规则 6. 让你的 Agent 了解你的说话风格，比如说看看、分析一下这个问题的时候，它只需要去读代码分析问题不要去改代码，你说修复、修改的时候才去动手，每次提交、发布和删除的时候都找你确定。 7. Agent md、CLAUDE md 里面除去重点的项目型要求外，只写代码里面看不出来的那种规则，以及之前被否决过的方案也可以分流进去。对你而言密钥和 token 不要贴给 Agent，贴了就当已经泄露了，立马去更换一个。 8. 对于Agent必须遵守的规则不要完全信 prompt，可能会拦不住，一定要用规则脚本去限制，让它真实跑一遍通过后才算完成了。 编码 9. 开始写代码之前，先让 Agent 讲清楚要改什么地方，会影响到什么功能和效果，这样是为了补充你的上下文，方便后面更好判断决策做什么。 10. 一定要让 Agent 基于项目补充一个能够让自己验证各种结果的脚本，每次特定的时候需要去跑一下验证效果，完成功能后需要检查，让他输出结果给你看，并基于此逐步沉淀你的项目 Agent 测试功能集。 11. 假如有多个 Agent 同时干活的时候，让他们各自用一份独立的 worktree 代码目录，同时提交的时候只提交自己改的代码，不要碰他人的代码，等到各自改完合到一起，再完整跑一遍测试。 排查 12. 修 Bug 的时候先找到原因再去动手，假如两次都没有修好，就去加一些日志看真实的数据以及运行效果，不要盲目去猜问题在哪儿。 13. 假如尝试修复了3次还不对，直接清空上下文重新写清楚你的问题、诉求，以及尝试过的解法让 Agent 重新开始。 审查 14. 让写代码的 Agent 和 Review 审查代码的 Agent 分开，保持解耦，这样一方不会被另一方带偏。 15. Review 代码的时候最多让 Agent 跑 3轮，防止跑着停不下来，第二轮开始只看新改动的地方，不要再把之前 Review 的再看一遍。 16. 对于你和 Agent 判断危险的改动，越危险让他查得越深，特别对于删除、付费、发布这种单向门改动你都需要自己去看一遍，点一下，看实际效果。 发布 17. 每次提交的时候，让Agent 写清楚做了什么，怎么去验证这个改动，除了问题怎么来回滚，用于给到后面开发过程中 git 记录本身就是 Agent 的一个非常好的上下文。 18. 需要对外的功能，可以先给自己用，或者给一批愿意尝鲜的用户使用，不要一上来就全量，可以在你的软件里面假如 beta 更新的开关，防止全量有问题，也是对用户负责。 18. 先给自己和愿意尝鲜的人用，没问题再发给所有人。 复盘 19. Agent 需要对每一个线上 Bug 和用户反馈的问题都留一个测试案例，每次上线前都来跑一遍，防止继续踩坑，包括你换模型的时候也可以把这些旧问题全部都跑一遍，看看模型是否还行。 20. 修复问题的时候，让 Agent 学会举一反三，把同类的问题一起修复掉。优化功能的功能，完善视觉的时候也是一样，防止只改一个地方，忘记了其他的地方。

来一波回忆杀，我的博客居然写了快 12 年了，从 2014 年底开始写，当时还是稚嫩的大学生，更有趣的是框架还是十几年前比较火的 Ruby 的Jekyll，几乎没有改过版本，当然也是我在写了 2 年 PHP 后感觉前端更有意思，学习 JS 的第一个项目。 翻到了当时写了一篇 Vue、Angular、Avalon 框架的比较，当时 Vue 刚刚出来不久，Angular 被很多人开始喜欢，司徒正美老师的 Avalon 也有不少人用的那个时候，当时我还在用 Bootstrap 写全栈接商业项目赚生活费，看到知乎上的一个问题，花了一晚自习时间看官网文档写了几个demo，然后就写下了这篇很初级的对比文章，想到刚好可以沉淀到我的博客上，就随手提交了。 正是这个举动对我后续影响非常大，当时大学非常喜欢写代码，每天泡图书馆带着电脑按照书上的教程去学编程，然后想着让博客更加饱满，就会把学到的一些记录整理成文章搬到博客，差不多那两年时间把图书馆关于计算机基础、Web开发、编程思想的一些知名好书几乎都看完了，这一块对我帮助很大，以至后续工作的时候，感觉干活不是很难，就有更多时间来学习一些新东西。 转眼到了 2022 年，当时一年前学习 Swift 写了一个妙言 Markdown 笔记应用自己用，差不多成熟就开源了，后面想着要有一个发布更新日志的地方，顺手看到了这个小蓝鸟，非常好看，又顺手用谷歌邮箱一键登录了，发了第一个推特「妙言 - 轻灵的 Markdown 笔记本」，后面慢慢把妙言的更新日志以及做的过程就发到了推特，没多久被不少用妙言的小伙伴看到了，后续就交到了很多朋友，也是一个非常无意之举。 这个无意之举更有意思，我非常喜欢在推特发一些自己的想法和产品更新，当做一个完全没有顾忌的发言地方，一转眼居然玩了 4 年多了，正经推文差不多 2400 篇左右，由于推特自己的搜索和分类排序不好用，刚好需要查一些自己发的东西，于是我做了一个有意思的时候，让我的 Grok Bot 帮我的推特全部下下来了，也放了一份到我的博客上，我给这个栏目取名「片语」，开源是只言片语，每天会同步，这样也非常方便访问我博客的小伙伴可以看到一些轻松的片语。 说起写东西，我还有一个不变的习惯就是，不让 AI 代替我的思考、写作，所有大伙看到我的内容差不多都是手写的，虽然看着在 AI 时代很不潮流，但是我很喜欢这种输出，说不定这些文字可以成为以后硅基文明一个很重要的二十世纪中国年轻程序员的历史记录，哈哈哈，想想更有意思了，而且硅基人看着会感觉，呀和我们说话很不一样，是一个另类，得好好研究，这也是我在 AI 时代继续写一些看着没有什么用的东西的原因。 回到现实，我写博客没有走到大部分人走的那两条路，一年给自己博客换一个框架，装修一次，然后就是不写东西（没有喷的意思就是笑），也没有走另外一条，通过大量的 AI 生成补充很多看着非常丰富厉害的知识的模式（对不少人帮助很大），我的博客就只是我的一个 Markdown 渲染容器而已，表达的一个输出。

有了 AI 以后写代码速度快了非常多，但是校验的速度其实还是不快的，特别是在 GitHub 上跑 Actions CI 的速度，下午花了一些时间对 Mole、Kaku、Pake 的 CI 全部彻底优化了一下，效果很不错，分享给大伙。 你可以这样直接 Copy 下面给到你的 Agent，我们来看看可以帮你节约多少时间。 帮我把这个仓库的 GitHub Actions 提速，在不减少必要的测试项以及功能校验下，最大幅度减少耗时。 1. 先使用 gh 拉最近 50 次的运行情况，把每一个 job 拆成排队、准备、真正跑测试的 3 个时间段，去看规律，可能很多时候慢的是准备的阶段，不是测试本身。 2. 同一个 PR 连着推好几次时，只跑最新的那次，旧的直接取消掉，用 cancel-in-progress 去实现。不过 main 分支不要这么做，需要确保发版 main 上的每一个提交都完整跑过一遍。 3. 只改 README 和文档的这种提交不要触发跑 CI，可以用 paths 过滤掉，另外被跳过的必需检查会一直卡住 PR 合不进去，这个要提前注意一下。 4. 优先用 setup 类 action 自带的缓存，setup-node 打开 cache，setup-go 默认就开，Rust 用 Swatinem/rust-cache，注意每个仓库缓存只有 10 GB，用不上的就不要放到这里面去。 5. 本地连着构建两次，第二次应该几乎不花时间，假如有多余的花时间的地方，一定是哪些写得有问题，比如 Dockerfile 装依赖前先 COPY 了整个仓库，或者构建脚本盯着一个不存在的文件，类似的问题记得检查。 6. 工具直接下载预编译好的，不要用 go install、cargo install 现场安装编译，这里会很费时间。 7. 不互相依赖的 job 并行跑，删掉不传数据的 needs，最长的那套测试拆到多台机器上去跑。 8. 免费账号的 macOS 最多同时跑 5 个，所有 workflow 共用，格式化、lint、依赖审计这些不挑系统的都移到 Ubuntu 去跑更好。 9. 做过的事情就不要做重复了，以及不要多此一举做事情，比如别的 job 跑过的检查就不要套重复再跑，比如只构建前端的 job 就不要多此一举去拉整个 Rust 缓存。 10. 改完去 push 那个上面测试运行效果，看运行的时间，发现规律，再次查漏补缺来优化一遍，做到最好，最后给到我优化前后的对比。