浅谈程序员的职业操守

作者:吴欣蔚(蓄昂)     阿里大淘宝平台技术团队

《匠艺整洁之道》是鲍勃大叔的整洁系列新书。这本书主要从纪律、标准、操守三个方面阐述了软件从业者应该如何要求自己,提升研发质量、效率、道德水准,本文主要围绕《匠艺整洁之道》的第三部分 —— 操守,聊一聊我们程序员该如何自我约束、自我提升。

一、为什么程序员需要职业操守

1.1 行业的壮大

这个问题还得从软件行业的发展说起。 软件行业从诞生(1935)至今(2022),已经有八十多年历史了。





在这期间,整个软件行业有了巨大的发展:

  • 从业人员已经过亿

  • 计算机/电子设备的数量超过人类数量

  • 软件监控、协调着全社会的运转

大众对计算机及软件的认知,从早年的以机器为主,到现在以机器背后的程序员为主。早期《星际迷航》、《太空奥德赛》等以机器/计算机作为重要角色。 而随着个人计算机的出现,《黑客帝国》、《战争游戏》等电影逐渐以程序员作为救世主,程序员正脱去神秘的面纱,被社会所了解和接纳。

1.2 影响面扩大

作为程序员,我们虽然不是各种规则的制定者,但我们编写了运行这些规则的代码,并在全面监控和协调我们生活的机器中执行。换句话说:程序员们统治着这个世界。

我们编写的软件,记录着日程表、货物的运输、商品的交易,控制着汽车的方向盘、火箭卫星,甚至还能影响法律的颁布或执行。

因为软件出错而导致的惨剧,在各行各业都有案例:

  • 科研:地面软件出错,使用了错误的单位,导致火星气候探测者号在火星大气层中下降太深,被撕成了碎片。

  • 医疗:Therac-25 放射治疗机事故。由于进程冲突,Therac-25 的高能电子束导致3人丧生,还烧伤了另外3人。

  • 商业:因为用错标识符,遗留在系统中的死代码被激活,导致骑士资本集团在45分钟内损失了 4.6 亿美元。

  • 交通:丰田汽车的堆栈溢出漏洞,可能导致汽车加速失控,最终可能导致多达89人遇难。

总有一天,程序员们做的一些自认为无伤大雅的(蠢)事,可能就会导致成千上万的人死去。而这一天,也许就在明天。

当发生这些惨剧时,会有人需要为此负责,人们会要求程序员们说清楚如何防止这种错误再次发生。

因此,作为程序员的我们,亟需有明确的职业操守以进行自我约束,为的是让软件行业能有更大的发展,也为我们自己能有更好的职业发展。



思考:你是否有出现过故障,造成的最坏影响是什么?是否对社会造成了影响?



二、什么是职业操守?

2.1 职业操守的定义

WIKI 里对职业操守的定义是指人们在从事职业活动中必须遵从的最低道德底线和行业规范。

在职业活动中,有一些公认的职业操守,如:

  • 诚信的价值观

  • 诚实地制作工作报告

  • 不要泄密给竞争对手

同时,各个行业也有各自细分的职业操守,如:

  • 医生:救死扶伤,爱岗敬业

  • 魔术师:不公开魔术的秘密

  • 公安干警:重视调查研究,处理案件不捕风捉影,主观臆断

  • 法律工作者:忠于宪法和法律,坚持以事实为根据

  • 教师:为人师表,关爱学生

  • ...

在 《匠艺整洁之道》 里,鲍勃大叔提出了10条软件开发人员的职业操守。



2.2 软件开发人员的职业操守

以下摘自 《匠艺整洁之道》 :

  1. 为捍卫和维护计算机程序员职业的荣誉,我承诺,尽我的能力和判断力:

  2. 我不写有害的代码。

  3. 我生产的代码将永远是我最好的作品。 我不会故意让那些在行为或结构上有缺陷的代码累积起来。

  4. 我将在每次发布时提供快速、确定和可重复的证据,证明代码的每个元素都能正常工作。

  5. 我将经常进行小规模的发布,不妨碍其他人的进展。

  6. 我将无畏地、毫不留情地利用一切机会改进我的创作。我绝不让它变更差。

  7. 我将尽我所能尽可能地提高自己和他人的生产力。我不会做任何降低生产力的事。

  8. 我将一直确保其他人能够补上我的位置,我也能够为其他人补位。

  9. 我将给出在数量级和精确度上都靠谱的预估。我不会做出没有把握的承诺。

  10. 如果我的程序员同事拥有足够的操守、标准、纪律和技能,就能赢得我的尊重。任何其他的属性或特征都不会成为我尊重程序员同事的因素。

  11. 我永远不会停止学习和改进我的技艺。

