AI时代的原型开发速度

# 人工智能时代的原型开发速度 来源：https://darylcecile.net/notes/speed-of-prototyping-age-of-ai 人工智能时代的原型开发速度 2026年5月31日，星期日·7分钟阅读 **注意：** 这些是我个人对过去一年工作流程变化的反思，并非为任何工具做宣传。你的体验可能（而且很可能应该）有所不同。 几年前，我曾写过一篇文章，讲述我对一次性原型（https://darylcecile.net/notes/throwaway-prototypes）的热爱——那些纯粹为了将想法从头脑中变成可触摸实体的小型概念验证。当时，我最大的瓶颈就是我**自己**：搭建项目框架、连接那些无聊的部分、直到可以真正测试有趣部分所需的时间。转眼到现在，这个瓶颈几乎消失了。 我有点犹豫要不要写这个话题。我之前已经分享过一些关于AI的谨慎思考（https://darylcecile.net/notes/github-copilot-agent-actually-useful-ai）以及它如何融入我的工作流程，并且我仍然坚持这些观点。我依然认为整个行业都在实时摸索，而且小心谨慎总是没错的。但谨慎并不意味着视而不见，事实是，AI极大地改变了我从“我想知道如果...”到“哦，它居然能工作”的速度。 ### 最近的仓库（https://darylcecile.net/notes/speed-of-prototyping-age-of-ai#the-recent-repos） 如果你最近看过我的GitHub（https://github.com/darylcecile），你会注意到一串新仓库的出现。Sakoa（https://darylcecile.net/projects/sakoa），一种我从零开始设计的渐进式系统语言，配备了效应系统、三种内存模式以及一个多后端中间表示。Kato（https://darylcecile.net/projects/kato），一种介于JSON、TOML和YAML之间的表示语言，但明确设计为对人类和智能体都友好。Seal（https://darylcecile.net/projects/seal），一个小型命令行工具，通过将密钥存储在操作系统原生凭据存储中，悄无声息地消灭了.env文件。Karabiner（https://darylcecile.net/projects/karabiner-app），一款面向iOS且原生支持智能体的消息应用。Plim（https://darylcecile.net/projects/plim），一个受Notion启发、可嵌入的网页版块编辑器，拥有框架无关的核心和React绑定。另外还有几个尚不适合公开的项目在酝酿中。 几年前，这个列表可能只有三个带README的仓库、两个废弃的分支，以及一个我会暗自骄傲的工作原型。而现在？原型**存在**。它们能运行。有些还有测试。有几个甚至开始看起来像真正的项目了。虽然并非所有都会变成正经项目（而这正是关键所在（https://darylcecile.net/notes/throwaway-prototypes）），但能够真正**尝试**一个想法，而不只是纸上谈兵，这种感觉非常满足。 ### 宏观视角（https://darylcecile.net/notes/speed-of-prototyping-age-of-ai#zooming-out） 没人真正提醒我的是，AI不仅仅是改变了工程工作的速度，更改变了它的**形态**。当我不再亲自敲每一行代码时，我被迫以不同的方式思考。我在思考边界、约定，以及各部分如何组合在一起。我在编写提示词和规范，在系统存在之前就描述它的整体结构。 这种转变听起来很小，但实际上悄无声息地具有变革性。我在更抽象的层面进行规划，在解决问题之前先定义问题，而且我明显变得更善于委派任务——无论是给智能体还是给人类。事实证明，“精确描述成功是什么样子，让初级工程师（或模型）无需你在场就能据此行动”这项技能，在两个方向上都是相同的。分享愿景、分解任务、预见可能出错的地方——这些是我被迫更刻意锻炼的能力，而我也因此变得更好。 ### 关于生产力（https://darylcecile.net/notes/speed-of-prototyping-age-of-ai#on-productivity） 我粗略追踪这个有一段时间了，主要是出于好奇。根据我日常的工程任务（大致通过典型工作项的PR时间来衡量），我现在的效率平均比智能体成为我工作流程重要部分之前快了大约**4倍**。有些天更高，有些天更低，有些天智能体做了些奇怪的蠢事，害我花一个小时去撤销（这我乐意计入平均值）。 但这个数字低估了一个更有趣的效果：我能承担的工作**类型**发生了变化。以前我会搁置在“好主意，没时间”下的事情，现在可以塞进一个下午。以前我会皱眉头的重构现在变得可行。尝试某件事的成本已经降到足够低，我会直接尝试那些以前会在文档里争论半天的事情。 ### 速度的代价（https://darylcecile.net/notes/speed-of-prototyping-age-of-ai#the-cost-of-speed） 但这并非全是好处。让我高效的那股速度也意味着我敲的代码比以前**少**了，而且我注意到必须刻意保持自己的技术敏锐度。如果我放任不管，工具会很乐意替我干**所有**事——这不是我想要的交易。我仍然希望了解我所做的事情到底是如何工作的。 所以我开始有意地挤出时间来做手动操作。亲手实现一个完整流程。阅读源代码而不是请求总结。坐在调试器前而不是把堆栈跟踪粘贴到聊天里。这更慢、有时令人沮丧，而且很可能必要——既是为了我自己的理智，也因为当AI**不够用**时，仍然需要一个真正懂行的工程师。 另一方面，这种变化更令人愉快：有了新的速度，很容易挤出时间去探索、学习和制作原型。过去我花在项目不可避免的中间环节上的时间，现在被解放出来，可以用来尝试新想法、钻研不完全理解的东西，或者纯粹为了好玩而构建一些奇怪的东西。这笔交易我很乐意做。 ### 对工作的影响（https://darylcecile.net/notes/speed-of-prototyping-age-of-ai#impact-at-work） 这种新节奏也体现在我的日常工作中（https://darylcecile.net/notes/committing-to-change）。不深入细节（我会等到获得适当批准后再专门写文章），速度的提升让我能够在角色的几个不同领域产生影响，而这些领域以前我根本没有精力去碰： - 我帮助搭建了一些自动化工具，为其他工程师提供支持——这是我真正引以为豪的一项工作，希望很快能专门写一篇文章。 - 我还在研究我们内部的代码空间启动时间，并成功实施了改动，将其削减了大约**~50%**。关于我们如何实现这个目标，我有很多话想说，但只能等以后了。 这两件事都是那种一两年前我可能有想法，但由于核心工作负担过重而无法实际交付的事情。速度的变化不仅加快了我原本在做的事情，还扩展了我能做的事情的范围。 ### 我并非唯一注意到这一点的人（https://darylcecile.net/notes/speed-of-prototyping-age-of-ai#i-m-not-the-only-one-noticing-this） 业内其他一些工程师也在写类似的转变，阅读他们的文章让我感到安心（也很有帮助）。特别推荐两篇： - Kent Beck 关于“eXtreme Programming AI”的思考（如果你还没看过的话） - 还有 Simon Willison 的超能力（https://simonwillison.net/2025/Oct/10/superpowers/）文章，更广泛地展示了编码智能体在现实中的能力——如果你没读过，非常值得一看。 --- 我仍然不认为AI是魔法，而且我对整体图景仍然持谨慎态度；环境、财务和社会（https://darylcecile.net/notes/github-copilot-agent-actually-useful-ai）问题并没有消失。但对我个人而言，目前的日常现实是：我可以更快地行动，思考得更大胆，交付得比以前更多。这真的很有趣。 我没有一个简洁的结论来收尾。我只会继续制作原型，在需要的时候亲自实践，并持续关注哪些变了、哪些没变。随着情况继续变化，我会有更多想法。 下次再见……✌🏽