企业官网建设流程全解析

做营销型网站,百度网络营销的概念和含义,网站建设所用的工具,网站开发保存学习进度的方案一个下午#xff0c;我折腾出了一个 Code Review 的 Skill踩了个大坑#xff0c;但挺值起因 事情是这样的。 我手头有两个之前写的小工具#xff1a;一个能分析代码里的 API 调用流程#xff0c;画成时序图#xff1b;另一个能从 Git 里捞变更内容。某天下午我突然想到我折腾出了一个 Code Review 的 Skill踩了个大坑但挺值起因事情是这样的。我手头有两个之前写的小工具一个能分析代码里的 API 调用流程画成时序图另一个能从 Git 里捞变更内容。某天下午我突然想到这俩拼一块儿不就能做代码审查了吗不是那种帮我看看有没有 bug的审查——那个 Claude 本来就能干。我想要的是告诉我这次改动到底改了哪些调用链影响了哪些依赖风险在哪。想想就挺美动手吧。第一版三步走很合理16:13我的设计很朴素第一步分析变更前的代码生成基准报告 第二步用 Git 拿到变更内容 第三步对比一下出报告嗯逻辑清晰无懈可击。我还顺手规划了报告的样式——用 Mermaid 画图绿色表示新增的黄色表示改过的红色虚线表示删掉的。脑子里已经在预演最终效果了。用/skill-creator初始化好目录结构写完SKILL.md感觉良好。第二版还是写个脚本吧16:41开始实现第二步的时候我犹豫了一下。让 Claude 直接跑 Git 命令比如gitdiff--name-statusgitshow abc123gitdiffmain..feature想了想还是算了。这些命令的输出格式乱七八糟有的带颜色有的不带文件名要是有空格或者中文又得特殊处理diff 太长还会截断… 让 Claude 去解析这些乱麻不太靠谱。干脆自己写个 Node 脚本把 Git 操作封装一下统一输出成 JSON。这样 Claude 拿到的就是干干净净的结构化数据省心。给自己定了几个约束用 Node 18能用原生 API 就不引依赖零npm install拿来就能跑输出必须是 JSON方便后续处理最后这脚本写了 928 行。支持六种模式看工作区变更、看暂存区、看某个 commit、和某个分支比、看最近 N 次提交、比较两个 commit 之间… 基本够用了。{metadata:{gitMode:branch:main,currentBranch:feature/xxx},summary:{added:2,modified:3,deleted:1},files:[{path:src/hooks/useAuth.ts,status:modified,diff:...}]}到这儿为止一切都挺顺的。第三版翻车了17:02然后我实际跑了一遍。跑完愣住了。我设计的第一步是分析变更前的代码对吧但问题是——当我执行这个 Skill 的时候本地的代码已经是改完之后的代码了啊所以第一步分析出来的根本不是变更前的工作流而是变更后的。整个对比的前提就是错的。我盯着屏幕想了几秒有点想笑。这 bug 属于设计时觉得很合理跑起来才发现根本不是那么回事的典型。怎么办想了一会儿发现 Git diff 里其实啥都有- const API /api/v1/user const API /api/v2/user减号开头的是原来的加号开头的是现在的。也就是说我可以从 diff 反推出变更前的状态。那就把顺序换一下第一步先拿 Git diff这里面有变更前后的全部信息 第二步分析当前代码的工作流这是变更后的状态 第三步根据 diff 反推变更前的工作流然后生成对比这才对。当前能直接分析的是变更后变更前得靠 diff 倒推。之前的设计完全搞反了。改完之后顺畅多了。第四版补个默认值17:18最后跑了一遍git diff --stat发现文档里漏了一个东西报告默认输出到哪这种细节不写清楚用的时候肯定要问。补上默认输出目录v6/docs/code-review顺手整理了一下三份参考文档一份管工作流分析一份管 Git 变更检测一份管报告格式。各管各的以后好维护。复盘整个过程大概一个半小时改了四版。版本时间干了啥v116:13定了三步走的框架v216:41写了个 Node 脚本处理 Gitv317:02发现顺序错了重排v417:18补文档细节最大的教训是 v3 那个坑。画流程图的时候很容易想当然地觉得旧版本和新版本都能直接拿到。但实际跑起来你手头只有当前状态历史状态得自己想办法重建。这个道理说出来谁都懂但设计的时候真的很容易忘。最终长这样skills/code-review/ ├── SKILL.md # 主文档 ├── scripts/ │ └── git-change-collector.js # Git 脚本928 行 └── references/ ├── analyze-codeflow.md # 工作流分析 ├── git-change-detection.md # Git 变更检测 └── change-report-format.md # 报告格式用起来大概这样# 看看工作区改了啥node scripts/git-change-collector.js --modediff--source src/modules/user# 和 main 分支比一下node scripts/git-change-collector.js --mode branch:main# 看最近 3 次提交node scripts/git-change-collector.js --mode last:3输出的报告会有时序图对比、依赖图对比、每处变更的影响评估还有个验证清单告诉你该测哪些东西。所有节点都有编号讨论的时候可以直接说S3 这个调用有问题不用来回描述。为什么要写成 Skill有人可能会说直接让 Claude 审查不就行了干嘛非得搞个 Skill我是这么想的Skill 就是把一套方法论固化下来。每次审查都用同样的分析框架、同样的输出格式结果是可预期的。下次再审查不用重新解释一遍帮我看看 API 调用链有没有变化直接调就行。而且写 Skill 的过程会逼着你把事情想清楚。那个顺序搞反了的 bug如果不是认真设计工作流可能就一直藏着每次审查的结果都是错的还不自知。工具会倒逼你思考。这个过程本身就挺有价值的。