AI 写代码更快了，产品为什么还是交付不了？我如何理解 AI 原生开发流程

读完 Anthropic 的 《The AI-native SDLC playbook》，我一直在想一个问题：当 AI 能很快写出代码时，我们到底还在等什么？

假设我正在运营一个活动报名网站，想加上“候补通知”功能。我让 AI 开始做，它很快就完成了邮件发送和确认页面。但我还没决定：有人取消报名后，名额要为候补者保留多久？对方没回复，要不要通知下一位？已经过期的链接，还能不能继续使用？

这时候，代码写好了，距离能放心上线却还有一段路。

原文作者是 Louis Claxton，页面标注的发布日期为 2026 年 8 月 21 日。它提出，AI 加快代码产出后，瓶颈会转移到需求、验证与交付；开发流程应该让 AI 参与各个阶段，通过可追溯的成果衔接工作，同时保留人的决策责任。

这篇文章想整理我对这个观点的理解，再用一个功能从头走到尾。下面的候补网站、人物、时间和数字，都是我为了说明问题设置的假想场景。提示词和文档也只是示例，没有实际运行结果。

我先把 SDLC 理解为：一个功能如何从想法变成可用的产品

SDLC 是 Software Development Lifecycle，中文通常叫“软件开发生命周期”。我会把它理解成六个问题：

阶段	我想先回答的问题	以候补通知为例
规划	为什么要做？	主办方需要反复人工联系候补者
设计	用户会怎么操作？	候补者收到通知后，在有效期内确认
开发	系统需要改哪些地方？	名额、通知邮件、确认页面
测试	如何确认功能确实可用？	重复点击、过期后确认都不会导致超额报名
部署	怎么让用户用上？	先用测试活动演练，再分批启用
维护	上线之后要关注什么？	邮件是否送达、名额是否正确释放

“部署”就是把新版本放到实际提供服务的环境中；“维护”则包括排查错误、修复问题和持续改进。在小型项目里，这六件事可能都由一个人负责，但仍然值得分开考虑。

我对“AI 原生”的理解，是在安排工作时，就把 AI 能做什么、需要什么信息、如何验证结果一起考虑进去。如果下一步还得有人把整段聊天重新讲一遍、重新整理文件、追问执行结果，流程就还有改进空间。

我会先看整个交付周期，而不只是写代码有多快

我觉得餐厅出餐是个很好的比喻。炒菜突然变快了，但点单没说清楚、食材没备好、菜卡在出餐口，顾客仍然得等。

候补通知也是一样。即使 AI 很快写好了邮件发送功能，如果我又花几天才决定名额分配规则，或者一直没时间评审代码，用户也感受不到加速。

我用这张图说明等待如何累积。方块长度只是概念示意，不代表实际工时或性能提升比例。

所以，我更想观察的是：一个功能从提出到可用，一共花了多久？哪些地方反复讨论？上线后是否增加了客服负担？如果代码产量增加了，评审却堵住了，下一个该改进的环节就很清楚。

下面，我用候补通知来说明：如果要把整个流程交代完整，我会怎样和 AI 合作。

第一步：我先说清楚问题，不急着做功能

“有人取消，就通知候补的人”是一句很直观的需求，但离能动手实现还有不少空白。我会先让 AI 帮我找问题：

我想给活动报名网站增加候补通知功能，先不要写代码。

目前的问题：有人取消报名后，主办方要人工查看名单、逐一联系，
也不知道对方什么时候会回复。

请先列出需要我决定的问题，分成：
1. 不确定就无法继续设计的规则。
2. 可以留到下一版的选项。
3. 必须查看现有系统才能回答的问题。

不要自行补充尚未确认的业务规则。

我希望它指出“确认有效期”“排序方式”这样的关键决策，也把“能否使用现有邮件服务”列为待核实事项。如果它直接写上“保留 24 小时”，我会要求标为假设，因为这个数字关系到主办方多久才能补满名额。

讨论之后，我会留下一份这样的需求草稿：

# 候补通知：需求草稿

## 要解决的问题
有人取消报名后，主办方需要人工联系候补者，容易遗漏空出的名额。

## 这一版要实现的结果
系统按加入候补名单的时间排序，一个空缺每次只邀请一人。
被邀请者有 2 小时确认，过期后才通知下一位。

## 需要遵守的限制
不修改支付流程，不支持主办方手动插队。
通知内容不包含其他候补者的信息。

