日常开发工作流

任务描述越具体，越容易让 Qwen Code 找到正确上下文并验证结果。官方常见工作流采用“先理解、再修改、最后核验”的顺序。

理解与定位

在项目根启动 qwen，先问整体结构、关键数据模型和项目术语，再缩小到功能文件和调用链。例如从认证文件位置追踪到前端、后端与数据库，而不是要求一次解释整个仓库的每一行。

已知文件用 @src/path 提供上下文；当前源码对 @目录 返回目录结构和文件信息，不会递归注入所有正文。Commands 表的“递归读取全部文本”与 Common Workflows/实现不一致，这里按 atCommandProcessor → readManyFiles 的目录分支说明。

重要代码应逐文件引用或明确要求读取。官方还说明文件引用可引入其目录及祖先 QWEN.md，需留意上下文指令来源。MCP 资源采用 @server:uri 形式，实际 URI 应由已连接服务提供。

修复与重构

提供失败命令、完整错误、复现步骤，并说明是稳定还是偶发。先让模型定位原因并比较修复选项，再限定文件与行为实施。

重构应写清不变的外部行为、兼容要求及已有约定，分成可测试的小步；不要只说“现代化”而省略运行环境和验证目标。

测试与文档

先定位未覆盖的行为，再参考现有测试框架和断言风格生成用例，补错误、边界和意外输入，最后运行相关测试。验证对象应是行为，不只是新增代码行。

文档任务可指定 JSDoc、docstring 等现有风格，优先公共 API、接口和复杂逻辑，再补实际示例并核对项目约定。

专用 agent 与交付

/agents 可查看和创建 subagent；官方建议给明确用途、description、所需工具和系统提示，项目定义放 .qwen/agents 共享。工作目录隔离另见Worktree，不因“启用 subagent”就自动拥有独立文件状态。

生成 PR 前先总结真实改动、验证结果和风险，再让模型形成描述并审阅。自然语言“create a pr”是实际任务请求，不是只生成示例文本；应明确目标仓库和范围。

自动化与证据

cat build-error.txt | qwen -p "Explain the root cause and cite evidence in this log." > analysis.txt

机器消费见无头输出。官方建议把团队的证据规则放项目 QWEN.md：结论追溯实际日志、查询或命令输出，代码阅读推断应标注，逐环验证因果链，历史陈述只当线索。

这些是工作要求，不会自动保证模型结论正确。恢复旧会话后仍要核对当前代码和运行结果，不以以前的回答代替新证据。