公民开发者：现在人人都是工程师

# 公民开发者 来源：https://www.massdriver.cloud/blogs/the-citizen-developer 你可能还没听说过“公民开发者”这个术语，但他们确实存在，而且已经存在很久了。 九十年代，他们是应付账款部门里那些听信销售电话买了会计软件，然后“哎呀”，现在数据中心多了台戴尔服务器插在以太网口上的人。或者二十一世纪初，市场团队用Dreamweaver搭了几个网页，你得想办法把它们部署到IIS 5上。如今，他们是销售团队里下载Claude Code、搭建一个存储个人身份信息应用的人。同样的人，不同的手段。 你可能在想，这听起来像是影子IT。没错！它就是。这让全世界的首席信息安全官和IT人员都脊背发凉。 一旦被发现，团队往往将其视为一起安全事件。可能还会给那个只是利用自己的自主权推动业务前进的人……一点警告？ 这确实是一起安全事件。但它也是一个信号：人们有事要做，没时间等工程团队排期。而且这个趋势没有放缓。它也不是从AI开始的。Gartner在2021年，也就是ChatGPT发布之前，发现有41%的员工在IT部门之外创建技术或分析能力。五个人里就有两个，那还是在技术门槛很高的时候。而现在，天哪，变得太简单了。你公司里一半的人已经在绕开你们了。他们只是没告诉你。 ## 这些人是谁！？ 那个SDR（销售开发代表）申请了一个线索管理工具，看着它在待办事项梳理中搁浅，然后自己用一个下午搭了个简陋版本。他公司里有很多工程师。但没人为他工作，他的工单在优先级排序中永远赢不过路线图项目。 一家从未雇用过软件团队的地区保险公司的运营经理。二十年的机构知识都活在她的电子表格里，而第一次有了不用雇人就能将其转化为更强大工具的方法。她这样做并不违反IT政策。*这里根本没有IT政策。*从来没人想到她会需要它。 还有我们自己。后端开发搞前端。前端开发去研究Terraform。我不是Node专家，所以当我用Node时，*我*就是个公民开发者。我的联合创始人用Elixir时也是个公民开发者。一旦你走出自己的专业领域，你就是他们中的一员。 当我刚开始了解这个角色时，我认为区分“公民”开发者和“软件”开发者很重要，直到我意识到，当我们走出舒适区，试图做些重要的事情，推动业务前进，只是能力有所不逮时，我们所有人其实都是公民开发者。这种情况一直发生。这个行业里没有人持证上岗，每个人的专业知识都只覆盖了巨大领域中的一小片。这描述普通软件开发者的频率，可能比我们愿意承认的要高得多。 当我从DevOps/平台的角度深入思考这个角色时，从这个位置看，这两者也愈发相似。运维有需要人们自助使用的系统，而围绕这些系统的治理（安全、合规、成本）不在乎是谁在使用。从运维的角度看，公民开发者和专业开发者是一样的。他们都在向我们必须保持稳定的生产系统引入变更。*听起来我们像是在搞DevOps。* ## 你什么时候成为开发者的？ 你必须编写或理解多少软件，才能被授予这个头衔？没有执照要考。我是一名软件开发者，是因为我申请了一份工作并得到了它？因为我读完了一本书？一门课？一个计算机学位？一个带着徽章的训练营毕业生第一天就是开发者，而一个干了十五年但没有职位头衔的爱好者不是。这告诉你这个头衔实际衡量的东西，*什么也不衡量*。当一家公司同意称你为开发者时，你就成了一名软件开发者。 也许你是一名经验丰富的开发者。你亲手写每一行代码，是开发者。你用语言服务器写，仍然是开发者。你用自动补全写，仍然是开发者。Copilot写了一半，当然，还算。Claude写了全部，但你指定了每个行为并捕获了它的错误。在这个序列中，你从什么时候开始不再是开发者？没人能回答，因为问题从来不在于*代码*本身。 那么，那个SDR和高级开发人员实际上有什么共同点？他们都看到了业务需要的某个价值，认为它应该能通过某种界面实现自动化和交互，并努力将其变为现实。这就是工作的全部。只是其中一个人练习更多而已。专家和公民开发者之间存在一个渐变。我们划定界限是因为那样报酬更高。 ## 达成目标的手段 没有人在创业时想的是：“我等不及要雇佣四十个特别喜欢争论代码格式、花光我的运营预算在云支出上、派书呆子去拉斯维加斯领免费T恤的人。”他们创业是因为他们发现了一个想要解决的问题。软件是达成这个目标的手段。开发者是达成这个目标的手段。这一直如此，而我们的行业二十年来都客气地没有大声说出来。 看看软件在公司内部实际是如何被制造出来的。业务部门有个问题。问题等着产品经理。产品经理等着工程师。工程师等着运维。在这块层叠蛋糕中，每层都有阻碍，而且每层都人手不足、进度落后。三年前，位于最顶端的人只能等待。如今他们不再等待。他们打开Claude或其他什么工具，心想：“这不可能这么难。”于是，看哪，对他们来说确实不难。但对于你，稍后，当它落到你手里时？那就自求多福了。 而业务部门对此很满意。设身处地为CEO想想。有两个人能做出你需要的东西。一个现在就能做出来，可能有点粗糙，但粗糙可以修正。另一个想谈谈工匠精神，还有六个月的待办清单。这个决定大约只需要四秒钟。他们可以接受粗糙。 如果你对此感到冒犯，我理解。当年外包和无代码兴起时，也冒犯了很多人。业务部门从来不关心价值是如何被创造出来的。我们只是唯一能创造它的人，我们错误地把这种垄断地位当成了尊重。我们一直是达成目标的手段。目标属于业务部门。手段现在属于每个人。 ## 我们以前经历过 “但这种粗糙是危险的。”是的，它是。去年十月，研究人员扫描了5600个在生产环境中运行的“氛围编程”应用，发现了超过2000个漏洞，400个泄露的密钥，以及175个暴露个人数据的实例，包括医疗记录和银行账户号码。Moltbook在上线三天后，就通过客户端JavaScript中一个Supabase密钥泄露了150万个API令牌。粗糙会累积，任何曾经持有寻呼机的人都知道，一个四秒钟的决定如何让你两年后出现在事故电话会议上。事故电话已经开始响了。 这就是催生DevOps的那个问题。 开发者想比运维能安全处理的速度更快地交付，而业界最初的反应是阻止。工单、变更顾问委员会、高墙。这没用。开发者绕过了运维，就像公民开发者现在绕过所有人一样。DevOps最终承认，对于更快速度的构建者，答案应该是铺好的路，而不是更大的门。设计一条让快速通道和安全通道是同一条路的路径。今天，很多组织仍在为此挣扎，而现在，一种新型的构建者正向他们袭来，比开发者更快，直接将东西交付给用户，甚至从未接触过运维知道的服务器。而供应商们正在铺路。微软正在发布开源技能文件，将Claude Code和Copilot变成支持Fabric的代理，这样分析师就能用纯英语提出并查询企业数据工作负载。地球上最大的软件公司希望这类构建者更多，而不是更少。 所以，不，运维没有过时。相反，我要尽可能大声地主张它变得更加重要。三十年来，真正让公司安全的不是治理。**而是稀缺性。**只有少数人能创建软件，因此爆炸半径足够小，可以手动管理。这种稀缺性消失了。当组织里的每个人都能发布应用时，防护栏是唯一剩下的控制手段。DevOps刚刚成为这栋楼里最重要的工作，而大多数运维团队还不知道。框架们也不知道。云安全联盟（CSA）指出，没有主要的AI安全框架（NIST AI RMF、OWASP LLM Top 10、CSA自己的框架）为公民开发者在没有专业安全监督的情况下发布提供专门指导。制定标准的人还没跟上编写软件的人。 你无法阻止公民开发者，你的CEO也不想你阻止。你的工作是在整个公司以光速围绕你构建时，成为那些不可妥协事项（安全、成本、合规）的守护者。*既要让路，又要保持控制。* 但“构建防护栏”有个明显的问题：这些人不知道你是谁。他们不使用你的平台，不阅读你的文档，也不提交你的工单。他们中大多数人甚至不知道有个DevOps团队，他们的规则据说违反了。 那么，你如何治理一个根本不知道你存在的人？ ## 公民开发者不知道你的存在 旧的开发者自助服务模式仍然要求开发者知道铺好的路在哪里。学习平台、找到门户、使用正确的模块、遵循文档。 对于那个为了在午饭前解决一个问题而下载了一个代理的销售人员来说，这已经要求太多了。 但现在，在这个人和基础设施之间有了东西：代理。让运维出现在那里。 如果你的公司提供编程代理，就给这些代理一种公司特定的软件发布方式。它不必始于某个宏大的内部平台计划。给他们一条你能支持的简单路径：一个应用可以运行的地方，一种部署它们的方式，一种处理身份和密钥的方式，以及一个代理知道该停下来询问人类的节点。然后教导代理，当有人说“部署这个”时，在这里部署意味着什么。 销售人员不需要理解你的云账户、CI、网络、密钥管理或合规要求。他们不应该需要。代理可以知道该走哪条路，以及哪些东西它不能自己发明。 如果你已经有了一个平台，就把它暴露给代理，而不是期望新一代构建者去学习它。如果你没有，就从小处着手。一个带有公司指令、部署工作流和几个工具的代理，在你构建任何可以上平台工程路线图的东西之前，能帮你走很远。 这不是绝对的控制。一个决心使用个人笔记本电脑、个人账户和个人信用卡的人仍然可以创造影子IT。二十年前他们也能。但对于公司提供的工具和拥有的资源，安全路径最终可以存在于公民开发者已经在使用的工具内部。 他们不需要知道运维是谁。他们的代理知道。 ## 他们不会回头 你可能嘲笑这些人。你可能认为AI泡沫会破裂。也许会。但市场部的人现在已经发布了一个应用。那个一直活在电子表格里的分析师有了一个署着她名字的可用工具。一旦人们感受到这种力量，就不会再交回去，不管泡沫破不破。 公民开发者一直都在。只是工具将他们放大到无人能忽视的程度。 2009年，John Allspaw和Paul Hammond在Velocity大会上站在台前，对满屋子的工程师说，Flickr每天部署超过十次。一半的听众认为这太鲁莽。业界的回应是让部署变得足够安全，以至于数字不再重要：小的爆炸半径，快速的回滚，人人共享的工具。十七年后，这个数字又回来了，只不过现在每天十次部署来自销售部、理赔部、来自那个分析师。运维是这栋楼里唯一能让这个数字变得*枯燥*的团队。