有一个项目想法，却不知道第一步该做什么，是很多非技术用户真正的卡点。
你可能同时在想：要不要买现成产品？找人配置就行吗？能不能把几个工具接起来？在已有方案上修改会不会更快？还是只能从头开发？
最容易花冤枉钱的做法，是还没确认问题，就直接开始“做一个系统”。代码和预算已经投入，最后才发现真正需要的只是一个成熟产品、一组设置，或者一条把已有工具连起来的自动化。
先判断该买、配、连、改还是建
把交付路径分成五类，不是为了增加术语，而是为了避免过早自研。
买：现成产品已经够用
核心需求已经被成熟产品覆盖，就先买。不要为了少数非关键差异承担开发、测试、维护和交接成本。
配：能力已经有了，只差设置
产品本身能完成任务，只是字段、权限、提醒或工作流程还不合适，就先配置。
连：能力分散在不同工具里
客户、消息、订单或文件已经存在于多个工具，真正缺的是数据和动作之间的连接。这类问题通常先评估集成或自动化。
改：主体可用，但关键规则特殊
成熟方案已经覆盖大部分流程，只有少数关键业务规则、交互或权限需要定制，这时再做有限修改。
建：前四条都解决不了核心问题
只有核心流程、权限、数据结构、体验或风险要求无法由现成方案满足，才进入自研。自研不是更专业的默认答案，而是承担长期成本后的选择。
例如，你想做一个客户跟进工具。如果核心只是记录联系人、设置提醒和交接任务，先看现成 CRM 或表格配置；如果客户、消息和订单分散在不同工具里，先评估连接；只有审批、权限或数据结构确实特殊，才进入有限定制或自研。
这个例子只用来演示选路，不代表某种方案适合所有项目。
AI 应该先问清五件事
路径判断前，先回答：
- 谁是实际用户？
- 他们在哪个场景完成什么关键动作？
- 最后必须看到什么可观察结果？
- 预算、时间和维护边界是什么？
- 哪些风险绝对不能接受？
这些问题不像开发任务，却决定项目最终会不会有人用。
人掌舵，AI 推进
人负责目标、体验、成本和不能接受的风险。AI 可以帮助研究方案、拆解任务、实施、验证和整理证据。
付款、部署、修改权限、启用外部服务和处理生产数据等会产生真实影响的动作，仍然需要人的明确授权。
完成要过两层验收
第一层是用户验收：入口能找到，关键动作能完成，结果能看懂，失败时知道怎么办。
第二层是工程验收：测试通过，安全与恢复达到需要的等级，文档和交接完整。
页面能打开、代码上线或测试通过，都不能单独证明用户已经获得真实可用结果。
复制这段启动模板
我有一个项目想法：
[用一句话描述想解决的问题]。
请先确认真实目标、目标用户
和可观察结果，再判断
“买、配、连、改、建”中
最合适的交付路径。
不要默认写代码。
请先给一个推荐，并列出
会改变路线的已确认事实、
假设和阻塞。
只向我询问会实质改变成本、
体验、风险或维护方式的问题。
未经我单独确认，不要提交、
推送、部署、付费、处理
生产数据或执行不可逆操作。
把第一句话换成你的项目想法，然后粘贴到一个新的 Codex 任务。第一轮先得到目标、推荐路径、关键假设和下一步，不需要先安装 Skill。
做到下面四点，就算第一轮完成：
- 已经写清实际用户和要解决的问题；
- 已经选出一条优先交付路径，并说明为什么不是另外四条；
- 已经定义一个用户能观察到的结果；
- 下一步如果涉及付款、部署、权限或生产数据，流程会停下来等你确认。
如果 AI 仍然直接开始写代码，就补充实际用户、可观察结果、预算时间和不能接受的风险，再让它重新选路。信息不足时，不要让它用猜测补齐关键决策。
现在就能开始
入行实验室正式页已经提供同一份可复制模板。
项目源码与发布事实可以从 GitHub 公开仓库查看。
当前实验室页面明确标注为 Preview。公开仓库和生产页面已经可访问，但正式前向评测、全局 Skill 安装和真实用户效果尚未被证明。GitHub 仓库目前没有附加 LICENSE，因此只能说源码公开可见，不能写成已经授予复制、修改和再分发权利的开源项目。