三、程序员的职业操守

鲍勃大叔提出的这10条誓言可以分为三个类型: 伤害、集成、团队合作,我们针对这三个类型分别展开聊聊。

3.1 关于伤害

  1. 我不写有害的代码。

  2. 我生产的代码将永远是我最好的作品。 我不会故意让那些在行为或结构上有缺陷的代码累积起来。

  3. 我将在每次发布时提供快速、确定和可重复的证据,证明代码的每个元素都能正常工作。

3.1.1 何谓伤害

我们编写的软件每时每刻都在对这个社会产生影响。我们任何无意中的行为,都可能会给这个社会带来意想不到的伤害。

例如人们发现大众汽车公司的程序员写了一些代码,故意阻挠EPA排放测试,影响有关部门对环境危害的评估,损害了这些汽车驾驶地所有人的健康。

如果我们放任自己,就会对自己,或者身边的人,甚至整个社会造成危害,包括:

  • 对社会造成的伤害

  • 对你的同行造成的伤害

  • 对未来的程序员造成的伤害

  • 对功能/结构造成的伤害

3.1.2 直面伤害

上述大众汽车公司的程序员造成的危害 ,谁该为此负责?

作为程序员的我们,可能会这么说:"我只是在做我的工作,这不是我能控制得了的事情。"

但是,如果你明知道这么做会带来不好的后果但还继续这么做了,那你就需要为此后果承担一部分责任。请不要忘记,公司雇佣你作为软件开发工程师的重要理由之一,是你应该有能力识别出软件可能在什么情况下出问题,你需要在它产生麻烦之前找到它,并且有责任大声说出来。

避免伤害,尽力而为

思考:以下两种系统,哪个系统的价值更高?

  1. ​工作完美,但不可修改

  2. 不能正确地做任何事情,但却容易修改

上述的两个系统,分别体现了软件的两个价值:

  • 行为价值:让程序能够正确工作

  • 结构价值:让程序易于调整

一个软件系统如果无法被改变,即使它能够正确工作,最终也摆脱不了被淘汰的命运:





一个软件系统要想能够提供长期价值,它就必须能够响应需求的变化。因此,除了最紧急的情况之外(对人、对公司、对社会造成灾难的情况),我们应该优先选用第二种系统。 即使我们需要一点时间和金钱的投入,但在那之后,它就将可以永远继续工作。

坚持好结构,它与我们利益相关

为了能使软件能够提供长期价值,不对当下的同事、未来的同事造成伤害,就要求我们写出来的软件要有一个好的结构,一个好结构带来的价值有:

  • 容易测试

  • 容易修改

  • 容易重用

要写出一个好的结构,往往要花我们更多的时间。我们经常会遇到这样的场景:

一个紧急的需求过来,要求我们在指定时间内完成并上线,但这些时间往往只够我们完成需求,同时你的老板也要求你尽快完成这个紧急需求。如果是你,会如何应对这种情况呢?

首先要记住的一点是:一个项目/软件的成功,对我们的事业、声誉有着直接的影响,它与我们的利益息息相关。因此,作为利益关联者,我们对系统的开发和结构有发言权;同时,我们也是工程师,公司雇佣我们,是因为我们知道如何构建软件系统,如何搭建这些系统的结构,并使其能够提供长期价值,我们需要确保系统不会因为坏行为和坏结构而遭到破坏。

回过头再来看这个问题,我们的老板了解结构吗?或者老板的理解仅限于行为吗?如果老板明确告诉你不要理会结构,应完全关注行为,我们该怎么办?

