ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

AI代码Loop实战:以登录模块为例,解决假达标、空转、结构漂移

2026/8/15 18:54:47 拓冰建站 浏览量
AI代码Loop实战:以登录模块为例,解决假达标、空转、结构漂移 文章目录1. 先唠唠为啥拿登录模块说事1.1 说白了选登录就是因为咱们熟2. 第一关先搞明白啥叫“合格”2.1 很多人第一步就栽了2.2 正确做法把“好”拆成能验货的硬条款2.3 两个小提醒3. 第二关写得不行怎么说才有用3.1 最没用的反馈就是“再改改”3.2 有效反馈公式位置问题级别4. 第三关跑多少轮能停4.1 别只定一个条件得三个搭着用4.2 为啥要组合5. 最容易忽略的坑谁来当评委5.1 让AI自己查自己纯纯开玩笑5.2 正确操作分开干6. 防跑偏定好交付物清单6.1 啥叫结构漂移6.2 清单怎么定最合理7. 跑一遍才知道设计行不行7.1 别觉得设计完就完事了7.2 校准的心态8. 最后捋一遍七步走P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看 传送门https://blog.csdn.net/qq_344193121. 先唠唠为啥拿登录模块说事1.1 说白了选登录就是因为咱们熟做开发的谁没写过十个八个登录页闭着眼都能说出哪容易出问题。评判标准这东西本质拼的就是你对这块熟不熟。你不熟的领域AI写出来花里胡哨你都觉得对熟的领域扫一眼就知道坑在哪。咱们今天就拿最常见的邮箱密码登录说事——登录成了存token就这么个简单需求看看怎么让AI老老实实给你干活而不是跟你打太极。2. 第一关先搞明白啥叫“合格”2.1 很多人第一步就栽了上来就跟AI说“给我写个好点的登录模块。”你品品“好”是啥标准AI听完当场就能给你回一句“写完了效果挺好”——反正好不好全凭它一张嘴第一轮就敢自称达标俗称“假达标”。这就像你点外卖备注“多放辣”商家随手撒俩辣椒面就觉得自己放够了你吃着淡如水它还觉得你事儿多。2.2 正确做法把“好”拆成能验货的硬条款我自己给登录模块定了六条一条比一条实① 编译能过敲个./gradlew assembleDebug得实实在在出BUILD SUCCESSFUL不是嘴上说能跑。② 架构得对上项目原来啥结构就啥结构接口、Provider、Repository、ViewModel、依赖注入别瞎改套路。③ 状态要清晰idle、loading、success、error这几个状态得放在StateFlow里能盯着看。④ 边界情况兜住空输入、邮箱格式不对、密码太短、报错提示这些都得有。⑤ token得存住本地存好重启App不能丢过期了自己清掉。⑥ UI别瞎做主登录不登录全看ViewModel的状态UI别自己偷偷判断。这六条没一个是形容词全是能查、能测、能跑通的硬杠杠。2.3 两个小提醒第一标准必须提前定。别等AI写完了你再补标准那标准铁定被它带着走等于白定。第二得踩过坑才知道加啥条。比如第六条看着不起眼实则是血泪教训——UI自己管登录状态后期bug能追到你秃头状态源一散全是定时炸弹。3. 第二关写得不行怎么说才有用3.1 最没用的反馈就是“再改改”很多人一看写得不对就甩一句“不行再改改写得不好。”你猜AI啥反应它根本不知道哪不好只能东改改西凑凑改来改去原地打转俗称“空转”。这就像你对象跟你说“你错了”你问“我错哪了”对方说“你自己想”——想破头你也想不明白纯纯内耗。3.2 有效反馈公式位置问题级别直接说死哪个文件哪一行出了啥问题严不严重。比如[LoginRepository.kt第15行] token只存在内存里重启就没了 | 严重[MainActivity.kt第20行] UI自己判断登录状态应该全看ViewModel | 中等有凭有据AI才能精准改不会瞎忙活。没证据的反馈纯纯浪费双方时间。4. 第三关跑多少轮能停4.1 别只定一个条件得三个搭着用很多人要么定“达标就停”要么定“最多跑几轮”其实都不稳。我一般三个条件一起上满足任意一个就停① 六条标准全达标了立刻停这是最理想的质量到位了就收工。② 连续两轮没找出新问题停说明再跑也没长进了别在这死磕空转。③ 最多跑5轮强制停万一标准定飘了或者这活AI真干不了也不能让它无限跑下去耗电。4.2 为啥要组合光靠第一个万一标准有漏洞或者AI跟你装达标能给你循环到天荒地老。光靠后两个可能质量还没够就停了白忙活。三个搭着用就是既要质量兜底又保证它肯定能停下来不会死循环。5. 最容易忽略的坑谁来当评委5.1 让AI自己查自己纯纯开玩笑很多人图省事写完让同一个AI自己检查达标没。这不就等于让考生自己改自己的卷子吗它写的时候觉得对的地方查的时候还是觉得对思维盲区焊得死死的。要么第一轮就给自己打满分假达标要么反过来硬挑毛病凑数没一个靠谱的。我见过最离谱的AI自己写的bug自己查三遍都没看出来换个AI一眼就揪出来了。5.2 正确操作分开干一个AI专门写代码另一个AI专门查。俩AI各干各的评审的不用给生成的留面子直接读文件、跑编译实打实验证不信对方的自卖自夸。要是生成的不服评审结果还能申辩一句评审再复核一遍。就这么个简单的分工靠谱程度直接上一个台阶。6. 防跑偏定好交付物清单6.1 啥叫结构漂移跑Loop最烦的一件事每一轮结构都不一样。第一轮校验写在UI里你说不对要放ViewModel第二轮它挪过去了结果把第一轮的UI改得乱七八糟第三轮你发现仓库层又变样了……改来改去不是在优化是每轮都在重构永远收敛不了。就像你装修房子今天改插座位置明天改水管改到最后发现第一天铺的地砖被撬了纯纯返工。6.2 清单怎么定最合理核心文件必须固定每一轮都照着这些文件查。比如登录状态、登录接口、实现类、token存储、仓库层、ViewModel、登录页、依赖注入、入口跳转这些是必须有的。但也别定太死分三档一档全放开AI随便写容易飘二档核心文件必须有想加新文件可以得说清楚为啥加三档严格卡死只能有清单里的文件太僵了。一般选第二档最合适既不会乱跑结构又给AI留了发挥空间。7. 跑一遍才知道设计行不行7.1 别觉得设计完就完事了纸面设计再完美真跑起来总有地方出问题。三个常见故障对着查就行第一个第一轮就假达标。评审全过了你肉眼一看就不行要么标准太松要么评审放水了——赶紧加严标准或者把生成和评审彻底分开。第二个没完没了空转。每轮都有反馈但改了五轮还在同一个地方打转——说明反馈太模糊AI根本不知道怎么改赶紧把反馈补到具体行、具体问题。第三个永远达不了标。跑了八轮质量就卡在那上不去——要么标准定太高了要么这活超出AI能力了该降标准降标准该拆小任务拆小任务。7.2 校准的心态跑起来不达标不是你设计得烂是你没料到AI哪块不行。别死磕设计该改就改。你的设计意图是一回事AI实际能做成啥样是另一回事磨合嘛不丢人。8. 最后捋一遍七步走说白了设计一个Loop就这七步① 选个你熟的需求当载体② 把“合格”拆成能验证的硬标准③ 反馈要具体到位置、问题、级别④ 三个终止条件搭着用⑤ 生成和评审分开别自己查自己⑥ 定好交付物清单防结构漂移⑦ 跑一轮校准有问题及时调全是踩坑踩出来的经验假达标、空转、结构漂移、自评自欺……每一条都是真实踩过的坑照着来能少走很多弯路。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/qq_34419312