项目早期很容易出现两种进展：页面越来越多，或者底层设计越来越完整。但业务人员仍然无法用系统完成一件具体的事。第一周更有价值的目标，是用最小范围验证整条工作路径。
先找最可能让项目失败的假设
GOV.UK 的 Alpha 阶段指导把原型用于检验高风险假设，而不是提前完成整个服务。[1] 我们将这一思路用于企业 AI 试点：第一周优先验证最不确定、又足以改变项目方向的环节。下面的节奏是工作安排建议，不是所有项目的交付承诺。
假设目标是生成客户跟进建议。最大的不确定性可能是企业资料不足，也可能是现有销售系统不允许读取必要字段。此时先制作精美的聊天页面，并不能降低主要风险。应该先拿到授权样例，确认能否形成可追溯的判断。
第一、二天：把输入和结果固定下来
选一个使用者、一种任务和一个数据来源。将输入样例、期望结果及失败条件放在同一个说明中。结果最好能够被直接检查，例如生成一份待审核草稿，并关联到正确的公司记录，而不只是“给出专业建议”。
同时记录外部依赖：账号权限由谁提供，字段由谁解释，测试数据能保存多久。无法按时取得真实接口时，可以先用明确标注的样例验证界面，但要单独列出尚未验证的接入假设，避免演示效果掩盖交付风险。
第三、四天：接通一条窄路径
让数据进入系统，经过处理，再由使用者确认，最后形成一个可以找回的结果。沿途尽量复用现有能力；固定规则清楚的部分，用普通代码处理。Anthropic 对工作流和 Agent 的区分提供了一个参考：明确步骤可以预先编排，只有需要动态判断路径时才增加自主决策。[2]
在这个例子里，第一版可以只支持一类公司资料、一个输出模板和人工审核。先不加入多个角色协商、自动发送或复杂的任务调度。范围收窄之后，更容易判断失败发生在资料、推理、呈现还是审核动作。
第五天：让使用者操作，而不是观看
安排一次短测试，把鼠标交给真实使用者。工程师观察他在哪里停顿、何时回到旧工具、哪些信息仍需要口头解释。演示讲得很顺，与使用者独立完成任务，是两种不同的结果。
复盘只需要回答几个问题：路径是否走通，哪项假设被支持，哪项被推翻，下一步继续、缩小还是停止。若关键数据不可获得，及时停止某条方向也是有效交付。第一周留下的决定，应该让第二周更确定，而不只是更忙。
把第一版写成“一个人，完成一种任务，得到一个可检查的结果”，再据此删减功能。
参考资料
本文结合公开资料与 Terriva 的方法建议整理。文中的假设场景用于说明设计思路，不代表客户实绩。