04 · 拆解一个小网站的经营过程
把网站经营拆成获客、交付、收费、支持和复购，沿一笔教学订单建立状态与证据链，找出自动化前必须人工验证的环节。
发布时间：2026-10-31
本页为文字教程；视频与配套媒体仍以实际发布状态为准。
本课交付：一条从来源到售后的经营链
网站不是首页加一个生成按钮。本课沿着一位假设用户的完整任务画出经营过程：她在搜索中发现教程，进入工具，生成商品介绍，调整事实，决定购买额度，付费后继续处理，最后遇到一次失败并联系支持。这是教学情境，不是一个已经发生的客户案例。
先画出八个方框：发现、理解、尝试、成功结果、付款、权益、支持、再次使用。每个方框写一个能观察的事件和一个责任人，责任人可以暂时都是你，但不能写“系统自动处理”后就不再定义成功条件。
沿着任务记录状态，而不是只截成功图片
发现对应可追踪的入口；理解对应用户知道工具做什么、不能做什么；尝试对应有效请求被接收；成功结果对应用户采用或导出结果。最后一个比“接口200”更接近价值。即使模型成功返回，如果内容篡改了产品材质或尺码，任务仍可能失败。
为每一步设计最少的数据。事件可以记匿名任务ID、版本、耗时与错误类别，不必把完整商品资料塞进分析平台。MDN安全文档提供的是常见风险基础，本项目的具体落实是：输入按不可信数据处理，密钥不放前端，错误日志不记录用户全文，数据读取验证所有者。能完成生成，不能替代这些边界检查。
用一笔教学订单建立证据链
准备一条测试订单，状态从created到pending，再到paid或failed。只有服务端确认的支付结果才触发权益。用户看到成功页只是浏览器导航结果，不应单独把它当成入账凭证。本课先画状态图，支付接口的详细实现放到后续专课，避免把未经测试的示例直接用于收款。
来源会话 → 核心任务 → 测试订单 → 支付提供商记录 → 权益记录
↓
退款／支持记录
为每条箭头写出关联ID和检查方法。价格使用产品与价格标识关联，不能仅凭界面上的“高级版”三个字匹配商品。Stripe的产品价格文档可作为建模参考；实际选择其他支付商时，需要重新映射它的对象，不应照搬资源名。
人工先走一遍异常分支
给流程加入四张故障卡：生成超时、支付结果延迟、付费后额度未增加、用户要求删除已保存历史。逐张回答用户看到什么、能否安全重试、重复请求会不会扣两次额度、后台能否找到相关记录、支持人员可访问哪些数据。若只能通过直接修改数据库解决，应记录临时操作并尽快设计可审计的管理入口。
早期可以手动联系愿意参与测试的人，观察他们实际如何使用。Paul Graham关于不可扩展工作方式的原文，支持的是主动做一线工作以获得反馈；并不意味着可以长期用人工掩盖产品承诺的自动交付能力。若收费承诺立即得到额度，就不能把每天手工批量发放当成已实现即时交付。
把经营台账和产品分析分开
经营台账关注钱、订单、退款与责任；产品分析关注用户在哪一步离开、是否完成任务、是否回来。二者可以通过最小化的标识关联，但不是同一张随意堆字段的表。发票、支付状态和私人资料不应为了看一张漏斗图就全部发送给分析供应商。
每周选一个失败案例复盘，先重现原过程，再判断属于产品、服务、支付还是沟通问题。不要一看到用户离开就调整按钮颜色。例如进入工具后退出，可能是输入资料不齐；付款后不使用，可能是权益没有发放；这些问题需要查看不同证据。
演练：把支持问题还原成技术证据
假设用户反馈“付款后仍显示免费额度”，先问订单标识和发生时间，而不是让对方发送完整银行卡截图。后台按订单找到支付记录，再查对应用户与权益写入结果。若付款属于另一个账号，应走身份核实和正常处理流程，不能仅凭一张截图把任意账号改成付费。记录处理人、修改前后状态和关联订单，重试操作必须避免重复发放。只有读回用户实际可用额度，才能结束这条异常路径。
完成标准与下一步
交付一张八步流程图、一笔完整测试任务的脱敏记录、四条异常路径，以及一份客服回复草稿。回复必须说明事实、当前处理状态和下一次更新时间，不承诺无法控制的支付到账时点。模拟数据要明确标注，不能放进真实营业报表。
当每条链都能由记录解释，你才知道应该自动化哪一环。若成功路径本身没有被真实用户采用，继续增加营销自动化只会放大无效流量；若只是人工反复复制同一条可靠操作，才适合将它写成任务和后台流程。下一课会把这些责任转成时间预算和停止条件。
研究来源与适用边界
资料核对日期：2026年11月2日。本文的工具站、用户记录与金额为教学设计，不代表作者已获得对应收入；平台界面、价格和接入条件应在实际操作时再次核验。