我们得拒绝,因为我们是工程师,是利益相关者。也许会有争斗、对抗,但我们的专业不允许我们退缩。也许你认为拒绝就会被解雇,但大多数情况下不会。因为大多数经理也期望为他们需要和相信的东西而奋斗,而且他们尊重那些愿意做同样事情的人(否则还会有那么多的技术沙龙、技术分享交流会吗?)。

3.2 关于集成

  1. 我将经常进行小规模的发布,不妨碍其他人的进展。

  2. 我将无畏地、毫不留情地利用一切机会改进我的创作。我绝不让它变更差。

  3. 我将尽我所能尽可能地提高自己和他人的生产力。我不会做任何降低生产力的事。

3.2.1 为什么需要关注集成

软件上的并发是指:同一时间可能有多个用户对同一数据进行读写操作。

软件的集成,也一样存在并发。当我们的项目不断变得复杂、庞大, 参与这个项目的开发人员变多的时候,每个人同时都在改动着各自的功能模块,软件集成冲突的问题会越来越突出,最终会成为瓶颈。

漫长的(集成)周期阻碍了团队的进步。因此,我们需要关注集成,关注它的周期。它与迭代有关,它与编辑/编译/测试周期有关。只有提升这些步骤的效率,我们才不会阻碍别人的进度、团队的进步。

3.2.2 持续集成

软件行业经过这么多年的发展,已经有了不少解决方案。其中,持续集成就是一个很好的手段。

持续集成能够带来以下好处:

  • 快速发现错误

  • 防止分支大幅度偏离主干

持续集成并不能让我们消除Bug,但是能让它们非常容易被发现和改正;它可以让我们的软件在快速迭代的同时,仍能保持高质量,不阻碍别人的进度。

3.2.3 随机善意行为

鲍勃大叔在《代码整洁之道》里提到过的童子军军规: 代码签入时要比签出时更整洁。

如果每次代码签入时,代码都比签出时干净,那么代码就不会腐坏。我们可以通过在每次检查代码时,对其进行随机善意行为来做到。任何善意的行为,无论多么微小,都不会被浪费。

我们可以通过增加测试的覆盖率(但不应该变为管理指标),来协助我们改进代码,协助我们写出更加健壮的代码。

另一个有效的随机善意行为是简单的清理--以改进为目的的重构。我们可以从一些简单的手段入手,如:

  • 优化字段的命名,让代码可读性更强

  • 清理无用代码,减少理解成本

  • 调整代码结构,保持代码的灵活性

3.3 关于团队合作

  1. 我将一直确保其他人能够补上我的位置,我也能够为其他人补位。

  2. 我将给出在数量级和精确度上都靠谱的预估。我不会做出没有把握的承诺。

  3. 如果我的程序员同事拥有足够的操守、标准、纪律和技能,就能赢得我的尊重。任何其他的属性或特征都不会成为我尊重程序员同事的因素。

  4. 我永远不会停止学习和改进我的技艺。

上述几点主要是关于团队合作相关的誓言,总结起来主要为以下几点:

  1. 有团队精神,能够被补位,避免团队因知识断层而陷入瘫痪;

  2. 诚实合理地预估,不轻易承诺;

  3. 只尊重职业技能、纪律、标准和操守,不因其他因素彼此歧视;

  4. 永不停止学习,跟上行业的变化是对职业的尊重,也是对自己的事业负责。

3.3.1 诚实合理地预估,不轻易承诺

系一次鞋带需要多久? 也许你可以很快地说出:20秒左右。因为系鞋带这件事几乎天天都在做,你可以相当快速、准确地给出合理的预估。

那如果要你写一个系鞋带的教程,需要多久?你是否没有办法快速准确地做出一个预估?你需要考虑这个教程的受众、是否需要图文并茂、篇幅限制 ……

这正是我们作为程序员经常会遇到的问题:预估工时。 我们面临的用户可能都是计算机新手,他们对软件可能一窍不通,我们必须要写出使用要足够简单软件,并拥有足够详细的使用说明……

当一位经理来找你说:“我在星期二之前需要这个。” 你被这个问题困住了,因为你不知道你是否能在星期二之前完成这件事。也许你做过类似的事情,花个两三天就搞定了;也许这里面藏着一个跟你之前做过的都不一样的技术难点,你不知道能否按时完成。

