Skip to main content

· 7 min read
Chris (Gentle) Yang

在 AI 编程普及的今天,GitHub Copilot、Cursor、OpenAI Codex等工具已经成为开发者的标配。当有新的贡献者带着 AI 编程工具来到你的开源项目时,AI 是会成为一个高效的高级工程师,还是一个到处制造混乱的“实习生”? 答案往往取决于你是否为 AI 提供了明确的上下文。这就是 AGENTS.md 规范诞生的原因。

与此同时,越来越多的开发者在参与开源项目贡献时使用自己的AI Coding Agent,这包括向Linux内核提交代码。所以开源项目及其维护者不得不积极面对这一现实变化。

1. 什么是 AGENTS.md?

简单来说:README.md 是写给人类看的,而 AGENTS.md 是专门写给 AI 编程工具看的。

它是一个放置在项目根目录下的标准 Markdown 文件(遵循 https://agents.md 开放规范),用于为 AI Agent 定义在当前仓库中工作的操作规范、架构约束、技术栈细节以及常用的终端命令。

2. 为什么要使用 AGENTS.md?

在项目中引入 AGENTS.md 能带来立竿见影的收益:

消除“幻觉”与过度重构:AI 经常会根据其训练数据推荐过时的库,或者在修复小 Bug 时擅自重构不相关的文件。在 AGENTS.md 中设定严格的边界,可以大幅降低这类风险。

统一跨工具的行为:无论贡献者使用的是 Cursor、Copilot 还是独立的 CLI ,AGENTS.md 都能作为唯一的事实来源(Single Source of Truth),确保 AI 生成的代码符合你项目的风格指南。

大幅降低新贡献者的上手门槛:当开发者启动 AI 助手时,AI 会自动读取该文件,了解如何构建项目、运行测试和格式化代码,无需开发者反复手动向 AI 投喂冗长的上下文。

提升测试与交付的成功率:通过提供精确的测试和校验命令,你可以要求 AI 在修改代码后自行验证结果。

3. 如何编写高质量的 AGENTS.md?

编写给 AI 看的文档,与写给人类看的文档有本质区别。AI 不需要客套话,需要的是可执行的命令和明确的规则。

第一步:在根目录创建文件 直接在仓库根目录新建 AGENTS.md ,并在头部明确其用途和角色设定。如果是一个大型单仓项目,那么你也可以在不同模块下创建专属于该模块的 AGENTS.md ,这完全没有问题,符合最佳实践。

第二步:指令命令化 (Command-First) 不要使用模糊的散文。例如,不要写“请确保代码通过测试”,而是直接提供命令,让 AI 可以通过退出码 (Exit Code) 来验证结果:

“在完成任何修改后,必须运行 npm run test 和 npm run lint。”

第三步:明确技术栈与代码规范 指出项目使用的具体库版本和约定俗成的写法,明确禁止 AI 引入你不想要的技术栈。

第四步:划定红线(边界) 明确告诉 AI 哪些目录是只读的,哪些文件是自动生成的、绝对不能手动修改的。

真实案例模板 以下是一个适用于前端项目的 AGENTS.md 示例,展示了如何清晰地向 AI 下达指令:

## AI 编程操作指南
你是一个资深的前端工程师。在修改本仓库的代码前,请严格遵循以下规则:

### 1. 技术栈与架构
- 这是一个使用 React 18 + TypeScript + Vite 的项目。
- 状态管理使用 Zustand,**请勿引入 Redux** 。
- 样式使用 Tailwind CSS。**禁止编写内联样式** (`style={{...}}`)。

### 2. 编码规范
- 优先使用 `const` 而不是 `let` 。
- 在定义类型时,优先使用 `interface` 而不是 `type` 。
- 组件必须放置在 `src/components/` 目录下,并使用命名导出(Named Exports)。

### 3. 测试与验证
在完成任何代码修改后,你必须在终端执行以下命令验证更改:
- 运行测试: `npm run test`
- 类型检查: `npm run typecheck`
- 代码格式化: `npm run lint:fix`

### 4. 边界与限制
- **绝对不要** 修改 `src/legacy/` 目录下的任何文件,该目录已被标记为废弃。
- 不要尝试手动修改 `package-lock.json`。

当然,对于相对比较简单的项目,你完全可以尝试让Coding Agent在阅读了 AGENTS.md 官网的信息后自动帮你快速创建一个 AGENTS.md 文档,在经过你的评审后即可使用。

4. 结语

在 AI 原生开发的浪潮中,让 AI 更好地理解你的项目,是维护代码质量和提升社区协作效率的关键。在你的开源项目中花几分钟添加一个 AGENTS.md,你将收获更高质量的 Pull Request 和更少的人工评审负担。

立刻行动起来,为你的代码库雇佣一个合格的“AI 守门人”吧!


相关链接

· 11 min read
Chris (Gentle) Yang
原文 https://wanderingstan.com/2020-02-04/the-evolution-of-developer-experience-in-the-20th-century
作者 stan james (已书面获得作者授权翻译及发布)
翻译 杨振涛

翻译:20世纪的开发者体验简史

一个做营销的朋友曾在我写代码的时候,看着我的屏幕说:“看起来太可怕了!” 这引发了我的思考,我们是如何进入到这个看起来奇奇怪怪的彩色字符与黑色美学世界的。正因如此,才有了这篇开发者体验简史。

起源

Ada Lovelace 在1842年编写了第一个计算机程序。由于当时实际上并没有计算机,因此该程序从来没有运行过。不过当看到她如何在纸上实现算法时,就会发现这是一项令人着迷的、史无前例的开创性工作。

Wikipedia

这是为查尔斯·巴巴奇(Charles Babbage)的分析引擎计算伯努利(Bernoulli)数字的程序,这在数论中很重要。

电线和文字错误(1940年代)

第一台计算机是在1940年代建造的,它是通过连接电线、转动表盘和切换开关来编程的。所谓“编程”只是一种特殊的“接线”工作。当时并没有做其他使人类编程更容易的任何努力,因为这些机器能够存在就已经足够了!

ENIAC计算机 编写程序

这个时代还给我们带来了BUG(程序错误或漏洞)的概念。第一个 BUG 是一只飞蛾(字面意思)造成继电器短路。格蕾丝·霍珀(Grace Hopper)在她的日志中记录了这一事件的发生及那只飞蛾。

第一个软件 bug.

汇编语言(1950年代)

尝试减轻人类负担的第一个努力是汇编语言,该语言使程序员可以使用“ADD”或“JUMP”这类的更适合人类下达的指令,而不是记住诸如“523”或“10011011”之类的数字代码。但这只是非常有限的一步前进,因为程序员仍然必须知晓计算机的内外部架构。

阿波罗太空任务的代码是汇编语言的一个很好的例子,尽管它是在1960年代编写的。下面是该程序部分内容的打印输出,还有一个很有趣的名字:亲吻!

Code From Apollo computer 阿波罗计算机的代码 (完整的代码库存于 Github上)

INTRPVP         STQ     BOFF            # PRECISION UPDATE PASSIVE VEHICLE
RTRN # TDEC1
AVFLAG
OTHERV
CALL
CSMPREC
GOTO
RTRN
OTHERV CALL
LEMPREC
GOTO
RTRN

打孔卡和高级语言(1950年代)

像 Fortran 和 Cobol 这类语言使用了准英语函数名称,例如 “if”、“not” 和 “while”,只要有合适的编译器,就可以在不同的计算机上运行。

这些第一代“高级”语言都是以相同的方式编写的:在打孔卡上。每张卡对应于一行代码,每行通常为80个字符。

人类可读的代码位于卡的顶部,我们可以从上述卡片读取到:

IF MOD-G-JAHR NOT NUMERIC MOVE ZERO TO MOD-G-JAHR. 

一个程序由一组卡片组成。编辑程序包括打孔新卡或对该组卡片重新排序。

如下图所示,写在该组卡片侧面的“注释”,标示出了子程序。红色斜线作为一种简单粗暴的方法,以便在卡片组散落开的时候可以顺利恢复。您还可以看到旧的红色标记,标示出了该组卡片已重新排序的部分。

单个程序卡片组,标记为单独的子程序。当卡片被更换或重新排序时,这些标记能够展示编辑的影响范围。 (维基百科)

与现代语言不同,当时并没有缩进来表示块。在您一次只能看到一行的世界中,缩进毫无意义! Fortran 语言使用缩进来区分注释(第1列)、标签(第2-5列)和语句(第7列及以后)。

C AREA OF A TRIANGLE - HERON'S FORMULA
C INPUT - CARD READER UNIT 5, INTEGER INPUT
C OUTPUT -
C INTEGER VARIABLES START WITH I,J,K,L,M OR N
READ(5,501) IA,IB,IC
501 FORMAT(3I5)
IF(IA.EQ.0 .OR. IB.EQ.0 .OR. IC.EQ.0) STOP 1
S = (IA + IB + IC) / 2.0
AREA = SQRT( S * (S - IA) * (S - IB) * (S - IC) )
WRITE(6,601) IA,IB,IC,AREA
601 FORMAT(4H A= ,I5,5H B= ,I5,5H C= ,I5,8H AREA= ,F10.2,
$13H SQUARE UNITS)
STOP
END

REPL 与行号(1960年代)

BASIC 计算机语言的设计是为了更加易于使用。它采用分时并行的策略开发,这使得许多用户可以通过电传打字机与一台计算机进行交互,而无需加载打孔卡。史上第一次,用户可以直接在计算机内存中编写、修改和运行程序!这是第一个 REPL,即“读取–执行-显示 循环”(read-eval-print loop)。

为此而开发的标准和协议,今天仍在开发人员的终端中使用。

Teletype Code

(来自 YouTube)

在上图中,请注意行号的创新。与手动分类打孔卡相比,这一定是个很棒的创新!

1968年的手册中的这个例子,实现了对输入数字求平均值:

5 LET S = 0
10 MAT INPUT V
20 LET N = NUM
30 IF N = 0 THEN 99
40 FOR I = 1 TO N
45 LET S = S + V(I)
50 NEXT I
60 PRINT S/N
70 GO TO 5
99 END

可视化编辑(1970年代)

廉价 CRT 显示器的出现意味着开发人员不用再浪费纸张了,而改为在屏幕上写程序。此时代码编辑器 vi 和 emacs 出现了,从而开始了漫长的开发者传统项目——谁是最佳编辑的争论。(今天依然很流行的 vim 是从编写于1990年代的 vi 更新而来。)

vi 编辑器展示在 CRT 终端上的 C 程序 (维基百科)

像 C 这样的新语言通过引入缩进来利用显示器的优势。在上图中,join(int c)后的行旨在表明它们在函数的范围内,for(a1…)命令后的行同样具有类似的范围声明含义。这种使用视觉空间来表示语义含义的方法是一种真正的创新,也是对人类视觉能够发现视觉对齐方式的真正启示。

这项创新还引发了缩进应当采用“Tab还是空格”、2-4-8空格以及“括号应当放在哪一行?”等无休止的“宗教战争”。

语法高亮、自动格式化和可视化调试器(1980年代) Mac Pascal 是第一个在编辑时就检查语法错误的编辑器,而不用等到编译阶段。

它也是第一个进行语法高亮和自动格式化的编辑器。由于 Mac 一开始不支持颜色显示,因此使用粗体和斜体来突出显示。

Video of Mac Pascal showing syntax highlighting and auto-indenting.

Mac Pascal 的视频展示了语法高亮和自动缩进。

几年后,Mac Pascal 背后的公司带来了世界上第一个可视化调试器。

(译者注:此张图片在原文的连接已不可访问 https://insidelinkusa.com/wp/wp-content/uploads/2020/02/v4LightsBug.jpg , 译者通过Google搜索到同名且符合该上下文的原图替换在此。新替换的图片所在文章链 接 http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2010/3/20_MacPascal_and_Think_Technologies.html

界面设计器、查看源代码和搜索(1990年代)

史蒂夫·乔布(Steve Job)在被踢出苹果之后,创立了 NeXT 计算机。 NextStep 操作系统对开发人员来说是开创性的,因为它将界面开发与代码编写分离。现在,你可以通过仅从调色板中拖动它而不是编写数行代码,即可实现将一个按钮添加到窗口中。该程序称为界面设计器(Interface Builder),而且今天它依然存在于 Apple 的 XCode 中,用来构建所有 iOS 应用程序。

20世纪末期,Web网络出现了。这将再次彻底改变开发者体验。

Web浏览器将开发人员的学习民主化,因为可以“查看源码”:让任何人都感到好奇的网页源代码可以立即查看!突然,每个人都有了自己的 HTML和 JavaScript 开发环境,每一个新网页都是一个新的学习示例!

1998年作为本世纪的暮光,也是 Google 的成立之年。这将成为开发者体验的无名基石,因为我们开始复制错误消息以及诸如“如何退出VIM?(https://www.freecodecamp.org/news/one-out-of-every-20-000-stack-overflow-visitors-is-just-trying-to-exit-vim-5a6b6175e7b6/ )”这类问题,然后粘贴到搜索框里面。不过这已经是另一个话题了!

· One min read
Chris (Gentle) Yang

OSPO 介绍 漫画版

此前发布过的【OSPO 漫画:来自日本OSPO Summit 2023的分享】,近期终于抽时间完成了中文版翻译。原作品使用日语和英语发布在 https://www.miraclelinux.com/miracle110/miracle-chan 及X平台,使用CC BY-SA 4.0许可;中文版是基于英语版本翻译而来,已和原作沟通,后续也会同步发布到X平台。

OSPO = Open Source Program Office,即 开源项目办公室,也称为开源办公室。

· 9 min read
Chris (Gentle) Yang

生成式AI在持续快速发展进化,OSI 也在持续推动行业共识,研讨“开源人工智能”的定义,笔者一直在跟进该项工作的进展,近期看到OSI官方博文发布了最新的v0.0.7版本,特此翻译供参考。(OSI官网内容采用知识共享 署名 4.0 国际许可协议)

HackMD上发布的 OSAI v0.0.7,欢迎参与反馈和讨论。 https://hackmd.io/@opensourceinitiative/osaid-0-0-7

OSI官方博客文章链接 https://opensource.org/blog/open-source-ai-definition-weekly-update-april-15

OSI官方论坛的讨论帖,欢迎反馈意见与建议。 https://discuss.opensource.org/t/draft-v-0-0-7-of-the-open-source-ai-definition-is-available-for-comments/298

缩略语与术语


开源 AI 定义

版本 0.0.7.1

注:本文件由三部分组成:前言说明了本文件的意图、开源人工智能定义本身以及评估法律文件的核对表。

本文件采用了经济合作与发展组织(OECD)对人工智能系统的定义(https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0449)。

人工智能系统是一种以机器为基础,可以根据明确或隐含的目标,从接收到的输入信息中推断出如何生成预测、内容、建议或决策等输出结果,从而影响物理或虚拟环境的系统。不同的人工智能系统在部署后的自主性和适应性程度各不相同。

关于人工智能系统定义的更多信息,请访问 OSI 博客(https://blog.opensource.org/open-source-ai-establishing-a-common-ground/)。

· 9 min read
Chris (Gentle) Yang

原文标题:3 types of leadership for open organizations Servant leaders, quiet leaders, and open leaders have traits useful to open organizations.

原文链接:https://opensource.com/article/23/2/leadership-open-organizations

作者 Len Dimaggio 发表于 2023-2-9

在经典电影《佳人有约》中,一个犯罪团伙的头目打嗓门儿威胁式地反复吼道:"照我说的做!"以此展示他的领导风格。这在喜剧中很有娱乐性,但在一个开放式组织中,这样做会导致失败和被忽视。

在本文中,我将回顾在开放式组织中有效的领导风格。请记住,这些领导风格并非存在于真空或孤岛之中。要想成为一名有效的管理者,你需要根据具体情况的要求,组合使用各种领导风格技巧。

这三种领导风格对开放型组织很有帮助。

服务型领导 Servant leadership

俗话说,政客想要当选,要么成人要么成事。这句谚语也适用于任何类型的领导人。有些领导人只想当指挥;虽然所有领导人都有野心,但对这类领导人来说,满足自己的野心才是首要目标,获得权力本身就是目的;一旦拥有权力,他们可能就无心利用权力来解决问题或建功立业。组织取得的任何成就对他们来说都像是个人的胜利。

相比之下,如果你是一名服务型领导者,你就会把自己的领导角色看作是为人民服务的一种手段。在政界,你会把公共服务看作是帮助公众的机会,而不是陈词滥调。作为一名服务型领导者,你会努力改善所领导的人的生活,并主要关注周围人的福祉。

服务型领导还很有感染力。通过关注你所领导的人的福利和发展,你正在培养下一代服务型领导。作为服务型领导者,你不喜欢独揽功劳。例如,当传奇棒球经理凯西·斯坦格尔(Casey Stengel)因赢得联赛冠军而受到祝贺时,他说了一句著名的话:"没有我的球员,我不可能做到这一点。”作为一名经理,他最伟大的技能之一就是最大限度地发挥每个球员的贡献,使整个球队受益。

沉稳型领导 Quiet leadership

过去几年,我们一直生活在名人CEO的时代。他们很容易识别:他们粗鲁、高调,不断宣传自己,好像他们知道所有问题的答案。他们试图主宰每一次互动,希望成为众人瞩目的焦点,并经常通过告诉别人该怎么做来发挥领导作用。爱丽丝·罗斯福·朗沃思(Alice Roosevelt Longworth)形容她的父亲、美国总统西奥多·罗斯福(Theodore Roosevelt)是一个“每次葬礼都想当尸体,每次婚礼都想当新娘,每次洗礼都想当婴儿”的人。罗斯福是一位卓有成效的领导者,他做了很多非凡的事情,比如创办美国国家公园管理局和修建巴拿马运河,但他并不沉默寡言。

相比之下,当你是一个沉稳型领导者时,你会以身作则。你不会纠结于问题,而是保持积极的态度,让行动说话。你专注于可以做到的事情。你通过解决问题和为团队树立榜样来发挥领导作用。面对突如其来的问题,沉稳型领导者不会把时间花在抱怨上,而是寻找解决方案并付诸实施。

开放型领导 Open leadership

作为服务型领导者,你要努力帮助组织成员成长为领导者。沉稳型领导者以身作则。服务型领导者和沉稳型领导者不会独断专行。开放型领导者兼具上述诸多特点。

开放型领导者也不是自上而下的专制领导者。作为一名开放型领导者,你的成功之道在于创建能够让团队茁壮成长的组织。换句话说,作为一名开放型领导者,根据《开放型组织定义》,你要创建一个框架或环境,让组织能够实现以下目标:

  • 更加敏捷:在开放式组织中,所有团队成员都清楚地了解组织的目标,因此可以更好地协同工作,实现这些目标。

  • 更快创新:在开放式组织中,无论想法来自何处,都会被听取(评审和争论)。领导者不会把想法强加给组织。

  • 更高参与度:由于组织成员可以参与组织方向的决策,因此他们对团队的目标有一种主人翁意识。

开放式组织将以下五大特征定义为开放式组织的基本原则:

  • 透明性:组织的决策过程是开放的,所有支持项目的资源也是开放的。团队从不对孤立做出的决定感到惊讶。
  • 包容性:所有团队成员都参与讨论和评审。制定规则和协议,确保所有观点都得到评审和尊重。
  • 适应性:不断要求并接受反馈意见。团队根据结果和投入不断调整未来的行动。
  • 协作性:团队成员从项目或任务一开始就一起工作。工作不是孤立地或各自为政地进行,然后再提交给团队其他成员征求意见。
  • 社区性:团队成员对组织如何运作有共同的价值观。团队领导以身作则,鼓励所有团队成员为团队做出贡献。

发挥领导风格的作用

作为一名开放型领导者,你如何才能兼具服务型领导和沉稳型领导的特点?

在开放式组织中,为了支持一个包容的社区,你要发挥导师的作用。正如服务型领导者会教导和培养未来的服务型领导者一样,你也必须身体力行,以身作则,确保透明度和协作性,并按照共同的价值观行事。

沉稳型领导者如何为开放型组织做出贡献?开放式组织往往很嘈杂,没有更好的词来形容。开放式组织中的交流与合作是持续不断的,有时会让不习惯这种交流与合作的人不知所措。开放式组织成员的主人翁意识可能导致争论不休、激情四射的讨论和分歧。

沉默寡言、积极乐观的领导者往往能从看似矛盾的观点中看到前进的道路。在这些讨论中,沉稳型领导者能够打破喧嚣。而作为开放式组织的镇定剂,安静型领导者可以帮助人们克服分歧,同时推动问题的解决。