← #796

AI 时代的原型开发速度

查看原文 HN 讨论

文章摘要

（注：原文链接抓取返回 403，本摘要主要依据 HN 讨论及作者引用的原文片段整理。）

作者 Daryl Cecile 在这篇笔记中分享了自己在 AI 时代做原型开发的真实体验。他的核心感受是：借助 AI 编程助手（如 Claude Code 等），原型开发的速度得到了显著提升——他能”走得更快、想得更大、产出更多”，而且这个过程”真的很有趣”。从一个想法到一个可演示甚至接近可发布的产品，所需时间从过去的数周缩短到了数天。

不过作者保持了清醒和克制。正如他在文中所写：他依然不认为 AI 是魔法，对更宏观的图景也保持谨慎——围绕 AI 的环境、财务和社会层面的种种问题并没有消失。但就当下、就他个人的日常现实而言，AI 让他在原型阶段的迭代速度实实在在地变快了。他也提到一个重要观点：开发者仍需保持自己的技能锋利，不能因为 AI 代写了大量代码而荒废了对问题本身的理解。这篇文章在 HN 上引发了关于”AI 加速原型开发到底意味着什么、又付出了什么代价”的激烈讨论。

HN 评论精华

• righthand（质疑派核心）：发出一连串尖锐质疑——用 AI 真的比用现成的代码生成器/脚手架工具更快吗？你怎么知道你的项目不是另一个仓库的”复读”？”这只有 LLM 才能快速搞定”的说法忽略了 LLM 本身就是建立在这些工具之上的。在工作中，他从未因为不用 LLM 而错过项目截止日期，那么这种”速度”到底带来了什么？多出来的”摸鱼时间”吗？他还质疑”这本来要花几周”是老掉牙的项目工时估算问题——凭什么相信工程师真的知道省下了几周？

• hombre_fatal（支持派回应）：因为我们有 AI 之前做事的经验。比如以前大多数项目没有测试，因为写测试耗时且需要预先把代码设计得可测；而现在写测试变得轻而易举，他交给 AI 的每个项目都有（而且是好的）测试——凭 20 年经验他能看出来。修 bug 也简单到只需把用户的 bug 报告邮件粘贴给 Claude Code，它会验证 bug、写一个失败的红色测试、再提出最佳修复方案。

• hparadiz：强调”知道自己要什么”是关键。他在动手前就清楚要哪些结构体、协议、事件总线如何分层、需要哪些线程——所以生成的代码严格符合他的设计模式。”在你还在纠结文件该怎么命名的时候，我已经在跑基准测试了。”

• utopiah（专业原型师视角）：他靠做原型为生，认同这套流程，但强调”你永远不要从一张白纸开始”。第 0 步是挑战需求的价值本身——花大量时间和有需求的人深挖他们真正需要什么（而不是他们以为想要的），这往往会让对话很快变得不舒服，因为你要质疑他们自己的设想。

• mooreds 引用 Kelsey Hightower：用 agent 去构建”工具/实用程序”比直接让 agent 干活更聪明——软件产物相当于你对问题理解的”缓存版本”，可以反复使用，直到问题或你的理解发生变化。

• 关于”垃圾产出”的担忧：baisampayans 指出执行成本变低后，大量垃圾正在被快速发布——不是代码质量差，而是连烂点子都被原型化了；表面好看、底层有 UX 问题的东西因为”会说话的人”能说服领导而被优先做，传统的用户调研反倒被嫌太慢。anssip 直言”AI 让人能极快地发布大量垃圾”。bob1029 则升华道：执行成本已降至接近零，在这个新世界里，”说不”的能力比以往任何时候都重要；专家有更多路径可走能更快得到高质量方案，而新手会更快陷入麻烦。

• bluefirebrand：一针见血的类比——这就好比我们不再自己写代码，而是开始从开源仓库复制粘贴。”想象我的速度！我几秒就克隆了 Linux 内核！”实际上我们正在通过一个 AI 混音器做着差不多的事，这让他”嘴里泛起一阵酸味”。

• ArneCode：代价不止是放弃亲手写代码。自己写原型时你会深入了解问题、看到各种设计取舍；写代码时大脑始终在后台运转，思考哪里会出问题、哪里能简化。当 LLM 代写时，由于你与软件的接触大大减少，这种隐性的学习和思考也随之削弱。