代码让 AI 写，责任还得人背：HN 在榜 15 天的争论，卡在谁按下发布
Hacker News 上有个帖子，2026-10-20 发出来，到 2026-11-08 还在榜上，分从 177 涨到 620，评论七百多条。问题不长：现在用 AI 写代码、赶着上线，等于发出去一个自己说不清楚的系统，逐行读太慢，读完了代码又改了三版，你怎么处理？
一个在榜 15 天没分胜负的帖子，往往比那些一边倒的热帖更值得看。它是一道没有标准答案的题。每个人手上都堆着同样的处境。这篇把高赞回答里的几派做法拆开，最后给出我自己怎么划这条线。
一、问题本身：交付一个说不清楚的系统
发帖人转述的是一位 Meta 工程师的说法：AI 写代码、快速发布，代码在变成黑盒。逐行检查 AI 生成的代码太慢，慢到你最终交付的是一个自己并不真正理解的系统。
这句话戳中的，是写出来的东西责任落在谁身上。代码是人签的字。你合进去的每一行，出了问题都是你的系统、你的事故记录。可现在生成的速度超过了你理解的速度，中间的落差就是那 620 分在吵的东西。
二、主流答案分三派
我把讨论里反复出现的做法归成三类。
第一派，人管设计，AI 管实现。这是人数最多的一派。做法是：自己先在抽象层定好模块、接口、哪些字段和不变量不能动，用一份伪代码或设计稿卡住，然后让 AI 只去填中间的空。有人专门写一份临时 Python 脚本，把方法签名、领域模型字段、关键不变量写死，不关心的地方留空。核心逻辑是 AI 可以负责具体实现，但架构、边界、接口必须人掌握。
第二派，小步走，提交权不放手。有人把任务切到很小，每次先花十来分钟和 AI 把方案聊透再动手，像跟一个同事对需求那样提问。最关键的一句是它不提交、由我提交。代码可以它生成，但什么时候进仓库、进哪个分支，决定权留在人。另一派的做法是先让 AI 生成一份 Markdown 计划，自己编辑这份计划，再交给实现 agent 执行，先审计划再放行实现。
第三派，按风险分级。有人引架构投入应与风险成比例的说法：能回滚、能做 A/B 测试的代码，可以审得松一点；安全、可靠性、长期维护有硬要求的部分，还是得人盯。不是所有代码都值得同等较真，把力气花在会出事的地方。
三、反例：只看说明就合的人，在赌什么
讨论里也有人走完全相反的路。一位说自己在大厂做资深开发的回答者，做法是读完改动说明就合。他不管代码可维护性，理由是往后来的模型更强，眼下这堆代码后面会有更强的模型接手。功能能不能正确交付、能不能尽快上线，在他看来比代码长期健不健康更重要。
这条在评论区吵得最凶。反对的人说，让 AI 对所有决策都做主，最后会得到一团谁也不敢动的泥球，改一个小需求要动很多文件，技术债越滚越大。也有人把问题从个人工作流上升到组织。如果公司只追速度、不建质量责任和代码评审机制，个人很难独自维持质量。项目两年后技术债爆发时，当初的人可能已经跳槽了。
这两派都没错，赌注不同。一派赌模型会越来越好、眼下的烂代码会被未来接住；另一派赌系统会活得比模型迭代周期更长。
四、我的读法：信任边界画在哪
我的判断（属推断）：这个帖子在榜 15 天分不出胜负，症结不在大家没想明白。答案不在代码里，在你团队的信任边界画在哪。
同样用 AI 写代码，有人睡得着有人睡不着，差别不在模型，在人握住了哪几个决定权。我把它收束成四根线：
设计权，模块怎么分、接口长什么样，不能交给模型拍脑袋。 测试权，AI 生成的代码必须有你写的、它不能自己改的验证，行为对不对以你的测试为准。 提交权，什么时候合、合进哪个分支，人不放手。 回滚权，万一出事，你能不能把它干净地撤掉，这决定了你敢松手到哪一步。
这四根线握住了，剩下的实现可以放手交给 AI，交付速度上去了，责任还是你的、可控的。一根都没握，那 620 分的争论就落在你头上：你发出去的是一个说不清的盒子。
五、未核实与边界
- 讨论页数字（177 到 620 分、761 条评论）来自本机
data/world采集缓存（10-20 到 11-06 逐日快照），帖 id 50151036。各回答者的立场为我当天实读讨论页（WebFetch）整理。个别回答未标注点赞数，文中按出现位置而非高赞排名转述。 - Meta 工程师的说法是发帖人转述，非 Meta 官方表态，属二手。
- 我方未实测：没有复现任何一种做法，四根线的划分是我的归纳，不是 HN 共识，也不构成方法论背书。
- 本篇不涉及任何具体公司股价、标的或投资建议。
以上为技术信息梳理，不构成任何投资建议。
标签：#AI大模型 #AI编程 #开发者 #技术前沿