所以当你被要求估计某件事时,你不能给出一个具体的时间,因为那是谎言,你不知道你是否能够在特定的时间完成它,你需要考虑到最好和最坏的情况。如果你确实给了一个精确的时间,那最好能咬牙完成它。因为你在做出承诺,所以你最好准时完成它,不要有任何借口。

要给出一个合理的预估,可以这么做:

  • 不要轻易给出一个具体时间,诚实地保持诚实

  • 对项目的预估不能只是一个交付日期,而是一个时间范围

    • 进行工作项拆解,找出隐藏在里面的模糊因子(不确定因素)

    • 与经理交流,花更多时间细化模糊因子,如此来回递归式操作

  • 针对最好情况、最坏情况、普通情况,分别估计其可能发生的概率,再针对这3种情况预估日期范围

3.3.2 永不停止学习

我们所处的行业在过去几十年,经历了快速变化,而且这个变化还在持续,我们必须跟上。这就意味着我们必须持续学习,持续阅读图书、博客、参加技术交流会等等。我们的雇主没有责任培训我们,我们需要对自己的事业负责。学习是自己的事,我们要弄清楚该学什么,花多少时间学。因此,除了工作时间之外,每周投入10~20小时的时间来培养和维护我们的事业吧,这是保持我们专业性的合理做法。

四、写在最后

“The simplest way to describe craftsmanship is pride of workmanship. It is the mindset that you are working on something important and you are going to do it well."

程序员是一个技术含量很高的职业,但也必须受非技术概念的约束(标准和道德规范)。只有通过这些标准和道德规范的约束,才会让我们这个行业越走越好。它约束我们的行为,对我们提出更高的要求,在提升我们竞争力的同时,也会给我们带来更多的成就感。

让我们一起尽力的努力做到最好,做一个有『良知』的程序员!

相关推荐

阿里巴巴 12 篇论文入选全球系统顶会 ATC 2026(内附下载)

2026 ATC 会议中,阿里巴巴以12篇论文录用数居全球企业首位。研究聚焦大模型服务与Agent基础设施、云资源调度、安全计算等关键瓶颈,提出CacheFS(P2P权重缓存)、Axon(异步KV感知调度)、Chorus(GPU-CPU协同解码)等创新系统,显著提升推理效率与资源利用率。论文基于真实生产数据,推动系统优化从理论走向落地,彰显中国产业界在计算机系统领域的前沿影响力。

阿里技术 270

Personal Agent 对比分析及未来技术发展趋势

近期,Personal Agent赛道迅速升温,大厂与独角兽密集发布新品。从Anthropic的Claude Tag、SpaceXAI的Grok Bot,到Meta的Muse、OpenAI的Dots等,均聚焦个人用户场景,强调“数字同事”与个性化服务。相比早期Agent多用于开发或企业协作,新版本更注重跨平台集成、主动任务执行与用户情感连接。技术上,其核心差异在于更强的自主决策能力、长期记忆与多模态交互。这标志着Agent正从工具向“智能代理”演进,预示着人机协同的新范式。

阿里技术 109

高分智能体为何反而更脆弱?阿里 Token Foundry 揭示「协同进化陷阱」,提出 CODA 可靠性评测协议

本文揭示智能体在技能—策略协同进化中存在“协同进化陷阱”:尽管训练阶段分数持续提升,但模型对特定技能库依赖加深,导致部署后技能变化时性能显著下降。阿里巴巴团队提出可靠性评测协议CODA,引入一致率、抗干扰率与最差成功率等指标,系统评估模型在技能漂移下的稳定性。实验表明,原始增益52%–93%被抵消,凸显当前评测仅关注峰值成绩的局限性。研究呼吁从“追求高分”转向“保障可靠”,推动智能体在动态环境中持续可信运行。

阿里技术 350

手把手带工程同学从零实现一个完整的 LLM(CS336)——Transformer 篇

本文是学习斯坦福CS336课程的首篇笔记,从零构建MLP入手,逐步理解神经网络训练原理。通过线性回归与非线性拟合实验,揭示损失函数、梯度下降与激活函数的作用。文章以手搓MLP为例,为后续实现带RoPE、SwiGLU的Transformer打下基础,强调深入理解LLM底层机制对Agent开发的重要性。

