Kayne

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

[Kayne @StocksFromZero]

@snwiki238337 评测给的都是整理好的题：有描述、有复现步骤、有测试。真实项目里最费劲的恰恰是前面那一步，用户一句「用着不对劲」，要变成能稳定复现的问题，得翻日志、换机型、猜操作顺序。这一步做不好，后面修得再快也是在修错的地方。

[Kayne @StocksFromZero]

@HanZhang415188 本地和云上其实不用二选一。碰私有数据的，比如本地文件、账号、公司代码，放在自己机器上跑更踏实；要长时间跑、不想让电脑一直开着的，放云上更省心。按任务的敏感程度和要跑多久来分，比押一边更实际。

[Kayne @StocksFromZero]

@xiaoshan0413 很认同。手边有编辑器，人就忍不住自己改两行，问题永远停在「差一点」，智能体也永远碰不到最后那一步。拿掉编辑器，人只能回头把要求说清楚：哪里不对，应该是什么样。逼的其实不只是智能体，还有提需求的人。

[Kayne @StocksFromZero]

@bangbuilds 功能表看着都差不多，真正拉开差距的是换模型的代价。今天这家顺手、明天那家变强，你写好的规则和上下文能不能原样搬过去，还是每换一次就得重新调教一遍。能把一件事从头做完是底线，换得动才是长期用得下去的原因。

[Kayne @StocksFromZero]

@runes_leo 这种从空目录开始的对比，比跑分有意思多了。比起最后做出来的东西好不好，更值得看的是中间人插手了几次：哪一步卡住了，哪一步得人指方向，哪一步是推倒重来。想问下作者，三家各返工了几轮？

[Kayne @StocksFromZero]

@guanmo_ai 我这边 Grok 会员的额度就不够日常写代码用。对天天用的人来说，额度能不能预期比给多少更重要：今天够、明天突然砍，比一直不多还难受。工作流最好别全押在一家的额度上，至少留一条能切过去的路。

[Kayne @StocksFromZero]

@dngzsn37461 跟 iOS UI 测试走过的路一模一样：早年写死坐标，界面一改全挂；后来改用辅助功能标识定位，按钮挪了位置照样找得到。agent 操作网页也一样，认得清结构才扛得住页面改版，靠坐标和写死的选择器，迟早要重写。

[Kayne @StocksFromZero]

@swordBluesy 只说目标，AI 会找最短的路去够它，删测试就是最短的那条。比起把目标写得更细，更管用的是把护栏写明白：哪些测试不能改，哪些接口不能动，哪些文件只能读。告诉它不能碰什么，往往比告诉它要做什么更省事。

[Kayne @StocksFromZero]

@shuizhuyu 不逐行看 diff 以后，审查的问题就换了：不再是「这段代码写得对不对」，而是「它跑起来的行为是不是我要的」。前者靠读代码，后者靠能跑的例子和清楚的预期。而且后者才是用户真正会碰到的那部分。

[Kayne @StocksFromZero]

@TiagerBao 做过 iOS 的人都知道，测试最难的从来不是把流程点完，而是点完以后的判断：这里闪了一下算不算 bug，文案折行算不算，动画慢半拍算不算。AI 能替你点一百遍，但「什么算对」这把尺子，还得人先定好交给它。

[Kayne @StocksFromZero]

@realfxw 写客户端的人大多见过：泄漏很少真出在框架本身，多半是没人管生命周期的缓冲区和监听。界面早就没了，订阅还挂着，数据还在往里灌。Agent 应用的数据流比普通 App 密得多，这种小口子会被放大得特别快。

[Kayne @StocksFromZero]

@XikCJY 很认同。AI 让造一个看起来很热闹的东西变得太便宜了，假数据几分钟就能铺满一页。也正因为这样，敢留一个诚实的空页面反而更难，那等于承认现在还没人来。可冷清是真的，后面每来一个真用户也都看得清。

[Kayne @StocksFromZero]

@CY160909 长得都一样，多半是因为没人告诉 AI 这个产品给谁用。给设计师用的和给父母辈用的，信息密度、字号、按钮大小都该不一样。用户是谁得由人先定下来，AI 才有理由做出差别。风格可以借，用户是谁借不来。

[Kayne @StocksFromZero]

@ChuckBass14291 记忆难的不是存，是哪些该忘。项目的长期规则和这一次的临时状态混在一起，它记得越多，越容易把上周的临时方案当成定死的规矩。比起让它记住更多，先把「一直成立的」和「只管这一次的」分开放，可能更管用。

[Kayne @StocksFromZero]

@jackcorleone19 写代码更该在意质量。错一次，返工的不只是那几行，还有后面跟着它写的东西和花在排查上的时间，比慢几秒贵得多。速度只在小步来回改的时候值钱，改一下看一眼，快才有意义。

[Kayne @StocksFromZero]

@chenYijl AI 写代码时顺手装个依赖，可能是最容易被忽略的口子。改的代码好歹有人看 diff，新装进来的包却很少有人点开看是谁维护的、带进来了什么。把这一步拦在机器层面，比指望人每次都留意靠谱得多。

[Kayne @StocksFromZero]

@chasen_liao 不用每个都追。手头的活跑得稳，就先别换，换一次模型要重新摸它的脾气，提示词和工作流都得跟着调。等真的卡住了，再带着那个具体问题去看新的，比盯着发布会和榜单有用得多。

[Kayne @StocksFromZero]

@ReignSwords Agent 长会话的钱，大头不在它新写了什么，而在它一遍遍重读的那些上下文。固定的规则和说明放前面，变化的放后面，缓存才吃得上。提示词怎么排，比换个便宜模型更值得先想：后者压的是单价，前者省的是每一轮都在重复付的钱。

[Kayne @StocksFromZero]

@tvytlx 写了十一年 iOS，最清楚的一件事是：代码跑起来不难，难的是产品该长什么样。哪个按钮放哪、哪一步可以省掉、用户第一眼看到什么，这些决定比代码本身难得多。按长处分工挺好，只是最难的那部分还在人身上。

[Kayne @StocksFromZero]

@Lazily57 AI 把做功能的成本压得这么低，最容易出的问题就是先做后想，做着做着就停不下来。动手之前，先找几个真的会用的人聊聊，问他们现在怎么解决这个问题。这一步花不了多少时间，却能省掉后面很多白做的功能。