别再写代码了 程序员到超级个体的升级

我刚入行时，在一个七八人的小团队里做初级程序员。上班第一天，打开电脑、搭好环境，项目经理丢过来一个功能点；架构师说：“参考老功能A，换个数据源，写个新接口。”于是我去读A的代码，照着写，测一遍，提 PR；架构师指出几处问题，我改完再测，汇报完就结束了。

后来我把同样的需求丢给AI，它几乎原样走完了同一套流程：读代码、写接口、测试、根据反馈修改，直到通过。不是它突然变得无所不能，而是“读老代码、改数据源、写接口、测试、提PR”这一整套初级循环，已经可以被稳定地交给它。于是一个问题自然出现：AI是不是已经能替代刚入职的我了？

更值得追问的，其实是：我们每天真正在干什么？

一个典型的开发流程大致是：客户提出需求，项目经理整理功能，架构师设计实现，程序员写代码。对应到软件工程里，就是需求、功能、架构、代码四个阶段。前两个偏业务，后两个是实现。

把时间摊开看，实现阶段通常最耗时——做一个项目做了两年，可能有一年半都在写代码。程序员也往往是团队里人数最多的人。原因很简单：把一个已经明确的功能变成可运行的代码，需要大量具体、重复、需要小心翼翼的工作。

但现在情况变了。以前写几周的原型，现在几个小时就能完成；以前一两年的系统重构，现在也许几周就能推进完。当写代码的边际成本被大幅压低之后，“AI会不会取代我们”这个问题，和十年前“更便宜的团队会不会取代我们”其实是同一类问题——本质都是成本。真正值得问的不是会不会被取代，而是：当实现不再那么稀缺时，程序员应该把自己放在流程的哪一层。

过去几十年，团队其实一直在想办法harness程序员。需求文档告诉你做什么，业务文档帮你理解背景，系统文档、Dev Log、代码规范、Code Review、自动化测试和Sprint，告诉你怎么做、怎么验证、这一轮该完成什么。

这些约束不是为了限制人，而是为了减少出错和返工，让交付更稳定。用现在流行的话说，敏捷/Scrum就是给程序员做了一套Harness：保证交付质量始终优秀。

这正是我最喜欢、也最不喜欢敏捷的一点。好的一面是质量可控；不好的一面是，它很强调“程序员写代码”这一层价值——周边都准备好了，你只要一心扑在写代码上。价值被关在“只写代码”的笼子里，程序员就变得好替代。十年前替代你的未必是AI，但可以是更便宜的团队；今天，AI也能走进同一条路径。

那价值就在走出只写代码，往流程上游走。

超级个体要做更多、实现更多价值——听起来很对。但我有一句听起来奇怪的话：要做得更多，首先要做得更少。

更少，是指不要把自己埋在每天写代码、每天debug里。只有从这些循环里解放出来，才有时间去做更多事。这件事现在之所以可能，是因为AI可以成为我们的分身。

做法并不神秘：把原来harness程序员的那套系统，对象换成Coding Agent。给它Goal（最终要达到什么效果），Context和Knowledge（它在做什么、背景是什么），Memory（可复用的记忆），Roadmap（怎么拆、怎么推进），Rules（怎么写、什么不能碰），再加上 Review和Testing。这些和需求文档、规范、评审、测试，其实是同一类东西——不是每次都重新描述一遍需求，而是建立一套可复用的约束方式，让它在你的规则下工作。

这套方式一旦固定下来，就不再是临时的提示，而是你自己的系统。

还可以推得更远。不要只有一个Coding Agent：可以有PM Agent设定目标、验证结果、管理上下游；有Review Agent保障交付；有QA Agent去做测试。一个人背后，可以是一个小团队。你想让AI有什么样的产出，取决于你怎么对待它——如果你希望它像人一样当程序员，就要像对待人类程序员一样，给它完整的环境。环境决定产出。

超级个体的关键，不在于一个人能写多少代码，而在于他是否拥有一套可复用的系统。有了这套系统，以前需要团队分工才能完成的闭环——理解问题、拆解任务、实现、验证、根据反馈调整——就可以被压缩到个人可控的范围内。系统不是效率技巧，而是身份转变的前提：它让一个人不再把自己主要放在“执行实现”的位置上，而是放在“定义问题并让系统落地”的位置上。

