最近在使用一种和 AICoding 更好交流的方式，椅子上一躺，按住语音输入法，把自己要做的事情、为什么要做、解决什么问题、期待长什么样子、喜欢什么样子的风格、如何来验收等等自言自语聊上几分钟，不停补充要求，然后把这些杂乱单重要的上下文一股脑给到 AI ，效果往往会比打字一句句聊好太太太多了!

这期潮流周刊封面图拍摄于昨天去我的精神家园-王小波的书店，非常感谢有小伙伴指出之前几期周刊有点水，最近沉迷到 AICoding 了，接受批评，以后还是保持内容更有趣一点好，也让自己在代码之外多去看点好东西，不能丢掉人文的东西，争取也成为大家的小精神家园。

Claude Code 写到一半想换 Codex，项目怎么做的、哪些办法试过没用、接下来还有什么，又得重新讲一遍。 发现一个 开源项目 ai-memory ，会把这些内容整理成 Git 管理的 Markdown Wiki，让 Claude Code、Codex、Cursor 等 20+ AI 编程工具共用项目记忆，不过不同客户端的接入方式不完全一样。 可以自托管在本机、Homelab 或 VPS；远程访问记得配置认证和 HTTPS。不接云端模型也能记录和搜索。 👉 #ClaudeCode# #Codex# #AICoding#

请来继刚、歸藏、橘子对谈，几个思考： 1. 让 AI 真正落地的不是产品，是服务 2. 企业 AI 转型，只需要搞定 5% 的人 3. 越土的行业，AI 越吃香 4. 卖 Skill 给个人用户，是个伪生意 5. 别人的 Skill 再厉害，也进不了你的工作流 6. 下一张社交网络，一半节点不是人 #aicoding# #易论AI# #归藏# #colaOS# #李继刚#

