企业官网建设流程全解析

1. 从"pstack-claude"这个名字说起：它到底想解决什么问题

第一次看到pstack-claude这个项目名，很多人会愣一下——pstack 是什么？和 Claude 又是什么关系？我最初的反应也是这样。拆开来看，pstack通常指代"process stack"或者"personal stack"，在开发者圈子里，它更多被用来指代一套个人化的工具链组合；而claude则是当前被大量开发者用于辅助编码、文档撰写、代码审查的 AI 助手。把这两个词拼在一起，pstack-claude的核心意图就很清晰了：把 Claude 这套 AI 能力，整合进个人开发工具链（pstack）里，形成一套可复用、可迁移、可自动化的本地工作流。

这个项目标题背后，其实藏着一个非常现实的痛点。现在用 Claude 辅助开发的人越来越多，但大多数人的用法还停留在"打开网页、复制代码、粘贴提问、再复制回来"这种原始阶段。这种用法有几个致命问题：上下文容易丢、历史记录散落在各个对话窗口、无法和本地项目文件联动、每次都要手动搬运代码。而pstack-claude想做的，就是把这套流程"栈化"——让 Claude 成为你本地工具链里的一个标准组件，而不是一个需要你反复切换窗口的外部服务。

从热搜词也能看出这个方向的真实需求有多旺盛：claude code 安装、vscode 配置 claude code、claude code 从零上手、claude code 接入 deepseek、windows wsl 安装 claude code……这些词背后是大量开发者在真实环境里踩坑、摸索、寻找可落地方案的过程。有人卡在安装环节，有人卡在环境依赖，有人卡在模型接入，还有人卡在权限和路径问题上。pstack-claude这个项目，本质上就是对这些碎片化问题的一次系统性回应。

这篇文章适合谁看？如果你是刚接触 Claude 辅助开发的新手，想从零搭一套顺手的本地工作流，那这篇内容能帮你少走很多弯路；如果你已经用过一段时间，但总觉得"用得不顺手"，那这里关于工具链整合、上下文管理、模型切换的思路，可能会给你一些新的启发；如果你是在团队里负责工具选型和流程规范的人，那文中关于环境隔离、配置管理、故障排查的部分，可以直接拿去参考。

需要提前说明的是，pstack-claude目前公开的原始描述非常简短，没有详细的官方文档。所以下面涉及的具体操作步骤、配置参数、目录结构，都是基于我本人在类似工具链整合项目中的实际经验，结合当前开发者社区里常见的实践方案整理出来的。我会明确标注哪些是通用做法、哪些是我个人的取舍，你可以根据自己的环境灵活调整。

2. 为什么要把 Claude 塞进个人工具链，而不是继续用网页版

2.1 网页版 Claude 的三个隐性成本

很多人觉得网页版够用了，何必折腾本地整合。我一开始也这么想，直到连续做了几个中型项目之后，才发现网页版的隐性成本高得吓人。

第一个成本是上下文搬运成本。你在本地 IDE 里改代码，遇到问题要切到浏览器，把相关文件内容复制过去，等 Claude 回复，再把建议复制回来。一个下午来回切几十次，每次都要重新组织上下文，光是"选中哪些代码、怎么描述问题"就消耗了大量注意力。更麻烦的是，Claude 在网页端看不到你的项目结构，它不知道你的utils目录里已经有一个现成的工具函数，于是给你生成了一段重复代码，你还得手动去重。

第二个成本是历史记录碎片化。网页版的对话是按会话隔离的，你今天问了一个关于数据库连接池的问题，明天再问一个相关的，Claude 不会自动关联。你得手动把之前的结论贴过来，或者重新解释一遍背景。项目做到后期，你会发现自己的知识散落在十几个对话窗口里，想找某个具体结论得翻半天。

第三个成本是无法与本地文件系统联动。这是最要命的。Claude 网页版不能直接读你的文件、不能直接写你的文件、不能跑你的测试命令。它只能"说"，不能"做"。而真正的开发工作，大量时间花在"读文件、改文件、跑命令、看结果"这个循环上。如果 AI 只能参与"说"的部分，那它离真正提效还有很远。

2.2 pstack 思路的核心：把 AI 变成可编排的组件

pstack-claude这个项目名里的 "pstack"，我理解它的精髓在于可编排。什么叫可编排？就是 Claude 不再是一个孤立的聊天窗口，而是你工具链里的一个节点，可以被脚本调用、可以被其他工具触发、可以读写本地文件、可以和其他命令串联。