阿里技术 280

深度解析 RSI:当 AI 开始实现自我迭代提升

2026年,RSI(递归自我改进)因Anthropic与多位AI巨头论文引爆热议。其核心是AI自主优化自身,形成正反馈循环,理论上可催生智能爆炸与超级智能。虽严格意义上的RSI仍存挑战,但广义上已涵盖自进化、持续学习等技术。从人工编码到AI自主开发,研发效率呈指数提升。尽管RSI非实现AGI/ASI的唯一路径,也未必必然引发智能爆炸,但其作为“如何达成智能跃迁”的关键机制,正推动AI进入自我迭代新阶段。

阿里技术 403

清华×阿里 AI Native人才培养计划暨格造社启动日活动举行

10月15日,清华大学无穹书院与阿里巴巴联合启动“格造社AI开源俱乐部”,以“从好奇到创造”为主题,发布近40个涵盖算力、模型与公益创新的AI真实课题。通过校企协同、开源共享与项目实践,学生将在导师指导下开展选题、开发与验证,成果将开源发布于魔搭社区,推动技术转化与创新成长。活动还配套开展多场工作坊,助力AI Native人才培养。

阿里技术 153

从榜单走向真实业务负载:Kernel Agent 刷新 Qwen3.8-Max 核心推理算子性能

Kernel Agent 的公开研究已经表明,Agent 可以在标准题目上生成并优化 GPU Kernel;AKA 这次把问题推进到了生产契约:面对 Qwen3.8-Max 的真实关键算子、复杂调度约束,以及专家已经深度优化过的实现,Agent 仍然找到了新的执行路径,并在三条独立算子线的几何平均时延上全部低于专家版本。AKA 将反馈、设计和生产验证组织成一个可以持续运行的闭环,把专家经验之外的结构维度纳入搜索,也把一次性能突破沉淀为下一次优化的系统能力。

阿里技术 188

代码生成越来越快,软件交付真正的瓶颈转向了哪里?

2026年云栖大会,阿里巴巴探讨AI Native研发范式转型。嘉宾指出,尽管代码生成提速,但交付瓶颈已转向需求明确、上下文连续、环境复现与验证机制等环节。许晓斌强调需构建完整工程系统支撑Agent生产落地;李英各提出“统一上下文+验证”降低协作成本;黄挺揭示基础设施正从服务人转向服务Agent;陈烨主张将AI前置至需求入口重构流程;彭鑫以“可驾驭性”界定AI边界;李亚洲则警示个人效率提升不等于团队效能跃迁。最终,《AI Native研发实践手册》发布,推动研发从“辅助编码”迈向“系统重构”。

阿里技术 157

《AI Native 研发范式实践手册》重磅发布

在云栖大会发布的《AI Native 研发范式实践手册》揭示了AI研发从“辅助编码”迈向“自主交付”的关键转折。随着MCP协议、Agent Harness框架及多模型协同的成熟,行业进入Agentic时代。阿里巴巴通过AIDC数字投手、千问用增Agent等实践,探索企业级AI研发基础设施建设,聚焦环境验证、知识沉淀、组织变革三大挑战,推动Agent实现从写代码到可靠交付的跃迁,构建覆盖工具链、安全管控与可观测性的系统化工程体系。

阿里技术 954

当 AI 开始真正“做事”,基础设施准备好了吗?

Agent 可以写代码、修改配置并提交变更,但“任务已完成”不能只由 Agent 自己判断。代码进入生产之前,仍然需要稳定、准确、可追溯的评审机制。

阿里技术 267

把「达标判定」从大模型手里收回来:Graph Engineering实践

回看整个 Agent 的演进过程,模型换过,编排的流程换过,Agent 合过也拆过,但工程方向始终一致:我们在不断地减少模型的自主权,把可被代码验证的确定性决策,从模型侧逐项收回到控制面。首先是把「达标判断」从模型手里收回:给予客观的评测手段,并在评测里加入对侧样本,防止过度优化走向过拟合。其次是把「核心目标」给模型解释清楚:先理清楚优化的最终目标是什么,可以从什么方向进行优化,要解决的是过拟合还是无效优化。才能保证模型的方向不会跑偏。

