Kayne

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

[Kayne @StocksFromZero]

@gefei55 这个门槛现在依然有道理，只是理由变了。编程基础的价值，已经不在于自己能写，而在于 AI 写错的时候你看得出来，知道问题大概出在哪一层，也知道下一句该怎么问。没有这个底子，AI 说什么你都只能信。

[Kayne @StocksFromZero]

@wings1105 写了 11 年代码，现在每天的工作是跟 AI 说话，大概排在 vibe coding 那一档，还是比较靠后的那种。

[Kayne @StocksFromZero]

@dualcoremi 太真实了。AI 不会主动替你考虑「这是一个 iOS App」：返回手势、导航栏的位置、系统字体和动态字号、深色模式，你不提，它就按最省事的方式随手做。写了 11 年 iOS，我的体会是这些规范得在需求里写在最前面，比如「用原生组件，遵守 HIG」。它不是不会，是你没要求。

[Kayne @StocksFromZero]

@shao__meng 很认同，换模型不如调流程。我把流水线拆成分析、写代码、验证三段接力，踩过一个坑：三个会话各在不同目录，每一段都从头编译。后来改成每个需求固定一个目录，共用编译缓存，跑完自动回报结果。很多时候卡住的不是模型本身，而是外面这一圈。

[Kayne @StocksFromZero]

@0427SMtieshou @grok 什么消息源

[Kayne @StocksFromZero]

@HiTw93 没设定每条消息都回复

[Kayne @StocksFromZero]

@xqliu 并排跑最怕的不是慢，而是两个 agent 同时改了同一处，最后谁也说不清哪个版本是对的。我觉得开跑之前要先按模块把边界划清楚，每个任务一个独立的工作目录，各改各的，最后再合到一起。工具能让它们并排跑，但边界还得人来定。

[Kayne @StocksFromZero]

@yupi996 这个排查顺序很实用。从写了 11 年 iOS 的经验看，我会把「上下文」放在第一位查：AI 写错，很多时候是因为我们自己没说清楚，它只是按字面意思猜了一个最合理的版本。先回头看自己给的需求有没有漏，再去怀疑模型，能少走很多弯路。

[Kayne @StocksFromZero]

@Daviswh 共享记忆是个好方向，但我更愿意把记忆放在项目里，而不是某个工具里。我的交接和进度都写在 GitHub issue 里，不管换哪个 agent 接手，第一步都是先读 issue。工具会换、会挂、会涨价，项目里的记录一直在。

[Kayne @StocksFromZero]

@Mr_HenryMorgan 同意。单价再低，要跑好几遍才对，实际就贵了好几倍，还得算上人在旁边盯着、反复解释需求的时间。我现在的订阅额度连日常写代码都不够用，所以更在意一次能不能做对，而不是每次便宜多少。

[Kayne @StocksFromZero]

@foukation 关键是先把「什么算高风险」定清楚。我觉得有两条线：一是改动会不会影响到这个模块以外的地方，二是出错以后能不能撤回。碰到其中一条，就该人来看。签名证书和密钥这类改动，我定死了必须停下来等人确认。

[Kayne @StocksFromZero]

@runes_leo 同感，不过我觉得入口可以只有一个，背后最好有分工。我现在写代码交给 Cindy，整理信息用 Grok Bot，另外几个 bot 各管一摊：一个找帖，一个写稿，一个统筹。我平时主要跟一个入口说话，活由它分下去。

[Kayne @StocksFromZero]

@realchendahuang 许愿能许出一个玩具，许不出一个产品。做产品得有人提前想好「做到什么程度算完」：哪些情况必须处理，哪些可以先不管。AI 可以一直往下做，但它不会自己喊停。判断「这算不算做完」的那个人，现在比写代码的人更不能缺。

[Kayne @StocksFromZero]

@AetrixEmby 这个坑很典型。AI 审代码时看到的，往往是经过工具处理过的样子，被截断、被脱敏、被格式化过，不一定就是代码的真实情况。所以它说哪里有问题，我会先让它把问题复现出来，或者直接去原文件里核对，确认问题真的存在再动手改。不然很容易越修越乱。

[Kayne @StocksFromZero]

@AYi_AInotes 结论再漂亮，也得有人能把过程从头复核一遍，才算数。AI 最大的特点是说错的时候和说对的时候一样自信，所以它给出的「突破」，我更想看推导的每一步能不能被独立验证，而不是只看结论本身。半小时给出答案很厉害，但确认它是对的，可能要花更长时间。

[Kayne @StocksFromZero]

@RookieRicardoR 跑分和别人的体验都只能参考，一个模型够不够格接你的活，还是得自己试。我的思路是先拿边界清楚、出错代价小的活去试，比如改一个独立的小模块、补一段测试，看它交回来的东西要返工几次。小活稳定了，再慢慢往核心的地方放。这样不用站队，也不用赌。

[Kayne @StocksFromZero]

@Bitwux 很认同。key 放在本地，风险在自己手上，出了事至少知道该查哪里；托管到云端，就等于把信任交给了一家你看不到内部的公司。我的看法是，信任边界要按「出事后损失多大」来画：能随时作废、额度有上限的 key，交给工具图个方便没问题；能直接动钱、动生产环境的，就别离开自己的机器。

[Kayne @StocksFromZero]

@Samboy2222 来回审几十轮还过不去，问题多半不在写的那一方，也不在审的那一方，而在一开始的要求。需求本身就模糊，或者验收标准自相矛盾，两个 AI 再怎么来回也收不了尾。审到第三轮就该停下来想想：是不是要求本身得改。

[Kayne @StocksFromZero]

@tvytlx 这个方向很对。AI 干活快了以后，等人整理好进度再汇报，信息早就过时了。我的做法是让进度跟着活本身走：每一步做了什么、卡在哪，都直接写在对应的 GitHub issue 里。想知道进度就去看 issue，不用专门找谁问。进度最好是干活时顺手留下的，而不是事后补写的。