写下第一行代码前，该弄清什么

团队有个创意：几分钟内准备供应商提案的服务。技术栈、注册表单和页面列表都已选好，只剩一个令人不安的问题：谁需要这个结果，发生什么才会愿意付费？

写第一行代码前，不必掌握市场的一切，而要找到可能改变“是否开发”这个决定的未知因素。几次有针对性的验证就可能大幅收窄产品范围。有时技术很简单，真正障碍却是数据访问或采购流程。

明确研究要支持的决策

“做探索”范围太大。请明确要做的选择：是否推出独立产品、首版服务哪个情境、是否承接定制开发，还是先从有限服务开始。

假设一个采购服务，问题可以是：“是否有依据投入一个团队月，为小型制造企业自动比较报价？”所需信息就明确了：比较频率、耗时环节、结果由谁使用和付费，以及怎样的结果才会被接受。

单独列出团队自身约束。如果无法支持几十种文档格式，这条边界从一开始就应参与客户细分选择。否则研究可能找到诱人需求，而公司暂时无力服务。

拆解最近一次真实经历

请采购人员展示最近一个例子：原始报价、比较表和最终决定。查看文件前，先约定访问范围与机密数据删除方式。真正有用的产物是匿名化的任务结构，不是别人的商业信息。

还原顺序：为何采购，找到哪些方案，补充确认过什么，谁检查条款，延迟出现在哪里。围绕一次已完成的经历，能区分惯常的流程叙述与真实发生的过程。

如果对方说“比较很耗时”，就追问时间花在哪里。计算也许只需十分钟，取得缺失的交货日期却耗了三天。自动计算并不能消除这个关键约束。

使用者、购买者与审批者可能不是同一个人

在 AJTBD 的 B2B 分析中 需要考虑角色、内部审批和实施障碍。日常使用者认可，并不代表采购能通过其他环节。

可以画一张简单角色图：采购人员准备比较，生产经理检查材料适用性，财务负责人批准支出，IT 决定哪些文件能交给外部服务。每个角色都有自己的同意条件。

不一定能在原型之前见到所有人，但尚不清楚的参与者应保留为明确风险。“采购人员喜欢”不等于回答了谁会批准用真实工作数据接入服务。

把已有认识分成三栏

这张表防止证据被悄悄抬高等级。一个故事不能代表市场频率，愿意沟通不等于有预算，成功分析一个文件也不能证明所有格式都可靠。

下一次验证应足够小，可以放心停止；又足够有意义，结果能够改变计划。技术风险可以通过处理样本文档并人工核对来验证；价值则可以通过手工比较结果是否被用于真实采购决策来验证。

启动前先约定试点条件

明确输入、承诺结果、时间、人工处理边界和验收标准。例如，采购人员应获得指定字段的可比条件，每个数值都能追溯到源文件。这比“AI 自动化采购”具体，也让工程师理解可核验性要求。

预先明确什么结果会要求调整计划。如果主要工作是追补信息，可能需要收集答复的服务；如果数据不能离开公司，就需要不同部署方式；如果节省太少、撑不起定价，就要重审情境或收费模式。

应该向工程团队交付什么

进入首版开发时，应明确用户、触发情境、有用结果、约束、现有证据和剩余风险，并补上发布后如何观察，以及谁负责试点后的决策。

不确定性仍会存在，但现在它已被明确，并连接到具体行动。团队有了依据，只构建获得下一个可验证结果所必需的系统部分。