当Harness接走了日常实现，人就可以往上挪一步：先到架构。

架构决定系统跑得快不快、以后改起来痛不痛。解耦、清晰的边界、明显的报错、好测的结构，都会约束后续的代码。它需要年累月的积累。但AI让这一层也变得不一样了——可以很快做出原型，迁移或改进时也能给出多种方案，试错成本变低。你甚至可以把“试架构、打磨架构”也纳入自己的体系。

不过要注意：架构和代码贴得很近，它们仍然属于实现层面。好的架构能让代码写得更顺，但它回答不了「这个功能到底该不该做、做成什么样才真正解决问题」。

站得更高之后，目光应该落到业务和需求。

很多时候，客户手里只有一张随手画的草图，而我们要交付的是一整套系统。需求，就是客户真实世界与软件之间的桥梁——把一个想法、一个概念，翻译成能在真实业务里运转的系统。这是软件最美妙的地方。

传统咨询链条里，客户对着项目负责人，再经 BA、开发经理、架构师，最后才到程序员。一层层翻译下来，到我们手里往往只剩一份文档：“按这个写功能。”很长时间里，程序员很少有机会真正接触业务场景本身；时间上，这一步也不占大头。大部分精力都花在了实现上，身份也因此被定在了“实现者”上。

现在有条件反过来。当实现成本被系统和AI压下来之后，程序员可以带着工程视角直接和客户谈，这也是盛安德一直强调的「程序员直接面对客户」，而现在有系统撑腰时，这件事变得更加简单和重要。你看到的不只是功能点，而是业务场景：系统边界在哪里、什么地方容易随规模变复杂、什么改动以后会很痛、什么信息值得结构化、什么流程其实可以简化。程序员看业务，和纯业务人员看业务不一样；好的拆解本身就会让后面的架构和代码更干净。

这不只是多了一项技能，而是身份的转变：从主要负责实现的人，变成用系统杠杆去定义和拆解业务问题、并让它落地的人。以前这一步很少被程序员碰到；现在它应该成为主要工作，而不是有空再参与。

AI擅长解决问题；定义问题，必须是人来做。

AI还很年轻，变化也快。去年我们还在说Prompt Engineering、RAG、Coding Rules；现在更多人谈的是 Harness、Agent Workflow。名词每个月都会冒出来，但本质没变——都是在学习怎么更稳定、更可控地使用模型。模型在变聪明，真正决定你能不能把它用进开发流程的，是你在模型外面搭的那套系统。

全球做AI的人里，绝大多数并不是在训练模型，而是在 harness模型：怎么从已有模型里拿到你想要的结果，怎么让它融入日常工作。Claude Code、Codex 这类产品的演进，与其说只是模型的进化，不如说是harness 与运用方式的进化。

正因为用法还在快速变化，一套属于自己的、可复用的系统反而更有价值。需求、功能、架构、代码——每一步都可以长成系统：Coding Agent帮你写代码，架构体系帮你试设计，甚至在分析功能、理解客户诉求时，也可以有自己的方法撑着。系统支撑起咨询，咨询又反过来检验和打磨系统，这才是可持续的。解决问题，和解决问题的方法，一样有价值——系统本身就是价值。

我说“别再写代码了”，不是要你立刻把键盘扔掉，而是希望你先在脑子里转个弯：如果不想把写代码当成主要工作，该如何让系统去写？该如何设计问题、定义问题？究竟想解决的是什么？

当你开始这样想，角色就变了。你不再只是每天实践代码、解决问题的人——因为AI也在做这件事。你要守住的是定义问题。少做机械的事，才能多做真正有用的事；一个人有限的时间里，若有系统替你承担更多角色，你就可以代表一个团队。这才是超级个体。

每个人都可以按自己的习惯设计一套系统。写代码不再稀缺的时候，真正稀缺的是：能把问题看明白，并且用自己的方法稳稳落地的能力。

所以我倡议别再写代码了。多想一想：如何通过少写代码，去做更多的事。