阿里技术 276

垂类业务如何落地生产级 Agent

在AI技术快速迭代背景下,AI Agent从概念走向生产需跨越稳定性、可控性、可审计性与业务闭环四道关。尽管工具链与模型能力成熟带来窗口期,但真实业务中复杂场景与风险要求系统化工程支撑。企业应聚焦“大模型+工具+循环”核心范式,以标准化协议与可复现流程实现从“能跑”到“能产”的跃迁,把握垂类落地先机。

阿里技术 144

5 人 7 天干完 20 人数周的活:Spec-Driven Development 如何重新定义 AI 编程

5人7天用Qoder完成传统需20人数周的工作,核心在于Spec-Driven Development(SDD)。通过Day 0精心撰写可验证、有边界、带约束的Spec,将“WHAT”明确化,让AI高效执行“HOW”。SDD以spec.md为唯一真实来源,辅以plan.md与tasks.md拆解任务,constitution.md固化原则,实现人机协同、并行开发与自举迭代。其本质是:在AI时代,代码只是思考的副产品,而规范才是工程的锚点。

阿里技术 234

AI Agent 应用精细化评测:评测体系设计与工程实践

本文构建了一套面向AI Agent的精细化评测体系,突破传统粗粒度评估局限,从感知、规划、记忆、工具四大模块入手,实现“质量×成本×性能”三维量化。通过模块级拆解与端到端结合,支持根因定位、幻觉检测与多轮交互评估,结合自动化数据集映射与埋点采集,打造可持续、可追溯的评测基础设施,助力Agent高效迭代与生产落地。

阿里技术 440

zg 正式开源:本地检索,不止于关键词

<think>我们根据文章内容写一段≤150字的摘要。文章主要介绍zg(zvec-grep)本地优先检索工具,解决人和Agent在本地文件中查找信息困难,结合向量检索、BM25和rg,提供语义检索、精确匹配,支持CLI/MCP,本地优先,多语言格式。摘要需简洁,涵盖核心要点。字数限制严格。输出摘要即可。</think>zg(zvec-grep)是面向人与 Agent 的本地优先检索基础设施,结合 Zvec 向量检索、BM25 与 ripgrep,实现从语义探索、相关性排序到精确验证的全流程检索。它支持多种代

阿里技术 493

Agent 终章(Harness 成本篇):一次百炼账单降低 88% 实战

回头看,成本优化并不是一套外挂式的 Token 优化技巧,它们就是 Harness 实践。模型只负责生成,Harness 决定哪些内容要发、哪些过程要隔离、什么时候该停,以及这次任务应该用什么模型,最终怎么高效完成这个 prompt。Agent Loop 的成本本身也没有什么单一解法。前缀少一点、缓存多命中一点、探索少带回来一点、无效轮次少跑一次,单看都不惊人;但这些开销会在每一轮、每一次任务里重复,最后的差距就是这样乘出来的。这就是开头提示写出一个能跑的 Agent 很容易。

阿里技术 232

阿里巴巴 12 篇论文入选全球网络顶会 SIGCOMM 2026(内附下载)

在网计算将集合通信卸载到网络交换机进行,可以压缩流量,进而加速传输过程。在网计算系统的构成通常包括交换机、网卡、协议栈、通信库、网络管理器;但是在开放以太网生态中,上述组件分属不同的供应商或者开发者,彼此之间存在依赖。以太网生态的的供应商和开发者在自己的功能范围内无法实现整体的系统;在单独一个生态位实现自己功能而缺乏其他厂商配合的情况下,其研发投入无法体现为系统级别的加速能力,造成低效的投入回报比。

阿里技术 483

Harness 工程之道:Skill 原理与最佳实践

