vibe coding 的代码你怎么放心上线？

那就让 AI 把测试也搭建起来跑。

自己写的/别人写的就放心上线？也许你只是缺个背锅的

自动化测试, 要做到 agent 自我迭代

ai 写完了会自己驱动浏览器、命令行工具或上服务器实测的，比人测的还全面

先自测，再互测,codex 写 claude 测，claude 写 codex 测

AI 写的代码目测比绝大部分程序员写的好。
同时测试覆盖度也还可以。

我自己用当然不放心，但是大多数人写代码都是给老板写的，都是给别人写的，只要说一句，写代码又不会死人，就安心的交付了。

看客户，客户要速度，不嫌 bug 多，弄点灰度、AB 集群兜底就行了，有故障就修。要是要质量，那就老老实实测吧，出了问题也是自己的锅。ai 又不懂业务，不懂客户要什么，没啥办法。

写好文档，把测试方法和边界扔给 AI ，SOTA 模型基本都能搞定

@milkleeeeee 没有人类专业 QA 覆盖的全。

@MindMindMax 是的，但这就不是我关心的事情了，公司愿意花钱请人类专业 QA 最好，反正 ai 测的比我自己一个人测的又快又好

那 leader 按排下属写的代码怎么放心上线的。

我的项目在收尾，刚巧问了 Gemini 这个场景。这句格言引用的很有意思：

Software is never finished, only released.

只要是软件都有 bug ，这不是摆烂的理由，但要接受这个事实，不要因此而焦虑。

没发现 bug 说明根本没人用，追求完美是永远无法发布的。

我只能确保按照我的理解的业务逻辑让 ai 进行测试覆盖，至于你硬要去啤酒馆硬点鲱鱼罐头蛋炒饭，不在我考虑范围内

我以前也很焦虑，但上线了以后发现，也就那样。。关键的东西都走内网，走不了的都在 nginx 层面加 IP 白名单。

自己写代码的时候 我也不放心自己写的代码上线。但是无论任何时候，产品经理都放心得很...

自己再用 ai 过下 cr ，现在发现其实用上 ai 后，整个后端的代码质量是提升的，事故也大大减少

自己先用一遍，就能发现 90%的常见 bug 了，用户一般发现的都是罕见 bug ，用户提交这种 bug 我都是直接给一笔余额，不过不能提现/不能代充

@yidinghe APP 测试怎么搭？我之前没写过 APP 代码，现在都是 AI 写，测试只能自己点点点，但架不住覆盖不全。所以想着有没有什么 AI 自动化测试的轮子

@vance123 有什么轮子吗？

@milkleeeeee APP 的怎么搞？

@wildwind2333 用 ADB 啊，我之前手机发现后退按钮总是不灵，我让 AI 连上 ADB 帮我调试，全程 AI 自己规划，要我帮忙开什么权限我就照做，最后 AI 找出来是有个 app 故意在屏幕上放了一个 1x1 透明悬浮窗，定时抢走焦点导致的。我就取消掉了其悬浮窗权限，问题解决了。

现在的 ai 写代码的水平至少能秒掉 95% 以上的程序员

ChatGPT 家的模型真的太爱测试了，我没有测试的项目他也会自己搭一套。

只要不涉及付钱，放心大胆的搞吧。 我仔细看过了，我比较菜。比 AI 菜多了，AI 都想不到的问题，我更想不到了。

ai 写代码，然后 ai 先 review ，然后人工 review ，关键的地方用 tla+做形式化验证，反正我是这么来的

不放心，我一般会 review 一遍

AI 是这样自我评价的

ai 写完自己验证结果

@break AI 的自我评价挺中肯的

跑了 1 年，我就一个结论。不要相信 ai 写的单元测试…因为他的单元测试永远挡不住问题，永远是看了代码写的单元测试。我现在不 review 代码，只 review 单元测试代码，狗屁的强太多。一半的的测试都是看起来正确。

单独一个 agent 写集成和 e2e 用例，并且人类 review ，然后 simulator 测试，就是比较费 token 。

AI 写的代码人类难以 review. 我一般先 ai 出一个原型然后完善，然后自己调整框架架构，对主要功能流程觉得合理后，
自己先跑跑，收集信息，记录功能性和非功能性问题是否存在，然后解决，迭代几个周期基本稳定后上线拿用户当小白鼠。

上线了再说

