> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# 你的技术栈清单交付不了你的产品

上百位开发者收藏了我的技术栈清单——清单没写出来的，才是让一个 Windows 桌面工具在 48 小时内上线的管道工程。

_发布于 2026-10-12._
_更新于 2026-10-27._

> **技术栈清单越长，交付就越快吗？**
> 这取决于清单漏掉了什么。栈清单只列出工具名称，并不会装好它们的边界——已验证的 Webhook、租户范围限定、发布签名——而项目恰恰卡在这些接缝上。照抄的清单复制了工具，却没有集成。清单可以当作调研菜单，但通往可交付产品的路是经过测试的管道工程，无论你如何获得它。真正该问的是：你的每个晚上值多少钱。

## 收藏陷阱

前几天我在 X 上回了一个帖子，贴出自己实际在用的技术栈——我的“2026 独立开发技术栈”，一条回复装了十几款工具。[这条回复](https://x.com/noah_z_zhang/status/2114919719538978934)收了一百多个收藏，还顺带给这个网站引来一百多次点击。

后台数据就没那么好看了：大多数访客扫了一页就走。技术栈清单读起来像一份已经完工的计划，可抄下来的清单什么也交付不了——每个工具仍然要安装、要和相邻的工具接线、要测试，工具之间的接缝才是几周时间真正流失的地方。

这篇才是那些收藏真正想找的文章：不是我跑哪些工具，而是哪些管道工程早就在承重——以及它让我能在四十八小时内交付了什么。


## 项目真正死在哪里

大多数独立项目不是死在核心功能上。它们死在第一周，死在和点子毫无关系的基础设施上。动力的半衰期大约是四十八小时——每有一小时没花在产品本身，烧掉的都是单人开发最稀缺的资源。

那一周的过法惊人地一致：

- 第一天：monorepo 布局、ESLint、`tsconfig` 路径、数据库迁移。
- 第三天：还泡在支付服务商的文档里，琢磨怎么把 webhook 幂等做对。
- 第五天：想加个桌面端或移动端的配套应用——一条新的构建流水线、一个新的鉴权面、从零开始的自动更新。


## 一次端到端的 48 小时构建

上周我交付了 [SpinShare](https://spinshare.dev)，一个 Windows 原生桌面小工具：在资源管理器里拖起一个文件，按一下 Shift，光标底下直接弹出扇形轮盘菜单；松手就执行一次本地转换或操作。不弹窗、不上传，文件从头到尾不离开这台机器。

真正值得细看的是时间线：新建仓库、Rust 核心逻辑、在现有计费轨道上接好离线授权流程、提交微软商店——核心开发一共四十八小时，全程和 agent 结对写码，几乎没调过 prompt。Agent 没翻车，原因一点也不光鲜：最容易让它胡思乱想的架构边界，早就封死在我自己的 kit——supastack 里了。

下面算一笔账：那两天里不必现搭的管道工程。


## 安装与护栏

`pnpm setup` 把环境引导压成一条命令：预检、环境变量对齐、依赖安装、数据库迁移。不存在“先花一个晚上拼出一个可用环境”这回事——仓库要么通过自己的检查清单，要么直接点名缺了什么。

`.ai/` 镜像文档、`AGENTS.md` 和 `.agents/skills/` 是一份写给 agent 而不是人类的契约——每个包的职责边界、测试规则和红线（桌面端是单 webview 外壳，绝不分叉产品 UI）。[项目结构指南](https://supastack.dev/zh/docs/web/project-structure.md)展示了它读到的目录布局；[agent 工作流文章](https://supastack.dev/zh/blog/building-saas-with-a-coding-agent.md)讲了协作节奏。

写下来的边界，才是 agent 不会乱闯的边界。


## 计费与发布开箱即用

八个计费适配器站在同一套契约后面——Stripe、Creem、Polar、Dodo、Lemon Squeezy、Paddle、Whop 和 PayPal——`webhook_event` 账本让每一笔结算在变成许可证或邮件之前都先验签且幂等。我的工作从它的下游才开始：按订单数切换的 Early-Bird 档位，以及 Ed25519 签名的离线许可证密钥——桌面工具必须不联网也能激活。[计费模块指南](https://supastack.dev/zh/docs/modules/billing.md)记录了我扩展的那条流程。

发布侧同样没什么波澜，而这正是重点。Tauri 2 流水线——`desktop-release.yml`——构建签名过的安装包，并通过 minisign 生成 `latest.json`，为 Windows（NSIS 和 msi）、macOS（dmg）和 Linux（AppImage）提供 stable 与 beta 通道。我亲手做的唯一打包工作，是为微软商店打了一个 MSIX；其余内容[桌面端快速上手](https://supastack.dev/zh/docs/desktop/ship-in-5-minutes.md)都讲了。


## 用户真正能感知的那 10%

这是技术栈清单藏起来的算术：一个产品需要的东西里，大约九成是用户永远看不见的管道工程。看不见的管道正是地基应该扛的工作——也是唯一扛得动的部分。剩下的，才是产品。

因为我的地基已经在承重，四十八小时几乎全部投进了用户能感觉到的那一成——这些工作塞不进任何一条技术栈评论，也绝不会在一周都耗在 webhook 和签名上的时候发生：

- 用 Rust 写的 Windows OLE 拖拽钩子，轮盘只在真的拖着文件、按住 Shift 时才待命——打字时绝不触发。
- 多窗口托盘流程，让工具始终离一次按键之遥，任务栏上却不留窗口。
- 扇形轮盘的动效，调到菜单读起来是“瞬间出现”而不是“在播动画”为止。
- 三十多个本地格式转换器，每个都配了自己的单元测试。


## 务实的部分：定价与透明度

那个站得住脚的质疑是：“我有 Cursor——为什么还要为一份技术栈清单付钱？”在你的时间还没有标价之前，它都成立。两个晚上耗在 webhook 幂等上，代价就是你没交付的那个功能。

关于透明度：[文档](https://supastack.dev/zh/docs/web/ship-in-5-minutes.md)全部公开——目录结构、双 Web 引擎、跨平台同步、全部八个计费适配器、AI 路由。我宁愿怀疑者从头读到尾然后离开，也不想让人冲着标题下单；[用脚手架还是从零开始](https://supastack.dev/zh/blog/starter-kit-or-from-scratch.md)是把这笔账讲得最诚实的一篇。

两件务实的事：展示价格已包含 $100 首发优惠，结账支持支付宝。还有 50% 开发者返现——六十天内做出真实产品上线，公开分享构建故事（在 X、Reddit、YouTube 或类似平台拿到 5,000 次自然浏览或 50 个自然点赞），把链接发邮件给我：退你一半，许可证照样归你。规则在[上线返现条款](https://supastack.dev/terms#launch-cashback)。


## 关于技术栈清单的常见问题

每次这套 kit 出场，同样的质疑就会冒出来。它们值得正面回答。

- agent 不能帮我把这些全部搭出来吗？ — 它能搭出看似合理的东西，但没法一次跑通就验证接缝。幂等的 webhook 是测出来的，不是生成的——脚手架只会把同一份清单再递给你一次。
- 脚手架不会让产品变得千篇一律吗？ — 管道是共享的，产品不是。SpinShare 的拖拽钩子、托盘行为和转换器在 kit 里根本不存在——客户看到的那一成永远是你的。
- 如果我只需要一个 Web 应用呢？ — 反正买的都是这套 kit；移动端和桌面端是可以采用也可以无视的端面，不是硬性要求。SpinShare 能存在，正是因为桌面那个端面早就建好了。
- 一个桌面小工具真的能代表买家故事吗？ — 这是我手里最短的诚实例子：从空仓库到商店提交只用两天。同一套管道同样服务 SaaS——[上线检查清单](https://supastack.dev/zh/blog/saas-launch-checklist.md)是更长的版本。
- 为什么不直接把技术栈清单公布出来？ — 已经公布了：[技术栈指南](https://supastack.dev/zh/docs/web/tech-stack.md)写明了每个选择和理由。清单是菜单，不是计划——本文主张的是，值得买的是一个已经搭好的计划。