## 待确认的问题
距离活动开始不足 2 小时，是否继续补位？
邮件服务中断时，确认有效期应从哪个时间点开始计算？

这里的 2 小时只是这个示例中的选择。我刻意保留未解决的问题，因为“文档看起来完整”很容易让人误以为所有事情都已经确定。

到这一步，我会做一个检查：没参加讨论的人，能否在读完后说清楚这个功能要解决什么、这一版不做什么？如果还说不清，就继续梳理。

第二步：我用具体场景，把设计细节问清楚

需求方向明确后，我会把抽象规则换成一段用户操作过程。

假设上午 9 点有人取消报名，排在第一位的小安收到邀请，系统为他保留名额到 11 点。小安没有确认，11 点后名额改为保留给下一位小柏。11 点 05 分，小安才打开原来的邮件。

这时页面应该怎么处理？

我的选择是显示“本次邀请已过期”，不允许小安占用为小柏保留的名额。页面也不能随便承诺“你已自动重新排队”，除非我确实确定了重新加入候补名单的规则。

这些时间是我设置的示例。把流程放到一条时间线上，过期链接与名额归属的问题就更容易看清。

我会让 AI 对照这段场景整理设计：

请根据需求草稿，画出候补者从等待、收到邀请，到确认或过期的流程。
先不要实现。

请逐项回答：
- 系统如何判断这份邀请目前仍然有效？
- 邀请过期后，旧链接还能执行什么操作？
- 同一个人连续点击两次确认，会不会占用两个名额？
- 邮件发送失败时，用户页面和管理后台分别会显示什么？

需求中尚未确定的内容，请标为待确认，不要自行决定。

我会重点看“上一个操作失败后，下一步怎么办”。正常收到邮件、点击确认的流程通常不难画，问题往往出在发送失败、链接过期、用户重复操作的时候。

这也是我希望 AI 帮忙的地方：把容易遗漏的分支列出来，让我能在修改代码之前决定要接受哪些行为。

第三步：我先评审实现范围，再让 AI 改代码

设计说得通之后，我会要求一份可以评审的实现计划。文件叫什么并不重要，关键是让我看清这次修改的边界。

例如，这个假想项目可能涉及以下工作：

修改范围	我会要求说明的内容
候补名单	如何选择下一位，以及如何避免把同一名额分给两个人
邀请记录	记录对应的活动、候补者、有效期和当前状态
邮件发送任务	失败后如何重试，以及如何避免创建重复邀请
确认页面	成功、过期和已经确认时，分别显示什么
管理界面	主办方如何发现邮件发送失败及其他待处理事项

这些只是用来讨论的范围。具体文件、数据结构和修改顺序，仍要读过现有代码才能决定。我不会先编出一串不存在的文件名，再要求 AI 照着改。

我会这样写提示词：

请先阅读现有的报名、候补和邮件发送流程，再提出实现计划。

列出实际要修改的文件、每一步影响的行为、是否需要调整数据，
以及每一步应如何验证。
如果现有系统无法支持设计，请先说明原因和可选方案。

这一轮只读取并整理计划，不修改代码。

我想提前发现的是：“看起来只是个小功能，实际上却会影响关键规则。”比如，新增邀请有效期，可能需要处理现有候补数据没有有效期的情况；调整名额保留方式，也可能影响原有的正式报名流程。

如果开发过程中才发现设计行不通，我会同步更新计划和验收标准。否则，评审时手里是一份旧说明，眼前却是另一套实现。

第四步：我用验收场景，判断 AI 做出的功能是否可用

“测试全部通过”很让人安心，但我还想知道：到底测了什么？

我会先列出重要场景，再让 AI 或工程师把适合自动化的部分写成测试。以下是这个假想功能的验收表：

场景	我期望的结果
小安在有效期内确认	获得一个正式名额，邀请状态变为已确认
小安连续点击两次，或网络重试同一请求	仍然只有一条有效报名记录，不重复扣减名额
小安的邀请过期，名额已改为保留给小柏	小安无法通过旧链接确认，小柏的保留仍然有效
没有其他候补者	空缺保持为可用名额，不发送没有接收对象的通知
邮件服务暂时失败	不把发送失败记录为已送达，并保留可追踪的状态
活动已经取消	不能用旧邀请完成报名，页面说明原因

