为什么 AI 让软件开发变快，却没让交付变快

我们目前正在打造一套产品，而打造它们是最简单的部分。Claude、Devin、Codex 和 Hermes 都各自尝试过其中的一些部分，演示很快就出来了。没有快起来的是生产化。在迎来第一个付费客户之前，我们仅在工具和软件上就花了超过 5,000 美元，只为把安全性、可靠性和隐私做到我们愿意署名的标准——扫描器、审查工具、监控，全套——而这还没算上创始人的时间，那才是昂贵的部分。AI 让构建变便宜了。它让检查变贵了。加起来一算，账单开始看起来像一家软件公司会收的费用，而软件公司至少还会带来经验。

这就是本文的全部论点，所以值得在一开始就直白地说出来：AI 让软件构建变快，却没有让交付变快。一个能跑的演示现在只需几天。让这个演示变得安全、可靠、有人支持并被真正使用，仍然需要几个月。大多数永远到不了那一步。下面是我们观察到的 AI 构建产品卡住的五个地方、我们现在用在自己工作上的就绪度框架，以及一个免费的套件，可以在你已有的任何编码代理里运行它。

为什么 AI 让软件构建更快，却没有让交付更快？

因为它加速的是制作，而且只是制作。代码周围的一切——审查、签字确认、值班、与你无法控制的系统集成——都以一如既往的速度运行，有时甚至更慢，因为现在有更多代码要检查，而且对是谁写的更没信心。

已发表的证据也指向同一方向，尽管并非所有证据都同样可靠。

DORA 的 2024 年报告建模显示，AI 采用率每提高 25%，交付稳定性就下降 7.2%（DORA 2024）。这是跨许多组织建模得出的估计，而不是对任何一个团队测得的下降，所以应把它当作一个方向，而不是预测。2025 年版用文字表达了同样的事：AI“放大高绩效组织的优势，也放大挣扎中组织的功能失调”（DORA 2025）。这与我们看到的相符。它不会修复薄弱的流程；它只是让薄弱的流程跑得更快。

METR 的研究是人们引用最多、也最不信任的一项。16 名经验丰富的开源开发者，在自己的代码库上工作，使用 AI 工具后耗时增加了 19%，却以为自己快了 20%（METR，2025 年 7 月）。16 是个小数字，而且这些人对自己的代码库了如指掌，这几乎是对助手而言最糟糕的情况。但感觉速度与实测速度之间的差距才是值得记住的部分。我们自己也有过这种感受。

然后是质量数据。Veracode 在超过一百个模型生成的代码样本中发现 45% 存在安全缺陷（Veracode 2025）——这是供应商的测试套件，不是生产代码，但一家卖扫描服务的供应商没有理由低估它。Stack Overflow 的 2025 年调查显示，46% 的开发者不信任 AI 的准确性，而 33% 的人信任它（Stack Overflow 2025）。

而业务数据才是真正应该让创始人担忧的。BCG 发现 74% 的公司尚未从 AI 中展现出切实价值，只有 4% 在创造实质性价值（BCG，2024 年 10 月）。麦肯锡测试了 25 项属性，发现工作流重新设计对 EBIT 影响最大——而只有 21% 的公司做到了（麦肯锡，2025 年 3 月）。Gartner 预测，30% 以上的生成式 AI 项目将在概念验证后被放弃，40% 以上的智能体项目将在 2027 年前被取消（Gartner 2024，Gartner 2025）。这些是预测，不是结果。Gartner 在这类预测上的过往记录好坏参半。不过，也没有人预测相反的情况。

这不仅仅是工程层面的故事。Typeface 在 2026 年调查了 200 多位营销副总裁：93% 表示 AI 加大了加快行动的压力，而需要一到两个月才能启动一次营销活动的比例在一年内从 5% 升至 34%（Typeface Signal Report）。Typeface 销售的正是号称能解决这一问题的工具，所以看这些数字时要考虑到这一点。但问题的形态是熟悉的。创作变快了；审批、交接和治理没有。

BCG 的经验法则正是我们反复回到的那一条：从 AI 中获得价值的公司，大约把 10% 的精力投入算法，20% 投入数据和技术，70% 投入人员、流程和变革（BCG，2025 年 1 月）。这是一种启发式方法，不是精确测量。它也恰恰与大多数 AI 构建的 MVP 的组装方式相反——全是算法和界面，没有运营模式。我们自己的产品一开始也是如此。

AI 构建的产品在演示和生产之间卡在哪里？

演示能跑通。缺的是演示从来不需要承受的一切。

隐形安全债务是第一个，也是 AI 最不擅长隐藏的。密钥写在代码里或留在 git 历史中。授权只在浏览器里检查，别处都没有。数据库规则因为演示需要而保持宽松。依赖项没人看过。代价是一次泄露或入侵，在产品起步之前就将其终结，而尴尬的真相是，写下这些代码的模型会兴高采烈地告诉你它是安全的。

