用一份活动报表打通需求、SOP 与产品
社区手作空间每周把报名、签到和退款整理成活动报表。运营说“做个能看报表的后台”，却没有说明报表里的收入按收款日还是活动日计算。开发如果直接画图表，很可能越做越偏。本例从这句话开始，交付可评审需求、可重复操作程序，再把一条报表路径做成可验收原型；没有导入真实客户数据，也没有上线应用。
原文的三个场景是澄清需求写 PRD、把重复工作整理为 SOP、按五阶段推进产品。这里保留三者的区别：PRD 说明系统应满足什么，SOP 说明某项工作怎样执行，工作流还需要触发、状态与实际执行者。写出步骤并不会自动建立权限、调度或可靠的失败恢复。所谓 Review 与 Vibe Check，也要变成明确证据，而不只是“感觉不错”。
第一场景：把一句话拆成可评审 PRD
先收集获准使用的会议记录、现有表格和原始报表，标出来源日期。把内容分成已确认事实、提议、矛盾与缺失。会议里有人说“老板主要看周收入”只是一个需求输入，不能自动升级为所有用户的唯一目标。列出角色：运营校对数据、负责人查看汇总，普通报名者不访问后台。
优先澄清会改变结果的变量：一周从哪天开始、时区是什么、取消与退款怎样计算、缺签到是否算缺席。可以一次提出最关键的问题，并在答案未到时继续整理不受影响的部分；不能自行补齐业务口径。比如负责人确认按活动发生周统计，退款按所属活动回冲，那么报表应能追溯这个规则版本，不能混用资金流水的收款周。
PRD 初稿包含问题、角色、范围、核心流程、字段定义、异常状态、权限和验收条件。自动补漏只负责指出可能遗漏的点，补充建议保持待确认；不要把模型猜测写成已经批准的决定。现有 PRD 的扩展请求也要说明改变哪些规则、影响哪些页面与旧记录，并保留变更依据。
具体验收可以写为：“测试活动 A 有三笔有效报名、一笔全额退款；汇总表显示有效人数与退款后金额，并能展开查看对应记录；缺少金额的行进入异常清单，不能按零计入。”数字来自测试夹具而非真实运营结果。交付一份 PRD、一张术语表和待决问题清单，每项问题有负责人和对下一步的影响。
第二场景：从口述经验提取 SOP
请运营描述一次完整的周报工作，不只说理想流程，还要说明上周哪里返工。记录触发时机、输入文件、文件版本、每步动作、检查点、输出和接手人。转录中的“把那个表再处理一下”需要追问究竟是哪张表和什么处理，不能用漂亮标题掩盖操作缺口。
本例 SOP 从导出获准测试数据开始：保留原文件与导出时间，核对列名和活动标识，统一日期格式，按确认规则匹配退款，生成候选汇总，人工检查异常，最后发布批准的周报。每个步骤写明前置条件和停止条件；没有活动 ID 的退款不能随意匹配金额相同的一行，应进入待核对队列。
把判断分支写出来。例如“退款重复”可能是重复导出，也可能是两笔真实部分退款。先用交易标识和来源记录核实，不直接去重删除。数据源缺文件时暂停受影响部分，明确报告不完整；不让代理为了给出完整答案而编造缺失表。产物可包括步骤文档、分支流程图和执行清单，但三者应指向同一规则版本。
质量评分可以提示步骤缺少输入或检查点，却不能代替实操验证。安排另一位操作者只依照 SOP 处理一份脱敏样例，记录在哪一步需要口头补充，修正文档后再试。合并冗余步骤时保留必要的人工审核，不能为了流程短而删除发现错账的关口。
从 SOP 到自动化机会清单
将步骤分成确定性处理、需要判断与外部写入三类。格式检查和按明确 ID 合并适合先自动化；退款归属冲突交给运营；发布周报属于带实际影响的写入，需要相应授权和审核状态。自动化的第一版可以只产生草稿与异常清单，不必同时接入调度、邮件与所有系统。
建立一个可调整的阶段路线图：先跑单次样例，再做小规模人工触发，稳定后考虑定时执行。原文提出九十天计划与 ROI 预测，本例不把固定天数或模型算出的收益当承诺。先记录人工耗时、复核时间、错误返工、维护成本和接口费用，再比较多次可比运行；节省点击不等于节省同样比例的全部工时。
工作流需要 run_id、输入版本、当前步骤、审批状态和重跑规则。导出超时先检查文件是否已生成；发布超时先核对结果，不能盲目重复发送。定义部分失败时保留哪些产物、谁处理异常和何时停止重试。没有配置真实调度器就写“手动执行”，不要把文档中的触发时间当成已创建的定时任务。
第三场景：五阶段落实为产品门槛
需求阶段接受上述 PRD，第一版只做上传测试文件、展示待审汇总和异常清单。架构阶段比较现有工具扩展与独立原型，记录维护、存储与权限约束。GitHub 的 MADR 提供精简架构决策记录方法，本例借鉴其记录背景、候选方案与选择理由的思路，不需要为写一条决策额外安装应用。它是文档方法，不会替团队自动决定架构。
代码生成阶段一次实现一条完整路径：读取文件、验证、生成结果并显示异常。使用隔离夹具，原始文件只读，导出文件另存。任务明确允许修改的文件范围和不做的功能；新增依赖说明用途与版本，模拟接口标明未连接。UI 看起来像后台并不说明数据正确，必须按固定样例核对每个汇总值。
调试阶段先保留错误输入、版本、运行命令和期望结果。如果同一退款被扣两次，沿导入、匹配、汇总链路查第一处重复，不先重写整个后台。修复后运行原失败样例和相邻分支，确认没有把正常的两笔部分退款错误合并。迭代阶段只接收一项已评审变化，例如增加活动筛选；重新核对旧汇总，不让新功能悄悄改变口径。
部署准备另外列明环境变量、访问控制、数据备份、健康检查与恢复方法。生成部署说明不是已经上线，测试模式成功不是正式环境通过。代码回滚也不一定恢复已变更的数据，迁移与恢复要在隔离副本演练；本案例没有创建账户、发布报表或进行生产部署。
在哪个步骤使用可核验 Skill
Webapp Testing仅用于原型的本地浏览器验收：应用运行后观察实际 DOM，选择文件与筛选控件，核对异常提示、结果展示，并记录截图和日志。使用前需要 Python、Playwright、对应浏览器依赖、本地启动命令和获准样例。它不负责抽取完整业务 SOP，也不能单独确认会计口径或服务端数据正确性。
可以要求验收“上传合法样例显示汇总，缺活动 ID 显示异常，切换筛选不丢失异常提示，页面刷新后的状态符合 PRD”。数据计算另有确定性检查，两者共同支持结论。详情页的固定来源和 Apache-2.0 许可证可复查，静态来源核验不等于本应用已实跑或安全认证。
原文六个名称没有在本专题获得对应本站源码与用途证明，因此不凭名称添加链接。寻找新候选时说明当前缺口，例如“从脱敏操作转录提取带异常分支的 SOP”，然后检查来源、SKILL.md、许可证、权限和依赖。先在一份可恢复样例试用，分别记录发现、安装、调用与产物验收，不以一条安装成功提示代替结果。
一份能复用的任务输入
把任务交给 Agent 时附四项内容：已批准的周报口径 v2、测试夹具、允许改动范围、验收条件。示例要求是：“把口述流程整理为 SOP；已确认规则与建议分列；每步写输入、动作、产物、停止条件；缺信息放待确认；不要连接外部账户或发布结果。”进入编码阶段再传入确认后的版本，避免把最初的讨论稿作为永久需求。
每轮输出变更摘要、文件清单、规则变化、实际运行检查和未验证项。保留最后被接受的版本节点，下一位操作者能从该点继续。若问题只影响发布方式，就不要同时重写导入逻辑；把不同目标拆开能减少回归范围，也让失败时的恢复路径更清楚。
排查与 FAQ
PRD 一直写不完？检查是不是把待决问题混成无限追问，先确定最小使用路径及阻塞变量。SOP 很完整却没人能执行？用新操作者试跑，找出隐藏的口头知识和缺少的文件入口。自动化节省不明显？检查复核、例外处理与维护是否抵消收益，缩小范围后再比较。
非技术人员能推进吗？可以负责业务口径和可观察验收，技术选型、权限与数据恢复仍需要相应能力复核。是否可以不看代码？可以少手写，但需要理解修改范围与验证证据；“感觉页面对了”不能确认数据和权限。工作流必须由 AI 自动跑吗？不必，人工与确定性脚本同样可组成工作流，先保证职责和异常处理，再考虑智能步骤。
来源
中文原文提供三个场景与五阶段范围；本文以独立周报案例重写，没有沿用下载量和安全保证。MADR是 GitHub 检索后参考的精简决策文档方案，公开说明支持 MIT 或 CC0 许可选择，适合记录本例架构理由。 Webapp Testing 固定来源用于本地界面验收方法。这里没有安装或执行所列工具，所有运行结果要求属于示例验收设计。