企业官网建设流程全解析

“superpowers”这个词听起来很中二，但作为常年泡在终端和编辑器里的人，我确实在慢慢接近那种“超能力感”：别人还在翻文件夹找资料，我已经一条命令把结果丢到屏幕前；别人从零搭环境，我十几分钟就复现了整套工作流。这套被我命名为 superpowers 的方案，不是某个软件或框架，而是一套可以复制的个人工作系统——把终端配置、自动化脚本、AI 辅助和知识管理串在一起，专门解决“每天都在重复劳动，真正想做的事却没时间做”的困境。

这篇文章是对 superpowers 的完整拆解，包括我为什么这么设计、每一步怎么落地，以及踩过的坑和排查方法。如果你是一名开发者，或者日常需要处理大量资料和文档的知识工作者，这篇内容应该能帮你省下不少时间。我也尽量把方案写得通俗一些，哪怕你之前对终端脚本不熟，也能照着操作。

1. 项目整体设计与思路拆解

1.1 先把“超能力”拆成可训练的能力组合

superpowers 到底指什么？在我的定义里，它不是玄学天赋，而是在面对重复、复杂任务时，能更快完成，并把省下来的精力留给真正需要判断的事情。很多人在网上看到别人用一串命令完成一堆操作，第一反应是“他肯定用了什么神器”，但真相往往是：他把基础能力训练到位了，再用工具把所有基础能力组合起来，效果才显得“超能力”。

我用了一个很朴素的类比来理解这件事：魔术师变魔术看起来很神奇，但拆开看全是手法练习和道具设计。我们的“道具”是终端、自动化脚本、AI 工具，“手法”是操作习惯和肌肉记忆，“剧本”是每天真正面对的工作流。superpowers 的核心不是某个单点工具，而是把这几层组合成一个完整的闭环。

我最早想搭这套系统的原因也很简单：我发现每天做的好多事，其实并不需要“思考”，只是无意识重复。打开项目目录、找上次用过的命令、从一堆 git log 里回忆这周做了什么、把同样的内容复制到不同平台。这些事本身没有创造性，但很耗时间。与其靠毅力硬扛，不如把它们交给脚本和工具。superpowers 本质上是一套“精力再分配”方案，让我能把更多时间花在写代码、做设计和思考问题上。

1.2 三条底层原则：可复现、可替换、可测量

搭这套系统的过程中，我给自己立了三条原则，防止越折腾越复杂。

第一条是可复现。我所有的终端配置、脚本、模板都存在 Git 仓库里，换电脑后执行一条脚本就能恢复。配置不落地，等于没配置。网上很多人收藏了一大堆配置片段，但从来没整理成自己的仓库，等到换设备时又得重新找，时间成本非常高。我见过不少同事，换台电脑要花半天重新配置环境，而我的恢复时间大概半小时，差别就在配置是否版本化。

第二条是可替换。我不希望系统依赖某个闭源工具或某个人的维护。核心工具必须有替代方案。比如 fzf 如果不维护了，我可以用 picker、telescope 或 IDE 自带的模糊搜索顶上来。可替换的意义不是提倡反复换工具，而是防止某天某个工具突然不能用了，整个工作流停摆。

第三条是可测量。我只关心两件事：完成一个常规任务需要几步、花了多久；一周内有多少时间用在创造性工作。如果折腾工具导致复杂度增加，反而让我没时间做正事，那这个工具就应该删掉。很多效率方案失败，不是因为工具不好，而是因为维护成本超过了收益。superpowers 的每一层都要能回答“它帮我省了什么”这个问题。

1.3 哪些人适合照抄这份作业

这套方案最适合三类人。第一类是高频使用终端和 IDE 的开发者，他们每天要切换项目、查日志、跑命令，收益最直接。第二类是兼职内容创作的工程师，需要采集资料、整理文档、写周报和博客，自动化脚本和知识管理部分会很受用。第三类是做新人 onboarding 的技术负责人，因为这套东西对标准化启动环境很有帮助，新人拿来就能用，少走很多弯路。

如果你只是偶尔用电脑处理简单工作，不需要全套，挑两三招就够了。superpowers 的核心不是工具数量，而是减少杂念。我最开始也只加了一个模糊搜索，后来发现稳了，才慢慢扩展。这里也建议你读完先别急着全配，选一个痛点试运行两周，再决定要不要继续。

