# code agent 个人工作流：trellis+grill-me+fast-context+grok-search

**URL:** <https://www.nodeloc.com/t/topic/97224>\
**Category:** 工具控\
**Tags:** AI\
**Created:** [2026 年7 月 2 日 10:41 UTC](https://www.nodeloc.com/t/topic/97224 "2026-07-02T10:41:41Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

作者： ![MuXu\_YI](https://www.nodeloc.com/user_avatar/www.nodeloc.com/muxu_yi/32/32633_2.png) [@MuXu\_YI](https://www.nodeloc.com/u/MuXu_YI)\
发布日期： [2026 年7 月 2 日 10:41 UTC](https://www.nodeloc.com/t/topic/97224/1 "2026-07-02T10:41:42Z")

</div>

_声明：具体相关工具的配置在仓库md中提及，不清楚的也可以在本帖留言，我会一一回复_  
开源自荐，我先放个地址：[GitHub - dream-rec/dream-workflow: personal code workflow. · GitHub](https://github.com/dream-rec/Dream-Workflow)  
安装命令：`npx dream-wf`，支持claude code, cursor, codex, opencode

# 正文开始

最近我越来越觉得，code agent 最大的问题不是“不会写代码”，而是“太快开始写代码”。

很多时候，用户只说一句“帮我优化一下”，agent 就开始改文件、重构逻辑、顺手加配置。看起来很主动，但也很危险：需求没确认，代码没读透，外部 API 可能还是旧认知，最后越写越偏。

所以我现在更喜欢给 agent 一套工作流，而不是只给它一个任务。

这套组合是：

这套组合不是简单堆工具，而是每个工具各自补上 agent 工作流里最容易出问题的一环：

- `Trellis` 负责流程。它的优势在于 harness 工程做得很完整：任务状态、PRD、设计、实现计划、检查项、hooks、spec 更新都能串起来。相比普通 TODO 或“先写个计划”，Trellis 更像是给 agent 铺了一条工程化轨道。

- `grill-me` 负责澄清。它不做开放式头脑风暴，而是一次只问一个关键决策，并给出选项和推荐答案。相比常见的 PRD 模板，它更能降低用户负担，也更容易把模糊需求压缩成可执行决策。

- `fast-context` 负责读代码。它的核心优势是上下文和 code 片段的精准召回。相比只靠 grep 搜关键词，它更适合回答“某个行为在哪里实现”“这个功能涉及哪些文件”这类语义问题，让 agent 在改代码前先拿到正确上下文。

- `grok-search` 负责查外部事实。它的优势是精准联网检索、网页抓取，以及返回 source URL。相比让模型凭记忆回答，它更适合验证最新文档、API、配置格式和 release 状态，把“我记得”变成“我查证过”。

它们合起来解决一个问题：让 agent 在写代码前，先知道自己为什么写、往哪写、凭什么写。

* * *

## Trellis：把任务从聊天里拎出来

`Trellis` 是这套工作流的骨架。

它的价值不是多生成几个文档，而是把需求、设计、实现计划和检查项沉淀到项目里，而不是散在聊天记录里。

一个复杂任务会有明确的状态和产物：

- `prd.md` 记录需求；
- `design.md` 记录设计；
- `implement.md` 记录实现计划；
- `check.jsonl` 记录检查点；
- task 状态从 `planning` 到 `in_progress`。

这让 agent 不再靠“记忆”工作，而是靠项目里的事实工作。

> design.md有传统意义上的trd的意思，所以有过产品设计经历的朋友应该很熟悉这一套流程。

我的理解是：Trellis 不是让 agent 更啰嗦，而是让它有上下文、有边界、有交接能力。

* * *

## grill-me：少问，但问到点上

很多 agent 澄清需求时，要么不问直接猜，要么一次抛十几个问题。

`grill-me` 的风格更像一个有经验的产品同事：

- 一次只问一个问题；
- 给 2-3 个选项；
- 给出推荐答案；
- 能从代码里查到的，就别问用户；
- 用户回答后，立刻更新 `prd.md`。

它的重点不是“多问”，而是“每个问题都解决一个关键决策”。

比如不是问：

> 你想怎么优化登录？

而是问：

> 登录失败时，要展示通用错误，还是按错误类型展示具体提示？我推荐后者，因为当前项目已有表单错误组件，改动小，体验提升明显。

这种问题用户更容易回答，agent 也更不容易跑偏。

* * *

## fast-context：先理解代码库，再动手

代码库不是字符串集合。

很多时候，我们并不知道该搜哪个函数名，只知道一个行为：

- 登录后跳转在哪里处理？
- MCP 配置在哪个平台写入？
- task 状态流转在哪里定义？
- 某个功能涉及哪些文件？

这类问题用普通关键词搜索很容易漏。

`fast-context` 的特色是语义检索。它更适合让 agent 先建立代码库地图：哪些文件相关，逻辑怎么串起来，改动可能影响哪里。

我一般会把它放在实现前的第一步：

> 先用 `fast-context` 找上下文，再用精确搜索补细节。

这能减少一种很常见的错误：agent 只看到局部匹配，就以为自己理解了全局。

* * *

## grok-search：别靠旧知识写新代码

code agent 很容易犯的另一个错，是把训练时的知识当成今天的事实。

但开发环境变化太快了：

- API 会改；
- 配置格式会变；
- hook 事件名会更新；
- 包可能迁移；
- 文档可能已经不一样。

所以我会让 `grok-search` 负责外部知识验证。

尤其在 PRD 确认前，agent 需要检查那些可能过期的技术假设，比如：

- 某个 MCP server 的启动命令是否正确；
- Cursor / Codex / Claude Code 的 hook 配置是否变了；
- 依赖包是否仍然可用；
- 官方文档是否和当前方案一致。

查完后，把结果写进 `Knowledge Verification`。

这一步的意义是：把“我记得”变成“我验证过”。

* * *

## 组合起来，重点是顺序

这套工作流最重要的不是工具本身，而是顺序。

```plaintext
Trellis 定义任务边界
        ↓
fast-context 理解代码库
        ↓
grill-me 澄清关键决策
        ↓
grok-search 验证外部事实
        ↓
确认 PRD
        ↓
开始实现

```

* * *

## 我真正想要的 agent

我不太想要一个“特别积极”的 agent。

我更想要一个靠谱的员工（也是体验上当老板的滋味了）：

- 知道什么时候该问；
- 知道什么时候该查；
- 知道什么时候不能动手；
- 知道需求要落盘；
- 知道外部事实要验证；
- 知道确认之后再实现。

所以这套 `trellis + grill-me + fast-context + grok-search` 工作流，本质上不是为了让 agent 写得更快，而是让它少走弯路。

先读，先问，先验证，先确认。  
然后再写代码。

> 写到最后，这是我自己平常开发的一套流程，想了很久，隔壁do站也有号，但是还是想发在我们NL站，也是与社区的朋友们的一次“友好交流”。哈哈哈哈，很喜欢这边自由的环境。

---

<div class="post-metadata">

作者： ![metucky](https://www.nodeloc.com/user_avatar/www.nodeloc.com/metucky/32/59103_2.png) [@metucky](https://www.nodeloc.com/u/metucky)\
发布日期： [2026 年7 月 2 日 10:46 UTC](https://www.nodeloc.com/t/topic/97224/2 "2026-07-02T10:46:12Z")

</div>

感谢大佬的分享

---

<div class="post-metadata">

作者： ![jzhfg](https://www.nodeloc.com/user_avatar/www.nodeloc.com/jzhfg/32/3611_2.png) [@jzhfg](https://www.nodeloc.com/u/jzhfg)\
发布日期： [2026 年7 月 2 日 11:14 UTC](https://www.nodeloc.com/t/topic/97224/3 "2026-07-02T11:14:26Z")

</div>

将类别从 **杂谈** 变更为 **工具控**

---

<div class="post-metadata">

作者： ![Amiya\_desi](https://www.nodeloc.com/user_avatar/www.nodeloc.com/amiya_desi/32/54171_2.png) [@Amiya\_desi](https://www.nodeloc.com/u/Amiya_desi)\
发布日期： [2026 年7 月 2 日 12:12 UTC](https://www.nodeloc.com/t/topic/97224/4 "2026-07-02T12:12:30Z")

</div>

这么纯正的味道，发在隔壁早就被举报了，只能截图 :ac10:  
不过佬的这个工作流和我差不多呢，除了fast-context外其他都有了

---

<div class="post-metadata">

作者： ![zhi\_yang](https://www.nodeloc.com/user_avatar/www.nodeloc.com/zhi_yang/32/3671_2.png) [@zhi\_yang](https://www.nodeloc.com/u/zhi_yang)\
发布日期： [2026 年10 月 18 日 08:18 UTC](https://www.nodeloc.com/t/topic/97224/5 "2026-10-18T08:18:41Z")

</div>

仓库已经改名Pitaya了，README里的安装入口也换成npx pitayax了