
我写公司的一些底层框架,说个需求让 AI 嘎嘎给你一顿写,乍一看也算是实现了,但是细节太难受了,这里不考虑缓存击穿,那里不考虑性能问题。
有啥技巧没?请教一下大家
1 Lockeysama 1 月 16 日 现阶段写服务端程序就是帮你提提效率,想完全不用管是不太可能的。即使要求先规划各种 TDD 、BDD ,在实际开发中,还是会漏。 |
2 NoobNoob030 1 月 16 日 1. 拆分复杂需求 2. 分步执行,或者列出 TODO List 3. 大致描述实现思路 4. 关键业务代码给出注释 说白了,你描述的越详细,AI 写的越能符合你的预期。表达能力是 AI 时代很关键的能力 |
3 hitrip 1 月 16 日 Speckit (需求复杂) -> OpenSpec -> Superpower -> Planmode (需求简单) 认真回答他们提出的问题。 |
4 JYii 1 月 16 日 你真信他们啊,现在即便是小需求,我也要先沟通项目现状、需求背景、变更要点、涉及模块、实现方案,老老实实让 AI 写篇文档出来,再去执行。prompt 写的再好,那能套到所有项目上吗 |
5 HtPM 1 月 16 日 确实有点难受,我现在只让 AI 写一些功能函数 |
6 94 1 月 16 日 那么问题来了你的 “说个需求” 是怎么说的? |
7 8355 1 月 16 日 技巧问 ai 诶 |
9 dnfQzjPBXtWmML 1 月 16 日 写详细的 spec 可以让 ai 生成还不错的代码,然而对于熟练工,写详细 spec 的时间可能就把代码写的差不多了(有高效的补全帮助下) |
10 vipfts 1 月 16 日 提示词工程师, 薪水很高的 |
11 Tengdw 1 月 16 日 “但是细节太难受了,这里不考虑缓存击穿,那里不考虑性能问题。” 你给 AI 的文档或提示词中有提到关于这两个地方的缓存或性能问题吗?如果你没提到他不写也是正常的 这种可以在计划模式中多和他讨论下,提到他应该关注的地方让 AI 自己把文档补上,后面编码时就不会漏掉了 |
12 yukiir 1 月 16 日 前段时间做了个外包小项目,写的时候挺爽,现在要重构痛苦死了,写得比我还屎山。 |
13 eleganceoo OP @Lockeysama 是的,漏了一点,想要 AI 帮我补上,真的是拆东墙补西墙。越跟 AI 描述,越暴躁了 |
14 Kirkcong 1 月 16 日 大概率你的描述太宽泛了,一般让 ai 写代码都是对某个具体的功能,比如写一个处理消息队列的接口用于暂存订单信息,并发访问量可能会有 xxx ;而不是 造一个外卖订单管理系统,供 10000 人使用。 第一种说法明显就是程序员在写代码,第二种一看就是项目经理在 yy |
15 eleganceoo OP @NoobNoob030 我是列出我大部分思路了,也基本实现了;就是我发现他各种细节问题时,让 AI 修复太难了,越修复,漏洞越来越多了 |
16 eleganceoo OP @JYii 他们天天说一个月不用写几行代码了,我也想摸鱼,我也要搞个 AI 工具人帮帮我,真的是急死我了 |
17 shakaraka PRO 在做新需求前,先沟通实施方案,最近几个需求我和 AI 反复完善了具体的文档,1 万多行+,然后才开始让他开发的。模型在这个时间点我推荐用 codex cli gpt-5.2-codex Extra high ,跑一两个小时就差不多弄完了。 但是但是但是。你还是需要在他完成任务后,让他 review ,至少 4 轮。每轮 AI review 后你都要人工 review 。 不过即使是这样,效果也不达预期的 90%。只能说你从开发者变成了指导者,最终的代码你是要负责的,看上去省力,实则你的代码只能 AI 去改,这时候再人工的话,就很难了。 |
18 eleganceoo OP @94 功能基本都实现了,细节一堆问题呀,不敢用到实际项目上去 |
19 zzk037 1 月 16 日 现在是在用 openSpec + claude code 去处理。大体流程是先使用 openSpec 在项目中初始化,初始化后会有一段提示词,在 idea 中启动 claude 去输入提示词,claude 会基于这个提示词去项目中提取基础的规则和技术栈,然后就是在继续输入对应的需求然后改改改,最后确认了在实现对应的需求。感兴趣可以了解一下对应的规则: https://github.com/Fission-AI/OpenSpec 。 总体来说一些简单需求实现比较符合预期,可以通过输入输出的方式去实现代码,而不是手法编程,缺点也有,一些约定俗成,不在代码中体现的只能一个项目一个项目不断输入,体感不好,复杂需求实现起来最好还是拆分再去实现,这样比较不错。最后还是有一些不如意的,只好不断地输入在更改,使用 ai 改变了我的编码习惯,从边想边写到等 ai 工具的思考时间。 整体提效差不多 40%-100%(看业务复杂度),前期有学习成本。 |
20 hackyuan 1 月 16 日 我遇到的问题是优雅、分层、结构很好的项目 AI 能借鉴上下文写的大差不差,如果本身就一般让 AI 堆只能说迅速变不可维护的屎山。 |
21 eleganceoo OP @Tengdw 没说,它给我回答的时候,叭叭叭的说了一堆优化了什么,性能更好 |
22 Lockeysama 1 月 16 日 @eleganceoo 哈哈,接受现实就不会那么容易暴躁了。 这种情况下,上下文已经基本算是污染了,继续同一个会话跟 AI 聊,会被反复摩擦。 我的做法一般是,新开一个会话,按照 hotfix 的思路,先给 AI 提供问题和线索,然后让 AI 先分析修改方案,讨论到你满意后,重新让 AI 执行开发。这样大概率能比较好的完成。 |
23 eleganceoo OP @shakaraka 对对对,我后面气不过,只能自己去改了,其实差不多就是重新写了一遍 |
24 luckzk 1 月 16 日 我现在是让 trae 给出方案、架构,然后具体的东西让 gpt 去写,后端功能好写,但是前端 AI 看不到,这个就很烦,我也崩溃好几次了 我是完全不会写代码。。。。。。 |
25 94 1 月 16 日 @eleganceoo #15 ,当成一些实习生或者初级开发来用就好了。很多细节和坑就是要明确提到的,不然就是会掉进坑里面去。换成 AI 就变成要变成文字落到开发文档里面去。 少了很多提示,就会变成像我们刚接盘一个项目时一样,会不知道项目有哪些已经写好的 sdk 或者 utils 可以调用,然后反复造轮子。 或者像时间太久远的项目,修改 A 功能可能会影响到 B 功能,在缺少测试覆盖的情况下很可能因为遗忘的缘故造成出现意料外的 BUG 。 毕竟现在的 AI 还需要受限于上下文的限制,软件工程相关、开发经验这些和资深开发还有明显差距的。如果到这些都不需要人来介入了,那研发岗就真的完蛋了。 |
26 forbreak 1 月 16 日 我猜会有一堆人说你提的需求不对不够细。巴拉巴拉。 其实是 ai 上下文还是不够的,复杂的问题。联系多的时候很容易跑偏。 写框架级别的底层的,你需要一个方法一个方法的让他写。然后写一个验证一个。不能完全交给他。 那些说用 ai 开发了什么什么的,全程不参与的。其实就是只是能跑而已。 |
27 javalaw2010 1 月 16 日 把 AI 当成工具,而不是同事。 |
28 geminy066 1 月 16 日 我现在用的是 claude code + glm4.7 , 开局前:先让 gemini 3 pro 帮忙构建项目文档,以及初始化 claude 时的 claude.md ;用 figma 设计原型; 开局时,让 glm 阅读产品文档和 claude.md 。然后 glm 一顿操作下来,网站能跑,样式大致上和 figma 一样(如果直接用 figma 的原始代码,那还原度更高)。 也就是说稍微调教,开局的作品能有 70 分左右; 调教阶段(包含 UI 校准,和功能调试)后能达到 80 分; 但是想达到 90 分+, 很难,需要人为修改或者和 AI 频繁交互,比较消耗精力。我还没想到好的方案。 PS: 之前用过了 Cluade sonnet 4 ,分数稍微高一点,但奈何被封了(- -|||) 我现在试图想让 AI 自己发现问题,自己修改,但是似乎 AI 意识不到哪里有问题。。。 |
29 eleganceoo OP @luckzk 前端代码更多,更容易出错 ![]() |
30 94 1 月 16 日 @eleganceoo #21 ,已经有很多基于 speckit 的 AI 编程分享,可以借鉴别人的经验。而不是自己埋头尝试了,现在已经不是 2025 年初大家都懵懵懂懂的阶段了。 [第 057 期:我总结了程序员靠 AI 做独立产品的可靠开发流程 - Robust: 程序员的 TALK PLACE]( https://www.xiaoyuzhoufm.com/episode/694ea7b1efa9eb089958c7bb) [第 196 期 AI 编程学来了 - 后互联网时代的乱弹]( https://www.xiaoyuzhoufm.com/episode/6959460312e0e3ae757139d2) 这两篇播客是我能立刻找到最近这段时间听到的相关分享。可以借鉴改进一下自己的 AI 开发流程。 虽然这种方式并不一定能够比自己写来的快,但是一定可以改善你现在遇到的困境。 |
31 eleganceoo OP @forbreak 是的,我之前一直是用代码补全和单个方法编写;今天想再试下,又暴躁了 |
32 eleganceoo OP @94 #30 感谢,我去看看 ![]() |
33 han3sui 1 月 16 日 什么模型,opus4.5 ? |
34 Revenant 1 月 16 日 说上下文不够的,大概率是没把一个大任务拆成小批量任务让 AI 执行,只要任务粒度足够细,AI 的上下文一般是够的 |
35 chtcrack 1 月 16 日 @geminy066 用 AI 搞了几个玩具,总结下来就是解释型语言用 AI 来搞,会比较麻烦,比如前端 js,AI 不知道会出现什么错误,你必须自己把详细错误告诉 AI,它才会修复. 而编译型语言比如 Rust,AI 写完以后自己会编译,编译报错它自己知道,就会自己修复..不过因为上下文不够长的关系,不能叫它加一大堆功能,绝对出问题..得一点点完成..然后后期加功能什么的,有可能会留下一堆没使用的函数变量啥的,还好编译时有警告,可以叫 AI 消除警告.. |
36 bbao 1 月 16 日 em…… 本周实现了一个需求,我就按照大家常用的方式,让 AI 实现了一下,一个 case 比较多的场景;我 review 了 2 天;现在还有一段代码看的不是那么懂~~~~~~~~~ 下午还得 review 一下。 |
37 zmal &bsp;1 月 16 日 先说说你用的什么模型... |
38 bbao 1 月 16 日 @JYii 能,我们 CEO 可牛了,让 A 老大用 AI Vibecoding 出来前后端实现 ,每天玩儿输出的 DEMO 可开心了;然后让另一个部门 B (负责影视后期,非产研部分)负责人用 AI 输出 视频;然后 A+B 结合起来做出一个工程化产品;让我来落地他们工具输出的作品,形成 APP 平台;我说做不了,老板现在在招人~ |
40 chtcrack 1 月 16 日 提示:AI 上下文有限,你不可能把让 AI 理解你工程里的所有代码(特别是原来就有一堆屎山代码的),你要让 AI 知道你要修改什么,加什么功能,代码量很大的你最好自己心里要清楚,告诉 AI 什么功能模块在哪个文件里,或者告诉 AI 某个函数做啥的.. |
41 potatowish 1 月 16 日 via iPhone 一般是这样,业务>需求->开发->AI , 开发要做的就是把需求细节、逻辑关系整理清楚,提供完整详细的上下文,AI 根据你提供的上下文来编码。你写的越清楚,它的实现越符合预期。说到底它只是个工具,我看很多人是想直接把业务需求说明书丢给 AI ,一步到位。 |
43 joffey 1 月 16 日 @NoobNoob030 “描述的越详细,AI 写的越能符合你的预期”这个观点不太认同,用自然语言没有逻辑错误详细的描述复杂需求,甚至比直接开发更难。其实编程,或者说用高级语言编程本身就是在用逻辑更严谨的语言描述需求,需求的实现是编译器做的。 |
44 RuralHunter 1 月 16 日 还是要 review 的,我让 ai 把我一个 python 批处理数据的方法改成多进程,一个庞大的数据集,每行数据单独一个进程处理,它改完了我大概看了一下好像没问题,一跑,性能却几乎没有变化。我再仔细一看代码,它每次都是把那个庞大数据集传给子进程,在子进里取一行处理。由于我这个所有数据相当庞大,所以它实际上大部分时间都是在进程之间传数据。我把传的参数改成要处理的那一行,立刻就飞快了。 |
45 xsonglive491 1 月 16 日 理想:需求->任务->执行. 实际:需求-任务->调整需求->执行->调整任务->调整需求->执行. 结束的时候,最开始的需求于完成差别太大. |
46 joffey 1 月 16 日 不开源完整提示词或者与 AI 沟通过程的项目,最终成品无论如何复杂,都可以认为是扯淡。 |
47 eleganceoo OP @han3sui cursor gpt5 |
48 eleganceoo OP @chtcrack #40 说了具体模块具体类了的 |
49 eleganceoo OP @xsonglive491 是的,调整需求 AI 就不太行了 |
50 eleganceoo OP @bbao #38 正确的做法,真接了这个活,那就玩完了 |
51 kdwnil 1 月 16 日 我感觉现阶段很尴尬的地方在于,如果要还描述一大堆限定条件和细节说明的话,那我直接写代码不就已经是最简洁的了…… |
52 eleganceoo OP @RuralHunter 还是得自己完成大框架,让 AI 谢谢小函数吧 |
53 sikuu2al 1 月 16 日 最呆 b 的是 我用 cc 有时候某个会话 ai 会完全曲解你的意思 并且在一条歪路越走越远。 反复告知他不是这样他还这样,然而我新开一个会话他就能够秒解决自己刚刚的问题。。。 |
55 eleganceoo OP @kdwnil 天天看帖子说不用写什么代码、超级个体,有点小小的焦虑;所以也想尝试搞一个适合自己的 AI 助手的,目前来看还是只适合简单的需求,大家都有这样的烦恼,那我就放心了 |
56 echizenryoma 1 月 16 日 和人一样,要不断去 push |
57 chtcrack 1 月 16 日 @eleganceoo 目前因为上下文关系,没办法做到一下子只凭一段文字描述就完成所有需求,还是得开懂程序原理的人去一步步叫它完善,修复. |
58 defaw 1 月 16 日 控制粒度,最好逐函数编辑和审查,不然无解,很多东西也不是三句两句你就能给 ai 说明白的,最稳定的反而是一点一点写。 |
59 lixintcwdsg 1 月 16 日 AI 写代码你要放开想象力,比如你这个问题你就要喂给 AI “我写公司的一些底层框架,说个需求让 AI 嘎嘎给你一顿写,乍一看也算是实现了,但是细节太难受了,这里不考虑缓存击穿,那里不考虑性能问题。 有啥技巧没?请教一下大家” 给我一个可以渐进式改善这个问题方案 |
60 pweng286 1 月 16 日 功能拆分后再让 ai 写 |
61 Hyxiao 1 月 16 日 我现在都是文档先行,不管是公司还是个人目录,里面都放在一个 docs 目录,可以 git ignore 掉,然后先跟 AI 沟通几轮,对齐下功能效果,然后将对话细节不断完善在文档中,有点类似于行动计划一样,先列出具体的步骤,完成了就打,逐步去完善,这样即使换了 session ,也可以复用 memory 。 但即使这样,还是难免会出现返工的现象,只能不断地优化文档,尽可能把文档给细化,不断的需求放在不同的文档,然后加一个目录索引,可以指向不同的文档,然后 AI 自己去找上下文补充。 |
62 chtcrack 1 月 16 日 @eleganceoo 你都已经知道具体问题了,就告诉 AI 叫它改进啊...一步步来,这个问题搞定了,新开话题,解决下个问题.. |
63 chtcrack 1 月 16 日 我叫 AI 写的玩具,我观察到问题,就这样告诉 AI,然后它就自己分析解决了. 我的对话:当文章数很多时,点击文章列表里的未读文章会很占用 cpu,但是点击已读的文章则不会,检查一下是什么导致的,看看能不能优化下. |
64 singer PRO 我现在用 AI 写项目写确实不错,但我的开发约束读完,AI 的上下文 70%已经占用了,离谱得很! |
65 Felldeadbird 1 月 16 日 你不要让 AI 去做 0 到 1 的东西。你需要把需求拆分。 例如,你让 AI 做: 帮我实现购物车并且完成微信支付、支付宝、京东支付、银联支付及各种。。。 你一口气让 AI 去吃一个胖子,结果就是崩溃了。 |
66 dyniao 1 月 16 日 如果优化代码,你需要告诉 AI ,千万不要修改不必要的地方。这可以可以保证绝大部分的地方不给你乱改。 |
67 chtcrack 1 月 16 日 @Felldeadbird 哈哈,这肯定不行的,写到后面,超出上下文了,相当于记忆缺失混乱,就开始乱搞了.. |
68 kirch 1 月 16 日 那是你没说清楚啊 过去产品经理不把需求说清楚 不也这样? |
69 Greendays 1 月 16 日 我觉的不太好的地方就是 AI 往往不会主动忘记一些东西,有些功能写出来效果不好,想换个方向实现,这时候往往就会一直纠结在老方法上修改,越来越钻牛角尖。 |
70 DefoliationM 1 月 16 日 via Android 不能直接给一个很大的范围,而是告诉它具体要哪些东西,怎么写,代码风格,当成编程语言的高级语言用。 |
72 snailya 1 月 16 日 我的体会是如果从头开始的项目,且目标不是演示项目,那么很难受。 如果是已经比较巨的项目,加新功能,还是比较爽的。一是它可以模仿你其它 service 的实现风格。二是有的时候我自己都背不下来某个方法在某个类里了,但是只要告诉他大概的名字它差不多就能找到。不过我基本都会告诉我我想怎么实现,不会直接给他说我要一个什么什么功能。 |
73 Felldeadbird 1 月 16 日 @chtcrack 所以要把需求拆分,一点一点去让他做。如果比较重要的东西,一定要写 md 文档,告诉 AI 干什么。明确细节,技术规范。AI 就很好实现功能了。现在 AI 还不能一口气吃掉整个胖子。分餐吃完全没问题的。 |
74 MoozLee 1 月 16 日 只限于 crud 层面,再深入复杂的逻辑还是得自己写 |
75 puduhe1 1 月 16 日 我从来没有写过小程序,然后上个月用 AI,在一天半时间帮我写了一个,叫"孩徒步"现已上线,整个小程序端我没有写一行代码,我要什么功能和 AI 讲清楚,AI 生成,我测试功能,后面慢慢加功能一个月我用了 4 亿 token AI 写代码真的是爽 |
76 MIUIOS 1 月 16 日 鼓吹 ai 都替代程序员或者完全一样代码不写的,大部分是以下几种人: 1.没有编程基础或有一点点,拿着 ai 写了个简单的 demo ,激动的来论坛发 ai 要替代一切了。 2.准备卖课或卖你中转 api 的人 3.准备给你发他的公众号推文。 |
77 yanchongwen101 1 月 16 日 给你一把传说级武器,你也不会用啊? 你就不是这块料,转行吧 |
79 HankYao 1 月 16 日 目前最佳的编程模型 opus4.5 ; 其次,如果用 cursor 你要开 plan 模式,确认清除需求,需求文档.md 中列出来的功能和实施步骤你要过一遍核对无误; 或者,用 kiro 的开 SPEC 模式,也是对清楚需求; 或者,用 claude code 的可以维护好 Agent Skills ,生成一些你们项目级别的 Skills,减少沟通成本和上小文消耗; 总之,AI 的边界不是能力,而是信息不对称,你要做的就是做好编码前的信息对称工作,以及编码后的审查工作。 诸如此类... |
80 kkbear 1 月 16 日 在搜索引擎年代用不好搜索的人,大概率在 AI 时代也用不好 |
81 haria 1 月 16 日 初级程序员的代码我觉得可以 100%AI 生成。坐标某二线大厂,毕业来了之后所有代码都是 AI 生成。 重点是背景文档,以及清楚地告诉他要做什么。 |
82 RaymonR 1 月 16 日 @eleganceoo #49 AI 还是很强大,不过使用的时候得清楚它的能力边界,这个多用用就知道了。我一开始用 ai 写东西,也是一团糟,但现在我真的可以一行代码不写去写嵌入式软件、qt 、go 、前端等,能明显感觉到总体的能力进步是很快的,有时候也能感受到某一次更新后变蠢了 |
83 lostwolfkf 1 月 16 日 最厉害的点在于赚钱,真正干活的人,有多少是干全用 ai 生成的。做个 demo 没问题,现在就是个还行的辅助,当不了主 C |
84 kandaakihito 1 月 16 日 1. 每个人都是自己代码的第一责任人; 2. AI 比绝大多数人都聪明; 3. AI 和你的目的不一定一样,你的目的是在完成任务的同时写出高质量代码,而 AI 的默认目的是跑过测试案例。所以需要你写清楚提示词,或者用各种工程手段来匡扶; |
85 dandankele 1 月 16 日 没啥技巧的。。现在 AI 编程的短板显而易见的。。所以最常用的场景还是局部用 AI 编写,尤其是细节不需要那么多的、比较通用化的地方,让 AI 可以辅助写。其他地方还是老老实实自己手撸吧,再配合一下 tab 补全。 要说一个完整项目让 AI 写,那么这个项目肯定是骗投资人的、非生产级的、规模过小的 |
86 mhycy 1 月 16 日 如果你自己都搞不清楚需求,那么 AI 也搞不懂需求 AI 本质是个渲染器,所以得搞清楚渲染器该怎么用,至少得有个草稿吧 |
87 HotieCutie 1 月 16 日 我也一直在用 AI 完成代码需求,自我感受,AI 确实能完成需求,但是也只是完成快,很多东西它不会自动去封装,抽取,不会考虑各种异常操作问题,或者可能存在的并发问题,所以每次让 AI 弄完,我都要自己检查代码,想完全脱眼不去看,几乎不可能,除非是不重要的项目,出了问题再继续改 |
88 NoString 1 月 16 日 在公司内部我搞了一个基于 SDD 思想的 CC 命令集,目前我的需求在 claudecodecli 中实现起来非常靠谱,模型就是 ops 。你们说不好用有没有一种可能是模型不行?尤其是 glm4.7 这种时强时弱的模型,就是得返工去 Review ,ops 在我看完全具备中级开发工程师的能力,至于国产的几个模型不评价,有些场景还行,但是强度上来就是 ops>其他。ops 出规划,sonnet 去实现,或者用 codex 去实现,写完规划文档和 tolist ccswitch 启动转模型,最后 Review 阶段用 gpt5.1 ,我这做的平台功能我觉得足够复杂( 1200wdau 商业化后端、),反正 ai 能 cover 住,代码也少有 bug ,方案提的都挺不错。 |
89 catazshadow 1 月 16 日 把智障当智能就这样的 |
90 artiga033 1 月 16 日 via Android 只能当实习生用。你算算实习生工资多少,ai 工具才几个钱,是不是就释然了 |
91 labubu 1 月 16 日 via Android op 想象中的 ai:帮我实现一个淘宝,然后喝咖啡等就行了 |
92 glsee 1 月 16 日 现在 claude code 真不需要自己写。 设计,tradeoff 还是得自己做的 |
93 caiyuan 1 月 16 日 只要你交代得够清晰,AI 写得比你好。不要想着让 AI 创造,而是把它当做流水线的工人,首先你得设计好流水线。 |
94 keithwhisper 1 月 16 日 > Here are three approaches with tradeoffs. I recommend Option A. 文档写得好, 设计和 trade-off 也可以 AI 来支持 |
95 glsee 1 月 16 日 @keithwhisper 可以让它自己先设计,评估,但是最终还是需要人选择一个方向 |
96 prosgtsr 1 月 16 日 via iPhone 我最近几天把 codex 干到几次五小时窗口用完了,但是这有个前提 我已经把这个需求囫囵吞枣的实现了一遍,特别是主要流程我已经抽像好了需求和实现,然后一些参数传递的工具我都写好了,这个时候我再让 ai 去在我的基础上去完成我觉得繁琐的部分,或者说完成新修改的需求,这个时候问题不大,可以完全不写代码。 |
97 SchwarzeR 1 月 16 日 via Android 要么自己脑子里面过一遍写成文档 要么简陋的代码加合适的命名和注释把架子打个样 然后让 AI 出计划,做一步 review 一步,有半自动帮忙干体力活 敢大撒把全自动的都是一次性项目居多吧 |
98 mx2dream 1 月 16 日 自己设计一个初步的架构,跟 AI 以聊天模式反复讨论,别真的把它当成纯自然语言的编码方式,要不然怎么叫 vibe 呢。 具体操作是你可以让 AI 以结对的角色向你提问,某些方案需要经过你的确认之后才能开始执行。在经过十几个来回之后,让 AI 把讨论的最新的结果生成一份说明书,达到某个里程碑时进行实例测试和进度评估和后续计划修正,对比最初的产品开发文档并输出一份包含以上至少三方面内容的评估报告,经过跟你的讨论和确认之后,再输出一份下一阶段的开发文档。 弊端:次数或 Tokens 消耗得更快了; 好处:开发效率和质量有明显提升。 |
99 mx2dream 1 月 16 日 还有个体会,就是要强调或者加入过程管理的规则,比如就某些范围和条件进行约束,其它的确保不能动。花大量的时间在互动讨论上,而不是前期讨论太少就急于开始,否则都不用等到后期就会给 AI 擦屁股擦到恶心。用好了会发现比 100 个实习生起到的效果都要好,自己都使用 vibe coding 了,自己的角色同样需要调整和适应,需要代入部分 owner 和 coach 的功能。经过这么切换和沉浸式体验后,终于开始有些暗爽的感觉了 |
100 udisyue 1 月 16 日 @eleganceoo 让 AI 改代码一定要说明别给老子加乱七八糟的封装,就老老实实在给出的代码里修改,不然就会像屎遇上扫地机器人,抹你一地板 |