⏱ 预计阅读：9 分钟
[!summary] 这篇把镜头放在第一行代码出现之前：需求该走哪条研发路径，问题值不值得解，完成到底怎么验收，用户如何走完流程，界面要覆盖哪些状态，系统边界又该画在哪里。前面少说清一个问题，后面的 Skill 往往就要各猜一遍。
先设一个贯穿全文的工程样例
假设你要做一个面向团队的“资料问答工作台”：管理员导入一组内部文档，成员提问后获得带来源引用的答案；管理员能控制哪些人能看哪些资料，并能追踪失败问答。这个样例足够小，能由独立开发者完成；也足够真实，会逼出权限、数据删除、Agent 工具、流式交互和发布回滚这些问题。
这六个 Skill 不需要同时开工。先看项目缺的是商业判断、需求、交互还是系统边界，补最短的一段就够了。唯一不能省的是交接：上游留下的未知项，到了下游仍然要叫“未知”，不能悄悄变成既定事实。
S000：先给需求选路，再决定调用谁
1. $haonan-s000-pmp 如何把一句需求路由成研发路径
图注：S000 先分类事实与未知项，再选择最短研发路径和质量门禁。
如果手上只有一句“做个资料问答”，我不会马上让 Codex 列页面。先把已有仓库、现成文档、明确约束和未知项摊开，判断现在缺的是战略、需求、交互还是架构。S000 会把这些信息分成 EXPLICIT（已明确）、INFERRED（有依据的推断）、UNKNOWN（会影响决策的未知）。单租户还是多租户、文档是否包含敏感资料、模型能不能执行写操作，都不能因为用户没提就由 AI 自动补全。
随后 S000 在三种模式中选择：ROUTE 为单一请求找下一步；PLAN 画多阶段依赖 DAG（有向无环图）；AUDIT 查已有资产的缺口和错序。对上面的工作台，合理输出不是“依次执行所有 Skill”，而是：先 S001 判断是否值得做，再 S002/S003/S004；S005-1 到 S005-4 在 HLD 契约稳定后并行；测试计划和威胁模型可以前置；S006 在设计和发布两个时点各做一次门禁。
最后得到的是一张能执行的路径表：每个阶段需要什么输入，会交付什么，依赖谁，在哪个门禁停下来检查。S000 不替下游写设计和代码，它只负责把范围与授权边界钉住。这里最容易犯的错，是把“项目编排”理解成越完整越好，最后生成几十份没人会用的文档。我更看重的是：为当前目标挑出最少但足够的一组 Skill。
S001：先验证价值，再把时间投入实现
2. $haonan-s001-ceo-strategy 如何把产品直觉变成下注实验
图注：S001 将用户、替代方案、商业变量与低成本实验连接到继续或调整决策。
S001 要回答三个朴素问题：给谁用，替代什么，凭什么现在值得做。资料问答工作台的使用者可能是频繁查制度的运营同学，买单者可能是部门负责人，现有办法则可能是共享盘、企业搜索或直接问同事。三者不能混在一张“用户画像”里，因为他们在意的结果完全不同。
接下来，把每条判断的来源、置信度和反证条件写出来，再挑最大的未知做低成本实验。比如拿一小批可脱敏文档，请几名目标用户完成一组常见问题，观察答案能否追到原文、权限有没有越界、用户是否愿意放弃原来的查找方式。具体样本量应由项目条件决定，不能把示意数字写成经验定律。实验还要事先约定成功阈值和停止条件，否则很容易只收集支持自己想法的反馈。
这些判断最后会收敛为战略命题、非目标、目标客户、替代方案、单位经济变量、风险，以及 INVEST / EXPERIMENT / PIVOT / STOP 建议。S002 真正需要接住的是可验证假设：谁先用，最小价值是什么，暂时不做什么，看到什么结果就应该推翻当前判断。至于 TAM（市场规模）和转化率，没有资料就留空，别为了让报告完整而编出一组数字。
S002：把“要做什么”写成可测试的需求契约
3. $haonan-s002-prd 如何消除功能、状态与验收的歧义
图注：S002 将业务场景拆成可追溯的需求、业务规则与验收标准。
“支持智能问答”看起来像需求，实际上无法验收。S002 要做的，是让产品、设计、开发和测试对“完成”采用同一解释。它先定义背景、目标、非目标、角色、核心对象和术语，再写主流程、异常流程和状态机。比如“导入文档”至少要说清谁能导入、允许哪些格式、解析失败怎么反馈、重复上传怎么处理、删除后引用与索引何时失效、成员何时能够看到。
它用稳定 ID 建立追溯：功能需求为 FR-###，非功能需求为 NFR-###，验收标准为 AC-###，业务规则为 BR-###，风险为 RISK-###。每个关键 FR 至少连到用户场景、业务规则和可观察的 AC。以“成员提问”为例，不能只写“支持智能问答”；可写成：当成员对其有权访问的资料提问时，系统返回答案、引用片段和无结果提示；当引用资料被删除或无权限时，不得显示其内容。AC 用 Given/When/Then（给定/当/则）表达，测试才能直接接住。
这些 ID 最后组成需求—流程—页面—验收—风险追溯矩阵。性能、可靠性、安全、隐私和可访问性，如果暂时没有基线，就明确标成“待基线化”。S003 从这里接任务流和状态，S004 接系统边界与约束，S009 接测试基线。PRD 篇幅短并不可怕；真正危险的是用“体验更好”“响应更快”这样的形容词假装已经定义了需求。
S003：用线框和状态机验证任务流，不抢做视觉或代码
4. $haonan-s003-prototype 如何把验收标准落到每一屏
图注：S003 先搭信息架构与任务流，再覆盖异常和恢复状态。
原型最有价值的时刻，往往不是主路径第一次点通，而是第一次遇到失败与恢复。S003 默认以 SPEC 模式产出页面地图、线框和交互规格，不直接写生产前端。它从“角色—任务—入口—结果—恢复路径”开始：管理员从资料库进入上传，成员从问答页进入提问；每条任务除了成功终点，还要有返回、取消、失败重试和权限不足的出口。
在资料问答样例中，原型应至少明确三类状态。第一类是内容状态：资料库为空、上传处理中、解析失败、索引完成。第二类是问答状态：输入中、流式生成、工具检索中、无可靠答案、引用不可用。第三类是控制状态：无权限、网络断开、重复提交、危险删除确认。每个屏幕要写目标、内容层级、控件、校验、跳转和响应式规则；每个关键动作都要有反馈。
screen-map 会把屏幕 ID、入口、角色、关联 FR/AC 和状态连起来。S003-2 据此知道哪些视觉状态必须补齐，S004 和 S005-4 也能看到页面边界与端侧约束。只画 happy path（顺利完成路径），等于把空状态、错误状态和移动端规则留给开发临场发明；反过来，在这一阶段就做高保真，也会过早锁死品牌和实现方式。
S003-2：把“能点”的原型升级为可交付的视觉系统
5. $haonan-s003-2-ui 如何让全页面和资产不再各自漂移
图注：S003-2 从视觉母版扩展到 Token、组件状态、真实资产与交付审计。
如果我一个人做产品，会先用 S003-2 做一张视觉母版，而不是一口气铺开所有页面。它可以从 PRD、原型、截图或真实路由启动，先建立 route-design-map 或 screen-design-map：本轮究竟覆盖哪些页面、状态和角色。凡是设计过程中推导出的页面，都要单列为假设，不能悄悄混进真实需求。
视觉工作先做一张母版：一个核心页面、关键组件、主要状态和资产样例。方向确认后才形成语义颜色、字体、8pt 间距、圆角、阴影、动效强度、响应式断点，以及按钮、输入框、卡片、弹窗、Toast（轻提示）等组件在默认、悬停、禁用、加载、错误状态下的规则。资料问答工作台的关键不是把聊天框画得炫，而是让“引用来源”“工具执行中”“需要管理员审批”“无权访问”有一致且不误导的视觉语言。
交付物除了页面稿，还包括 tokens.json、真实资产、资产清单、页面—资产映射和 UI 审计。前端 LLD 接走 Token、组件、状态和资产契约，评审则拿到视觉验收基线。默认 DESIGN 模式不改代码，只有明确授权才进入 IMPLEMENT。如果只有首页，没有加载、空、错误、权限等状态稿，UI 其实还没交付完。Emoji、临时 CSS 图形和被拉伸的图片也不能代替最终资产。
S004：把产品规则转成稳定的系统边界
6. $haonan-s004-hld 如何在“能跑”与“可演进”之间做取舍
图注：S004 根据真实约束选择复杂度，并将稳定边界分发给四个详细设计分支。
架构图最容易在这里变成技术名词展览。我通常先问三个问题：数据由谁负责，信任边界在哪里，某个依赖失败后用户会看到什么。S004 负责回答这些高层问题，不提前写字段级 DDL 或部署脚本。它从 PRD 提取权限隔离、文档规模、响应时间、预算、可用性、数据敏感度和外部模型依赖，再比较至少两个可行方案，用 ADR（架构决策记录）留下选择依据以及放弃另一方案的原因。
对独立开发者，S004 最重要的纪律是复杂度分级：SIMPLE 可以是单体加托管数据库和异步任务；STANDARD 才引入清晰模块和有限服务拆分；COMPLEX 需要规模、隔离、合规或组织证据。资料问答工作台并不会因为有 Agent 就自动需要多智能体、Kubernetes（容器编排）或私有模型。架构应画清用户、应用、身份系统、文档存储、检索服务、模型服务和审计之间的数据流、权限流与超时/重试/降级边界。
最后要留下组件职责、数据所有权、同步与异步接口类别、NFR/SLO（服务目标）、容量和成本假设、RTO/RPO（恢复目标）、迁移与回滚策略，以及四个 S005 分支共同使用的输入契约。安全威胁模型也可以从这里与 S010 并行启动。HLD 好不好，不看图上有多少方框，要看数据、后端、Agent 与前端各自细化后，是否仍在同一条边界上说同一种语言。
开发前的交接检查：六份资产怎样真正连起来
用下面四个问题检查是否可以进入详细设计：
- S000 是否把未知、依赖和授权边界写清，而不是只列 Skill 名称？
- S001 的关键假设是否有实验和停止条件，并已传递给 S002？
- S002 的每个关键 FR 是否至少关联 AC、状态、风险与责任边界？
- S003/S003-2 的屏幕和状态，是否能分别追溯到 PRD；S004 的组件和 NFR，是否也能追溯到 PRD？
某一项暂时答不上来，不代表项目必须停工。把它标成草案或阻塞任务，继续做不依赖它的部分即可。最怕的是写一句“开发时再看”，几天后却发现它已经变成不可回滚的协议、数据或权限决定。
明日预告｜第 3 篇：开发中，怎样让四层契约真正接上
当 PRD、原型和 HLD 都准备好，真正难的交接才刚开始。下一篇会进入 S005 到 S008，沿着同一条问答链路，看数据、后端、Agent 和前端怎样共享字段、权限、错误与状态；也会讲清技术评审、任务 DAG 和代码验证如何把这些契约变成真正跑得过的实现。