• Geek_0ba253
    2026-06-06 来自日本
    老师可以讲一下,如何从外围,比如文档和测试的issue到代码,到核心贡献者,拥有合并代码和review权限的发展之路吗? 还有在Rust或Go等正在发展的阿帕奇孵化项目等,如何参与比较好?就和上一章节类似,了解学习技术,了解背景,提出方案探讨? 还有一些开源项目是由公司主导的,影响力大了之后会闭源,从而也会影响自己的贡献的项目。要怎么选长期发展的项目?还有修改范围,很多开源项目会有标准的,就是之前课程讲到的灰色区域,哪些API设计上是长期的 trade-off,哪些是错误?大概的评判标准。
    
    
  • Geek_0ba253
    2026-06-06 来自日本
    还有commit 的内容,注意让claude不要加上它是协作者的身份,这一般也是容易被误杀为AI自动提PR的证据。(之前AI造成的噪声有点多,让核心贡献者们有点敏感,可能会被close掉PR)。review 上的话,可以让AI 扫某语言,比如go的顶级项目,把其中issue常见错误写法,记录成一份常见误用清单,给AI对照(用十多年后技术行业标准,扫描发展很多年的项目,会发现还是会有很多收获的)。扫描审计可以弄一个skill,再加上一个对照误用清单(借鉴代码坏味道),再加上之前的架构图和核心模块及API分析文档。(把这个课程所有能帮助理解的东西都加入辅助了)。AI会偷懒,老是扫描不够全。(为了解决这个问题,可以加入代码轨迹记录,重复扫的放过,项目太大嫌慢的话(有足够token额度下,可以并行开Agent(提示词中加入,比如给我开10个Agent并行扫描(从不同角度,性能,写法等))))。按单一职责 分为 多个skill,审计,代码轨迹,用户故事(有时有误报,让AI顺着调用上下文,解释场景,问题,从而更一步减少误判,并发场景(可以加入时间窗口分析)),安全重构(问题重现(注意要按照项目资料的用法(有时AI会乱用)),建立安全防护网测试,解决问题,比对重构前后,输出报告文件(性能改善,可以输出基准测试)),pr (整理整个上下文,用简洁的语言,也就是老师的提示词)。skill一般是在300多行左右比较好,发现效果不佳,可以让claude简化,分离。
    展开
    
    