R

rick

202606 WMS/SCM/SRM Cursor 使用情况问卷分析报告 1. 数据概况 数据来源：202606-WMS&SCM&SRM cursor使用情况.xlsx 有效样本：4 份 覆盖团队： 团队 样本数 占比 SCM开发组 1 25% WMS后端开发组 1 25% WMS前端开发组 1 25% SRM开发组 1 25% 覆盖角色： 工作场景 样本数 占比 后端（含 Android） 3 75% 前端 1 25% 人员使用时间： 人员 团队 开始使用时间 截至 2026-06-15 大约使用时长 叶子法 SCM开发组 2026.02 约 4.5 个月 李兰霞 WMS后端开发组 2026.02 约 4.5 个月 尚轲 WMS前端开发组 2026.02 约 4.5 个月 王炜杰 SRM开发组 2025.05 约 13.5 个月 样本限制：当前只有 4 条答卷，结论适合用于识别问题方向、设计优化动作和下一轮调研问题，不适合直接代表 WMS/SCM/SRM 全量使用者。 2. 核心结论 Cursor 已经进入高频、强价值阶段：4/4 受访者“几乎每天”使用，4/4 认为整体效率提升“50%以上”。 当前主要矛盾不是“是否有用”，而是“如何稳定、规范、低成本地把高价值场景规模化”。 最突出的阻碍是额度：2/4 用户表示额度不够用，且这两位均在 1 周内用完月额度。 最稳定的高价值场景是“修改已有代码”：4/4 选择。其次是代码理解、生成初稿、排查 bug、写 SQL、写文档，均为 3/4。 用户最需要的支持集中在“代码评审规范”和“最佳实践分享”，各 2/4；其次是项目规则配置、模型选择指南、安全和隐私边界说明、典型场景培训。 当前已经出现从“个人使用技巧”向“团队工程化配置”的需求，例如 AGENTS.md、项目级 skills、数据库 MCP、SQL 优化辅助等。 3. 多维度分析 3.1 使用频率维度 使用频次 样本数 占比 几乎每天 4 100% 分析： Cursor 对现有受访者不是偶发工具，而是日常开发工作流的一部分。 在这种使用频率下，优化重点应从“推广使用”转向“提升单位额度产出、降低误用风险、沉淀团队标准”。 优化方向： 建立团队级使用规范，而不是只做入门培训。 对高频场景沉淀可复用提示词、项目规则、代码审查标准。 建立额度使用策略，优先保障高收益任务。 3.2 效率提升维度 效率提升感知 样本数 占比 50%以上 4 100% 分析： 当前样本对 Cursor 的价值感知高度一致。 说明后续优化不应聚焦“证明 Cursor 有用”，而应聚焦“把已经验证有效的用法复制给更多人”。 优化方向： 将“提效 50%以上”的典型案例结构化，例如：任务背景、输入上下文、提示词、Cursor 输出、人工校验点、最终收益。 每个团队至少沉淀 2-3 个可复用场景模板。 把最佳实践从个人经验转化为团队资产。 3.3 团队维度 团队 额度情况 主要阻碍 可优先优化点 SCM开发组 1 周用完 额度不够用 数据库 MCP、SQL 排查、SQL 优化、额度优先级 WMS后端开发组 2 周用完 没有明显问题 项目规则配置、模型选择指南 WMS前端开发组 1 周用完 额度不够用 AGENTS.md、项目 skills、跨 IDE/Agent 配置复用 SRM开发组 暂时够用 和现有开发习惯冲突 工作流融合、低侵入使用方式、结对示范 分析： SCM 与 WMS 前端存在明显额度压力，说明这两个场景可能已经将 Cursor 用在高频复杂任务上。 WMS 后端反馈较稳定，适合作为“规范化试点”，先建立项目规则、模型选择和代码评审标准。 SRM 的问题不是额度，而是习惯冲突，说明需要解决工作流嵌入方式，而不是简单增加培训。 优化方向： 对额度消耗快的团队，先做“高收益场景优先级”和“低价值任务限流”。 对反馈稳定的团队，先做“标准模板”和“可复制案例”。 对习惯冲突的团队，先做“嵌入现有流程”的轻量方案，例如从代码解释、局部重构、单文件修改建议开始，而不是要求全流程迁移。 3.4 角色维度 角色 样本数 共同特征 主要阻碍 后端（含 Android） 3 高频使用、提效明显，覆盖代码修改、SQL、bug 排查、文档 额度、习惯冲突、部分无明显问题 前端 1 高频使用、提效明显，重视规则配置和跨工具复用 额度不够用 分析： 后端用户的使用场景更容易扩展到 SQL、bug 排查、文档和代码理解，需要更强的安全边界和评审规范。 前端用户已经提出较成熟的工程化建议，如 AGENTS.md 和项目级 skills，说明前端场景可能适合优先沉淀项目配置模板。 优化方向： 后端：重点建设数据库访问边界、SQL 生成/优化规范、接口变更检查清单、代码评审规则。 前端：重点建设项目规则、组件规范、上下文索引、跨 IDE/Agent 可复用配置。 3.5 高价值场景维度 场景 选择人数 占比 修改已有代码 4 100% 阅读和理解代码 3 75% 生成代码初稿 3 75% 排查 bug 3 75% 写 SQL 3 75% 写文档 3 75% 分析： “修改已有代码”是当前最明确的共性场景，适合优先标准化。 代码理解、bug 排查、SQL、文档都属于强上下文任务，效果高度依赖项目规则、代码索引、提示词质量和安全边界。 仅靠让用户自由输入问题，容易造成额度浪费和输出质量不稳定。 优化方向： 修改已有代码： 建立“改动前理解 -> 影响面分析 -> 最小修改 -> 自测建议 -> Review 清单”的标准流程。 给 Cursor 固定要求：不要大范围重构、不要改无关文件、输出变更原因和风险点。 代码理解： 提供项目结构说明、模块边界、核心链路文档。 建议每个项目维护 AGENTS.md 或等价规则文件，写清模块职责、代码风格、测试约束、禁止事项。 生成代码初稿： 建立“初稿只作为草案，必须人工审查”的团队共识。 对接口、DAO、SQL、安全、权限等高风险代码增加强制检查点。 排查 bug： 提供日志、traceId、接口参数、复现步骤的标准输入模板。 让 Cursor 先输出假设和验证步骤，再改代码。 写 SQL： 使用数据库 MCP 或只读查询工具时，需要明确权限边界。 生成 SQL 后必须检查索引、范围条件、NULL 处理、分页、事务影响。 写文档： 用于接口说明、变更说明、排查记录、Review 说明，降低沟通成本。 建议沉淀统一模板，减少重复写作。 3.6 额度维度 月额度使用情况 样本数 占比 1 周用完 2 50% 2 周用完 1 25% 暂时够用 1 25% 分析： 3/4 用户在 2 周内或更快用完额度，说明额度已经成为继续扩大使用的真实瓶颈。 额度压力集中在 SCM 和 WMS 前端，但样本太小，需进一步扩大统计。 如果不治理额度消耗，高频用户可能转向多个 Agent/IDE 切换，导致配置分散、规范难统一、审计困难。 优化方向： 建立额度分层策略： 高优先级：复杂代码修改、bug 定位、SQL 分析、技术方案评审。 中优先级：代码解释、文档生成、测试思路。 低优先级：简单格式化、普通搜索、无需项目上下文的问答。 建立“额度消耗快用户”的复盘机制：看额度主要花在哪些任务、是否存在重复上下文投喂、是否缺少项目规则导致反复试错。 推广跨工具复用配置，例如 AGENTS.md、项目级 skills、统一 prompt 模板，减少每个工具重复配置成本。 对确实高产出的重度用户，考虑额度倾斜或更高套餐，但前提是有可解释的产出记录。 3.7 阻碍因素维度 最影响继续使用的问题 样本数 占比 额度不够用 2 50% 没有明显问题 1 25% 和现有开发习惯冲突 1 25% 分析： 额度不足是第一优先级问题。 “和现有开发习惯冲突”说明不是所有优化都靠增加额度或培训解决，需要调整接入方式。 “没有明显问题”的用户可以作为示范样本，反向提炼其使用方式。 优化方向： 对额度问题：做额度治理、提示词复用、上下文配置标准化。 对习惯冲突：从低侵入场景切入，例如代码解释、Review 前自查、单个方法重构建议，不强推全流程 AI 编程。 对无明显问题用户：访谈其使用习惯，沉淀可复制流程。 3.8 支持需求维度 期望支持 选择人数 占比 代码评审规范 2 50% 最佳实践分享 2 50% 项目规则配置 1 25% 模型选择指南 1 25% 安全和隐私边界说明 1 25% 典型场景培训 1 25% 分析： 用户并不只是需要“怎么用 Cursor”的入门说明，而是需要“怎么用得安全、稳定、符合团队工程规范”。 代码评审规范和最佳实践分享是最适合短期落地的两个动作。 项目规则配置、模型选择、安全边界属于中期治理项，会直接影响质量、额度和风险。 优化方向： 第一优先级：代码评审规范 + 最佳实践分享。 第二优先级：项目规则配置 + 模型选择指南。 第三优先级：安全和隐私边界 + 典型场景培训。 4. 使用者分层优化方案 4.1 重度高收益用户 识别标准： 几乎每天使用。 1-2 周用完额度。 明确认为提效 50%以上。 当前样本对应：SCM开发组、WMS前端开发组、WMS后端开发组。 优化策略： 优先保障额度，但需要绑定产出复盘。 提供项目级规则配置，减少重复解释上下文。 鼓励沉淀最佳实践，作为团队模板。 提供高级场景支持：SQL 优化、bug 排查链路、复杂改造影响面分析。 4.2 稳定使用用户 识别标准： 高频使用。 额度暂时够用或使用节奏稳定。 没有明显阻碍。 优化策略： 作为标杆样本访谈，提炼其工作流。 让其参与代码评审规范和最佳实践模板共建。 观察是否有隐藏痛点，例如输出质量波动、Review 成本、上下文维护成本。 4.3 习惯冲突用户 识别标准： 认为 Cursor 有提效，但继续使用受到原有开发习惯影响。 当前样本对应：SRM开发组。 优化策略： 不要求一次性改变完整开发流程。 从“辅助型任务”切入：代码解释、变更风险分析、Review 前自查、文档总结。 提供 15-30 分钟结对示范，把 Cursor 嵌入其现有开发链路。 强调 Cursor 输出需要人工决策，降低“被工具替代流程”的抵触。 5. 优化方案优先级 P0：先解决额度和高频场景标准化 原因： 额度不够用是当前第一阻碍。 修改已有代码是 100% 共性场景。 动作： 建立《Cursor 额度使用建议》： 哪些任务值得用高阶模型。 哪些任务可用低成本模型或本地搜索替代。 何时新开会话，何时复用会话。 如何减少重复粘贴上下文。 建立《修改已有代码标准流程》： 先理解上下文。 再输出影响面。 最后做最小改动。 必须提供自测建议和 Review 风险点。 对 1 周用完额度用户做一次复盘： 额度主要消耗在哪些场景。 是否存在多轮无效对话。 是否缺少项目规则导致反复纠偏。 P1：沉淀项目规则和评审规范 原因： 用户明确提出项目规则配置、代码评审规范、安全边界。 这些动作能同时提升质量、降低风险、减少额度浪费。 动作： 每个项目维护 AGENTS.md 或等价配置： 项目结构。 模块边界。 编码规范。 测试约束。 禁止事项。 安全边界。 建立 AI 生成代码 Review 清单： 是否改了无关文件。 是否引入安全风险。 是否破坏事务、权限、幂等、分页、兼容性。 SQL 是否可走索引。 是否补充必要测试或自测说明。 建立模型选择指南： 简单解释、文档总结：低成本模型。 跨文件改造、复杂 bug、SQL 分析：高能力模型。 高风险代码：模型输出只作草案，必须人工审查。 P2：做典型场景培训和最佳实践分享 原因： 最佳实践分享是 2/4 的明确需求。 当前已经有有价值实践：数据库 MCP、AGENTS.md、项目级 skills。 动作： 每两周一次 30 分钟分享： 一个真实任务。 原始提示词。 Cursor 输出。 人工修正点。 最终收益。 建立场景模板库： 代码理解模板。 bug 排查模板。 SQL 优化模板。 文档生成模板。 Review 自查模板。 让重度用户贡献模板，普通用户直接复用。 6. 建议落地路线图 0-2 周 输出《Cursor 使用规范 v1》。 输出《AI 生成代码 Review 清单 v1》。 访谈 2 位 1 周用完额度用户，复盘额度消耗场景。 选 WMS 或 SCM 一个项目试点 AGENTS.md。 2-4 周 建立项目级规则模板。 建立 5 类高频场景 prompt 模板。 做一次最佳实践分享，重点讲数据库 MCP、AGENTS.md、项目 skills。 建立额度使用看板或至少每月人工统计一次。 1-2 个月 扩大问卷样本，覆盖更多 WMS/SCM/SRM 使用者。 对比不同团队、角色、使用时长、额度消耗和提效感知。 建立团队级 Cursor/Agent 使用知识库。 形成“重度用户额度倾斜 + 规范约束 + 产出复盘”的机制。 7. 后续问卷建议补充字段 当前问卷已经能看到方向，但如果要做更准确的管理决策，建议下一轮补充： 每周使用 Cursor 的小时数。 每月额度消耗大概发生在哪些场景。 具体节省了哪些工作：开发、排查、文档、测试、Review。 输出代码被人工大幅修改的比例。 Cursor 输出导致返工或风险的案例。 是否已经配置项目规则文件。 是否使用 MCP、知识库、代码索引、外部文档。 使用的模型类型和选择依据。 是否愿意作为最佳实践分享者。 对安全、隐私、代码外发边界的理解程度。 8. 管理建议 当前最合理的判断是：Cursor 已经在受访者中验证了高频使用和强提效，但还没有完成团队级工程化治理。 建议不要把后续动作做成单纯的“工具培训”，而应做成三件事： 额度治理：确保高价值任务有额度，减少低价值消耗。 工程规范：用项目规则、Review 清单、安全边界保证输出质量。 经验复制：把重度用户的最佳实践变成团队可复用模板。 短期最优先的优化组合： 代码评审规范。 最佳实践分享。 项目规则配置。 额度使用策略。 如果只能先做一件事，建议先做“修改已有代码 + Review 清单”的标准化，因为这是 4/4 用户共同选择的高价值场景，覆盖面最大、落地最快、风险控制收益最高。