Agent Skills 是一种轻量、开放的能力扩展规范,用于为 AI Agent 扩展专业知识和工作流。本文从概念原理出发,结合真实的工程化项目 trade-ab-skill,系统性地讲解 Skill 的结构规范、触发机制、作用域优先级,以及最佳实践。(文章内容基于作者个人技术实践与独立思考,旨在分享经验,仅代表个人观点。

阿里技术 320

Agent 越改越乱之后,我用评测和轨迹把它拉回来了

如果你也在反复手改 agent 的 skill、打地鼠似的顾此失彼,不妨试试让这件事跑起来:让 agent 完成任务的能力,沿着评测结果自己进化。参考资料:《别让大模型"想太多":SKILL 开发中的语义陷阱与抗幻觉设计》

阿里技术 369

Qoder CLI 上运行 Qwen3.8-Max:5 个硬核任务实测

这次评测开始前,我们关心的问题是:在单轮提示词驱动下,这些模型能不能独立跑完数小时量级的工程任务。实际上五个任务中,所有模型均独立走完了全程,没有一家中途失控。真正需要关注的问题是,在没有人规定「好」是什么的空白处,模型只能依靠自己的标准决定做到什么程度才算完成。这一代模型+Harness之间比的,已经不是能不能达到要求,而是在无人要求时,它对自己的要求是什么。最后是本文全部结论共同的边界:每个任务均为单次运行,小分差不构成排名依据;

阿里技术 379

连续五天登上 GitHub Trending 首页的思考

现在是做开源最好的时代。AI 把那些原本吃掉维护者大量时间的重复性工作(Issue 分类、代码评审、测试编写、发版……)自动化了。一个小团队甚至一个人,就能撑起过去十人团队的节奏。门槛降低了,但上限没降——省下来的时间用在真正需要判断力的地方:定方向、做决策、经营社区。几个我觉得最重要的认知:**别开源一个 demo。**AI 时代做 0-1 太容易了,社区不缺 demo,缺的是经过验证的方案。你的“判决书”越硬(生产数据、benchmark、真实用户规模),别人帮你传播的时候底气就越足。

阿里技术 467

从 Agent Flow 到 AI Native:为什么通用 Agent 是“饮鸩止渴”

我最近一直在做一个“小玩具”:Agent Flow。最初的目的很明确,就是想在某些特定场景和受众群里,取代现有的 Agent Skill。这个 Flow 本质上是传统 Flow 的强化,但它的核心不是让用户理解节点、连线和 JSON,是让用户用自然语言描述目标,然后让 LLM 去理解目标、生成 Flow、修改 Flow、运行 Flow。Flow 本身的重要性也降级了,它只是一个编排层,不对 Node 和细节负责,只负责链路控制、任务下发和结果回收,具体的任务由 Node 负责。

阿里技术 361

NL2SQL 在超大规模数仓场景的架构突破与工程实践

本文介绍了高德数据团队基于QoderWork Agent Skill构建的NL2SQL智能取数系统从V1到V2的架构演进。V1采用分域独立Skill设计,验证了LLM在企业数仓场景生成准确SQL的可行性,但暴露了用户选择成本高、Skill间路由困难等5个结构性问题。V2通过统一Skill+确定性两级路由的四层架构(域路由层、知识加载层、标准工作流层、公共服务层)实现智能路由和渐进式知识加载,解决了V1的域间冲突问题。文章重点分享了架构设计思路、知识工程方法论和实践中提炼的设计原则,为类似企业数仓的NL2SQ

阿里技术 489

分解一座冰山:后端系统「AI 知识库体系」建设实践(长文干货)

本文探讨了如何让AI在复杂后端系统中正确行动,指出仅靠代码可读性和文档完整性无法解决关键问题——AI缺乏系统全局认知。作者强调技术方案设计是AI Coding的核心环节,其质量直接影响执行正确性。文章提出需构建结构化知识库,贯穿需求理解、影响分析、方案设计、编码执行等全流程,将分散的系统知识显式化,包括架构、依赖关系、业务约束等,帮助AI获得准确上下文。特别指出业务概念与技术实现的映射、变更红线规则等关键知识,并强调知识库需要持续闭环更新,避免成为过期文档。最终目标是让AI从代码协作者进化为能自主判断的工程

阿里技术 690

阿里开源 skill-up:让 Agent Skill 可评测可回归

摘要: 阿里巴巴开源了Agent Skill评测框架skill-up,旨在解决AI技能开发中的质量验证难题。该框架通过声明式YAML配置支持多引擎测试,提供expect+judge分层判定机制,降低LLM抖动对CI的影响。核心设计包括:1) 声明式评测配置,提升可读性;2) 分层判定策略优化资源消耗;3) 多引擎适配能力;4) 结构化报告输出,支持CI集成。skill-up特别强化了多轮对话测试,可验证复杂交互场景下的技能表现,如危险操作确认流程。项目已开源并应用于阿里内部,帮助开发者确保技能迭代的可靠性和

