上周，我为了找一个三个月前写过的特定正则表达式，翻遍了六个不同的 Slack 频道、三个 GitHub 仓库，还有一个乱糟糟的桌面文件夹。我明明记得自己已经解决过这个一模一样的问题，但相关的上下文却散落在我工作流的各个角落。这种连自己的代码上下文都找不到的挫败感，正是驱使我尝试 Pieces for Developers 的原因。
如果你还没接触过它，Pieces 是一款本地运行的 AI 编程助手，它能在你的编辑器、浏览器和聊天记录之间充当桥梁。它可不只是个自动补全工具；它的设计初衷是帮你捕捉、整理并检索你真正关心的代码和上下文。下面我就来聊聊我是怎么把它装好并融入日常工作流的。
入门：安装与设置
我平时主要用 VS Code 写代码，所以我先装了 Pieces 的扩展。在 VS Code 扩展市场里搜索“Pieces for Developers”就能找到。
装完之后得重启 VS Code。重新打开后，侧边栏就多了一个 Pieces 的图标。点一下它会提示你登录。我直接用的 GitHub 账号登录，大概十秒钟就搞定了。
有一点让我挺惊喜的：Pieces 默认是在你的设备本地运行 AI 模型的。如果你在写私有代码，这可是个巨大的隐私加分项。不过，如果你想让云端模型（比如 OpenAI 的 GPT-4）来干点重活，也可以在设置里切换。我大部分任务都用本地模型，只有在遇到复杂的架构问题需要深度分析时，才会切回云端模型。
核心工作流：保存与整理代码
我从 Pieces 身上获得的最直接的价值就是代码片段管理。但它比普通的代码片段管理器强太多了，因为它会自动抓取上下文。
我现在的工作流是这样的：
第一步： 在编辑器里高亮选中一段代码。假设我刚写完一个自定义的 React hook。
第二步： 右键点击，选择“Save to Pieces”。
第三步： Pieces 侧边栏弹出来了，见证奇迹的时刻到了。它不只是保存了干巴巴的代码——它还会自动打上语言标签、推断出一段功能描述，并关联上源文件路径。
然后我会加上自己的标签（比如 react-hooks、auth、v2-project），再简单写两句备注，说明我为什么要存它。这个“为什么”非常关键。三个月后，我肯定想不起来当时存这个 hook 是专门用来处理 token 刷新逻辑的——所以我得把它写下来。
查找相关资料：我没想到自己会这么需要的功能
这个功能真的让我惊艳了。当时我正在做一个新的 API 集成，高亮选中了一个刚写好的 fetch 请求。出于好奇，我右键点了一下“Find Related Materials in Pieces”。
Pieces 扫描了我保存的代码片段、浏览记录和最近的工作流上下文，然后找出了三个相关项：
- 我上周存的一个代码片段，里面有类似的 API 错误处理模式
- 两天前我看过的 Stack Overflow 页面，讲的是如何处理速率限制
- 开会时同事分享的一段代码片段
我根本没去手动搜这些东西，它们就根据上下文自动出现了。这起码给我省了 20 分钟的翻找时间。
AI 副驾驶：带着完整上下文提问
Pieces 侧边栏里内置的 AI 副驾驶，是它真正区别于普通代码片段管理器的地方。因为 Pieces 一直在追踪我保存的代码、笔记，甚至是浏览器活动，所以这个副驾驶在回答问题时，能完全感知我的项目上下文。
比如，我问它：“在用户服务模块里，我是怎么处理身份验证的？”
副驾驶直接引用了我项目里保存的一个特定代码片段，给出了它所在的文件路径，并解释了我当时采用的方案。它甚至提醒我，自己还留了一条关于刷新过期 token 的 TODO 注释。
对比一下普通的 AI 聊天机器人，它们只会给我一堆关于 JWT 或 session cookie 的通用回答。而 Pieces 给我的答案，是深深扎根于我自己的代码库的。
自动捕捉工作流上下文
有一个功能，我是用了几天后才意识到它有多好用的，那就是长期记忆（Long-Term Memory）。Pieces 能记住笔记、浏览器活动、对话、文档、代码以及其他工作流上下文，让你轻松找回之前的工作状态。
之前我在研究一个棘手的数据库迁移问题。当时我打开了一堆标签页：PostgreSQL 文档、一个 Stack Overflow 帖子，还有一个内部 Wiki 页面。第二天，我问 Pieces：“昨天关于数据库迁移的问题，我都看了些什么？”
它直接把相关链接全找出来了，还总结了我当时关注的重点。我明明没有手动保存过这些东西——全靠浏览器扩展自动捕捉了我的浏览活动上下文（强烈建议把浏览器扩展也装上）。
我的使用经验与实用建议
用了 Pieces 两周后，这是我总结出的几条血泪经验：
疯狂打标签。 它的搜索功能确实不错，但加上标签能让检索瞬间完成。我现在给每个代码片段都会打上项目名标签、技术栈标签和用途标签。
写好“为什么”的备注。 没有上下文的代码就只是一堆文本。一定要加上备注，解释你为什么存这段代码，以及以后什么时候会再用到它。
装上浏览器扩展。 VS Code 扩展确实很棒，但只有装了浏览器扩展，它才能把你的资料查阅和写代码的过程串联起来，形成丰富的工作流记忆。
多用“Find Related Materials”。 在写新代码之前，先高亮你现有的代码跑一下这个功能。你经常会发现自己其实早就解决过类似的问题了。
定期回顾和清理。 就像任何整理系统一样，如果你从来不清理，Pieces 也会变得乱糟糟的。我现在每周五都会花五分钟删掉过时的代码片段。
实话实说的局限性
Pieces 也不是完美的。在老硬件上，本地 AI 模型可能会比较慢——我在 2019 款的 MacBook Pro 上跑复杂查询时，就感觉卡顿很明显。切到云端模型确实解决了速度问题，但那样你就得把代码上下文发送到设备之外了。
刚开始用的时候，也需要刻意培养习惯。头几天我老是忘记把代码片段存到 Pieces，因为以前习惯了复制粘贴到 Notion 的老流程。大概过了一周，存到 Pieces 才变成了我的肌肉记忆。
另外，“Find Related Materials”这个功能，得在你攒了一定量的代码片段库之后才能发挥最大作用。我刚用的头两天，它根本搜不出什么东西来。给它点时间，让它慢慢积累你的上下文。
总结
Pieces 填补了一个我以前都没完全意识到的空白：它把我开发工作流中那些散落的碎片（双关语，pieces 既是碎片也是产品名）串联成了一个可搜索、具备上下文感知能力的系统。它并没有取代我的编辑器或终端——它只是待在它们旁边，帮我记着那些事，这样我就不用自己费脑子记了。
如果你也经常发现自己正在重复解决早就搞定过的问题，或者经常要在聊天记录里翻找别人上周二分享的代码片段，那 Pieces 绝对值得你花点时间装一下。只要坚持用一个星期，你会发现：喂给它的上下文越多，它给你的回报就越丰厚。