用途
ponytail-audit 用于对指定范围（某个文件夹、某个包或整个仓库）做一次完整质量审计，目标用户是需要快速摸清陌生代码库风险的开发者。它的关注顺序是：正确、安全、在预期负载下稳定、有测试、运行快、代码精简。
主要能力
- 先做地图：阅读 README、部署与构建配置、依赖清单、入口点（main、路由、处理器、任务、CLI 命令）和测试。
- 判断预期负载：是单人跑脚本，还是大量用户和进程并发；并在报告中说明假设的负载规模。
- 端到端追踪主要流程：数据从哪进来、存了什么、往哪输出；完整阅读涉及用户输入、金额、认证、数据写入、后台任务和跨进程共享的路径。
- 大仓库则优先深入错误代价最高的部分，并明确说明哪些部分没有读。
- 查找问题：错误结果、崩溃、边界情况（空值、零、最后一项、舍入、时区）、调用方与返回值不一致、同一规则在两处实现不同；安全漏洞（注入、弱随机、代码中的密钥、用户输入缺少校验）；数据丢失（吞掉错误、写入顺序错误、缺少事务）；规模问题（先检查后写入的竞态、每个进程重复做同样工作、只增不减的内存或列表、逐项查询、大输入下的 O(n²)、必须共享的进程内状态）；缺少测试的高风险逻辑；明显拖慢速度的路径；以及可删除、可复用标准库、可合并、可拆分或纯属多余的代码。
- 每条发现提供最小可行修复，优先通过删代码解决，不新增问题不需要的层、框架或配置。
使用方式
按用户指定的范围审计；未指定时审计整个仓库。只产出一份一次性报告，不修改任何代码。
输出结构
报告以“What this repo does”开头，用两三句话说明仓库用途和假设负载。随后按重要性分三组列出发现，空组跳过：Must fix（Bug、安全、数据丢失、在预期负载下会坏）、Should fix（缺测试的高风险代码、真实存在的慢路径、重复、职责混杂的函数、不应存在的代码）、Nice to have（小幅提速、更短写法）。所有发现跨组统一编号，最多 20 条，省略较小问题需说明数量。每条发现包含四部分：标题与位置、这是什么、问题、修复；并说明若不修的后果。结尾给出 Verdict（一句话结论或优先修什么）、Lean（在存在精简发现时给出可减少的行数与依赖数）和 Not checked（未读或未能运行的部分）。若无发现，则说明仓库用途后写 Healthy. Nothing to fix.，并用一行说明检查了什么。
适用场景与限制
适合接手陌生仓库、上线前评估、或想了解代码健康度时使用。它是一次性只读审计，不会改动代码；不关注代码风格偏好，不接受没有具体案例的发现；标记了限制说明的快捷实现不算问题，除非预期负载已经超出该限制。对未读取或无法运行的部分会明确列出。资料未提供安装方式、运行命令、收费或平台信息。