AI 工具链

从 monorepo 里挑微调样本,我是怎么把重复样板代码挡在门外的

从 monorepo 筛选微调样本时,重复样板代码是最大陷阱。文章提出三层过滤方案:AST 结构指纹归一化标识符后算哈希,抓“换皮代码”;路径聚类利用目录结构识别同目录批量生成物;diff 信号通过 Git 历史标记长期未修改的死代码。三者叠加可将重复率从 34% 降至 4%,同时避免误杀同构不同义的高价值业务样本。

AI 工具链

多仓库共用一套文档提示词,按服务差异注入上下文还保持输出格式统一

多仓库共用提示词时,需采用“结构化插槽+强制骨架回填”策略,先锁定输出格式硬约束,将上下文注入设计为只填空不改结构的插槽机制。关键做法包括:物理隔离骨架与插槽文件、显式标记上下文为纯数据、用同构字段模板消除自由文本、内置差异最大的 few-shot 示例、输出前程序化校验骨架并触发重生成,以及将插槽内容控制在 1500 token 内。该方案使格式校验一次通过率达 85% 以上,两次重生成后达 99%。

AI 工具链

用分步提示词拆解复杂正则:让模型先解释语义,再给等价改写

三步流程提升复杂正则改写质量:先约束粒度做语义解释,明确“不匹配什么”和回溯风险;再基于等价约束清单生成候选,重点保持捕获组编号与回溯语义;最后用对抗性测试用例验证,刻意构造边界情况暴露差异。分步执行比一次性改写更可靠,适用于嵌套分组、零宽断言等复杂场景。

AI 工具链

微调时依赖版本对不上,训练出来的代码模型会怎么退化

微调代码模型时,训练数据中的API调用模式会固化为特定依赖版本的“快照”。当推理环境版本不同,模型仍按旧版模式生成代码,导致可执行率显著下降——从91%跌至74%的实测案例中,主因是`torch.load`、`OneHotEncoder(sparse=False)`等API的语义或参数变化。这种退化源于训练数据版本信息缺失、多版本混叠,以及模型缺乏运行时反馈。缓解方案包括:在微调数据中注入版本条件、构建多版本覆盖样本、推理侧静态校验API兼容性,或直接锁定推理环境版本。

AI 工具链

AST 提参数类型和默认值,比纯文本注释准在哪:三种生成函数文档方式的对比

AST 提取签名信息配合注释解析是生成准确 API 文档的最优方案:类型和默认值从 AST 直接获取,准确率 100%,描述文字从 docstring 匹配。纯文本正则解析在处理复杂默认值时准确率骤降,纯 AST 生成则缺少描述信息。推荐使用 `ast` 模块加 `docstring_parser` 库实现,约 100-150 行代码即可稳定运行。

AI 工具链

把错误码表和业务规则喂给模型后,错误场景说明怎么从“失败”变成能直接用的排查步骤

错误场景说明质量差,根源在于上下文缺少排查路径维度。将错误码表升级为包含触发条件、可观测信号、检查动作、修复动作和验证方式的诊断卡片,并在提示词中明确要求按顺序完整输出排查步骤,禁止省略或推给客服。诊断卡片应作为 YAML 源数据维护在版本库,通过 CI 自动生成文档,确保单一数据源和同步更新。

AI 工具链

嵌了类型定义后,API 客户端代码还得过哪几道静态检查才敢合入

生成代码要真正可合入,仅靠提示词中的类型定义远远不够,还需通过三道硬性检查:先用真实工具链做编译与类型校验,确保代码可运行;再与 OpenAPI/JSON Schema 及业务规则比对,验证契约语义和错误路径;最后执行 lint、安全扫描、依赖与架构约束,保证代码符合工程规范。将三道检查串成合入门禁,失败即反馈重试,才能稳定产出高质量客户端代码。

AI 工具链

把历史 review 拒掉的改动做成负样本,微调后模型还会犯同样的错吗

负样本微调只能局部压制特定坏模式,无法教会模型正确写法,常导致模型从一种错误迁移到另一种。有效做法是按模式聚类、配高质量正样本(至少1:2)、构造近邻负样本,并利用reviewer评论做条件训练,将“不要这样”转化为“应该这样”。实测显示,该方法可显著降低同类及相邻坏模式出现率。

AI 工具链

从 commit 和 PR 描述里筛出用户能感知的变更,AI 生成的 changelog 才不用人工重写

从 commit 和 PR 描述中提取用户可感知的变更,需先按“用户行为、界面、性能是否发生可观察变化”分类,过滤掉纯重构、测试、CI 等噪音。工作流包括:commit 前缀初筛加语义分类(P1/P2/P3)、从 PR 描述中提取用户视角信息、合并去重、按类型生成 changelog。边界情况如安全修复、废弃功能、依赖升级需预设规则。完整 prompt 模板可复用,实际可将流程嵌入 CI 实现增量处理。