202606 WMS/SCM/SRM Cursor 使用情况问卷分析报告 1. 数据概况 数据来源：202606-WMS&SCM&SRM cursor使用情况.xlsx 有效样本：4 份 覆盖团队： 团队 样本数 占比 SCM开发组 1 25% WMS后端开发组 1 25% WMS前端开发组 1 25% SRM开发组 1 25% 覆盖角色： 工作场景 样本数 占比 后端（含 Android） 3 75% 前端 1 25% 人员使用时间： 人员 团队 开始使用时间 截至 2026-06-15 大约使用时长 叶子法 SCM开发组 2026.02 约 4.5 个月 李兰霞 WMS后端开发组 2026.02 约 4.5 个月 尚轲 WMS前端开发组 2026.02 约 4.5 个月 王炜杰 SRM开发组 2025.05 约 13.5 个月 样本限制：当前只有 4 条答卷，结论适合用于识别问题方向、设计优化动作和下一轮调研问题，不适合直接代表 WMS/SCM/SRM 全量使用者。 2. 核心结论 Cursor 已经进入高频、强价值阶段：4/4 受访者“几乎每天”使用，4/4 认为整体效率提升“50%以上”。 当前主要矛盾不是“是否有用”，而是“如何稳定、规范、低成本地把高价值场景规模化”。 最突出的阻碍是额度：2/4 用户表示额度不够用，且这两位均在 1 周内用完月额度。 最稳定的高价值场景是“修改已有代码”：4/4 选择。其次是代码理解、生成初稿、排查 bug、写 SQL、写文档，均为 3/4。 用户最需要的支持集中在“代码评审规范”和“最佳实践分享”，各 2/4；其次是项目规则配置、模型选择指南、安全和隐私边界说明、典型场景培训。 当前已经出现从“个人使用技巧”向“团队工程化配置”的需求，例如 AGENTS.md、项目级 skills、数据库 MCP、SQL 优化辅助等。 3. 多维度分析 3.1 使用频率维度 使用频次 样本数 占比 几乎每天 4 100% 分析： Cursor 对现有受访者不是偶发工具，而是日常开发工作流的一部分。 在这种使用频率下，优化重点应从“推广使用”转向“提升单位额度产出、降低误用风险、沉淀团队标准”。 优化方向： 建立团队级使用规范，而不是只做入门培训。 对高频场景沉淀可复用提示词、项目规则、代码审查标准。 建立额度使用策略，优先保障高收益任务。 3.2 效率提升维度 效率提升感知 样本数 占比 50%以上 4 100% 分析： 当前样本对 Cursor 的价值感知高度一致。 说明后续优化不应聚焦“证明 Cursor 有用”，而应聚焦“把已经验证有效的用法复制给更多人”。 优化方向： 将“提效 50%以上”的典型案例结构化，例如：任务背景、输入上下文、提示词、Cursor 输出、人工校验点、最终收益。 每个团队至少沉淀 2-3 个可复用场景模板。 把最佳实践从个人经验转化为团队资产。 3.3 团队维度 团队 额度情况 主要阻碍 可优先优化点 SCM开发组 1 周用完 额度不够用 数据库 MCP、SQL 排查、SQL 优化、额度优先级 WMS后端开发组 2 周用完 没有明显问题 项目规则配置、模型选择指南 WMS前端开发组 1 周用完 额度不够用 AGENTS.md、项目 skills、跨 IDE/Agent 配置复用 SRM开发组 暂时够用 和现有开发习惯冲突 工作流融合、低侵入使用方式、结对示范 分析： SCM 与 WMS 前端存在明显额度压力，说明这两个场景可能已经将 Cursor 用在高频复杂任务上。 WMS 后端反馈较稳定，适合作为“规范化试点”，先建立项目规则、模型选择和代码评审标准。 SRM 的问题不是额度，而是习惯冲突，说明需要解决工作流嵌入方式，而不是简单增加培训。 优化方向： 对额度消耗快的团队，先做“高收益场景优先级”和“低价值任务限流”。 对反馈稳定的团队，先做“标准模板”和“可复制案例”。 对习惯冲突的团队，先做“嵌入现有流程”的轻量方案，例如从代码解释、局部重构、单文件修改建议开始，而不是要求全流程迁移。 3.4 角色维度 角色 样本数 共同特征 主要阻碍 后端（含 Android） 3 高频使用、提效明显，覆盖代码修改、SQL、bug 排查、文档 额度、习惯冲突、部分无明显问题 前端 1 高频使用、提效明显，重视规则配置和跨工具复用 额度不够用 分析： 后端用户的使用场景更容易扩展到 SQL、bug 排查、文档和代码理解，需要更强的安全边界和评审规范。 前端用户已经提出较成熟的工程化建议，如 AGENTS.md 和项目级 skills，说明前端场景可能适合优先沉淀项目配置模板。 优化方向： 后端：重点建设数据库访问边界、SQL 生成/优化规范、接口变更检查清单、代码评审规则。 前端：重点建设项目规则、组件规范、上下文索引、跨 IDE/Agent 可复用配置。 3.5 高价值场景维度 场景 选择人数 占比 修改已有代码 4 100% 阅读和理解代码 3 75% 生成代码初稿 3 75% 排查 bug 3 75% 写 SQL 3 75% 写文档 3 75% 分析： “修改已有代码”是当前最明确的共性场景，适合优先标准化。 代码理解、bug 排查、SQL、文档都属于强上下文任务，效果高度依赖项目规则、代码索引、提示词质量和安全边界。 仅靠让用户自由输入问题，容易造成额度浪费和输出质量不稳定。 优化方向： 修改已有代码： 建立“改动前理解 -> 影响面分析 -> 最小修改 -> 自测建议 -> Review 清单”的标准流程。 给 Cursor 固定要求：不要大范围重构、不要改无关文件、输出变更原因和风险点。 代码理解： 提供项目结构说明、模块边界、核心链路文档。 建议每个项目维护 AGENTS.md 或等价规则文件，写清模块职责、代码风格、测试约束、禁止事项。 生成代码初稿： 建立“初稿只作为草案，必须人工审查”的团队共识。 对接口、DAO、SQL、安全、权限等高风险代码增加强制检查点。 排查 bug： 提供日志、traceId、接口参数、复现步骤的标准输入模板。 让 Cursor 先输出假设和验证步骤，再改代码。 写 SQL： 使用数据库 MCP 或只读查询工具时，需要明确权限边界。 生成 SQL 后必须检查索引、范围条件、NULL 处理、分页、事务影响。 写文档： 用于接口说明、变更说明、排查记录、Review 说明，降低沟通成本。 建议沉淀统一模板，减少重复写作。 3.6 额度维度 月额度使用情况 样本数 占比 1 周用完 2 50% 2 周用完 1 25% 暂时够用 1 25% 分析： 3/4 用户在 2 周内或更快用完额度，说明额度已经成为继续扩大使用的真实瓶颈。 额度压力集中在 SCM 和 WMS 前端，但样本太小，需进一步扩大统计。 如果不治理额度消耗，高频用户可能转向多个 Agent/IDE 切换，导致配置分散、规范难统一、审计困难。 优化方向： 建立额度分层策略： 高优先级：复杂代码修改、bug 定位、SQL 分析、技术方案评审。 中优先级：代码解释、文档生成、测试思路。 低优先级：简单格式化、普通搜索、无需项目上下文的问答。 建立“额度消耗快用户”的复盘机制：看额度主要花在哪些任务、是否存在重复上下文投喂、是否缺少项目规则导致反复试错。 推广跨工具复用配置，例如 AGENTS.md、项目级 skills、统一 prompt 模板，减少每个工具重复配置成本。 对确实高产出的重度用户，考虑额度倾斜或更高套餐，但前提是有可解释的产出记录。 3.7 阻碍因素维度 最影响继续使用的问题 样本数 占比 额度不够用 2 50% 没有明显问题 1 25% 和现有开发习惯冲突 1 25% 分析： 额度不足是第一优先级问题。 “和现有开发习惯冲突”说明不是所有优化都靠增加额度或培训解决，需要调整接入方式。 “没有明显问题”的用户可以作为示范样本，反向提炼其使用方式。 优化方向： 对额度问题：做额度治理、提示词复用、上下文配置标准化。 对习惯冲突：从低侵入场景切入，例如代码解释、Review 前自查、单个方法重构建议，不强推全流程 AI 编程。 对无明显问题用户：访谈其使用习惯，沉淀可复制流程。 3.8 支持需求维度 期望支持 选择人数 占比 代码评审规范 2 50% 最佳实践分享 2 50% 项目规则配置 1 25% 模型选择指南 1 25% 安全和隐私边界说明 1 25% 典型场景培训 1 25% 分析： 用户并不只是需要“怎么用 Cursor”的入门说明，而是需要“怎么用得安全、稳定、符合团队工程规范”。 代码评审规范和最佳实践分享是最适合短期落地的两个动作。 项目规则配置、模型选择、安全边界属于中期治理项，会直接影响质量、额度和风险。 优化方向： 第一优先级：代码评审规范 + 最佳实践分享。 第二优先级：项目规则配置 + 模型选择指南。 第三优先级：安全和隐私边界 + 典型场景培训。 4. 使用者分层优化方案 4.1 重度高收益用户 识别标准： 几乎每天使用。 1-2 周用完额度。 明确认为提效 50%以上。 当前样本对应：SCM开发组、WMS前端开发组、WMS后端开发组。 优化策略： 优先保障额度，但需要绑定产出复盘。 提供项目级规则配置，减少重复解释上下文。 鼓励沉淀最佳实践，作为团队模板。 提供高级场景支持：SQL 优化、bug 排查链路、复杂改造影响面分析。 4.2 稳定使用用户 识别标准： 高频使用。 额度暂时够用或使用节奏稳定。 没有明显阻碍。 优化策略： 作为标杆样本访谈，提炼其工作流。 让其参与代码评审规范和最佳实践模板共建。 观察是否有隐藏痛点，例如输出质量波动、Review 成本、上下文维护成本。 4.3 习惯冲突用户 识别标准： 认为 Cursor 有提效，但继续使用受到原有开发习惯影响。 当前样本对应：SRM开发组。 优化策略： 不要求一次性改变完整开发流程。 从“辅助型任务”切入：代码解释、变更风险分析、Review 前自查、文档总结。 提供 15-30 分钟结对示范，把 Cursor 嵌入其现有开发链路。 强调 Cursor 输出需要人工决策，降低“被工具替代流程”的抵触。 5. 优化方案优先级 P0：先解决额度和高频场景标准化 原因： 额度不够用是当前第一阻碍。 修改已有代码是 100% 共性场景。 动作： 建立《Cursor 额度使用建议》： 哪些任务值得用高阶模型。 哪些任务可用低成本模型或本地搜索替代。 何时新开会话，何时复用会话。 如何减少重复粘贴上下文。 建立《修改已有代码标准流程》： 先理解上下文。 再输出影响面。 最后做最小改动。 必须提供自测建议和 Review 风险点。 对 1 周用完额度用户做一次复盘： 额度主要消耗在哪些场景。 是否存在多轮无效对话。 是否缺少项目规则导致反复纠偏。 P1：沉淀项目规则和评审规范 原因： 用户明确提出项目规则配置、代码评审规范、安全边界。 这些动作能同时提升质量、降低风险、减少额度浪费。 动作： 每个项目维护 AGENTS.md 或等价配置： 项目结构。 模块边界。 编码规范。 测试约束。 禁止事项。 安全边界。 建立 AI 生成代码 Review 清单： 是否改了无关文件。 是否引入安全风险。 是否破坏事务、权限、幂等、分页、兼容性。 SQL 是否可走索引。 是否补充必要测试或自测说明。 建立模型选择指南： 简单解释、文档总结：低成本模型。 跨文件改造、复杂 bug、SQL 分析：高能力模型。 高风险代码：模型输出只作草案，必须人工审查。 P2：做典型场景培训和最佳实践分享 原因： 最佳实践分享是 2/4 的明确需求。 当前已经有有价值实践：数据库 MCP、AGENTS.md、项目级 skills。 动作： 每两周一次 30 分钟分享： 一个真实任务。 原始提示词。 Cursor 输出。 人工修正点。 最终收益。 建立场景模板库： 代码理解模板。 bug 排查模板。 SQL 优化模板。 文档生成模板。 Review 自查模板。 让重度用户贡献模板，普通用户直接复用。 6. 建议落地路线图 0-2 周 输出《Cursor 使用规范 v1》。 输出《AI 生成代码 Review 清单 v1》。 访谈 2 位 1 周用完额度用户，复盘额度消耗场景。 选 WMS 或 SCM 一个项目试点 AGENTS.md。 2-4 周 建立项目级规则模板。 建立 5 类高频场景 prompt 模板。 做一次最佳实践分享，重点讲数据库 MCP、AGENTS.md、项目 skills。 建立额度使用看板或至少每月人工统计一次。 1-2 个月 扩大问卷样本，覆盖更多 WMS/SCM/SRM 使用者。 对比不同团队、角色、使用时长、额度消耗和提效感知。 建立团队级 Cursor/Agent 使用知识库。 形成“重度用户额度倾斜 + 规范约束 + 产出复盘”的机制。 7. 后续问卷建议补充字段 当前问卷已经能看到方向，但如果要做更准确的管理决策，建议下一轮补充： 每周使用 Cursor 的小时数。 每月额度消耗大概发生在哪些场景。 具体节省了哪些工作：开发、排查、文档、测试、Review。 输出代码被人工大幅修改的比例。 Cursor 输出导致返工或风险的案例。 是否已经配置项目规则文件。 是否使用 MCP、知识库、代码索引、外部文档。 使用的模型类型和选择依据。 是否愿意作为最佳实践分享者。 对安全、隐私、代码外发边界的理解程度。 8. 管理建议 当前最合理的判断是：Cursor 已经在受访者中验证了高频使用和强提效，但还没有完成团队级工程化治理。 建议不要把后续动作做成单纯的“工具培训”，而应做成三件事： 额度治理：确保高价值任务有额度，减少低价值消耗。 工程规范：用项目规则、Review 清单、安全边界保证输出质量。 经验复制：把重度用户的最佳实践变成团队可复用模板。 短期最优先的优化组合： 代码评审规范。 最佳实践分享。 项目规则配置。 额度使用策略。 如果只能先做一件事，建议先做“修改已有代码 + Review 清单”的标准化，因为这是 4/4 用户共同选择的高价值场景，覆盖面最大、落地最快、风险控制收益最高。

共 1 张图片