举个具体例子。传统用法是：你发现一个测试挂了，复制报错信息，打开 Claude 网页，粘贴，等回复，复制修复建议，回到 IDE 改代码，再跑测试。而在 pstack 思路下，你可以写一个脚本：自动读取失败的测试输出，把相关源文件一起打包发给 Claude，拿到修复建议后自动生成一个 patch 文件，你只需要 review 一下就能应用。整个过程你只做了"触发"和"review"两件事，中间的搬运全部自动化。

这种思路带来的效率提升不是线性的，而是质变的。因为你一旦把 Claude 变成可编排的组件，就可以把它嵌入到代码审查、文档生成、提交信息撰写、依赖升级检查等各个环节。它从一个"你去找它"的工具，变成了一个"它在你需要时出现"的基础设施。

2.3 哪些场景最适合先做整合

不是所有场景都值得一开始就做深度整合。根据我的经验，下面这几类场景投入产出比最高，建议优先做：

我个人的建议是，从"代码审查"和"提交信息撰写"这两个场景切入。原因很简单：这两个场景的输入输出都很明确，不需要复杂的上下文管理，容易跑通，跑通之后能立刻感受到效率提升，给你继续深入的动力。等这两个场景稳定了，再往测试生成、文档同步这些更复杂的场景扩展。

3. 环境准备：绕开那些让人抓狂的安装坑

3.1 操作系统与运行环境的选型逻辑

pstack-claude这类工具链整合项目，对环境的要求比普通脚本高一些，因为它要同时处理文件读写、进程调用、网络请求这几类操作。我实测下来，不同操作系统的体验差异很大，这里直接给结论：

Linux（推荐 Ubuntu 22.04 及以上）是最省心的选择。文件权限模型清晰，包管理成熟，脚本调用顺畅，绝大多数工具链整合项目都是在 Linux 上开发和测试的。如果你有一台常开的 Linux 机器，或者愿意在本地装一个 Linux 环境，优先选它。

macOS体验也不错，尤其是 Apple Silicon 芯片的机器，性能足够，Unix 环境完整。唯一需要注意的是某些命令行工具的版本可能和 Linux 上有差异，配置时留意一下。

Windows是最容易踩坑的。不是说不能用，而是很多工具链整合项目默认假设你在 Unix 环境里，路径分隔符、权限模型、进程管理都不一样。如果你坚持在 Windows 上用，强烈建议通过 WSL2 来跑，把工具链装在 WSL 的 Linux 发行版里，Windows 只作为终端和编辑器。这样能避开大量兼容性问题。

提示：如果你在 Windows 上遇到"virtual machine platform not available"这类提示，通常是因为 WSL2 依赖的虚拟化功能没有在系统设置里开启。这个属于系统层面的配置，和工具本身无关，按系统提示开启对应功能即可。

3.2 依赖清单与版本约束

在动手之前，先把依赖理清楚。下面这份清单是我在实际项目中验证过的，版本号给的是"最低可用版本"，实际用更新的稳定版通常也没问题：

# 基础运行时（以 Ubuntu 为例） nodejs >= 18.0.0 # 很多 AI 工具链的 CLI 基于 Node npm >= 9.0.0 # 包管理 python3 >= 3.10 # 部分脚本和工具依赖 git >= 2.30 # 版本控制，工具链整合几乎必用 curl >= 7.68 # 网络请求调试 jq >= 1.6 # JSON 处理，解析 API 返回时非常有用

安装命令（Ubuntu/Debian 系）：

sudo apt update sudo apt install -y nodejs npm python3 python3-pip git curl jq

这里重点说一下jq。很多人装依赖时会忽略它，觉得可有可无。但在工具链整合项目里，jq几乎是刚需。因为 Claude 的返回、配置文件的读写、状态的管理，大量涉及 JSON 格式。没有jq，你只能用grep和sed去硬抠字符串，又慢又容易出错。装上jq之后，一行命令就能提取、过滤、重组 JSON 数据，效率完全不是一个量级。

3.3 目录结构设计：别把东西乱堆在一起

工具链整合项目最容易犯的错误，就是把所有文件堆在一个目录里。跑是能跑，但过两周你自己都找不到东西在哪。我建议从一开始就按下面的结构组织：

