#把模糊需求变成可执行任务

当一句“帮我优化一下这个页面”还不足以安全修改代码时，先让 DevCodex 把目标、边界和验收条件说清楚。

#你将完成什么

• 识别这次请求应进入 analyze、dev 还是其他工作流。
• 得到待确认的目标、范围、非目标和验收条件。
• 在确认前保持只读，避免模型过早改代码。

#前置条件

在项目根目录完成 devcodex init，用 devcodex status 确认工作区已识别，并重新打开宿主会话。第一次使用请先走5 分钟开始。

#发送这条请求

分析当前首页加载体验，先澄清“优化”具体指什么。请检查现有实现、列出目标、范围、非目标、风险和可验证的验收条件；确认前不要修改文件。

#预期工作流

DevCodex 应先显示入口检查并选择只读分析路径。你会看到它读取与首页相关的代码、配置和现有约束，然后给出需求定义或需要补充的问题，而不是立即写文件。

#写入边界与确认

分析阶段可以读取仓库、运行只读诊断和整理证据，但不能把“我理解了”当成实施授权。若结论指向代码变更，后续应按 dev 的 CP1 → CP2 → 条件 CP3 顺序确认；删除等不可逆操作仍需单独确认。

#可见结果

成功时，你至少应得到：

• 一个明确的任务目标和用户结果；
• 包含与不包含的范围；
• 可验证的验收条件；
• 受影响消费者与主要风险；
• 推荐工作流和下一步确认点。

#如果没有进入正确路径

• 仍然直接改代码：重申“确认前不要修改文件”，并检查入口块中的意图是否为 analyze。
• 项目上下文缺失：运行 devcodex status；若 Profile 缺失，按故障排查恢复。
• 目标仍然含糊：补充用户、场景、当前问题和成功标准，不必先给出技术方案。

#下一步

需求确认后进入 dev 工作流；如果你只需要一份结论，停在分析报告即可。