用 AI 做的应用“快完成了”，到底意味着什么？

最近，一位潜在客户告诉我，他用 Claude 两天就做完了整个应用。他希望我帮忙收尾几个简单问题，随后提出要我免费做两小时评估。我拒绝后，话题变成了 AI 将取代程序员的说教。

我在 LinkedIn 上写过这次交流。这里想继续讨论对正在聘请开发者收尾的创始人更重要的问题：到底还剩下什么？

我没有确认那位客户的软件究竟完成了多少。他的描述是对项目状态的说法，并非技术评审的结论。正因为存在这个区别，定价前才需要调查。

封面：为 Rosecraft Studios 制作的 AI 生成编辑插画。

“快完成了”背后需要一张具体清单

AI 编程工具可以帮助人取得很大进展。能运行的原型可能让产品更清楚，暴露棘手需求，也为开发者提供可继续利用的代码。这些工作当然有价值。

但已完成的界面数量，并不能说明还剩多少工作。修改按钮文字和修复客户访问权限，在任务清单上都可能只有一行，实际却完全不同。

询价前，尽量具体地写出尚未完成的行为。“完成订阅功能”会让开发者猜测；“客户可以买套餐，但账号一直锁定，直到我手工修改”则给出了可以复现的问题。补充预期结果、实际结果，以及是否每次都会发生。

未完成的工作可能是缺陷，可能是尚未开发的功能，也可能是您还没作出的产品决定，例如取消订阅后应立即终止访问，还是保留到已付费周期结束。开发者可以帮您理清，但这些都属于范围。

走完一条完整的客户流程

以一个假设的订阅应用为例，我会从全新客户账号开始，走过注册、付款，直到获得第一个有用结果。这是在说明如何界定评审范围，不是对前面那位客户应用的判断。

在安全的测试环境中，先展示无需人工干预就能工作的部分，再展示需要您介入的位置。管理操作也要算进去：如果每次付款后都得修改数据库，即便客户看不到，它仍是当前流程的一部分。

接着检查重要异常。比如，Stripe 的 webhook 文档说明，付款相关事件可能重复到达，也不保证按生成顺序到达。应用需要明确的处理方式。一次成功结账，无法证明重复通知时也能正确工作。

访问权限同样需要证据。Supabase 的生产检查清单要求行级安全及恰当的策略。通俗地说，数据库必须规定每位客户能访问哪些记录。对于包含客户私有记录的应用，应在授权下用两个独立账号测试；看到登录页面并不足以回答这个问题。

具体检查取决于产品。没有账号的计算器，与保存客户文件的订阅服务，需要完成的工作不同。从首个版本真正作出的承诺开始。

为有明确产出的评估付费

简短的需求交流可以判断开发者的经验是否适合项目。查看代码、复现故障和追踪依赖则是实际工作。如果负责任的报价需要这些工作，就应约定边界清楚的付费评估。

问清这段时间会交付什么。有用的评估应包括：

• 检查范围：评审的版本、环境和客户流程，以及无法访问或测试的部分。
• 具体发现：哪些已正常工作、哪些失败，以及每项发现的证据。
• 首个发布版本建议：上线前必须完成什么，哪些功能可以合理推迟。
• 带有假设条件的估算：可定价的有限变更、仍需调查的未知项，以及您必须作出的产品决定。

两小时或许足以复现一个故障并提出下一步，也可能远远不够评估大型应用。先约定这段时间要回答的问题。坦诚说明范围有限的评估，比匆匆看一眼后的全面保证更有用。

AI 也能协助评审。GitHub 的 9 月 11 日 Copilot 代码评审更新介绍了更广泛地使用 shell 工具验证代码。更好的工具值得欢迎，但评审仍需核对业务真正期待的行为，包括从未写入最初提示词的决定。

让估算说明下一步该怎么决定

考虑那个假设订阅应用中的三个发现：确认文案不对，可能只是小范围修改；已付款账号偶尔仍被锁定，需要先调查付款与权限流程才能可靠估算；客户可以进入别人的工作区，对于承诺私有工作区的产品，这就是上线阻碍。

把三者都归为“打磨”，会掩盖您需要作出的决定。有用的估算应说明哪些可直接修复、哪些仍不确定，以及哪些行为阻止预定上线。请开发者区分清楚。

对全面重写的建议也要同样追问：什么阻止了修复现有应用，哪些部分可以保留，替换的证据是什么？部分代码由 AI 编写，并不能直接回答这些问题。

约定您会怎样验收

每项工作都要描述将要检查的结果。例如，客户在测试环境购买指定套餐，获得正确权限，重复付款通知不会重复授权。您和开发者都能核对这个结果。“让计费达到生产要求”则需要更多定义。

上线不需要愿望清单上的每个功能，但约定的首个版本必须能工作，已知限制要明确，并有人负责运行。缩小首发范围，有助于理解剩余工作并安排预算。

如果您的应用正处在这个阶段，Rosecraft 的技术评估可以在您承诺继续开发之前厘清范围。带上当前应用、可以演示的功能清单，以及能够复现的问题。这是判断下一步的有用起点。