突然想给大伙聊聊，我是怎么给产品取名字的，这个过程很有趣，或许你也可以结合你的性格喜好来给你的产品取一个不错的名字。 在 AI 没有来之前，市面上各种 Coding 产物没有这么多，我对产品本身的生命感存在感对于会非常很看重，所以基本上会非常认真对待这个事情，好比一个新生儿出生，父母需要花不少时间去给这个即将到来的生命取一个陪伴她一辈子的名字，让她的以后对自己的名字也是非常喜欢，甚至可以鼓励她的一生，给她自信的那种。 即使在现在 AICoding 产物盛行的这一代，假如你很想把这个产品推给大众而非自己把玩，还是非常推荐你给她取一个非常好的名字，这样每次你给大众介绍的时候，你也会对你自己的产品非常自信，喜欢，也会非常花时间花精力把她持续迭代好。 我的第一个产品叫做妙言，在2020年那个前后，其实 markdown 笔记应用非常火，当时感觉没有太顺手的就自己学 swift 写了一个，我自己特别喜欢中文字，当时也没有考虑国际化，更多是自己用，我用他来记录我工作学习中各种笔记，一直认为好的文字也是有生命力的，就想到了妙不可言，正是写文字想表达的那个观点，现在我依然很喜欢这个名字，也持续在迭代，读起来也朗朗上口，简单好记，这里想表达的是产品名字需要和你的产品本身功能或者要体现的意义关联，防止取一个不相关的名字，虽然好听，你也不好讲 。 第二个产品叫做 Pake，是一个用 Rust 写的，可以一条命令把你的网页打包成轻量的桌面包，为啥这次开始取英文名，其实是后面妙言我发现国外人也用的很多，直接用MiaoYan拼音介绍很奇怪，所有后面的产品我尽量取名让所有人都看得懂一点，当时给 Pake取名的时候，我就想到打包这两个词，换成英文是 Pack，这个词其实挺好的，但是由于非常大众，我担心过于大众化，这里的灵感来源现在回想起来和 Vue 很像，其实 Vue 最开始应该是想叫 View 的，但是尤大感觉这个名字太直接了，他就放到谷歌翻译里面去试试，然后找到了它的法语翻译叫做 Vue，当时我给 Pake 取名的时候也这样，我去找 打包的各种语言的翻译，最后发现在海地克里奥尔语打包就叫做 Pake，狂喜，就取名成这个了。而且这个名字非常好拼写、好记、好打字，对于任何人使用过后，应该能够很好的记住，同时 Pake 自己的命令也是 pake，这样产品使用传播就非常简单了。 第三个产品就是我们更熟悉的 Mole 了，当时还是一个深度挖掘你的Mac电脑垃圾命令行工具，其实这里我是先取的中文名字，我一直把这个产品当做一个有动作、看似安静、勤恳清理垃圾的小可爱小东西，当时就取想什么小动物最贴合这个，想了很久没有想到喜欢的，貌似应该是在一个小孩书上看到介绍鼹鼠，突然一想，对对对是我想要的，就是这样的感觉，安静/小/疯狂挖掘那个感觉，更惊喜的是英文命名 Mole 非常非常贴合我一贯的取名风格，好记、好写、好评、但不大众化，现在回忆起来非常有意思，挺好玩的。 后面 3 个产品就被我不经意间形成了一个系列，那就是 Kaku、Waza、Kami，应该说没有Kaku的取名，就没有后续这两个产品的名字了，Kaku是我去年过年长假写的一个轻量、简单、开箱即用、AI友好的命令行终端工具，取名的时候，我唯一想到的就是这个产品一定要表达出来轻快很爽的那种感觉，然后自己的随口念不同的词，乱念的那种，最后最后，发现 kakukakukakukakukakaku 非常爽，然后就按照这个音取找，发现kaku是日本书写里面的書く这个词的意思，太有意思了，终端和书的关系很近，而且很有诗意，而且也是海贼王里面的一个角色，立马就取到这个了，后面的 Waza 是日文 技，对应着我的工程师技能 skills 也很贴合，Kami 是紙，是我的一个好内容值得好版面的排版 skills 名字，正是我想表达的意思，纸面是干净的，可以写出非常多有价值的东西。 并不是说名字和产品是至关重要的，比如说我在 Anthropic 刚出来的时候非常讨厌这个名字，因为我永远记不住如何拼写，但是也不妨碍他的产品模型的成功，没有啥必要关系，比如即使你的产品叫做二狗，但是非常牛逼，也不妨碍他的成功。不过也有些是有关联的，比如还有一个丑名字叫做 Antigravity，这个名字甚至比Anthropic 还要难读难写，其实从他刚刚推出，我就有点儿感觉这个产品很难成功，因为本身模型并发第一第二那种，只能更多靠产品能力出来拼，结果产品能力也不是太好，就变成现在这样了。此外也不是名字短看着简单就好，比如说Trae，我今天还会很容易达成 trea 或者忘记怎么打，可见也不是名字短，字母简单就是好名字，因为不好记不好拼，也看着没有意义那种感觉，假如他不告诉你这个是 The Real AI Engineer 的缩写，可能永远不会有人知道这个名字是这个意思，这样就比较难在大众市场打开。 一不小心就碎碎念了这么多，比较想表达的就是，你的产品应该有一定调性，需要有产品自己的性格，不能千篇一律，当然我说的取名方法更适合我自己，适合我的性格，对于你而言，你的产品也需要贴合你的性格喜好，比如你喜欢日本动漫就可以多和这个里面角色靠近，你喜欢中国古代神话，你的产品名字就可以从这里面取找稀有但有趣的名字。最后最后，我认为名字一定是朗朗上口的、好读的、好记住的、好写的、不长，甚至也是你在键盘上敲起来非常无感的那种。

想和大伙分享一下，最近我用自己产品 Mole 遇到的 4 个 Aha Moment，对我使用非常有帮助。 第一个是，有一天下午居然收到了一个消息通知，说我的 Airpods 电量不足要充电了，这个功能惊喜到了我，是当时做电池健康的时候 AI 主动给我加上的，Mole 会提醒和Mac关联的蓝牙带电池的设备低电量充电，但是我一直没有遇到这个场景，直到遇到了，感觉非常贴心，但频繁不打扰。 第二个是，对于每日使用的我居然还可以清理掉 86G，之前有一个版本加上清理项目里面肯定无用的build编译内容，我的 Rust 项目产生了不少 target 内容，一下子清理这么多，非常有满足感。 第三个是，屏幕常亮的功能，经过用户提醒给加上了3种不同的常亮行为，我还是喜欢把屏幕打开的方式，比如周末你突然出门，你的 AICoding 可以用手机客户端很好的控制让他干活，非常稳定，也帮我节约了不少异步的时间。 第四个是，Mole 的电量显示居然也支持展示你的 iPhone 的电量了，之前这一块不是很好实现，但是很巧妙的实现了，现在可以在状态里面很清楚看到与你相关的设备的电量情况，也不打扰，但是很安心。 更神奇的是，以上这4个功能的起源都不是我想到的，是初期使用 Mole 的朋友反馈告诉我要加的功能，我加上后对我帮助非常大，非常感谢！话说你使用 Mole Mac 有惊喜的地方是哪一些，以及你非常建议 Mole 要加的功能，欢迎告诉我。

