← #794

我要回去亲手写代码了

查看原文 HN 讨论

文章摘要

作者是 Kubernetes 终端面板项目 k10s 的作者。标题看起来像反 AI 宣言，但读完会发现他真正主张的是”架构先靠手写，实现再交给 AI“。过去 7 个月他用 Claude 一路”vibe-coding”做 k10s，快速堆出了一堆功能，但最近他发现这种”快”是一种幻觉——表面上 feature 越来越多，内部架构却在悄悄腐烂。他给出了一句很扎心的总结：”AI 写功能，不写架构。你让它没有约束地开车开得越久，事故现场就越惨。”

文章列出了 AI 编程的五大典型问题：第一，没有架构愿景——AI 倾向于把所有状态塞进一个巨型 struct（god object），因为这样最快满足 prompt，而不是因为它是好设计。第二，功能堆积——廉价的功能生成制造了”速度幻觉”，让 scope 不断膨胀，最终复杂度爆炸但你看不见。第三，位置数据——AI 喜欢用字符串数组配 magic index number，列一重排序列逻辑就崩。第四，状态隔离失败——没有强制的视图边界，每加一个新功能就要在代码各处撒 if 判断。第五，并发违规——后台任务直接写共享状态而不是通过 message 传递，制造数据竞争。

作者给出的解法不是”放弃 AI”，而是先写一份 CLAUDE.md——把架构规则用人类语言写死，作为 AI 必须遵守的不可变约束，然后再让 AI 在边界内实现具体功能。文章实际上是写给”过度信任 AI 自由发挥”那一派的清醒剂：人类判断在设计阶段仍然不可替代。

HN 评论精华

1. pron（最热门长评）：AI 在初期阶段写得”看起来还行”，但随着需求演化，模型缺乏判断力去识别”什么时候该推翻原有策略”。它会用”复杂、不可维护的代码”去掩盖更深的设计问题。”30 个 change 之后这玩意儿基本就救不回来了”，而 review 又往往被跳过——这就是 AI 编程最致命的循环。

2. K0balt：分享自己的反例——他强调”文件级粒度（file-level granularity）”+ 严格模块化，AI 出问题的可能性大幅降低。

3. senordevnyc：用 AI 做出了一个 ARR 35 万美元的 SaaS。关键纪律是：planning mode 先想清楚、把任务切小块、只对关键路径做严格 review、定期主动 refactor。

4. dkersten：抛出“Review 悖论”——”读 AI 生成的代码花的时间比自己写还多”，这等于抹掉了所有生产力收益。

5. eatsyourtacos：反驳——AI 真正擅长的恰恰是快速架构改造，比人手 refactor 快 100 倍；但 pron 反驳说模型不会主动告诉你”现在该改架构了”。

6. SpicyLemonZest：精准观察——”Go 不管架构好坏读起来都很顺”。代码可读性本身并不能暴露结构性缺陷，只有熟悉这门语言的人才能直觉到问题。

7. ok_dad：直白论断——糟糕架构来自人没盯紧，跟语言选什么没关系。”在任何语言里，好架构对有经验的人都是显而易见的。”

8. hansmayer：讽刺式评论——一边拥抱 AI 一边”逃避抽象”，本身就是一个矛盾的依赖陷阱。

9. ChicagoDave：建议把领域驱动设计（DDD）当成 AI 编程的前置技能——大部分被 AI 坑的人其实是底子没打好。

10. tinyattackcat：情感层面的最后一句——”和 LLM 一起写代码，把写软件的乐趣全吸干了。”

11. 共识：生产力提升真实存在（2-10 倍），但需要监督；AI 顶替不了“什么时候坚持约束，什么时候放弃约束”这种判断——而这恰恰是工程师的核心价值。