https://www.yunxiangai1029384756.top/Good Luck To You!https://www.yunxiangai1029384756.top/?id=1<p>欢迎使用Z-Blog，这是程序自动生成的文章，您可以删除或是编辑它:)</p><p>系统生成了一个留言本和一篇《欢迎使用Z-BlogPHP！》，祝您使用愉快！</p>Sat, 15 Aug 2026 15:13:59 +0800https://www.yunxiangai1029384756.top/?id=3<h2>为什么突然想这么干</h2> <p>这周我做了个决定：把 AI 从「偶尔问一句的搜索引擎」升级成「天天坐我旁边的结对程序员」。起因很简单，上个月赶版本，我一个人写了大概两万行代码，其中有一半是重复的样板活。累是一回事，主要是觉得不对劲——这些活明明可以交给机器干。</p> <h2>这一周我是怎么工作的</h2> <p>每天早上先花十分钟把当天的任务拆成小块，标出哪些是「体力活」（写 CRUD、补测试、配参数），哪些是「脑力活」（定架构、抠业务规则、判断取舍）。体力活直接丢给 AI 写第一版，脑力活我自己先想清楚再动手。</p> <p>举个具体例子：周三要把一批老接口改成新的鉴权方式。这种活以前我要花大半天，这次我把接口清单、新旧鉴权差异、几个边界样例喂给 AI，让它先出改造方案，确认没问题后再让它逐个改。实际只花了两小时，其中一半时间还是在 review 它的改动。</p> <h2>几点真实的感受</h2> <p>AI 写通用代码确实快，但业务判断还是得靠人。它会把「你觉得应该怎样」当成事实来写，所以<strong>上下文给得越具体，它写得越靠谱</strong>。最让我意外的是，它写测试和文档比我快得多也全得多，这两样以前是我最不爱干的。</p> <p>打算把这个模式固定下来，再建一个团队共享的 prompt 库，把反复用到的场景沉淀成模板。</p>Sat, 15 Aug 2026 09:30:00 +0800https://www.yunxiangai1029384756.top/?id=4<h2>这个模块的来历</h2> <p>公司有个订单处理模块，五千多行，单人维护了三年，前后经过六个人手，谁都不敢大动。每次加需求，大家宁可在外面包一层，也不愿意往里改。到今年已经膨胀成一座「违章建筑」了。</p> <h2>AI 怎么帮上忙的</h2> <p>我第一步没让它写代码，而是让它先做「分析」。我把整个模块的源码丢给它，让它梳理出：核心流程有哪些、哪些函数被谁调用、哪些是死代码、哪些是公认的危险区。它给出一份带调用图的报告，说实话比我手动翻半天源码高效多了。</p> <p>第二步才是动手。我们按调用图把模块切成 12 个相对独立的部分，每一部分都先让 AI 写一组「行为测试」把现有行为钉死，然后才允许重构。整个过程中 AI 负责生成大部分新文件的结构和迁移逻辑，我负责核对业务规则有没有被改歪。</p> <h2>结果和教训</h2> <p>重构完代码量从 5000 行降到 3200 行，线上零事故，因为每一步都有行为测试兜底。最大的教训是：<strong>没有测试就谈重构，等于在悬崖边跳舞</strong>。AI 让重构的门槛变低了，但它放大的不是你的胆子，而是你的测试覆盖率。</p>Fri, 14 Aug 2026 10:05:00 +0800https://www.yunxiangai1029384756.top/?id=5<h2>事情是这样的</h2> <p>上周我想偷个懒，让 AI 给支付回调接口写单元测试。当时心里想的是：这活又重复又无聊，AI 肯定手到擒来。结果它确实「手到擒来」了——一口气写了四十多个测试，全部绿灯，我差点就直接合并了。</p> <h2>翻车在哪</h2> <p>代码 review 的时候同事问了一句：「重复支付这个 case 你测了吗？」我愣了一下，回去翻了翻 AI 写的测试，发现它 mock 得太「完美」了：所有的校验逻辑都被它 mock 掉了，等于把考试题目和答案一起改了。四十多个绿灯，没有一个真正测到「回调被篡改」或者「订单状态不一致」这种核心场景。</p> <h2>复盘</h2> <p>问题不在 AI，在我给它的指令。我只说了「写测试」，没说「重点测哪些业务场景」。第二次我把自己积累的真实事故案例、边界条件列表喂给它，明确告诉它哪些路径必须真实走一遍，这次它写的测试才算能看。</p> <p>结论：<strong>AI 适合写量大但模式固定的测试，核心业务路径必须由人指定「测什么」</strong>。「怎么测」可以让 AI 发挥，但「测什么」永远是人的责任。</p>Thu, 13 Aug 2026 15:20:00 +0800https://www.yunxiangai1029384756.top/?id=6<h2>事故经过</h2> <p>周三下午两点四十，监控报警：测试环境 CPU 持续 100%。查了一圈，最后定位到一段昨天刚合并的代码——是我让 AI 写的一个数据同步任务，里面有个 while 循环，退出条件写得模棱两可，遇到脏数据就死循环了。</p> <p>当时我图快，想着「这段逻辑又不复杂」，没认真 review 就合了。结果 AI 把「看起来对」的代码写得漂漂亮亮，问题藏在退出条件里，不跑真实数据根本看不出来。</p> <h2>处理过程</h2> <p>回滚只花了两分钟，但排查花了一个多小时。真正的问题在于：那段代码没有日志、没有超时保护、也没有测试，出了问题只能靠猜。事后我补了三样东西：<strong>循环加最大迭代次数、关键步骤打日志、把脏数据样本补进测试</strong>。</p> <h2>复盘总结</h2> <p>AI 生成代码本身没错，错的是「信任来得太快」。现在我的规矩是：AI 写的代码，凡是涉及循环、网络请求、数据库事务的，必须过 review 且必须有一套最基本的兜底（超时、重试上限、日志）。信任是一点点攒出来的，不是一句「AI 写的」就能盖章的。</p>Wed, 12 Aug 2026 11:45:00 +0800https://www.yunxiangai1029384756.top/?id=7<h2>先说结论</h2> <p>用了半年 AI 辅助开发，我发现写 prompt 的能力基本等价于「把你的需求讲清楚」的能力。一个能把需求讲明白的工程师，哪怕不懂任何 prompt 技巧，用 AI 的效果也不会太差。反过来也一样。</p> <h2>五条经验</h2> <p><strong>1. 把上下文喂足。</strong>贴代码要贴全文件或关键函数，报错要贴完整堆栈。信息残缺的时候，AI 会靠猜，猜出来的东西质量看运气。</p> <p><strong>2. 先要方案，再要代码。</strong>让它先讲「你打算怎么改、影响哪些地方」，确认思路对了再让它写。省去大量来回返工。</p> <p><strong>3. 拆小问题问。</strong>一次只问一件事。把一个大需求拆成五步问，比一口气甩给它强十倍。</p> <p><strong>4. 要求它自证。</strong>让它「写完带上怎么自测的步骤」「说明这段代码的边界情况」。等于强制它自己 review 一遍。</p> <p><strong>5. 沉淀自己的 prompt 库。</strong>好用的指令存下来，下次同类任务直接套模板。我现在有一个团队共用的文档，已经攒了三十多条。</p> <h2>最后想说的</h2> <p>工具会一直变，prompt 技巧也会过时，但「把问题想清楚、把话说清楚」这个底层能力不会。AI 只是把这个能力的重要性放大了。</p>Mon, 10 Aug 2026 20:10:00 +0800https://www.yunxiangai1029384756.top/?id=8<h2>流水账</h2> <p>这周没有大版本发布，属于相对平稳的一周。记录一下我这周让 AI 干了哪些活，哪些干得好，哪些还得返工。</p> <p><strong>周一：</strong>写数据迁移脚本。数据库字段要拆表，我描述了表结构和迁移目标，AI 半小时出了第一版，我改了两个边界 case，完成。省了大概一上午。</p> <p><strong>周二：</strong>补接口文档。十几个历史接口没文档，我让它对着代码自动生成，再人工校了一遍。这活要是自己写，我估计要两天，AI 加校对花了半天。</p> <p><strong>周三：</strong>生成了三个第三方服务的 mock server，方便前端并行开发。这个它干得特别顺手。</p> <p><strong>周四：</strong>改一个线上 bug——订单金额精度问题。我给了报错堆栈和数据库样例，它给了两种修复思路，我选了带兜底判断的那种。这次交互很顺，因为它问了我两个关键问题而不是直接开写。</p> <p><strong>周五：</strong>用它辅助做 code review，让它在合并前扫一遍「常见的坑」（空指针、资源泄漏、SQL 注入），发现了两个低级问题，人工确认后修了。</p> <h2>小结</h2> <p>这周 AI 帮我省下的时间，粗算大概三天。但所有产出我都过了一遍，有几处返工。值不值？值。但前提是：<strong>它写，我看，我不闭眼</strong>。</p>Sat, 08 Aug 2026 09:00:00 +0800