架构 · 创业 · 成长 专注大规模系统架构 · 互联网连续创业者 · 技术人 …

🧰 工具与工作流

真实在用的工具 · 脚本 · 模板 · 工作流

这个栏目规矩很简单：只写我真用过的工具，没用过的一律不写。而且不只给链接——每个工具我都会讲清楚在什么项目里用、踩过什么坑、什么场景劝你别用、备选是什么。工具导航站到处都是，缺的是用过之后的实话。

按使用场景分了几类（表格在下方）：架构运维、AI 工程、创业与独立开发、个人效率，最后是我自己的一套工作流。

挖的坑：5 个人的创业团队怎么把工具开支压下来、哪些「看起来香」的工具我付了费又退了款。

🛠️ 架构 & 运维工具

面向后端、架构师、运维，全部来自生产环境实战，而非网上搜集。

工具用途适用场景不适用场景踩坑提醒备选方案
Prometheus + Grafana指标监控与可视化告警，压测/容量观察的基础底座。服务数量多、需要多维聚合与告警规则的规模化后端。单机小项目、只有一两个服务且无人值守的场景，属于过度建设。长期不清理指标会吃满磁盘；高基数标签（如把 userId 当标签）会把 TSDB 拖垮。小规模可用 Node Exporter + Netdata，或云厂商托管监控。
Loki + Promtail日志聚合与检索，按 label 过滤、快速定位。多实例服务需要统一查日志、和指标/追踪对齐时间线时。对日志做复杂全文统计分析的场景（它不是搜索引擎）。label 设计错了，查询成本会爆炸；别把日志正文内容当 label。体量小时直接 tail/grep + systemd journal，或云日志服务。
OpenTelemetry统一的链路追踪与可观测性数据标准。微服务/多语言栈需要端到端 trace 时。还没搞清楚要解决什么观测问题的早期项目，先别上。采样率没配好，追踪数据量能把后端压垮；埋点成本常被低估。Jaeger/Zipkin 起步更轻，或云厂商 APM。
Nginx / OpenResty反向代理、限流、缓存、灰度路由、WAF 前置。统一入口、需要按需扩缩与细粒度流量控制。纯内部 RPC 场景没必要硬套一层网关。配置漂移难治理；限流规则写错会把正常用户误伤。Envoy / APISIX（需要更动态的网关能力时）。
Redis缓存、分布式锁、计数、消息队列等通用内存组件。热点读放大、需要跨实例共享状态时。把 Redis 当持久化数据库用、存不可丢失数据。大 key、热 key、缓存雪崩/穿透/击穿三件套，线上事故高发。数据量小且单机够用时，进程内缓存即可。
k6 / wrk压测与性能基线，验证容量与稳定性。上线前容量评估、大促/改版前回归。对生产环境直接打高压而不做隔离与观测（会打出事故）。压测结果要看 P95/P99 与毛刺，只看均值会误判。JMeter（偏业务脚本）、Locust（Python 友好）。
ClickHouse海量数据实时分析型数据库。日志分析、用户行为漏斗、时序聚合等大宽表场景。频繁单行更新/删除的 OLTP 场景，选型错误代价很大。分布键与分区设计不当，查询会退化成全表扫描。数据量小用 PostgreSQL + 物化视图即可。

💼 创业 & 独立开发工具

面向创业者、独立开发者、小团队，讲早期创业真实工作流。

工具用途适用场景不适用场景踩坑提醒备选方案
Notion / 飞书文档需求库、产品文档、会议纪要、团队知识库。早期团队需要一处沉淀想法与决策记录。复杂项目管理（甘特、依赖、迭代）不适合硬塞。文档不维护会变成信息坟场；权限与结构要先定好。Linear / 飞书 + 多维表格组合。
Linear轻量敏捷项目管理，迭代与 issue 跟踪。研发小团队希望流程轻、上手快的看板。非研发团队或需要强流程管控的大组织。工具再顺也替代不了「谁对结果负责」的共识。Jira（重流程）、Trello（更轻）。
Figma产品原型与界面设计协作。MVP 阶段快速出稿、与开发对齐交互。不做设计投入的纯后台项目，可先用线框图工具。设计稿与真实实现长期脱节，要有开发评审环节。Excalidraw / Whimsical（低保真）。
Stripe / 微信支付 / 支付宝收款、订阅、发票与对账。独立产品需要变现、订阅续费时。还没验证付费意愿就提前接支付（过度工程）。退款、争议、税务合规容易被忽略，早期就要想清楚。Lemon Squeezy / Paddle（托管式，省合规成本）。
GA / Plausible / Matomo访问分析、转化漏斗。上线后要判断渠道与留存时。还在做 idea 验证、没有流量的阶段。隐私合规（GDPR）与数据口径要在一开始定好。Plausible（轻量隐私友好）。
飞书 / Slack团队沟通与协作。跨职能小团队的日常同步。把聊天当项目唯一事实来源（信息会散落）。通知过载会摧毁专注；关键结论要回写到文档。Discord（社区/用户群场景）。