pstack-claude/ ├── config/ # 配置文件 │ ├── default.yaml # 默认配置 │ └── local.yaml # 本地覆盖配置（不提交到 git） ├── scripts/ # 可执行脚本 │ ├── review.sh # 代码审查入口 │ ├── commit-msg.sh # 提交信息生成 │ └── test-gen.sh # 测试生成 ├── prompts/ # 提示词模板 │ ├── review.md │ └── commit.md ├── logs/ # 运行日志（不提交到 git） ├── cache/ # 缓存（不提交到 git） └── README.md

这个结构的关键在于配置和代码分离、模板和逻辑分离。config/local.yaml放你的个人配置（比如 API 端点、模型偏好），不提交到版本库；prompts/目录放提示词模板，改提示词不用动脚本逻辑；logs/和cache/单独隔离，方便清理和排查问题。

注意：local.yaml和logs/、cache/一定要加到.gitignore里。我见过有人把带密钥的配置文件提交到公开仓库，后果很严重。养成习惯，涉及个人配置和运行产物的目录，第一时间排除。

4. 核心整合逻辑：Claude 怎么和本地工具链对话

4.1 三种整合模式的取舍

把 Claude 整合进本地工具链，本质上要解决"本地工具怎么和 Claude 通信"这个问题。目前主流有三种模式，各有适用场景：

模式一：CLI 直调。通过命令行工具直接调用 Claude 的能力，输入输出都在终端里完成。优点是轻量、快、容易脚本化；缺点是交互性弱，不适合需要多轮对话的复杂任务。适合代码审查、提交信息生成这类"一问一答"的场景。

模式二：编辑器插件。在 VS Code 等编辑器里装插件，Claude 直接读取当前打开的文件和项目结构。优点是上下文自动获取，不用手动搬运；缺点是绑定特定编辑器，换环境要重新配置。适合日常编码辅助。

模式三：自建服务层。自己写一个中间服务，统一管理 Claude 的调用、缓存、日志、限流。优点是可控性最强，可以对接多个模型、做复杂的编排；缺点是要维护的代码多，前期投入大。适合团队使用或需要深度定制的场景。

我个人的建议是从模式一开始，跑通之后再考虑要不要升级。很多人一上来就想搞模式三，结果光服务层就写了一周，核心功能还没跑起来。先用 CLI 直调把"代码审查"这个场景跑通，感受到价值之后，再决定要不要投入更多。

4.2 配置文件的字段设计

不管用哪种模式，配置文件的设计都很关键。下面这份配置结构是我在实际项目中反复调整后定下来的，字段不多，但每个都有明确用途：

# config/default.yaml model: name: "claude-sonnet" # 模型标识 max_tokens: 4096 # 单次返回上限 temperature: 0.2 # 代码场景建议低温度 api: endpoint: "" # 接口地址，本地配置覆盖 timeout: 60 # 超时秒数 retry: 2 # 失败重试次数 context: max_files: 10 # 单次最多附带文件数 max_file_size: 51200 # 单文件最大字节数 ignore_patterns: # 忽略的文件模式 - "*.lock" - "node_modules/**" - "dist/**" output: format: "markdown" # 输出格式 save_to: "logs/" # 结果保存目录

这里有几个字段值得展开说。temperature设成 0.2 而不是默认值，是因为代码相关任务需要稳定、可复现的输出，温度太高会导致同样的输入每次给出不同的建议，不利于建立信任。max_files和max_file_size是防止上下文爆炸的保险丝，不加限制的话，一次审查可能把整个项目塞进去，既慢又贵。ignore_patterns一定要配，node_modules、dist、*.lock这些文件对理解代码逻辑没有帮助，只会稀释有效上下文。

4.3 提示词模板的工程化写法

提示词写得好不好，直接决定整合效果。我见过太多人把提示词写成一段随意的自然语言，结果输出质量忽高忽低。正确的做法是把提示词当代码来写：结构化、有明确约束、可版本管理。

以代码审查为例，我的模板大致长这样：

# prompts/review.md 你是一名资深代码审查者。请审查以下代码变更，按下面的格式输出。 ## 审查范围 {{DIFF_CONTENT}} ## 相关上下文 {{CONTEXT_FILES}} ## 输出要求 1. 按严重程度分级：BLOCKER / MAJOR / MINOR / NIT 2. 每条意见必须包含：文件路径、行号、问题描述、修改建议 3. 只报告真实问题，不要为了凑数而提无关紧要的建议 4. 如果代码没有问题，直接输出 "LGTM" ## 输出格式 | 级别 | 文件 | 行号 | 问题 | 建议 | |------|------|------|------|------|

