独立开发：从做出来到确认可用

独立开发：把“做出来”推进到“确认可用”

独立开发者往往同时负责需求、实现和验收。AI 可以加快实现，但产品能否交付，仍需要一个可观察的完成标准。与其只记录写了多少代码，可以围绕一个用户任务，说明它在什么条件下成功，以及失败后如何恢复。

这篇综述以本站 2026 年 9 月 21 日 Builders 精选中的软件验证案例为起点。案例描述与本文提出的工作方法分开陈述，避免把一次成功演示当作普遍保证。

Guillermo Rauch 分享过 agent 排查移动端应用内浏览器渲染问题的经历。按照收录材料，过程涉及复现、模拟、修复、部署和验证；其中一个动作是创建临时 Vercel 部署并使用 iPhone 模拟器检查。他据此表达了对未来软件质量的乐观判断。

这个案例支持的是一种工作方式：发现异常之后，继续追踪到结果验证。它没有证明所有 agent 都能完成所有软件测试，也没有提供可直接迁移到其它产品的成功率。将它用于自己的项目时，应复用验证步骤，并在自己的环境里取得证据。

可以把任务写成一条具体路径：谁打开哪个入口，输入什么，看到什么结果，刷新后是否仍然存在。涉及登录、权限或发布时，还要说明未登录者和普通读者能看到什么。这样，界面看起来正确与数据真的保存之间的差异就容易发现。

对于内容产品，一个可检查的例子是：编辑者保存草稿，普通读者无法访问；编辑者发布后读者可以访问；后续修改仍保持草稿，直到再次发布。每一步都能用实际页面和数据回读来验证，不依赖“应该没问题”的推测。

网络请求可能已经保存成功，却没有把响应送到客户端。再次点击时，系统需要辨别重复请求，避免产生第二篇文章或重复交易。多人编辑时，旧页面应收到冲突提示，而不是覆盖较新的正文。

这些是本文建议的验收场景。实现时可以先选风险最高的一个操作，模拟响应丢失、刷新重试或版本冲突，再确认数据是否仍然一致。只测试正常路径，无法覆盖这种恢复能力。

交付记录可以很短：需求、改动、测试环境、通过的步骤、已知限制和回退方式。部署成功说明某个版本已经上线；真实用户是否完成任务，需要另一个证据。把两者分别记录，后续修改就能知道哪些假设仍未验证。

建议先阅读来源案例，再为当前项目写一条完成路径，并做一次失败恢复演练。下一次迭代复用同一条路径，只对新增风险补充检查。