Mole Mac 发布 20多天后销量到了一个小里程碑，想和大伙聊聊我这个过程中的一些取舍，以及我为啥在前期在处理和用户的任何交流、答疑上、退款全部用手工的方式来进行，希望对正在独立研发自己作品的小伙伴有一些输入。 首先说，为啥我要检查完全手工手写的处理处理用户的答疑、反馈、邮件回复、退款、重置激活码、退差价等等这些事情，虽然不足用户量的1%，其实完全可以花半小时写一个 Agent 来帮我处理，这或许也是很多工程师做产品过程中一个很常见的看似高效但是不是很好的误区，这里有两个考虑，只有你真实的处理用户的售后问题，你才能感觉到用户真正需要的，他为啥要退款，为啥感觉不好用，他的真实的建议反馈，甚至还可以邮件交流获取到更多真实的诉求，以及这个你的处理过程中你熟练了解各种问题的最好答复和解决方案，这样等产品慢慢做大以后，再来用 Agent 提效会比一开始好很多。 其次，为啥不建议一开始就建立所谓的售后系统，因为这也是产品工程师一个重要的决策技术判断，优先做好主产品功能，而非一上来就把你的周边配套都搭建起来，虽然 AI 很快，但是还是会浪费你的宝贵时间去优化产品本身，看似不花时间，其实花了你很多时间，有这个时间去优化产品，满足用户的真实诉求会好太多了。 然后想和大伙交流，对于工程师转型产品独立研发过程中常见的一些坑点，首先一个好的产品和一般产品的区别是什么呢？好的产品更会决策哪些东西不做，不同的功能放到哪一个阶段做对于产品以及用户最好，哪些功能即使很好，但是不是本产品的主线也不应该放进来，不然很容易变成一个大杂烩，也不好维护。好的产品还有一个特性是脑袋里其实有这个产品半年内发展的脉络，很清晰知道每一个版本应该加哪些功能，以及哪些功能是伪需求，以及什么功能应该放到用户顺手的地方，对于普通小白不要说明书的产品才是好产品，这也是有小伙伴建议一些mac上的好功能想加到 mole 里面被我抱歉的原因，保持克制，以及坚信如无必要，勿增实体的产品观点。 mole 的定位是 mac 的系统优化、清理、维护的安静守护者，保持这个定位，去完善他，做到全世界最好用的 mac 维护软件，要是全球有每 100 个 mac 用户就有一个使用 mole，那么mole就真的很好用了，也是我做产品追求的点，让更多非技术小伙伴享受到工程师产品的乐趣，最近还有视障用户在使用mole，遇到一些无障碍问题，我抓紧修复，非常期待他们使用起来的效果和体验。 或许在 AI 时代，的确让很多东西方便很多了，但是和人的交流不能用 AI 代替，不然就没有啥意思来，虽然可以提效，但是很难提升彼此感情和信任，这或许会是以后用 AICoding 出来的产品保持人味的一个很好的途径。 由于第一次做付费产品，可能也有是我思考不周的地方，也很欢迎有经验的朋友帮助指出和建议。

想从产品工程师视角和大伙聊聊，在代码全部由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 过程无聊，让工程师的一些专业度得以延续下去。

AI Coding 再快，现实中的人还是得一页页签字、一次次盖章。技术已经踩下油门，但被渠道、支付、财务和制度咬住的慢齿轮，AI 暂时还带不动。 #AI边界# #一人公司# #创业日常# #AI创业# #易论AI# #歸藏# #李继刚#