这个模板的关键在于输出格式的强约束。你告诉 Claude 用表格输出，它就会用表格；你告诉它分级，它就会分级。格式统一之后，后续用脚本解析、汇总、生成报告就非常方便。如果输出是自由文本，你还得再写一层解析逻辑，得不偿失。

提示：提示词模板建议用版本控制管理起来。每次调整之后，记录一下改了什么、为什么改、效果如何。积累一段时间，你会有一套针对自己项目特点的、高度优化的提示词库，这是别人抄不走的资产。

5. 跑通第一个场景：代码审查的完整链路

5.1 从 git diff 到审查报告的自动化流程

代码审查是最适合作为第一个跑通场景的，因为它的输入输出边界非常清晰。整个链路可以拆成五步：

1. 获取变更：用git diff拿到本次改动的 diff 内容
2. 收集上下文：根据 diff 涉及的文件，读取相关源文件作为补充上下文
3. 组装请求：把 diff 和上下文填入提示词模板
4. 调用 Claude：发送请求，拿到审查结果
5. 格式化输出：把结果整理成可读的报告，保存到日志目录

下面是一个简化版的实现脚本：

#!/bin/bash # scripts/review.sh set -e # 1. 获取 diff DIFF=$(git diff --cached) if [ -z "$DIFF" ]; then echo "没有暂存的变更，先 git add 再运行" exit 0 fi # 2. 提取涉及的文件 FILES=$(echo "$DIFF" | grep "^+++" | sed 's/^+++ b\///' | grep -v '/dev/null') # 3. 收集上下文（限制大小） CONTEXT="" for f in $FILES; do if [ -f "$f" ] && [ $(stat -c%s "$f") -lt 51200 ]; then CONTEXT="$CONTEXT\n\n### $f\n\`\`\`\n$(cat "$f")\n\`\`\`" fi done # 4. 组装提示词 PROMPT=$(cat prompts/review.md | \ sed "s|{{DIFF_CONTENT}}|$DIFF|" | \ sed "s|{{CONTEXT_FILES}}|$CONTEXT|") # 5. 调用并保存 echo "$PROMPT" | your-claude-cli > "logs/review-$(date +%s).md" echo "审查完成，结果已保存到 logs/"

这个脚本里，your-claude-cli是占位符，代表你实际使用的调用方式。不同环境下的调用命令不一样，但整体流程是通用的。

5.2 上下文收集的取舍：不是越多越好

新手最容易犯的错误，是觉得"上下文给得越多，Claude 理解得越准"。实际上恰恰相反。上下文过多会带来三个问题：一是超出模型的上下文窗口，导致关键信息被截断；二是无关信息稀释了有效信息，模型注意力被分散；三是请求变慢、成本变高。

我的经验法则是：只给和变更直接相关的文件，以及这些文件直接依赖的接口定义。比如你改了一个函数，那就给这个函数所在的文件，加上它调用的工具函数的签名（不需要完整实现）。不要给整个项目，不要给测试文件（除非变更涉及测试），不要给配置文件（除非变更涉及配置）。

具体到脚本层面，可以用max_files和max_file_size两个参数做硬限制。超过限制的文件，要么跳过，要么只取前 N 行。宁可少给，也不要给一堆噪音。

5.3 审查结果的二次处理

Claude 返回的审查报告，不要直接扔给团队看。原始输出往往包含一些"正确的废话"，比如"建议添加注释""注意边界情况"这种没有具体指向的意见。直接展示会降低信任度。

我的做法是加一层过滤：只保留包含具体文件路径和行号的意见。因为一条意见如果能定位到具体位置，说明它是基于真实代码得出的；如果定位不到，大概率是泛泛而谈。用jq或简单的文本处理就能实现这个过滤。

过滤之后，再按严重程度排序，BLOCKER 和 MAJOR 放前面，MINOR 和 NIT 折叠起来。这样团队 review 的时候，注意力会集中在真正重要的问题上。

6. 模型接入与切换：不被单一服务绑死

6.1 为什么要做模型抽象层

热搜词里有个很值得注意的现象：claude code 接入 deepseek、vscode 安装 claude code 调用 deepseek、claude code harness 可以不登录用其他模型吗。这说明大量用户有多模型切换的需求。原因很现实：不同模型在不同任务上表现不一样，有的擅长代码，有的擅长文档，有的在特定语言上更强；而且单一服务的可用性和成本也会波动，多一个备选就多一份从容。

