# 把我们走过的路，留给下一位开发者

Bruce 博客创刊词：记录设计、产品、交互、技术与决策，让开发的过程成为开发者和他们的 Agent 都能继续使用的知识。

Bruce 团队 · 2026-11-05

https://flydogai.com/bruce/blog/why-we-build-in-public?lang=zh

<a id="everyone-who-builds"></a>

## 使用工具的人，也在成为开发者

我们做 Bruce，是希望更多人能把想法变成可以使用的作品。独立开发者、第一次尝试做产品的人，以及专业团队，走进来时可能有不同的经验。只要开始提出问题、验证想法、判断结果，他们就在参与开发。

AI 能替我们完成越来越多的代码，但一个产品为什么这样做、什么地方不顺手、哪次尝试没有奏效，仍然需要人的判断。这样的判断经常藏在会话、改动和提交里。项目向前走，它们却很容易散掉。

<a id="leave-a-trail"></a>

## 把做过的事，写成别人能继续走的路

这个栏目从这里开始：把 Bruce 的设计、产品、交互、工程探索和关键决策持续记录下来。我们希望文章能交代最初的问题、观察到的现象、尝试过的方向、最后的选择，以及还没有解决的部分。

这也是一种 Build in Public。公开的不必只有漂亮的结果。一次绕路、一个被推翻的猜测、一组放回真实使用环境才有意义的数据，都可能帮下一位开发者少走一段弯路。文章面对人，也面对帮助他们工作的 Agent：背景、约束和验证方法越清楚，知识越容易被接着使用。

<a id="from-work-to-writing"></a>

## 让开发过程，长出自己的开发日志

这不只是我们给自己的写作要求，也是 Bruce 希望帮助使用者做到的事。现有的内置写作提示可以围绕一个主题检索记忆、里程碑和相关记录，并结合可用的 Git 历史，整理博客、开发日志、进展回顾和 Build-in-Public 草稿。

找到素材与写出草稿之后，还需要开发者核对事实、补充解释、删去不适合公开的信息，再决定是否保存和发布。我们重视这个决定权。文章应该帮助你表达自己的工作，而不是让工具替你宣告没有核实的成果。

<a id="a-place-to-talk"></a>

## 让技术交流有一个具体的落点

我们不期待每篇文章都给出唯一答案。我们更希望它能把讨论落到具体情境里：你为什么选择另一条路？同样的交互在你的设备上有什么不同？你的 Agent 从这些记录里发现了什么遗漏？

文章会有稳定的地址、可引用的小节和便于保存的文字版本。你可以把它交给同伴或 Agent，也可以带着具体文章来信讨论。交流从已经发生的事情开始，比重新解释整段背景更容易。

<a id="explain-the-product"></a>

## 让一篇文章，支持更多次清楚的表达

官网上的一句特性介绍，背后应该有足够扎实的理由。博客为这些理由留下空间：交互为什么这样安排、一个技术选择换来了什么、轻量和完整体验之间怎样取舍。需要深入了解时，产品页面可以直接引用对应的文章。

同一份经过核对的内容，也能成为对外供稿、产品介绍和媒体交流的基础素材。我们会保留完整解释，再按场景整理摘要；让宣传与实际工作有共同的依据，也让后来回看项目时能理解当时的判断。

<a id="start-here"></a>

## 从创刊号开始，逐步补上来路

第一批内容包括这篇创刊词、小狗标志的设计记录、两次交互排查，以及关于 Agent 运行边界的工程说明。旧记录会标出发生时间与本次整理时间，历史实验中的数字也会保留它们的测试条件。

接下来，我们会逐步从项目沉淀的文档和提交记录中整理更多值得讲清楚的主题。设计、产品、交互、技术和决策，都有自己的故事。希望你在这里读到的经验，能成为你的下一次尝试，也希望我们能由此认识更多正在创造的人。