从“做一个应用”变成一次可以接受的改变
社区摄影社想做一个器材借用登记页：成员查看器材，提交借用申请，管理员确认归还。负责人没有完整开发经验，希望用 Agent 快速做出产品。这里的演练不包括真实上线或真实成员资料。第一目标不是一次生成全部系统，而是让“提交一份申请并能查到结果”成为可运行、可复查的最小切片。
原文覆盖需求与架构、实现与交付、调试与质量，以及技能发现和高效迭代。九个名称代表不同方法角色，不代表必须装九个包。本文把这些角色落在同一案例的交接产物上，不重复下载量、全库安全认证或生成即生产可用的承诺。工具能执行多少取决于宿主权限、项目环境和外部服务，不由“全栈”二字决定。
需求阶段：先约定什么算完成
问清三件事：谁提交、管理员如何识别申请、发生冲突时系统怎么办。把用户描述写成可观察条件：测试成员选择一件可借器材、填入起止日期并提交后，页面展示申请编号；刷新后仍可查看；非法日期被拒绝；网络失败不能显示成功。暂不做支付、短信、智能推荐和公开社区。
还要区分业务词。申请不等于预订成功，管理员确认之前状态为待审核；器材归还不自动说明检查合格。先用纸面状态表列出待审核、批准、拒绝、取消与已归还，以及谁能触发转换。把边界写进一页需求说明、三条用户路径和待决问题，避免生成器自己发明审批规则。
非技术负责人可以用结果和反例表达需求，不必先熟悉所有框架。比如“同一申请连点提交只出现一次记录”比“请用最佳架构保证可靠”更容易验收。尚未决定的权限和保留期限标为待确认，不能把问号藏进代码默认值。规划类方法的产物应是可交付蓝图，而不是越来越长的功能愿望单。
架构阶段：用约束比较方案
先调查已有代码、运行说明和锁定依赖，不为一个新页面直接重建项目。若已有网站，比较复用其登录和数据库与独立原型的成本；若只是本地演练，则可先用测试账号和隔离存储。记录选择依据：部署环境、维护者熟悉度、并发与持久化需要、备份恢复和费用，避免把流行技术栈当成默认答案。
本例把 UI、申请接口和持久化边界画清。服务端检查成员身份与日期，客户端负责交互提示，但不能只靠按钮禁用防止重复写入。模型包含器材标识、申请标识、申请人、日期和状态；个人联系方式不因“以后可能用”就进入第一版。请求重试的幂等策略与申请冲突规则分别说明，二者不是同一个问题。
产物是一条架构决策记录、字段表和接口约定。写出被放弃方案及代价，例如本地 JSON 演示不支持多个进程安全写入，因此不能拿它证明多人上线可用。先保留一种能解释和运行的方案，真实发布前再评估认证、访问控制、数据生命周期与运维需要。本教程没有替代这些上线检查。
实现阶段：让每个切片穿过完整路径
把工作排成可运行顺序：展示测试器材列表、提交与查看申请、管理员状态变更。每个切片都穿过所需界面、接口与存储，而不是先生成全部页面再猜后端怎样连接。任务卡注明允许改的范围、输入、预期行为、运行命令和验收条件；只有一个写入者修改同一批文件，其他审查建议先记录。
一个可用的实现请求是：“在现有项目增加测试申请提交。只改本切片需要的界面、接口和测试；服务端验证起止日期；重复请求返回原申请；网络错误展示失败且保留输入。先说明受影响文件与数据变化，再实现并报告运行结果。不增加支付、通知或新账户服务。”这并不保证代理一定正确，但让偏离范围可被识别。
运行前检查依赖、环境变量与测试数据库。示例配置不能带真实密钥，生成了环境文件也不代表外部服务已连接。若接入第三方服务会产生费用或传输资料，应按实际授权处理；本地占位接口在报告中标明模拟，不把它算作已完成的真实集成。遇到依赖冲突先核对项目版本和锁文件，不为消除一个错误而同时升级整条依赖链。
切片完成后检查 diff，确认没有顺带删除其他功能、改动不相关配置或将临时资料提交。变更报告包括修改文件、数据结构、启动命令、实际执行的检查、未覆盖情况和恢复方法。构建通过说明能生成产物，不说明用户路径、权限或数据持久化都正确；这些要分别观察。
用测试与证据接受这一轮
在本地网页验收阶段使用 Webapp Testing。该固定来源流程通过 Python Playwright 观察页面、选择控件、交互并记录截图和日志。前提是本地应用可启动，已知端口和命令，Python、Playwright 与相应浏览器依赖就绪，测试数据获准使用。它不负责选择产品需求，也不能单凭页面结果证明后端并发和授权正确。
先读实际渲染 DOM 再选择标签或角色定位器。执行“选择器材—填日期—提交—读取申请编号—刷新再查”的路径，同时检查非法日期、接口错误与重复提交。截图用于证明界面状态，接口响应和持久化查询用于证明记录，两类证据要对上同一个申请标识。不要把屏幕上的成功提示当作数据库已写入的充分证明。
对重复提交，浏览器测试可以观察前端行为，另外用服务端测试验证相同幂等键确实只产生一份申请。权限也需要独立测试：另一个成员不能读取或修改不属于自己的记录。不要在报告里把“所选场景通过”扩成“所有浏览器都兼容”或“系统已安全”。如只跑了一个浏览器，就如实写配置；没有运行的测试列为未验证。
验收记录保留版本、测试命令、输入、预期与实际、日志及失败证据。失败后重跑通过仍要记录首轮失败和是否存在偶发问题，不能只展示最后一张绿图。负责人根据预定条件接受或退回这一切片，再开始下一项，防止一连串未确认变化把定位成本叠高。
调试阶段：固定故障，再做最小修复
假设页面提示成功，刷新后申请却消失。先固定环境、提交数据、路径、应用版本和时间，保留请求状态及相关日志。区分浏览器只更新内存、请求没有到达、接口返回错误却被忽略、存储未提交，以及刷新查询过滤错误。这些是待检验假设，不能从截图直接断言“数据库坏了”。
先写一个能重现消失行为的检查，再沿调用链找第一处预期与实际分离的位置。若发现 UI 把所有响应都当成功，应修复状态处理并补充失败提示，同时确认实际存储问题是否另有原因；不要用延迟刷新掩盖失败。修改后重跑原复现、错误分支和邻近路径，并检查 diff 范围，避免“最小修复”只是口头标签。
何时换 Skill？当当前方法不支持实际技术栈或产物需求时可以换；单次报错先排除输入、环境与调用方式。换工具前保存复现与已尝试方案，否则新工具只会再猜一遍。多个调试包同时改一套文件会让因果关系更难判断，应明确当前写入者和审查顺序。
发现技能：按当前缺口找，验证后再关联
描述任务时包含用户、技术栈、项目状态、阻塞与产物，例如“现有本地借用登记页，Python 后端，刷新后申请消失，需要复现步骤和浏览器回归证据”。比较候选的公开来源、SKILL.md、许可证、运行依赖和实际权限，而不只比较排名。记录候选为什么适合哪一步，哪些部分仍需普通工程实现。
当前可核验且用途匹配的关联是上述网页测试流程，用在实现后的浏览器验收。原文规划、蓝图、全栈构建与调试名称未在本文获得对应本站源码证据，不为凑足九个链接添加猜测记录。可以按瓶颈发现新候选，但发现成功不等于已安装，安装不等于已启用，读过指令也不等于执行后产物合格。
若使用发现工具帮助搜索，先核对其官方来源、宿主安装路径与所需访问，再在非敏感样例验证触发和输出。不要承诺自动搜索就允许自动安装所有结果，也不要把静态来源审查称为运行安全认证。保留所用版本与试验记录，更新后复查作用范围，避免技能库变化使旧教程的关联失真。
回滚与交付：代码恢复之外还有数据
每个被接受的切片形成版本节点，记录上一个可运行版本、依赖变化与迁移。代码回退不必然恢复数据库；涉及新增字段或状态时，写清旧版能否读取新数据、是否需要前向修复，并先在隔离副本演练。不要为恢复演示而删除真实申请。
部署准备包含可复现构建、环境说明、备份恢复、日志与健康检查，但仍不等于已经发布。真实上线后还要用获准测试账号观察关键路径、确认版本与监控，失败按方案恢复。此处没有执行部署，交付的是可复查的示例流程，而非宣称摄影社已有生产应用。
常见问题
只有想法从哪里开始？先写用户动作、结果和失败反例，再选规划方法。PRD 能直接变应用吗？可以作为输入，但字段、权限、状态与运行环境仍要落地并分段验收。不会编程能否使用？可以描述与核对用户路径，遇到数据迁移、权限和运行风险应让有相应能力的人复核，不能把生成结果当正确答案。
项目总报错怎么办？收集最短复现、错误日志与版本，区分环境和业务缺陷，再修一处并回归。第三轮越改越乱怎么办？回到最后被接受的节点，对照需求与变更报告，把新愿望拆成下一张任务卡。如何判断完成？产物可运行、指定路径有证据、未验证范围可见、恢复方法可解释，而不是代理说“全部完成”。
来源
中文原文提供规划、构建、质量与发现的场景范围。GitHub 上的 Playwright有公开浏览器测试实现与文档，适合作为页面验收参考；本例优先复用这类成熟方法，不另造浏览器控制框架，也没有安装依赖或实跑摄影社应用。 Webapp Testing 固定来源支持本文关联的本地网页测试步骤，其 Apache-2.0 许可证和依赖应在采用前再次核对。