用 AI 写 code，前期真的很爽。 很多东西丢进去，很快就有东西跑出来。 UI、CRUD、测试、refactor，体感都比以前快很多。 但我自己用一阵子之後，慢慢发现一个问题： AI 很会让你在前两周觉得自己效率翻倍。 但如果专案稍微变大，後面很可能就开始失控。 --- 我自己最常遇到的大概是这几种： 原本正常的页面，被改一轮之後反而坏掉 UI 理解一直有落差，你以为讲清楚了，它其实理解成别的东西 前面讲过的规则，过几轮就忘 context 很快塞满，品质开始往下掉 换个 session 之後，像失忆一样，很多东西都要重讲 所以我後来慢慢有个感觉： 我後来慢慢有个感觉：AI coding 不稳，很多时候不一定是模型本身不行。 我自己看身边同事在用 AI，很多时候还是这种模式： 开个 chat、丢需求、等它吐东西，不对就再重讲一次。 这样不是不能用， 但很难长期稳定产出。 --- 我自己真正意识到这件事，是去年 Amazon 两次 re-org 之後。 我原本做的是 Payment 系统， 每天处理上百万笔交易，这块我做了三年，算是很熟。 但某次 re-org 之後，我被拉去做一个新任务： 在既有的广告 backend 里， 接一条新的交易流程。 我第一次打开 codebase 的时候，心里只冒出一句话： What the hell did I just get myself into. 主专案很大，很多团队共用，service 之间互相依赖， 很多逻辑不是你看一两个档案就能懂的。 更现实的是，时程也不长。 第一个月要有 beta。 第二个月要完整上线。 那时候我就很清楚， 如果我还是用以前那种方式慢慢看、慢慢接、慢慢查， 风险会很高。 不是那种「辛苦一点还是做得完」的高， 而是你根本很难在有限时间里，建立足够的全局理解。 所以我那时候做了一个决定： 先不要急着叫 AI 帮我生 feature。 先把自己的 AI 使用方式整理起来。 --- 我後来给自己定了一条原则： 任何需要手动重复做，而且超过两三步的事情， 都要想办法系统化。 所以我开始做的事情，大概像是： 把常用操作整理成固定 command 把环境资讯、测试方式、规则整理成可重用的 context 可以平行验证的事情就拆出去跑 比较明确地管理 session、规则和回馈 让 AI 不只是回答问题，而是进入我的开发流程里 这些东西听起来都不炫， 但真正让我後面速度差很多的，反而是这些。 --- 老实讲，第一周这样做的时候压力很大。 因为表面上看起来，你没有立刻产 feature。 我还记得那时候 manager 问我一句话： "You haven't worked on any feature?" 那时候的压力，其实真的很大。 因为在别人眼里，你像是在花时间整理工具， 不是在推进事情。 --- 但我那时候心里很清楚， 如果这套东西没有先立起来， 後面只会一直卡在： context 爆掉 规则忘记 改一处坏三处 测试一直重跑 每次都从头解释 这种状况短期看起来还能撑， 但在大 codebase 里，很容易越做越乱。 所以我後来回头看，那一周反而是最值得投资的一周。 --- 我现在对 AI coding 最大的感想，不是它能多快帮你生出 code。 而是专案一旦变复杂， 真正影响效率的，往往已经不是模型会不会写， 而是你有没有一套稳定的方法，让它持续在对的轨道上工作。 我现在不太相信 「只要模型够强，一切自然会变顺」这件事。 我自己的经验比较像是： 模型变强当然有帮助， 但如果 workflow 没跟上， 最後只是更快把专案搞乱。 --- 回头看，去年那次 re-org 留给我最大的收获， 不是我用了什麽模型。 而是我终於搞懂： 真正的门槛， 不是你会不会下 prompt。 而是你有没有能力，把 AI 变成一套能长期运作的工作方式。 --- 写工程师在 AI 时代的转变 也分享 AI 工作流、创业思维与矽谷职场 矽谷叔叔 Uncle Sam https://www.facebook.com/100063864652124 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 4.16.80.18 (美国) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Tech_Job/M.1774988822.A.61A.html