🧑‍🎓 职业成长 & 个人效率工具

面向程序员与技术管理者，讲职业发展与自我管理，重点是「人的约束」。

工具用途适用场景不适用场景踩坑提醒备选方案
Obsidian本地优先的 Markdown 知识库与卡片笔记。长期沉淀技术笔记、建立自己的知识树。多人实时协作编辑（它不擅长）。插件装太多、结构过度设计，会变成「记笔记的笔记」。Logseq / 飞书文档（协作场景）。
Anki间隔重复记忆，攻克需要背的内容。面试八股、体系化知识点的长期记忆。理解类、需要动手实践的内容（光背没用）。卡做太多、不做取舍，会变成负担。自制错题本 / 定期回顾清单。
Raycast / Alfred启动器与脚本化工作流，减少重复操作。高频切换工具、执行自建小脚本。Windows 用户需另找对应方案（PowerToys）。配置复杂度上去了，边际收益反而下降。macOS Spotlight + 简单 shell 脚本。
Typora / Markdown技术文档、方案、复盘的可移植写作格式。写方案、复盘、教程，追求版本可控与迁移。重度排版、需要复杂表格布局的场合。团队协作需统一模板与目录规范，否则各自为政。VS Code + Markdown 插件。

🤖 AI 工程工具

把大模型当后端组件时真实在用的工程工具：编排、推理、检索、可观测（2026 热点方向，均经真实部署验证）。

工具用途适用场景不适用场景踩坑提醒备选方案
LangGraph / OpenAI Agents SDKAgent 编排：有状态流程可控（LangGraph），或轻量接入模型生态（OpenAI Agents SDK）。生产 Agent 需要状态管理、多步工具调用与失败回退时。纯知识问答、单轮简单调用（直接调 API 即可）。编排复杂度被低估；长任务上下文与 token 成本线性上涨，先做上下文治理。Dify（低代码平台层，业务同学可搭）。
vLLM高性能开源 LLM 推理服务（PagedAttention，兼容 OpenAI API），私有化部署主流选择。数据不能出域、需要自托管推理且吞吐要求高时。小体量 / 无合规要求时（调托管 API 更划算，别自建）。显存与并发参数、KV Cache 配置影响吞吐明显；版本迭代快，升级前看 changelog。SGLang / TensorRT-LLM，或直接托管 API。
Qdrant / pgvectorRAG 的向量存储：pgvector 随 PostgreSQL 起步最省，Qdrant 适合独立高并发向量服务。小团队先 pgvector 验证检索质量，量级上来再迁专用向量库。还没做对「切分与召回」就上分布式向量集群（工具救不了设计问题）。Embedding 维度与索引参数（HNSW 的 M/ef）影响召回与内存，需压测调参。Milvus（大规模集群）、云托管向量库。
LangfuseLLM 可观测性：trace 每次调用的 prompt / 输出 / token 成本，支持评测与回放。生产 LLM 应用上线必备：定位幻觉、追成本、复盘失败案例。demo 阶段（先跑通再说）；埋点不全等于白做。prompt 可能含敏感数据，记录前要脱敏；自托管注意存储与备份。LangSmith（商业）、自建日志表。

📝 我的个人工作流

串联整套流程的方法论，看到的不只是工具，更是思考与做事方式。

工具用途适用场景不适用场景踩坑提醒备选方案
架构方案工作流调研 → 选型 → POC → 落地复盘 的固定节奏。每个重大技术决策都按这套流程走，可复现、可复盘。小改动、临时脚本不需要走完整流程。POC 不设「验证什么才算通过」，等于白做。轻量场景用 ADR（架构决策记录）留痕即可。
线上排障工作流发现 → 止血 → 定位 → 复盘 的标准化动作。线上故障统一按此链路执行，减少慌乱与误操作。无监控、无日志的小项目，先补可观测性。先止血再定位，别在故障中反复「看一眼」浪费黄金时间。结合 tools 栏目的《线上排障工具链》。
写作输出工作流选题 → 大纲 → 初稿 → 复盘 的内容生产闭环。博客、分享、个人品牌的持续输出。追求一次性完美的完美主义拖延。写作卡在「怕写不好」，先完成再完美。卡片盒笔记法（见 Obsidian）。

📝 工具专题文章