重复请求的问题，在工程上经常会涉及“幂等性”：同一个操作重复执行，结果仍然只相当于执行一次。用候补确认来理解很直观，因为用户确实可能连续点击两次，系统也可能由于网络问题重新发送请求。

我还会区分两类检查。

一类检查系统内部的结果，比如名额不能被重复占用，适合用自动化测试验证；另一类检查用户能否看懂页面，比如“邀请已过期”是否解释清楚，适合通过实际操作和截图来检查。两者都重要，不能互相替代。

让 AI 修复问题时，我也会要求保留原来的验收标准：

请先复现“旧邀请过期后仍然能确认”的问题，说明失败原因，
再修改代码。完成后重新运行相关测试，并附上实际输出。

不要通过删除测试、跳过检查，或放宽“不能超额报名”的条件来让测试通过。
如果你认为验收标准本身存在矛盾，请先指出来，由我判断。

我在意的是，证据能不能支持结论。如果绿色的检查结果没有覆盖旧链接和重复确认，就还不足以证明候补流程正确。

第五步：我通过 PR 评审行为，也演练如何撤回变更

PR 是 Pull Request，也就是把修改集中起来，请人评审后再合并的请求。我希望通过它快速看清：“改了什么、如何验证、还存在哪些问题。”

我会要求提供下面这样的摘要。它只是需要填写的模板，不能把示例当成已经通过验证的结果：

## 用户会看到的变化
有人取消报名后，第一位候补者收到邀请；过期后才轮到下一位。
已经过期的旧邀请不能再获得名额。

## 验证证据
- 自动化测试：填写实际命令、结果及尚未覆盖的场景。
- 操作检查：附上有效、过期、已确认三种页面截图。
- 邮件发送失败：填写演练方式和观察结果。

## 上线与恢复
- 先对内部测试活动启用。
- 说明如何停止创建新邀请，以及谁有权操作。
- 说明已经发出、但尚未确认的邀请将如何处理。

## 待评审事项
列出尚未确定的规则和已知限制，不用“应该没问题”一笔带过。

上线前，我会用测试邮箱走一遍完整流程。除了确认新版本可以发布，也要演练发现问题后如何停止。

比如，发现邀请邮件的内容有误时，关闭“创建新邀请”并不能撤回已经发出的邮件。我还需要决定：已发出的确认链接是否继续有效？要不要补发说明？主办方如何找出受影响的用户？

因此，我不会只在文档中写“有问题就回滚”。如果新版本已经修改了名额或邀请数据，回滚到旧代码后，可能仍然有记录需要处理。对于这个功能，我会先设计停止创建邀请、保护现有名额、排查影响范围的方法，再考虑是否回滚代码版本。

第六步：我让用户反馈进入下一轮需求

假设功能上线后，有人反馈：“收到邮件时，链接就快过期了。”

我不会马上让 AI 把 2 小时改成 4 小时，因为这可能掩盖真正的问题。首先要查清楚：有效期从什么时候开始计算？邮件何时进入发送队列，何时被邮件服务接受？有没有重试或延迟？

我会让 AI 把调查分成三部分：

我要求的分类	这次事件可能记录的内容
已知事实	邀请创建时间、有效期、发送尝试和重试日志
有待验证的推测	可能是邮件延迟，也可能是页面显示时间有误
下一步	核对时区、排查邮件发送任务，确认有效期的计算规则

这里还有一个容易混淆的地方：邮件服务接受了请求，不代表用户已经收到或读到了邮件。调查记录要写清楚究竟观察到了哪一步，避免把推测当成事实。

如果最后确认问题是“从创建邀请时就开始倒计时，但邮件发送延迟很久”，我才会重新讨论有效期的起算方式。修改后，也把这种延迟场景加入测试，避免下次再出现同样的问题。

这样，维护中得到的线索就能回到规划阶段，六个阶段形成持续改进的循环。

我希望每次交接都留下“决定了什么、如何验证、谁来接手”。这是我自拟的候补通知案例。

我为什么希望信息保存在聊天以外的地方

走完这个例子就会发现，需求、设计、实现和验证，其实是一连串相互影响的决策。

如果它们只存在聊天记录里，过几天换人接手，就得重新拼凑：名额究竟保留多久？邮件发送失败后是否开始倒计时？哪个版本才是最终决定？

原文用 intent.md、spec.md、plan.md 等文件衔接工作，并保留版本记录；也允许继续使用已有的需求管理系统，但需要明确哪里是权威数据来源。详见原文。这里的 .md 是 Markdown 文本文件，用普通文本编辑器就能阅读。