2. 核心能力拆解：工具选型与关键原理

2.1 终端：给双手装上“命令肌肉记忆”

我把终端视为 superpowers 的地基，因为所有自动化、搜索、远程操作都能在终端里串在一起。很多刚入门的朋友觉得终端是又黑又丑的窗口，但当你熟悉之后会发现，它是最高效的交互界面：没有按钮层级，所有功能都可以用命令直达。

我目前的主力 shell 是 zsh，因为它的补全、全局历史记录和插件生态比系统默认的 bash 更适合日常使用。我用的插件很少，主要是 zsh-autosuggestions 和 zsh-syntax-highlighting。前者会在你输入命令时用灰色文字提示历史命令，省去反复查记录的麻烦；后者会在你敲错命令或语法不对时立刻显示出不同颜色，相当于给命令输入加了一层实时校验。

我的 .zshrc 里并没有堆很多别名，只保留了高频操作。一个典型的片段是这样：

plugins=(git zsh-autosuggestions zsh-syntax-highlighting) alias gs="git status" alias ga="git add -A && git commit -m" alias gpo="git push origin HEAD"

为什么不追求插件数量？因为每个插件在终端启动时都会占用资源。我实测过，装了二十多个插件后，终端启动从 0.3 秒涨到 1.2 秒以上，体验反而变差。更关键的是，配置越多，记忆负担越大，最后自己都忘了哪些别名是什么意思。终端的价值是“顺手”，不是“炫酷”。

2.2 fzf + rg：把“找文件”变成条件反射

如果把终端环境比作基地，那 fzf 就是基地里最常用的传送门。fzf 是一个通用模糊查找器，可以接管命令历史搜索、文件搜索、git 分支切换等场景。它速度快、交互直观，输入几个字母就能过滤出候选结果。rg 则是 grep 的现代替代品，默认会忽略 .gitignore 里列出的文件，搜索代码库时非常快。

我常用的配置是让 fzf 默认用 rg 来生成文件列表：

export FZF_DEFAULT_COMMAND='rg --files --hidden --glob "!.git" --glob "!node_modules"'

这样在 Vim、VS Code 或纯命令行里呼出文件搜索时，都能快进快出，而且不会把 node_modules 这种大目录一块儿算进去。还有一个使用频率很高的命令，是查看之前执行过的命令。我把 fzf 接在历史记录后面：

alias fh="fc -l | fzf"

输入fh后直接模糊搜历史命令，回车就能复制，再也不用往上翻几十行找一条几天前的命令。有人可能觉得这不过是少点几次鼠标，但这种事一天发生几十次，积累下来的时间和精力很可观。我常开玩笑说，当你能“直接跳”到目标文件时，编辑器文件树反而成了摆设。

2.3 自动化脚本：让机器替你执行“固定剧本”

自动化脚本是 superpowers 里最朴素、但回报最稳定的一部分。机器的优势不是聪明，而是稳定执行固定步骤。人最大的问题不是不会，是重复做同样的事会烦会累，还会偶尔漏掉一个参数。脚本可以把这个过程固定住。

我平时会在~/scripts目录下放一些小脚本。最简单的例子，一键收集最近两天改动的文件和 commit 列表：

#!/usr/bin/env bash git log --since="2 days ago" --pretty="%H %s" --name-only > /tmp/changes.txt echo "改动文件已生成：/tmp/changes.txt"

这个脚本本身没有任何高深逻辑，但它把我每次都要敲的长命令封装成了一个固定动作。为什么这很重要？因为人每天会忘记某个参数，一旦忘记，就得去查文档；而脚本把参数固定下来，我只需要记住一个名字。所谓“高手动作快”，很多时候不是手速快，而是决策次数少。脚本就是减少决策次数的最直接方式。

2.4 AI 辅助：用“指挥”代替“手写重复代码”

AI 不是 superpowers，但它可以当“经验实习生”来用。我目前把 AI 用在三件事：生成重复性代码、解释陌生代码或日志、把口语表达改写成专业文档。这三件事的共同点是“结果确定性高”或“已有内容需要加工”，不太需要真正的原创性判断。

一个我常用的做法，是让 AI 基于 git log 写周报条目。我会给一个很明确的 prompt：

你现在是资深开发者。请根据以下 git log 生成周报条目，每条包含改动模块和影响，忽略格式化提交。输入：...

