05 · 制定时间、预算与学习目标
把网站出海项目拆成四周证据计划，建立现金与时间双预算，设置成本上限和继续、调整、停止条件，避免只用上线作为成功标准。
发布时间：2026-10-31
本页为文字教程；视频与配套媒体仍以实际发布状态为准。
本课交付：四周证据计划与双预算
“一个月做出网站”只描述了交付时间，没有描述做出的东西是否有用。本课把目标改写成可以判断的证据：目标用户是否完成任务、是否采用结果、服务能否稳定交付，以及一笔实验预算能否得到足够信息。你可以更换四周为适合自己的周期，但必须保持每一阶段有明确退出条件。
先写可投入的真实时间。若每天只能在下班后做一小时，就不要按照全职团队的功能清单安排计划。把学习新工具、等待账号审核、排查部署问题、与用户沟通和复盘也列入时间表，不把它们视为“以后自然会发生”的免费资源。
第一周：验证问题，不以写完页面为交付
本周应交付用户任务表、现有替代方案和一份人工完成任务的记录。示例目标是观察几次英文商品介绍的真实处理过程，并确定事实保留与修改的最小边界。人数和完成率应在自己的计划中预先写下，并注明样本很小，不推断整个市场。
如果无法接触任何目标用户，先把问题标成渠道或人群定义风险，不要立即去做登录系统逃避它。Paul Graham关于创业想法与早期人工工作的原文，给出的启发是从真实问题和直接服务中学习；本课将其转成一个时间安排：每周预留固定沟通时段，而不是开发完成才开始找人。
第二周：做出单任务闭环
只实现从输入产品事实到得到可编辑结果，加入必要的长度限制、错误提示和成本保护。不要同时做多语言后台、团队权限、十种模型选择和复杂积分商城。交付标准是另一位测试者在没有你全程解释的情况下，能走完任务并知道如何判断结果。
将每项工作写成可验收的小任务：输入为空时不发请求；超长输入被明确拒绝；超时可以安全重试；密钥不在前端资源中；一次失败不会重复扣减额度。任务完成以测试结果和读回证据为准，不以AI说“已修复”为准。
第三周：发布并测量真正的成功事件
发布正式域名，检查手机、桌面、访问错误和搜索引擎可读取的内容。记录工具完成、结果采用与再次使用等事件，不把访问量当成所有目标。同步核对每次生成的变量成本，包含重试、失败和日志。Cloudflare官方计费页提醒我们资源存在不同维度；实际预算应采用你正在使用方案的最新账单口径。
设置日预算提醒和应用层使用上限。提醒不是硬性限额，看到邮件不代表支出已经停止。为模型调用和存储分别准备停止开关，确认被触发时用户能得到清楚解释，而不是无限重试让费用继续增加。
第四周：复盘并选择一条下一步
复盘表至少有四行：价值证据、获客证据、交付质量、成本。每行写实际结果、与原假设的差异和下一次最便宜的验证动作。例如，用户能生成但不用结果，应先检查质量与场景；用户采用却不再回来，应检查使用频率；无人访问，则尚未检验产品价值，不能直接归因为定价错误。
为继续、调整和停止分别写触发条件。停止一个没有证据的方向，不代表删除全部学习成果；可以保留验证笔记、通用组件和用户允许保留的研究记录。不能为了证明投入值得，反复降低自己事先写下的标准。
现金预算与时间预算分账
以下为教学预算框架，不是实际平台报价。将域名、托管、模型、邮件、媒体、支付与人工支持列为现金项；将研究、开发、质量检查、沟通和维护列为时间项。每项记录币种、计费周期、是否自动续费、取消入口和最坏情况。免费层也要写出超过边界之后会发生什么。
本轮损失约束 = (现金上限，时间上限)
现金与时间分别核对，不能把不同单位直接相加
实验剩余额度 = 批准上限 - 已发生支出 - 已承诺但未扣款支出
不要把自己的小时数直接套成虚假的市场工资得出精确利润，但必须看到它消耗的机会。若项目每周需要大量人工修稿，首笔销售额可能不足以支持持续交付；这正是预算表应揭示的问题。
验收清单
交付四周计划、双预算、风险登记表和复盘模板。检查每周是否都有能被否定的假设；是否给用户研究、部署、支持留出时间；费用提醒和服务停止机制是否真实存在；取消试用和自动续费日期是否记录。完成本课后，你应该能说明下一笔时间或金钱具体用于降低哪个未知风险，而不是只说“再优化一下”。
研究来源与适用边界
资料核对日期：2026年11月2日。本文的工具站、用户记录与金额为教学设计，不代表作者已获得对应收入；平台界面、价格和接入条件应在实际操作时再次核验。