ACDL研发流程02：从想法到项目骨架
ACDL研发流程系列第2篇，共15篇。
项目刚开始时，先验证方向
一个项目刚开始时，Director可能只有一个模糊想法：某类用户遇到了一个问题，现在的软件似乎解决得不好，新技术也许能够提供一种不同做法。此时连产品是否值得做都还不确定，立即建立完整需求、设计、版本和交付记录，只会让尚未验证的猜测看起来像已经确认的需求和设计。
冷启动要做的，是用尽可能低的成本回答三个问题：
1.我们是否正在解决一个真实且值得处理的问题？
2.我们想到的核心做法是否可行？
3.我们能否做出一个有人愿意真正使用的最小结果？
这一章是ACDL之前的冷启动教程，不属于ACDL的强制流程。它的终点不是“产品已经设计完成”，而是得到一个方向清楚、可以运行、值得继续建设的项目骨架。
先把需求说清，不要急着设计答案
不过度设计，不等于带着一句模糊口号就让Agent写代码。如果Director说不清准备为谁解决什么问题，Agent只能自己补全产品目标。它也许能很快生成一个界面完整的系统，但这个系统很可能没有真正用户。
开始实现前，Director至少要能用普通语言说清：
- 谁会遇到这个问题；
- 他当时想完成什么任务；
- 现在为什么难以完成；
- 什么最小改变能让他得到实际价值；
- 用什么现象判断方向值得继续；
- 当前已经确认什么，还在猜什么。
这些问题要清楚，但答案不必一次完整。例如，Director可以确定“企业员工希望用自然语言让智能体完成一项重复任务”，但暂时不决定最终要支持多少类工具、怎样编排多个Agent、是否提供插件市场。前者是决定要验证什么，后者是在证据出现前就提前设计未来。
用对话把脑中的想法说出来
冷启动时，可以把Agent当作一个随时讨论想法的伙伴。Director不必先写出完整方案，可以直接讲自己看到的问题和初步想法，让Agent帮助追问、重述和比较不同做法。
这时不需要准备一个巨大而完美的Prompt。多聊几轮，每次说清一个问题，发现Agent理解不对就马上纠正。最终目的不是让Agent替Director作决定，而是帮助Director说清需求，找到下一件最值得验证的事。
善用语音对话
当Director脑中已经有很多背景，但还没有组织成一份书面材料时，语音往往比键盘更适合快速说出和展开想法。具备语音能力的对话工具可以用来追问、头脑风暴和边说边修正想法。Director可以要求Agent先听完背景，再逐个提问；也可以在听到错误理解时立即打断并纠正。
语音会话结束后可以回看聊天中的文本，但转写不一定与当时说过的每句话完全一致。因此，不要把整段语音转写直接当作需求文档。对话结束时，可以让Agent整理出“问题、已确认事实、当前假设、候选方向、下一步验证”，再由Director亲自删改和确认。
让工具选择服从当前问题
冷启动的大部分对话不需要一次给出最终答案。日常发散、用户场景梳理和候选方向比较更看重对话连续，复杂架构、安全边界和高成本选择则需要更充分的调查与推理。使用什么工具或模型，应根据当前问题、可用能力和风险决定。
无论使用什么工具，重要结论都要回到可核对的事实。对话可以帮助形成候选方向，但不能替代PoC、真实使用、代码验证或Director确认。
从PoC到MVP，再到项目骨架
对话能够帮助Director改进问题，但不能证明一个想法可行。一旦当前最需要验证的问题已经清楚，就让Agent做出可以运行、能够验证想法的最小结果。
PoC、MVP和项目骨架不是三道必须严格依次审批的流程。一个熟悉的技术方向可能不需要单独PoC，一个复杂想法也可能需要多个相互独立的PoC。它们表示的是三种不同的问题。
用PoC验证最大的不确定性
PoC是Proof of Concept，即概念验证。它只需要回答一个对方向有决定作用的问题，例如：目标模型能否稳定识别特定业务指令，某个企业系统是否提供必需的接口，或者一条实时交互链路能否达到可接受的延迟。
为了尽快得到答案，PoC可以临时写死数据，可以只在本机运行，也可以没有完整界面。它暂时不必具备正式产品所需的通用性、运维性和全部安全要求。但Director要清楚记住这些省略：PoC证明了一个概念可能成立，不代表它已经可以直接进入生产。
用MVP验证最小用户价值
MVP是Minimum Viable Product，即最小可行产品。PoC回答“某个关键想法能不能做到”，MVP则回答“最小的完整体验是否已经能给用户带来价值”。
MVP不是把所有功能都做到粗糙的半成品，也不是把几个PoC放在同一页面上。它需要选中一个真实用户和一项核心任务，让用户可以从开始走到结果。与这项任务无关的个性化、管理界面、扩展接口和高级配置，都可以暂时不做。
把有效结果整理成可以继续开发的骨架
当PoC已经证明关键做法可行，MVP也让Director看到了最小用户价值，就需要决定哪些临时结果值得保留，哪些应该删掉重做。不要因为原型已经能运行，就让所有临时代码直接变成长期基础。
一个可以继续开发的项目骨架，通常已经具备：
- 明确的目标用户和核心任务；
- 一条可以真正运行的端到端路径；
- 已经选定并实际跑通的基本技术栈；
- 能够安装、启动、运行最小测试的代码仓库；
- 大致稳定的核心模块边界；
- 已知限制、未验证假设和下一步决定。
骨架不等于空白的脚手架目录，也不等于已经完成的产品。它是一个有核心路径、有实际技术选择、可以让Agent继续读取、修改和运行的最小代码仓库。
什么不要提前设计
冷启动阶段最容易发生的偏差，是Director和Agent开始为尚未出现的未来编写大量结构。一旦话题变成通用插件体系、无限扩展、完整角色矩阵、多租户、微服务、多地容灾或全部平台组合，先回到当前用户和最小任务，问一句：现在有什么证据说明必须解决这个问题？
不要过度设计，也不等于所有决定都留给未来。会让PoC根本无法开始，或者后续更换成本极高的事情，仍然需要Director当场做出最小决定，例如核心数据归属、不能突破的安全边界、目标部署环境、基本技术栈和必须接入的外部系统。只决定当前试验必须依赖的部分，并清楚记下还没有决定的内容。
用一个例子走完冷启动
假设Director最初只有一个想法：“做一个能帮企业员工工作的Agent平台。”这句话无法直接指导实现，因为“帮助工作”可以包含几乎无限多种任务。
Director先通过语音和文字对话补充自己观察到的问题。几轮追问后，当前最值得验证的场景变成：一名企业员工在自己的私有工作空间中，通过对话要求Agent读取一份文件并生成摘要。系统暂时不解决多Agent协作、公共Skill市场、企业审批和多种业务系统接入。
第一个PoC只验证模型能否根据员工指令正确读取文件并返回有用摘要。它可以使用本地文件和临时脚本，不先建账号体系和完整界面。
PoC证明核心链路可行以后，MVP再提供最小的登录、对话、私有工作空间和结果展示，让一名真实员工可以完整走完这项任务。Director亲自试用，判断这条路径是否值得继续投入。
方向成立后，Agent清理只为试验服务的临时代码，保留真正有用的端到端路径，补上基本构建、测试和运行入口，形成可以继续开发的项目骨架。
这个例子只用于说明冷启动方法，不是当前项目的历史记录。
什么时候结束冷启动
冷启动没有一个固定天数，也不需要等到所有问题都有答案。出现以下情况时，项目通常已经值得结束快速试验，进入持续的工程化建设：
- Director能够说清主要用户、核心问题和当前产品边界；
- 至少一条核心使用路径已经可以真正运行；
- 最重要的可行性假设已经由PoC或实际结果验证；
- 基本技术栈、代码仓库和核心模块已经能够支持后续开发；
- 下一批工作需要跨会话追踪，或者开始涉及多个并行任务；
- 错误决定和实施偏离的返工成本已经明显上升。
按实际复杂度增加工程约束
项目结束冷启动以后，不需要立即套用完整ACDL，也不应只根据代码行数决定流程深度。更有用的判断是：一项决定是否已经难以撤回，工作是否需要跨会话继续，多个任务会不会互相影响，是否涉及安全、生产数据、环境发布或正式交付。
当一次对话已经难以掌握全部目标和历史决定时，就开始系统建设文档、明确验收场景并补齐自动化测试；当多项工作需要并行、错误决定的代价明显提高或准备形成正式版本时，再引入Loop、独立评审和版本验收。代码规模可以提醒复杂度正在增长，却不能替这些事实作决定。
无论代码行数是多少，都不要把全部聊天记录和临时代码原样留给后续Agent自己理解。Director需要与Agent一起整理当前确认的问题、产品边界、技术选择、已知限制和未决问题。下一章将说明这些内容怎样进入文档，并像代码一样持续维护。