所以pstack-claude在设计上，应该从一开始就把"模型"抽象出来，而不是把某个具体模型的调用逻辑硬编码到脚本里。抽象层的核心是一个统一的接口：输入提示词和上下文，输出文本结果。至于底层用的是哪个模型、哪个端点，由配置决定。

6.2 统一接口的字段约定

抽象层的接口设计，关键是字段要统一。下面是我用的一套约定：

不管底层对接的是哪个服务，上层脚本只认这套字段。切换模型时，只需要改配置里的model和endpoint，脚本逻辑完全不用动。这就是抽象层的价值。

6.3 切换时的注意事项

切换模型不是改个名字就完事，有几个坑要提前知道。

提示词需要适配。不同模型对提示词的敏感度不一样。有的模型对格式约束响应很好，你让它输出表格它就输出表格；有的模型更"自由发挥"，需要更强的约束词。切换之后，先拿几个典型任务测一下，看看输出格式是否还符合预期，不符合就调整提示词。

上下文窗口不一样。不同模型能接受的上下文长度差异很大。切换到一个窗口更小的模型时，如果还按原来的max_files和max_file_size配置，可能会超限报错。建议在配置里为每个模型单独设置上下文限制。

输出风格有差异。同样的提示词，不同模型给出的建议详略程度、语气、侧重点都不同。如果你的下游脚本对输出格式有强依赖（比如要解析表格），切换后一定要重新验证解析逻辑。

提示：建议在配置里维护一个"模型档案"，记录每个模型的上下文窗口、擅长任务、提示词适配要点。切换时先查档案，能省很多试错时间。

7. 那些文档里不会写的踩坑记录

7.1 权限问题：最常见的"莫名其妙失败"

工具链整合项目里，最高频的报错就是权限问题。典型表现是：脚本手动跑没问题，放到定时任务里就失败；或者今天能跑，明天突然报"no write permission"。

根本原因通常是运行身份不一致。你手动跑的时候用的是自己的账号，有完整的读写权限；定时任务可能用的是系统账号，权限受限。解决办法有两个：一是确保脚本运行身份对相关目录有读写权限；二是在脚本里显式检查权限，提前给出友好提示，而不是等到写文件时才报错。

# 在脚本开头加权限检查 if [ ! -w "logs/" ]; then echo "错误：logs/ 目录不可写，请检查权限" exit 1 fi

这个检查看起来简单，但能帮你省下大量排查时间。报错信息越早、越明确，定位问题就越快。

7.2 路径问题：相对路径的陷阱

第二个高频坑是路径。脚本里用相对路径，手动在项目根目录跑没问题，一旦从别的目录调用就找不到文件。这个问题的根源是工作目录不确定。

我的做法是：脚本开头先确定自己的位置，然后所有路径都基于这个位置来拼。

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" PROJECT_ROOT="$(dirname "$SCRIPT_DIR")" CONFIG_FILE="$PROJECT_ROOT/config/default.yaml"

这样不管从哪里调用脚本，路径都是对的。多写两行，省掉无数"文件找不到"的困惑。

7.3 网络超时：重试策略的设计

调用外部服务，网络超时是常态。不加处理的话，一次超时整个流程就断了。合理的做法是加指数退避重试：第一次失败等 1 秒，第二次等 2 秒，第三次等 4 秒，最多重试 3 次。

retry_call() { local max_retry=3 local delay=1 local attempt=1 while [ $attempt -le $max_retry ]; do if "$@"; then return 0 fi echo "第 $attempt 次失败，${delay}s 后重试..." sleep $delay delay=$((delay * 2)) attempt=$((attempt + 1)) done return 1 }

但要注意，不是所有失败都值得重试。网络超时、服务暂时不可用，重试有意义；参数错误、认证失败，重试多少次都一样。所以重试逻辑里要区分错误类型，只对可恢复的错误重试。

7.4 缓存设计：避免重复调用

同一个文件、同一段代码，反复调用 Claude 是浪费。加一层缓存，能显著降低成本、提升响应速度。

缓存的键怎么设计？我的做法是对输入内容做哈希：把提示词和上下文拼起来，算一个 SHA256，作为缓存文件名。下次同样的输入，直接读缓存，不调服务。

