文章总结： 本文基于作者使用ClaudeCode和Codex完成20万行代码项目的实战经验，探讨LLM时代软件工程的变革。核心观点包括：应抛弃Java等重型框架转向Python/Golang/Rust；开发者需强化问题域定义能力而非依赖AI生成代码；大型项目管理需通过全局规划和高强度重构控制熵增；AI订阅成本实际低于外包且效率更高；小型软件无需学习编程，但大型工程仍需传统经验支撑。 综合评分： 85 文章分类： 实战经验,解决方案,技术标准,AI安全,其他

最近1个月的LLM Coding观察和讨论小结

原创

黄师傅 黄师傅

黄师傅的赛博dojo

2026年4月21日 13:24 上海

在小说阅读器读本章

去阅读

导语

在 LLM（大语言模型）和 Vibe Coding 彻底改变代码生产方式的今天，软件工程的底层逻辑正在发生巨变。

当 AI 能够帮你“手搓”出数十万行代码时，我们到底还需要学习编程吗？传统的后端框架还有意义吗？几千块钱的外包和几千块钱的 AI 订阅，究竟哪个更香？

今天，结合用 Claude Code 和 Codex 从0到1完成一个 20万行代码大型项目的实战经验，我们来聊聊 AI 时代的软件工程与开发调优。

01 抛弃重型框架，Java 的生态护城河正在消失

在讨论后端框架选型时，很多人还停留在传统的思维路径里。但在如今的 LLM 时代，我的建议是：能不用重型框架，就尽量不用。

现在的项目，真正需要的是非常“薄”的通用框架（比如基础的日志框架）。为什么？

在“古法编程”时期，因为人力成本极贵，重新造轮子的质量和成本都不划算，所以哪怕重型框架多出来 90% 你根本用不到的冗余代码，你也只能当没看见。重型框架存在的价值，就是对大量各种各样需求的并集进行抽象和实现。

但现在不一样了。单个项目需要的功能，让 AI 自己生成也没多少代码，干净且极其好维护。

这也引出了一个残酷的现实：Java 所谓的“生态优势”，在目前的 LLM Coding 面前基本不存在了。

新项目的选型逻辑变得非常直接：

• • 没有性能需求： 直接选 Python。
• • 有性能需求： 直接选 Golang 或 Rust。
• • 老项目： 梳理逻辑，然后让 AI 顺着原来的架构继续堆砌。

在 AI 的生成能力面前，语言和 Runtime 根本不存在什么障碍。

02 别用“勤奋的打字”掩盖“无知的定义”

软件工程是一门实践科学（是工学而非理学），理论没啥用，好不好用都是看结果的。

我一直强调一个简单的洞察：目前的 AI 非常擅长“解决域（Solution Domain）”。 你看现在无数的开源项目、Skill 库、框架，谁都可以靠 AI 搓一大堆代码出来。

但这恰恰暴露了当前开发者的致命弱点——大部分人可能缺乏定义“问题域（Problem Domain）”（即定义正确问题）的能力，只是用勤奋掩盖无知。 在不需要你亲自写每一行代码的今天，如果你连问题都定义不清楚，AI 给出的解决域代码再多，也毫无意义。

03 从0到1写20万行代码：如何收敛复杂度和腐化？

目前我主要用 cx 和 cc（Codex 和 Claude Code）写了一个 20万行代码的项目。当然，AI 实际生成的代码肯定超过了 100 万行，多出来的都被重构掉了。

在开发这种大型项目时，如何收敛复杂度和控制代码腐化？目前比较简单有效的方法就是**“一前一后”**的配合，然后持续去执行：

一前（全局一致性计划）：当复杂度上来之后，你要舍得花更多的 token 调查一遍全局的代码，去做更一致性的计划（需要适当权衡，将一部分核心规划放到 AGENTS.md 或者类似的常驻上下文里面）。

一后（高强度降熵）：在一段时间内，比如纯新增 1~2 万行代码之后，必须进行一次全局的高强度审查。核心目的就是“降低熵”——重写、重构、移除兼容和过时的代码、补充测试等。

但这个做法是有一个**“临界值”**的。当前模型的最大上下文窗口、全局梳理代码的时间、以及烧掉的 token 成本，这些都会约束这个临界值。一旦超过了这个临界值，代码的熵值就彻底控制不住了。

其实无论你用啥 SDD（Spec-Driven Development，规格驱动开发） 或者其他什么辅助流派，我的看法是：你必须知道你需要什么，并且能评估这些玩意儿是否产生了预期的效果（比如烧掉的 token、占掉的上下文窗口，到底解决你具体问题的程度有多大）。适合别人项目的，不一定适合你。这一切最终都需要你有相对丰富的软件工程经验和素养作为托底。

全自动开发大型高质量软件的未来，目前都是模糊和不确定的。现在所有路上的过程或者说步骤，都是临时的，都需要不断调整，不存在银弹。

04 Token 比外包还贵？你算错账了

关于成本，最近有一个很有意思的讨论：“现在 Token 这么贵，有时候感觉比找个外包还贵？”

就几千块的外包，肯定不如几千块的 AI 订阅能干：

• • 技术与专注力的降维打击： 一个是技术能力，一个是持续的专注力。外包自带 token 这个事情有点胡扯，真的为了几千块干活的人，能给你买顶级的订阅？用垃圾订阅加上本身的技术能力，大概率只是在给你堆垃圾。
• • 管理成本的差距： 如果上升到一个团队，差距就更大了。管理人工外包的成本损耗很大，而管一个 Agent Team（智能体团队）损耗要小得多。
• • 对于简单的小页面： 其实根本也不需要什么外包了，AI 直接搞定。

另外，目前除了国外的“御三家”（也有低成本的），其他的 token 可以说都是免费的。当然这需要你投入一些时间和精力，去维护自己的底层基础设施（更底层的 Harness）。如果啥事情都要喂饭，或者指望花几十块钱就帮你搞定一切，目前阶段还做不到。

05 终极问题：现在还有学编程的必要吗？

我觉得不太重要了。

对于小型软件或一次性软件： 目前的工具足够了，你不用太担心代码腐化的问题，一次性软件用完即走没啥不好，所以不用学。

对于严肃的大型软件工程： 现在的系统还没太完善（或者说 token 烧得还不充分）。所谓的“屎山”其实就是腐化（既有架构层面的也有代码层面的），但正如前文所说，重写和重构能有效改善这种情况——这些工程的最佳实践都是存在的，并且可以在优化之后被 Vibe Coding 重用。

虽然现在有那么多软件开发的 Skill 库和辅助理念（比如 SDD 规格驱动开发等，我就不点名了），虽然从需求分析开始做也没毛病，但从严肃的软件工程来讲，做得还远远不够，还需要发展。

不过从结果来看，全自动开发大型高质量软件，并不是一个遥不可及的目标。

互动时间：你在使用 AI 写代码时，遇到过“熵增失控”的屎山情况吗？你是如何梳理“问题域”和做代码架构管理的？欢迎在评论区聊聊你的 Vibe Coding 体验！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：黄师傅的赛博dojo 黄师傅 黄师傅《最近1个月的LLM Coding观察和讨论小结》