01 · 成功定义
立项前先写：上线后，谁要完成哪个动作
“搭建 AI 知识库”是一个产品名，不是成功标准。更可交付的表达是：客服在两分钟内找到可追溯的标准答案，并能看到资料版本和负责人。
同样，“重做官网”不如“目标客户在手机上两分钟内看懂三类服务、打开可核验成果、并提交一个具体问题”清楚。后者能直接影响页面结构、内容准备和验收方法。
一句话模板：为了让〈使用人〉在〈真实场景〉下完成〈具体动作〉，我们交付〈可观察产物〉，并用〈检查方法〉确认它能用。
02 · 范围边界
只写“要做什么”还不够，必须同时写“这次不做什么”
例如：一个首页、三个服务页、一个咨询表单、桌面与手机适配、上线配置和使用说明。
例如：这次不做 CRM、不重写全部历史文章、不迁移旧系统、不包含长期内容运营。
产品资料、服务规则、图片、标准答案和测试账号如果延迟，周期也会变。
如果每次确认都需要多个部门重新讨论，项目会在决策等待中失速。
03 · 周期与预算
价格不是按“用了多少 AI”算，而是按交付边界和风险算
| 影响因素 | 为什么影响周期 | 为什么影响成本 |
|---|---|---|
| 真实内容量 | 内容需要整理、确认、导入和校对 | 页面少不代表内容处理量小 |
| 系统与接口 | 要联调账号、数据和失败情况 | 需要更多安全、日志和回退设计 |
| 权限和敏感性 | 需要审批、测试权限与人工确认 | 容错、审计和数据边界要额外交付 |
| 迭代与验收轮次 | 确认人越多，返馈窗口越长 | 超出约定的新需求不应隐形进入原报价 |
因此，一个可靠报价应该和一份范围文档绑定。如果交付物和不做事项还没有说清，页面上的统一低价通常只是一个无法对应真实交付的入口价。
04 · 验收标准
不只看“页面能打开”，至少要检查六层
- 业务验收真实使用者能否完成预定动作，并得到可以继续工作的结果。
- 内容验收名称、规则、数字、链接和对外承诺已经由负责人核对。
- 功能验收核心入口、表单、搜索、权限和失败提示按用例通过。
- 数据验收旧数据不被破坏，新数据存储和导出正确，上线前后有核对依据。
- 安全验收权限按最小必要分配，敏感操作保留人工确认，凭证不出现在页面或日志里。
- 交接验收负责人知道怎么使用、怎么修改、出问题找谁，并拿到必要的说明和备份。
模糊的验收：页面美观、AI 回答智能、系统整体好用。
可执行的验收：指定使用者从首页进入，在手机上完成三个约定任务；每个任务有预期结果、错误情况和通过记录。
可执行的验收：指定使用者从首页进入，在手机上完成三个约定任务；每个任务有预期结果、错误情况和通过记录。
05 · 方案清单
一份正式 AI 项目方案，至少应该写清这十项
为什么做，成功动作是什么。
谁用，在哪里用，使用频率如何。
页面、流程、数据、说明和培训的明细。
明确本期不包含的需求和后续候选项。
谁提供、谁确认、什么时候提供。
账号、权限、接口、备份和数据归属。
首版、试用、修正、上线和交接节点。
付费节点、包含内容、第三方费用和变更方式。
逐项写明检查方法、预期结果和责任人。
什么情况要重新报价、延期、暂停或转人工。
这篇只需要带走四句话
- 先定义使用者的成功动作，再定义系统
- 范围必须同时有交付清单和不做清单
- 周期和成本由内容、接口、权限、风险和验收决定
- 上线不等于交付完成，使用、数据、安全和交接也要验收