阿里技术 676

面向复杂业务场景的智能分析 Skills 架构设计与演进实践

本文复盘了一个面向本地生活业务的分析类AI Skill的架构演进过程。面对数十个行业复杂的经营框架和指标体系,团队经历了三次重构:从V1过度工程化的分层解耦架构,到V2采用知识收拢与按需加载,最终在V3实现稳定知识与时效知识的分离。这一过程提炼出六条Skill设计原则:1)知识组织应服务于模型的推理需求而非工程规范;2)按变更频率分层管理知识;3)动态路由实现按需加载;4)写入与读取采用不同粒度;5)保持核心知识文件的轻量化;6)通过分层加载平衡维护效率与token经济性。该案例为处理领域知识密集型AI应用

阿里技术 472

阿里荣膺 ACL 2026 最佳资源论文 | HSCodeComp 揭开智能体「分层规则应用」的能力鸿沟

先从任务本身说起。HS Code(Harmonized System Code,商品名称及编码协调制度)是支撑全球每年约 26 万亿美元贸易的商品"唯一数字身份证"。每一笔跨境货物通关都必须申报 HS Code,它直接决F f f F f定了超过所有跨境商品的关税计算和合规性,跨境商品的编码如果报错,轻则多缴关税,重则触发合规风险和货运延误。如下图1所示,在阿里巴巴跨境电商海关商品编码(HS Code)场景中,该专家级任务需要将商品沿着人类专家编写的规则树逐层向下推导、精确归类到唯一国际通用编码上。

阿里技术 415

从 Coder 到 Designer :电商团队数据研发的 Harness Engineering 实践

本文介绍了AI Data团队在数据研发效率提升方面的实践,重点通过知识工程和Harness Engineering架构设计解决NL2SQL转化中的核心问题。团队构建了语义层基础设施,采用Multi-Agent协作框架,将数据研发经验结构化并形成标准化流程,实现从自然语言到SQL的精准转化。方案通过三层质量保障体系和闭环知识管理机制,确保AI在复杂任务中稳定运行并持续积累经验。目前该方案已在大促场景落地,显著提升了NL2SQL的研发效率和质量。

阿里技术 129

一个小模型意图识别系统的 5 天进化实录|支付宝618

本文摘要: 支付宝618大促中,团队探索了AI在电商优惠场景的两种交互模式:一期基于推荐逻辑的"AI找优惠",二期升级为对话式交互。作者负责意图识别模块,将用户自然语言转化为结构化查询。面对模型选型的时间压力,团队快速评估了Qwen3系列模型,最终基于性能、成本和准确率平衡选择了Qwen3-14B。文章详细记录了从业务需求分析到技术方案落地的完整决策过程,为AI产品化提供了实战参考。

阿里技术 206

为什么 Agent 时代,大家都在做 CLI ?

AI时代的CLI复兴:从人类友好到Agent友好的范式转变 随着AI Agent的崛起,命令行界面(CLI)正经历一场复兴。本文探讨了人机交互从CLI到GUI,再到Agentic CLI的发展历程,指出CLI因其文本输入输出特性、自描述性、Unix哲学组合能力等优势,成为AI Agent操作数字世界的高效入口。文章提出未来产品设计需兼顾人类和Agent需求,分为完全面向人、完全面向Agent和人机协作三层架构,并强调"AI友好"应具备可调用、可理解、可组合、可恢复四大特征。CLI与MCP、SKILL共同构成

阿里技术 169
上一篇: 瓴羊,从阿里最佳实践到社会化服务
下一篇: 6年技术迭代,阿里全球化出海&合规的挑战和探索
阿里技术
阿里技术 阿里技术官方账号 阿里技术官方账号
博客等级 码龄5年 5210粉丝 280原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值