做安全工作的人应该都有同感每次给一个项目做安全审计来来回回都是那几件事——翻依赖版本、查敏感信息、看配置文件、找危险函数调用然后手动整理一份报告。这套流程重复性极高但每次项目上下文又不太一样很难直接套用现成模板。我之前一直想找一种方式能把安全审计这套方法论沉淀下来让大模型在接到审计任务时自动按专业流程执行而不是泛泛地帮我看看有什么安全问题。后来接触到 AI 编程工具里的 skill 机制才意识到这就是我要的东西。所谓 skill本质上是给大模型一份可复用的专业技能包里面有任务拆解步骤、领域知识、检查清单甚至还能附带脚本工具。把安全审计做成一个 skill就等于给智能体配了一个随身的安全审计专家不管面对什么代码库它都懂得按标准流程去排查、去验证、去输出报告。这篇文章就完整分享一下我从零搭建 security-audit-skill 的思路、代码和踩坑记录希望对准备自己做 skill 的朋友有帮助。1. 为什么安全审计值得做成一个 Skill1.1 Skill 到底是什么和普通提示词、Agent 有什么区别先聊清楚概念。拿我实际使用的 Claude Code、Codex、OpenCode 这些工具举例它们的 skill 机制大同小异在一个约定好的目录里放一个或多个结构化的技能包每个技能包由SKILL.md主文件加上可选的脚本、模板、参考资料组成。当对话内容命中技能包的描述特征时工具会自动加载这个技能包的内容让大模型按照里面定义的流程去执行。很多人会问这不就是一个更长的提示词吗区别还真不小。提示词是一次性的写在会话里就没了下次审计另一个项目还得重新写一遍。Skill 是长期存放在文件系统里的可版本管理、可分享、可复用。更关键的是skill 里可以捆绑可执行脚本这就突破了纯文本的限制——大模型可以调用脚本去扫端口、查依赖版本、跑静态检查拿到真实结果后继续分析。本质上skill 是一种文本引导 工具增强的组合体比提示词更接近一个完整的工作流又比 Agent 轻量得多。Agent 是会自动决策、自动拆解任务、自动调用工具的独立执行体skill 更像是一份高度结构化的操作手册加上配套工具箱它依赖宿主智能体来逐条执行但保证了执行路径的标准化和高质量。1.2 安全审计场景为什么天然适合 Skill 化安全审计是最适合 skill 化的场景之一原因有三点。第一审计流程高度标准化。无论是审计一个 Python 后端、一个 Node 前端还是一个 K8s 部署环境走的路子基本一致先摸底项目结构再查依赖和配置然后逐个检查高危风险点最后汇总成报告。这种流程固定、执行高度可复制的任务正是 skill 最擅长承载的。第二安全审计依赖大量领域知识比如 CWE 编号、OWASP Top 10、各类中间件的高危版本号、典型的危险函数列表。这些知识平时要么存在安全工程师脑子里要么散落在各篇文档里很难随时完整地传给大模型。但把它们整理进 skill 文件后大模型每次执行审计任务时都能自动加载这份安全知识库这比在对话里临时粘贴几篇资料可靠得多。第三审计结果需要统一的输出标准。给客户或领导的安全报告是有固定格式要求的风险等级要分高、中、低每条发现要包含位置、原因、影响、修复建议。把这些格式规范写进 skill大模型产出的报告就不会天马行空而是稳定输出结构一致的文档直接可用。如果你经常用 AI 工具帮忙做代码安全相关的工作但觉得回答太飘、不落地、没有系统性那大概率不是模型能力不够而是缺少一份给它立规矩的 skill。这就是我做 security-audit-skill 的初衷。2. Skill 的标准结构与设计思路2.1 目录组织一个 Skill 包到底该放什么目前主流工具的 skill 规范基本统一我这里以最常见的一种目录结构为例。一个名为 security-audit 的 skill通常长这样security-audit-skill/ ├── SKILL.md ├── scripts/ │ ├── run_audit.sh │ ├── check_hardcoded_secrets.py │ ├── check_dependencies.py │ └── check_config_risk.py ├── references/ │ ├── cwe_top25.md │ ├── owasp_api_top10.md │ └── dependency_high_risk_versions.md └── templates/ └── security_audit_report.md整个包的精髓在SKILL.md。它是技能包的入口也是宿主智能体唯一会主动读取的文件。脚本和参考资料本身不会自动加载但SKILL.md可以在正文里用相对路径指引模型去按需读取。目录设计上我坚持几条原则把可执行逻辑和纯知识分开scripts 是跑得动的代码references 是给模型读的资料报告中要固定的框架单独放模板方便模型直接往里面填内容不容易漏项所有文件尽量短小聚焦宁可多拆几个文件也别堆成一个大文件否则模型加载时消耗上下文 token 太多反而影响主任务执行。2.2 SKILL.md 的核心字段与写作要领SKILL.md的开头是一段 YAML 格式的 frontmatter这部分不仅要有还非常关键因为它决定了技能包在什么时候被触发。实际编写时这几个字段值得花心思name技能包的唯一名称简单明确我用的是security-audit。description这是整个 skill 里最重要的一段文字。它描述的是什么场景下该用这个技能大模型会基于这段描述来判断是否激活当前 skill。经验是写得越具体越好要把触发场景、目标对象、任务目标都说清楚。比如我写的描述是当需要对一个代码仓库、项目目录或运行中的服务执行安全审计检查依赖漏洞、硬编码敏感信息、错误配置、危险函数调用并输出分级安全报告时使用。光有安全审计三个字是不够的模型很难精确匹配。license如果你打算公开分享这个 skill最好声明开源协议。allowed-tools声明这个 skill 在执行过程中可以调用哪些命令或工具。它相当于一份白名单既约束模型不乱折腾系统也让模型明确知道自己有哪些可用资源。frontmatter 之后是正文部分。正文里我会明确写好这几块角色定位让模型以资深应用安全工程师的身份工作执行流程从信息收集、静态扫描、人工验证到报告输出的分阶段步骤关键约束比如不允许修改业务代码、必须区分确定项与疑似项、命令执行出错要记录并继续等输出格式直接引用报告模板并明确要求模型按模板产出结果。2.3 安全知识库怎么组织才不臃肿安全领域知识爆炸如果全塞进 skill 里光是依赖漏洞列表就能撑爆上下文。我的做法是分三层。第一层是SKILL.md里直接写核心流程和规则这部分必须精简绝不能超过合理的 token 预算。第二层是 references 目录下的专项知识文件比如 OWASP API Top 10、CWE Top 25以及我整理的高危依赖版本表模型在实际审计中遇到相关问题时会去查。第三层是动态扩展比如高危 CVE 库不可能内置在 skill 里我会在脚本里写一个联网查询接口或者引导模型在必要时自行搜索验证。这个分层思路的核心逻辑是静态知识要控制体积动态情报要走接口。skill 的价值是提供方法论和工具而不是背下整个世界。3. 完整实操从零搭建 security-audit-skill3.1 环境准备哪些工具必须安装动手之前先把环境捋一遍我用到的工具链如下工具用途备注Claude Code / Codex / OpenCodeskill 的宿主环境三者均支持 skills 目录可任选Python 3.9审计脚本运行环境建议 3.10 以上git审计 git 历史非必须但查敏感信息泄露很好用banditPython 代码静态安全扫描pip 安装即可npm audit 环境审计 Node 项目依赖有 Node 项目时才会用到我本机用的是 macOSLinux 环境也完全兼容。Windows 用户建议在 WSL 里操作因为 skill 脚本里大量使用 shell 命令原生 Windows 的兼容性是个坑。3.2 编写 SKILL.md从角色定义到流程约束SKILL.md是灵魂代码量不多但字字都要打磨。我直接把当前在用的完整版本贴出来你可以照着改--- name: security-audit description: 当需要对一个代码仓库、项目目录或运行中的服务执行安全审计检查依赖漏洞、硬编码敏感信息、错误配置、危险函数调用、权限风险并输出分级安全报告时使用。适用于 Web 应用、API 服务、微服务架构等常见开发场景。 license: MIT allowed-tools: ls, cat, grep, find, git, python, pip, npm, docker, curl, bandit, npm-audit --- # Security Audit Skill 你是一名拥有 10 年以上经验的应用安全工程师。你的目标是对目标仓库或服务执行一次专业、可复现的安全审计并输出结构化报告。 ## 执行流程 1. 信息收集先查看项目根目录结构识别技术栈、语言、框架如 find . -maxdepth 2 -type f | head -50或查看 package.json、requirements.txt、pom.xml 等清单文件。 2. 依赖审计 - Python 项目检查 requirements.txt / pyproject.toml运行 python scripts/check_dependencies.py 比对高危版本 - Node 项目查看 package-lock.json如有条件运行 npm audit --omitdev - 其他语言基于 references/dependency_high_risk_versions.md 中的已知漏洞列表进行人工比对。 3. 敏感信息检查运行 python scripts/check_hardcoded_secrets.py 扫描硬编码密钥、密码、Token、云厂商 AK/SK同时用 git log -p 快速排查历史提交中是否出现过敏感内容。 4. 配置风险检查重点审查环境变量文件.env、配置文件settings.py、application.yml、config.js 等检查 DEBUG 开关、弱口令、过宽 CORS、缺乏鉴权的管理接口等。 5. 代码风险点检查对于 Python 项目可运行 bandit -r 目标目录对于 JavaScript/TypeScript 项目重点查找 eval、innerHTML、child_process.exec 等危险调用。 6. 验证与交叉确认对上述扫描结果进行人工复核排除因测试代码导致的误报如果时间允许用 curl 或 docker 启动服务做基础验证。 7. 输出报告严格按 templates/security_audit_report.md 的格式输出每条发现必须标注风险等级、文件路径、行号如可得、问题描述、修复建议。 ## 关键约束 - 审计过程中不得修改业务代码不得部署或启动生产环境服务 - 区分确认问题与疑似问题疑似问题单独标注不得夸大为已确认漏洞 - 所有自动扫描命令输出可能很长先截取前 100 行分析再按需查看完整输出 - 如果某个检查步骤因环境原因失败如缺少依赖、网络不通在报告中记录失败原因不得跳过整项审计 - 报告最后必须附上复现步骤确保其他工程师能验证你的发现。这段SKILL.md的核心技巧在于把流程拆得足够细、每步都有明确产出物这样模型就不容易跑偏。约束条件里那句先截取前 100 行分析非常实用——大模型上下文有限一次性塞几百行脚本输出容易拉低分析质量。3.3 配套审计脚本三个关键脚本的写法与逻辑光有流程描述还不够脚本才是让 skill 真正可落地的部分。我核心维护三个脚本每个都经过多次迭代这里挑两个重点讲。check_hardcoded_secrets.py是整个 skill 里最实用也最容易误报的脚本。它的基础逻辑是正则匹配高熵字符串和已知模式#!/usr/bin/env python3 import re import sys from pathlib import Path SECRET_PATTERNS [ (rAKIA[0-9A-Z]{16}, AWS Access Key ID), (r(?i)(password|passwd|pwd)\s*[:]\s*[\][^\]{6,}[\], Hardcoded Password), (r(?i)(api[_-]?key|secret[_-]?key|token)\s*[:]\s*[\][^\]{8,}[\], API Key/Token), (r-----BEGIN (RSA |EC |DSA )?PRIVATE KEY-----, Private Key), (rxox[baprs]-[0-9A-Za-z-]{10,}, Slack Token), (rgh[pousr]_[0-9A-Za-z]{20,}, GitHub Token), ] SKIP_DIRS {.git, node_modules, venv, .venv, dist, build, __pycache__} SKIP_FILES {package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock} def scan_file(path: Path) - list: findings [] try: content path.read_text(encodingutf-8, errorsignore) except Exception: return findings for line_no, line in enumerate(content.splitlines(), 1): for pattern, desc in SECRET_PATTERNS: if re.search(pattern, line): findings.append({ file: str(path), line: line_no, type: desc, snippet: line.strip()[:120] }) return findings def main(root: str .) - None: root_path Path(root) findings [] for path in root_path.rglob(*): if path.is_file() and not path.name in SKIP_FILES: rel_parts path.relative_to(root_path).parts if any(part in SKIP_DIRS for part in rel_parts): continue findings.extend(scan_file(path)) if not findings: print(No hardcoded secrets detected.) return for f in findings: print(f{f[file]}:{f[line]} [{f[type]}] {f[snippet]}) print(f\nTotal: {len(findings)} potential findings. Please manually verify.) if __name__ __main__: main(sys.argv[1] if len(sys.argv) 1 else .)这个脚本的设计要点在于排除目录要覆盖常见依赖目录否则 node_modules 一扫描就是几十万条结果直接卡死锁定常见 token 前缀格式宁可漏报也别疯狂误报因为误报会严重消耗模型的分析注意力输出格式带上文件路径、行号和关键片段方便模型直接引用到报告里。check_dependencies.py则负责依赖版本比对。思路是解析项目依赖清单文件提取包名和版本号再和内置的高危版本字典比对#!/usr/bin/env python3 import json import re import sys from pathlib import Path HIGH_RISK_VERSIONS { django: {3.2.24: CVE-2024-... SQL injection risk, 4.0: Known DoS vulnerabilities}, flask: {2.3.0: CVE-2023-... info disclosure}, requests: {2.31.0: CVE-2023-... proxy bypass}, lodash: {4.17.21: CVE-2021-... prototype pollution}, minimist: {1.2.6: CVE-2021-... prototype pollution}, log4j: {2.17.1: CVE-2021-44228 Remote Code Execution}, spring-boot: {2.6.6: CVE-2022-... Spring4Shell}, } def parse_requirements(text: str): packages {} for line in text.splitlines(): line line.strip() if not line or line.startswith(#): continue match re.match(r([A-Za-z0-9_.\-])\s*[!~]\s*([0-9A-Za-z.\-]), line) if match: packages[match.group(1).lower()] match.group(2) return packages def parse_package_json(path: Path): try: data json.loads(path.read_text(encodingutf-8)) deps {**data.get(dependencies, {}), **data.get(devDependencies, {})} return {k.lower(): v.replace(^, ).replace(~, ) for k, v in deps.items()} except Exception: return {} def check_version(pkg: str, version: str) - list: issues [] if pkg not in HIGH_RISK_VERSIONS: return issues for cond, desc in HIGH_RISK_VERSIONS[pkg].items(): if cond.startswith(): limit cond[1:] if version and version limit: issues.append(f{pkg} {version} violates {cond}: {desc}) return issues def main(root: str .) - None: root_path Path(root) found False for req_path in root_path.glob(requirements*.txt): found True packages parse_requirements(req_path.read_text(encodingutf-8, errorsignore)) for pkg, ver in packages.items(): for issue in check_version(pkg, ver): print(f{req_path.name}: {issue}) for pkg_path in root_path.glob(package.json): found True packages parse_package_json(pkg_path) for pkg, ver in packages.items(): for issue in check_version(pkg, ver): print(f{pkg_path.name}: {issue}) if not found: print(No dependency manifest files found. Skipping dependency check.) elif not sys.stdin.isatty(): pass这里得说明一点内置高危版本表不可能覆盖全部生态所以这个脚本定位是已知漏洞快速筛查而不是全量漏洞库。真正全量的话应该对接 GitHub Advisory Database 或各家包管理器的审计接口那可以作为后续增强方向。还有个check_config_risk.py核心是检查.env文件是否存在、权限位是否过宽、配置里有没有把DEBUGTrue之类的危险开关打开。它逻辑简单核心就几条正则加权限判断这里不展开贴代码了思路就是上面两个脚本的简化版。3.4 安装到宿主环境Claude Code、Codex、OpenCode 的通用做法写完之后怎么让工具识别这个 skill不同工具目录约定略有差别但整体上一句话就能说清把整个 skill 目录放进宿主工具指定的 skills 路径下。以我常用的 Claude Code 为例我把 security-audit-skill 放进~/.claude/skills/目录下它就能全局生效。如果只想对某个项目生效就放到项目根目录的.claude/skills/下。Codex 对应的目录是~/.codex/skills/OpenCode 则是~/.config/opencode/skills/。放进目录后重启对话新会话就能识别到。我的建议是先用全局目录安装调试行为稳定后再决定要不要放进项目级目录。项目级 directory 的好处是团队成员可以提交到 git大家一起维护审计基线适合多人在一个仓库配合的场景。启动后怎么确认 skill 生效了最简单的方法是在新会话里问一句你现在有哪些可用的 skills或者直接说请对当前目录执行一次安全审计观察模型是否加载了 security-audit 的流程。如果它开始列目录、找依赖文件、跑脚本说明激活成功了。3.5 触发机制观察模型什么时候会启动这个 Skill一个很玄学但我实测中反复验证过的点description写得好不好直接决定 skill 的激活率。同一个项目目录我一开始写的 description 是security-audit skill for code security结果模型经常不触发需要我手动说用 security-audit 技能跑一遍。后来我把 description 改成明确列出触发场景——检查代码仓库/项目目录/运行服务是否包含安全漏洞、依赖风险、敏感信息泄露、危险配置——激活率明显提升。原因是宿主导入模型在每轮对话开始时会用一段 prompt 对所有 skill 的 description 做相关性评分评分高的才会被加载进上下文。description 里包含越多的任务类关键词和动作场景匹配成功率就越高。这和在搜索引擎里做关键词匹配是同一个逻辑。4. 实战记录拿一个真实订单服务跑一遍审计4.1 目标环境说明做了一个完整实战来验证这个 skill 的效果。目标是一个常见的订单服务项目技术栈是 Python 的 Django 3.2 加 MySQL另外额外加了一个 Node.js 的辅助服务结构不算复杂但覆盖了多数典型问题场景。我在这个项目里预先埋了几个真实项目里常见的问题Django 的DEBUG没关、requirements.txt里固定了一个存在已知漏洞的旧版本库、.env文件被误提交进 git 仓库而且在代码里硬编码了一个数据库密码、某个 view 直接用了字符串拼接拼 SQL。一共四个问题难度中等模拟的是开发过程中常见的疏漏。4.2 完整执行过程与模型行为观察我对终端里的助手直接说请对当前目录执行一次完整的安全审计使用 security-audit 技能。然后观察它的行为。第一步是信息收集阶段。它先执行了find . -maxdepth 2 -type f | head -50把一个中型项目的文件清单列出来随后识别出manage.py、requirements.txt、config/目录判断是 Django 项目。这个判断过程比我直接告诉它这是 Django 项目更有价值因为现场看到的信息远比我口头描述的全。第二步依赖审计模型调用了python scripts/check_dependencies.py。脚本输出显示Django3.2.4命中高危版本规则提示存在已知 SQL 注入风险。这里它做了个很聪明的动作——没有立刻下结论而是先打开requirements.txt确认版本号确实写死在 3.2.4然后才把这个问题写入报告。这种先自动扫描、再人工复核的节奏正是我在SKILL.md里强调的流程。第三步敏感信息检查。执行python scripts/check_hardcoded_secrets.py后脚本在order_service/settings.py的第 58 行匹配到一个疑似硬编码密码。模型显然对被标记的高亮片段产生了警觉在报告里把它标成疑似问题而不是确认问题并提示工程师去验证。这个行为很关键——它没有被脚本输出带着走而是严格按SKILL.md的要求做了分级。随后它还主动跑了一遍git log --oneline | head -20检查有没有敏感信息被提交进历史记录。第四步配置风险检查里模型找到了两个重要问题。一是settings.py里的DEBUG True二是.env文件被提交进了仓库通过git status和git ls-files | grep .env确认。这部分它不是靠脚本发现的而是靠SKILL.md里重点审查环境变量文件、配置文件这条指令引导出来的。第五步代码风险扫描Python 项目直接跑了bandit -r .扫出一堆中低危问题其中就有我埋的 SQL 拼接漏洞。bandit 输出很长模型按我的约束只取了前 100 行分析命中关键问题后没有再被无关输出干扰分析质量比较稳。最终它按templates/security_audit_report.md的格式产出了一份完整报告把所有四个预置问题全部找到并且每个例子都标注了文件路径、行号、修复建议。整个审计过程大约 8 分钟其中大部分时间花在脚本执行和依赖解析上。4.3 产出报告效果与质量这份报告质量超出我预期。四个预置问题无一遗漏每个结论都带复核路径不是单纯罗列扫描结果。更让我意外的是它把硬编码数据库密码和.env 文件被提交两件事关联起来指出这属于同一类敏感信息泄露风险建议一起修复。这种跨文件的关联分析能力是普通静态扫描工具给不了的价值。报告模板里我要求的复现步骤它也写了。比如对 SQL 拼接漏洞它给出了如何通过curl访问对应接口并传入参数验证问题的具体方法。这意味着团队里任何人拿到报告都能按步骤复查不用再拉着原作者解释半天。5. 常见问题与排查技巧实录5.1 Skill 不触发或触发率低这是我被问得最多的问题。首先是检查description是否写得太宽泛或太窄。太宽会让任何对话都触发干扰正常使用太窄则该触发时不触发。我最后的做法是描述里明确写对xxx执行安全审计这类动作词并列出目标对象的常见形态代码仓库、项目目录、运行服务。其次是确认 skill 目录是否真的被宿主读取了。不同工具读取时机不一样Claude Code 是启动时加载所以装完新的 skill 必须重启会话。最后如果是在项目级目录注意确认相对路径别放错层级。5.2 误报太多模型被带偏敏感信息扫描和依赖版本比对天然有误报率。check_hardcoded_secrets.py初版把 Docker 镜像里的示例密钥、测试用的假 Token 全扫出来了模型又不够聪明全写进报告里一篇报告十几条高危实际一半以上是误报。解决办法分两层第一层在脚本里做过滤排除测试目录、示例文件、mock 数据本质是减少噪声输入第二层在SKILL.md里加约束要求模型对自动扫描结果进行人工语义复核把疑似和确认分开标记。这两个措施叠加误报率降了大概七成。5.3 上下文窗口被撑爆如果项目的依赖文件特别大比如package-lock.json几万行脚本一次性输出全部比对结果大模型上下文直接爆掉。我的解法是几管齐下脚本输出限长匹配结果超过 50 条就只打印前 50 条并加一行完整结果见 audit_output.jsonSKILL.md里明确要求模型先看输出摘要再做决策尽量不要把大文件的原始内容喂给模型让脚本先做粗筛模型只审核可疑行。5.4 脚本执行权限与环境变量问题把 skill 目录通过 git 同步到别的机器后经常遇到脚本没有执行权限。我踩过这个坑之后在README里加了一行安装命令chmod x scripts/*.sh scripts/*.py另外如果脚本引用了第三方库比如 requests目标机器上没装就会直接执行失败。我的策略是能只用标准库就只用标准库脚本保持零依赖非要第三方库不可在SKILL.md的依赖说明里写清楚并在脚本开头加依赖检查缺库时提示安装命令而不是直接抛堆栈。5.5 模型幻觉报了代码里不存在的漏洞这是大模型做安全审计时最容易被人诟病的问题。我遇到过模型信誓旦旦说某个文件存在 SQL 注入但打开文件一看根本没有相关代码。排查之后发现它是在参考了网上类似项目的审计报告后脑补的。针对这个问题我在SKILL.md里加了硬性规定报告中所有高危和中危发现必须附带能够佐证的具体代码片段或可复现的验证步骤无法提供佐证的发现只能放入建议人工复核清单不算作确认问题。这个约束立竿见影模型开始严格引用代码内容而不是凭经验编造报告的可信度明显提升。6. 一些后续可以继续做的方向6.1 对接漏洞数据库实现动态查询当前内置的高危版本表是静态的肯定越用越旧。后续计划把核心脚本升级成可配置的数据库驱动支持接入第三方漏洞情报接口自动拉取最新 CVE 数据。这样每次审计时依赖比对不再是固定版本表而是实时获取已知漏洞情报准确率会有一个质的提升。6.2 输出多格式报告与自动化流转现在报告是固定 Markdown 模板对纯技术团队够用。但安全审计的受众不一定都是开发给管理层看的报告更关注风险等级分布和修复优先级而不是具体到哪一行代码。后续可以增加模板变体支持按受众不同输出执行摘要版、技术明细版甚至对接工单系统自动创建待办事项进一步提升安全审计的自动化程度。6.3 多人协作与组织级审计基线skill 本质是文件天然支持 git 协作。团队内部可以把它作为安全审计基线仓库一起维护沉淀不同业务的审计要点补充各自技术栈的特殊检查项。当组织内部有一套公共的安全审计技能库之后新项目上手审计的速度会快很多安全经验也不再集中在个别工程师身上。我个人维护这个 skill 后最大的一个体会是安全审计这件事以前靠人反复重复劳动积累经验现在可以把方法论结构化地沉淀到工具链里让每个项目默认获得同一条标准的审计流水线。这比自己每次从零问一遍大模型帮我查查安全问题要靠谱得多。如果你也在做类似的事情建议直接复制一份SKILL.md按自己技术栈调整跑通之后再慢慢加脚本、补知识库迭代出自己的专属版本。