没有人在值班。没有错误追踪，没有告警，备份从未被恢复过，没有回滚，没有运行手册。第一次故障持续数天，因为没人知道它正在发生。第一次数据丢失是永久性的，因为备份只是个勾选项。

集成漂移是最安静的那个。沙盒密钥仍在生产环境中。API 版本未固定。Webhook 未经校验就被接受。对供应商某天宕机或更改条款毫无预案。它表现为静默失败和来自你并不拥有的系统的意外账单。

这三项是技术就绪度，任何像样的清单都会涵盖它们。接下来两项才是我们实际看到产品死亡的地方。

试点炼狱。没有商定的成功指标，没有“扩大或砍掉”的标准，新工具上线了，旧工作流却原封不动。数月“前景可期”却毫无决策，用户逐渐回到以前的工作方式。

治理放在最后。法务、安全和品牌审查作为最后一道关卡，所有东西都排在它后面。最快的构建遇上最慢的签批，你在第一周获得的速度在第四个月消失殆尽。

大多数清单涵盖前三项。大多数失败来自后两项。

AI 产品的生产就绪框架应该是什么样子？

就绪度是一份画像，而不是一份清单。我们花了一段时间才得出这个区分。清单把周末原型和受监管的 B2B 产品一视同仁，所以要么对前者太重，要么对后者太轻，无论哪种情况人们都会弃用它。

我们的版本包含三个部分。十三个核心领域适用于每个产品：十个技术领域（密钥与配置、身份与访问、边缘与应用安全、数据与备份、可靠性、可观测性、CI/CD 与发布、测试、性能与成本、运维与支持）和三个组织领域（法律与信任、产品就绪度、采用与运营模式）。十个模块根据你在构建什么而启用——消费的集成、公共 API、移动端与应用商店、Web 与电子邮件、AI 与 LLM 功能、支付、受监管数据、B2B 与企业、市场平台、开发工具与开源。一个接受支付的移动 AI 应用会启用其中三个。一个开发者插件会启用另外两个。

然后层级决定门槛有多高，这正是让框架在两个方向上都保持诚实的原因。对五十用户的 beta 版施加企业级控制会浪费数月时间。对付费产品施加 beta 级控制会流失客户。

• T1，公开 beta。真实用户，规模小，容忍一定停机。没有泄露的密钥，可靠的身份验证，能恢复的备份，错误被追踪，法律页面，可用的回滚。
• T2，正式发布。有 SLA 期望的付费用户。T1 中的一切加上服务目标、能触达真人的告警、负载测试、运行手册、支持路径、每个集成的回退方案。
• T3，企业或受监管。B2B 合同、健康、支付或儿童数据。T2 中的一切加上 SSO、审计日志、数据协议、渗透测试、SOC 2 或 HIPAA 控制、灾难恢复演练。

三条规则让它运转起来，而第一条是我们不得不付出代价才学会的。

没有证据，就不算通过。每个条目都是通过、缺口、不适用或未知，而通过需要证据——一个文件、一份配置、一次测试运行、一个仪表盘。一个写着“备份已启用”的 README 不是证据。编码智能体这么说也不是。我们曾遇到智能体把条目标记为完成，而五分钟的检查就显示并非如此，这条规则的名字就是这么来的。

实时核实规则。应用商店、OAuth、支付和电子邮件发件人要求每年都在变。查阅供应商当前的文档，而不是模型对它的记忆。

治理在工作流内部运行。检查存在于 CI、拉取请求和产品本身之中，而不是在发布前一周的会议里。

为什么一个通过了所有技术检查的产品仍然会失败？

因为没有人改变它周围的工作方式。已发布不等于已被采用。

解决办法是在发布前而非发布后做出六个决定，而且没有一个是技术性的。哪一个单一数字能让这次发布算作成功，到什么时候——没有它，每个试点看起来都永远充满希望。什么结果意味着扩大规模，什么结果意味着停止。谁批准什么，以及多快——低风险变更由一个审查者批准，高风险变更需要更多，而且周转时间要公布。这是否涉及个人数据、AI 输出或受监管用户，在第一天就决定，而不是在第三个月才发现。哪些早期用户会先试用并教其他人，因为同行推动采用比强制命令更快。以及何时审查使用情况——30、60、90 天，然后每季度——这样产品就被当作活的东西，而不是被发布出去的东西。

审批决策是最容易被团队低估的一环。在 Typeface 的调查中，88% 的营销负责人表示内容创作很快，但签核却不快。合规是规模化应用 AI 的首要障碍，有 66% 的人提及（Typeface）。和之前一样，这是供应商自己的说法，但这两个数字我们都不反对。

两个设计选择有助于让采用真正落地。把能力放进人们已经在用的工具里——他们的编辑器、CMS、收件箱或 IDE——而不是一个他们得记着去访问的新应用。并且展示边界：AI 不能做什么、答案来自哪里、哪些部分只是草稿。赢得的信任能持久；想当然的信任不能。

