Grok 编程工作流

Grok 接入后，建议用一次有明确验收条件的小任务确认编程能力。先完成 VS Code 配置 或 Grok Build 安装配置，再执行下面流程。

#1. 定义任务和边界

在项目根目录先运行：

git status --short
git diff --stat

告诉模型哪些文件已有修改。一个合适的首个任务是“修复已知函数的空输入处理，沿用现有测试”，避免首次就要求全仓重构。

#2. 先只读分析

在 Cline 或 Grok Build 中输入：

只读检查当前项目，不修改文件。
找出目标函数、调用位置和现有测试。
解释实际错误原因，再提出最小修改计划。
保留已有未提交改动，使用锁文件对应的包管理器。

核对它确实读取了实现，不是根据文件名猜测。Cline 可以先用 Plan 模式；切换到 Act 时检查供应商仍是 Passion8。

#3. 把规则放在正确的客户端位置

Cline：使用自己的项目规则入口，见 Cline 多模型配置。

Grok Build：在仓库根目录添加 AGENTS.md，例如：

# Project instructions

- Read the implementation and relevant tests before editing.
- Preserve unrelated local changes.
- Follow the existing naming and formatting conventions.
- Do not upgrade dependencies for a small bug fix.
- Run the relevant existing checks and report their real results.
- Report changed files and unverified behavior.

官方 Grok Build 会读取目录树中的项目规则，深层规则在冲突时优先；monorepo 可为各个包添加自己的 AGENTS.md。运行以下命令核对发现的规则与配置来源：

grok inspect

AGENTS.md 是 Grok Build 的规则机制；不要假设每个第三方插件都会读取同一份文件。

#4. 修改、审批和验证

计划确认后输入：

按已确认计划修复该错误。
只修改目标实现和必要测试，不改其他模块。
完成后展示 diff，并运行这个项目中对应的现有检查。

审阅文件写入，再批准测试命令。Grok Build 也可以单次调用指定已配置的 Passion8 别名：

grok -p "只读解释目标函数和现有测试，不修改文件" -m passion8-grok

这里 passion8-grok 是 安装配置 中自定义模型段的别名，不是新的模型 ID。

#5. 接受结果前检查

git diff --check
git diff --stat
git diff

关注修复有没有覆盖原始错误、测试是否实际运行、是否夹带其他修改。模型摘要应列出改动文件、测试命令与结果、仍未验证的行为。完成一个目标后再开启下一个任务。

#长上下文和工具边界

500k 官方窗口不意味着应该每次传入整个仓库。优先搜索和局部读取，保留与当前任务有关的文件。客户端预算、自动压缩和渠道上限分别核对；长会话失败时先缩小上下文。

Cline 的文件、终端和 MCP 工具在客户端运行。xAI 的 Web Search / X Search 等托管工具走不同接口，不能因为模型支持工具调用就认为这些工具已在本站开放。普通文本验证见 Grok API，用量与模型路由以控制台记录为准。

#核对来源

核对日期：2026-10-11。

• Grok Build 项目规则
• Grok Build 自定义模型与 inspect
• Grok 4.7 模型能力