修改并测试用于评估AI模型的大型TypeScript代码库

## 先判断是审查还是修复，再读就近的智能体指南 首先确定代码库根目录、请求的结果以及负责该更改的子系统。大型代码库通常会在核心库、CLI、Web应用、持久化层、提供方、调度器、模式、实用工具、测试、文档、示例、迁移、自动化和安全工具之间划分职责。 编辑目录前，先阅读距离该范围最近的智能体指南，以及所有针对任务的设计或工作流文档。本地指南可能会细化根级规则，包括测试、生成文件、公开契约、数据库访问或发布行为。 采取行动前，先对请求进行分类： - 审查或审计是只读操作。检查当前分支、差异、评论和CI；在有用时运行不改变状态的检查；报告发现，但不得提交、推送或重写文件。 - 修复、改进或落地请求包括功能分支上的正常实现循环：检查、修改、验证、提交、推送，并跟进相关CI。 - 行为更改必须通过面向用户的工作流加以证明，不能只依靠孤立的单元测试。 从正确的根目录开始工作，并在将失败视为权威证据前，使运行时和软件包管理器版本与代码库声明保持一致。在新的checkout中，应先执行确定性的依赖项安装，再断定缺少模块属于代码缺陷。 将更改限制在所触及的子系统及其直接使用方。创建另一层抽象或添加软件包前，先搜索现有实现、实用工具、依赖项和附近的模式。 ## 在真实的CLI、API或浏览器流程中测试改动 使用代码库声明的脚本和封装程序，不要通过偶然的工具调用绕过它们。当封装程序有此要求时，通过软件包运行器的分隔符传递命令标志；代码库级评估应从代码库根目录运行。 按逐步扩大范围的顺序选择验证： 1. 运行针对已更改模块的测试。 2. 运行相关的类型、lint和格式检查。 3. 运行受影响的集成测试套件。 4. 使用本地构建执行实际的CLI、示例、API或浏览器流程。 5. 仅在风险或代码库政策有充分理由时，才运行更广泛的测试套件。 对于评估型工作流，应禁用结果复用，而不是清除缓存。导出机器可读的结果，并检查每个用例的成功状态、分数、错误、提供方输出、跟踪和安全发现。退出状态为零可能只表示通过了汇总阈值；这不能证明每个用例都成功。 只有当工作流需要凭据且环境文件确实存在时，才加载该文件。使服务持续连接到活跃会话，避免后台进程无声消失。通过启动输出或端口检查确认实际监听端口，不要假定框架默认值。 除非请求明确需要，否则不要启动静态生产查看器或另一个开发服务器。先检查预期服务是否已在运行；如果启动服务会与用户的会话冲突，应先征求同意。 当文档、模式、迁移或引用属于生成内容时，应使用其规范生成器并验证所得成果物。若代码库提供受支持的快速路径，则通过该路径测试文档，同时不得悄然跳过对更改有影响的检查。 ## 先复现失败再调试，不清空缓存和数据 使用暴露故障时相同的输入、状态和执行路径来复现问题。启用结构化调试日志，针对本次运行禁用缓存读取，并在修改代码前缩小故障范围。 区分环境故障与产品故障： - 运行时或软件包管理器版本不匹配属于环境问题。 - 干净checkout中缺少依赖项，通常需要执行确定性的安装。 - 过时的构建需要通过受支持的本地封装程序重新构建。 - 环境对齐后，同一代码路径仍出现确定性故障，就是产品缺陷的证据。 绝不能仅为让测试通过就删除或清空缓存、数据库、lockfile、生成的历史记录或用户数据。应优先使用无缓存选项、临时隔离的存储或只读检查。删除操作必须获得明确授权，并精确指定目标。 secret应存放在被忽略的环境文件或获批的secret存储中。绝不能在日志、代码、分支名称、提交消息、审查文本、截图或示例命令中打印、嵌入、提交或复制凭据。将源材料中发现的凭据视为已经泄露的数据，而不是可复用的指令。 使用项目的结构化日志记录器、对象上下文及其脱敏层。即便如此，若日志记录器不需要secret，也不要向其提供。错误处理应保留类型化上下文，同时不得暴露敏感载荷。 提出多个原因假设，再通过针对性检查逐一排除。应在实施最小修复之前或同时，添加一个能针对所观察行为失败的回归测试；在原因仍不确定时，避免无关的重构。 ## 通过功能分支合入改动，并等CI通过 所有更改都应通过功能分支和pull request交付。未经明确批准，绝不能直接向受保护分支提交、绕过hook或执行force-push。默认创建新提交；只有维护者要求进行相应的历史操作时，才能执行amend、squash或rebase。 仅stage预期文件，运行限定范围的lint和格式检查，遵循代码库的提交惯例，并更新该分支现有的开放pull request，而不是创建重复请求。不得让无关的lockfile或依赖项漂移混入更改。 当用户要求修复、改进或落地功能分支上的更改时，应完成获准的循环，无需在每个常规步骤暂停。按要求同步，运行限定范围的验证和真实工作流，提交、推送并观察CI。不得将此授权扩大到受保护分支、破坏性的历史更改、信息披露或生产操作。 合并后，持续跟进受保护分支的新CI运行，直至完成。采取行动前先对失败分类： - flake是非确定性的基础设施或工作进程噪声，尤其是测试成功完成后作业才失败的情况。仅重新运行失败的作业并确认恢复。 - 真正的回归是确定性的，并且可归因于该更改。通过后续pull request恢复受保护分支；共享分支损坏时，应优先迅速revert。 - 反复出现的flake本身就是缺陷。应修复泄露的资源、脆弱的设置或不切实际的timeout，而不是无限期地重新运行。 完成时应确保受保护分支处于green状态；否则，应通过支持日志明确指出一个预先存在且无关的故障。报告运行了哪些检查、检查了哪些证据，以及哪些验证无法完成。 ## 先审查安全问题，并从攻击者角度测试 在一般正确性问题之前，先审查安全回归。优先检查提示注入、对抗性输入的不安全处理、凭据暴露、服务器端请求伪造、路径遍历、不安全的反序列化、授权错误、数据外泄、不安全的工具使用、缓存误用和证据缺失。 然后检查可能破坏公开契约、数据完整性、并发处理、错误处理、提供方互操作性或持久化结果的行为。当更改影响安全行为、公开接口或缺陷修复时，应将缺失或无效的覆盖视为高优先级问题。 从攻击者视角测试安全和模型评估功能。探查假阴性、绕过、隐藏载荷、嵌套指令、编码技巧、不安全的工具调用和不完整的跟踪。发现绕过时，应在针对性的回归测试中保留原始攻击向量。 审查应以已更改的差异和当前分支尖端为基准。现有评论、自动审查和issue报告只是线索，不是证据；同步后应重新验证。除非更改使无关的既有缺陷恶化，否则不要重复已解决的发现，也不要标记这些缺陷。 在公开涉及未发布漏洞的更改前，确认协调披露允许公开。在此之前，只能使用获批的非公开协作渠道，并避免使用标识符、利用细节、受影响版本范围或会泄露信息的分支名称。每项安全修复都应包含针对原始攻击向量的回归测试。 如果演示应用的用途是教授对抗性测试，就不要移除其中有意保留的弱点，除非加固演示是明确目标。审查截图只能使用获准的托管工作流和获批的凭据；绝不能暴露上传密钥或提交附带产生的图片。 ## 编写严格类型的TypeScript，最后检查改动差异 编写遵循代码库模块系统和编译器边界的严格、惯用TypeScript。优先使用直接导入、`const`、对象简写、一致的大括号、`async`/`await`、类型化错误检查，以及在不可信边界处进行模式验证。当代码库要求直接归属时，避免使用再导出汇总文件。 添加辅助函数或依赖项前，先复用已有实现和本地实用工具。通过现有的示例模式保持提供方和集成配置有据可查。同时测试成功与失败路径，并在前端和后端惯例不同时分别遵循。 将死代码报告视为设计反馈： - 删除确实未使用的代码。 - 将按约定加载的工作进程、fixture或替代项注册为显式条目，并通过注释说明加载机制。 - 只有在注释中注明使用方时，才能将外部使用的export加入允许列表。 - 在检查有文档说明的使用方之前，绝不能移除允许列表条目或受保护的export。 不要手动编辑生成的changelog或其他生成成果物。修改源，然后运行规范生成器。将示例保存在指定区域，并提供足够的运行文档。 完成前，审查最终差异中是否存在意外文件、过时成果物、secret材料和范围蔓延。确认限定范围的测试、相关集成检查以及面向用户的实际路径。准确说明结果：区分哪些内容已通过、检查了什么、哪些内容仍未验证，以及任何失败是否与更改无关。