Kayne (@StocksFromZero) header
Kayne (@StocksFromZero) profile picture

不写代码的工程师。用 AI 做产品,记录真实的工作方式、踩坑和想法。

Joined October 2026
给自己的多端需求写了个 skill,里面有一条规矩:根会话只当总指挥,整理需求、维护状态、生成交接单,不替任何一端写代码。各端会话拿着交接单干活,发完成信号后,总指挥要重读状态文件、核对产出和证据,才往下走。收到通知不算数,有证据才算。修复的会话也不能给自己标通过。
7
deepseek 4.1 flash 和 grok 4.7,你觉得哪个更强?我自己的感觉是,ds 更像理工男,grok 偏感性,当然只是我个人的主观印象。你们平时拿它们干什么活?用在哪类任务上,各自是什么体感,评论区聊聊。
1
15
我经常用 ds 写代码,grok 来做审查
8
AI 排查图片加载失败,看到一堆 200,就编出一套重试和并发的故事,顺到连怎么改代码都想好了。后来逐字节对比同一个文件的两份响应,PNG 开头 89 50 4E 47 变成了 EF BF BD 50 4E 47。200 只说明 HTTP 成功,不说明字节没坏。改代码前先写一句反证:这个猜想要是错的,哪次测量会失败。
12
Kayne retweeted
We brought Touch to the Mac! From the all-new iPad mini to the 14-inch MacBook Pro and iMac... and now MacBook Pro with PROLED XDR Display and Touch, creators have new tools to do their best work yet.
3,299
4,475
3,389
65,902
7,917,369
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 已经解锁的话,全程不用动手
81
97
18
772
149,428
Kayne retweeted
Robotaxi makes the roads safer for everyone
391
1,434
189
13,342
917,626
一个 issue 评论越堆越多,翻着费劲。与其在评论里接着吵,不如只维护一个方案。 后来定了这几条: 1. 主方案只更新在正文 2. 有新证据就加评论,同时更新正文 3. 被推翻的旧评论标 Outdated 4. 正文末尾留一段变更记录,每次一行:日期、改了什么,链到对应的证据评论 5. 标 Outdated 之前,先在那条评论里写一句被哪条取代、附上链接。GitHub 折叠评论只显示原因,看不出是被谁更新的 正文是当前结论,评论是变更记录。 你们 issue 里过时的讨论都怎么处理?还是干脆挪进文档?
我现在主要用 Cindy(@making_cindy)写代码,最近在做一件事:把任务和上下文都搬进 GitHub issue。 聊天窗口适合来回讨论,但不适合当记忆。换个会话、隔几天再回来,前面说过的约束就散了。issue 不一样,它是一份能被反复读的说明:要改什么、为什么改、哪些地方别碰,谁接手都从同一页开始。 分工就变成:人负责把 issue 写清楚,AI 负责干活。 取舍也很明显。写 issue 本身是个细活,写得含糊,AI 就会按自己的理解去补。省下来的是写代码的时间,省不掉的是把话说清楚的时间。
1
45
我现在主要用 Cindy(@making_cindy)写代码,最近在做一件事:把任务和上下文都搬进 GitHub issue。 聊天窗口适合来回讨论,但不适合当记忆。换个会话、隔几天再回来,前面说过的约束就散了。issue 不一样,它是一份能被反复读的说明:要改什么、为什么改、哪些地方别碰,谁接手都从同一页开始。 分工就变成:人负责把 issue 写清楚,AI 负责干活。 取舍也很明显。写 issue 本身是个细活,写得含糊,AI 就会按自己的理解去补。省下来的是写代码的时间,省不掉的是把话说清楚的时间。
1
1
75
以前我只是个 iOS 开发,现在借着 AI,在干运维和 DBA 的活。 让 AI 在浏览器里操作阿里云 DMS,给测试库提数据库变更工单。动手前它先跑了 7 条只读查询核对现状,还发现一条更早的变更在测试库里也没执行过,就并进了第一张工单。 每张都停在提交前等我确认。系统算的影响行数是 2,我们填的是 1,它查出是两条 UPDATE 改了同一行,讲清楚了我才提交。 4 张工单,目前才交了 1 张。
2
38
更新:这批变更涉及的表,已经全部在测试环境上线。回头看,最省心的不是它填得快,而是每张工单都停在提交前等人确认。
1
32
昨晚人不在电脑旁,让 @making_cindy 远程给 Mac 升级系统。 Cindy 负责下载系统和重启。重启时被终端里一个活跃进程挡住,我通过桌面共享远程关掉弹窗,系统顺利重启。重启后 Cindy 自动回来,我又让它把 Xcode 从 26 升到 27。 今天到工位,直接用新版 Xcode 开工。
1
63
今天复盘了一次 AI 流水线:一个需求自动拆成三个会话接力,分别负责出方案、写代码、做验证。 结果发现 AI 干活并不慢,慢在等和交接。三个会话加起来,大约 2.3 小时花在「睡一会儿再查一下」上;每换一个会话还要重新编译一次。 不写代码以后,我的工作越来越像在设计流水线。
57
不写代码以后,我的工作方式收敛成了一条链路: 我只跟 Grok Bot 说话 → 它通过 Slack 派活给 @making_cindy 写代码 → 任务和交接都落在 GitHub issue 上。 这样分的好处是,我只需要盯一个入口,不用在几个 AI 之间当人肉路由;上下文也不靠谁的记忆,全写在 issue 里,谁接手都能看懂。 AI 能干的活越来越多,人更要把自己放在派活和验收的位置上。
1
52
OMG the Tesla Roadster just flew in the air!
2,113
5,059
3,047
41,172
10,152,450
写了 11 年 iOS,现在我一行代码都不写了。 代码全交给 AI。我每天做的事变成了三件:想清楚要做什么,把需求讲明白,判断 AI 交上来的东西对不对。 我是 Kayne。这个号会记录一个工程师在 AI 时代真实的工作方式: - 我具体怎么用 AI 干活 - 效率到底变了多少 - 踩过的坑和走过的弯路 不预测未来,只记录正在发生的事。 你现在写代码,有多少是 AI 写的?
58