CACHE_KEY=$(echo "$PROMPT" | sha256sum | cut -d' ' -f1) CACHE_FILE="cache/$CACHE_KEY.md" if [ -f "$CACHE_FILE" ]; then cat "$CACHE_FILE" exit 0 fi # 调用服务，结果写入缓存 result=$(call_service "$PROMPT") echo "$result" > "$CACHE_FILE" echo "$result"

缓存要注意失效策略。代码变了，缓存就该失效。因为缓存键是基于输入内容算的，代码一变，键就变了，自然命中不到旧缓存，这个设计天然解决了失效问题。

8. 从单点工具到工作流：下一步怎么扩展

8.1 把审查、提交、测试串成一条线

跑通代码审查之后，最有价值的扩展方向是把多个单点串成工作流。比如一个完整的"提交前检查"流程：

1. 检测到git commit，触发 pre-commit 钩子
2. 自动跑代码审查，有 BLOCKER 级别问题就阻止提交
3. 审查通过后，自动生成提交信息草稿
4. 提交完成后，自动为新增函数生成测试用例草稿

这条线串起来之后，你每次提交代码，背后都有一整套自动化检查在跑。你只需要在关键节点做决策，其余全部自动完成。

8.2 用钩子实现"无感触发"

工作流要真正好用，触发方式必须"无感"。不能指望用户每次都记得手动跑脚本。用 git 钩子是最自然的方式：

# .git/hooks/pre-commit #!/bin/bash "$PROJECT_ROOT/scripts/review.sh" || { echo "代码审查未通过，请处理后重新提交" exit 1 }

把钩子装好之后，审查就变成了提交动作的一部分，不需要额外记忆。这种"嵌入到已有习惯里"的设计，比"新增一个需要主动使用的工具"更容易坚持。

8.3 日志与可观测性：出了问题能查

工作流跑起来之后，一定要有日志。不然出了问题，你根本不知道是哪一步、哪个输入导致的。我的做法是每次调用都记录三样东西：输入摘要、输出摘要、耗时和状态。

{ echo "时间: $(date -Iseconds)" echo "输入哈希: $CACHE_KEY" echo "输入长度: ${#PROMPT}" echo "输出长度: ${#result}" echo "耗时: ${elapsed}s" echo "状态: $status" } >> logs/run.log

日志不用记完整内容（完整内容在缓存里），记摘要就够。出问题时，先看日志定位是哪次调用异常，再去缓存里找对应的完整输入输出。这套机制在排查"为什么这次审查结果很奇怪"这类问题时特别有用。

8.4 团队协作时的配置管理

如果这套工具链要给团队用，配置管理就要更规范。核心原则是默认配置统一、个人配置隔离。

config/default.yaml放团队统一的默认值，提交到版本库；config/local.yaml放个人覆盖项（比如自己的 API 端点、偏好的模型），加到.gitignore。脚本加载配置时，先读默认，再用本地覆盖。

# 合并配置 yq eval-all 'select(fileIndex == 0) * select(fileIndex == 1)' \ config/default.yaml config/local.yaml > /tmp/merged.yaml

这样既保证了团队一致性，又保留了个性化空间。新成员加入时，只需要复制一份local.yaml模板，填上自己的信息就能用。

9. 我在这套工具链上的一些真实体会

用了大半年这套整合方案，有几个体会是当初没想到的。

第一个体会是：整合的价值不在"用了 AI"，而在"减少了切换"。真正让我效率提升的，不是 Claude 给出的建议有多惊艳，而是我不再需要在编辑器和浏览器之间反复横跳。注意力保住了，工作流连贯了，这才是核心收益。

第二个体会是：提示词的质量比模型的强弱更重要。我一开始总想着换个更强的模型，后来发现，把提示词从"帮我看看这段代码"改成结构化的、有明确输出格式要求的模板，效果提升比换模型明显得多。提示词是你能完全掌控的变量，值得花时间打磨。

第三个体会是：不要追求一步到位。我见过有人想一次性把审查、测试、文档、提交全部自动化，结果每个都半途而废。正确的做法是一个场景一个场景地跑通、稳定、再扩展。跑通一个，就有一个的收益，而且前一个场景积累的配置、脚本、经验，都能复用到下一个。

最后一个体会是关于心态的：这套工具链是给自己用的，不是给别人看的。不用追求架构多优雅、功能多全面。能解决你自己的实际问题，能让你每天少花半小时在重复劳动上，它就是成功的。至于别人怎么评价，不重要。