用这个模板的收益很大，因为周报过去要花不少时间回忆和措辞，现在 AI 能基于真实提交记录生成初稿，我再补充会议和沟通类信息就行。但我也要给 AI 的使用画一条红线：生成的代码必须经过语法检查、测试和 review。我踩过 AI 按旧 API 生成代码的坑，如果完全不看就合入，生产环境迟早出问题。AI 可以提速，但最终责任在你自己。

2.5 知识管理：把“我记得”升级为“我能搜到”

超能力不只在执行层，还在记忆层。如果你常常有“这事我之前处理过，但想不起来怎么处理的”这种体验，那问题不出在记性，而出在你没有一套可检索的知识库。

我的知识库现在只用纯 Markdown 文件加一个本地笔记软件，主要用的是 Obsidian，偶尔用 VS Code 直接打开文件夹。没有选择复杂数据库或在线服务的原因是：Markdown 是纯文本，零锁定，可以被任何工具处理，也可以放进 Git 管理，天然适合长期维护。

目录结构也很简单，只有三层：

inbox/ 临时收集的想法、截图、链接 active/ 正在做的项目、尚未闭环的调研 archive/ 已结束的项目、已解决的问题

我之前试过复杂的标签体系和双链图谱，后来发现整理连接的成本远高于检索收益。对一个以解决问题为目标的工程师来说，全文搜索比花哨的“第二大脑”更实用。归档这个动作本身也会给正反馈：看到 archive 里积累的问题记录，能明显感受到自己处理问题的半径在变大。

3. 实操过程与核心环节实现

3.1 快速搭建一个不拖后腿的终端环境

如果你从零开始，不想复制一大段看不懂的配置，可以按我下面的顺序操作。这套流程的目标是“最少步骤，最快可用”。

第一步，确认当前 shell。macOS 上 zsh 已经是默认，Linux 上可以装一下。Ubuntu 使用apt install zsh，然后执行chsh -s /usr/bin/zsh切换。第二步，安装 starship 作为命令行提示符。starship 的特点是配置简单、显示信息清楚，而且因为是用 Rust 写的，不会显著拖慢启动速度。安装后只需在.zshrc末尾加一行：

eval "$(starship init zsh)"

它能显示当前 git 分支、虚拟环境、命令执行耗时等信息。第三步，克隆 zsh-autosuggestions 和 zsh-syntax-highlighting 到本地插件目录，并在.zshrc里启用。不要一次塞太多插件，先跑通最基础的配置再慢慢加。

这里有个容易踩的坑：很多人从网上复制一段庞大的.zshrc，里面包含大量自己看不懂的配置。一旦出错，根本不知道从哪排查。我的建议是自己逐行添加，每加一行就重启终端验证一次，确保知道每一行在干什么。这样慢一点，但稳定。

3.2 把项目切换做成“一条命令”

过去我经常开一整天终端，就为了等某个项目进程不中断。后来我用 tmux 管理开发会话，并且和 fzf 做了结合，现在切换项目成了几秒钟的事。

tmux 是一个终端复用工具，它的核心价值在于让你在断开连接后，会话仍然在后台继续运行。我常用的一个 shell 函数是这样：

function ts() { local dir dir=$(find ~/projects -maxdepth 2 -type d | fzf --prompt="项目> ") tmux new-session -A -s "$(basename "$dir")" -c "$dir" }

原理很简单：先用 find 列出所有候选项目目录，再用 fzf 做模糊选择，最后用 tmux 打开或附着到对应的会话。这样我不需要记住项目名，也不需要一个个打开编辑器窗口，输入ts、打几个关键字、回车，就进入了完整上下文。

经验提醒：不要在 tmux 里再嵌套一层 tmux，快捷键会变得很混乱。我的习惯是一个 session 对应一个项目，这样切换上下文和关闭上下文都非常明确。

3.3 自动化周报：从半小时到五分钟

写周报可能是很多人最不想做又不得不做的任务。我最开始的周报基本靠回忆，后来想通了：git 已经替我记下了所有代码改动，为什么要靠脑子去还原？我只需要一个脚本把 commit 拉出来，再加上手工补充非代码信息。

脚本其实很简单：

#!/bin/bash author=$(git config user.name) since=$(date -v -7d +%Y-%m-%d 2>/dev/null || date -d '-7 days' +%Y-%m-%d) git log --author="$author" --since="$since" --pretty="* %s" > /tmp/commits.md echo "请查看 /tmp/commits.md 并手动补充会议、沟通类条目"

