YAGNI（你不会需要它）的核心并非反对设计，而是关于时机。过早构建复杂结构与过晚一样有风险。文章通过作者与Chet的对话说明，YAGNI是一种对时机的思考，而非拒绝设计的借口。

根据您的要求，以下是文章主要内容的重新陈述，保留了关键细节并删除了与主题无关的部分（如赞助商信息）：

YAGNI的真正成本从来不是关于代码本身

文章通过作者与Chet Hendrickson的对话引出核心观点：当Chet提出提前实现一个更复杂的功能时，作者反复回应“你不会需要它”（YAGNI）。这并非反对设计，而是关于时机的思考——过早构建结构与过晚构建同样危险。

YAGNI常被误解为“节俭规则”，即不要写不需要的代码以节省成本。但作者指出，这种理解是错误的，且在当前时代更为关键。YAGNI的真正成本不在于编写代码的代价，而在于投机性结构——在功能需求到来之前提前构建的结构。这种结构会带来两笔账单：

1. 可选性损失：提前构建结构是基于猜测。你准备的功能往往不是实际需要的功能，导致需要两次付出：一次绕过错误的结构，一次将其拆除。即使猜测正确，提前构建也浪费了“等待”带来的价值——等待不是懒惰，而是持有资产。

2. 净现值损失：金钱有时间价值，功能亦然。为三个月后的功能提前构建结构，意味着成本提前、收入推迟。即使预测完美，这种时间错配也会造成损失。

两笔账单独立存在，且几乎总是一致。当它们看似矛盾时（如“后期改造太贵”），那本身也是一种预测，又回到了第一笔账单。

值得注意的是，代码输入的成本从未出现在这两笔账单中。随着AI生成代码的成本趋近于零，节俭解读YAGNI的逻辑崩溃了——如果YAGNI是为了节省努力，廉价生成应使其过时。但事实并非如此：两笔账单（更差的净现值与减少的可选性）在廉价代码时代依然存在。免费生成不会削弱YAGNI，反而使违规更易发生，且更危险——因为你不理解生成的代码。

YAGNI从来不是节俭，而是两条价格理论穿上了程序员的标语。这条标语在AI时代依然有效，因为价格理论本身没有改变。在需要时构建它，不是因为代码珍贵，而是因为未使用的选项更值钱，未支出的资金更值钱——这些在代码变便宜时都没有改变。

根据评论内容，主要观点和论据总结如下：

1. 重构成本下降与代码可删除性 - 评论1（phamilton）：AI降低了重构和零停机迁移的成本，强调快速安全修改代码的能力是首要优化目标。关键引用："The cost of restructuring has also gone down... This is the number one thing I optimize for now: the ability to quickly and safely change significant parts of the code and product." - 评论7（turlockmike）：主张代码删除成本应尽可能低，包括整个应用程序，只要数据可重用。关键引用："the cost of deleting code should be as low as possible... the program itself should be as deletable as possible"

2. 信任与预测的平衡 - 评论2（sebastianconcpt）：执行和重做成本下降，但破坏信任链的成本未降，重写会重置积累的信任资本。关键引用："The costs that didn't go down are the ones of breaking the chain of trust to a predictable outcome... If you rewrite it from scratch that capital is reset on release." - 评论4（marifjeren）：反驳"预测不困难"的观点，认为论证只有在预测困难时才成立。关键引用："The argument only works if prediction is hard."

3. YAGNI原则的争议 - 评论6（Scubabear68）：批评YAGNI被滥用为技术债务的借口，认为许多"不需要"的东西实际是必需的。关键引用："I think a huge amount of technical debt goes straight to YAGNI - devs pretending they are not going to need something that, yeah, they need." - 评论9（gste）：认为YAGNI是过度概括，实际取决于概率和成本权衡。关键引用："The whole YAGNI idea is a massive generalisation by design. Ultimately it depends on the circumstance." - 评论12（esafak）：反对YAGNI，主张代码应面向未来结构化，使用正确抽象。关键引用："You absolutely should structure your code with a view to the future. Easily refactorable code is synonymous with good code."

4. 未写代码的价值与风险 - 评论5（skybrian）：将未写代码比作金融期权，但指出过度使用可能导致无限期规划。强调保持项目最小化、延迟代码增长的好处。关键引用："Kent Beck compares unwritten code with a financial option... It might be used to justify staying in the planning stage and putting off writing code indefinitely." - 评论8（passive）：认为提前构建结构有助于尽早发现需求，AI时代错误成本降低但计算仍需团队自行判断。关键引用："Building speculative structure can be a forcing function to establish requirements... Building the wrong thing is now a much less expensive option."

5. 领域差异与经验价值 - 评论3（zephen）：指出Kent Beck的方法不适用于芯片公司等需要长期、不可见产出的领域。关键引用："Nothing I have read by Kent Beck has ever suggested that he would be useful in a chip company... produce something that no customer can possibly see until it's finished." - 评论10（AyanamiKaine）：强调探索问题方向比盲目实现更重要，批评无目的的实现。关键引用："implementing solutions aimlessly is never a good idea... critizing implementing something just in case because you might need it in the future."

6. 抽象与具体化的权衡 - 评论13（mrkeen）：主张对具体实现使用YAGNI，但编写尽可能抽象的版本以减少承诺。关键引用："I YAGNI the concretion and write the abstract-as-possible version... you're committing yourself the least to any concrete implementation."