同事都用 AI ，还不一定有你测得全，不必内耗
一个 session 写，一个 session 审，直到收敛
不要看代码，只要看更改的文件范围是否符合预期
AI 的单测要有，这是你没有乱改的唯一证据
自己在测试服手动跑一遍 happy path ，unhappy paths 太多了根本跑不过来，有问题是下一个 ticket 的事

如果你自己的想法你应该有明确的产品流程，然后慢慢的测试 bug ，让 codex 审查代码，修改后 claude 在查一遍，第一步能查出非常多问题修复后基本都是没为什么问题。服务器安全可以让 codex 攻击自己的服务器也会很明确安全策略。普通的人写的代码真多还不如 ai 写的。bug 更多。

开发的时候让 AI 遇事不决多停下来问，开发完成之后自己测试常见 case ，pr 让其他模型交叉 review ，就上线，发现 bug 再修呗。

没办法 ai 落地之后 需求给的时间更短了 ai 做完 用 ai review 然后再用 ai 修修补补推上去好了

你要是带过团队，你手下的人的代码你是怎么放心上线的，agent 的代码就怎么放心上线，这有什么区别吗，还是说 agent 开发的代码你直接不测就上线？

boom ，先爆炸，炸一次你就知道了

@milkleeeeee #4 不是很理解，他怎么知道页面里面加载的数据正常呢？ 比如这个查询接口筛选的数据根本就不对。

做好单元测试和回归测试，再完成前端自动化测试，如果接入支付这些重要系统则自己 review 一下

自己写的就更不放心了🤣

听过一个新能源汽车的分享
产品开发本质都是风险管理，只要风险可控范围内不出大问题上线，就算成功

领导都让你娱乐 vibe 了，你还担心上线？

和手工一样啊，灰度/遥测/关键代码保证热更新能力

反正自己不会用，能过测试就行。你们会用自己公司的服务么？

线上崩了关我什么事呢？我只是按领导要求办事，更何况也通过测试那关了呀，除非你公司没有测试。

@wangxiaoer ai 会直接去数据库里查。从调用接口、验证数据库里的数据、确认页面展示它会整个链路查一遍，如果你放心的话它也可以直接查生产数据库的数据

@z1154505909 通透

@MrL21 哈哈

@SuperDaniel313 智慧！

@milkleeeeee 确实

写好测试直接推

不放心又如何，打不过就加入，相信后人的智慧

你们是怎么控制 Ai 不跑偏的 ,我拿 deepseek 写 agent 都按任务切片了,还能自己另辟蹊径跨契约层直接调用..

https://github.com/google/artemis

@0x0x 现在已经有很多类似的开源在做这一块的了。shopify 从 rn 切回 native ，看他们的文章，内部也是实现了一个用来真实验证 coding 正确性的框架

这有什么放心不放心的？那你得想，老板凭什么放心他底下的那些人写完的程序可以上线？产品负责人，他凭什么放心？如果不放心，那就安排测试去测，Agent 又不是不能去测试。老板或产品负责人，他们也都是听测试说有没有问题。那你现在就是这个角色，你要做的就是让测试去做，优化测试的能力，然后相信测试就行了。要不然你自己会累死的。

@yidinghe #22 哈哈哈,我也是这样,一个 1x1 的透明组件导致了很多问题哈哈哈,引入是为了输入法

多写测试，不断总结经验，逐步完善

让 AI 发动自己的雷霆大思考，自己实机测试自己找 Bug ，自己修 Bug

@wildwind2333 #18 这方面叫 E2E ，web 的话 playwright ，ios 的话 facebook 有一个 idb 工具可以通过模拟器让 AI 操作。Android 可以通过 ADB

过度担忧会错失机会，先上线再说

@0x0x 这个看起来不错 试试

看到阿里开源的这个 code review 项目 ，也准备试试
https://github.com/alibaba/open-code-review

不同的项目有不同的技巧的，我在写 tcptun-go 的时候，最简单的验证方法就是给它构建真实环境，让 GPT 自己不断测试完善，验收的时候我只需要看它是不是稳定，是不是真的比别的协议更快。

简单写个单元测试很容易，但是要写出好的测试用例是很难的

生产路径上很多测试用例都是从用户奇奇怪怪的输入累积的，以及测试工程师根据经验构造

我目前的体验是，ai 写的测试基本只能覆盖最基本的路径
而且几个模块耦合比较紧会互相影响的时候，ai 还经常破坏回归，改完这边那边坏了但是没测出来

所以上线之前最好还是自己把主要路径都体验一下，简单人工验收一下