变化：信号无处不在——Slack 讨论串、支持工单、销售记录、Jira 问题等；团队在不同工具间切换时，信号的上下文也随之流失。重要性：忽略需求背后的“原因”，会导致冲刺白白浪费。受影响人员：必须决定优先解决哪些问题的产品经理、研究负责人和客户成功团队。实践建议：配置连接器，让发现智能体导入访谈记录、文档和工单。使用基于证据的痛点看板评估问题的出现频率和严重程度，展示有代表性的客户原话，并标出相互矛盾的信号。风险与限制：嘈杂的输入可能导致评分偏差；应加入人工验证环节，纠正抽样偏差。

变化：确定优先级时，除了业务影响，还必须评估智能体应用的可行性。重要性：编码提速降低了构建产品的成本，真正的瓶颈变成了如何选择正确的投入方向。受影响人员：需要权衡价值、风险和可行性的产品经理、设计负责人及业务利益相关者。实践建议：运行双重评分矩阵——一套 0–10 分标准评估 LLM/工具匹配度和运营准备度，另一套评估影响、投入与监管因素。让优先级智能体生成排名评分矩阵，为每项评分附上可追溯的证据和简短理由。风险与限制：评分权重体现了战略取舍，应提前设定并记录；出现新证据时要重新评分。

变化：设计阶段现在必须产出可作为编码智能体实施依据的交付物。重要性：清晰且包含验收标准的规格说明能减少歧义，加快端到端交付。受影响人员：负责接收规格说明的 UX 团队、产品经理和工程负责人。实践建议：使用逆向工作智能体生成 PR/FAQ，再由规格生成器将其转化为用户流程、用户画像、验收标准和设计交接简报。确保每项需求都标明对应的来源痛点和优先级背景。风险与限制：过于严苛的规格说明可能束缚工程团队的创造力；应加入“约束条件与设计意图”部分，让实施人员能够提出效果相当的替代方案。

变化：设计师智能体可以在编排器使用的同一工作区中生成线框图、用户旅程图和可交互 HTML 原型。重要性：快速原型能让利益相关者和客户在编写代码之前验证甚至推翻假设。受影响人员：必须在工程团队投入开发前审核并签字确认的研究人员、UX 团队和利益相关者。实践建议：对熟悉的领域使用快速通道，对全新的问题使用深度探索。围绕可交互原型开展短周期可用性测试或礼宾式测试，记录指标和客户原话，并将结果补充到痛点看板中。风险与限制：原型可能造成保真度很高的错觉；设计实验应着重明确学习目标和验收门槛。

变化：Kiro 或 Claude Code 等编码智能体可以通过智能体客户端协议（ACP）读取结构化规格说明并快速生成可运行代码，但它们需要明确、无歧义的契约。重要性：附带验收测试、可直接投入开发的规格说明，能弥合产品意图与实际实现之间的差距。受影响人员：工程经理、SRE 和安全审核人员。实践建议：将需求、数据模型、验收标准和测试用例汇总到一个 prototype_spec.md 文件中；使用兼容 ACP 的适配器进行交接，并设置强制人工审核关卡，由审核者接受或驳回规格说明。风险与限制：自动化构建也可能加速错误决策；应为隐私、合规和架构一致性设置明确的检查点。