为什么保留“手动补充”这一步？因为 git log 只包含代码变更，不包含“和技术负责人对齐需求”“和产品确认优先级”这类关键的非编码贡献。完全自动化生成的周报容易失真，加一点人工输入反而更可靠。我会在脚本生成之后，把 /tmp/commits.md 里的内容复制出来，再丢给 AI 润色成更面向读者的表达。

这个流程走下来，原本半小时的周报大概能压缩到五分钟以内。节省下来的时间不多，但起码我不再讨厌写周报了。

3.4 AI 辅助编码的落地小案例

讲一个真实的批量处理案例。我之前有一个 Markdown 文件夹需要做结构整理，要求把每个文件中“第一个以 # 开头的标题行”剪切到文件第一行，如果文件第一行本来就是标题，就跳过。这种批量操作如果手动一个个改，几十个文件得弄到崩溃。

我的处理方式是用 AI 生成一次性脚本。我给的描述是：

写一个 Python 脚本，递归处理当前目录下所有 .md 文件；找到第一个以 # 开头的标题行，把它剪切到文件第一行；如果原文件第一行本来就是标题，则跳过；处理前先备份为 .bak。

生成后我检查了两件事：备份逻辑是否真的生效，以及会不会误伤代码块里的# 注释。跑了一次小目录验证，确认没问题后再全量执行。这个过程的体验是，我像一个提需求的人，而不是一个敲重复代码的人。但再强调一次，AI 生成的代码也有可能出错，尤其当语料里的规则和你实际文件不一致时。测试不完，代码就不能说稳。

3.5 知识库实操：建立自己的“第二大脑”

知识库不需要花哨，关键是形成习惯。我一般看到有价值的文章、错误排查记录、灵感片段，先丢进inbox，每周固定一个时间整理到active或archive。这个流程看起来简单，却能保证知识库不会因为维护成本过高而荒废。

我常用的模板是这样的：

# 2025-xx-xx 问题记录 ## 现象 ## 原因 ## 解决步骤 ## 以后如何避免

模板的作用是降低记录成本。如果每次都要想“怎么写”，大概率不会坚持。用固定模板，只要填空就行。等到一个项目结束，完整的复盘已经在 archive 里沉淀好了，写博客或者给团队分享时可以直接复用，不需要临时翻聊天记录和邮件。

实际用下来，我能明显感到“搜得到”比“记得住”更可靠。记忆会受状态影响，但全文搜索只要文件在，结果随时都在。

4. 常见问题与排查技巧实录

4.1 终端启动越来越慢，明明配置也没加多少

这是最典型的效率工具问题：最初搭环境很快，用一段时间后发现每次打开终端都要等好久。常见原因有三个——插件数量失控、nvm 或 pyenv 每次启动都执行初始化、PATH 变量重复追加。

排查方法可以分两步。先执行time zsh -i -c exit，看一下总耗时。如果超过一秒，说明配置里有明显开销。然后挨个注释掉.zshrc里的source行，用二分法定位是哪个插件或初始化语句拖慢了启动。

我最后的解决方案是把 nvm 改成懒加载：只有真正执行 node 命令时才加载，平时打开终端不做任何初始化。高频命令我已经熟到不用补全，所以插件越少反而越顺。终端的价值是快速响应，不是启动后做一堆检查。

4.2 fzf 搜索不到我想找的文件

有朋友问过我，fzf 搜不到项目里某个文件，是不是配置错了。多数情况是FZF_DEFAULT_COMMAND没有生效，或者 rg 默认不搜索隐藏文件。排查思路很直接：先跑which rg确认 rg 已安装，再单独跑rg --files --hidden | head -20看输出是否符合预期。

配置里一定要加上--glob "!.git"，否则会把 .git 目录里的对象也搜进来，既慢又乱。另一个容易被忽视的问题是某些目录文件特别多，如果忘记写 .gitignore，rg 默认会忽略它，但如果你改成了--no-ignore，搜索会突然变慢。fzf 的性能很多时候取决于 rg 的规则，先别急着怀疑 fzf，先查数据结构。

4.3 自动化脚本到第二天就“失灵”

我很早就遇到过脚本在终端里跑得好好的，放进计划任务后却完全失效。排查下来，最常见的原因是路径不一致。你终端里的 PATH 和计划任务里的 PATH 不一样，导致脚本里依赖的 git、python 等命令找不到。