对我来说，先维护好一个工单就很有价值。它至少要关联需求结论、相关 PR 和验证结果。如果把保留时间从 2 小时改成 4 小时，也要同步更新验收场景与客服说明，避免各处说法不一致。

我也会控制文档数量。只改几行文字，不需要为了凑齐文件名而重复写三份内容相近的文档。让接手的人和 AI 找到正确信息，比文档数量更重要。

我会区分：提醒 AI，和系统真正限制它的操作

原文区分了 skill 和 hook：前者提供工作指引，后者可以在执行操作时运行程序检查。参考原文对 Skills 和 Hooks 的说明。

我会把它们理解为活动现场的两种安排：“请检查门票”是工作手册，“验票通过才开门”是入口设备。手册说明应该怎么做，设备则负责检查某个条件。

放到候补通知这个案例里，我会这样分工：

需要遵守的规则	我会提供的指引	还需要的检查或限制
不能超额报名	说明名额和保留规则	更新名额时的系统机制，以及重复操作、并发操作的测试
不泄露联系方式	说明哪些字段不能写入错误日志	日志检查与受限的数据访问权限
正式发送邮件前先确认	说明测试活动与正式活动的区别	测试账号不能向正式名单发送邮件，正式操作由指定人员授权

我不会把所有限制都寄托在一种 hook 上。开发工具的检查、邮件服务的权限、报名系统本身的规则，分别保护不同环节，也都有配置错误的可能。

我想追问的是：违反这条规则时，会先有人收到提醒、操作会被阻止，还是只能等用户反馈？知道答案，才能判断现有防护是否足够。

如果是我的个人博客，我会如何简化这套做法？

候补通知涉及名额和联系方式，流程需要交代得更完整。但我也想把同样的思路用到个人网站上，把第一步缩小到确实能开始做。

假设我要给博客增加“文章阅读进度条”，我会这样安排：

1. 先明确目的。 我想让读者知道文章还剩多少，而不是看到别人有就跟着加。
2. 说清楚设计。 进度从正文开始计算，不包含导航栏和评论区；短文章是否显示，也提前决定。
3. 让 AI 查看现有模板。 找到正文容器和现有样式，再提出修改范围，避免在每个页面重复添加代码。
4. 验证实际阅读效果。 检查长文、短文、手机页面和深色模式；读到正文底部时，进度应接近完成。
5. 附上截图再评审。 在 PR 中放入桌面和手机截图，说明如何移除这个功能。
6. 回看使用体验。 如果遮住标题，或者让手机页面显得拥挤，就调整位置，而不是因为“代码已经写完了”就勉强保留。

这个修改不需要照搬整套企业流程。我可能只用一个工单、一个小 PR 和几张截图，就能留下足够的背景信息。

我会特别避免这样做：只让 AI“帮我加一个好看的进度条”，看到它能动就合并。这样很容易遗漏非文章页面、移动端适配和实际阅读范围的问题。

我会如何判断，这套流程到底有没有帮助？

如果要开始试行，我会选择一个范围明确、容易恢复的小修改，先记录原有的等待情况，再用同样的方法观察几次。

我会看四件事：

• 交付时间： 从需求确认到功能可用，一共花多久？哪些时间是在等待？
• 返工原因： 是代码写错、需求没说清，还是评审时才发现设计不合适？
• 用户问题： 上线后有没有出现原先没考虑到的操作场景？
• 总体成本： AI 使用费用、运行时间，以及我阅读文档、评审 PR、处理错误所花的时间。

如果 AI 写得更快了，我却花更多时间猜它为什么这样改，我就会缩小每次修改的范围，要求更清晰的摘要。如果需求反复变化，就先改善前面的需求梳理。一次顺利交付也不能证明所有工作都适用同一套方法，我会继续观察不同类型的修改。

读完这份 playbook，我最想改进的是每次交付的完整程度：我是否说清楚了要解决的问题？AI 是否提供了足够的验证？接手的人是否知道哪些事情已经确定，哪些还需要判断？

这些问题有了具体答案，AI 写代码的速度，才更有可能转化为我能放心交付、读者或用户也能感受到的改进。

延伸阅读

• Louis Claxton，Anthropic：The AI-native SDLC playbook。原文提供六个阶段的详细做法和治理建议。本文是我的阅读心得与延伸示例，没有复用原文图表。