给自己的多端需求写了个 skill,里面有一条规矩:根会话只当总指挥,整理需求、维护状态、生成交接单,不替任何一端写代码。各端会话拿着交接单干活,发完成信号后,总指挥要重读状态文件、核对产出和证据,才往下走。收到通知不算数,有证据才算。修复的会话也不能给自己标通过。
deepseek 4.1 flash 和 grok 4.7,你觉得哪个更强?我自己的感觉是,ds 更像理工男,grok 偏感性,当然只是我个人的主观印象。你们平时拿它们干什么活?用在哪类任务上,各自是什么体感,评论区聊聊。
AI 排查图片加载失败,看到一堆 200,就编出一套重试和并发的故事,顺到连怎么改代码都想好了。后来逐字节对比同一个文件的两份响应,PNG 开头 89 50 4E 47 变成了 EF BF BD 50 4E 47。200 只说明 HTTP 成功,不说明字节没坏。改代码前先写一句反证:这个猜想要是错的,哪次测量会失败。
Kayne retweeted
iPhone 上,Grok Bot 可以顶替你的笨蛋 Siri 了!
喊一声“Hey Grok”,直接开 Grok Bot 语音聊天,不用再喊 Siri,也不用装额外的 App。
我真机录了一遍,视频在下面
这个办法是 @Texas_Twins_Dad 先发现的,全靠 iOS 自带功能:
1. Grok Bot 更新到最新版
2. 打开“快捷指令”→ 右上角 + → 添加操作 → 搜 Grok Bot → 选 Start Voice Chat with Bot
3. 设置 → 辅助功能 → 人声快捷指令 → 选这条快捷指令 → 输入“Hey Grok”,对着手机念 3 遍
有个坑:手机锁着的时候,iOS 会先让你点一下屏幕。Face ID 已经解锁的话,全程不用动手
一个 issue 评论越堆越多,翻着费劲。与其在评论里接着吵,不如只维护一个方案。
后来定了这几条:
1. 主方案只更新在正文
2. 有新证据就加评论,同时更新正文
3. 被推翻的旧评论标 Outdated
4. 正文末尾留一段变更记录,每次一行:日期、改了什么,链到对应的证据评论
5. 标 Outdated 之前,先在那条评论里写一句被哪条取代、附上链接。GitHub 折叠评论只显示原因,看不出是被谁更新的
正文是当前结论,评论是变更记录。
你们 issue 里过时的讨论都怎么处理?还是干脆挪进文档?
我现在主要用 Cindy(@making_cindy)写代码,最近在做一件事:把任务和上下文都搬进 GitHub issue。
聊天窗口适合来回讨论,但不适合当记忆。换个会话、隔几天再回来,前面说过的约束就散了。issue 不一样,它是一份能被反复读的说明:要改什么、为什么改、哪些地方别碰,谁接手都从同一页开始。
分工就变成:人负责把 issue 写清楚,AI 负责干活。
取舍也很明显。写 issue 本身是个细活,写得含糊,AI 就会按自己的理解去补。省下来的是写代码的时间,省不掉的是把话说清楚的时间。
我现在主要用 Cindy(@making_cindy)写代码,最近在做一件事:把任务和上下文都搬进 GitHub issue。
聊天窗口适合来回讨论,但不适合当记忆。换个会话、隔几天再回来,前面说过的约束就散了。issue 不一样,它是一份能被反复读的说明:要改什么、为什么改、哪些地方别碰,谁接手都从同一页开始。
分工就变成:人负责把 issue 写清楚,AI 负责干活。
取舍也很明显。写 issue 本身是个细活,写得含糊,AI 就会按自己的理解去补。省下来的是写代码的时间,省不掉的是把话说清楚的时间。
以前我只是个 iOS 开发,现在借着 AI,在干运维和 DBA 的活。
让 AI 在浏览器里操作阿里云 DMS,给测试库提数据库变更工单。动手前它先跑了 7 条只读查询核对现状,还发现一条更早的变更在测试库里也没执行过,就并进了第一张工单。
每张都停在提交前等我确认。系统算的影响行数是 2,我们填的是 1,它查出是两条 UPDATE 改了同一行,讲清楚了我才提交。
4 张工单,目前才交了 1 张。
昨晚人不在电脑旁,让 @making_cindy 远程给 Mac 升级系统。
Cindy 负责下载系统和重启。重启时被终端里一个活跃进程挡住,我通过桌面共享远程关掉弹窗,系统顺利重启。重启后 Cindy 自动回来,我又让它把 Xcode 从 26 升到 27。
今天到工位,直接用新版 Xcode 开工。
今天复盘了一次 AI 流水线:一个需求自动拆成三个会话接力,分别负责出方案、写代码、做验证。
结果发现 AI 干活并不慢,慢在等和交接。三个会话加起来,大约 2.3 小时花在「睡一会儿再查一下」上;每换一个会话还要重新编译一次。
不写代码以后,我的工作越来越像在设计流水线。
不写代码以后,我的工作方式收敛成了一条链路:
我只跟 Grok Bot 说话 → 它通过 Slack 派活给 @making_cindy 写代码 → 任务和交接都落在 GitHub issue 上。
这样分的好处是,我只需要盯一个入口,不用在几个 AI 之间当人肉路由;上下文也不靠谁的记忆,全写在 issue 里,谁接手都能看懂。
AI 能干的活越来越多,人更要把自己放在派活和验收的位置上。