解决方案是在脚本开头显式设置环境变量：

#!/bin/bash export PATH="/usr/local/bin:/usr/bin:/bin:$PATH"

另一个坑是数据格式变化。比如某次 git 版本升级后，log 输出格式变了，我的周报脚本生成的 Markdown 里多出一些空行。排查手法是手动把脚本里的命令拆开，一条一条跑，看哪一步输出不符合预期。自动化脚本不是写完就能一劳永逸，要把它当成一套需要定期维护的小系统。

4.4 AI 改代码把好好的项目改坏了

AI 能提高效率，也会放大错误。我遇到过 AI 做全局变量名替换时，把另一个语言关键字也替换了，所有用到相关语法的地方全部编译失败。从那以后，我给自己定了三条铁律。

第一，批量修改之前先建分支或打 tag。第二，每次只接受一个 diff，不一次性接受所有建议。第三，执行前先git diff查看变化，确认每一处都符合预期。这不是不信任 AI，而是对生产环境负责。把 AI 当实习生，你不会让实习生直接部署，对吧？AI 生成的内容也一样，必须有人工 review 兜底。

4.5 工具囤积癖：买了一堆“超能力”，人却更累了

最后这条可能不是技术问题，而是心态问题。有些人包括我自己，有一阵子天天逛新工具、折腾配置，觉得用上某个工具就能效率起飞。实际结果是，工具越来越多，配置越来越重，真正写代码的时间反而少了。

我后来给自己定了一个“效率工具预算”：每周最多花三十分钟折腾配置，其余时间全部投入业务。每月末清理一次，冷静地问自己“这个配置最近两周用过吗”，没有就删掉。这个习惯帮我保持了系统的精简，也让我更接近 superpowers 的本质：不是掌控所有工具，而是被最少的好工具支持。

5. 影响范围：从一个终端到一整个工作方式

5.1 量化对比：旧方式和新方式实测

我把这套方案用在自己身上两三个月后，记录了不同场景的耗时变化。先放一张对比表，数据来自个人经验，仅供参考。

我不建议你把这几项当作绝对承诺。同样的工具在不同人手里效果差异很大，和你的使用频率、项目复杂度都有关系。但如果方向对，收益一定会在某个维度上体现出来。

5.2 从个人效率到团队标准化

当你适应了这套系统，下一步可以考虑把低风险的配置共享给团队。我建了一个叫team-superpowers的仓库，里面放.zshrc、starship.toml、weekly_report.sh和一份 README，说清每个文件是做什么用的、有哪些副作用。新人入职后不需要从零摸索，直接复用，启动成本大幅降低。

不过要注意边界：不是所有个性化插件和别名都适合放进团队仓库。比如我习惯的私有别名，只对自己有意义，塞进团队仓库只会造成混乱。共享版本要保守，只放收益明确、不含个人偏好的配置。然后每月或每季度做一次效率分享，让团队里愿意折腾的人一起维护这套资产。

5.3 后续还能怎么扩展

superpowers 现在对我来说已经不是一个具体工具，而是一个持续迭代的习惯。我最近的计划是把常用脚本整理成一个小型的命令行工具包，加上帮助信息，方便自己和新同事快速上手。AI 部分也可以往更深处走：自动给 PR 写描述、自动分析近期故障的关联日志、基于本地知识库回答问题。

再远一点，还可以把本地脚本和低代码自动化平台结合，让日报自动推送到团队协作工具，让环境初始化变成一个可视化流程。你会发现，当技术栈和业务变化后，原本的工具可能被替换，但“把重复动作自动化、把隐性知识显性化”这个思路一直有效。这才是 superpowers 真正能持续发挥价值的地方。

文章到这里，核心内容已经全部讲完了。最后分享一点我的真实体会：这套 superpowers 说穿了不复杂，它的价值来源于一个习惯——把每个动作拆成“需要思考”和“不需要思考”两类，然后给后者一点自动化。如果你看完想试试，我的建议很朴素：不要一口气搭完所有内容。先选一个你最痛的点，比如“找文件很慢”或者“写周报很烦”，用一条命令或者一个小脚本解决它，跑两个星期再回头判断。我自己最初只是想少敲几个字，结果一路滚成了整套体系。你的 superpowers 未必和我一样，但你可以从一个很小的脚本开始。