AI Coding 还看源代码吗？要是不看，会害怕血崩吗？

[edgeedge]

V2EX 帖子，AI Coding 到无法掌控局面： https://v2ex.com/t/1224558

还有报道 AI Coding 9 秒内删除整个业务数据库的： https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database

我个人也有经历。去年 8 月份开始，给公司做一个爬虫项目，AI coding 上功能很快， 住宅 ip 轮换这一块，用的供应商平台接口，自动按城市地区动态返回。 后面对需求，要求每个社交媒体的账户，要尽量固定一个 ip 地址，不能每次发起请求都变。 这个功能也很快用 ai coding 做好。也让 ai 做了测试，没问题，我就交付了。 不几天，几万个社交媒体账户，跑起来。

第二天来，发现，爬取任务的报错率超过 50% ，md,吓出冷汗！！！

然后开始查问题、啃 ai 写的代码; 发现，住宅 ip 供应商给的固定 ip ，很大概率出现 cloudflare/谷歌的 http 测试端点能通，但爬具体的业务例如 x.com 会访问超时。 然后决定，在具体业务逻辑里做 ip 超时的回退策略(超时则重新获取 ip ），当时涉及貌似三四十个工作流，，用的 cursor ……

总共下来化了一两周吧，不在项目排期里的，真特么的焦头烂额的……

为什么前面 ai 测试良好？因为 AI 测试时,是用了洛杉矶等热门地区的账户，可能供应商 ip 充足；爬虫项目为了分摊风险，几万个社交媒体账户有不同国家、城市的。

---

现在 AI 更强，对于 ai coding 的情况掌控，我似乎仅限于这些了：

1 了解和规划项目目录结构，要求按功能领域拆分目录，ai 改的时候，看看它动了哪些目录里的文件。 2 框架和代码组织上，尽量去中心化、模块化，那怕代码重复，也要解耦，减少怀疑“改了 AB 是否被牵连” 3 好像也没了，就看看每次它新增和删除了多少行代码，和预期是否相符。

我今年都是离职自己玩（闭门造车）。不知道现在阶段了，各位 AI Coding 时，是如何保持，对项目掌控方面的自信心？

或者说白了，就是你让 AI Coding 时想爽，但是否会担心，或做些什么，来保证自己对项目的持续开发、持续维护、甚至上线，都仍然有信心担责？这方面你会用些啥策略，或行为吗？

[thinkm]

自己的项目，之前每次都看改了哪些，后来有次赶时间，没 review ，后来再也没看过了

[MHPSY]

我确实会担心 但是目前一个礼拜的任务已经压缩到一天了 我也只能差不多就行了 大概看一下关键的节点 能行就提交了

[Mandelo]

所以上了 codex ，之前 DeepSeek 老给我把别的改坏。或者你让他添加记忆，修改业务代码先检查影响范围

[UmiKz]

血崩倒不至于，就是有些你可能只要优化调整几行代码的，它有可能给你来个上百行多个文件协同调整，调整就罢了，后续你来一句，还是改为原来方案把，它又给你来一顿操作....都是烧的 token

[seekerZhang]

会看的，而且我从来不给很足的权限，怕有注入，同时做完任务，会交替 code-review

[NQ]

建议别看，看的越多 git reset 越多

[ethanwan9]

@UmiKz 是你自己的问题。不会用 git worktree 吗？

[yshan]

你这属于场景没覆盖到，或者就没想到，review 估计也发现不了吧

[snarkprayer]

根本来不及看

[ffalex]

对于自用的项目，你不要老是骂她，调查她，她自己可以做得很好

[c0nstantien]

多看设计文档，少看代码，文档挑方案设计看，实施文档不看，有不明白的直接问，问多了让 ai 出产品文档

[nc]

不算暴论吧，AI 写的代码一眼都不要看，让 AI 写测试验证代码，前提你用的是前沿模型。不同意本观点只能说你 vibe 的不够多

[jaskle]

根本看不过来的，改动少用 ide 看看哪些地方动了。改动多就问他逻辑，看看和预期实现的有没有差异。完全不看会导致上线后逻辑对不上，不闭环。注意不是为了找 bug ，bug 几乎没有，主要是逻辑是否完整实现，是否有偏差。

[7beloved]

自从 codex 自己有 code-review 就再也没看过

[7beloved]

组里但凡日用 1Btoken 以上的，我觉得都是不看的，因为根本看不过来，我日用差不多 0.5B

[duanxianze]

我反正是肯定要看的，除了在初始化这种大规模创建代码可能看不全，单独的 bug 修改或者小需求我肯定要自己看一遍代码

[JYii]

重点项目，只让 AI 修改关键点，然后人力来串起来。
非重点项目，一眼都不看。

[lm1368]

@thinkm 这种事情当然是有一次就会有无数次啦😂

[bbxx11]

不看代码，ai 就会用惯性经验给我整代码～

[dwSun]

不需要，让 AI 自己编写一堆测试，测试通过就放心上线就得了。

[Dengddd]

用 sol 和 fable 写的从来不看
其他的模型我会看看思考过程，代码不看

[liushuang]

早崩晚崩，早晚会崩，放心吧，不管你咋写都会有问题的。我是反复拷问，把它当骡子就行了。

[dinjufen]

曾经一次修改几十个文件，怎么看？后面就完全信任 AI 了，看个 der

[balusch]

@ethanwan9 这个场景和 worktree 没有关系

[edgeedge]

@yshan 是这个理，，，
但若不是 AI Coding ，而是自己一行行写的话，我估计当时首先可能不会慌，而是立即就打开 IDE 看代码了。。
觉得主要还是掌控感方面问题：东西你不熟，责任要你来担。自己写的代码是：东西我熟，责任我担~

[jakson]

看场景，如果是公司场景，重点环节得生产环境必须得看，还得 codereview 。 比如我现在负责的项目，稍微一点 bug 就是影响上亿的用户，组内允许 vibe coding ，但是禁止不 review 上生产环境

[edgeedge]

觉得真正专业的 AI Coding ，应该做类似元编程的东西，我不看代码，但是我要把涉及编程的高维规范抓起来：
框架设计（代码怎么组织怎么管理）、开发规范（功能怎么增删改查）和验收测试，抓在手里，而且不能仅仅是通过提示，而是要用可执行的 tool 、skills 、harness……

用于检查 Coding 规范的 tool 、harness 本质也是代码。所以说白了，就是用一个代码仓库，来‘驱动’一个项目。
不看源代码，但是要搞项目‘驱动’。把 ci/cd 、devops 那一套再扩大一圈，把 AI Coding 也纳管

[flyxl]

写好 review 规则，开一个全新的会话让 ai review 代码，指出架构问题。然后就是让 ai 写测试，改完代码跑一次回归测试，再然后是人肉测试。。。

[zuokanyunqishi]

@dinjufen 改十几个文件,你也敢提交..

[fanhed]

只看 spec, 具体代码已经来不及看了

[msg7086]

> 但若不是 AI Coding ，而是自己一行行写的话

自己一行行写那么多代码早就加班到猝死了。

> 吓出冷汗

吓出什么冷汗，只是个公司业务而已，报错率高就高了，让 AI 快速排查原因就完事了。你们都代码写完直接上生产了，想必本来也对产品质量没有变态苛刻的需求，遇到问题原地迭代再上线就行了。自己吓自己。

> 是否会担心，或做些什么，来保证自己对项目的持续开发、持续维护、甚至上线，都仍然有信心担责

我用 AI Coding 如果出了问题，那就是我测试用例写得还不够，AI code review 做得还不够暴力。Vibe 时代，代码可以被看成是黑盒，你要做的是在黑盒之上，用测试，用流程，用行政角度的方法，去保证这个黑盒的可用性。纯 Vibe 项目我几乎不会看实现，而且很多时候我也看不懂，因为我不会要求他用我能看懂的语言来写。我只关心行为是否正确，所有的功能是否都由测试覆盖到了。

之前 vibe 了一个字节码反编译器，大约 20 万行代码，两三千个测试用例，全方面覆盖所有代码细节，用官方测试自己编译器的压力套件来测试我自己的项目。那至少我知道我的项目可用性和官方编译器的可用性会在同一个等级上。那我也不可能自己去读这 20 万行代码吧。

[edgeedge]

@msg7086 😄😄，很多事情，我觉得都是自己吓自己吧，天塌了有高个顶着？……但不争气的人，就是会很难说服自己。

可能一开始就是没处理好，面子 + 入了局：用 AI 快速交付了，产品那边会觉得你很屌，但你 AI Coding 了多少，一开始就没和别人说清楚，暗暗享受了 AI Coding 的爽。现在出问题了，然后能不能修复、修复需要多久，心理没底。就像是做了把小偷。

现在不看代码的信心是更足了，去年那时候，我记得 AI Coding 还经常陷入死胡同、对库/框架的运用-常常是旧版本的记忆-要人类去把最新文档查出来给它之类。

[ArrayBuffer]

应该重视软件测试, 保持尽量高的测试覆盖率, 也可以专门用单独的 agent 跑 code review, 可以在不做人工审查的情况下最大程度避免出问题

[bigdogbigpig]

准确的来说，我连 ai 写的代码用 ai code review 都不做。

我觉得最关键的是测试，测试能到什么级别，决定了 vibe coding 的质量。

[JasonYip]

前面也有说的 就是单测覆盖率 交叉 CR ，对抗性审查 还有就是 spec 文档画一下类图 人工现在只能看看关键 service 逻辑了，然后最关键还是沉淀团队的规范，这个是最大的资产。另外，自己写说不定有些 bug 和问题也根本发现不了。

代码设计的时候用一些 grill me 的 skill ，在写代码的时候尽量对齐 llm 理解你需求的语义空间

[sakurajiayou]

我写了十几年代码了，去年就不看代码了，全部 AI ，错了就让它继续修复

[zch693922]

拼好码 一步步引入熵增 不加控制任由发展 只会越来越难以维护
问题就在 谁来背锅呢 将来要背锅的人 不 review 控制的话，呵呵

[HetFrame]

早晚会崩，vibe 开发的人爽得很，只有接手项目解决问题的人才知道有多痛苦

[QlanQ]

我还是会看的，如果改的太多，可能看的少了
上次让 ai 写了个需求，我自己测试的时候总是出问题，到处都是问题，没办法我就 一点点看了，感觉还是不太行，就算你让 ai 写了测试，但是你不看测试代码，不还是不知道有么有覆盖完整么？
我反正是不敢完全放手的，我现在，先汇总大的方案，然后拆分 让 ai 一部分一部分的改，写一点我验证或者简单看看，然后 提交，然后 ai 改一下部分，来减少一次审查的范围。

[ethanwan9]

@balusch 你看我回的谁？

[balusch]

@ethanwan9 #40 我看了你回的谁, 所以才说这个场景和 worktree 没有关系

[ethanwan9]

@balusch 没话说