从全栈开发到真实系统

我以前介绍自己，最容易说的一句话是：我是一个全栈开发。

这句话当然没错。2008 年开始写程序，那时候很多小团队里并没有那么清楚的岗位边界。前端要写，后端要写，数据库要管，服务器要部署，客户说不清楚需求的时候也要去问。那时候不叫全栈，可能只是“美工也会一点、程序也会一点、电脑坏了也能看看”的那种人。

但到现在，如果还只用“全栈开发”来介绍自己，我会觉得不太准确。

不是因为这个词不够高级，而是因为它只能描述我会用什么工具，不能描述我现在真正处理的是什么问题。

技术只是入口

在真实公司里，很多问题看起来是技术问题，拆开以后往往不是。

一个按钮点了没反应，可能不是前端 bug，而是权限、状态机、审批流程、业务口径和历史数据一起纠缠出来的结果。一个结算单算不对，可能不是公式写错，而是业务规则从来没有被稳定地表达过。一个系统上线后不好用，可能不是界面丑，而是流程本身就绕，责任边界也不清楚。

这些问题最后也许都要落到代码上，但代码只是最后的表达形式。

真正困难的部分，是把事情问清楚：这个流程为什么存在？谁在什么情况下可以改？改了以后影响谁？异常数据怎么处理？旧数据算不算历史事实？系统应该忠实记录混乱，还是应该强行规范混乱？

这些问题如果不先回答，写再多代码也只是在把混乱固化到数据库里。

这几年我越来越多地站在“系统运转”的角度看问题。

这里的系统不只是软件系统，也包括组织系统、流程系统、权限系统、知识系统。一个真实公司里的信息化，不是把纸质表格搬到网页上，也不是做几个漂亮页面。它更像是在把原来靠人脑、微信群、Excel、口头约定维持的东西，一点点变成可追踪、可复核、可调整的结构。

这件事并不浪漫。它经常很琐碎，甚至很烦。

字段命名、单据状态、审批口径、财务期间、权限隔离、历史数据修复、异常流程兜底，每一项单独看都不大。但它们叠在一起，就决定了一个系统到底是“能演示”，还是“能长期运行”。

我现在对“能长期运行”这件事的兴趣，已经超过了对某个框架、某种语言、某个新概念的兴趣。

很多人以为复杂系统只存在于大公司。实际上，小公司也有小公司的复杂度。

大公司复杂在规模、层级、协作成本和历史包袱。小公司复杂在边界不清楚，一个人可能同时在处理技术、产品、运营、财务沟通、法务风险、客户解释和内部管理。很多时候你不能只说“这不是我的职责”，因为问题如果没人接，它就会一直在那里。

这种环境会迫使人形成一种很具体的能力：既要能写代码，也要能听懂业务；既要能理解老板、财务、客服、运营分别在担心什么，也要能把这些担心翻译成系统规则；既要知道理想设计是什么，也要知道现在只能先做到哪一步。

这不是一个好听的头衔，但它是一种真实能力。

最近我大量使用 AI coding agent，也在尝试让它们进入更严肃的工程流程。用得越多，我越觉得，AI 会把人的问题放大。

如果你只把任务描述成“修一下这个 bug”，AI 很可能会给你一个看起来合理但没有业务上下文的补丁。如果你不能判断哪些 reviewer 意见是真的，哪些是误报，AI 只会让噪音更多。如果你没有把业务规则讲清楚，AI 写代码的速度越快，偏离真实需求的速度也越快。

反过来，如果上下文足够清楚，边界足够明确，验证足够严肃，AI 会非常有用。它可以帮你读大量代码，交叉审查方案，补齐测试，整理文档，甚至帮你发现自己没有意识到的风险。

所以我现在关心的不是“AI 能不能写代码”，而是“我们能不能把真实问题表达成 AI 和人都能共同工作的结构”。

这也是我做个人背景系统、项目记忆、Agent 工作流和各种工具实验的原因。

如果现在重新介绍自己，我大概会这么说：

我从全栈开发出发，长期在真实业务系统里处理复杂问题。代码是我的基本工具，但我更关心业务流程、组织协作、系统边界和长期可维护性。最近我也在探索 AI 协作、个人知识系统，以及软件如何服务工作之外的长期生活。

这句话没有“架构师”“负责人”“专家”这些词听起来响亮，但它更接近我现在真实在做的事情。

我也不急着把自己包装成某种固定角色。很多事情还在变化，很多方向也还没想清楚。能做的是把做过的事、踩过的坑、形成的判断慢慢写下来。

这大概也是这个站重新整理的原因。