这就是 BCG 那 70% 的用武之地，而麦肯锡的数据从另一面说明了同一件事：重新设计工作流程是生成式 AI 带来底线影响的最大单一驱动因素（McKinsey）。

如何在 30 天内让一个 AI 构建的产品达到生产就绪？

同一套框架，三个切入点，取决于你是谁。

创始人和产品负责人

第一周是画像与决策：层级、成功指标、退出标准、列出每一项集成、标记法律和隐私问题。完成的标准是有一页所有人都签过字的文档，并且就绪扫描已经运行并记录了缺口。第二周是关闭阻塞项——把密钥从代码和提交历史中移除、在服务端做授权、真正恢复一次备份、上线错误追踪——完成的标准是 T1 没有未解决的阻塞项，且每个修复都附有证据。第三周让它可运维：验证回滚、告警能触达真人、针对前五大故障的运行手册、每个付费 API 都有支出上限。完成的标准是你已经制造了一次故障，并看着它被检测、告警和回滚。第四周是向小范围群体发布、让支持者完成上手、开放反馈渠道、把第一次评审日期写进日历。

创始人的工作不是逐项做检查，而是拒绝在“我们觉得没问题”的情况下发布。

企业负责人

把治理一次性放进工作流程里。安全、品牌、隐私和审批规则变成 CI 中的检查、拉取请求模板和产品护栏，而不是一场评审会议。按风险对审批分级，并公布每一级的周转时间。先标准化再规模化——只有 20% 的营销组织拥有可供 AI 使用的成文工作流程（Typeface），而根据我们的经验，软件团队也好不了多少，所以一份共享的就绪画像胜过每个团队各用一套清单。还要规划退出：拥有你的数据、提示词和配置，避免没有中断条款的多年锁定，并且每年两次审查模型和供应商，因为你今年春天选的那个，不会成为明年春天最好的那个。

工程负责人

让每项检查都产出证据。主分支上的必需检查：lint、类型检查、关键路径测试、对完整历史的密钥扫描、依赖审计。用证据而非承诺——恢复日志、回滚运行、触发过的告警、负载测试报告，每一项都附在它所关闭的就绪条目上。在追求覆盖率数字之前先测试关键路径：认证、支付、权限和数据写入优先，因为百分比很容易被钻空子，而一个坏掉的权限检查不会。并且验证智能体交给你的每一个模板。AI 建议的 CI 文件经常引用不存在的 action 和包。在你信任它之前，检查每一个都能解析。

我们先在自己的产品上运行它

发布一个框架却从不使用它，这很容易。所以第一个通过它检验的产品就是我们自己的，而且无论结果是否对我们有利，我们都会公布。

KnoKeep by Viaknox 是一种可移植、保密安全的记忆，让 AI 编码代理能够从上次会话停止的地方精确恢复，即使是在不同的工具中。它以 Claude Code 插件、Cursor 规则、Codex 指令文件和 shell 命令的形式发布。它是开源的，采用 AGPL-3.0 许可，版本为 v0.1.0，并计划为将其嵌入自己产品的团队提供商业许可。

从纸面上看，它的状态不错：683 个测试通过，CI 覆盖 Linux、macOS 和 Windows，每次提交都运行 gitleaks，有威胁模型、分支保护，还有一个审查步骤，让多个不同的模型在人类看到之前就每个变更相互争论。仅凭技术清单就会让它通过。这正是它成为一个有用测试的原因。

它的画像为 T1——一个公开的开源测试版，T2 已在考虑中，用于商业许可——并启用了 Integrations、Marketplaces 和 Dev-tools 模块。我们预计它会遇到困难的问题不是技术性的。当存储的记忆格式发生变化时，升级路径是什么？对于想要在内部使用它的公司来说，AGPL 实际上意味着什么？干净机器安装是否在全部四个工具上每次都有效，还是只在我们构建它的机器上有效？测试版的成功指标是什么——因为现在，说实话，我们有的是一种感觉，而不是一个数字。

完整的评分卡、我们发现的阻碍、我们修复了什么以及需要多长时间，将是下一篇文章的内容。没有证据就不通过，这条规则对我们自己也适用。

免费的生产就绪工具包

本文中的框架是免费的，并且与你已经在使用的 AI 编码工具兼容。它基于开放的 SKILL.md 格式构建，Claude、Codex、Cursor、VS Code 中的 GitHub Copilot 和 Gemini CLI 都可以加载（VS Code 文档）。

许可证：代码采用 MIT，文档采用 CC BY 4.0，因此你可以为你的团队调整它。

→ 获取工具包：github.com/viaknox/production-readiness

还没准备好安装任何东西？上面的十问就绪检查可在两分钟内给出你的分数、你最薄弱的领域以及你所用工具的安装命令。

证据来源和说明