分享基于Cursor与多模型协作的高效AI编程工作流

背景

随着 AI 编程助手（如 Cursor）的普及，开发者不再仅仅满足于简单的代码补全，而是开始探索更复杂的自动化工作流。然而，直接使用 AI 进行开发往往面临需求模糊、上下文缺失、幻觉频发以及重构成本高等问题。

本文分享了一套基于 Linux DO 社区讨论形成的稳定 Coding 工作流组合。该工作流并非单一工具的堆砌，而是通过多个专用工具（Cursor++, ACE, smart-search-cli, grill-me, Trellis）的协同，构建了一个从“需求澄清”到“代码实现”再到“规范沉淀”的完整闭环。其核心逻辑在于：在让 AI 动手写代码之前，先通过多轮拷问和检索，确保需求清晰、上下文完整且方案可行，从而避免“猛猛干”后的高昂重构成本。

核心内容

1. 基础架构：Cursor 与模型路由

作者坚持使用 Cursor 作为核心 IDE，因其拥有极低的日常交互成本。在 Cursor 的 Agent Window 中，开发者可以同时查看代码、Diff、文件操作记录、命令输出及诊断信息，实现了多任务并行处理。

为了解决订阅限制并接入更多模型，作者使用了 Cursor++ 插件。该插件允许轻松接入 BYOK (Bring Your Own Key) 服务器，支持切换包括 CPA 的 gpt-5.5、自定义 OpenAI/Anthropic 兼容接口在内的多种模型。这种多模型路由机制使得开发者可以根据任务类型选择最合适的模型，而非依赖单一模型。

2. 多模型分工策略

作者根据任务特性，将不同模型分配至特定场景，以平衡效果与成本：

• 复杂代码修改 / 多文件重构：倾向使用 gpt-5.5。尽管其成本高，但在处理复杂逻辑时表现稳定（“力大砖飞”）。
• 中文总结、归档、润色：使用 deepseek v4。
• 低风险文本处理：使用 gemini-3.5-flash。速度快，适合简单文档整理，但需警惕其偶尔的“嘴硬”或幻觉。
• 方案审查：交叉使用多个模型进行对比。
• 外部资料整理：先通过搜索工具获取信息，再交由 gpt-5.5 或 qwen3.7-max 总结。

3. 上下文增强：本地与外部检索

为了解决 AI “只看当前文件”导致的上下文缺失问题，工作流引入了两个关键检索工具：

• ACE (本地代码库语义理解)：用于解决“AI 不复用现有工具、不遵循项目结构”的问题。通过语义级检索，回答诸如“相关代码在哪些模块”、“调用链走向”、“类似逻辑实现”等问题。
  • 工作流习惯：涉及跨文件影响时，先用 ACE 找模块，再读文件确认风格，最后才让 Agent 修改。
• smart-search-cli (外部资料入口)：基于 grok-search 思路重构的 CLI 工具，替代了臃肿的 MCP 搜索插件。它具备搜索、抓取、文档检索和 Deep Research 计划能力，输出可保存为 JSON/Markdown，过程可复现。
  • 应用场景：查询新工具、新 API、官方文档、社区帖子等易过时信息。作者认为 AI 凭记忆回答此类信息极易产生幻觉，必须通过搜索获取最新证据。

4. 需求澄清与任务管理：grill-me 与 Trellis

这是该工作流中最具特色的部分，强调“磨刀不误砍柴工”。

• grill-me (需求拷问)：针对模糊需求，通过不断提问（一轮约 20 个问题）来澄清意图。作者认为多数 AI 产出垃圾是因为需求本身模糊，而非模型智商不足。
• Trellis (共识落档与执行闭环)：将 grill-me 澄清后的想法转化为结构化文档。
  • 核心文件：prd.md (需求/验收标准), design.md (设计边界/数据流), implement.md (执行计划/回滚点), .trellis/spec/ (项目规范)。
  • 辅助命令：trellis-before-dev (开发前读规范), trellis-check (实现后检查), update-spec (经验沉淀), finish-work (收尾记录)。
  • 适用场景：多文件改动、新功能、重构。简单修改可直接执行，无需开启 Trellis Task。

5. 最新迭代：Trellis 0.6.0-beta.21 的变化

在最新版本中，trellis-brainstorm 已融合了 grill-me 的核心 Prompt 和行为模式。因此，分工变得更加灵活：

• 轻量模糊想法：使用独立的 grill-me，不创建 Trellis Task。
• 正式开发任务：直接使用 trellis-brainstorm，它同时承担需求拷问和 PRD 生成。
• 复杂/高风险任务：在已有 PRD 基础上，可再次使用 trellis-grill-me 或 grill-me 进行二次拷问优化。

6. MCP 的态度：按需接入

作者对 MCP (Model Context Protocol) 持谨慎态度，认为其更适合作为工具接口而非工作流核心。已删除 Context7 和 mcp-deepwiki（被 smart-search 替代），仅保留浏览器、GitHub、Playwright 等必要工具。工作流的定义更多依赖于规则、Skill 和 Trellis 文档，而非依赖大量 MCP 服务器。

7. 完整工作流示例

面对复杂任务的标准流程：

1. Phase 0 (拷问)：描述想法 -> grill-me 拷问需求。
2. Phase 1 (调研)：代码相关问题 -> ACE；外部资料问题 -> smart-search-cli。
3. Phase 2 (规划)：共识明确后 -> Trellis 生成 PRD/Design/Implement。
4. Phase 3 (执行)：Cursor + Cursor++ 选择合适模型执行 -> 按需调用 MCP。
5. Phase 4 (闭环)：Trellis check 检查 -> update-spec 沉淀规范 -> finish-work 记录。

对于简单任务，则跳过上述复杂流程，直接口头描述让 Agent 执行。

8. 全局提示词原则

作者的全局提示词核心包括：

• 证据优先，不凭空假设。
• 修改前先理解项目上下文（本地用 ACE，外部用 smart-search）。
• 复杂任务优先走 Trellis 流程。
• 高风险操作必须先问。
• 未跑验证不得声称验证通过。
• 交付时必须说明改动、验证内容及剩余风险。

关键要点

• 前置澄清优于快速生成：花时间在 grill-me 和 Trellis 上理清需求和规范，远比快速生成代码后花费大量时间重构要划算。
• 多模型协同：没有万能模型。利用 Cursor++ 实现模型路由，根据任务复杂度、语言偏好和成本敏感度选择 gpt-5.5、deepseek v4 或 gemini-3.5-flash。
• 检索增强生成 (RAG) 的本地化与外部化：
  • 本地代码理解依赖 ACE 的语义检索，避免 AI 盲目修改。
  • 外部知识依赖 smart-search-cli 的 CLI 工具链，确保信息时效性和可复现性，减少幻觉。
• 结构化工作流：通过 Trellis 将非结构化的对话转化为结构化的 PRD、Design 和 Implement 文档，使 AI 的执行有据可依，并将经验沉淀为项目规范。
• MCP 做减法：MCP 是工具而非流程。保留必要的浏览器和代码库接口，剔除冗余搜索插件，避免工作流